Hi, On Fri, 2024-06-14 at 14:46 -0700, Russ Allbery wrote: > Ansgar π <ans...@43-1.org> writes: > > > Okay, so we have to accept a path into the archive that is known to > > accept malicious uploads that would have been rejected by dak so maybe > > that path will be changed later? I don't see that happening given all > > suggestions to change this have been rejected, even when fairly simple > > to implement. > > This is not known.Β You have asserted this, and then come up with > increasingly implausible excuses for why you cannot clearly explain wtf > you are talking about. > > It's entirely possible that there are security bugs in the current > tag2upload implementation, just like it's entirely possible that there are > security bugs in dak and in any other piece of software.Β The way we deal > with those, now and in the future, is that someone explains what the > security bug is and then we see if we can fix it.
*shrug* For tag2upload even trivial patches fixing bugs like references to undefined functions won't be applied. I doubt any more involved patches to fix security issues would be applied. So I decided to not waste my time on that (but I checked briefly and it at a quick glance it looks like issues from ~5 years ago are still not resolved) and not stand in the way to create another stalemate in case someone wants to fix them. So why bother when all that comes in the end is "generating a manifest is hard even though others do it with one line of shell"? (Yes, it might be a bit more if one doesn't want to include .git in the manifest or possibly have two in case .debian.tar.* overwrites something in .orig.tar.*.) Or suddenly the tags must be possibly to create manually and so no manifest or other changes are possible even though before it was a script (git-debpush). I'm sure people will find new requirements if they are too conservative to consider any changes. Ansgar
