Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Simon Josefsson writes ("Re: Include git commit id and git tree id in *.changes files when uploading? [and 1 more messages]"):
>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>> > We would generally recommend against using gbp import-orig.
>>
>> Please don't: gbp import-orig can be teached to work the way you want.
>> Instead, encourage that configuration.
>
> Currently gbp import-orig does not seem to have an option for
> requiring that the tarball it's importing is treesame to upstream git.
Doesn't it? 'gbp import-orig --uscan --upstream-vcs-tag=v1.2.3' will
fail with a hard error if v1.2.3 cannot be found and imported to the
upstream branch. Isn't that the property you want?
> 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.
So maybe these commands (or something similar) is what should/could be
recommended instead of 'gbp import-orig'.
> I find your focus on tarballs and your distrust of git perplexing.
> The difficulties with SHA1 aren't negligible, but they have not been
> used to carry out actual attacks and indeed I'm not aware even of
> collisions (let alone second preimages) in git's hardened SHA1.
> This is a largely theoretical problem, right now.
Maybe it helps to realize to understand where I'm coming from to is to
see that I worry about long-term authenticity and reproducibility of
bit-by-bit identical release artifacts.
A PGP signature on a 'git archive' tarball is the closest I'm coming to
solve my concern, so pending anything better, that's what I will
recommend.
If there is a way to implement something with that property with native
git, I would happily give up tarballs.
Dismissing SHA1(CD) collision resistance as a theoretical concern is
fine -- I would agree Debian has more serious problem -- but claiming
that out of context is dated. The crypto engineering world has mostly
already completed the migration away from trusting SHA1 for collision
resistance.
>> >> Is there any advantage to using --upstream-tag=upstream/1.2.3?
>> >
>> > If your upstream's origs come from git-archive, none.
>>
>> One example to the contrary: git-archive from a Git SHA256 repository.
>> It seems Salsa nor dgit supports these now?
>
> 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.
/Simon
Attachment:
signature.asc
Description: PGP signature