From mboxrd@z Thu Jan 1 00:00:00 1970 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Mon, 2 Apr 2018 17:22:48 -0400 Subject: [RFC/PATCH 0/7] Snapshot signatures In-Reply-To: References: Message-ID: On 03/31/18 11:35, John Keeping wrote: > Again, this isn't exactly what Konstantin asked for, but this approach > is easier to implement and I think achieves the main goal of exposing > signatures for snapshots. > > The difference is that this approach has a notes ref for each archive > format and the note simply contains the signature content; there is no > additional metadata you just stick the signature in (for example) > refs/notes/signatures/tar.gz against the relevant tag object. > > This disadvantage of this is that we only support a single signature > format, but I don't think that's a huge drawback as I expect any future > format to be obviously different so that we can easily inspect the > signature content to tell the difference. Thanks for all this work, John! I have a few comments that I think would be useful/relevant. First, something to keep in mind: while "git archive --format tar" will almost always generate the same byte-for-byte content between different platforms/versions of git (it's considered a bug if it doesn't), the same cannot be said about "--format tar.gz". An updated version of libz can create different results. Similarly, someone can pass -9 in their command for a higher compression ratio -- or even use something like zopfli or pigz. This is even worse for xz or bz2, because they are not natively available inside git-archive, so a person would use external compression libraries and we can assume they would use different flags from what cgit would use for the same purpose. Therefore, I consider signatures for compressed versions near-useless, because they will almost certainly no longer work some time after they've been generated, while the goal is to provide tarball signatures that can be used as far into the future as possible. I like the idea of using refs/notes/signatures/[format] regardless what I said above, but with this patch the (sig) links won't show up for .tar.gz downloads, so I'd like to have a way to offer .tar sig downloads for .tar.gz archives. :) Secondly, the signature metadata *has* to include some way of telling the end-user what prefix they should use with git-archive for this to be useful outside of cgit. We don't need to parse this for cgit if we provide snapshot-prefix info elsewhere, so it's just a musing out loud. We can include this info inside the pgp signature comment, which is how I planned to do it: -----BEGIN PGP SIGNATURE----- Comment: X-Git-Archive-Format tar Comment: X-Git-Archive-Prefix linux-4.16/ Comment: X-Git-Archive-Version 2.16.2 [Actual sig data] -----END PGP SIGNATURE----- Using the above should allow anyone to recreate the tarball signature from just the version of the repository without relying on any other info. So, basically, what you have is just fine with me, as long as I can offer a .tar signature for compressed archive versions. Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: