On Mon, 1 Jul 2024 at 11:33, Matthias Urlichs <matth...@urlichs.de> wrote:
>
> On 30.06.24 21:30, Aigars Mahinovs wrote:
>
> The Debian developer/maintainer creates a signed git tag that contains
> (in its message, presumably, to avoid adding new communication lines)
> the file listing of the git checkout at the point of signing
> (including file names, modes and short SHA checksum hashes). This
> extra content is added at the end of the tag message,
>
> OK, maybe I'm just not getting it, but the tag *already* contains the file
> listing you want to add to the tag, implicitly: it refers a commit which
> refers a tree which refers to exactly those files.
>
> If it ever does not, then we'd all have _way_ worse problems than figuring
> out how to safely create a t2u tag.
>
> So what would this actually buy us, in terms of additional safety?
Yes and no. See what the git tag actually contains and what the GPG
signature actually signs is just the one hash of the commit object.
This commit object then refers to the other files of the repo, but the
GPG signature does not directly sign those.
I just did a local experiment to verify this. I created a new signed
tag in one of my repos.
$ git tag -s -m "test signed tag" 24w27.1-1
Then I inspected the result with this command:
$ git cat-file -p 24w27.1-1
object 4d0e377e992901f873bfca5850eb8862b9a1f057
type commit
tag 24w27.1-1
tagger Aigars Mahinovs <aigars.mahin...@bmw.de> 1719829010 +0200
test signed tag
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQSeqa3XEFMtCKeITWHKWshbVxu0FgUCZoKCEhccYWlnYXJzLm1h
aGlub3ZzQGJtdy5kZQAKCRDKWshbVxu0Fq4fAQDSySaFH9ytCr70i+Bs0MxfPDRt
BQ4O9Xp9JCoXnrVsiAEA/i8CUFqSlU51fy1UL6YTPC/O4pq1QUYcVJP7X9V5FAo=
=r+o7
-----END PGP SIGNATURE-----
That looks like simple text and detached GPG signature. So to check
that I split the text part and the signature part into two files:
```
object 4d0e377e992901f873bfca5850eb8862b9a1f057
type commit
tag 24w27.1-1
tagger Aigars Mahinovs <aigars.mahin...@bmw.de> 1719829010 +0200
test signed tag
```
and
```
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQSeqa3XEFMtCKeITWHKWshbVxu0FgUCZoKCEhccYWlnYXJzLm1h
aGlub3ZzQGJtdy5kZQAKCRDKWshbVxu0Fq4fAQDSySaFH9ytCr70i+Bs0MxfPDRt
BQ4O9Xp9JCoXnrVsiAEA/i8CUFqSlU51fy1UL6YTPC/O4pq1QUYcVJP7X9V5FAo=
=r+o7
-----END PGP SIGNATURE-----
```
And running `gpg --verify` with those two files showed a good
signature. This confirmed my theory that the git tag signature nothing
more than a signature on this exact text that we see above.
It signs the commit object hash, tag name, tagger identity and
whatever is in the tag message.
Just dumping the output of `git cat-file -p ${tagname}` would provide
a way of verifying the uploader signature even without git.
And including the output of `git ls-files ...` in that message would
both provide a non-git way of matching this tag to the tarball and
would additionally extend the scope of the GPG signature to hashes of
all files in the repo checkout directly, without going through
multiple hash object jumps in the git object hierarchy.
As far as I can see doing things this way provides for a rather simple
verification pathway that does not involve running git or parsing git
objects. It's easier to reason about this compared to rather complex
git internals. Can even be done in a shell script.
Does this actually prevent or make herder any attack vectors right
now? I don't think so.
However, implementing it this way does give us options later, for
example if `git ls-files` gets an ability to print stronger checksums
of files we can switch to use that and gain stronger checksum benefits
even if the git repo itself remains based on the current checksumming
scheme. If we (later) agree to require that the maintainer has not
only git and gpg installed locally but also sha512sum binary, for
example then the client command line can be later changed so that it
uses that binary to create checksums of all files instead of using
checksums that git already has. Same for another (not invented yet)
hashing algorithm. And all without having to change git internal data
structures for all the repos.
--
Best regards,
Aigars Mahinovs mailto:aigar...@debian.org
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#
