Ian Jackson <[email protected]> writes: > 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: >> > 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
signature.asc
Description: PGP signature
