4 ms·

I don’t follow this reasoning: you might trust this distribution packager to be honest, but this doesn’t stop them from honestly packaging malicious code. It’s

I don’t follow this reasoning: you might trust this distribution packager to be honest, but this doesn’t stop them from honestly packaging malicious code. It’s unlikely that the typical distribution packager is reviewing more than a minority of the code in the packages they’re accepting, especially between updates. There are significant advantages to the distribution model, including exact provenance at the point of delivery. But I think it’s an error to treat it as uniquely trustworthy: it’s the same code either way.

WhyNotHugo 2y ago
"Trust" as two meanings in English: - You can trust someone as in "think they're honest and won't betray me". - You can trust someone as in "think they are competent and won't screw-up". In this case, we trust distributions packagers in both ways. Not only do we trust that they are non-malicious, we also trust that they won't clumsily package code without even skimming through it.
- woodruffw 2y ago
  The point was not about competency. I think typical distribution packagers are very competent. "They won't screw up" is the wrong way to look at security: humans always screw up. We're essentially fallible. We would all do well to remember that the xz backdoor was not caught by distribution code review: it was caught due to a performance side effect that the next adversary will be more careful to avoid. Software stacks are getting bigger, largely due to engineering pressures that are outside of the control of distributions. It's a basic fact that that means work for the same (or fewer) people, which in turn means less time spent on more complicated packages. Under those conditions, competency is not the deciding factor. This is, separately, why having lots of little packages can be (but isn't necessarily) a good thing: small packages that decompose into well-understood units of work can be reviewed more quickly and comprehensively, and can be assigned capabilities that can be tracked and audited with static analysis. You can't do that as easily (or at all) when every package decides to hand-roll its own subcomponents.
  - PaulDavisThe1st 2y ago
    > "They won't screw up" is the wrong way to look at security: humans always screw up. We're essentially fallible. Sure. So pick a system that includes at least one extra possible barrier to them screwing up than the system that has none.
    - woodruffw 2y ago
      It’s not “either or.” It’s been decades since a “package the world” approach has been practical at human scales. (I think it’s great that distributions provide one extra set of eyes. But we’re deluding ourselves if we think that can scale to the actual realized demand for both new software and continuous change to software. It’s also not very fair to the distributions.)
- akerl_ 2y ago
  The average distro package maintainer is not reviewing the underlying code changes in packages to determine if they are malicious, nor is the average disto package maintainer qualified to spot intentionally obfuscated malicious code. The the average distro package maintainers is “person who cares that package repos stay up to date and is willing to commit their time to that work”
- rad_gruchalski 2y ago
  You are making a sweeping assumption that people who create container images are incompetent.
palata 2y ago
It's not only the packager. Some distros have an actual security team. That does not mean they audit everything, but it's vastly better than getting random code from PyPi.
- rad_gruchalski 2y ago
  Some companies providing container images also have security teams. Some companies providing pypi packages also have security teams. Your point is?
  - palata 2y ago
    The point is that if you pull 100 dependencies from PyPi, you have absolutely no idea who you are trusting unless you put the effort to go check those 100 dependencies. If you link to dependencies that you get from Canonical, then you know that a security team is caring about the packages that Canonical distributes and actually patches them. Who patches security issues in PyPi? The individual package maintainers, which may well be pushing a malware leveraging typo-squatting. Typo-squatting is not really a thing in the Ubuntu package manager, is it? Not saying it's perfect. Just that it's better than the far west. PyPi is pretty much like downloading a .exe from a webpage without even opening the webpage (because back in the days, opening the webpage could sometimes - not always - tell you that it was clearly shady).
    - rad_gruchalski 2y ago
      All I hear is “here’s a business opportunity, go figure out if you can sell a python registry with libraries vetted by a security team”. Maybe there’s money in it. Canonical doesn’t do this as a good will. They make money on it, right? Who vets packages for fedora? alpine? arch?
      - croemer 2y ago
        Isn't that what Anaconda does? As opposed to say conda-forge? Anaconda tries hard to get orgs to pay money when they could just use conda-forge which has more packages, more up to date etc.

WhyNotHugo 2y ago

"Trust" as two meanings in English: - You can trust someone as in "think they're honest and won't betray me". - You can trust someone as in "think they are competent and won't screw-up". In this case, we trust distributions packagers in both ways. Not only do we trust that they are non-malicious, we also trust that they won't clumsily package code without even skimming through it.

woodruffw 2y ago
The point was not about competency. I think typical distribution packagers are very competent. "They won't screw up" is the wrong way to look at security: humans always screw up. We're essentially fallible. We would all do well to remember that the xz backdoor was not caught by distribution code review: it was caught due to a performance side effect that the next adversary will be more careful to avoid. Software stacks are getting bigger, largely due to engineering pressures that are outside of the control of distributions. It's a basic fact that that means work for the same (or fewer) people, which in turn means less time spent on more complicated packages. Under those conditions, competency is not the deciding factor. This is, separately, why having lots of little packages can be (but isn't necessarily) a good thing: small packages that decompose into well-understood units of work can be reviewed more quickly and comprehensively, and can be assigned capabilities that can be tracked and audited with static analysis. You can't do that as easily (or at all) when every package decides to hand-roll its own subcomponents.
- PaulDavisThe1st 2y ago
  > "They won't screw up" is the wrong way to look at security: humans always screw up. We're essentially fallible. Sure. So pick a system that includes at least one extra possible barrier to them screwing up than the system that has none.
  - woodruffw 2y ago
    It’s not “either or.” It’s been decades since a “package the world” approach has been practical at human scales. (I think it’s great that distributions provide one extra set of eyes. But we’re deluding ourselves if we think that can scale to the actual realized demand for both new software and continuous change to software. It’s also not very fair to the distributions.)
akerl_ 2y ago
The average distro package maintainer is not reviewing the underlying code changes in packages to determine if they are malicious, nor is the average disto package maintainer qualified to spot intentionally obfuscated malicious code. The the average distro package maintainers is “person who cares that package repos stay up to date and is willing to commit their time to that work”
rad_gruchalski 2y ago
You are making a sweeping assumption that people who create container images are incompetent.

palata 2y ago

It's not only the packager. Some distros have an actual security team. That does not mean they audit everything, but it's vastly better than getting random code from PyPi.

rad_gruchalski 2y ago
Some companies providing container images also have security teams. Some companies providing pypi packages also have security teams. Your point is?
- palata 2y ago
  The point is that if you pull 100 dependencies from PyPi, you have absolutely no idea who you are trusting unless you put the effort to go check those 100 dependencies. If you link to dependencies that you get from Canonical, then you know that a security team is caring about the packages that Canonical distributes and actually patches them. Who patches security issues in PyPi? The individual package maintainers, which may well be pushing a malware leveraging typo-squatting. Typo-squatting is not really a thing in the Ubuntu package manager, is it? Not saying it's perfect. Just that it's better than the far west. PyPi is pretty much like downloading a .exe from a webpage without even opening the webpage (because back in the days, opening the webpage could sometimes - not always - tell you that it was clearly shady).
  - rad_gruchalski 2y ago
    All I hear is “here’s a business opportunity, go figure out if you can sell a python registry with libraries vetted by a security team”. Maybe there’s money in it. Canonical doesn’t do this as a good will. They make money on it, right? Who vets packages for fedora? alpine? arch?
    - croemer 2y ago
      Isn't that what Anaconda does? As opposed to say conda-forge? Anaconda tries hard to get orgs to pay money when they could just use conda-forge which has more packages, more up to date etc.