On Fri, Apr 05, 2024 at 03:19:23PM +0100, Simon McVittie wrote: > I find that having the upstream source code in git (in the same form that > we use for the .orig.tar.*, so including Autotools noise, etc. if present, > but excluding any files that we exclude by repacking) is an extremely > useful tool, because it lets me trace the history of all of the files > that we are treating as source - whether hand-written or autogenerated - > if I want to do that. If we are concerned about defending against actively > malicious upstreams like the recent xz releases, then that's already a > difficult task and one where it's probably unrealistic to expect a high > success rate, but I think we are certainly not going to be able to achieve > it if we reject tools like git that could make it easier.
Strongly agree. For many many things I rely heavily on having the upstream source code available in the same working tree when doing any kind of archaeology across Debian package versions, which is something I do a lot. I would hate to see an attacker who relied on an overloaded maintainer push us into significantly less convenient development setups, thereby increasing the likelihood of overload. > In the "debian/ only" workflow, the Debian delta is exactly the contents > of debian/. There is no redundancy, so every tree is in some sense a > valid one (although of course sometimes patches will fail to apply, or > whatever). I'd argue that this, and the similar error case in patches-unapplied, is symmetric with the error case in the patches-applied workflow (although it's true that there is redundancy in _commits_ in the latter case). -- Colin Watson (he/him) [cjwat...@debian.org]
