open source

Don’t let computers go to waste and join us in fighting restriction on December 20 for the eighteenth International Day Against Digital Restrictions Management (IDAD).

Automation is one key factor that lets the small F-Droid team provide apps
to millions. The @checkupdates-bot
is a new reworking of an old piece of automation in F-Droid:
checkupdates. This goes through all of the existing apps, checks if they
are set up for automatic updates,
and if so, runs the process to automatically generate a new build entry for
that release. That gets added to
fdroiddata, which is what the
production buildserver processes in order to build and ship apps.

Since the best security is provided by systems that follow the principal of
least
privilege, we
recently reorganized our setup and workflow around that principal so that
the @checkupdates-bot has the least privileges needed to do its job. The
checkupdates process now runs in its own isolated project, separate from
fdroiddata and any other F-Droid project on gitlab.com. It now only
pushes commits to its own dedicated
project, then makes
a merge
request
per app to fdroiddata. Both our automated CI processes and our trusted
human reviewers now handle all updates using the same process as for new
apps.

At the same time, we removed a key bit of cruft in our code:
stats/known_apks.txt. This file was the place that stored the dates when
each app was added to the collection. This file was updated on the
buildserver and maintained in fdroiddata. That information is also in
the index file, so we
switched to
fetching it from there instead. That meant we could remove the last deploy
key in use in fdroiddata. Our operations no longer require any deploy
keys in fdroiddata.

While we were at it, we added some additional checks via the merge
requests. For example, now any time an image file is added or modified, a
CI job checks
whether the image contains any EXIF metadata, which can be used as an
exploit vector. We also added some additional enforcement to make sure
changes to key files go through human review via merge requests.

Security issue as inspiration

About a month ago, @SomberNight reported a
security issue to us
in a confidential issue. We appreciate this detailed report, and also want
to highlight their diligent follow up. In specific situations, the old
setup was leaking the private deploy key which granted access to directly
push commits to fdroiddata. We immediately revoked that key, then removed
all privileges from the @fdroidci user that
was associated with that private key. We also investigated all the leads we
could follow to see if someone had used this key to insert something into
F-Droid. We searched the activity of the @fdroidci user and found no
evidence that unauthorized commits were added.

To be sure, we did some additional investigations. Since checkupdates had
been running as part of the fdroiddata project on gitlab.com, a malicious
app build recipe could have also read the CHECKUPDATES_SSH_DEPLOY_KEY
variable which contained the private key. We checked fdroiddata’s history
for signs of exfiltration and found nothing. We require that apps are built
from source code, and that source code is in a source code management system
like Git. That ensures a local copy with history is retained on our
buildserver. We searched our local copy source code and found no evidence
that any app build processes where trying to exfiltrate the checkupdates
private key.

Do you have more ideas for things to search? Please dig in and let us know
if you find anything suspicious. Working in public means everyone is free
to investigate and come to their own conclusions, and contribute to a more
secure free software ecosystem on Android.

I’ve been dropping a lot of hints about my journey to rid myself of Google’s Android on my Pixel 8 Pro lately, a quest which grew in scope until it covered everything from moving to GrapheneOS to dropping Gmail, from moving to open source “stock” Android application replacements to reconsidering my use of Google Photos, from dropping my dependency on Google Keep to setting up Home Assistant, and much, much more. You get the idea: this has turned into a very complex process where I evaluated my every remaining use of big tech, replacing them with alternatives where possible, leaving only a few cases where I’m sticking with what I was using. And yes, this whole process will turn into an article detailing my quest, because I think recent events have made remocing big tech from your life a lot more important than it already was. Anyway, one of the few things I couldn’t find an alternative for was Google Pay’s tap-to-pay functionality in stores. I don’t like using cash – I haven’t held paper money in my hands in like 15 years – and I’d rather keep my bank cards, credit card, and other important documents at home instead of carrying them around and losing them (or worse). As such, I had completely embraced the tap-to-pay lifestyle, with my phone and my Pixel Watch II. Sadly, Google Pay tap-to-pay NFC payments are simply not possible on GrapheneOS (or other de-Googled ROMS, for that matter), because of Google’s stringent certification requirements. Some banks do offer NFC payments through their own applications, but mine does not. I thought this is where the story ended, but as it turns out, there is actually a way to get tap-to-pay NFC payments in stores back: Garmin Pay. Garmin offers this functionality on a number of its watches, and it pretty much works wherever Google Pay or Apple Pay is accepted, too. And best of all: it works just fine on de-Googled Android ROMs. Peope have been asking me to check this out and make it part of my quest, and ever the people-pleaser, I would love to oblige. Sadly, it does require owning a supported Garmin watch, which I don’t have. To guage interest in me testing this, I’ve set up a Ko-Fi goal of €400 you can contribute to. Obviously, this is by no means a must, but if you’re interested in finding out if you can ditch big tech, but keep enjoying the convenience of tap-to-pay NFC payments – this is your chance.

Learn about the top articles published at OpenSource.net in 2024. This site is dedicated to fostering knowledge sharing about Open Source software, hardware, open culture, and open knowledge.