[gnucash-de] Pakete für Debian Sarge: gnucash-hbci nicht vorhanden

[Thomas Viehmann]

Hallo Martin,

vorweg (und Fazit): aus meiner Sicht ist leider die Implementierung der
Gwen-Crypt-Funktionen mit GnuTLS/GCrypt wohl der einzige richtig saubere
Ausweg, sorry.

Martin Preuss wrote:
> Hmm, was mich nur wundert: Ist Gwen denn das einzige Projekt, dass
> gegen OpenSSL linked?? Neben Middleman? Sollen dann alle Projekte
> verschwinden, die OpenSSL verwenden und unter einer GPL/LGPL-Lizenz
> stehen?? Wie steht denn das Team von OpenSSL dazu? Die koennen doch
> gar kein Interesse daran haben, dass eine der Distros alle Projekte
> mit OpenSSL-Verbindung entfernen und dadurch alle von OpenSSL weg
> gehen?
Oh, apache2 ist nicht GPL(?), viele benutzen nur ein wenig SSL, was mit
der Kompatibiltätsbibliothek oft durch einfaches neukompilieren
funktioniert...
Das Problem bei OpenSSL ist wohl, daß das auf SSLeay zurückgeht und
dessen Autoren sich nicht kümmern/nicht erreichbar sind oder was auch
immer. Außerdem scheinen die OpenSSL-Leute eher Apache- als GNU-affin zu
sein.

> Ansonsten: Ich habe mir inzwischen mal libgcrypt angesehen, und es
> scheint den Funktionen von OpennSSL's crypto-Funktionen recht aehnlich
> zu sein, aber eine 1:1-Umsetzung bedeutet schon ein wenig Arbeit...
> Bist Du denn mit Deiner Umsetzung auf Gnu-TLS schon vorangekommen?

So gut war sie nicht, aber das rm *.c gerade war auch kein Fortschritt.
Ich weiß nicht, was in den vier Stunden, die mir jetzt fehlen, war.
Die Kompatibilitätsbibliothek von GnuTLS deckt nicht alle funktionen ab,
die nettransportssl verwendet, insofern ist nicht klar, ob man das nicht
auch "richtig" umstellt.
RSA habe ich noch nicht weiter versucht, das ist scheint mir auch nicht
ganz ohne, wenn man es richtig hinkriegen will.
(Meine Testmethode ist aber auch Debian-Pakete bauen, installieren und
meinen Kontostand abrufen und damit nicht die schnellste... Aehemm.)

> Hmm, mal ne andere Frage: Wie waere es denn, wenn ich den Crypto-Teil von Gwen 
> einfach zu einem Plugin mache? Das Plugin selbst koennte man unter eine 
> OpenSSL-konforme Lizenz stellen, und von Hause aus wuerde Gwen nicht gegen 
> OpenSSL gelinked, waere damit also als Paket erst mal unproblematisch.

Naja. Damit ersetzt man eine (nehmen wir mal an) unsachgemäße
Verbreitungsmethode durch eine mindestens zweifelhafte Umgehungsmethode.
Stell Dir vor, Du würdest eine GPL-Bibliothek mit Stubs für alle
SSL-Funktionen bauen und dann diese nach dem Linken gegen libssl
austauschen... Wäre das besser als gegen libssl zu linken?

> In jedem Fall ist bei mir genau das eingetreten, wovor Debian-legal in der von 
> Christian zitierten Nachricht gewarnt hat: Bei mir bleibt ein sehr schaler 
> Nachgeschmack im Bezug auf Debian (auch wenn ich es seit Jahren nutze und es 
> auch weiterhin tun werde), mir scheint, Debian waere wesentlich dogmatischer 
> als andere Distros. So eine Einstellung vertraegt sich jedenfalls nicht 
> zwangslaeufig mit der Einstellung aller Leute, die OpenSource machen 
> (zumindest nicht mit meiner).

Das Problem ist, daß die Feststellung, hier - zumindest wenn eine Distro
GPL mit libssl verlinkt - liege ein GPL-Verstoß vor, vermutlich richtig
ist. Zugegeben, eine Verfolgung durch einen Rechteinhaber scheint
unwahrscheinlich, aber daß ist dann schon wieder eine andere Sache.

> Hat Debian vielleicht mal bei OpenSSL angefragt, ob die nicht ihre Lizenz 
> anpassen koennten, um damit den sicher nicht wenigen Projekte zu helfen? Wenn 
> Debian da als Distro anfragt, wirkt das sicher anders als wenn ich da als 
> *ein* Projekt nachfrage...
Da haben genug Leute gefragt, als daß es ziemlich weit oben in den FAQs
ist, also glaube ich nicht, daß sich da etwas ändert (so das den
gegenwärtigen OpenSSL-Leuten möglich wäre).

> *Das* waere fuer mich jedenfalls eher geeignet, den Geist von OpenSource zu 
> unterstuetzen als das, was ich auf Debian-Bugs lesen muss...
Das nervt kaum jemanden mehr als mich, leider habe ich den Eindruck, daß
die Hardliner, zumindest was offizielle Debian-Pakete betrifft, recht haben.

Viele Grüße

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/