Hacker Newsnew | past | comments | ask | show | jobs | submit | eeZah7Ux's commentslogin

> No one does that by hand after a certain size

This is not true


Yes, having a good std library would be fine. It would really limit the proliferation of crates.


> the FDA allows levels 100x higher than what Europe considers safe

I thought it was an exaggeration so I checked. It's actually even worse:

EU is 0.2 ng/kg body weight and US is 50 µg/kg body weight. So the US limit is 250,000 times higher.


> process isolation, increased security

no, that's sandboxing.


The reason is bribery.


Stay away from them.


> greater LGBTQ+ acceptance recently has led to people being more open with that side of themselves, rather than it being the result of environmental pollution

That's a very weird implication. All human beings are complex products of social, economical, genetic, environmental and historical factors.

External factors do not make a person "less themselves" or "less real".


I think he's overstating the impact, but external factors absolutely impact how people present themselves.

There aren't to many openly gay Saudi Arabians.


Do you think Saudi Arabia is secretly 20% LGBT, like the US gen-z is openly?


That suspiciously high 20% doesn't just include people who are LGB or identify as T. It originates from a poll commissioned by GLAAD, who also included in that category anyone who described themselves as "gender non-conforming". Which could mean anything really: clothing styles, haircuts, hobbies, etc.


Then the problem is in the company and not in the license.


Hell no, I want stuff like OnCall packaged into Linux distribution. I need something stable and reliable and that receive security fixes.

Maintaining tenths of binaries pulled from random github projects over the years is a nightmare.

(Not to mention all the issues around supply chain management, licensing issues, homecalling and so on)


At this point I trust the Go modules supply chain considerably more than any free distro's packaging, which is ultimately pulling from GitHub anyway.


This is plain false. Most production-grade distribution do extensive vetting of the packages, both in terms of code and legal.

Additionally, distribution packages are tested by a significant number of users before the release.

Nothing of this sort happens around any language-specific package manager. You just get whatever happens to be around all software forges.

Unsurprisingly, there has been many serious supply chain attacks in the last 5 years. None of which affected the usual big distros.


> None of which affected the usual big distros.

I guess we can argue about "big" but didn't both Arch (https://lists.archlinux.org/pipermail/aur-general/2018-July/...) and Gentoo (https://wiki.gentoo.org/wiki/Project:Infrastructure/Incident... and older, https://bugs.gentoo.org/show_bug.cgi?id=323691) have actual compromised packages? And also not five years ago, but Fedora (https://lists.fedoraproject.org/pipermail/announce/2011-Janu...) and Debian (https://www.debian.org/News/2003/20031202) had compromises but no known package changes.


No, Go modules implement a global TOFU checksum database. Obviously a compromised upstream at initial pull would not be affected, but distros (other than the well-scoped commercial ones) don’t do anything close to security audits of every module they package either. Real-world untargeted SCAs come from compromised upstreams, not long-term bad faith actors. Go modules protects against that (as well as other forms of upstream incompetence that break immutable artifacts / deterministic builds).

MVS also prevents unexpected upgrades just because someone deleted a lockfile.


> At this point I trust the Go modules supply chain considerably more than any free distro's packaging

What has happened in the package ecosystem to make you believe this? Is it velocity of updates or actual trust?

I haven’t heard of any malicious package maintainers.


Better automation ensuring packages are immutable, fewer humans in the packaging loop.


generally I prefer humans in the loop, someone to actually test things. This is why distros are stable compared to other distros which are more bleeding edge.


For SC security, the fewer points of attack between me and the source the better.

For other kinds of quality, I have my own tests which are much more relevant to my use cases than whatever the distro maintainers are doing.

I've been a DD and while distros do work to integrate disparate upstreams as well as possible, they rarely reject packages for being fundamentally low quality or make significant quality judgements qua their role as maintainer (only when they're a maintainer because they're also a direct user). Other distributions do even less than Debian.


I have seen scenarios where package maintainers have rejected updating packages because the upstream is compromised though.


Fedora currently packages 10646 crates. It's implausible that they're manually auditing each one at each upgrade for anything other than "test suites pass", let alone something like obfuscated security vulnerabilities.

In the end most distros will be saved by the fact they don't upgrade quickly. Which is also accomplished by MVS without putting another attack vector in the pipeline.


No person manages more than 250 packages (and he's a RH employee).

There's more than a hundred package maintainers (I'm not sure exactly how many), but the median is about 50 packages.

Do you think people can't keep up with the updates for 50 packages?


I think I don't want "more than a hundred" additional points of trust, especially if they're trying to audit 50+ projects with various levels of familiarity each. And no, I don't believe one person can give a real audit to 50 packages each release even if was their actual job.

To paraphrase, all "more than a hundred" of those people need to be lucky every time.


dagger.io: "Developed in the open by the creators of Docker"

Hard pass.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: