automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnupload question


From: Ralf Wildenhues
Subject: Re: gnupload question
Date: Wed, 21 Jul 2010 19:59:38 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

Hi Eric,

* Eric Blake wrote on Wed, Jul 21, 2010 at 04:36:23PM CEST:
> I'm in the interesting situation of trying to upload autoconf 2.67
> signed by my new key, but while still waiting for my new key to be
> installed by the ftp-upload folks to run the upload process (see
> http://lists.gnu.org/archive/html/autoconf/2010-07/msg00016.html).
> Right now, gnupload assumes that it should both create the .sig files,
> as well as the signed upload .directive.asc file, using the same key.
> But does the GNU upload process really require that the .sig and the
> .directive.asc be created with the same key, or does it only validate
> the directive, in which case I could manually create a .sig with my new
> key but the .directive.asc with my old key?

I don't know the answer to this.  But I think this is a policy question
that FTP masters and/or GNU should address, and if the additional
freedom is ok then gnupload can add the functionality.

>  While
> http://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads is
> clear that an upload must be a triple, it is not clear whether the .sig
> is validated.  If the split key approach works, should gnupload be given
> an optional argument to allow a second key for creating the .sig,
> different from the main key used for the .directive.asc, to save anyone
> else the hassle of having to manually reproduce gnupload steps just to
> get the split key behavior?

FWIW, gnupload --dry-run should provide you with those steps for the
functionality it offers.

> Of course, if the ftp-upload folks respond in time, this will be a moot
> point for me, as I can just do the autoconf 2.67 upload with my new key.

And I do think that this issue will be fairly rare.  ;-)

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]