On Sat, 30 Mar 2024 at 10:16, Guillem Jover <guil...@debian.org> wrote: [snip]
This: > I'm personally not a fan of pristine-tar, and my impression is that it > is falling out of favor in various corners and big teams within the > project. And then I'm also not a fan either for mixing packaging with > upstream git history. The non-native packages I maintain only contain > debian/ directories, which to me have the superior properties (but not > tooling), including in a situation like this. I'll expand on this later. And this: > I think the biggest issue is that we are pretty much based on a model > that relies on trusting upstreams, for code, for license and copyright > compliance, etc. We tend to assume upstreams (and us!) can make > mistakes, but that in general they are not working against us. > > When confronted with a known hostile (and not necessarily malicious) > upstream the only winning game is not to play. If we do not even know > the upstream is hostile and/or malicious that seems like a losing > prospect to me. There are so many ways such upstream can slip stuff > through in this model that this gets really nasty really quickly. > > Don't get me wrong, I think we can/should modify our processes and > tooling somehow to at last try tot deter this path as much as possible, > but it still seems to go counter to our model, and seems like a losing > prospect. (You could have an upstream that tries to overwhelm you with > sheer amount of commits for example. In this case they even included > the bulk of the backdoor in git, and in the end I guess I don't see > much difference between smuggling something through git or a tarball.) > > And, coming back to the Debian side of things. To me the most > important part is that we might be able to close a bit this door with > upstream, but what about this happening within Debian? I think we have > discussed in the past, what would happen if someone tried this kind of > long term attack on the project, and my feeling is that we have kind > of shrugged it off as either "it would take too much effort so it's > implausible" or "if they want to do it we are lost anyway" but perhaps > I'm misremembering. > > Related to this, dgit has been brought up as the solution to this, but > in my mind this incident reinforces my view that precisely storing > more upstream stuff in git is the opposite of what we'd want, and > makes reviewing even harder, given that in our context we are on a > permanent fork against upstream, and if you include merge commits and > similar, there's lots of places to hide stuff. In contrast storing > only the packaging bits (debian/ dir alone) like pretty much every > other downstream is doing with their packaging bits, makes for an > obviously more manageable thing to review and not get drown into, > more so if we have to consider that next time perhaps the long-game > gets played within Debian. :( > > (An additional bonus of only keeping debian/ directories is that it > would make it possible to checkout all Debian packaging locally. :) Are the most insightful things I've read so far, both on the social and technical side of things. I will add that comparing autogenerated files in big/huge projects is something utterly complicated. Could take days of work. On the other hand big/huge projects tend to have much more eyes, but things can always go wrong. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
