[RFC/PATCH 0/7] Snapshot signatures

[konstantin at linuxfoundation.org (Konstantin Ryabitsev)]

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: <http://lists.zx2c4.com/pipermail/cgit/attachments/20180402/1de27890/attachment.asc>