Kevin's musings

I ordered one of the ubports editions of the pine64 pinephone and after a small amount of playing around with it, I’d like to share my thoughts.

First a little background. I’m very big on open source for many many reasons. I use Fedora rawhide for my laptop day to day and in general try and use free software wherever else I can. My phone has been a annoyance to me for many years now. Being completely closed source, apple/i-phones are right out for me, which basically just leaves android. Now you might think “Thats great, android is open source”, but it’s really not. While the source is indeed available, development is done by google in secret and dumped into the open after release. This means you don’t get a lot of the advantages of open source for android. Other forks/projects do take that android source and clean it up and make it nice, but they too are at the mercy of upstream that may change things in a new release drastically, leaving them to try and catch up for months after a new release. I’ve been using /e/ on my trusty one plus 3t for the last 3-4 years. They are based off lineageos and ‘de-google’ things from there. I’ve never found myself very excited by it, they too are trapped by the android development all taking place elsewhere. I’ve looked at other possible software, but they all have their issues.

3 or so years ago, Librem announced they were going to make a phone that was as open as they could make it, with high end specs. As far as I know some few batches have been made/distributed, but it’s still not a realized product. As part of this push however, software was created that could run on most normal linux distributions that could handle phone specific workflows. See https://source.puri.sm/Librem5 for a long list.

Fast forward to late last year: The pine64 folks, who have made a number of aarch64 based products successfully announced the pine phone. They produced a prototype like developer version and then, early this year announced the ubports version (some $’s of each phone would go to the ubports folks), cost: $150. The ubports version sold out and they have now announced a postmarketos version, also with a usb-c “dock”, more memory and a circut board fix to allow usb-c to work right. cost: $200 with dock, or $150 without.

