4 ms·

I disagree. This is more another reason to not run programs which are not from the official repository.

by acatton 3y ago

throwaway71271 3y ago
why do you think this can not happen in the official repository?
- acatton 3y ago
  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.
- Brian_K_White 3y ago
  Why do you think "can not happen" even matters? No one does think it can not happen, because that is a silly thing to even say. "can not happen" does not exist anywhere, there is only likelihood of happening, based on both history and motivation. How often HAS it happened in any reputable distros official repos? They have all got decades of history by now so a good sea of data to generate solid statistics on frequency and distribution.
  - throwaway71271 3y ago
    it is true, debian particularly has very good track record: https://security.stackexchange.com/questions/243455/was-there-ever-any-malware-found-in-debian-ubuntu-packages https://security.stackexchange.com/questions/243455/was-ther... however, cpan, npm, ports, homebrew, gems etc there are examples: https://docs.brew.sh/Acceptable-Casks#apps-that-bundle-malware https://docs.brew.sh/Acceptable-Casks#apps-that-bundle-malwa... but i was hinting more at the: there are so many packages, and so many that are used rarely, that there is no way we know. i think just running weekly modified files report and running things in sandboxes also dont give internet to all apps is good enough for me, and of course be critical of the sources you install from, reputable repos are better than non reputable ones, but are not immune.
knappe 3y ago
Even packages from the official repos can not be safe. https://www.debian.org/security/2008/dsa-1571 https://www.debian.org/security/2008/dsa-1571 I would just like to remind everyone to be cautious, in general. This bug was in the openssl package, and as a consequence was creating incredibly weak keys, for around 2 years before being discovered in what is arguably one of the most critical pieces of software for the OS.
- blibble 3y ago
  there's a difference between bugs and being actively malicious
- mistrial9 3y ago
  one hundred and sixty thousand signed packages with ten+ years of history and of course, one bad one means the system is "weak"
codedokode 3y ago
Not everything is in official repositories.

I disagree. This is more another reason to not run programs which are not from the official repository.

throwaway71271 3y ago

why do you think this can not happen in the official repository?

acatton 3y ago
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.
Brian_K_White 3y ago
Why do you think "can not happen" even matters? No one does think it can not happen, because that is a silly thing to even say. "can not happen" does not exist anywhere, there is only likelihood of happening, based on both history and motivation. How often HAS it happened in any reputable distros official repos? They have all got decades of history by now so a good sea of data to generate solid statistics on frequency and distribution.
- throwaway71271 3y ago
  it is true, debian particularly has very good track record: https://security.stackexchange.com/questions/243455/was-there-ever-any-malware-found-in-debian-ubuntu-packages https://security.stackexchange.com/questions/243455/was-ther... however, cpan, npm, ports, homebrew, gems etc there are examples: https://docs.brew.sh/Acceptable-Casks#apps-that-bundle-malware https://docs.brew.sh/Acceptable-Casks#apps-that-bundle-malwa... but i was hinting more at the: there are so many packages, and so many that are used rarely, that there is no way we know. i think just running weekly modified files report and running things in sandboxes also dont give internet to all apps is good enough for me, and of course be critical of the sources you install from, reputable repos are better than non reputable ones, but are not immune.

knappe 3y ago

Even packages from the official repos can not be safe. https://www.debian.org/security/2008/dsa-1571 https://www.debian.org/security/2008/dsa-1571 I would just like to remind everyone to be cautious, in general. This bug was in the openssl package, and as a consequence was creating incredibly weak keys, for around 2 years before being discovered in what is arguably one of the most critical pieces of software for the OS.

blibble 3y ago
there's a difference between bugs and being actively malicious
mistrial9 3y ago
one hundred and sixty thousand signed packages with ten+ years of history and of course, one bad one means the system is "weak"

codedokode 3y ago

Not everything is in official repositories.