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: >> > xzcat emacs-llama_1.0.3.orig.tar.xz | git-get-tar-commit-id >> > 2a89ba755b0459914a44b1ffa793e57f759a5b85 >> >> That would only match upstream commit if 'emacs-llama' pin the >> tag2upload upstream git commit to the actual upstream git commit, right? > > I'm not sure what you mean by "pin" here. But, yes, we would > recommending using actual upstream git.
With "pin" I mean the git commit id recorded in the tag2upload git commit: [dgit please-upload source=emacs-llama version=1.0.3-1 upstream-tag=v1.0.3 upstream=2a89ba755b0459914a44b1ffa793e57f759a5b85] This "pins" the tag2upload Debian upload to a particular git commit that is claimed by the maintainer to hold upstream source code. (A side note: That is a weak claim since it rely on SHA1 collision resistance, which is a hole large enough hole to run practical SBOM attacks through although, un-intuitively, that not an argument against this scheme, as some suggests, since we can move to SHA256 if we care to make a transition.) >> Which it does for this package: [demonstration] > ... >> However, I think for many packages, that is not what is happening, >> because the tag2upload upstream git commit will be the 'upstream/1.2.3' >> tag that is created by 'gbp import-orig'. Which is Debian-specific > > Yes, this is true. > > 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. > If the upstream orig tarball came out of git-archive then importing it > into git again is at best pointless I disagree with that as a general conclusion -- upstream git-archive tarballs MAY be relevant because 1) they are long-term archival in a stable format, 2) as such, they can be protected with a cryptographic signature on a long-term archival file. Things stored in git doesn't offer those guarantees. Neither the git repository, nor a git-bundle or a git-archive output provide long-term archival properties. I'm not aware of any documented/supported way to reproduce a particular artifact from a git repository 20 years ahead. Even to the contrary: git is more or less documented to NOT offer this functionality, since changes are happening. > and if the upstream tarball waa generated in some other way by > upstream, it can be hazardous. Agreed. > To put it more tendentiously: gbp import-orig's function is to import > the xz attack trigger, from the hard-to-audit upstream tarball, into > Debian's git, so that we can ship the vulnerable library, despite the > attack being only in dormant files in a test subdir in upstream git. > This relieves Jia Tan of the need to put the attack trigger into git > where it is more visible so more likely to be detected. > > But, does gbp import-orig not base its history on the upstream > history? So if the upstream tarball was made with git-archive, the > commit referenced by the gbp import-orig tag will be treesame to the > actual upstream release tag. So in this situation the traceability is > worse, but not catastrophically so. > > Anyway: a user who is determined to use gbp import-orig has presumably > subscribed to the "pristine upstream tarballs" doctrine and would want > tag2upload to reproduce that tarball. That requires pristine-tar. > > This kind of situation is one reason why we *do* want to support > pristine-tar. It's popular, even though it's usually a bad idea. > So we we want to support it, so that tag2upload produces the best > possible output, even when people do the bad normal-for-Debian thing. While I mostly agree, I think this is somewhat over-generalizing: 'gbp import-orig' can support the scheme you seem to prefer, unless I'm missing something. Recommend the 'upstream-vcs-tag' approach. >> This leads to me to believe that it would be better to use 'git-debpush >> --upstream-tag=v1.2.3' instead of 'git-debpush >> --upstream-tag=upstream/1.2.3', right? > > Yes. It would be nice to document this somewhere. The consequences of this choice was not at all clear to me, and maybe others will be similarily confused in the future. >> I've been mixing those two styles in my uploads, to experiment with the >> effect, and pending any recommendations on this. I haven't seen any >> noticiable difference between these two styles, and mix between them >> somewhat randomly to gain experience. >> >> 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? > If they don't then changing to use upstream git as your source of > truth rather than upstream tarballs might be some work, but is > definitely a good idea. > > The only time when you'd want to use gbp import-orig is if upstream > don't use git, or their git is wholly unuseable for some reason. Or use Git SHA256, I suppose? /Simon
signature.asc
Description: PGP signature
