4 ms·

Because the official repository has a strict vetting process. You cannot just show up and put your shaddy software in the official repository. Debian packagers

Because the official repository has a strict vetting process. You cannot just show up and put your shaddy software in the official repository. Debian packagers have a mutual trust process which you need to gain. Only trusted Debian packagers can approve packages to be included. Also some Debian maintainers will just randomly check packages from time to time. (e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792580 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792580 )

wfurney 3y ago
Nice classic email spam at the end of that thread! > "All we require from you is your willingness and ability to receive the funds in question"
- amenghra 3y ago
  You can report the spam by clicking on the link at the very bottom (or just going to https://bugs-master.debian.org/cgi-bin/bugspam.cgi?bug=792580 https://bugs-master.debian.org/cgi-bin/bugspam.cgi?bug=79258... and confirming).
throwaway71271 3y ago
the list of contributors is huge, you just need to hack one person https://contributors.debian.org/ https://contributors.debian.org/ not to mention libraries like libxslt that is used by like half the packages even kernel.org was hacked, and git saved us, and luckily it was before the sha1 collision attacks were viable https://www.reddit.com/r/linux/comments/k0mco/kernelorg_compromised/ https://www.reddit.com/r/linux/comments/k0mco/kernelorg_comp... https://crypto.stackexchange.com/questions/99767/how-easy-is-it-in-2022-to-find-a-sha1-collision https://crypto.stackexchange.com/questions/99767/how-easy-is...
- hobobaggins 3y ago
  > you just need to hack one person bribes are probably quicker and easier.
kelnos 3y ago
But Debian packagers aren't always super careful. They generally don't audit the full changeset between each version they package and publish. They mostly trust that upstream has not been compromised and continues to be trustworthy. I'm not trying to minimize all the hard work Debian (or any other distro) packagers do, but "only use official repositories" is not sufficient as a malware-avoidance strategy. Yes, it's better than installing random binaries from random websites, but let's not give ourselves a false sense of security. The suggestion upthread to run everything in a sandbox is a good one. I wish that was more common and that there was a better UX when doing so.
- redeeman 3y ago
  its obviously not a 100% garantuee, but its about as good as anyone can reasonably do
arp242 3y ago
> strict vetting process Eh, don't expect too much from this. It's just the packager downloading a .tar.gz from the website or cloning the version control, maybe checking if it looks alright for a bit at most, maybe check signatures if they're available (or maybe not), and that's usually it. Especially for updates don't expect a "vetting process" of any meaning. The main "defence" is time, not any vetting: usually people find out any problems before packagers have time to update the package or before a package becomes "known enough" to be added to Debian (or any other package repo): there will be GitHub issues, Reddit drama, HN threads, news articles, what-have-you. Things like Chromium has a bunch of eyes, but that's the exception and very much not the rule.

wfurney 3y ago

Nice classic email spam at the end of that thread! > "All we require from you is your willingness and ability to receive the funds in question"

amenghra 3y ago
You can report the spam by clicking on the link at the very bottom (or just going to https://bugs-master.debian.org/cgi-bin/bugspam.cgi?bug=792580 https://bugs-master.debian.org/cgi-bin/bugspam.cgi?bug=79258... and confirming).

throwaway71271 3y ago

the list of contributors is huge, you just need to hack one person https://contributors.debian.org/ https://contributors.debian.org/ not to mention libraries like libxslt that is used by like half the packages even kernel.org was hacked, and git saved us, and luckily it was before the sha1 collision attacks were viable https://www.reddit.com/r/linux/comments/k0mco/kernelorg_compromised/ https://www.reddit.com/r/linux/comments/k0mco/kernelorg_comp... https://crypto.stackexchange.com/questions/99767/how-easy-is-it-in-2022-to-find-a-sha1-collision https://crypto.stackexchange.com/questions/99767/how-easy-is...

hobobaggins 3y ago
> you just need to hack one person bribes are probably quicker and easier.

kelnos 3y ago

But Debian packagers aren't always super careful. They generally don't audit the full changeset between each version they package and publish. They mostly trust that upstream has not been compromised and continues to be trustworthy. I'm not trying to minimize all the hard work Debian (or any other distro) packagers do, but "only use official repositories" is not sufficient as a malware-avoidance strategy. Yes, it's better than installing random binaries from random websites, but let's not give ourselves a false sense of security. The suggestion upthread to run everything in a sandbox is a good one. I wish that was more common and that there was a better UX when doing so.

redeeman 3y ago
its obviously not a 100% garantuee, but its about as good as anyone can reasonably do

arp242 3y ago

> strict vetting process Eh, don't expect too much from this. It's just the packager downloading a .tar.gz from the website or cloning the version control, maybe checking if it looks alright for a bit at most, maybe check signatures if they're available (or maybe not), and that's usually it. Especially for updates don't expect a "vetting process" of any meaning. The main "defence" is time, not any vetting: usually people find out any problems before packagers have time to update the package or before a package becomes "known enough" to be added to Debian (or any other package repo): there will be GitHub issues, Reddit drama, HN threads, news articles, what-have-you. Things like Chromium has a bunch of eyes, but that's the exception and very much not the rule.