First lets talk about the hardware itself. It’s sturdy and well built. The specs are pretty low end, but thats smart (since it’s older hardware linux support is better) and not too bad considering the cost. The screen is actually pretty bright and looks nice. The back cover is a bit of a pain to take off, but I’d prefer it be that way to being too easy to remove. The phone uses a usb-c type connector for power/etc. As mentioned the ubports and braveheart (the developer release before ubports) have a pcb bug that prevents usb-c from working right. ;( There is a headphone jack, and front and rear cameras. Taking the cover off you can see: removable battery, sim and micro-sd slots and 6 “pogo” pins. These last are for future cover replacements that might have additional functions, like wireless charging or a larger battery or IR sensors. There’s also 6 dip switches allowing you to enable or disable various features. I’m not sure I would use these, but I guess it’s a nice feature for some folks. The ubports version has 2GB ram, the newer postmarketos one will have 3GB. There is 16GB internal eMMC. (32GB in postmarketos version). Bluetooth 4.0, wireless, and modem for LTE/3G/etc. You can get a serial console by switching the dip switch for the headphone jack ‘off’ and then it will do serial console. The speaker, mic, screen, wireless, bluetooth, modem, have all worked nicely for me under various software configs. Overall if the software were up to snuff, I think this would be a ok (if a bit slow) daily driver, but that brings us to software…

The pine phone has a Allwinner a64 cpu (aarch64). In theory any linux distribution that supports that cpu/arch would work. There is of course hardware specific to the pine phone that needs drivers or existing drivers that need tweaking to work with it. Due to that, most distributions are shipping a custom kernel with patches, etc. I sure hope with all the interest this stuff can get all upstreamed.

“Normal” desktops work, but they have drawbacks. For instance running Gnome on a Fedora install, many of the dialogs or windows appear too large to use and there’s no way to scroll around them. One help here is the librem software mentioned above. There’s a replacement for gnome-shell called ‘phosh‘ and a replacement for mutter called ‘phoc‘. They are more suited to small screens and have features like forcing everything to resize to screen, etc. There’s also phone and messaging apps of various stages and types. It’s really nice to be able to ‘dnf install’ something from rawhide, all that software ready to use. 🙂

The pine phone will try and boot from the micro-sd card first, then the eMMC, this allows you to pretty easily try other distros out without really committing to them. 🙂 Of course the eMMC is faster, and if you like you can overwrite it with a tool called jumpdrive. Just boot a micro-sd with jumpdrive, connect your laptop via usb and it will let you flash the eMMC.

Here’s a smattering of the ones I have looked at:

• The phone shipped with ubuntu touch on the eMMC.
• The first one I flashed to a micro-sd was of course Fedora! (more below)
• Mobian (debian for mobile)
• postmarketos (I actually couldn’t get this to boot for some reason)
• Arch
• Manjaro
• Probibly others I have now forgotten…

There’s some places some do better than others, but mostly they seem all at the same place: some things working, others not yet and pretty rapid changes.

The Fedora (unofficial) image is linked off the pinephone fedora wiki page, I did a few local tweaks here after setting up a micro-sd card with it. The image uses lightdm, but that makes gnome or phosh use X11 instead of Wayland, so I switched back to gdm and set it to autologin as the pine user and use phosh. For some reason you have to run ‘pineaudio’ from the command line once before the phone speaker will work right. I think it’s just in the wrong mode by default. dnf works fine. gnome-software works fine to install things.

In order for me to use a pine phone as my daily phone I need at least these things (your list might be completely different):

• Phone calls (this in general works, even bluetooth headsets seem fine)
• SMS and MMS (sms works, mms doesn’t)
• ebook reading (works fine, number of apps to choose from)
• RSS feed reading from my tt-rss setup. (Newsflash works nicely!)
• picture taking/upload (Some folks claim to have working camera, but I have yet to see it with any of the images I have looked at).
• Battery life a least a day (This is claimed now depending on what you do of course, see more below).
• maps/gps for when I travel (pretty rare these days). Gnome maps works surprisingly well here.
• Twitter (I should stop doomscrolling… but cawbird has a bug to be better on mobile sized screens).
• Light web browsing (check something, settle bet in bar, look up some info). Firefox is a bit sluggish, but it works.
• OTP app ( There has to be one right? right? I guess OTPClient if someone wants to package it for Fedora)
• Music playing (usually in car over bluetooth to the car speakers)
• Alarm clock (I think this should be doable, but not sure there’s a good linux app to manage it)
• Podcasts (also usually while traveling which… yeah. gPodder seems to work fine though)
• Weather (lots of options here, too bad about darksky tho)
• Very rare email checking (I would think most any email app would work here)
• IRC (oddly, hexchat has horrible problems resizing and input in dialogs is all messed up, I am not sure why. If nothing else, irssi would work fine in a tmux)
• Encryption support. The only distro I tried that had mention of this so far as postmarketos. It supposedly has a installer than can encrypt. Of course there’s workarounds here too. Could boot/use the eMMC for the os and encrypt a micro-sd for data. Then in the event of theft, at least the data could be safe.

Then current blockers for me are: MMS, camera working, OTP app, possibly battery life and possibly encrypted storage.

MMS needs development work. The librem folks asked ModemManager to implement it, but they feel it should be a seperate app that interfaces with MM. Hopefully this will move forward. In the US at least, lots of things are MMS (anytime it’s more than 1 person, anytime it’s over a size limit, etc)

The camera is clamed working, but It obviously needs more work. Cheese can’t get anything from it. Also it would be very nice if we had something like opencamera for linux. It has tons of adjustments and ability.

For OTP apps I did find OTPClient. Looks like it might fit the bill, but it’s not in Fedora yet. Any packages want to take it on? 🙂 If not, I might when I get some time.

I haven’t really run the phone with a sim in it and using it off power so battery life is a bit of a question. On the plus side however, folks have gotten crust ported to it. As I understand it, this is software that runs in a secondary CPU that can handle power management outside the main OS/cpu. So, it can suspend on idle, power things off that aren’t being used, etc. With this folks are claiming 100+ hours of complete standby and less of course with modem active. Suspend/resume does seem to work fine on most all of the distros I tried.

So, I am encouraged. I went ahead and ordered one of the postmarket os ones too, since I don’t think I am up to the soldering fix for the usb-c and another GB memory is likely to be nice. I really hope over the next months we see things get upstreamed to the linux kernel, things like MMS and camera get sorted out, and always performance and battery life could be improved. Once the kernel stuff is mostly worked out, I wonder if there is interest/desire to make a official image for the phone? With that we could curate a selection of apps we know works and get things setup right and additionally down the road ship a version based on a stable release instead of rawhide. 😉 It will be a lovely day I can run Fedora on my phone day to day.

I’ve been busy and remiss in blogging and this is something I was hoping to publish a while ago, so I give you… a review of the onlykey.

The onlykey is a USB2 connectable hardware security key. Many of you may know yubikeys, this is a competitor to those, with some advantages and disadvantages.

Ordering was simple, I just ordered one via amazon and had it 2 days later. You can also order directly from the onlykey website.

Right away you will note that this doesn’t have just one key like the yubikeys do, but instead has 6 of them. Additionally, it’s got a colored LED underneath, which shines green when it’s unlocked, flashes red when you enter an incorrect pin, etc. The idea here is that the key will be completely locked and useless to others until its plugged in and a correct pin is entered (yes, there’s more than one correct pin 🙂 This key only comes in USB2 form as they say USBC would be too fragile. You can of course use a USB2 -> USBC adapter.

There’s Several ways to manage the key:

• A chrom(imum) “app”. (Although chrome is discontinuing these)
• A “snap”
• A debian .deb package

So, thats not great for Fedora. I tried to get the snap working, but it failed. I tried to use the chrome app, but thats how I found that they are dropping those, so I went with the debian package unpacked and just using the application from there. The app is open source if anyone wants to package it up: https://github.com/trustcrypto/OnlyKey-App (It’s npm based)

Right off the bat I hit an issue. My onlykey had old firmware and it was old enough that the app was unable to update it, so I had to monkey around with “Teensy loader” to upgrade the firmware. At one point the key stopped even lighting up and I asked for help on the onlykey discussion group. They had someone answer me pretty quickly and I found that I wasn’t properly shorting the two contacts on each end of the key to put it in ‘upload firmware mode’. After I did that I managed to update to the new firmware and everything was smooth sailing after that. I really hope they have all their existing stock updated now so no one else should have to go through this. 🙂 Just look at these little contacts you have to short together while pressing the upload button on Teensy Loader! I managed to do it with a hanger from a xmas tree ornament finally:

There’s a sort of soft rubber case around the key, you can get all kinds of colors (I just stuck with black). It also comes with the handy little carribeener to attach it to your keychain or whatever.

So, once you have the firmware somewhat up to date, you can run the app. It will also update firmware as long as it’s not too old. The firmware is open source: https://github.com/trustcrypto/OnlyKey-Firmware

On your first run (or if you factory wipe it), you have to do a bit of setup. You can enter 2 profile pins (sequences of buttons). They suggest that this might be ‘work’ and ‘home’, but you could use them for whatever you like. You can also enter a ‘self destruct’ profile pin, which wipes back to factory settings if you enter it. You can also tell it to do this if someone enters the wrong pin 10 times, but it will flash red and stop taking input after 3 failed pins. So to wipe it this way you have to enter 3 wrong pins, remove, insert, 3 more wrong pins, remove, insert 3 more wrong pins, remove, insert, 1 more wrong pin. You can also load a firmware called the “International Travel Edition” that has no encryption at all (it’s only protected by the pin).

Once you have your profiles setup you can configure what you want in the slots. There’s actually 12 slots because (just like yubikeys) there is long press and short press on each button. You can assign whatever you like to those 24 slots (12 for each profile). You can do TOTP, U2F, Yubikey HOTP, username/password, tabs or returns, all kinds of things:

You can do encrypted backups of the contents of the key and of course restore them. There’s also some misc settings like how bright the LED is or how fast the keyboard types or what keyboard layout it uses. There’s some integration with keybase.io to do encrypted files/messages transfer.

Finally, there’s some advanced prefs about yubikeys and U2F tokens. I was confused by these at devconf, but the manual explains: https://docs.crp.to/usersguide.html#Yubico-one-time-password basically you have to run yubikey-personalize and have it generate “Public Identify, Private Identity, and Secret Key” which you then enter into the onlykey app. I can only assume they couldn’t just do this due to legal concerns. The U2F prefs are there because:

For the attestation certificates OnlyKey comes with a default attestation certificate and signing key and also allows users or enterprises to import their own attestation certificate/key. This feature allows organizations to only permit FIDO2 keys issued by the organization to be used. Importing attestation certificates and signing keys can be done in the OnlyKey app.

The manual is pretty easy to read and covers all this better than I can probibly. So, on to the actual reviewing:

First the good:

• Open source firmware and app!
• Nice to know that if someone stole it, they would not be able to access anything using it.
• Seems to work fine for U2F/webauthn, TOTP, HOTP and user/pass.
• The LED light is nice to know what state it’s in.
• I like being able to do encrypted backups.
• Having a bunch more slots is nice (If you forget which is which, you can press and hold down the 2 button for 5+ seconds and it will print out the labels you gave the slots).

Now the not so good:

• You can set a timeout where the key will lock after X minutes. It works and the LED goes off but the application if you have it open will happily think it’s still talking to the unlocked key (until you try and do something then it errors).
• You can sort of use it for keeping your ssh private key, but not easily. You have to import a key (using only very specific ecc curves) and then use a ‘onlykey-agent’ instead of normal ssh agent. This is a fork of another project and hasn’t been updated from that fork for like 4 years, which is really not encouraging. 🙁
• It’s a bit odd trying to type in your pin at say a coffee shop or table with a bunch of co-workers around. It seems like you can’t really hide what you are pressing. Still it is more secure than just any unlocked always token.

For me personally, the lack of a nice way to use it for storing my ssh private key is somewhat of a deal breaker. I really really don’t want that key to get out (even though it is passphrase protected). My current yubikey was able to generate it on key and keep it always stored there. If I didn’t care so much about ssh keys I might well move to using the onlykey day to day. If I traveled much I definitely would look at using it while traveling.

With the opening up of EPEL8, there’s a lot of folks looking and seeing packages they formerly used in EPEL6/7 not being available and wondering why. The reason is simple: EPEL is not a fixed exact list of packages, it’s a framework that allows interested parties to build and provide the packages they are interested in providing to the community.

This means for a package to be in EPEL8, it requires a maintainer to step forward and explicitly ask “I’d like to maintain this in EPEL8” and then build, test and do all the other things needed to provide that package.

The reason for this is simple: We want a high quality, maintained collection of packages. Simply building things once and never again doesn’t allow for someone fixing bugs, updating the package or adjusting it for other changes. We need a active maintainer there willing and able to do the work.

So, if you do see some package missing that you would really like, how do you get it added to the collection? First, open a bug in bugzilla.redhat.com against the package. If it has a Fedora EPEL product version, use that, otherwise use Fedora. Explain that you would really like the current Fedora/EPEL6/7 maintainers to also maintain it for EPEL8. If they are willing, they will answer in the bug. If no answer after a few weeks, you could consider maintaining the package yourself. Consult with the epel-devel list or #epel-devel on IRC for further options.

Do note that mailing maintainer(s) directly isn’t nearly as good as just filing a bug. They would get the bug info anyhow in email, Other users might see that and add that they too want the package, the maintainer might hand off the package and the new packager could see the bug request but have no idea about private emails, some other packager might see the bug and offer to maintain it. All wins for a bug over private emails.

As the collection grows, these sorts of questions will likely die down, but it’s important to remember that every package needs (at least) one maintainer.