On Monday, June 17, 2024 12:25:28 AM EDT Louis-Philippe Véronneau wrote: > On 2024-06-15 5 h 03 a.m., Philip Hands wrote: > > > 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. > > > Thanks for this thought experiment. Although I was already in favor of > the proposal, it helped me get a better grasp of what is at stake in > this GR. > > As many others have asked already, if there is really an opposition from > the FTP masters to the t2u proposal as stated in the draft GR, I urge > them to make it heard, especially with regards to Phil's email.
Given recent email on the list, are you still confused about this? Socially, I think this whole thing is awful. The objection was clearly stated 5 years ago and then after 5 years of silence, a GR out of nowhere claiming an unwillingness to engage. So far as I'm aware, no one on the FTP Team has been able to find a record of any discussion between the FTP Team and the tag2upload developers on this topic since 2019. Is this how we want Debian to work? Scott K
signature.asc
Description: This is a digitally signed message part.
