3 ms·

How would package signing have prevented this?

by janosdebugs 4y ago

eternauta3k 4y ago
Signing + web of trust might hinder this.
- zachlatta 4y ago
  I don’t think it’s realistic to expect people to maintain a web of trust.
  - shadowgovt 4y ago
    Oh, it never has been; huge pain in the ass. ... we do it anyway because the alternative is to just get 0wnz3d by bad actors.
    - salawat 4y ago
      ^...The most insightful comment of the day, right here.
- shadowgovt 4y ago
  The signatures would have to be rooted to a trust cert model (with a way for devs to verify that the "Microsoft" they're pulling a package from is the real "Microsoft"). Hypothetically, this could be done: put up a public key at a known domain, sign packages via public key, and if the package manager extends to include a "fetch from URL provided by the package and check signature" tool, we end up rooting trust in packages in trust in domain name ownership; not too shabby. We still need devs to actually bother to do the check and, like, read the domain name to make sure they haven't accepted authorization from "micr0soft.com", but the end result is a distributed signing solution that doesn't require any centralized authority (except, indirectly, the SSL cert issuers and DNS providers of the world).
  - bombolo 4y ago
    No there would not necessarily be a need for this. You could have alerts when an old account is using a new key that nobody has seen before, for example.
remram 4y ago
If you don't know the author, signatures do nothing. Anybody can sign their package with some key. Even if you could check the author's identity, that still does very little for you, unless you know them personally. It makes a lot more sense to use cryptography to verify that releases are not malicious directly. Tools like crev [1], vouch [2], and cargo-vet [3] allow you to trust your colleagues or specific people to review packages before you install them. That way you don't have to trust their authors or package repositories at all. That seems like a much more viable path forward than expecting package repositories to audit packages or trying to assign trust onto random developers. [1]: https://github.com/crev-dev/crev https://github.com/crev-dev/crev [2]: https://github.com/vouch-dev/vouch https://github.com/vouch-dev/vouch [3]: https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet
- salawat 4y ago
  You have now just transferred risk. You have done nothing to mitigate it, and created more work for those of us that actually do read code. Then again, if someone wants to pay me to do nothing but read and vouchsafe code, hell, why not. As QA I basically do that anyway. Will have to think on this.
  - remram 4y ago
    I don't see it as "transferred risk". As individuals we already have people we trust and people we don't know. This system allows you to get trust in your dependencies without requiring to trust the specific rando that authored the specific library you want to use. Yes ultimately someone you trust has to vouch for the library for you to trust it. That's unavoidable either way. Those systems only allow for that person to be anyone instead of just the author.
- loic-sharma 4y ago
  The .NET ecosystem has this [1], so far adoption has been low. Similar to HTTPS until LetsEncrypt, we need something that’s more convenient if we want developer adoption. [1]: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-trust#description https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-n...

How would package signing have prevented this?

eternauta3k 4y ago

Signing + web of trust might hinder this.

zachlatta 4y ago
I don’t think it’s realistic to expect people to maintain a web of trust.
- shadowgovt 4y ago
  Oh, it never has been; huge pain in the ass. ... we do it anyway because the alternative is to just get 0wnz3d by bad actors.
  - salawat 4y ago
    ^...The most insightful comment of the day, right here.
shadowgovt 4y ago
The signatures would have to be rooted to a trust cert model (with a way for devs to verify that the "Microsoft" they're pulling a package from is the real "Microsoft"). Hypothetically, this could be done: put up a public key at a known domain, sign packages via public key, and if the package manager extends to include a "fetch from URL provided by the package and check signature" tool, we end up rooting trust in packages in trust in domain name ownership; not too shabby. We still need devs to actually bother to do the check and, like, read the domain name to make sure they haven't accepted authorization from "micr0soft.com", but the end result is a distributed signing solution that doesn't require any centralized authority (except, indirectly, the SSL cert issuers and DNS providers of the world).
- bombolo 4y ago
  No there would not necessarily be a need for this. You could have alerts when an old account is using a new key that nobody has seen before, for example.

remram 4y ago

If you don't know the author, signatures do nothing. Anybody can sign their package with some key. Even if you could check the author's identity, that still does very little for you, unless you know them personally. It makes a lot more sense to use cryptography to verify that releases are not malicious directly. Tools like crev [1], vouch [2], and cargo-vet [3] allow you to trust your colleagues or specific people to review packages before you install them. That way you don't have to trust their authors or package repositories at all. That seems like a much more viable path forward than expecting package repositories to audit packages or trying to assign trust onto random developers. [1]: https://github.com/crev-dev/crev https://github.com/crev-dev/crev [2]: https://github.com/vouch-dev/vouch https://github.com/vouch-dev/vouch [3]: https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet

salawat 4y ago
You have now just transferred risk. You have done nothing to mitigate it, and created more work for those of us that actually do read code. Then again, if someone wants to pay me to do nothing but read and vouchsafe code, hell, why not. As QA I basically do that anyway. Will have to think on this.
- remram 4y ago
  I don't see it as "transferred risk". As individuals we already have people we trust and people we don't know. This system allows you to get trust in your dependencies without requiring to trust the specific rando that authored the specific library you want to use. Yes ultimately someone you trust has to vouch for the library for you to trust it. That's unavoidable either way. Those systems only allow for that person to be anyone instead of just the author.
loic-sharma 4y ago
The .NET ecosystem has this [1], so far adoption has been low. Similar to HTTPS until LetsEncrypt, we need something that’s more convenient if we want developer adoption. [1]: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-trust#description https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-n...