Simon Richter <s...@debian.org> writes: > We might get additional insights after a breach, perhaps, if Github > decide to take a compromised repository offline and our copy is still > accessible.
I think this is way more useful than you are making it sound. Upstream may not use GitHub at all and instead use their own personal Git servers. The malicious code may be introduced by a Debian contributor directly in Debian. Upstream may have tampered with their Git repository using force push or the like in a way that causes the desired trace information to be lost. There are numerous cases where Debian having its own archive of the Git history when investigating a compromise would be immensely valuable. > We have several 90% solutions of mapping Debian packaging onto git, but > all of these are incomplete and annoying to use because we disagree with > git on what constitutes data, and what constitutes metadata, so the data > model does not match reality or requirements, and from a security > standpoint that concerns me more than improved forensics. This is why people are working on incremental improvements. I think such improvements are more likely to get us closer to where we want to be than a boil-the-ocean approach that attempts wholesale change to how Debian works. It's easy to come up with new designs that in theory would be more coherent and straightforward, and very hard in practice to avoid that turning into <https://xkcd.com/927/>. One of the important properties of tag2upload is that it meets people where they are and tries to support their existing workflows while providing a more systematic source package construction algorithm. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
