1 files changed, 175 insertions, 0 deletions
diff --git a/template/gnurl.html.j2 b/template/gnurl.html.j2
new file mode 100644
index 00000000..dbfbe757
--- /dev/null
+++ b/template/gnurl.html.j2
@@ -0,0 +1,175 @@
+{% extends "common/base.j2" %}
+{% block body_content %}
+<div class="container-fluid">
+  <article>
+    <h1>{{ _("gnurl (libgnurl)") }}</h1>
+    <p>
+      {% trans %}
+      libgnurl is a micro fork of libcurl. The goal of libgnurl
+      is to support only HTTP and HTTPS (and only HTTP 1.x) with
+      a single crypto backend (GnuTLS) to ensure a small footprint
+      and uniform experience for developers regardless of how
+      libcurl was compiled.<br>
+      Our main usecase is for GNUnet, but it might be usable for
+      others, hence we're releasing the code
+      to the general public.<br>
+      libgnurl is released under the same
+      license as libcurl. Please read the README for instructions, as you
+      must supply the correct options to configure to get a proper build of
+      libgnurl.
+      {% endtrans %}
+    </p>
+    <h3>{{_("Motivation") }}</h3>
+    <p>
+      {% trans %}
+      cURL supports many crypto backends. GNUnet requires the use of
+      GnuTLS, but other variants are used by some distributions. Supporting
+      other crypto backends would again expose us to a wider array of
+      security issues, may create licensing issues and most importantly
+      introduce new bugs as some crypto backends are known to introduce
+      subtle runtime issues. While it is possible to have two versions of
+      libcurl installed on the same system, this is error-prone, especially
+      as if we are linked against the wrong version, the bugs that arise
+      might be rather subtle.
+      {% endtrans %}
+    </p>
+    <p>
+        {% trans %}
+        For GNUnet, we also need a particularly modern version of
+        GnuTLS. Thus, it would anyway be necessary to recompile cURL for
+        GNUnet. But what happens if one links cURL against this version of
+        GnuTLS? Well, first one would install GnuTLS by hand in the
+        system. Then, we build cURL. cURL will build against it just fine, but
+        the linker will eventually complain bitterly. The reason is that cURL
+        also links against a bunch of other system libraries (gssapi, ldap,
+        ssh2, rtmp, krb5, sasl2, see discussion on obscure protocols above),
+        which --- as they are part of the distribution --- were linked against
+        an older version of GnuTLS. As a result, the same binary would be
+        linked against two different versions of GnuTLS. That is typically a
+        recipe for disaster. Thus, in order to avoid updating a dozen system
+        libraries (and having two versions of those installed), it is
+        necessary to disable all of those cURL features that GNUnet does not
+        use, and there are many of those. For GNUnet, the more obscure
+        protocols supported by cURL are close to dead code --- mostly
+        harmless, but not useful. However, as some application may use one of
+        those features, distributions are typically forced to enable all of
+        those features, and thus including security issues that might arise
+        from that code.
+        {% endtrans %}
+      </p>
+      <p>
+        {% trans %}
+        So to use a modern version of GnuTLS, a sane approach is to disable
+        all of the "optional" features of cURL that drag in system libraries
+        that link against the older GnuTLS. That works, except that one should
+        then NEVER install that version of libcurl in say /usr or /usr/local,
+        as that may break other parts of the system that might depend on these
+        features that we just disabled. Libtool versioning doesn't help here,
+        as it is not intended to deal with libraries that have optional
+        features. Naturally, installing cURL somewhere else is also
+        problematic, as we now need to be really careful that the linker will
+        link GNUnet against the right version. Note that none of this can
+        really be trivially fixed by the cURL developers.
+        {% endtrans %}
+      </p>
+      <h3>{{_("Rename to fix") }}</h3>
+    <p>
+    {% trans %}
+    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 I'm not happy to wait for a decade for Daniel to review
+    the patches. The changes libgnurl makes to curl are miniscule and can
+    easily be applied again and again whenever libcurl makes a new
+    release.
+      {% endtrans %}
+    </p>
+    <h3>{{_("Using libgnurl") }}</h3>
+    <p>
+      {% trans %}
+      Projects that use cURL only for HTTP/HTTPS and that would work
+      with GnuTLS should be able to switch to libgnurl by changing
+      "-lcurl" to "-lgnurl". That's it. No changes to the source code
+      should be required,
+      as libgnurl strives for bug-for-bug compatibility with the
+      HTTP/HTTPS/GnuTLS subset of cURL.
+      We might add new features relating to this core subset if they
+      are proposed, but so far we have kept our changes minimal and
+      no additions to the original curl source have been written.
+      {% endtrans %}
+    </p>
+    <h4>{{_("Gotchas") }}</h4>
+    <p>
+      {% trans %}
+      libgnurl and gnurl are not intended to be used as a replacement
+      for curl for users. Since no conflicts in filenames should occur
+      you are not expected to remove curl to make use of gnurl and
+      viceversa.
+      {% endtrans %}
+    </p>
+  </article>
+</div>
+<div class="container adorn_h3_bracket">
+  <div class="row">
+    <div class="col-lg-6">
+      <h3>{{ _("Source Code") }}</h3>
+      <p>
+        {% trans %}
+        You can get the Gnurl Git repository using:
+        <code>git clone https://git.taler.net/gnurl.git</code>
+        The versions are checked in as signed git tags.
+        {% endtrans %}
+      </p>
+    </div>
+    <div class="col-lg-6">
+      <h3>{{ _("Downloads") }}</h3>
+      <p>
+        {% trans %}
+        Releases are published on <a href="https://ftp.gnu.org/gnu/gnunet/">ftp.gnu.org/gnu/gnunet</a>.
+        gnURL is available from within a variety of distributions and package managers.
+        Package Managers which include gnurl are:
+        <a href="https://gnu.org/s/guix">GNU Guix</a> (available as "gnurl"),
+        <a href="https://gentoo.org">Gentoo</a> through the collaborative ebuild collection
+        <a href="https://gnunet.org/git/youbroketheinternet-overlay.git/">youbroketheinternet</a>,
+        <a href=https://nixos.org/nix">Nix</a>, and <a href="http://pkgsrc.org">pkgsrc</a>.
+        {% endtrans %}
+      </p>
+    </div>
+  </div>
+  <div class="row">
+    <div class="col-lg-6">
+      <h3>{{ _("Reporting Bugs") }}</h3>
+      <p>
+        {% trans %}
+        You can report bugs on our bug tracker:
+        <a href="https://gnunet.org/bugs/">gnunet.org/bugs</a>. Alternatively
+        you can use our bug mailinglist, but we prefer to track bugs
+        on the bugtracker.
+        {% endtrans %}
+      </p>
+    </div>
+    <div class="col-lg-6">
+      <h3>{{ _("Maintainer and Cryptographic signatures") }}</h3>
+      <p>
+        {% trans %}
+        gnur/libgnurl is maintained by ng0.
+        Releases are signed
+        with the OpenPG Key <b>A88C8ADD129828D7EAC02E52E22F9BBFEE348588</b>,
+        with the key fingerprint <b>A88C 8ADD 1298 28D7 EAC0  2E52 E22F 9BBF EE34 8588</b>.
+        {% endtrans %}
+      </p>
+    </div>
+  </div>
+</div>
+</div> <!-- /container -->
+{% endblock body_content %}

