search

tpkg / client

tpkg client code
MIT License
5 stars 7 forks source link

Ability to sign (and verify signature of) packages #7

Open jheiss opened 12 years ago

jheiss commented 12 years ago

From Carl Johnson: Similar to RPM and other packaging systems, it would be helpful if tpkg offered the ability to sign packages, and for the tpkg utility to verify such package signatures.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/8

jheiss commented 12 years ago

This was in the original design (redacted reference to internal wiki page with original design specs). I never implemented it because I wasn't sure how we'd use it.

However, per IRC discussion today we might use this within ATTi by automatically signing packages that are uploaded to the central server. We authenticate package uploads against SSO and keep track of who did the upload, so a signed package means we have a record of who uploaded the package. The fancier implementation of having individual users sign packages requires too much overhead.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/8#comment:2

jheiss commented 12 years ago

From Carl Johnson: If we wanted to get REALLY fancy, perhaps we could incorporate GPG/PGP signatures from SSO as well. If the user wanted to further prove the lineage of their package, they could encrypt the package upon upload? Or perhaps just sign it... I forget if gpg/pgp supports plain ol' signatures. tpkg could then decrypt or verify sig based on user's public key in SSO.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/8#comment:3

jheiss commented 12 years ago

The right way to get PGP functionality isn't clear. Looking on gemcutter there are a couple of very low rev pure-Ruby PGP implementations openpgp-0.0.2 and klacointe-openpgp-0.0.1.3) and a couple of bindings against GPGME, the GnuPG library (gpgme-1.0.8 and ruby-gpgme-1.0.7).

The GPGME options probably aren't practical, as they require the native GPGME library be installed, and particularly for folks who get tpkg via gem we have no way to ensure that happens automatically. On the Red Hat side we'd have to get an RPM from a 3rd party repository, etc.

The openpgp gem was last updated in December 2009, so (FWIW) it seems to have the most current development. It's not immediately clear if generating a signature is implemented. If not we might try communicating with the developer and see if that could be implemented, or contribute it ourselves.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/8#comment:4

jheiss commented 12 years ago

I don't see much point in letting users encrypt packages with PGP and upload them to our central repo, as that user would be the only one who could install it. (Unless we let multiple people encrypt the package with their various keys, but that's just asking for a big maintenance headache.)

I'm fine with supporting multiple signatures per package, so the user can optionally sign the package himself, and then the tpkg server will also sign it. I suppose then we'd have to have a option on the client to accept any one valid signature or require that all signatures are valid.

Another thing to decide would be what our default requirements would be around signed packages. I think the default policy in public tpkg would be to attempt allow unsigned packages, allow signed packages if the client isn't configured with any PGP keys, and only reject unsigned packages or signed packages that don't validate if the user has configured keys. Which I suppose would be fine for ATTi use as well, we'd just make sure etch managed machines were configured with a PGP key to validate packages. However, we'd need a command line flag (something like --allow-unsigned) to let developers install unsigned packages.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/8#comment:5

jheiss commented 12 years ago

Sean O'Brien says he's using the openpgp-0.0.2 gem on the SSO server and has had no problems.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/8#comment:6

jheiss commented 12 years ago

From Carl Johnson: I was only referring to PGP encryption as an alternative to signing. Either way the package would be decrypted on the tpkg server.

I think an --allow-unsigned flag makes sense. One consideration is local .tpkg files that aren't in the repo. Would it just bypass sig checking for those? I'd assume so.

And of course there's the issue of what to do with all the packages currently in the repo. Would you go back and sign them all?

Was: https://sourceforge.net/apps/trac/tpkg/ticket/8#comment:7