Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.security.misc > #41387 > unrolled thread

Integrität von Git-Repositories?

Back to article view | Back to de.comp.security.misc

Contents

  Integrität von Git-Repositories? Christian Weisgerber <naddy@mips.inka.de> - 2026-05-13 18:10 +0000
    Re: Integrität von Git-Repositories? Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-05-13 22:33 +0200
      Re: Integrität von Git-Repositories? Christian Weisgerber <naddy@mips.inka.de> - 2026-05-13 23:55 +0000
    Re: Integrität von Git-Repositories? Stefan Reuther <stefan.news@arcor.de> - 2026-05-14 09:22 +0200
      Re: Integrität von Git-Repositories? Radio Eriwan <bounce.me@radio-eriwan.ru> - 2026-05-14 12:32 +0300

#41387 — Integrität von Git-Repositories?

Alice spiegelt ihr Git-Repository auf die bekannte Forge von Evil
Corp. Bob klont es von dort. Wie kann sich Bob nun sicher sein,
dass der Inhalt von Evil Corp nicht manipuliert wurde?

Prinzipiell ist ja jeder Commit die Spitze eines Hash-Baums, so
dass bei bekanntem Commit-Hash die ganze vorangehende Geschichte
unantastbar ist, weil bei jeder Änderung entsprechend andere Hashwerte
sich bis zur Spitze fortpflanzen würden. Nur, welche Operationen
_prüfen_ das?

Ein "git fsck" sollte aufspüren, wenn ein Objekt nicht mit seinem
Hash konsistent ist. Aber sonst fällt das nicht auf, oder? Werden
vorhandene Hashes irgendwo nochmal neu berechnet?

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [next] | [standalone]

#41388

Christian Weisgerber <naddy@mips.inka.de> wrote:
>Alice spiegelt ihr Git-Repository auf die bekannte Forge von Evil
>Corp. Bob klont es von dort. Wie kann sich Bob nun sicher sein,
>dass der Inhalt von Evil Corp nicht manipuliert wurde?

Alice sollte ihre Releasetags signiert haben.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#41389

On 2026-05-13, Marc Haber <mh+usenetspam2616@zugschl.us> wrote:

>>Alice spiegelt ihr Git-Repository auf die bekannte Forge von Evil
>>Corp. Bob klont es von dort. Wie kann sich Bob nun sicher sein,
>>dass der Inhalt von Evil Corp nicht manipuliert wurde?
>
> Alice sollte ihre Releasetags signiert haben.

Ja, oder sie steckt Bob den Hash auf einem Zettel zu oder Brieftauben
oder ...

Jetzt weiß Bob, dass der Hash für das Tag unverfälscht ist, aber
das geht an meiner Frage vorbei: Wie kann er sich sicher sein, dass
die Daten im Repository tatsächlich zum Hash passen? Wann/wo/wie
wird der Hash-Baum verifiziert?

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#41390

Am 13.05.2026 um 20:10 schrieb Christian Weisgerber:
> Ein "git fsck" sollte aufspüren, wenn ein Objekt nicht mit seinem
> Hash konsistent ist. Aber sonst fällt das nicht auf, oder? Werden
> vorhandene Hashes irgendwo nochmal neu berechnet?

Scheinbar tut das zumindest das 'checkout' Kommando nicht, man braucht
also 'fsck'.

   git init
   echo -n "hello world" > f.txt
   echo -n "goodbye world" > g.txt
   git add .
   git commit -m "initial"
   cp -f .git/objects/b8/* .git/objects/3b/*
   rm *
   git checkout .
   cat f.txt

...liefert "goodbye, world".

'git fsck' identifiziert aber korrekt einen "hash-path mismatch".


  Stefan

[toc] | [prev] | [next] | [standalone]

#41391

Stefan Reuther wrote:
> Am 13.05.2026 um 20:10 schrieb Christian Weisgerber:
> > Ein "git fsck" sollte aufspüren, wenn ein Objekt nicht mit seinem
> > Hash konsistent ist. Aber sonst fällt das nicht auf, oder? Werden
> > vorhandene Hashes irgendwo nochmal neu berechnet?
> 
> Scheinbar tut das zumindest das 'checkout' Kommando nicht, man braucht
> also 'fsck'.
> 
>    git init
>    echo -n "hello world" > f.txt
>    echo -n "goodbye world" > g.txt
>    git add .
>    git commit -m "initial"
>    cp -f .git/objects/b8/* .git/objects/3b/*
>    rm *
>    git checkout .
>    cat f.txt
> 
> ...liefert "goodbye, world".
> 
> 'git fsck' identifiziert aber korrekt einen "hash-path mismatch".

Mir hat man mal vor Jahren mein Go Code auf GitHub geändert, weil
ich da Spielereien mit SHA256 und dem string 'NSA' gemacht hatte.

Also sind eure Methoden nicht sehr nützlich, im Vergleich zu
yubisigner: https://github.com/Ch1ffr3punk/yubisigner

-- 
Grüße
Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.security.misc

csiph-web