I've come back from a party and am a bit tipsy so I will read this
properly later, but:
Thanks for engaging with these questions!
Andrea Pappacoda writes ("Bug#1106071: [RFC PATCH dgit v2] tag2upload: add
pristine-tar support"):
> In practise, pristine-tar always stores the signature file as
> "orig_name.asc". So I think we could just specify this requirement here.
I think in principle it might be a .sig.
> >> If an orig tarball needs to be (re)generated, the service will use
> >> pristine-tar, using precixely the metadata in the .id file. The
> >> service will check that the generated tarball MATCHES THE HASH IN
> >> THE .ID FILE and that its contained tree is identical to SOMETHING.
>
> I'm not sure I get this part, but if you meant what I understood, then
> it's wrong. The .id file does not contain the hash of the tarball, it
> contains a single line which corresponds to the tree id, as mentioned
> above. I'm honestly not sure where the hash verification happens, but *i
> believe* it's part of the reconstruction when pristine-gz and co re run,
> thanks to information stored in the .delta (VCDIFF) file.
So the .id contains the tree (git tree object) which uniquely
identifies the *contents* of the tarball.
But how does the pristine-tar information specify the precise hash of
the tarball itself? Does the .delta file say what the output hash is
supposed to be ?
> One question remains unanswered. Should we allow .delta files modifying
> the tarball contents (i.e., do we want to allow generating tarballs
> which have different contents then the git tree)?
I don't think I fully understand the implications. My default
position is that the answer should be "no" unless one of us *does*
understand the implications :-).
Regards,
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.
