Re: Summary of the current state of the tag2upload discussion
HW42 <hw42@ipsumj.de> writes:
> Russ Allbery:
>> For the third purpose, I believe only weak intent information can be
>> derived from the uploader signature today. It is common practice in
>> Debian to verify the Git tree that one wants to upload, run a package
>> build step, and then blindly sign the resulting source package. The
>> uploader signature therefore does not say that the uploader verified
>> the correctness of the source package, only that they triggered a build
>> process and trusted its results.
> Assuming they run this on the same system, I don't think that for
> integrity protection the source package build process makes a meaningful
> difference.
Yes, exactly. That is precisely my argument here. The information you
can glean about intent is only that the signer wanted to upload something
based on what they think is the contents of their working tree. Both the
Git tag signature and the source package signature provide equivalent
information for this purpose. Signing the source package itself doesn't,
in practice, make the results of the source package build process any more
reliable.
> It might be a bit easier for someone else to spot a suspect git change,
> but that's far from given.
Agreed.
> Also based on the description in this thread at least for dgit workflows
> you can already generate and check that the uploaded source is
> tree-same.
This is the hope, certainly. I don't know if anyone has written a tool
that does this yet. I'm reluctant to claim that this is definitely true
until someone has tested a tool. There are a lot of things that can go
wrong with reproducible builds, and while I think all the problems can be
overcome, some work may be required.
> Also the code in the source package is not just a hidden artifact that
> is temporarily used during the build. It's surfaced at various places,
> like sources.debian.org, apt-get source, dgit clone, .... So spotting an
> unusual change by accident is possible here too.
I agree with this as well.
>> This is equivalent in the tag2upload case except that the uploader
>> signature happens before the build process (on the Git tag) rather than
>> after the build process (on the source package). In both cases, the
>> uploader does not subsequently verify the content of the source
>> package; in both cases, if the system on which the source package is
>> built is compromised, the source package may be compromised and the
>> uploader signature step will not detect this compromise.
> But you are trusting the Developer system that signs the tag or source
> package anyway. If compromised it can simply sign malicious code in both
> cases.
Yes, I agree.
>> Therefore, for this purpose, the current uploader signature appears to
>> provide stronger evidence of intent than it truly does. The signature
>> on the original Git tag triggering the upload provides equal evidence
>> of uploader intent.
> As described above I'm not convinced by that "intent" argument from a
> security point of view.
I think you thought I was making a different argument than I'm making (and
if I said something that made that confusing, I should fix it). I don't
think the Git tag is more secure than the source package signature. I do
think signing a Git tag makes detection easier, but a compromise of the
uploader's system can still compromise either system.
Injecting the malicious code into the signed Git tree is noisier because
it creates a persistent artifact in more places in a form more likely to
be noticed. That's the only thing I'm claiming is better compared to the
source package signature. Otherwise, I think their security properties
are roughly the same.
> What might be worth mentioning is that verifying the signature by the
> developer on a .dsc or a git tag, can be actually quite involved.
> Especially if you don't want to trust the Debian archive (which some
> seem to see as a feature of shipping the signed .dscs). You first need
> to find out when the signature was made without trusting the included
> timestamps (since they could be faked). Then check the state of the
> Debian keyring at that time. Then check if the key was revoked later.
> Then you can finally check the actually file signature.
Yes. You have exactly the same problem if you want to check the signature
on a source package today. There is no neat universal solution to
verifying the uploader signature in either the current or the tag2upload
design. It's pretty easy to get to a 90% solution and quite difficult to
verify the remaining 10%.
You really want to rely on the archive sources list here, because its
semantics are much cleaner. The scenarios where you cannot rely on it, in
both the current system and in the tag2upload case, get rather complex.
I added this additional paragraph clarifying that a bit earlier today, but
after I posted this draft.
Verifying historical signatures on either a source package or a Git
tag for a package already in the archive has an inherent limitation:
it is not necessarily clear what keyring to use for that verification.
If the uploader is still an active Debian project member, this may be
straightforward. If they are not, this is complex, in identical ways,
for both direct signatures on source packages and Git tag signatures.
It is not possible to verify all uploader signatures in the archive
without using historical keyrings that are not readily available.
> Given this I'm not sure if tag2upload would make it much harder (but yes
> you would need things not on the mirrors, although you already kind of
> need this for checking the timestamps).
In the specific part of the review to which you're responding, I'm arguing
equivalence, not superiority of tag2upload.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: