Show more

@alloydflanagan @downey @neil From what I see, it is the other way around: Automattic has a pretty good track record of FOSS (Wordpress, Pocket Casts) while at this point, Beeper is mostly just a consumer of FOSS produced by others. So hopefully Automattic will follow the Pocket Casts pattern and start open sourcing the Beeper app.

@paoloredaelli yeah, I'm sure they're using the existing libraries from @element. The real question is: will they open up their app and get it on !

just acquired and , two chat apps that work with a bunch of bridges to popular apps :

* blog.beeper.com/2024/04/09/bee
* automattic.com/2024/04/09/auto

I really hope they open source it.
Since they are going for a fee-for-service model like Wordpress, I'm optimistic. This is key for breaking the network effects that companies rely on: .

@IzzyOnDroid @fdroidorg I'm happy to see @obfusk continuing with the very important work on signature analysis and the related tooling. I was worried she had stopped working on it after quitting F-Droid. That work is bigger than F-Droid, it is otherwise missing in the Android ecosystem.

@IzzyOnDroid @obfusk @fdroidorg sorry, I guess I should have started a new thread. I'm not so good at the social medias...

@IzzyOnDroid @obfusk @fdroidorg That was not directed at you, that was my takeaway from the analysis I posted in the 1/2 post. The TL;DR.

@IzzyOnDroid @obfusk @fdroidorg They key takeaway is:

If a binary repo maintainer is not careful about where they get their APKs and relies completely on AllowedAPKSigningKeys to verify the APKs, then this is an important issue.

2/2

@IzzyOnDroid @obfusk @fdroidorg All I'm asking is for . The tone you sense was my panic as I scrambled to figure out the proof-of-concept to ensure that users are kept safe. Signature verification is a key part of that. I cleared my schedule this morning to deal with this.

Thanks to @obfusk to doing the hard work of the proof-of-concept and the patch. I posted my preliminary analysis of the issue on gitlab.com/fdroid/fdroidserver

1/2

@IzzyOnDroid @obfusk @fdroidorg Part of the bug was known 11 months ago. The new proof-of-concept shows key details that were not previously known nor reported in the issue. Those were just dumped to the public. We asked for that yesterday, and you didn't send it to us, but withheld it to now publicly dump it. That code was posted to GitHub yesterday: github.com/obfusk/fdroid-fakes

You could have just sent us that link yesterday before tooting it, that would have been better.

@IzzyOnDroid @obfusk @fdroidorg you just published this wide open, yet before, you wouldn't even send us the POC code that you had? I think you two need to learn what means.

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.

@IzzyOnDroid @fdroidorg I looked around but could not find any message from you about this anywhere. If you think this is an important security bug, then please submit what you have ASAP so we can handle it.

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

f-droid.org/2024/04/04/twif.ht

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.
theintercept.com/2024/04/03/li

@Mer__edith Try to find the stressed out, overworked dev who implemented some piece of macOS or Google that annoys you. You can't, they are hidden within the corp. That doesn't mean they aren't an asshole, it just means you can't interact with them. FOSS devs are vastly more likely to operate in public and respond to feedback from anyone. So there is a data bias at work here.

@Mer__edith seems pretty off base to call that FOSS culture. In my 30 years of working in FOSS, the people who are actually immersed in FOSS are much nicer and more helpful than in general. It is the people who treat FOSS contributors of any kind as some kind of service provider that are the shitty ones. Way back, I worked in corp tech support, and got treated shitty. So often, I see people laying on that kind of crap on volunteer FOSS devs on the internet. That is not FOSS culture.

@sehe @gentoobro Free software passion projects are wonderful things. Payment often kills the passion that makes them great. Maintenance of infrastructure is not a passion project and that is what we all should be paying for. I see the moving towards this kind of funding. There are many opportunities for doing this well: for example, orgs like get billions to improve -defense. But they are subordinate to the offensive side who want the 0days. This needs to be exactly the opposite.

This just triggered a thought: the fact that a well resourced actor spent all this time on the focused on distros because they were not able to reliably hack into GNU/Linux in general, so they had to resort to this quite expensive campaign to get access again. Yes, this is speculation and yes I'm a fanboy. But there is a lot of good evidence that the free software distro model is quite good for providing secure setups. So take this news as good news 😄

Show thread
Show more
image/svg+xml Librem Chat image/svg+xml