Robbie, Thanks for detailed explanation. I will append my key into KEYS file.
Kind Regards, Alex On 2 December 2015 at 17:01, Robbie Gemmell <[email protected]> wrote: > On 2 December 2015 at 16:20, Oleksandr Rudyy <[email protected]> wrote: >> Hi all, >> >> Whilst performing release tasks for qpid java components of version 6.0.0 I >> realized that KEYS file [1] referred from Qpid download page [2] is >> actually not up to date. >> >> As far as I understood currently public PGP signing keys for qpid project >> are kept in [3]. >> >> I am not sure why download page refers public keys from [1]. Is it >> intentional? >> If yes, what is the rationale behind that? >> If not, we need to update download page to refer keys from [2]. >> >> Kind Regards, >> Alex >> >> [1] http://www.apache.org/dist/qpid/KEYS >> [2] https://qpid.apache.org/download.html#verify-what-you-download >> [3] https://people.apache.org/keys/group/qpid.asc > > > Great timing, I was also planning a mail on the subject as I had > grabbed your key from > https://people.apache.org/keys/committer/orudyy.asc earlier to verify > the files. > > Long ago, when the bits were put in place for > https://people.apache.org/keys/<foo> (files are available for > individual committers, committer groups, and pmc groups) I think the > idea was that folks could transition to using that as the source for > their keys. Traditionally the source was just a KEYS file in the > source repository, but this can be a little cumbersome and certainly > becomes a bit more awkward when you have multiple repositories as we > now do. > > Having a KEYS file on the main dist area (populated from the generated > file) still seems reasonable enough given it is the primary source, > contains the other files, and is explicitly updated. Like the sig > files, I don't believe it gets mirrored. Pointing directly to the > auto-generated files also seems reasonable enough (one thought that > just popped into my mind is that people.apache.org is being > transitioned away, with home dirs moving to home.apache.org soon, and > other services to be addressed when the time comes, not sure if that > will have any impact here). Both seem like improvement over keeping > the current source file in SVN, particularly when many of the > components now live in other repos. > > Robbie > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
