On Mon, Apr 9, 2012 at 17:38, Benson Margulies <[email protected]> wrote: > On Mon, Apr 9, 2012 at 10:45 AM, Andreas Veithen > <[email protected]> wrote: >> Wouldn't it make more sense then to go a step further and request >> setting up svnpubsub to publish releases via >> https://dist.apache.org/repos/dist/ (and manage the KEYS files in that >> repository as well)? > > I don't think that is relevant. > > Someone downloading might be suspicious that the owner of a mirror has > tampered, and created a bogus KEYS file while tampering. So, various > global apache.org web pages suggest going to the svn repo for the > actual source code and getting KEYS from there. Nothing pubsub will > help with this.
Not sure I understand the rationale about the mirrors. Obviously the link to the KEYS file should not point to the mirror, so this is a problem only if a user sees the KEYS file on the mirror and uses that one instead of following the links to the KEYS file on the download page (i.e. instead of downloading it from a server at apache.org). To avoid this, one would have to remove the KEYS file from the dist directory. However, I think that this is not possible right now because the file is also used by a script that automatically validates the signatures: http://people.apache.org/~henkp/checker/faq.html More precisely, we would first have to make sure that all keys ever used to sign a release can be found in the other locations checked by that script, which may be difficult. Also note that if we succeed with this, then we no longer need a KEYS file at all, so we no longer care if it is in SVN or not. > >> >> Andreas >> >> On Mon, Apr 9, 2012 at 16:22, Benson Margulies <[email protected]> wrote: >>> Yes, SVN. One of the validation mechanisms is to get KEYS from svn, to >>> detect tampered-with packages. >>> >>> >>> On Mon, Apr 9, 2012 at 10:21 AM, Daniel Kulp <[email protected]> wrote: >>>> On Monday, April 09, 2012 04:13:14 PM Andreas Veithen wrote: >>>>> On Mon, Apr 9, 2012 at 15:59, Daniel Kulp <[email protected]> wrote: >>>>> > On Sunday, April 08, 2012 04:48:27 PM Benson Margulies wrote: >>>>> >> but ... we have no KEYS file in the xmlschema tree. >>>>> > >>>>> > Not in neethi or axiom or others either.... >>>>> >>>>> That is not correct. Axiom always had its own KEYS file which was located >>>>> here: >>>>> >>>>> http://www.apache.org/dist/ws/commons/axiom/ >>>>> >>>>> Maybe you got confused because for the 1.2.13 release, I removed the >>>>> "commons" part of the URL and I created an empty axiom directory >>>>> already a couple of days ago (I only copied the 1.2.13 distribution >>>>> and the KEYS file to the new location today). >>>> >>>> I think Benson was commenting on KEYS in svn, not the dist area. I could >>>> be wrong though. :-) >>>> >>>> Same point though, would it make sense to just have a single KEYS file in : >>>> >>>> http://www.apache.org/dist/ws/ >>>> >>>> covering everything? >>>> >>>> (And looking at that list, we probably should remove some of the stuff >>>> there. Juddi, many of the Axis things, etc...) >>>> >>>> >>>> Dan >>>> >>>> >>>> >>>>> >>>>> > Would anyone object if I just grabbed: >>>>> > >>>>> > https://people.apache.org/keys/group/ws-pmc.asc >>>>> > >>>>> > and used that for the KEYS file? >>>>> > >>>>> > Next question: should I just stick it in the root of webservices or in >>>>> > each module individually? Maybe in: >>>>> > >>>>> > http://svn.apache.org/repos/asf/webservices/admin/ >>>>> > >>>>> > Thoughts? >>>>> > >>>>> > Dan >>>> >>>> -- >>>> Daniel Kulp >>>> [email protected] - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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] >>> >> >> --------------------------------------------------------------------- >> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
