Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Support Cryptographic Signatures with Public Key Pinning #4022

Open
sarciszewski opened this issue May 12, 2015 · 21 comments

Comments

@sarciszewski
Copy link

commented May 12, 2015

Please read these first

The purpose of this Github issue is to propose a movement towards enabling package maintainers to publish their own OpenSSL signatures via Composer, should they want to.

New optional property for composer.json

I'd like to propose a new composer.json property called "security". It will have the following properties:

  • contact which could contain an array of contact information options for reporting security vulnerabilities
  • publisher should contain an array of authorized publishers and the SHA-256 fingerprints of their public keys (e.g. openssl)

Example

{
    "name": "some_author/myproject",
    "security": {
        "contact": [
              {
                   "email": "security@example.com",
                   "pgpkey": "89F7B8300E87E03C52B05289926BC5171CDEA439",
              }
        ],
        "publishers": [
            {
                "name": "our_publishing_key",
                "public_keys": [
                    {
                        "key": "someRSApublickeyhere",
                        "sha256": "i4a+yBCeboJ2W4kYSQ1DoxUEK00OUpQ0dE6lw1K5XUk=",
                        "sha1": "XijzBWQ2WjqfEprXBu6TRkCUolI="
                    },
                    {
                        "key": "someOtherRSAPublickeyhere",
                        "sha256": "hCTafmUcyOYtvhO4ENY/U5v1pTK1iq+5YHtRnfiGpAk=",
                        "sha1": "xVY8xokHfHi1GSpm8fugZJsLInw="
                    }
                ]
            }
        ]
    }
}

How it should be used

When a package opts to specify their own public keys, Composer should be able to verify signatures on the client's side. Packagist may also benefit from tracking which projects offer digital signatures.

This idea is just a draft. I'd like to know what the Composer team and PHP community wants before I even think about writing a pull request.

@indeyets

This comment has been minimized.

Copy link

commented May 17, 2015

👍

@padraic

This comment has been minimized.

Copy link
Contributor

commented May 17, 2015

@sarciszewski I did some prototyping in this area a while back. While it's likely not aged well against the Composer public API, you can view the new classes and commands.

Branch: https://github.com/padraic/composer/tree/developer-signatures
Compare: master...padraic:developer-signatures

It uses a model where the signing keys are authorised using one or more offline root keys, i.e. allowing a lead to delegate signing to other maintainers or sets of online keys. Tracked in a keys.json file. The signature is made against a manifest of files.

Two tricky parts...

  1. Files included on the manifest need to be standardised. This was problematic at the time using Composer archive classes mixed with git. Composer does have a specific set of classes for this already which I was reusing, but they were in flux at the time.
  2. JSON data being JSON, it needs to canonicalised reliably across clients but has no native capacity for this. I was using the very simple Bencode which was the actual data form being signed.

Maybe this will all offer some inspiration or food for discussion and, by all means, borrow and steal as needed.

@alcohol alcohol added the Feature label Jul 25, 2015

@alcohol

This comment has been minimized.

Copy link
Member

commented Aug 19, 2015

This might also be related to #38, and to a lesser degree, #1074.

@paragonie-scott

This comment has been minimized.

Copy link

commented Jan 30, 2016

@padraic Since your branch is mostly additions, it shouldn't be too much work to rebase against upstream/master.

@Seldaek Seldaek added this to the Later milestone Apr 18, 2016

blackcoder87 referenced this issue in IlchCMS/Ilch-2.0 Aug 18, 2016

integrate composer and use composer autoloader, remove files of libra…
…ries loaded with composer, PHP -> 5.5 (already used in many files)
@rugk

This comment has been minimized.

Copy link

commented Oct 17, 2016

Any news here? I think adding support for verifying the downloaded files cryptographically would be a nice thing.
In this case there just remains one question: How is composer.json verified?

@alcohol

This comment has been minimized.

Copy link
Member

commented Oct 18, 2016

