Re: Umgang mit Dubletten

[Philipp Schafft <lion@xxxxxxxxx>]

reflum,

On Thu, 2009-08-20 at 23:24 +0200, Raphael Becker wrote:
> On Thu, Aug 20, 2009 at 06:47:19PM +0200, Werner Holtfreter wrote:
> > Also Softlinks! Aber wie? Vielleicht sollte man mehrfach benoetigte 
> > Dateien grundsaetzlich in ein Verzeichnis "SHARED" auslagern, um 
> > unbedachter Loeschung vorzubeugen?
> 
> Wie waere es mit folgender Idee:
> 
> Jede Datei, die als "schuetzenswert" gilt wird anhand ihres Contents
> indexiert, dabei bieten sich  Hashverfahren wie md5 oder sha256 an.

Da Hashes nicht kollisionsfrei sind muss hier fuer eine hohe
kollisionsischerheit gesorgt werden. Deswegen wuerde ich dazu raten die
kombination zweier hashes zu nehmen die nicht auf basis der selben
grundlage arbeiten. Beispielsweise ein hash aus der SHA-2 Familie und
ein TIGER order Wirlpool. Beide dann einfach zu einem string zusammen
setzen. Solange die Verfahren bekannt sind ist druch die laenge das
spaeder wieder auseinander teilbar, oder im zweifel ein '-' oder
aehnliches trennzeichen benutzen.

Zum anderen kann ich nur von der verwendung von MD5 *in allen bereichen*
abraten. Es gibt *nichts* wo es besser geignet ist als ein anderer Algo
und er zeigt seit jahren viele schwechen. Die Kollisionsicherheit ist
mitlerweile stark zusammen gebrochen. Nicht nur bei geziehlten
angriffen. Habe mitlerweile in meinem leben zwei zufaellige MD5
kollisionen erzeugt von denen ich weiss. Deswegen wuerde ich fuer neu zu
entwerfende system extremst stark von diesem hash abraten.

Wer klaubt das die kollisions sicherheit 1:2^bits ist sollte vieleicht
einmal in passender literatur nachlesen.

> Weitere Methoden zur Signierung oder Verschluesselung von Dateien im
> Repository seien hier nur erwaehnt aber nicht weiter ausgefuehrt. 

Hier moechte ich kurtz darauf hinweisen das OpenPGP in nahe zu allen
packeten fingerprints erzuegt/erzeugen kann. Diese intern genutzten
hashs koennen bsp. genauso verwendet werden wie das obige. Wenn soetwas
also gewuenscht ist kann man sich hier vieleicht deutlich rechenleistung
einspaaren wenn man hashes nicht doppelt berechnet.


> [...]
> stattdessen streng anhand von eindeutigen Merkmalen wie Checksummen
> operieren sollte, wenn moeglich *ausserhalb* der Umgebung, auf der
> aktiv gearbeitet wird.

Hier nochmal der hinweis auf das obige.


> Nur eine Idee.
> 
> Achso, Thema Doubletten: Die Treten im Repo nicht auf, koennen aber im
> Homeverzeichnis entstehen. Aber automatisch darf man sie nicht einfach
> durch Hardlinks de-duplizieren wenn nicht sicher gestellt ist, dass die
> Datei Read-Only ist, sonst aendert sich der Inhalt der Datei ungewollt
> auch fuer andere Stellen (bei Hardlinks). 

Dies ist leider ein Design Fehler bei den meisten Betriebssystemen: Es
gibt keine copy-on-write hardlinks wie man es beispielsweise vom
Addressraum eines prozesses her kennt. Es gibt ein paar Systeme die das
zumindestens teilweise koennen.


-- 
Philipp.
 (Rah of PH2)
--
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/