[gnucash-de] Sicherheit für Nicht-Programmierer

Mark MarkSchuppert at gmx.de
Don Nov 23 16:26:26 EST 2006


Zunächst einmal: Vielen Dank für diese umfassende Antwort. Sie zeigt
IMHO einen wesentlichen Vorteil von OSS Software - hier steht der
Entwickler *persönlich* für sein Programm ein. Bei closed Source wohl
unvorstellbar... Aber auch bei OSS nicht selbstverständlich - daher noch
einmal ausdrücklich vielen Dank.


Am Mittwoch, den 22.11.2006, 14:34 +0100 schrieb Christian Stimming:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hallo,
> 
> erstmal danke für die Blumen bzgl. Vorteile in GnuCash.
> 

Liegt auf der Hand! - Wenn ich es recht verstehe, kann ich doch über
HBCI die Umsätze meines Girokontos in gnucash laden und brauche sie dort
nur noch mit den Unterkonten verbuchen, nicht wahr? 
Einfacher kann es nicht sein, einen Überblick über seine Finanzen zu
gewinnen.  

> Mark schrieb:
> > Aber: Soll ich dem unsere Finanzen überlassen? 
> > Selbst wenn ich den Sourcecode lesen könnte - das Gnucash-Paket hat
> > einen Umfang, der die Möglichkeiten zur Kontrolle eines Einzelnen
> > zweifellos übersteigt (9 MB als tar.gz!). Wie kann ich dann davon
> > ausgehen, dass kein Schadcode darin ist? 
> 
> Als normaler Nicht-Programmierer kannst du das bei Open-Source nicht,
> genausowenig wie bei jeder Closed-Source Software. Du kannst lediglich
> bei Open-Source zusätzlich den Entwicklungsprozess im SVN-repository
> beobachten [1] und dem dort stattfindenden gegenseitigen "peer review"
> des Programmcodes vertrauen, also der Tatsache, dass jeder Code in
> gnucash von mehreren fitten Programmierern begutachtet wird (z.B. von
> Derek, David, Chris, Josh und mir).
> 
> > Vielleicht von einem "bösen" Sourceforge-Spiegelbetreiber?
> 
> Das Angriffsszenario des eingeschleusten Schadcodes in einem *Mirror*
> ist eine völlig andere Frage als der Schadcode im eigentlichen SVN. Die
> Abhilfe für den "paranoiden" User wäre hier, den Programmcode selber
> direkt aus dem SVN zu ziehen [2] anstelle einen fertigen tarball von
> einem mirror - dann hat man zumindest die Garantie, dass der Code
> identisch ist mit jenem, den die Entwickler auch tatsächlich selber
> entwickelt haben.
> 
Hm, damit würde ich tatsächlich mehr Sicherheit erreichen. Würde halt
ein bisschen mehr Gefummel bedeuten... 


> > HBCI überläßt gnucash AqBanking, las ich. Dieses Paket stammt von ubuntu
> > - aus einem universe repository. Es gibt daher keinen, der mir für die
> > Binaries garantiert - würde ich sie selber übersetzen, wäre mir der Code
> > ebenso unverständlich wie die gnucash sources.
> 
> Gleiches Szenario hier: Der Code aus dem SVN kann von jedem selber
> geholt werden [3] und das würde eine Manipulation durch einen Mirror
> ausschließen. Wie auch bei GnuCash ist hier die Kontrolle des
> Sourcecodes durch einen Nicht-Programmierer genausowenig möglich (sowohl
> bei Open Source als auch bei Closed Source), aber du kannst bei Open
> Source halt den Entwicklungsprozess beobachten und dir dazu eine Meinung
> bilden. Bei Closed Source siehst du nur das, was dir die
> Marketingabteilung erzählen möchte.
> 
> > Es fehlt mir hierbei jemand, den ich haftbar machen kann - denn den Code
> > kann ich selber nicht kontrollieren. 
> 
> Ich bezweifle stark, dass du bei kommerzieller/Closed-Source Software
> tatsächlich einen Hersteller für irgendeinen Schaden haftbar machen
> könntest, aber das soll mir ja auch egal sein. Im Open-Source Fall
> bekommst du das Programm jedenfalls als Schenkung [4] überlassen, und
> damit sind nach deutschem Recht die Hersteller (=die anderen
> Programmierer und ich) bei Vorsatz oder grober Fahrlässigkeit haftbar,
> ansonsten aber nicht. Wenn also kein Vorsatz (z.B. eigenes absichtliches
> Einfügen von Schadcode) oder grobe Fahrlässigkeit (z.B. SVN-repository
> mit Schreibzugriff für die ganze Welt) vorliegt, haftet der Hersteller
> hier gesetzlich nicht. Inwieweit ein kommerzieller Hersteller hier
> gesetzlich mit mehr Haftung einstehen muss (und entsprechende
> Haftungsausschlüsse der jeweiligen EULA dann unwirksam sind), ist mir
> relativ egal.
> 
> > Im Falle eines Schadens müßte ich
> > nachweisen, dass ich nicht leichtfertig mit den Bankdaten und der
> > Bankingsoftware umgegangen bin. 
> 
Natürlich sind es zwei paar Schuhe ob ich meine Pins/Tans bei den
Kontoauszügen oder im Tresor aufbewahre. Ähnlich könnte aber doch auch
eine Bank unterscheiden ob ich die dort erstandene und als
vertrauenswürdig eingestufte Software benutze oder ein von "irgendwo"
aus dem Internet gezogenes Programm. Allerdings stimmt, was du weiter
unten über die AGB schreibst - die Bank erwähnt dort mit keiner Silbe,
dass sie die Benutzung einer bestimmten zertifizierten Software
voraussetzt. Es gibt bei meiner Bank einen interessierten Mitarbeiter -
den werde ich mal auf diese Problematik ansprechen. 

