If the juju tool only knows the "official juju" public key. How does that not validate the tools are from a trusted source? It doesn't help the --upload-tools case, but those are put in your private bucket anyway. It is true that we shouldn't trust anything that is signed. Though I'll note xkcd: <a href="http://xkcd.com/1181/">http://xkcd.com/1181/</a> We could trust a specific CA or web or whatever, but why not just have a key that is needed to release the tools? John =:-> <div class="gmail_quote">On Apr 8, 2013 7:08 AM, "Tim Penhey" <<a href="mailto:tim.penhey@canonical.com">tim.penhey@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi all, I have a task card that I don't feel confident starting without more understanding of the problem, and how the solution would help with that. And how the tool release process would work with this too. Firstly, which is the problem that we are trying to solve? * We have an unmodified tarball as it was defined at the source * The tools are from a trusted source The traditional method for the first is to provide an md5 (or other) hash that you can grab as well as the source file. However if we are trying to solve the second problem, this doesn't help. So my first question really is what problem are we trying to solve? How will this differ between tools from a public bucket, and those that are uploaded locally? Who is considered trusted? How would we sign the tools to ensure that they come from us? I can think of several ways, but I'd prefer to hear some others input first. Tim -- Juju-dev mailing list <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> </blockquote></div>