Sean Whitton writes ("Bug#1106071: [RFC PATCH dgit v2] tag2upload: add
pristine-tar support"):
> Thanks. I've included some inline comments below.
>
> I think it would be helpful to work on the spec in tag2upload(5) before
> continuing too much with code. It'll make it easier to keep the three
> of us on the same page.
Yes, I very much agree. Spec work on the protocol ought to precede
the code.
> On Sat 26 Jul 2025 at 02:12pm +02, Andrea Pappacoda wrote:
> > - Differently from the old pristine-tar check, the code is not run just
> > for the first (i.e., -1 or -0.1) revision, but for any upload. This
> > way, the t2u service can potentially handle the case where
> > a pristine-tar upload was intended, but no orig is available in the
> > archive yet. Please let me know if this makes sense or not!
>
> It might make sense, I'm not sure yet. Can you describe a concrete
> example that would lead to this being helpful?
I'm pretty sure Andrea has this right.
If we have pristine-tar support we should engage it whenever we are
doing upstream handling (ie for non-native source formats) and this
ought not to depend on the version number.
The -1 etc. thing is just a guess really. That's fine for a check,
but it's not fine for functional code.
Of course the pristine-tar codepath is entitled to decide that
pristine-tar ought not to be applied to this upload, using its
pristine-tar-specific knowledge.
> > +# TODO: what about signature files?
>
> Do you think we could extract them and include them in the upload?
Does pristine-tar convey signature files? If so we should definitely
support them.
> I think we can verify them by using the upstream key embedded in the
> source package, right? And if that verification fails we should
> probably abort the upload -- maintainers who choose to use tarball
> signatures had better make sure they verify.
I don't think I agree that we ought to be doing signature verification
that isn't related to our functioning.
In particular, this means that if we were to accept an upload with no
signature file, we should accept an upload with a signature file we
can't verify for whatever reason. Since we are obviously not relying
on the signature if we don't mind if it's totally absent.
I know that this is not standard in Debian tooling but I find the
approach of Debian's tooling contrary to reasonable cryptographic
protocol design.
I guess a signature you can't verify might be a failed check, but,
really, is a maintainer *actually* going to get as far as git-debpush
without having discovered the signature doesn't verify in their local
environment? They've probably *run* the upstream code by then.
Or to put it another way, a signature that won't verify probably means
that the upload was previously done by another maintainer or on
another system where the right public key *was* available, but it's
not available here and now. It doesn't seem to me that it is likely
to mean "this is an attack and we should stop" or anything like that.
Questions like the ones we discuss above are examples of reasons why
it is a good idea to nail down the spec before writing code. Deciding
on correct behaviour in advance saves rework (and rework is extra
effort and often leads to additional confusion and additional bugs).
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.
