debiandev

> Are distros doing anything more than scanning CVE databases with the library versions, or are they _actually_ auditing the versions they choose?

Debian Developer here. Part of packaging work, for Python libraries or anything else, is to verify the reliability of the upstream developers, audit the code, set hardening flags, add sandboxing and so on.

I spotted and reported vulnerability myself and it's not uncommon.

This! Asciidoc is the grown-up brother of Markdown. Designed to scale up to entire books, handle images, tables, references, citation, book indexes, maths.

And the syntax is very friendly and intuitive.

Debian Developer here.

Reminder: the Debian Packaging Guidelines are meant for official Debian packages.

Making a package with dpkg-deb -b <dir> <packagename> is very easy and gives all the features of APT (dependency tracking, config management, atomic deployment).

Debian Developer here: upstream developer almost never care to prepare fixes for existing releases.

Debian Developer here. Backporting fixes to tenths of thousands of packages is already a huge amount of (thankless) work.

But it's still done - as long as there's usually one version of a given library in the whole archive.

Imagine doing that for e.g. 5 versions of a given library, embedded in the sources of 30 different packages.

I'm in no way responding to the blog, as you can see in my 4 points. I'm addressing the comments here.

Every time similar content is shared here there's a number of people making exaggerated claims around Debian being dead or in deep trouble.

The other comments accusing me of doing damage control are a good example.

I recommend attending Debian events in person (once COVID is gone) to see that 99% of interactions between people are very friendly.

A couple of healthy reminders to avoid drama and FUD:

1) People announce leaving publicly and the FLOSS community takes notice of it. This is a sign of health of Debian. In many other projects few people notices.

2) The number of Debian developers, projects, and packages has been increasing for decades.

3) For each person writing on mailing lists and blogs there are 10 people quietly contributing.

4) The same applies to the occasional flamewars. Vocal minorities are not representative of the thousands of DDs and contributors.

> the very real dangers of shipping blobs, which probably carries more weight than the dangers of vendoring you outline.

This is a false dichotomy.

> By not having that escape valve

Please do your research before posting. Building packages with bundled dependencies is allowed, actually.

Having a handful of small files from 3rd parties bundled in few packages is relatively harmless (if they are not security critical) and allowed.

Having 200 dependencies with hundreds of thousand SLOC creates a significant burden for security updates.

Put security-critical code in some of dependency and the burden become big. Make the dependencies unstable and it gets worse.

Now create a similar issue for many other packages doing the same and the burden becomes huge, for the whole community.

> This also encourages passive aggressive software design criticisms.

I would call it outspoken criticism of bad software design.

Debian Developer here. Some people take a very cursory look at Debian and assume the packaging is an exercise in masochism that we inflict on ourselves.

And yet the number of DDs keeps increasing (and Debian is one of most successful projects).

Indeed it takes time to do packaging, and this is by design. Packagers are expected to thoroughly review the code they are packaging and smooth out various sharp corners.

Many times I've found bugs in the upstream code while packaging. Sometimes around security and privacy, often around documentation, usability or non-x86 architectures.

Every time I check if other distributions opened bugs or applied patches for the same issues. It almost never happens.

This is why I might spend 2 hours on a package instead of 10 minutes.

Correct.

Furthermore, rebuilding and distributing a large number of large binaries every time a vulnerability is fixed is harmful!

- It encourage users to delay security updates. Hundreds of millions in the world have slow or expensive or capped Internet connectivity.

- Makes the distribution unsuitable for many embedded/IoT/industrial/old devices with very limited storage

- It gives the impression that the distribution is bloated.

You are confusing static linking with embedding library sources.

Debian is available for the lucky PinePhone and PineTab owners, thanks to the Mobian project.

> weird poorly-documented helper scripts which have strange interactions

I've never found a packaging tool without an extensive and clear manpage with examples.

> I think the biggest issue is the social problem of the long and arduous process to become a trusted Debian Developer. Although there's now an easier Debian Maintainer option for restricted access, it's still not easy to become one. Other people have to go through a developer to update or add packages.

There is an arduous process to become a senior engineer in a FAANG, or a tenured professor, or an airline pilot.

That's why a lot of people trust Debian.