gnurl (libgnurl)

motivation rename using gotchas source downloads building reporting maintainer

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 es könnte für andere verwendbar sein, daher geben wir den Code 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 GNUnet

Große Teile der folgenden 6 Absätze sind alt 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.

Quellkode

Du kannst das Gnurl Git Repository mit folgender Adresse abrufen:

  • git clone https://git.taler.net/gnurl.git
  • git clone git://git.taler.net/gnurl.git

Die Versionen werden als (signierte) Git-Tags aufgenommen.

Herunterladen

Releases werden auf ftpmirror.gnu.org/gnu/gnunet veröffentlicht. gnurl ist über eine Reihe von Verteilungen und Paket-Managern erhältlich. Einige Paket-Manager, die gnurl einschließen, sind: GNU Guix (erhältlich als "gnurl"), Gentoo über die kollaborative ebuild-Sammlung youbroketheinternet,Nix, oder als www/gnurl inpkgsrc.

Benutzung von libgnurl

Wir empfehlen, entsprechende Release-Ankündigungen genau im Auge zu behalten, da sie möglicherweise auf Änderungen bei der Erstellung von gnurl hinweisen.
Falls dein Paket-Manager einen binären Build oder Build-Instruktionen zur Erstellung von gnurl aus mit deiner Systemumgebung automatisierten und integriertem Quellcode zur Verfügung stellt, dann empfehlen wir dringend diesen binären Build zu verwenden.
Es gibt zwei Möglichkeiten, gnurl zu bauen. Bei der ersten Möglichkeit baut man ausgehend vom jüngsten Git-Tag, bei der zweiten verwendet man den verteilten Tarball. Distributoren sollten grundsätzlich vom Tarball aus bauen, aber wir beschreiben hier beide Methoden. Sie sind beide ausgehend von einer NetBSD 9 Benutzerlandschaft geschrieben, mit Ersatztools wo erforderlich.
Du solltest es vermeiden, gnurl von der Spitze des Standard Git-Astes zu bauen, da nur Tags als wirklich sichere und zulässige Builds betrachtet werden können.

Bauen aus dem verteilten Tarball (bevorzugte Methode)

Wenn du die Signatur überprüfen willst, installiere ein OpenPGP-kompatibles Tool wie security/gnupgp2 (und richte es ein). In der Annahme, dass du pkgin verwendest:

  • pkgin update
  • pkgin install gnupg2

Hole dir den Signaturschlüssel von keys.openpgp.org oder über die Kommandozeile mit gnupg2.

Rufe die Version, die Signatur, die Prüfsummendatei sowie deren Signatur ab:

  • ftp https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.65.3.tar.Z
  • ftp https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.65.3.tar.Z.sig
  • ftp https://ftpmirror.gnu.org/gnu.org/gnunet/gnurl-7.65.3.sum.txt
  • ftp https://ftpmirror.gnu.org/gnu.org/gnunet/gnurl-7.65.3.sum.txt.sig

Überprüfe die Signaturen, und verifiziere die Prüfsummen anhand der Prüfsummen in der Datei .sum.txt.

Pack den Tarball aus:

  • tar -zxf gnurl-7.65.3.tar.Z

Wechsele in das Verzeichnis

  • cd gnurl-7.65.3

Jetzt kannst du entweder einen Lauf starten

  • ./configure

, auf direktem Wege, (und lies vorher noch configure-gnurl) oder rufe auf

  • ./configure-gnurl

und übertrage zusätzliche Parameter wie z.B. einen benutzerdefinierten PREFIX-Speicherort. Eine weitere Information kann das www/gnurl Makefile. Führe nun die folgende Kommandos aus

  • make
  • make check (dies ist optional)
  • make install

und du bist fertig.

Aus einem getaggten Git-Commit bauen

Befolge die obigen Schritte, aber anstatt den Tarball herunterzuladen, klone das Git-Tag, aus dem du erstellen möchtest.

Fehler melden

Du kannst Fehler auf unserem Bug-Tracker bugs.gnunet.orgmelden. Alternativ kannst du unsere Bug-Mailingliste verwenden, aber wir ziehe es vor, Bugs auf dem Bug-Tracker zu verfolgen.

Maintainer- und kryptografische Signaturen

gnurl/libgnurl sucht einen neuen Betreuer. Releases nach der Version 7.69.1 und bis zu Version 7.72.0 wurden mit dem OpenPGPKey
0xD6B570842F7E7F8D
unterschrieben (keys.openpgp.or), mit dem Schlüsselfingerabdruck 6115 012D EA30 26F6 2A98 A556 D6B5 7084 2F7E 7F8D
.