Jak działa podpisywanie commitów?

Obecnie zastanawiam się, w jaki sposób podpisywanie git commit dokładnie działa.Jak działa podpisywanie commitów?

Próbowałem to znaleźć, ale nie mogłem znaleźć dokładnej dokumentacji technicznej. Jestem świadomy, jak robić podpisywanie git commit, ale zastanawiam się, co dokładnie robi git, aby podpisać commit.

Czym dokładnie jest podpis? Czy jest to pełne dane w repozytorium przy danym zatwierdzeniu, więc dane takie jak komunikat zatwierdzenia itp. I dane wszystkich plików? Czy jest to tylko zatwierdzenie ze wskaźnikami do zawartych plików itp.?

Źródło

2017-02-24 Markus Kreusch

Pytasz o [podpisanych tagów] (https://git-scm.com/docs/git-tag#git- tag - s)? – Leon

https://help.github.com/articles/signing-commits-with-gpg/ –

@Leon: Jestem prawie pewien, że chce wiedzieć, jakie dane są dostarczane do GPG. Staje się to bardziej interesujące w przypadku ostatniej wersji demonstracyjnej, w której zostały utworzone zderzenia SHA-1. – torek

Chociaż nie jest to nigdzie udokumentowane, badanie source code pokazuje, że jest to cała zawartość obiektu commit. Zawartość ta zostaje następnie zmodyfikowana, tak aby proces weryfikacji musiał odciąć podpis w oddzielnym buforze i przekazać oryginalne, wstawione przed podpisaniem dane do podpisu GPG.

Dane podpisu GPG mają następnie miejsce podczas obliczania sumy kontrolnej SHA-1 dla zatwierdzenia, aby stać się hashiem zatwierdzenia. Zobacz kolejno: gpg-interface.c i commit.c, funkcje sign_buffer i do_sign_commit. Podpisywanie tagów jest w builtin/tag.c (patrz funkcja do_sign i jej wywołujący); Tagi podpisane mają własne podpisy, a nie wstawiane, ale poza tym działa to w podobny sposób.

Źródło

2017-02-24 18:54:52 torek

Twoje założenie, o które pytałem zainspirowane przez wersję demonstracyjną SHA-1 było poprawne;) Tylko dla pewności zrozumiałem kod poprawnie (ja jestem raczej Javą, nie facetem C). Zatwierdzany jest tylko obiekt commit zawierający odwołanie do drzewa SHA-1. Więc jeśli mam podpisane zatwierdzenie, nie mogę mieć pewności, że drzewo jest poprawne, ale tylko to, że osoba podpisująca utworzyła zatwierdzenie dla drzewa z tym samym hash? To naprawdę smutne ... –

@MarkusKreusch: tak, podpis * bezpośrednio * chroni tylko zawartość obiektu commit lub tag. Jednak obiekty commit i tag mają dość oczywistą formę (pomimo tego, że mogą zawierać dowolny tekst), a istniejąca technika do pokonania SHA-1 pozostawia oczywisty ślad. Obiekty drzewa mają jeszcze bardziej ograniczoną formę: Git może (i powinien już) łatwo wykryć zniekształcone drzewa. Tylko obiekty typu blob są naprawdę przedmiotem ataków wtórnych. Wszystko, co powiedziałem, byłoby fajnie, gdyby Git mógł zacząć używać SHA-256, ale przejście będzie raczej trudne. – torek

(Zobacz także http://stackoverflow.com/q/42433126/1256452 i link do listy mailingowej.) – torek

Jest to surowy obiekt commit, który został zwrócony przez git cat-file (z usuniętym podpisem), który jest podpisany. Jeśli HEAD jest podpisana popełnić można zweryfikować podpisu przez strony w następujący sposób:

git cat-file commit HEAD > signed-commit 
grep -B 9999 'BEGIN PGP SIGNATURE-----' signed-commit | head -n -1 > signed-commit.stripped 
grep -A 9999 'END PGP SIGNATURE-----' signed-commit | tail -n +2 >> signed-commit.stripped 
sed 's/^gpgsig //' signed-commit | sed 's/^ //' > signed-commit.sig 
gpg --verify signed-commit.sig signed-commit.stripped

Źródło

2018-02-24 16:08:36 MMGen

Odpowiedz

Powiązane problemy