Tools with signatures
Tim Penhey
tim.penhey at canonical.com
Thu Apr 11 03:16:15 UTC 2013
All right then... this is a continuation.
Lets say we have a tool file called:
juju-1.9.13-precise-amd64.tgz
If during the upload process we create a signed associated file using a
shared Juju release key pair, we could have something like:
juju-1.9.13-precise-amd64.tgz.gpg
to go with it.
Now, to check the signatures, there is a crypto library on google code:
code.google.com/p/go.crypto
that handles openpgp stuff.
I'm assuming that we could have the public key embedded in our binary to
make the checking of the signature files easy(ish) - although I'm not
yet sure how to do this.
This does raise the questions of --upload-tools and how we interact.
We could use the gpg key of the user that uploads the tools, but what if
they don't have one?
Should we generate a key pair?
That would mean that we'd have to specify the public key part in the
config somewhere in order for more than one person to effectively use an
environment. (Unless you can think of a better plan)
Should we sign tools that go into the private bucket anyway?
How would signed tools interact with sync-tools? Should it handle
resigning tools with another well known key?
If we specify a public key for tool signings, should we only accept that
key, or the juju dist key too?
If we just used the key for the uploaded tools, we would never match a
public tool as it will not have the correct signature for verification
with our own public key.
Perhaps trusting tools that are in our own private bucket is sufficient,
as no-one else has permission to put stuff there?
What are people's thoughts around the questions here?
Tim
More information about the Juju-dev
mailing list