gnurl (libgnurl)

libgnurl ist eine Mikrogabel von libcurl. Das Ziel von libgnurl ist es, ausschließlich HTTP und HTTPS (sowie nur HTTP 1.x) mit einem einzigen Krypto-Backend (GnuTLS) zu unterstützen, um einen beschränkten Aktionsbereich und ein einheitliches Umfeld für Entwickler sicherzustellen, unabhängig davon wie libcurl zusammengesetzt ist.

Unser Hauptanwendungsfall ist für GNUnet und Taler, aber der Code könnte für andere anwendbar sein, daher geben wir ihn für die breite Öffentlichkeit frei.

libgnurl wird unter derselben Lizenz wie libcurl veröffentlicht. Bitte lies das README für Instruktionen, denn du mußt die richtigen Konfigurationsoptionen beisteuern, um einen korrekten Aufbau von libgnurl zu erreichen.

Über gnurl

Weite Teile der folgenden sechs Absätze sind veraltet und müssen neu geschrieben werden.

Motivation

cURL unterstützt viele Krypto-Backends. GNUnet benötigt die Benutzung von GnuTLS, aber manche Verteilungen nutzen andere Varianten. Falls wir weitere Krypto-Backends unterstützen, würde uns das eine größere Menge an Sicherheitsthemen bereiten, könnte Lizenzprobleme verursachen und vor allem neue Fehler einschleusen, da manche Krypto-Backends bekanntermaßen subtile Laufzeitprobleme verursachen. Obwohl es möglich ist, zwei Versionen von libcurl auf dem gleichen System zu installieren, stellt dies eine Fehlerquelle dar; tatsächlich können mögliche Fehler sehr fein sein, falls wir gegen die falsche Version gelinkt sind.

Für GNUnet benötigen wir auch eine besonders moderne Version von GnuTLS. Folglich würde es ohnehin erforderlich sein, cURL für GNUnet neu zu kompilieren. Aber was passiert, wenn man cURL gegen diese Version von GnuTLS linkt? Nun, zuerst würde man GnuTLS manuell im System installieren. Dann bauen wir cURL. cURL wird problemlos dagegen linken, aber der Linker wird irgendwann größere Probleme vermelden. Der Grund ist, daß cURL auch gegen eine Vielzahl anderer Systembibliotheken linkt (gssapi, ldap, ssh2, rtmp, krb5, sasl2, siehe die Diskussion über obskure Protokolle oben), die --- da sie bereits in der Distribution enthalten wurden --- gegen eine ältere Version von GnuTLS gelinkt sind. Daraus folgt, daß dieselbe Binärzelle gegen zwei verschiedene Versionen von GnuTLS gelinkt würde. Damit ist die Katastrophe vorprogrammiert. Folglich ist es erforderlich, um die Notwendigkeit der Aktualisierung dutzender Systembibliotheken zu umgehen (und dann auch noch jeweils zwei Versionen davon zu installieren), alle cURL-Merkmale, die GNUnet nicht verwendet, außer Kraft zu setzen. Davon gibt es übrigens viele. Bei GNUnet sind die eher obskuren Protokolle, die von cURL unterstützt werden, fast toter Code --- meistens harmlos, aber nicht nützlich. Da jedoch irgendwelche Applikationen irgendeins dieser Features verwenden könnten, werden die Verteilungen typischerweise gezwungen, alle diese Features zu aktivieren und damit auch die Sicherheitsprobleme einzuladen, die durch den Code auftreten könnten.

Um also eine moderne Version von GnuTLS zu verwenden, besteht ein sinnvoller Ansatz darin, alle "optionalen" Funktionen von cURL zu deaktivieren, die in Systembibliotheken ziehen, die mit dem älteren GnuTLS-System verknüpft sind. Das funktioniert, man sollte dann nur NIE die Version von libcurl in say /usr oder /usr/local installieren, weil dadurch andere Teile des Systems, die vielleicht auf die soeben deaktivierten Funktionen angewiesen sind, außer Betrieb gesetzt werden. Libtool-Versionierung hilft hier nicht, da sie nicht für den Umgang mit Bibliotheken mit optionalen Funktionen vorgesehen ist. Selbstverständlich ist es ebenso problematisch, cURL anderswo zu installieren, denn wir müssen genau aufpassen, daß der Linker GNUnet gegen die richtige Version linkt. Man beachte, daß dies alles auch keineswegs einfach von den cURL Entwicklern gelöst werden kann.

Umbenenung als Lösung

How does forking fix it? Easy. First, we can get rid of all of the compatibility issues --- if you use libgnurl, you state that you don't need anything but HTTP/HTTPS. Those applications that need more, should stick with the original cURL. Those that do not, can choose to move to something simpler. As the library gets a new name, we do not have to worry about tons of packages breaking as soon as one rebuilds it. So renaming itself and saying that "libgnurl = libcurl with only HTTP/HTTPS support and GnuTLS" fixes 99%% of the problems that darkened my mood. Note that this pretty much CANNOT be done without a fork, as renaming is an essential part of the fix. Now, there might be creative solutions to achieve the same thing within the standard cURL build system, but this was deemed to be too much work when gnurl was originally started. The changes libgnurl makes to curl are miniscule and can easily be applied again and again whenever libcurl makes a new release.

Benutzung von libgnurl

Projekte, die cURL nur für HTTP/HTTPS verwenden und mit GnuTLS funktionieren würden, sollten in der Lage sein, zu libgnurl zu wechseln, indem sie "-lcurl" in "-lgnurl" ändern. Mehr nicht. Es sollten keine Änderungen am Quellcode nötig sein, da libgnurl eine Fehler-zu-Fehler-Kompatibilität mit den HTTP/HTTPS/GnuTLS-Untergruppen von cURL anstrebt. Wir könnten zu dieser wesentlichen Untergruppe neue Funktionen hinzufügen, falls solche vorgeschlagen werden, aber bislang haben wir unsere Änderungen auf ein Mindestmaß gehalten, und keine Ergänzungen zum ursprünglichen curl-Quellcode wurden bislang geschrieben.

Aufgepasst!

libgnurl und gnurl sind nicht als Curl-Ersatz für Nutzer gedacht:
Das heißt nicht, es mangele an Vertrauen in mit gnurl produzierten Arbeitsergebnissen, sondern trägt der Tatsache Rechnung, dass Werkzeuge, die Curl oder libcurl erwarten, nicht auf anders benannte Binäre und Bibliotheken zurückgreifen. Solange du weißt was du tust solltest du in der Lage sein, gnurl als Teil deiner Systemgestaltung anstelle von Curl zu verwenden. Allerdings empfehlen wir nicht so vorzugehen, da der einzige getestete Einsatz als Teil des Taler's Bausystems ist.
Da keinerlei Konflikte in Dateinamen auftreten wird nicht erwartet, dass du Curl entfernst, um gnurl zu verwenden, oder umgekehrt.