Sean Whitton <spwhitton@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. -- Philip Hands -- https://hands.com/~phil
Attachment:
signature.asc
Description: PGP signature