diff --git a/template/gnurl.html.j2 b/template/gnurl.html.j2 new file mode 100644 index 00000000..dbfbe757 --- /dev/null +++ b/template/gnurl.html.j2
@@ -0,0 +1,175 @@
	1	{% extends "common/base.j2" %}
	2	{% block body_content %}
	3	<div class="container-fluid">
	4	<article>
	5	<h1>{{ _("gnurl (libgnurl)") }}</h1>
	6	<p>
	7	{% trans %}
	8	libgnurl is a micro fork of libcurl. The goal of libgnurl
	9	is to support only HTTP and HTTPS (and only HTTP 1.x) with
	10	a single crypto backend (GnuTLS) to ensure a small footprint
	11	and uniform experience for developers regardless of how
	12	libcurl was compiled.<br>
	13	Our main usecase is for GNUnet, but it might be usable for
	14	others, hence we're releasing the code
	15	to the general public.<br>
	16	libgnurl is released under the same
	17	license as libcurl. Please read the README for instructions, as you
	18	must supply the correct options to configure to get a proper build of
	19	libgnurl.
	20	{% endtrans %}
	21	</p>
	22	<h3>{{_("Motivation") }}</h3>
	23	<p>
	24	{% trans %}
	25	cURL supports many crypto backends. GNUnet requires the use of
	26	GnuTLS, but other variants are used by some distributions. Supporting
	27	other crypto backends would again expose us to a wider array of
	28	security issues, may create licensing issues and most importantly
	29	introduce new bugs as some crypto backends are known to introduce
	30	subtle runtime issues. While it is possible to have two versions of
	31	libcurl installed on the same system, this is error-prone, especially
	32	as if we are linked against the wrong version, the bugs that arise
	33	might be rather subtle.
	34	{% endtrans %}
	35	</p>
	36	<p>
	37	{% trans %}
	38	For GNUnet, we also need a particularly modern version of
	39	GnuTLS. Thus, it would anyway be necessary to recompile cURL for
	40	GNUnet. But what happens if one links cURL against this version of
	41	GnuTLS? Well, first one would install GnuTLS by hand in the
	42	system. Then, we build cURL. cURL will build against it just fine, but
	43	the linker will eventually complain bitterly. The reason is that cURL
	44	also links against a bunch of other system libraries (gssapi, ldap,
	45	ssh2, rtmp, krb5, sasl2, see discussion on obscure protocols above),
	46	which --- as they are part of the distribution --- were linked against
	47	an older version of GnuTLS. As a result, the same binary would be
	48	linked against two different versions of GnuTLS. That is typically a
	49	recipe for disaster. Thus, in order to avoid updating a dozen system
	50	libraries (and having two versions of those installed), it is
	51	necessary to disable all of those cURL features that GNUnet does not
	52	use, and there are many of those. For GNUnet, the more obscure
	53	protocols supported by cURL are close to dead code --- mostly
	54	harmless, but not useful. However, as some application may use one of
	55	those features, distributions are typically forced to enable all of
	56	those features, and thus including security issues that might arise
	57	from that code.
	58	{% endtrans %}
	59	</p>
	60	<p>
	61	{% trans %}
	62	So to use a modern version of GnuTLS, a sane approach is to disable
	63	all of the "optional" features of cURL that drag in system libraries
	64	that link against the older GnuTLS. That works, except that one should
	65	then NEVER install that version of libcurl in say /usr or /usr/local,
	66	as that may break other parts of the system that might depend on these
	67	features that we just disabled. Libtool versioning doesn't help here,
	68	as it is not intended to deal with libraries that have optional
	69	features. Naturally, installing cURL somewhere else is also
	70	problematic, as we now need to be really careful that the linker will
	71	link GNUnet against the right version. Note that none of this can
	72	really be trivially fixed by the cURL developers.
	73	{% endtrans %}
	74	</p>
	75	<h3>{{_("Rename to fix") }}</h3>
	76	<p>
	77	{% trans %}
	78	How does forking fix it? Easy. First, we can get rid of all of the
	79	compatibility issues --- if you use libgnurl, you state that you don't
	80	need anything but HTTP/HTTPS. Those applications that need more,
	81	should stick with the original cURL. Those that do not, can choose to
	82	move to something simpler. As the library gets a new name, we do not
	83	have to worry about tons of packages breaking as soon as one rebuilds
	84	it. So renaming itself and saying that "libgnurl = libcurl with only
	85	HTTP/HTTPS support and GnuTLS" fixes 99%% of the problems that darkened
	86	my mood. Note that this pretty much CANNOT be done without a fork, as
	87	renaming is an essential part of the fix. Now, there might be creative
	88	solutions to achieve the same thing within the standard cURL build
	89	system, but I'm not happy to wait for a decade for Daniel to review
	90	the patches. The changes libgnurl makes to curl are miniscule and can
	91	easily be applied again and again whenever libcurl makes a new
	92	release.
	93	{% endtrans %}
	94	</p>
	95	<h3>{{_("Using libgnurl") }}</h3>
	96	<p>
	97	{% trans %}
	98	Projects that use cURL only for HTTP/HTTPS and that would work
	99	with GnuTLS should be able to switch to libgnurl by changing
	100	"-lcurl" to "-lgnurl". That's it. No changes to the source code
	101	should be required,
	102	as libgnurl strives for bug-for-bug compatibility with the
	103	HTTP/HTTPS/GnuTLS subset of cURL.
	104	We might add new features relating to this core subset if they
	105	are proposed, but so far we have kept our changes minimal and
	106	no additions to the original curl source have been written.
	107	{% endtrans %}
	108	</p>
	109	<h4>{{_("Gotchas") }}</h4>
	110	<p>
	111	{% trans %}
	112	libgnurl and gnurl are not intended to be used as a replacement
	113	for curl for users. Since no conflicts in filenames should occur
	114	you are not expected to remove curl to make use of gnurl and
	115	viceversa.
	116	{% endtrans %}
	117	</p>
	118	</article>
	119	</div>
	120
	121	<div class="container adorn_h3_bracket">
	122	<div class="row">
	123	<div class="col-lg-6">
	124	<h3>{{ _("Source Code") }}</h3>
	125	<p>
	126	{% trans %}
	127	You can get the Gnurl Git repository using:
	128	<code>git clone https://git.taler.net/gnurl.git</code>
	129	The versions are checked in as signed git tags.
	130	{% endtrans %}
	131	</p>
	132	</div>
	133	<div class="col-lg-6">
	134	<h3>{{ _("Downloads") }}</h3>
	135	<p>
	136	{% trans %}
	137	Releases are published on <a href="https://ftp.gnu.org/gnu/gnunet/">ftp.gnu.org/gnu/gnunet</a>.
	138	gnURL is available from within a variety of distributions and package managers.
	139	Package Managers which include gnurl are:
	140	<a href="https://gnu.org/s/guix">GNU Guix</a> (available as "gnurl"),
	141	<a href="https://gentoo.org">Gentoo</a> through the collaborative ebuild collection
	142	<a href="https://gnunet.org/git/youbroketheinternet-overlay.git/">youbroketheinternet</a>,
	143	<a href=https://nixos.org/nix">Nix</a>, and <a href="http://pkgsrc.org">pkgsrc</a>.
	144	{% endtrans %}
	145	</p>
	146	</div>
	147	</div>
	148	<div class="row">
	149	<div class="col-lg-6">
	150	<h3>{{ _("Reporting Bugs") }}</h3>
	151	<p>
	152	{% trans %}
	153	You can report bugs on our bug tracker:
	154	<a href="https://gnunet.org/bugs/">gnunet.org/bugs</a>. Alternatively
	155	you can use our bug mailinglist, but we prefer to track bugs
	156	on the bugtracker.
	157	{% endtrans %}
	158	</p>
	159	</div>
	160	<div class="col-lg-6">
	161	<h3>{{ _("Maintainer and Cryptographic signatures") }}</h3>
	162	<p>
	163	{% trans %}
	164	gnur/libgnurl is maintained by ng0.
	165	Releases are signed
	166	with the OpenPG Key <b>A88C8ADD129828D7EAC02E52E22F9BBFEE348588</b>,
	167	with the key fingerprint <b>A88C 8ADD 1298 28D7 EAC0 2E52 E22F 9BBF EE34 8588</b>.
	168	{% endtrans %}
	169	</p>
	170	</div>
	171	</div>
	172	</div>
	173
	174	</div> <!-- /container -->
	175	{% endblock body_content %}