7 ms·

Are there any public package repos that do package signing well, or is this still an unsolved problem?

by kibwen 3y ago

taeric 3y ago
I'm tempted to give in to the claim that a problem that is fundamentally a liability concern, and therefore needs legal fallback, is unlikely to have a technical solution. Closest you can get is probably the Apple model?
udifuutdvbkx 3y ago
[flagged]
- woodruffw 3y ago
  Linux distributions that use PGP are effectively closed key ecosystems, meaning that their use of PGP is purely incidental: you trust the key material because they come from trusted sources or baked into your distribution, not because of any of the behavior that PGP supplies. PGP is strictly a liability in these contexts: it's more malleable and allows third-party signers to make mistakes that a reasonable codesigning scheme does not. In other words: each of these distributions could switch to bare signing keys tomorrow, and nothing would change (other than being able to delete a massive pile of insecure GPG code).
- Avamander 3y ago
  There's little that inspires confidence that what is used is not actually awful, there's plenty that shows how fragile and finicky PGP implementations are, thus how awful they are. Doing things the same way for two decades combined with not taking additional precautions (like transport crypto) puts a lot of weight on a single thing. That deserves all the possible scrutiny it possibly can get.
  - XorNot 3y ago
    Why would transport cryptography be in scope for package signing? It's literally an anti-feature, because any practical environment needs to MITM and inspect the incoming package stream to enforce policy, or provide caches. The abuse of HTTPS to "verify" content on the internet has been one of the biggest missteps.
    - Avamander 3y ago
      > Why would transport cryptography be in scope for package signing? It's not just package signatures that aren't encrypted. In addition to avoiding any MITM exploiting the implementation that verifies those signatures there are other parts most people don't want to reveal to a random MITM. > It's literally an anti-feature, because any practical environment needs to MITM and inspect the incoming package stream to enforce policy, or provide caches. It's not. Most users are not in an environment where this would be a positive aspect, rather than a potential way to deny a service or invade their privacy. This day and age we have better methods than leaving things just plaintext. Take a look at DNS for example.
      - XorNot 3y ago
        > Most users are not in an environment where this would be a positive aspect, rather than a potential way to deny a service or invade their privacy. I think you are wildly disconnected from "most users" if you think most users care about who knows what Linux packages they're downloading, or are at risk of having that ability removed based on MITM inspection of their HTTP traffic.
        Avamander 3y ago
        I think it's the exact opposite at play here. There are many countries with millions of people, thousands of Debian(-like) users that get MITMed constantly. There are a few organisations where such MITM is useful and someone provides caching. The cons heavily outweigh the risks but you're in a privileged situation.
ecliptik 3y ago
Debian packages, although they aren't signed but "use apt-secure (also known as secure apt) which is a tool that will allow a system administrator to test the integrity of the packages downloaded" [1]. 1. https://www.debian.org/doc/manuals/securing-debian-manual/deb-pack-sign.en.html https://www.debian.org/doc/manuals/securing-debian-manual/de...
exabrial 3y ago
I think Maven does PGP fairly well. It's not perfect, but enh. Sonatype are the community stewards. They make sure you have control over and email address and a packaging namespace. PGP is nice because it _requires_ an email address tied to a cert. They _require_ signatures for _every_ artifact uploaded. The maven repository manager makes your release transactional. Either all of your artifacts are signed and the signatures match, or none of the artifacts are published. Your release is rejected if you fail to pass the test. After the checks, you are given the option to publish the transaction or not. There is no undo button, as it should be. I also reported a bug/security issue to Sonatype and they fixed it within a few weeks. There is room for improvement: I think they could get stricter and require the signing keys be listed in the pom or whatever build file you use. Maven does some signature checking, but it oddly enough doesn't do pgp verification. Given that 100% of signatures are checked on upload, it technically is redundant since nearly everything is TLS these days. I think Sonatype should publish a transparency keymap. This would probably be an actual good real-world use case for a blockchain too. KeyId -> Artifact Namespace controlled.
- zokier 3y ago
  Does Maven Central check that the GPG key used matches anything? Or can you just use whatever random key to sign your packages?
  - exabrial 3y ago
    Yes. See their requirements. No. You have to use the same approved key that’s associated with the artifact namespace.
    - zokier 3y ago
      I was checking their requirements pages and I didn't see any mention how the keys are associated with anything, that is why I was asking https://central.sonatype.org/publish/requirements/#sign-files-with-gpgpgp https://central.sonatype.org/publish/requirements/#sign-file... https://central.sonatype.org/publish/requirements/gpg/ https://central.sonatype.org/publish/requirements/gpg/ It only says: > These identifiers are essential as they will be seen by anyone downloading a software artifact and validating a signature but nothing about associating the keys with account or anything.
zokier 3y ago
NuGet (the .net package manager) maybe?

