[gnucash-de] GoB und Buchungen nicht mehr veränderbar machen

Thilo Pfennig tp at pfennigsolutions.de
Sa Feb 9 10:23:03 EST 2008


Am Thu, 31 Jan 2008 15:04:35 +0100
schrieb Frank Nagel <gnucash at fkn-systems.de>:

> Einzigste Möglichkeit ein Datei-Inhalt(!) vor Veränderungen zu
> schützen ist die Verwendung von Verschlüsselung, aber mindestens der
> Schlüsselinhaber kann dann wieder manipulieren.

Nope, wie schon gesagt. Hier noch mal der Unterschied:

 a ) Verschlüsselung dient dazu einen Inhalt unlesbar zu machen und z.B.
nur berechtigten Personen den Lesezugriff zu ermöglichen (durch
Passworteingabe), das wird z.B. in dem Thread "Datei Password vergeben
zum Öffnen bzw. gegen unberechtigtem" diskutiert. 
 b ) Signierung dient dazu einen Inhalt mit einer eindeutigen Signatur
zu versehen. Der Inhalt wird nicht verschlüsselt, kann aber durchaus
auch verschlüsselt sein. Es geht hier darum, das man in der
Lage ist zu sehen, ob ein Inhalt von einer bestimmten Person stammt
und/oder das man eben davon ausgehen kann, das der Inhalt nicht
verändert wurde nach dem Vorgang des Signierens.Verwendet wird die z.B.
bei GPG-signierten Emails. D.h. Du kannst dann die Signatur überprüfen
und wenn jemand dazwischen den Inhalt verändert hat sagt Dir Dein GPG
das die Signatur ungültig ist.
 

> Die Forderungen des FA in der GoB sind somit eh nur 'Augenscheinlich',

Was mich vermuten lässt, das das ganze eigentlich gar keine Bedeutung
hat.


>   a) dauernd dran geändert wird
>   b) jeder (Dank OSS) dran' rumfummeln' kann
>   c) eigenlich niemand die Gemeinschaft der Programmierer vertreten
> kann d) ein Haftungsanspruch gegenüber ?Wem? nicht durchgesetzt
> werden kann

a) Wird ja nicht. Ausserdem kann man die Zertifizierung auch nur für
alle paar Jubeljahre anstreben. Vielleicht einen konservativere Branch
machen, wo es primär geht um Konformität, Datenschutz,
Nachprüfbarkeit,... ?

b) Stimmt nicht. Die eingereichten Patches und Commits werden vorher
geprüft. Ein bestimmter SVN-Checkout sollte z.B. eindeutig
identifizierbar sein, z.B. MD5/SHA1-Summe des Archivs?

c) Letzlich gehts ja nur darum die Software zu zertifizieren.
Haftungsansprüche gegen Software sind sowieso nur auf dem Papier
vorhanden. Natürlich führt Software zu Datenverlusten - man nenne mir
aber mal einen Fall bei dem es zu einer Klage kam und nur ein einziger
Kläger damit Erfolg hatte. Zudem: Haftung gegenüber was?


> Wenn dann noch jemand aus der Liste Kontakt zur FreeSoftwareFoundation
> (oder wie die heissen) oder dem CCC herstellen kann, um die auch mal
> zu Wort kommen zu lassen, ist GC schon ein ganzes Stück weiter.

Bezüglich was? Also CCC hat mit Freier Software nichts zu tun - und die
FSF... was soll die jetzt wozu sagen? Wie lautet die Frage?


> Mit genügend Kapital würde ich eine/n Firma/Gesellschaft/Verein
> gründen, welcher die Interessen von GC gegenüber der/dem
> FA/Öffentlichkeit/Gewerbetreibenden vertritt.

Also was die FSF macht ist, wenn man ihr das Copyright überlässt, das
sie die Interessen der Programmierer bei Verletzung der GPL vertritt.
Aber auch nur auf dem Papier. Das tut dann eher gpl-violations.org.
Aber darum gehts hier ja eigentlich nicht.


Gruß,
Thilo