Il 03/07/2017 04:14, Eli Schwartz via arch-general ha scritto: > > So I was under the impression that git tags encode the tagname in the > actual blob, and I didn't see how that attack (rooted in the basic > nature of a branch as a lightweight, mutable, *pushable* pointer to a > commit) was supposed to work unless of course it was talking about a > lightweight tag (which is not really meant for public/permanent use)... > > Having actually tested this out, I find myself quite bewildered. > > Because, git *does* encode the tagname in the blob, like I thought. > And... you *can* simply copy .git/refs/tags/tagname to create a fake > tag, and then you see something quite bewildering: > > ``` > [eschwartz@arch ~/git]$ git clone https://github.com/systemd/systemd > [...] > [eschwartz@arch ~/git]$ cd systemd > [eschwartz@arch ~/git/systemd]$ echo "$(git show-ref -s v233)" > > .git/refs/tags/v232 > [eschwartz@arch ~/git/systemd]$ git tag -v v232 > object d60c527009133a1ed3d69c14b8c837c790e78d10 > type commit > tag v233 > tagger Lennart Poettering <lennart@xxxxxxxxxxxxxx> 1488405946 +0100 > > systemd 233 > gpg: Signature made Wed 01 Mar 2017 05:05:46 PM EST > gpg: using RSA key B63B21879C3485B0 > gpg: Good signature from "Lennart Poettering <lennart@xxxxxxxxxxxxxx>" > [unknown] > gpg: aka "Lennart Poettering <lennart@xxxxxxxxxxxxx>" > [unknown] > gpg: aka "Lennart Poettering (Red Hat) > <lpoetter@xxxxxxxxxx>" [unknown] > gpg: aka "Lennart Poettering (Sourceforge.net) > <poettering@xxxxxxxxxxxxxxxxxxxxx>" [unknown] > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Primary key fingerprint: 63CD A1E5 D3FC 22B9 98D2 0DD6 327F 2695 1A01 5CC4 > Subkey fingerprint: 16B1 C4EE C0BC 021A C777 F681 B63B 2187 9C34 85B0 > ``` > > I simply do not understand why git doesn't error when it sees that a tag > ref named v232 points to a tag blob named v233. The information is all > there, and it seems trivial to add a check. > > Oh well, one more reason to use commit hashes rather than pkgver tags. > (The other reason is, because upstreams themselves are quite capable of > modifying tags and re-signing them without waiting for some attacker to > play with the ref pointers.) > > Anyway, I learned something today. > I think I can reply to this. Just skip if not interesed to last part. """Thanks""" to a lab of a class I had the previous semester, I can describe you exactly how Git blobs are... There are: - normal *blob*s: standard files compressed using Deflate, have only a small special header at the top - *tree*s: a specially encoded file, pointing to blobs or other *tree*s... call them *blobbed directories* - *commits*: another deflated file, keeping the commit message and a reference to a *tree*. To be 100% I made one just now to check and I can say that we have - *tags*: a plain file referring to a commit object You see the point: you just renamed a text file pointing others. Unless you change the commit binary file (doing this won't pass the gpg check) or fake the whole .git blobs, it will point to the v233 commit and all the stuff below it. If you are instead saying that Git should notice that the file in the refs folder is named improperly, just `man git` and see what *git* is :P :D tl;dr: Too much an hassle; destroying a Git repo is easy, faking it is not. P.S. Thanks to that class, we made some Java classes to handle Git blobs, check them if you want: https://gitlab.com/ItachiSan/lab01/ -- Giovanni Santini My blog: http://giovannisantini.tk My code: https://git{hub,lab}.com/ItachiSan My GPG: 2FADEBF5
Attachment:
signature.asc
Description: OpenPGP digital signature
