On Thu, 5 Jul 2007, Michael E Brown wrote:
On Thu, Jul 05, 2007 at 09:26:51AM -0400, seth vidal wrote:
On Thu, 2007-07-05 at 03:54 -0500, Michael E Brown wrote:
/var/cache doesnt seem like a good place to be putting keyrings. I
thought that the intent behind /var/cache/ was that you could delete it
and things would still work?
See james' answer - he had it spot on.
Next question: are you implementing this in a way that is compatible
with the way that SUSE signs repos? I just implemented signed repos on
my repos and would hate to have to redo things just because yum does it
differently.
SUSE expects repomd.xml.asc and repomd.xml.key. If the signature isnt
already in the db, it will download repomd.xml.key and offer to import
that for you.
the repomd.xml.asc we can do, yes.
the repomd.xml.key is redundant when we already have the gpgkey option
in yum.conf.
Possibly stupid question: is there ever a time or use case for when you
would want the repository signed by one key, but would not necessarily
want to let RPMs be signed by that same key? Or maybe the reverse, say
you have RPMs in your repo signed by a key, but you dont want to
automatically trust a repo signed by that key?
I'm thinking that we may want to separate the trust model for
repositories out from the individual RPMs. I think that trusting
individual RPMs is different from trusting repositories. For example, I
believe that apt has separate key lists for repos and individual
archives.
Yup, separating the repository keys from RPM keys can be useful in some
cases. For example people composing a repository (rel engineering or
similar) could be an entirely different organization than the group
creating the actual packages. The uses might not be that common, but
allowing for is useful.
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
