Discussion of TAP 10: Remove native support for compressed metadata about taps

[JustinCappos]

- Why is it that we had the "compression_algorithms" attribute in the root metadata? Is it because if it was "['gzip']", then you wouldn't trust bzip metadata given to you? OK, I suppose that is somewhat useful, but why the focus on the algorithms? Is it because some compression algorithms are safer than others? Also, what about compression libraries --- wouldn't that also make sense? Where do we draw the line here? - What's the problem with compressed metadata unpacking to unexpected directory or filename? Does the client really have no control over this? Can't the client decompress things to a temp directory and see what comes out? Can compressed files even decompress to absolute file paths? There are a lot of problems with compression libraries in general, ranging

from simple DoS ( https://en.wikipedia.org/wiki/Zip_bomb ) to taking control of the process doing decompression ( https://www.rapid7.com/db/ modules/exploit/windows/fileformat/tugzip ). Unpacking things to odd paths / absolute paths ( https://www.exploit-db.com/exploits/39680/ ) possibly via symlinks ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774660 ) is also a common flaw. Compression code is tricky to write in a way that limits the potential for abuse.

- I don't think the client update workflow is terribly complicated by compression. Timestamp and root metadata must always be available uncompressed. The rest follows from snapshot metadata. I think that's all, right?

To some extent, I agree. Really it is not much different than the way that Uptane supports uniquely encrypted images. You're arguing more broadly that TUF should be responsible for helping implementers handle compression / decompression correctly. The current specification does not do a great job due to outdated text. Another path forward is that we warn about the issue, but avoid specifying this part of the process to let the implementers do what makes the most sense in their domain. TAP 10 proposes the latter approach. The informal feedback we've gotten from different parties indicates that the TAP 10 text removal is preferred over 'fixing' the specification, in part because integrators that implement TUF are not adding this optional support anyways. I'd be happy to hear other perspectives...

[heartsucker]

Related issues for completeness:
theupdateframework/python-tuf#105
theupdateframework/python-tuf#471

[vladimir-v-diaz]

There is additional coverage of TAP 10 in TUF's mailing list. Please see the "Questions regarding verification of compressed metadata" thread here:
https://groups.google.com/d/msg/theupdateframework/I7kI6Wp1A7k/94Ggjr4YAgAJ

In summary, it was decided that top-level metadata should not be compressed in the specification, but adopters are free to handle compression over a different channel/network layer. Snapshot/Timestamp metadata should always reference non-compressed versions of metadata.

TAP 10 will be accepted, and this issue will be closed unless there are any further objections.

[vladimir-v-diaz]

TAP 10 accepted in pull request #65 and commit 87cd913.