HN user
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.
This is good advice for software lifecycle management in general:
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.
Again, I'm talking about the article: "avoid drama and FUD" refers to HN.
Especially the word "avoid", knowing that the article is already written.
In the meantime, I'd recommend reading the blog: in it a Debian developer mentions having very friendly interactions
And still, you keep assuming that I'm not talking in good faith and that I'm trying to subtly attack he article.
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.
Here are some answers:
No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to.
[citation needed]
And, what's more, the contracts we're talking about are all basically pro-forma.
I had very custom employment contracts with 2 well-known large tech companies. When asking to remove some clauses and add new ones they did not flinch at the ask and let me have meetings with their lawyers.
I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on
Matasano is not the size of a FAANG and similar or maybe it has a small legal team by choice.
AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s risk aversion, not ideology, and it’s important to remember that identifying an argument as part of legal review does not call it the correct one. Anyone who’s ever worked with legal matters knows there is no such thing as “correct,” there are rulings. The existence of the argument condemns the license for FAANG, not its validity.
Having worked with lawyers, this largely overstates the risk. Companies are happy to discuss, modify and sign new contracts every day.
All these contracts are "unchallenged in court", by definition, because they are entirely custom.
A lot of software licensing contracts for closed source have complex and restrictive clauses to prevent "renting" such software through SaaS or weakening limitations using legal loopholes.
Yet companies still sign such contracts.
Another type of custom and complex contract is employment.
Furthermore, companies sue each other every other day over contract violation around IP, copyright, trademarks, patents but also employment contracts, rent, building regulations, shipment delays, all of that.
The idea that a FLOSS license is some scary monster is propaganda.
The goal of such propaganda is to drive the FLOSS community to provide valuable software for free and with zero strings attached - aka free labor.
After a couple of months with lawyers, it's now a major AGPL supporter
I had a similar experience. I took exams on patent and copyright law with IP lawyers as teachers during my degree.
Then I worked in well known tech companies and had the opportunity to attend meetings with lawyers, business people, read contracts, etc. and oh boy!
Misconceptions abound terribly. The average techie overestimates his/her understanding of law and business.
"permissive" licenses are stupidly lenient. Companies never sign similar contracts between each other when exchanging goods or services. Contracts have hundreds of defensive clauses to mitigate risks or ensure fairness.
I was hoping that he would be able to just double click the .deb file and install with no hassle, but he couldn't. I don't know if was the package manager fault or google's
And yet people praise Android for "inventing" the app store and preventing people from [inadvertently] installing stuff from random website.
It's been around since 13 years at least. I remember a website [1] that offered such installer.
[1] https://web.archive.org/web/20160523181321/http://goodbye-mi...
huh?
DD here. The main "barrier" is the level of quality required.
Simply throwing a bunch of files into a package or a container is very quick.
Making an official Debian package is not supposed to be quick. DDs thoroughly review and test the software they are packaging. While packaging I often chase missing licensing information, find plenty of bugs, write systemd unit/init files and sandboxing, write manpages, functional tests, and sometimes find serious vulnerabilities.
I worked on various packaging and deploying systems, and most other distributions don't come anywhere close to this level of scrutiny.
I should also add that becoming a DD requires years of commitment and proven track record of work.
The next time someone complains that making a container is very easy in comparison they should ask themselves: how much can I trust a software source with a very low entry bar?
DD here.
apt-get install maint-guide ...and then read:
file:///usr/share/developers-reference/index.html file:///usr/share/doc/maint-guide/html/index.en.html
Also look at existing packages and talk to DDs. Avoid random wikis.
I worked on many deployment systems and reading these guides made me a better engineer overall.
...
that they tend to take popcon statistics as evidence
Please provide a source to back that claim.
...not to mention that (some) distributions do extensive security and legal compliance reviews...
That's what distributions are for.
Just write software that is not unnecessarily difficult to package.
This is a reason for Debian to exists.
Licenses cannot be reviewed automatically in a reliable way. Debian developers review the licenses and store them in a machine-parsable file.
And this is why Debian exists.
When packaging we are required to disable privacy harming "features".