Support dist packages?

[mpdude]

I understand the decision to support only source packages in the first version of this plugin, because the necessary validation comes built into git.

It is, however, a limitation that might prevent people from using this plugin.

So, what would be needed to support dist as well, and can we get there without changes to Composer and/or Packagist?

Obviously, we need to figure out where to obtain GPG signatures for the individual packages, matching the versions installed.

Would it make sense from the security point of view if packages could put into their composer.json some extra metadata to point to an URL where the signature can be found? Maybe we could support simple placeholders in these URLs for the version number assigned to a package.

I haven’t yet checked if such extra data would easily be available for a plug-in. If all else fails, we could first download and unzip dist archives and then peek into composer.json ourselves.

Once we have the signature, use it to verify the ZIP (which has already been unpacked) and bail out if validation fails.

Too naive?

[Ocramius]

It's not a question of doing it or not: it is simply not feasible. Uunless a signature (checksum+GPG signature) is exported with the published package, we can't do much about it. The current repo is focusing about using `--prefer-source` (more than sufficient for current purposes), and should focus on improving support there, before doing anything fancier: right now, this tool is barely usable (if at all), and should be improved to a level where more people can start adopting it with `--prefer-source` (the tool can enforce it). After that is achieved (if ever), it is possible to think about "nice to have" features. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

…

On Sun, Dec 29, 2019 at 10:02 PM Matthias Pigulla ***@***.***> wrote: I understand the decision to support only source packages in the first version of this package, because the necessary validation comes built into git. It is, however, a limitation that might prevent people from using this plugin. So, what would be needed to support dist as well, and can we get there without changes to Composer and/or Packagist? Obviously, we need to figure out where to obtain GPG signatures for the individual packages, matching the versions installed. Would it make sense from the security point of view if packages could put into their composer.json some extra metadata to point to an URL where the signature can be found? Maybe we could support simple placeholders in these URLs for the version number assigned to a package. I haven’t yet checked if such extra data would easily be available for a plug-in. If all else fails, we could first download and unzip dist archives and then peek into composer.json ourselves. Once we have the signature, use it to verify the ZIP (which has already been unpacked) and bail out if validation fails. Too naive? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=AABFVECEJGKK623T3NV6ZVLQ3EF7VA5CNFSM4KBCOE6KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IDGGBTA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFVEBUTL4GAJJZ7IE27QLQ3EF7VANCNFSM4KBCOE6A> .

[mpdude]

I do understand your priorities.

It's not a question of doing it or not: it is simply not feasible. Uunless a signature (checksum+GPG signature) is exported with the published package, we can't do much about it.

Obviously the signature cannot be part of the package itself. But wouldn’t an URL as part of package metadata work? That would leave it to package authors how to distribute “their” signatures. They could, for example, attach them to GitHub releases.

[Ocramius]

Yeah, unlikely gonna be able to request that from package authors without full buy-in right now

…

On Sun, Dec 29, 2019, 22:45 Matthias Pigulla ***@***.***> wrote: I do understand your priorities. It's not a question of doing it or not: it is simply not feasible. Uunless a signature (checksum+GPG signature) is exported with the published package, we can't do much about it. Obviously the signature cannot be part of the package itself. But wouldn’t an URL as part of package metadata work? That would leave it to package authors how to distribute “their” signatures. They could, for example, attach them to GitHub releases. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=AABFVEGJLQNXC65LTG4EZLLQ3ELBLA5CNFSM4KBCOE6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHZJAGY#issuecomment-569544731>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFVEBQFVH7DHYZXHNIGHDQ3ELBLANCNFSM4KBCOE6A> .

[mpdude]

What if... we could convince GitHub to provide checksums and signatures at known (inferrable) locations with a dedicated key under their control exactly and only for those releases that they have verified to be signed by one of the repo maintainers?

Like with Symfony, releases are GPG-signed by Fabien and GitHub shows that info. If I'd trust that dedicated GH key, I could verify all dist ZIPs for Fabien's releases, without further work required for him. 🤔

People would not have to create dedicated releases and/or attach signature files. Only GPG sign their tags and make sure GH knows their key.

[Ocramius]

You cannot really sign the checksum without the key

…

On Mon, Dec 30, 2019, 12:11 Matthias Pigulla ***@***.***> wrote: What if... we could convince GitHub to provide checksums and signatures at known (inferrable) locations with a dedicated key under *their* control exactly and only for those releases that *they* have verified to be signed by one of the repo maintainers? Like with Symfony, releases are GPG-signed by Fabien and GitHub shows that info. If I'd trust that dedicated GH key, I could verify all dist ZIPs for Fabien's releases, without further work required for him. 🤔 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=AABFVEGPTUJ7LWFAUPBNDITQ3HJMTA5CNFSM4KBCOE6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH2CNYA#issuecomment-569648864>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFVEGK4HOZHT72M7X63ODQ3HJMTANCNFSM4KBCOE6A> .

[mpdude]

Hm, maybe my explanation was not clear or I don't get you...

GH creates/provides ZIPs/tar.gzs for tagged commits. They can also check if those tags have been signed by someone with access to the repo.

Now they could have a key that belongs to them (they created it) to sign that the ZIP file is "authentic" (was created by them) and is based on a signed tag that they have verified... does that make sense?

[Ocramius]

That doesn't really mean anything, since GitHub is a platform, and the original signature is not being checked anymore.

You have to do e2e authentication, GitHub is still a middle-man

[staabm]

But still it would cover a lot (And it could work for most packages as a huge margin is hosted on github).. not perfect but way better than anything we have atm...?

[mpdude]

Could go wrong if Mallory breaks into Alice's GitHub account, registers his GPG key with it, uses it to sign a malicious commit and publishes a release. Nobody could tell by looking at the ZIP signature issued by GitHub.

[staabm]

Same thing when mallory steals the private key of alice and signs releases with it (github accounts at least can have 2fa-auth)

[Ocramius]

The idea of e2e authentication and the trust chain is that the key can then be revoked.

What must be clear (before discussing further) is that GitHub is only a relay of the sources: it doesn't have any authentication that we can rely upon. Authentication comes from the source of the code. It is not possible to trust a signature made by GitHub on top of a released package if that package doesn't serve its own (author's) signature too.

[Ocramius]

Closing here meanwhile: this is not feasible with current tech, and would require the tool to be much more popular and ergonomic (with --prefer-source) before being proposed again. Refer to composer/composer#4022 (comment), where @paragonie-security has described this in much more detail.

[mpdude]

Just to put another idea on record: If we need an easily-available channel for package signatures to be distributed, maybe a signatures file (or .signatures directory) at the root of the master branch might do. That's not available per se if we download a dist archive for, let's say, some maintenance or release branch. But Packagist might find it and provide the URL/an endpoint to access the signature. Also, raw.githubusercontent.com might do the trick.

The point is that we need to find a way to teach people to acutally do the signing, take really good care of their keys and get the rest of the hassle out of the way. IMO, composer is so successful also because