Simon Richter writes ("Re: [RFC] General Resolution to deploy tag2upload [and 1
more messages]"):
> On 6/13/24 20:29, Marco d'Itri wrote:
> > Of course: this makes auditing much easier.
>
> That is a *massive* amount of data though, especially if we're expected
> to import the entire upstream git history as well and base the packaging
> branch on top of an upstream commit.
In practice IME the full git history is usually a small integer
multiple of the current codebase size. archive.d.o already has to
contain many copies of the source code. And we already want to keep
all uploaded versions indefinitely (that's what snapshot.d.o is).
I think it is possible that there will be a handful of packages where
things are significantly more awkward, which might not be able to
adopt tag2upload.
> We will also need to be prepared for removal requests, so there needs to
> be a procedure in place for that, people authorized to perform it, and
> an audit framework for that.
Yes.
The dgit git server is already set up for this, from an infrastructure
point of view. We have mechanisms that allow an administrator (Sean
or I in this case) to rewind a repository, and also to prevent harmful
git objects from being re-uploaded.
In the 10 years that dgit-repos has existed, this has been necessary
once, due to a bug in dgit itself (that caused corrupted commits that
were accepted by git but rejected by most forges, #850469/#849041).
We don't have a very developed process flow but I think we could
probably make it up without too much trouble.
> We could add some mechanisms, like enforcing that merge commits pulling
> in a new upstream version will only modify files outside of debian/ in
> one subtree, and files inside debian/ in the other, but that conflicts
> with workflows that maintain Debian-specific patches as commits instead
> of patch files.
This sounds a bit like `git-debrebase`, which is a git workflow tool -
a competitor to gbp and git-dpm. The src:xen team uses it, for
example. But I don't think it's suitable for everyone.
git packaging and delta management workflows (and the associated
tools) all have both strengths and weaknesses. Maintainers are going
to have to continue to decide which set of tradeoffs to choose.
> 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.
I think tag2upload brings Debian's model closer to git and to
upstream's. That's a big part of the point.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