@rugk It is not. Everything we do is totally insecure and will explode in our faces any day now. Any day now...

On a serious note though; security is nice and all that, but if it detracts from usability and ease of access, it could end up causing users to turn away from their tooling instead. No users, no need for the tool. No need for the tool, no security needed.

I wonder if some form of security could be obtained through a Composer plugin, thereby making it completely optional. Also, not yet-another-feature we would have to maintain.

@paragonie-scott

This comment has been minimized.

Copy link

commented Oct 18, 2016

I wonder if some form of security could be obtained through a Composer plugin, thereby making it completely optional. Also, not yet-another-feature we would have to maintain.

Unless it was an enabled-by-default plugin, most people would never use such a feature.

Regardless, doing it right is a nontrivial problem and I'd be skeptical of any implementations before libsodium becomes a core extension and PHP < 7.2 (or whenever libsodium's adoption arrives) is widely EOL'd.

@alcohol

This comment has been minimized.

Copy link
Member

commented Oct 18, 2016

@paragonie-scott every plugin is enabled by default, if you install it.

@paragonie-scott

This comment has been minimized.

Copy link

commented Oct 18, 2016

But it's not installed by default. :)

@andrewhowdencom

This comment has been minimized.

Copy link

commented Nov 17, 2016

Looking to establish a chain of verification for our software supply, for which this is a requirement. If anyone is keen on working on this, I promise you it'll be appreciated!

@rugk

This comment has been minimized.

Copy link

commented Nov 17, 2016

Maybe we could first get rid of the "low-prio/controversial" milestone? 😃

Security should never be "low-prio"…

@alcohol

This comment has been minimized.

Copy link
Member

commented Nov 17, 2016

@rugk Unfortunately, we (@composer team) have only limited experience in regards to security as far as this topic goes. Hence, it is low priority for us personally. We are open to discussions and contributions (discuss before contributing please) though!

@dzuelke

This comment has been minimized.

Copy link
Contributor

commented Nov 17, 2016

The problem is not the implementation, the problem is the key/signing infrastructure...

@alcohol

This comment has been minimized.

Copy link
Member

commented Nov 17, 2016

Isn't that part of the implementation? :p

@paragonie-scott

This comment has been minimized.

Copy link

commented Nov 17, 2016

You could implement this in an hour with openssl_sign() and openssl_verify(). The problem is: which public key to trust, how to verify these weren't silently replaced, etc.

@andrewhowdencom

This comment has been minimized.

Copy link

commented Nov 17, 2016

@sarciszewski Perhaps this is a naive question, but can you do that out of band? Perhaps store "trusted" public keys in local composer configuration on the machine, or something.

Edit: I'd even consider just keeping the trusted public keys in composer.json, if that were some how possible and not insane.

Edit: This seems be the idea of the original author. I should read closer.

(My experience is also limited! I only know the concepts.)

@andrewhowdencom

This comment has been minimized.

Copy link

commented Jan 16, 2017

Similar work being carried out on Wordpress. https://ma.ttias.be/wordpress-get-secure-cryptographic-updates/

@Ocramius

This comment has been minimized.

Copy link
Contributor

commented May 20, 2017

For those tracking this, I started a brutally simple implementation at https://github.com/Roave/composer-gpg-verify, which relies on the GPG keyring and the fact that packages are downloaded with GIT (which includes signing/verification mechanisms out of the box).

It's still a bit raw, but the idea is to first make it work reliably, then move it to composer once it's "ready for everyone".

@ericmann ericmann referenced this issue Mar 6, 2018
@robolmos

This comment has been minimized.

Copy link

commented Feb 24, 2019

Bump for 2019

@Ocramius

This comment has been minimized.

Copy link
Contributor

commented Feb 24, 2019

@robolmos bumping on OSS is basically asking for being scolded.

Please take the above suggestions and get involved yourself in first place instead.

@DiveRightIn

This comment has been minimized.

Copy link

commented Feb 25, 2019

@Ocramius @robolmos Take it offline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.