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 #Debian, @fdroidorg, #MavenCentral. Then other pieces can be safely automated https://www.bleepingcomputer.com/news/security/critical-cloudflare-cdn-flaw-allowed-compromise-of-12-percent-of-all-sites/
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 #Android #Debian #Windows #iOS 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 #VerifiedBoot itself. Here's a real world full #exploit of verified boot:
#Debian created an ecosystem where the software available there is reviewed and trusted, so the system can prioritize flexibility over security. In #Google Play, there are many apps we feel forced to use, despite knowing they are unethical or are tracking us. Google responds by locking down #Android to reduce data leaks, which also reduces the system's flexibility. #FreeSoftware puts the user in control so we can build user-friendly systems without being forced into bad decisions.
If anyone is looking for a #ReproducibleBuilds #Java / #Android project to hack around with, jtorctl now builds with #Gradle (from gradle.org or #Debian), #Maven, and #Bazel with sketches of Ant. The idea is that if all the build tools make the same JAR, no need to trust the build tool.
Key parts of the #Debian #AndroidDev 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 #ARM and #MIPS packages make it into #bullseye. We need contributors! If you can help, see: