1. 05 Feb, 2019 1 commit
  2. 09 Dec, 2018 2 commits
  3. 12 Nov, 2018 1 commit
    • Michael Catanzaro's avatar
      Remove the PKCS#11 backend · 4d6caa03
      Michael Catanzaro authored
      Nowadays the normal GnuTLS backend has full PKCS#11 support. (At least,
      it's certainly supposed to.) The PKCS#11 backend has been disabled in
      2.58, which is two months old now, and not a single complaint has
      reached me from Ubuntu 18.10 or Fedora 29 or anywhere else. It's always
      required a special environment variable to enable anyway, so I consider
      all of this code experimental.
      
      If anyone has a reason to keep this code around, please speak up now! We
      can consider reverting this if there's a good reason to keep the PKCS#11
      backend around that I'm not aware of. But I'm guessing there's not.
      
      Fixes #7
      
      Obsoletes #8
      4d6caa03
  4. 12 Sep, 2018 2 commits
  5. 22 May, 2018 1 commit
  6. 16 Mar, 2018 1 commit
  7. 15 Mar, 2018 2 commits
  8. 07 Mar, 2018 1 commit
    • Michael Catanzaro's avatar
      Use the GnuTLS system trust by default · f1c8feee
      Michael Catanzaro authored
      Get rid of the ca_certificates_path build flag. The default GTlsDatabase
      will now use the GnuTLS system trust. GTlsFileDatabase now builds its
      internal hash tables by iterating its gnutls_x509_trust_list_t, rather
      than by parsing its certificate file manually.
      
      The find-ca-certificates script is removed, since it's no longer needed.
      
      There are some potential compatibility risks here:
      
       * The minimum required GnuTLS version is increased from 3.3.5 to 3.4.
      
       * If GnuTLS is not configured with a system trust, all certificate
         verification using the default GTlsDatabase will fail. I noticed that
         GNOME's flatpak runtime does not configure a system trust, so this
         breaks HTTPS there. This is sad for Epiphany Technology Preview, but
         we should do this anyway, and separately fix the GNOME runtime.
      
       * It was previously possible to configure glib-networking using
         --without-ca-certificates to ensure the default GTlsDatabase is
         empty (GNOME #727282). Apparently this was desirable on some embedded
         systems, though I'm not sure why. Such configuration is still
         possible by configuring GnuTLS with no system trust. Presumably,
         anybody relying on this behavior will notice that the
         --without-ca-certificates flag has disappeared during the build
         system change and investigate, so this seems unproblematic.
      
       * The default GTlsDatabase is a GTlsFileDatabase, but it might not
         actually correspond to a file anymore. This will be fixed in the next
         commit.
      
       * If the anchors property of a GTlsFileDatabase is NULL, that
         previously indicated an empty GTlsFileDatabase, but now indicates
         that the system trust is used. This will also be fixed in the next
         commit.
      
       * Certificate handles created using the default GTlsDatabase will be
         different before and after this commit. This seems unlikely to cause
         problems in practice, since a quick Debian codesearch reveals zero
         applications using our certificate handles. But, if an application
         were to rely on handles generated by previous versions of
         glib-networking being valid in the new version, it would break.
      
      None of the above seem likely to cause practical issues, once
      distributors ensure that GnuTLS is built properly, so I think we can
      proceed.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=753260
      f1c8feee
  9. 02 Mar, 2018 3 commits
  10. 07 Feb, 2018 1 commit
  11. 04 Jan, 2018 1 commit
  12. 21 Oct, 2017 5 commits
  13. 13 Apr, 2017 1 commit