8 ms·

Things like diango don't really seem like they would target typos as much as malicious copy and paste targets.

Latteland 8y ago
The whole world of package maintenance is subject to this, from pip to c# packages, npm, everything. I'm sure we all (developers) have some of these on our systems, because you rely on downloading packages to use that depend on other things. It makes me want to do development in a dummy account, and my 'personal account' with my passwords and ssh credentials is somehow a separate account. I never do that in practice because it would be too much pain. That's why these kinds of package attacks are valuable. So what can we do to address this? This story exactly lines up with my long time worry. I could be careful or lucky and avoid things like this, but the packages I use might not be so careful or lucky.
- blattimwind 8y ago
  > So what can we do to address this? We use a a web of trust and sign releases using our well-known WoTted keys using GPG. Getting hacked every few years is less painful, though. (Actually Debian does this to some extent by asking upstreams for signed releases using a designated key, so this can be made to work)
  - Latteland 8y ago
    Thats a good start but what would have prevented the owner of "dujangoo" from siging their package? Nothing.
    - toyg 8y ago
      The key would appear untrusted, though. Which, admittedly, is not much of a defense: most developers would just assume it’s a new key and trust it blindly. Still, it would be an additional data point, and possibly another chance to spot the typo (if the UI repeats it).
    - jnbiche 8y ago
      That's why you check the signature to make sure it's the right one. It's almost always listed on the developer's web site, plus you can often google the signature to see if it's one other people are using as well.
- ris 8y ago
  > The whole world of package maintenance is subject to this Wrong. There are two types of package repository, "maintained" and what I call "wild west". The latter include pypi, npm, homebrew, dockerhub, and any other repos where any old joe can sign up and start uploading packages under some name they choose. Uploaded packages are controlled by the single entity in charge of the account, except in rare circumstances like this when the site owners were alerted to specific mischief. "Maintained" repositories have a layer of "maintainers" between the developers and the users. Their responsibility is to shield the user from irresponsible, user-hostile or potentially malicious decisions the developers may (and surprisingly often do) make. These include most Linux distribution repositories but also others like Nix and Guix. They tend to have fewer packages because of the added work of performing the maintenance and tend to lag behind release versions for the same reason but also because of an inherent conservatism of the maintainers. In return users get greatly improved stability. In the best cases (e.g. debian) the maintainers even do backports of security fixes to older stable releases. The maintainers also make decisions in a more public consensus basis and are better able to coordinate releases between different packages to ensure compatibility. Given the choice, I run a mile from the former style of repository.
  - Latteland 8y ago
    My last 3 jobs used pip and npm, they are ubiquitous. My current job makes infrastructure and uses both those too. Sure, we use officially maintained Ubuntu repos but it's incredibly common to use npm or whatever in combination with the safe package systems.
    - ris 8y ago
      I'm not saying it's not common, but so is herpes.
  - donaldstufft 8y ago
    Honestly, this is kind of FUDish and assumes the worst case scenario for upstream developers, and the best case scenario for the distro maintainers. Another way of phrasing what this extra layer of maintainers provides, is a second group of people who can introduce their own irresponsible, user-hostile, and potentially malicious (or at the very least, negligent) decisions. Worse, often times these developers have less (in some cases, far less) knowledge of how the code itself works, and are applying their own patches, often with minimal testing, without fully understanding the scope or impact of the changes they're making. For every poor decision you can find in a package that is popular enough to even appear in one of these downstream repositories, one could just as easily find a case where this extra layer is introducing their own problems. The non FUD-ish answer is that whether you get your software directly from the upstream developers through an uncurated repository like PyPI, or through a curated repository like a Linux repository neither one is inherently better than the other. Each of them has a variety of pros and cons and part modern day engineering is looking at these tradeoffs and choosing the right set for your particular situation. Sometimes that will even mean that you're choosing different tradeoffs for different packages on the same system.

The whole world of package maintenance is subject to this, from pip to c# packages, npm, everything. I'm sure we all (developers) have some of these on our systems, because you rely on downloading packages to use that depend on other things. It makes me want to do development in a dummy account, and my 'personal account' with my passwords and ssh credentials is somehow a separate account. I never do that in practice because it would be too much pain. That's why these kinds of package attacks are valuable. So what can we do to address this? This story exactly lines up with my long time worry. I could be careful or lucky and avoid things like this, but the packages I use might not be so careful or lucky.

blattimwind 8y ago
> So what can we do to address this? We use a a web of trust and sign releases using our well-known WoTted keys using GPG. Getting hacked every few years is less painful, though. (Actually Debian does this to some extent by asking upstreams for signed releases using a designated key, so this can be made to work)
- Latteland 8y ago
  Thats a good start but what would have prevented the owner of "dujangoo" from siging their package? Nothing.
  - toyg 8y ago
    The key would appear untrusted, though. Which, admittedly, is not much of a defense: most developers would just assume it’s a new key and trust it blindly. Still, it would be an additional data point, and possibly another chance to spot the typo (if the UI repeats it).
  - jnbiche 8y ago
    That's why you check the signature to make sure it's the right one. It's almost always listed on the developer's web site, plus you can often google the signature to see if it's one other people are using as well.
ris 8y ago
> The whole world of package maintenance is subject to this Wrong. There are two types of package repository, "maintained" and what I call "wild west". The latter include pypi, npm, homebrew, dockerhub, and any other repos where any old joe can sign up and start uploading packages under some name they choose. Uploaded packages are controlled by the single entity in charge of the account, except in rare circumstances like this when the site owners were alerted to specific mischief. "Maintained" repositories have a layer of "maintainers" between the developers and the users. Their responsibility is to shield the user from irresponsible, user-hostile or potentially malicious decisions the developers may (and surprisingly often do) make. These include most Linux distribution repositories but also others like Nix and Guix. They tend to have fewer packages because of the added work of performing the maintenance and tend to lag behind release versions for the same reason but also because of an inherent conservatism of the maintainers. In return users get greatly improved stability. In the best cases (e.g. debian) the maintainers even do backports of security fixes to older stable releases. The maintainers also make decisions in a more public consensus basis and are better able to coordinate releases between different packages to ensure compatibility. Given the choice, I run a mile from the former style of repository.
- Latteland 8y ago
  My last 3 jobs used pip and npm, they are ubiquitous. My current job makes infrastructure and uses both those too. Sure, we use officially maintained Ubuntu repos but it's incredibly common to use npm or whatever in combination with the safe package systems.
  - ris 8y ago
    I'm not saying it's not common, but so is herpes.
- donaldstufft 8y ago
  Honestly, this is kind of FUDish and assumes the worst case scenario for upstream developers, and the best case scenario for the distro maintainers. Another way of phrasing what this extra layer of maintainers provides, is a second group of people who can introduce their own irresponsible, user-hostile, and potentially malicious (or at the very least, negligent) decisions. Worse, often times these developers have less (in some cases, far less) knowledge of how the code itself works, and are applying their own patches, often with minimal testing, without fully understanding the scope or impact of the changes they're making. For every poor decision you can find in a package that is popular enough to even appear in one of these downstream repositories, one could just as easily find a case where this extra layer is introducing their own problems. The non FUD-ish answer is that whether you get your software directly from the upstream developers through an uncurated repository like PyPI, or through a curated repository like a Linux repository neither one is inherently better than the other. Each of them has a variety of pros and cons and part modern day engineering is looking at these tradeoffs and choosing the right set for your particular situation. Sometimes that will even mean that you're choosing different tradeoffs for different packages on the same system.