Zur Zeit nutze ich - das mag jetzt vielleicht überraschend sein -
bereits OSS für mein Banking. Naja, zunächst war da ja Firefox im
Pin/Tan Verfahren. 
Nun nutze ich MoneyPenny. Der Unterschied zu z.B. Gnucash ist dabei,
dass ich es kaufen mußte - was ja an sich kein Vorteil ist. Mit der
Rechnung (Adresse etc des Autors) erhielt ich dort eine "geprüfte" CD.
Der Autor übernimmt also in einer für mich viel leichter nachweisbaren
Form Verantwortung für die Software - auch wenn sie unter GPL steht und
die Haftung damit ebenfalls eingeschränkt ist. 



> Na ja. Das ist doch schon wieder eine neue Frage. Du müsstest hier
> genauer definieren, was mit "Schaden" gemeint ist -- und dann hängt es
> eben doch von der Bank und deren Online-Banking-AGB ab, wer hier für
> welchen Schaden unter welchen Bedingungen einstehen muss. Die mir
> vorliegenden HBCI-AGB hab ich bisher immer so verstanden, dass sie
> relativ kundenfreundlich sind - es stehen da z.B. keine harten Kriterien
> über die notwendigen Überprüfungen der Software drin. Also sehe ich mich
> durch die HBCI-AGB meiner Bank keineswegs irgendwie unter Druck gesetzt,
> dass *ich* beweisen müsste, dass meine Software nicht manipuliert worden
> ist.
> 
> > Doch wie kann ich davon ausgehen, dass
> > die Software sicher ist, wenn sie doch aus mehren Quellen
> > zusammengestellt ist?
> > 
> > Wie haltet ihr es mit gnucash und HBCI? Woher kann ich die Sicherheit
> > bekommen, dass mit dieser Kombination sicheres - oder gar "sichereres"
> > Homebanking möglich ist? 
> 
> "Sicher" kannst du nicht sein. Du kannst lediglich eine Abwägung
> zwischen deiner Bequemlichkeit und der Restwahrscheinlichkeit einer
> Manipulation treffen. Jeder der beteiligten Mirrors wiederum weiß
> natürlich, dass er schon nach einer einzigen Manipulation sein Vertrauen
> verspielt hätte, und kümmert sich deshalb allein schon aus
> Selbsterhaltungstrieb um eine geringstmögliche
> Manipulationswahrscheinlichkeit...
> 
> Meine eigene Abwägung hab ich getroffen, und deswegen programmiere und
> benutze ich diese Software und mache mich nicht weiter verrückt wegen
> der existierenden Restwahrscheinlichkeit einer Manipulation.
> 
> Gruß
> 
> Christian Stimming
> 
> [1] http://svn.gnucash.org/trac/timeline
> [2] http://wiki.gnucash.org/wiki/Subversion
> [3] http://article.gmane.org/gmane.comp.finance.aqbanking.devel/839
> [4] Da halte ich es mit Volker Grassmuck, http://freie-software.bpb.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iQCVAwUBRWRSAGXAi+BfhivFAQKVBAP7Bm66zsWAyjXfYI8hYLF+Rv4IO2loTtrz
> V003DslO7CsqbO1gDp4VWeuujRhAWGhfPJp+fd+umYyyLoeL6fpGPmQkRVREPjEe
> eo+wzLio3ZA/n5u8hpEtxL7DZFUC/iSwjiPdIMe+r0VkqoctkNczwB/BbiNz+DqR
> MWf/5dgiCoc=
> =FzDD
> -----END PGP SIGNATURE-----
> _______________________________________________
> gnucash-de mailing list
> gnucash-de at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-de