Conan: Package signing

[memsharded]

Blog post by @sztomi, also @tru seems to agree, that package signing should be useful. Probably @annulen might be interested in this feature too:

Feedback please:

• PGP signatures
• SSH Key signatures
• Conan RSA signatures
• ?

Please, something that:

• Is easily portable (seems that python pycrypto package can do quite a few things) between ALL major OS systems.
• Is easy to integrate and redistribute with all current conan installers.

Any other feedback welcome

This feature might be risky, let's put in for 0.18, but might drop for the milestone if too much trouble

[sztomi]

Cool, thanks for mentioning me. I agree that it's a risky feature, because it's hard to get it right. From the top of my I head I can only remember Arch Linux that had a package manager that added signing after the fact. Maybe the pacman devs could have some valuable input on the topic.

[opilar]

I'm voting for PGP. Even git has commit signing support.

[kent-at-multiscale]

Maven uses PGP signatures on packages.

https://maven.apache.org/guides/mini/guide-central-repository-upload.html

[memsharded]

Ok, PGP indeed is the reference one, just wanted to check to be sure. Thanks for the feedback!

[maddanio]

ok, so from #480 it seems the concensus (?) is to put this in as a plugin based on the in-development infrastructure for that. Is there an issue for that infrastructure so we can track that?

[maddanio]

or is there a branch/docs for that so one can start prototyping a plugin?

[maddanio]

since we are currently considering to temporarily hack this into a fork of conan with as little effort as possible I began digging through the source. it seems like the server does not really check the files that are uploaded, is that correct? i.e. i could just hack the client to also upload a signature file, and also on the other end to download one as well, and the server would not really have to know about it?

[maddanio]

from some more digging it seems it would also be downloaded automatically...

[maddanio]

so all that there would be to do is

• generate the signature after compressing and add it to the list of files to be uploaded
• after downloading check the downloaded signature in the package (if any)
  or am i missing something?

[earonesty]

The cleanest solution is to a) sign the manifest itself (not the zip... faster and gives you the same protection as long as the manifest is verified too), and then b) add the sig to a "conansignature.txt" file that is part of the zip file.

An environment variable like "CONAN_SIGNING_CERT" can be set to the path of a certificate file, just like "CONAN_UPLOAD" and other vars. Users can choose whether this file is password (or otherwise) protected... making uploading a manual, but more secure process.

Verification should include both a) verifying the signature (easy) and b) validating the certificate used to sign it (harder). Here's some code for signature validation https://github.com/ronf/asyncssh/blob/master/asyncssh/crypto/x509.py ... it combines pyca/crypto into a proper "validate()" function.... which would be needed if we wanted to support normal certificate chains, root-ca's, revocation, etc. Seems to work with the OS's normal cert chain.

Is this something that the plugin architecture could support? If someone familiar with that can provide me a hint on how it would work, I wouldn't mind taking a crack at building a code signing and verification plugin. IE: Can a plugin introduce a new file that exists outside of the manifest.

[maddanio]

any interest in this? imho its not only about providing a way to sign packages, but also to make signing a default feature, so that it actually gets adopted across the eco system. our dev-ops team, somewhat rightfully, is very concerned with installing unsigned packages. or are they alone in that? after all there is a lot of trust one has to put in these packages if they end up making up a big part of the shipped product...

[tru]

It's not a problem for us anymore - since we have taken control over our packages - we don't sign and install them from other sources than our in-house artifactory installation. We communicate with the artifactory install over HTTPS - I think that maybe what you can do to improve this a bit is to allow certificate pinning in the conan http client. So you can make sure you are getting packages from the correct source. Depends a lot on your use case.

Using the public conan repo is a whole other ball-of-wax - but if you have critical stuff running with conan I would imagine that you would never trust upstream binaries anyway.

[maddanio]

so the solution is then to build all packages on an in-house ci?

[tru]

if you have strict security concerns - then yes - why would you trust that to a third-party, signature or not?

[maddanio]

Well, people trust their os repos, right?

[memsharded]

This is an interesting discussion, that could indeed be extended to all other package managers. My opinion is that you can never 100% fully trust public repos. They are the target of different types of attacks, and they have been compromised in the past. As always it is a trade-off, it depends what your application is, your constraints of development and release, where you are going to run...

