Sean Whitton <spwhit...@spwhitton.name> writes:
...
The ftpmaster team have refused to trust uploads coming from the
tag2upload service. This GR is to override that decision.
Full disclosure:
I'm a happy dgit user. The support I've had from Ian for dgit (when I
messed things up, generally) has been outstandingly good, and has
generally resulted in a change to dgit that prevents me (and others)
from messing up in a similar manner. It strikes me that tag2upload is
another stride in the same direction, so I'd like to have the chance
to use it, because I suspect that it will also make contributing to
Debian easier, less error-prone, and just more pleasant.
[Note: in the following, I am NOT trying to suggest a technical fix, so
please don't start nitpicking the details -- it's just a thought
experiment that I hope might shed some light on the situation]
If it were easy to deploy an instance of tag2upload in my house,
populated with a sub-key of my GPG key, I would probably set that up
(and then start worrying about the security of the sub-key ;-) ).
If I did that, I believe the FTP masters would still accept my uploads.
Should they? or is it perhaps the case that they are objecting to the
idea that tag2upload is capable of reliably generating a source package
from a git tag. (I personally trust Ian when he says that it is capable)
If Ian were to offer a hosting service for such personal tag2upload
instances, in a way that he assured me could not be used to sign
packages unless I had signed a matching git-tag, I would be willing to
trust his assurances, and may well take him up on the offer.
It seems to me that such a centralised service is more likely to do
things like keep the keys in an HSM, and have effective separation of
the components, than something set up by a random developer at home, so
one could argue that it's going to be more secure than the self-hosted
version.
Would the FTP masters still be OK with that? If not, what's changed?
If that's OK, but tag2upload as proposed is not, are we really drawing a
line based on what name is on the signing key?
Would it make any difference to the FTP masters if there was some way
for me to assert that I trust the tag2upload service/key to build/sign
source packages for me?
For instance, if one had to sign something with a GPG key that matches
the one that later signs a gpg tag, before tag2upload would be willing
to process one's signed tags, would that make the FTP masters happier?
Personally, I'm not convinced that would really add anything, since if
one has sufficient control of the key to push a signed tag, then one's
also going to be able to sign a statement that you want tag2upload to
act on that tag, but I thought that describing the options might help
narrow down what the perceived problem is.
Of course, without something describing exactly what the problem is from
the FTP master's point of view, it's very hard to judge the merits of
their position.
Cheers, Phil.
