Hans-Christoph Steiner @eighthave@librem.one

PSA: The panic button features built into F-Droid break when targeting newer Android SDK versions (e.g. #targetSdkVersion) due to new restrictions.

It might be possible to get them working again, but we currently do not have the bandwidth to maintain this. We welcome contributions to get it going again. Until then, removing the panic features looks to be our only responsible course of action. #CalyxOS includes built-in panic features like app removal, so that is a recommended replacement.

This week in #FDroid was published again.

You should read it if you're on Android 7 or older. For those on newer versions we have following tl;dr, but you're also welcome to read it all:

- 1.20 is in the making with even better repo handling
- custom Anti-Features will be on by default
- TetheredNet will be a new AF
- our website still has problems with localization
- Bunny Media Editor is new
- Secreto is now known as Sekreto
- 2 removals, 10 additions and 206 updates

https://f-droid.org/2024/04/04/twif.html

Risk of socially engineered backdoors in critical software seems like an indictment of open-source projects, but it could happen anywhere, EFF’s Molly told @theintercept - in fact, this one was found only due to the project’s open nature.
https://theintercept.com/2024/04/03/linux-hack-xz-utils-backdoor/

Bullying in Open Source Software Is a Massive Security Vulnerability https://www.404media.co/xz-backdoor-bullying-in-open-source-software-is-a-massive-security-vulnerability/

Some thoughts about attribution in the XZ backdoor, having just wasted so many hours digging into the details.

The email addresses used for a couple of years at least by the parties involved have absolutely *zero* trace in any kind data breach or database beyond Github/Gitlab, and maybe Tukaani and Debian and a few mailing lists.

Normally when I see this, the assumption is that we're dealing with a single-use or single-purpose email address that was created either for fraud or b/c someone is super paranoid about privacy.

The people in the latter camp who do this tend to have other tells that give them away, or at least *some* trace or home base in the online world. Especially if we're talking on the order of years using that address.

Either way, very few people do opsec well, and for every year you're operating under the same name, nick, number, email, etc you dramatically increase the risk of screwing up that opsec. And almost everyone does, eventually.

To see this complete lack of presence in breached databases once or twice in the course of an investigation is rare, but to find it multiple times suggests we're dealing with an operation that was set up carefully from the beginning. And that almost certainly means a group project (state-sponsored).

First more detailed analysis of the backdoor AFAIK, in this Bluesky thread: https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b

So the backdoor’s intention isn’t compromising SSH sessions but rather executing arbitrary code on vulnerable Linux servers. The payload is hidden within the RSA key sent to the SSH server during authentication. This payload has to be signed with some unknown Ed448 key which only the attackers possess. If the signature is deemed correct, the payload is passed to system() (executes it as a shell command). Otherwise the code falls back to the default SSH behavior.

Had this backdoor been discovered a few months later, we would now have a lot of vulnerable servers all over the world. And only the attackers would be able to detect from outside which ones are vulnerable, because only they can send a correctly signed payload that would trigger command execution.

Planting a command execution backdoor into most Linux servers out there sounds too ambitious for someone driven by monetary interests, there are simpler ways to build a botnet. The level of sophistication and long-term planning indicates a state-level actor. Unfortunately, there isn’t a shortage of candidates. With quite a few Western governments pushing for lawful interception lately, I wouldn’t rule out any country at this point.

It is now possible to re-order the position of repositories in the list. The repo at the top has the highest priority while the repo at the bottom has the lowest priority. Only if an app is available from more than one repo, the priority matters.

For example, if NewPipe's repo was added and the user always wants to prefer apps from that repo, they can move it to the top. In older versions of F-Droid, newly added repos were implicitly granted higher priority than repos added before.

If the app is available from more than one repository, the box in the app details screen becomes a drop-down where the user can see all repos and choose which one should be used for installation, updates and app information.

When tapping an app, the user sees the app details screen as usual. There, a new box at the top shows the repository the app comes from.

All information on that page including the versions provided for installation are provided by that repo.

Version 1.20 of @fdroidorg brings some pretty big changes of how repositories are handled:

• official repo is always preferred
• the repo an app comes from is prominently shown
• if an app is available from more than one repo, they can choose where to get it from
• power users can change global repo priorities

If you did not yet opt-in to beta versions of F-Droid, please manually install 1.20 and help testing before we make it available for everyone.

Are you experienced with GTK and Rust ? ❤️

We are looking to contract someone to work on the new GNOME Password Manager 🔑

We want it to become a core/default app and help secure millions of users.

You'll be working with the GNOME Foundation, a non-profit dedicated to building emancipatory technologies for everyone.

Please send resume / portfolio to stf@gnome.org

Boosts welcome

#GTK #Rust #rustlang #GNOME #Linux #Ubuntu #Linux #Fedora #OpenSUSE #Debian

Its also kinda enlightening on how distros react to the #xz backdoor:
* #arch "lets rerelease the version from the untrusted party, we run autogen.sh ourselves now"
* #debian "lets roll back to the last version not having any changes by the untrusted party and rebuild our infra from scratch"

I know which of these I trust more as an upstream ...