and require signature verification, and is built on top of 's APK signing. This improves things a lot but does not mean they are immune. Debian and F-Droid repos can still override packages lower priority repos. It could make sense to have a "no overrides allowed" setting, but that would restrict useful features. Maybe F-Droid could implement "no new signing keys when overriding" rule by default, I wonder how much that would break what people are doing now? 2/2

Show thread

I'm sad to say that my new still needs non-free firmware blobs for working WiFi, Bluetooth, audio, and power management. Now will include those in the installer. Are we losing this fight? At least the graphics driver is and included in upstream Linux, that is progress. I specifically avoided for that purpose.

How are others feeling on the firmware blob fight?

@ljacomet I just saw your slides for your talk "Protecting your organization
against attacks via the
build system", a great overview! I'm a dev who has worked on packaging . We'd love to make it as close to your version as possible. There is a proprietary build dependency that blocks that from happening. github.com/gradle/gradle/issue

Hosting code with automated publishing into well known namespaces is looking more and more like a broken model. A better approach is human verification of package names like in , @fdroidorg, . Then other pieces can be safely automated bleepingcomputer.com/news/secu

I'd love to see data on what verified boot actually stops. The ideal malware implants itself at the lowest level possible. Is there good public data on these kinds of exploits on etc? Does standard spyware do that? Writing to /system requires a root exploit, lots of malware never gets root. How often there are vulns in itself. Here's a real world full of verified boot:
threatpost.com/multiple-vulner

created an ecosystem where the software available there is reviewed and trusted, so the system can prioritize flexibility over security. In Play, there are many apps we feel forced to use, despite knowing they are unethical or are tracking us. Google responds by locking down to reduce data leaks, which also reduces the system's flexibility. puts the user in control so we can build user-friendly systems without being forced into bad decisions.

If anyone is looking for a / project to hack around with, jtorctl now builds with (from gradle.org or ), , and with sketches of Ant. The idea is that if all the build tools make the same JAR, no need to trust the build tool.

GitLab.com/eighthave/jtorctl or GitHub.com/eighthave/jtorctl

Key parts of the tools package suite no longer build on anything but x86. This is also true with the new 10.0.0 version. I'd love to see the and packages make it into . We need contributors! If you can help, see:

bugs.debian.org/cgi-bin/bugrep

image/svg+xml Librem Chat image/svg+xml