PPA keys don't link to the archive / user that they are signing / signing for

Note that the Launchpad user nickname is also changeable by the user, so doesn't prevent users from playing tricks. That said, it probably is a good idea to include the nickname since it is possible to have multiple users in Launchpad with the same display name.

RIght, as discussed in bug #158570, we could use the PPA URL in the signing-key UID .

The PPA URL can easily become constant (by blocking 'name' changes on users/team with PPAs) and then provide an easy and secure manner for checking key references.

"Signing key for http://launchpad.net/~bzr/+archive/ppa"
"Signing key for http://launchpad.net/~bzr/+archive/stable"
"Signing key for http://launchpad.net/~bzr/+archive/experimental"

What do you think ?

On Mon, 2009-03-30 at 18:04 +0000, Celso Providelo wrote:
> RIght, as discussed in bug #158570, we could use the PPA URL in the
> signing-key UID .
>
> The PPA URL can easily become constant (by blocking 'name' changes on
> users/team with PPAs) and then provide an easy and secure manner for
> checking key references.
>
> "Signing key for http://launchpad.net/~bzr/+archive/ppa"
> "Signing key for http://launchpad.net/~bzr/+archive/stable"
> "Signing key for http://launchpad.net/~bzr/+archive/experimental"
>
> What do you think ?

It shouldn't have 'Signing key' in it, I don't think.

'Launchpad PPA at https://launchpad.net/~bzr/+archive/ppa'?

Or '“ppa” Launchpad PPA for bzr'? The latter should be just as fine as
the URL, and you could even stick the URL in the comment field.

--
William Grant

William,

I see your point about excluding 'Signing key' and I agree.

TBH, I prefer the former suggestion, 'Launchpad PPA at <URL>', because it pass the right message to the user 'Click on the URL to know what is that about.'.

No unstable, and sometimes meaningless, displaynames in the key UID.

I think that adding the repository URL as the UID comment would be nice, but since it varies according the PPA privacy, it's not a good idea.

On Mon, 2009-03-30 at 21:48 +0000, Celso Providelo wrote:
> William,
>
> I see your point about excluding 'Signing key' and I agree.
>
> TBH, I prefer the former suggestion, 'Launchpad PPA at <URL>', because
> it pass the right message to the user 'Click on the URL to know what is
> that about.'.

But the LP webapp URL is not the important thing to the user - the
archive URL is. As you say below, the archive URL is not a valid
candidate, so we can't use that. I don't think a less relevant, normally
invisible URL belongs in the name just because the better one can't be
used.

> No unstable, and sometimes meaningless, displaynames in the key UID.

The display name can't be in the UID, as it is mutable. My second
proposal was just a human-readable unambiguous immutable reference to
the archive. It's more readable and less irrelevant than the webapp URL.

> I think that adding the repository URL as the UID comment would be nice,
> but since it varies according the PPA privacy, it's not a good idea.

Right, its mutability removes it from candidacy.

--
William Grant

Note that signing-keys will be shared by PPAs owned by the same user/team, per bug #357177.

So the reference in the key UID should be for a user/team, not a specific PPA.

I think that including the PPA and/or user display name in the key is
reasonable even though they can possibly change. It's rare that
they'll change substantially, and in the future (as a wishlist type
thing) Launchpad could even generate new GPG UIDs when this happens.

After all it's quite possible for me to change either my real name or
my email address yet I put them both in gpg keys that I generate
myself.

I think blocking name changes for users with PPAs would be getting it
a bit backwards. People will or should know this will change their
PPA URL and I expect they'd rarely do it, and there may be some cases
with team PPAs where it's useful.

--
Martin <http://launchpad.net/~mbp/>

Name changes can be handled by updating the key - GPG has a protocol for that :). So renames merely need to trigger a key refresh.