On Sunday, June 16, 2024 12:26:48 AM EDT Sean Whitton wrote: > Hello, > > On Sat 15 Jun 2024 at 06:03pm +02, Joerg Jaspert wrote: > > On 17258 March 1977, Sean Whitton wrote: > >> So, why am I proposing a GR? > > > > This one took me by surprise, honestly. > > > > Looking into my notmuch, the last time tag2upload came up in my > > ftpmaster inbox was in 2019. Between then and now there doesn't appear to > > be any serious contact with us about it. There had been mentionings on > > some mailing list somewhere, but nothing coming to us, that I can > > find. > > In recent years, you have stepped in with your expertise in a number of > emergencies, and I am most grateful for that. > > But with respect, you have not otherwise been active in the ftpmaster > team, and you didn't significantly participate in the original > tag2upload discussions. So I think you may be missing things. > > We have been seeking help behind the scenes over the past four years. > No progress was made, so we decided to draft a GR. > > > Even then, back in 2019, one of the major points that ftpteam members > > raised had been "the archive has to be the final point to check if an > > upload is accepted" and that we do retain *all* user signatures of > > source packages, and that such a service must provide the same level > > of possible verification. Some other requirements on the signature too > > (collision resistant, need to be verifyable with only stuff included > > in the source package). Also something about not using Perl, but meh, > > lets ignore that one here. > > > > So, 5 years of (hopefully) development, but the major point (this should > > *not* bypass/circumvent archive upload checks and restrictions) did not > > get addressed. More like, entirely ignored. > > Like Russ, I'm grateful for how you've set out some things more clearly > in this message. I'm looking forward to reading your reply to him. > > I would ask you not to characterise the disagreement we are having as > merely over a technical detail. > It's the essence of tag2upload that the tag metadata is minimal, and > easily generated by a short shell script, like git-debpush. > > We did not ignore your position: we argued against it. No-one from > ftpmaster has responded to our arguments for wanting the metadata to be > minimal. So as I say, I'm looking forward to your reply to Russ.
I don't think this is fair. Joerg is paraphrasing an email he sent the last time (that I can find) this was discussed[1]: > I currently do not have too deep a thought on how good their > implementation is. Just one thing I've seen picked at multiple times, > and in different places: The current implementation appears to move away > the final integrity check linking an upload to a person away from the > archive software to some other. > > Thats a no-go. > > Note: I do not say it must be "a dsc" "a git commit" or "a something" > that is used for this check. That is an implementation detail. But the > final check/link of an upload with a maintainer(s key) has to be "in" > the archive. Systems before it can *additionally* do any number of them, > but the final one is in dak. My local mail archive is incomplete, but I only find one reply from the tag2upload developers that proposes some possible mechanisms to address this concern [2]. I don't find any arguments against it or claims that the metadata has to be minimal. As far as I can tell, none of the design changes Ian suggested might mitigate this concern are included in the current design. While I'm not an FTP Master, I have been active on the team as an FTP Assistant during most of this time. Before the posting of the draft GR, I simply have no evidence of any communication regarding tag2upload with the FTP Team since 2019. Since 2019, I have one mention of tag2upload in an email that by either of you in a message Ian sent to debian-project in 2023. I know we are supposed to assume good faith, but this whole thing certainly felt like an ambush to me when you proposed it. Scott K [1] https://lists.debian.org/msgid-search/87lfvdw1y3....@ganneff.de [2] https://lists.debian.org/msgid-search/ 23911.41752.922344.263...@chiark.greenend.org.uk
signature.asc
Description: This is a digitally signed message part.
