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