Hans-Christoph Steiner @eighthave@librem.one

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.

#PublicMoneyPublicCode

@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

It used to be pretty easy to build a local copy of the #Android developer docs. It was quite nice because it was super fast to navigate. I even made a #Debian package for the offline version. #Google broke that back in Android 6.0 or so.

#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.

Started syncing work on the #smali package between #Debian and #KaliLinux, bookworm's libsmali-java provides an update over Kali's own smali package, but there is still a bit more to be done. Hoping this is the start of more cooperation!

Just uploaded to #Debian the key #Android inspection tools #apktool 2.7.0 and the latest #smali from git, ahead of 2.5.2. All sorts of tools like #droidlysis #fdroid #kalilinux and more rely on these for inspecting Android APK files.

Just uploaded #droidlysis v3.4.0 to #Debian. It is an easy way to get started with analyzing #Android APK files to see what is in them.