Hans-Christoph Steiner @eighthave@librem.one
Joined Aug 2019
#apksigner v35.0.2 is now in #Debian trixie. The v3.1 signer rotation stuff needs testing. Please try it out!
Getting apksigner from Debian has two key advantages over the Google binaries:
* They are reproducibly built.
* They have an actual free software license.
The upcoming #Debian trixie release will ship with apksigner v35.0.2, which supports the APK v3.1 signer rotation. It is also reproducibly built, of course. I'll make a backport for bookworm too.
There are all too often complaints about #Debian: "why does it have such old packages". There is a really lovely property of properly maintained stable distribution. The only changes made are to make it more stable and more secure, e.g. targeted bug fixes only. New bugs come with new features, or even more general, new bugs come with new code. So if a release of software is already addressing the need, then new features are just adding more risk of problems
A popular dev culture these days is bult on always pulling in the latest library #updates whenever possible. There can be good reasons to do that but new library code must still be reviewed. Or at least, confirm that the maintainers have been doing that, and still are. If you've even been through a code audit, it becomes crystal clear that dependencies are part of the #security profile. #Debian provides another layer of review. I use deps from Debian and review when updating packages, to share.
#Debian has been moving more towards the deb.debian.org mirror which is provided by a single CDN company, #Fastly. It works well, but also feeds an enormous amount of #metadata to a single company, and it can be used to track computers and maybe even people. And the privacy policy in effect is unclear. Fastly says the #privacy policy of the "subscriber" applies, but the privacy policy for deb.debian.org is not listed anywhere I could find. Anyone have any insight here?
I'm working on a small project on the history of built-in "app stores". My hypothesis is that this idea actually originates from #GNULinux distros like #Debian. That was my personal experience of it. I started using computers in 1981 and have used DOS, Apple ][, C64, OS/2, GEM, Windows, MacOS, NeXTSTEP, MacOSX, Solaris, AIX, IRIX, OpenBSD, FreeBSD, and many distros starting with Slackware. I know the history of Debian, iOS, and Android well. Anyone have any other examples I might have missed?
Just migrated my #offline #gnupg and #ssh key setup to a new #smartcard. This only took about 8 hours whereas when I last did this in 2015, it took much longer. I guess this is a sign of process! But these things are still too painful. At least now, the software just works right out of #Debian.
Anyone procuring #Chromebook hardware with public funding, like for schools, should be aware that the expiration date on that hardware is artificially created by #Google since they maintain their firmware as incompatible with other standards. Given a properly structured firmware, any old #Chrome device would run #Debian or other #GNULinux just fine. The #Chromium team operates in public and has done a good job of releasing their source, but the bad structure remains.
@elly and @domi outline how #Google has structured their firmware to make it incompatible with the standard methods of booting an OS. So even though it is open source and #Google upstreams their #Linux changes, lots of key functionality like audio, USB ports, etc does not work when booting any other OS (e.g. GNU/Linux or even Windows). This serves to lock the hardware to #Chrome, and thereby generate lots of e-waste when Google drops support for hardware which #Debian supports.
I'm happy to see more attention given to freeing #Chromebook hardware. They already are built on free software, so with some focused attention on supporting them well with #FreeSoftware distros like #Debian, the number of good GNU/Linux laptops can be greatly expanded. #Depthcharge should be as well understood as other BIOS things. Thanks to @elly and @domi for your #37c3 talk: https://media.ccc.de/v/37c3-11929-turning_chromebooks_into_regular_laptops
When organizations that use #Debian maintain the packages they use in Debian, the whole ecosystem gains. The more organizations that do that, the more efficient the whole ecosystem becomes for all users. Here's a recent example from #FDroid:
https://f-droid.org/2023/10/10/f-droid-maintains-in-debian.html
I'm a Debian Developer, I'm happy to help get organizations working in this way. Reach out if you're interested!
Perhaps the most difficult case ever for #Debian packagers: #Gradle They do all the things that make packaging a nightmare:
* Build the tool with itself
* Circular dependencies: Gradle needs #Kotlin to build which needs Gradle to build...
* Depend on snapshots to build releases, but then they don't keep a way to reproduce the snapshot releases https://github.com/gradle/gradle/issues/26516
* Java-style bundling of all dependencies
* Hidden proprietary depends https://github.com/gradle/gradle/issues/16439
thanks ebourg for keeping on!
The #WebP #security vulnerability CVE-2023-4863 demonstrates a huge advantage of the "distro" approach of shipping software, like #Debian pushes so hard to deliver. We see a mad scramble for many software vendors to ship with the patched version of #libwebp. In the distro model, the patch is shipped in the single lib package, then all of the software automatically uses the safe version. This leads to shorter times to get fixes to users with much less work overall.
So I just worked through trying to make #Debian bookworm do hibernation with encrypted swap and #SecureBoot. Looks like #Linux is fine with using a swap file from an encrypted partition, but now the requirement is apparently that the swap is signed to prevent modification. I stuck what I know here https://wiki.debian.org/Hibernation#UEFI_.2F_Secure_Boot
#Tor Project maintains their tools in #Debian, giving them a base platform delivered with #ReproducibleBuilds and the rest of the Debian users get a better maintained Debian.
https://blog.torproject.org/built-with-purpose-puppet-debian/
I'd like to have something that automatically convert links to the #privacy preserving version in the browser. Like play #youtube links in #invidious, etc. There seems to be things like #UntrackMe but for me the question is which one to trust, is maintained, works well enough, etc. Once I find a tool that I think it generally applicable, then I work to get it into #Debian so its easy for others to make this decision. Is there a browser extension for this that is worth getting into Debian?
After using #NeXTSTEP/#macOS from 1994-2012, I reached the same conclusion as Ken Thompson: "I've become more and more depressed, and what #Apple is doing to something that should allow you to work is just atrocious... And I have come, within the last month or two, to say, even though I've invested, you know, a zillion years in Apple — I'm throwing it away. And I'm going to Linux. To #Raspbian in particular." https://www.youtube.com/watch?v=kaandEt_pKw&t=3473s
As a #Debian #Developer, I'd like to say: Welcome!
Just tagged v2.2.1 of #FDroid fdroidserver tools package, and uploaded it to pypi.org, #Debian, and our #Ubuntu PPA. This version has passed autopkgtest in Debian/bookworm, so it looks like it should make it into bookworm without further work https://tracker.debian.org/pkg/fdroidserver
#FreeSoftware was almost mentioned at #DMAWorkshop: one key point was that mobile operating systems in 2008 were in a race to get developers. #iOS and #Android were tiny newcomers with no developers. The idea from app stores came from free software and hackers. #Debian APT started in the 90s, #Cydia was on iOS when #Apple was still saying web apps were the only way. And of course, #Android used #OpenSource as a key strategy to get #developers interested in their platform.
Joined Aug 2019
