On 03/13/18 05:33, Uwe Kleine-König wrote:
>>> But it also has an impact on security: As long as the signature isn't
>>> verified I have to consider the .tar.xz "untrusted" and the less tools I
>>> have to make operate on it the better.  This scheme allows an attacker
>>> that has control over a mirror to provide a .tar.xz that makes unxz do
>>> undesirable things, see https://en.wikipedia.org/wiki/Zip_bomb for an
>>> attack idea.
>> Which is why we provide sha256sums.asc in each directory.
> That would be worth to point out more prominently on the above webpage
> then IMHO.

We do, we have a whole section about sha256sums.asc files:

> When you recompress files you have to resign your sha256sum file, so I
> don't see the advantage "without needing to re-sign all files" you
> mentioned above. 

Released tarballs carry signatures from developers, not from any
automated infrastructure, so you can see how that complicates the
picture if we have to ask Linus or Greg KH to create new signatures for
all tarballs they've ever created.

> (Also recompressing has the immediate downside to break
> third-party tools that rely on unchanged files from upstream, which IMHO
> outweighs the disk space gained from recompressing.)

I would say such tools are wrong because they expect non-normalized
formats to remain constant. I appreciate that I'm basically saying
"everyone is doing it wrong and we're the only ones who are shiny and
smell nice," but I do believe there's at least solid technical reasoning
behind our decision to sign .tar archives and not the compressed versions.

I think it will help you understand the reasoning more if I explain the
workflow behind how releases are currently produced (you can see my talk
about the entirety of the release process here:

1. Linus creates a .tar archive locally on his laptop, using "git
archive" -- which is always deterministic
2. Linus creates a detached signature of that tar archive
3. Linus sends us a very small request with just three things in it

   a. the tag
   b. the prefix to use with "git archive"
   c. the detached signature

4. We use these to create the .tar archive from our version of the tree,
verify it against Linus's detached signature, and if (and only if) the
signature verifies, we create .gz and .xz archives and upload them to
the frontends.

There are the following major benefits behind this process:

1. Linus only has to upload a few KB of data to produce a release,
instead of 200+ MB of combined .xz and .gz archive data. Since he
routinely produces releases while at conferences and remote diving
locations, he greatly appreciates not having to do that.
2. More importantly, if Linus's laptop is compromised and someone tries
to sneak in a trojaned tarball between the time when "git archive"
finishes and "gpg --detach-sign" fires off, the signature verification
will fail when we try to generate the tarball on our end. Any trojans
would need to exist in the git tree, where they have a much greater
chance of being discovered than in a one-off tarball. By using our
current procedure we significantly reduce the risks of workstation
compromises resulting in trojaned tarballs carrying legitimate developer

It's true, we could ask Linus to generate signatures for the .xz archive
on his end, but this would require that he runs "xz -9" on a 600MB
tarball and wait half an hour for it to finish -- and then hope we
produce the same resulting .xz on our end, which is not at all
guaranteed between different xz versions, whereas git has tests that
specifically check that git-archive generated .tar archives are
identical between git releases.

> Also for the attack vector against the decompressor, this effectively
> renders the developer's signature useless because I have to trust the
> sha256sum.asc (and so the archive key) before handing the compressed
> file to the decompressor.
> (Yeah I know, this is harder to exploit than introducing changes to the
> tar archive, but IMHO this is no reason to keep this flaw unfixed.)

I hope I've demonstrated how "fixing" this attack vector opens up a
whole another one that is much, much worse.

> Would it be possible to provide signatures on the compressed archives
> using the same key that today signs sha256sums? I imagine this wouldn't
> result in a significant retooling issue on your side and in return it
> would simplify the handling of signature verification for all those who
> care.

No, because this would pretty much guarantee that people will not bother
checking developer signatures and would just rely on automatically
generated ones. This would violate our grand principle of "trust the
developer, not infrastructure."

I believe our approach has merit and results in better security
protections. To verify the validity of any release you should:

1. Download the tarball and sha256sums.asc
2. Verify the signature on sha256sums.asc using a trusted keyring
3. Verify the tarball hash in sha256sums.asc
4. Decompress the tarball (in a jailed environment, if you like)
5. Verify the developer signature on the .tar file against a trusted keyring

Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to