Hello, On Thu 17 Jul 2025 at 01:49pm +01, Ian Jackson wrote:
> Package: dgit > Version: 13.5 > > It has become clear to me in many corridor conversations that, > workflows involving pristine-tar and upstream origs are really very > common. Where upstream origs are not treesame to git (which is > basically, whenever they were not made by git-archive): > > 1. Existing non-git-first workflows (git-buildpackage) do not report > the discrepancy. They treat the tarball as more authoritative. > > 2. dgit push-source will fail. tag2upload will fail, even if > we implement pristine-tar support. > > Of course no-one should be using these workflows, but we need to think > whether we would rather somehow dismantle this barrier to dgit/t2u > adoption. In practice I think the folks with the vulnerable workflow > are going to keep with their vulnerable workflow anyway. > > The obvious way would be to reify the xz attack diff as an extra patch > in d/patches, during git canonicalisation (as we do for .gitignore). Interesting. Doing it as an extra patch sounds good; it's easy to inspect what was done. The UI for turning this on for tag2upload seems tricky unless we only add one additional quilt mode which is like --gbp plus this. Otherwise we need another [dgit ...] element. Could it be on by default if the user is already using the foreseen pristine-tar support? I.e. we defer to their pristine-tar data. -- Sean Whitton
signature.asc
Description: PGP signature
