Simon Josefsson writes ("Re: Include git commit id and git tree id in *.changes
files when uploading? [and 1 more messages]"):
> Ian Jackson <[email protected]> writes:
> > Even if it did have an option to check the tarball contents was right,
> > it would be very tempting for a maintainer who's trying to get shit
> > done to override the check, rather than deciding not to import the
> > tarball at all, since they probably don't have a procedure they're
> > confident in that doesn't involve gbp import-orig. So what would be
> > needed is a mode for gbp import-orig where it is able to *not import a
> > tarball at all*, thus preferring git when tarballs and git disagree.
> > That way the user faced with a discrepancy can proceeed.
>
> I agree that would be an improvement. GBP is fairly tarball-centric.
>
> I now realize that maybe I agree more about your recommendation against
> 'gbp import-orig' than I earlier thought.
>
> If we use 'gbp import-orig' for the strong work-flow of importing
> upstream git, including using upstream git tags, into the upstream
> branch, then in this situation, 'gbp import-orig' is just a lot of
> complexity compared to
>
> git checkout upstream
> git fetch up
> git checkout -B upstream up/v1.2.3
> git checkout debian/latest
> git merge upstream
> git diff debian/1.2.2-4..
>
> or something to similar effect. More people should be familiar with
> this kind of normal git operation than any gbp commands.
Precisely. But also, gbp import-orig (1) expects an orig tarball
(2) if the tarball contents differ, synthesises git commits based on
the tarball.
That's not just a "lot of complexity". Point 2 it is a vulnerability
which has been used, in practice, to attack Debian!
> So maybe these commands (or something similar) is what should/could be
> recommended instead of 'gbp import-orig'.
Yes. That's what we recommend in dgit-maint-merge(7).
> > So not any gitlab, nor github. Codeberg supports it AIUI but you
> > can't get there from a SHA1 repo. This is a largely theoretical
> > situation. See my other comments about git upstream's approach to
> > this transition.
>
> Both GitLab(.com) and Codeberg supports Git SHA256 projects. It seems
> Salsa is configured to disable them.
I think the best information about the current situation is here:
https://git-scm.com/docs/hash-function-transition
Unless that's out of date, I think it's clear that there isn't yet
upstream support for a workable transition to SHA256 in existing
projects, and new projects still default to SHA1.
In particular, this part is totally hopeless:
Until Git protocol gains SHA-256 support, using SHA-256 based
storage on public-facing Git servers is strongly discouraged. Once
Git protocol gains SHA-256 support, SHA-256 based servers are likely
not to support SHA-1 compatibility, to avoid what may be a very
expensive hash re-encode during clone and to encourage peers to
modernize.
That's undeployable in two separate ways. I imagine the pressure to
fix it is is very intense though. We are fate-sharing with a lot of
powerful (and rich) people with similar concerns.
Ian.
--
Ian Jackson <[email protected]> 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.