Are there any public package repos that do package signing well, or is this still an unsolved problem?

by kibwen 3y ago

Are there any public package repos that do package signing well, or is this still an unsolved problem?

I'm tempted to give in to the claim that a problem that is fundamentally a liability concern, and therefore needs legal fallback, is unlikely to have a technical solution. Closest you can get is probably the Apple model?

udifuutdvbkx 3y ago

[flagged]

woodruffw 3y ago
Linux distributions that use PGP are effectively closed key ecosystems, meaning that their use of PGP is purely incidental: you trust the key material because they come from trusted sources or baked into your distribution, not because of any of the behavior that PGP supplies. PGP is strictly a liability in these contexts: it's more malleable and allows third-party signers to make mistakes that a reasonable codesigning scheme does not. In other words: each of these distributions could switch to bare signing keys tomorrow, and nothing would change (other than being able to delete a massive pile of insecure GPG code).
Avamander 3y ago
There's little that inspires confidence that what is used is not actually awful, there's plenty that shows how fragile and finicky PGP implementations are, thus how awful they are. Doing things the same way for two decades combined with not taking additional precautions (like transport crypto) puts a lot of weight on a single thing. That deserves all the possible scrutiny it possibly can get.
- XorNot 3y ago
  Why would transport cryptography be in scope for package signing? It's literally an anti-feature, because any practical environment needs to MITM and inspect the incoming package stream to enforce policy, or provide caches. The abuse of HTTPS to "verify" content on the internet has been one of the biggest missteps.
  - Avamander 3y ago
    > Why would transport cryptography be in scope for package signing? It's not just package signatures that aren't encrypted. In addition to avoiding any MITM exploiting the implementation that verifies those signatures there are other parts most people don't want to reveal to a random MITM. > It's literally an anti-feature, because any practical environment needs to MITM and inspect the incoming package stream to enforce policy, or provide caches. It's not. Most users are not in an environment where this would be a positive aspect, rather than a potential way to deny a service or invade their privacy. This day and age we have better methods than leaving things just plaintext. Take a look at DNS for example.
    - XorNot 3y ago
      > Most users are not in an environment where this would be a positive aspect, rather than a potential way to deny a service or invade their privacy. I think you are wildly disconnected from "most users" if you think most users care about who knows what Linux packages they're downloading, or are at risk of having that ability removed based on MITM inspection of their HTTP traffic.
      - Avamander 3y ago
        I think it's the exact opposite at play here. There are many countries with millions of people, thousands of Debian(-like) users that get MITMed constantly. There are a few organisations where such MITM is useful and someone provides caching. The cons heavily outweigh the risks but you're in a privileged situation.

ecliptik 3y ago

Debian packages, although they aren't signed but "use apt-secure (also known as secure apt) which is a tool that will allow a system administrator to test the integrity of the packages downloaded" [1]. 1. https://www.debian.org/doc/manuals/securing-debian-manual/deb-pack-sign.en.html https://www.debian.org/doc/manuals/securing-debian-manual/de...

exabrial 3y ago

I think Maven does PGP fairly well. It's not perfect, but enh. Sonatype are the community stewards. They make sure you have control over and email address and a packaging namespace. PGP is nice because it _requires_ an email address tied to a cert. They _require_ signatures for _every_ artifact uploaded. The maven repository manager makes your release transactional. Either all of your artifacts are signed and the signatures match, or none of the artifacts are published. Your release is rejected if you fail to pass the test. After the checks, you are given the option to publish the transaction or not. There is no undo button, as it should be. I also reported a bug/security issue to Sonatype and they fixed it within a few weeks. There is room for improvement: I think they could get stricter and require the signing keys be listed in the pom or whatever build file you use. Maven does some signature checking, but it oddly enough doesn't do pgp verification. Given that 100% of signatures are checked on upload, it technically is redundant since nearly everything is TLS these days. I think Sonatype should publish a transparency keymap. This would probably be an actual good real-world use case for a blockchain too. KeyId -> Artifact Namespace controlled.

zokier 3y ago
Does Maven Central check that the GPG key used matches anything? Or can you just use whatever random key to sign your packages?
- exabrial 3y ago
  Yes. See their requirements. No. You have to use the same approved key that’s associated with the artifact namespace.
  - zokier 3y ago
    I was checking their requirements pages and I didn't see any mention how the keys are associated with anything, that is why I was asking https://central.sonatype.org/publish/requirements/#sign-files-with-gpgpgp https://central.sonatype.org/publish/requirements/#sign-file... https://central.sonatype.org/publish/requirements/gpg/ https://central.sonatype.org/publish/requirements/gpg/ It only says: > These identifiers are essential as they will be seen by anyone downloading a software artifact and validating a signature but nothing about associating the keys with account or anything.

zokier 3y ago

NuGet (the .net package manager) maybe?