[Top][All Lists]

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

Re: [gnu.org #1784615] Textual change regarding ftp-upload instructions

From: Ian Kelling
Subject: Re: [gnu.org #1784615] Textual change regarding ftp-upload instructions
Date: Mon, 13 Dec 2021 19:48:42 -0500
User-agent: mu4e 1.7.0; emacs 28.0.50

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    >    > Could you please change this text:
>    >    > 
>    >    > - 2. The ASCII armored copy of your GPG key, as an attachment.
>    >    > + 2. The ASCII armored copy of your GPG key.
>    >    > 
>    >    > https://www.gnu.org/prep/maintain/html_node/Automated-Upload-
>    >    > Registration.html#Automated-Upload-Registration
>    >    > 
>    >    > The current text is a little confusing, because it says that text is
>    >    > an attachment within a GPG clear signed message, that is itself an
>    >    > attachment to an email. It seems to imply that people should be 
> using
>    >    > a special format with email attachment boundaries when composing the
>    >    > GPG signed message to ftp-upload@gnu.org.
>    >
>    > Not sure I understand the confusion.  The your armored GPG key should
>    > be put in as an attatchment in the MSGFILE.  _THAT_ file inturn needs
>    > to be clear-signed as well.
>    >
>    > What does "special format with email attatchment boundaries" mean
>    > here?
>    I see the confusion. The instructions on item 3 say to me: make a text
>    file with 4 things, 
> But that is not what it says, it says to construct a _message_ that is
> then sent.
> Not arguing that the text isn't clear, just that silly me doesn't see
> the unclearness to suggest a better wording.
>    then clearsign it and attach it. But, one of those 4
>    things says its should be an attachment, but if its in a text file with
>    other things, it can't also be an attachment on its own. So, I think
>    this patch is good.
> I'm not sure -- this depends entierly on how ftp-upload@ works.  If
> the expected format is that the GPG key is infact an attachment, then
> this makes it less clear.  Is that the case?  Maybe the overall
> wording could be improved entierly...
> Or maybe gnupload can do this stuff?

ftp-upload@gnu.org goes to our request tracker instance, and sysadmins
(including me), manually handle every message. A key point is that
request tracker mangles all mime signatures, so things should be

To handle your confusion about whether it should be a text file, replace
"Compose a message with the following items in some /msgfile/." with
"Compose a text file, hereafter called /msgfile/, with the items listed
below in it."

Then the first 3 should be like so:

1. Include a statement such as: "I intend for the GPG keys contained in
this signed message to be authorized to upload releases to the GNU
release server for the following package(s)", and list the package(s)
you want authorize. You must be an official GNU maintainer or uploader
for them.

2. Your name, your preferred email address for upload notifications, and
your Savannah username.

3. An ASCII armored copy of your GPG key.

Then #4 and #5 are the old #3 and #4.

The addition to #1, it gets a bit long, so I split it into #1 and #2.
They help fix a security issue that has nagged me for a long time:
people often sign a message that basically contains their email and a
list of packages, and outside of the signed message in the subject is an
indication they want to register the signing gpg key for uploads for
those packages. The problem is that The signed message itself is
ambiguous, there's a remote possibility that they signed that message
with some other intent, in some other context, then someone included the
signed message in a forged email.

Generally, having the gpg key as part of the signed message and not
being it's own attachment is slightly better. If it was just attached
and someone intercepted and modified the email, they could replace the
key with one that added signatures to it, or perhaps some other

- Ian

reply via email to

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