I still fail to see how package signing solves the problem, it might slightly alleviate it, but if I am a malicious user, I can still create some malicious package, put the public key in http://pgp.mit.edu, or equivalent, and publish my malicious package. All that can be verified is that such a package has been signed from that user with that PGP, and that it won't be easy to tamper with it, but not that it won't damage your system. The only way is to explicitly and manually verify the signatures of those package creators, audit their identity, and decide if they are trusted or not. It might be not only easier to fork recipes and build your own binaries, but also more robust in the sense that if it is necessary to do any change/customization to the packages, the system is already in place.

[tru]

Well, people trust their os repos, right?

I think there are levels of this. I would say yes to trusting updates signed by Microsoft, Apple, RedHat, SUSE etc. But I have very little illusions on trusting ARCH or Gentoo upgrades for example. IMHO signing is best when you have a insecure transfer medium or storage. Where you don't trust that the packages can be meddled with in transit.

Where I can see it working for conan is if there was more larger companies creating "official" conan packages for well known software and they signed it with their key. Then you could have on the client part a list of trusted keys.

So let's examine the attack vectors for this:

The risk is to get a intentional exploit into your application that you then deploy or distribute this can happen if

• The source is compromised
• The build tools / CI is compromised (similar to the hacked Xcode that was floating around earlier)
• Bintray is compromised - someone replaces the binary on bintray without the authors intent
• MITM attacks on bintray to compromise the transfer of the package

Package signing would secure the last two parts of this, but the last one would be solved with certificate pinning as well.

Source compromise would only be detected by audits or making sure that the source code is located in-house.

Build tools / CI would only work if you run that yourself as well.

While I am not against package signing at all. I think that there are things we can improve already with much less effort:

1) Certificate pinning - in the clients conan config dir we could store the finger print of the servers SSL certificate and verify that correctly. Should not be to many lines of code to do you can do this in requests by passing a certificate to the verify argument: http://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification
2) Better hashing of the binary packages - I think we still rely on MD5 - let's make sure to use SHA256 and make package download with the wrong SHA fail really badly. This should be used in conjunction with 1 so that we download the list of package SHA's from a "trusted" source.
3) I think we can be clever with embedding metadata in the package that is also hashed so that we can trace it back to a source somehow - needs a bit more thinking though and maybe this is partially solved when we can pin packages with binary revisions.

I think implementing these steps would really help with the biggest attack vector which is the transport to and from bintray.

Implementing signing would also solve the problem with bintray being compromised - I think we need to figure out a way to transfer a hash of what was actually built on the CI to the downloader in this case. Signing would also not be useful unless we have a way to trust a list of keys.

I still think that if you have high security concerns you should never trust any third-party binaries (ideally not even third-party sources - but that's not really practical in this day and age). I would really recommend running a local CI to build the packages you need instead of relying on the open source community providing that for you - so many things that can go wrong.

Thanks,
Tobias

[weatherhead99]

rather late to this discussion I'm afraid but am also very interested in package signing for our own use.
A couple of points first:
1) we don't only need to worry about bintray/artifactory, some people (i.e. me! and possibly like 2 others) are still using the "built in" conan server thingy to serve packages, sometimes e.g. downloading from public repo then copying them to that server for further (internal) distribution
2)One of the things about OS package management signing is that (to take the case of e.g. suse) whenever you add a repo it's either going to already know the correct signing key (e.g. it's burned on the install iso), or it's going to ask you when you add the repo if you trust the key, where that key it shows you is a fairly opaque string of PGP signature stuff

So, with all that in mind, and respecting the effort that's already gone into this before I've managed to look into it, can I suggest we consider looking at (TUF) https://theupdateframework.github.io/ which seems to be an effort to do a generic package manager / software update signing system "the right way" and not relying on PGP signatures, which at this point are pretty crusty.

[memsharded]

Yes, I like the approach of https://github.com/theupdateframework, and it is something that we should investigate. Let me also summarize my current thoughts about this:

• This is a functionality that makes a lot of sense to be implemented with conan-hooks, to be able to provide the flexibility, customization necessary for different use cases, while not compromising stability and maintenance of the client.
• If that is stabilized and matured, we migth consider making it built-in in the client, but at the moment I'd say too early.
• We have a lot of higher priority issues, features, and tasks, including the path to Conan 2.0, which is very important and necessary. I don't think we have resources to approach this functionality now, it seems it probably will be after 2.0. But of course, help and contributions are greatly appreciated, and it is always good to have early feedback about proof of concepts even if they cannot be successfully integrated, the feedback and lessons learnt are very valuable and appreciated.