[PATCH] gnu: gnutls: Configure location of system-wide trust store

[PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 114 bytes --]

This patch is needed to allow gnutls to find the system-wide trust store
(trusted CA certificates).

      Mark



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH] gnu: gnutls: Configure location of system-wide trust store --]
[-- Type: text/x-patch, Size: 1547 bytes --]

From 51fdea28198bd284949c98bc423e5fcef6169068 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Tue, 18 Feb 2014 21:30:53 -0500
Subject: [PATCH] gnu: gnutls: Configure location of system-wide trust store.

* gnu/packages/gnutls.scm (gnutls): Configure the location of the system-wide
  trust store.
---
 gnu/packages/gnutls.scm | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/gnu/packages/gnutls.scm b/gnu/packages/gnutls.scm
index 915f6f8..dde4416 100644
--- a/gnu/packages/gnutls.scm
+++ b/gnu/packages/gnutls.scm
@@ -87,6 +87,17 @@ specifications.")
      `(("libtasn1" ,libtasn1)
        ("nettle" ,nettle)
        ("which" ,which)))
+    (arguments
+     `(#:configure-flags
+       '(;; GnuTLS doesn't consult any environment variables to specify the
+         ;; location of the system-wide trust store.  Instead it has a
+         ;; configure-time option.  Unless specified, its configure script
+         ;; attempts to auto-detect the location by looking for common places
+         ;; in the filesystem, none of which are present in our chroot build
+         ;; environment.  If not found, then no default trust store is used,
+         ;; so each program has to provide its own fallback, and users have to
+         ;; configure each program independently.  This seems suboptimal.
+         "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))
     (home-page "http://www.gnu.org/software/gnutls/")
     (synopsis "Transport layer security library")
     (description
-- 
1.8.4

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

On Tue, Feb 18, 2014 at 09:47:18PM -0500, Mark H Weaver wrote:
> This patch is needed to allow gnutls to find the system-wide trust store
> (trusted CA certificates).

> +         "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))

As there is no system, and we advertise per user configuration, should this
not rather be $HOME/.guix-profile/etc/...? Which probably does not work
as it would be needed to be "resolved" at execution time. Is there any way
of telling gnutls to use an environment variable?

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:
> On Tue, Feb 18, 2014 at 09:47:18PM -0500, Mark H Weaver wrote:
>> This patch is needed to allow gnutls to find the system-wide trust store
>> (trusted CA certificates).
>
>> +         "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))
>
> As there is no system, and we advertise per user configuration, should this
> not rather be $HOME/.guix-profile/etc/...? Which probably does not work
> as it would be needed to be "resolved" at execution time. Is there any way
> of telling gnutls to use an environment variable?

I'm very sympathetic to your point of view.  I agree that each user
should be able to decide which CA certificates to trust.

However, GnuTLS does not support an environment variable setting, so we
would have to patch the code (add_system_trust in lib/system.c).  I
strongly considered doing this, but I'm worried about the possible
security implications.  For example, consider a setuid program that uses
GnuTLS and assumes that the person who ran the program will not be
capable of changing the trust store that GnuTLS uses.  This assumption
would be correct for the upstream GnuTLS, but not for ours.

Here's the thing: GnuTLS does not trust the system store by default.
The program has to call 'gnutls_certificate_set_x509_system_trust' to
use the system trust store.  Therefore, individual programs can still
allow the user to override the system trust store.

For example, look at the code for 'wget' (ssl_init in src/gnutls.c).  If
you put "ca_directory = <DIRECTORY>" in ~/.wgetrc, then wget does not
call 'gnutls_certificate_set_x509_system_trust'.  Instead, it trusts
only the certs in the specified user directory.

So, in the end, I don't think we should mess around with the way GnuTLS
was designed.  I think we should provide a hard-coded system-wide
location to allow 'gnutls_certificate_set_x509_system_trust' to work as
it was intended, and instead we should make sure that each individual
program has a way to override that.

What do you think?

    Regards,
      Mark

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

On Wed, Feb 19, 2014 at 05:13:26AM -0500, Mark H Weaver wrote:
> However, GnuTLS does not support an environment variable setting, so we
> would have to patch the code (add_system_trust in lib/system.c).  I
> strongly considered doing this, but I'm worried about the possible
> security implications.  For example, consider a setuid program that uses
> GnuTLS and assumes that the person who ran the program will not be
> capable of changing the trust store that GnuTLS uses.  This assumption
> would be correct for the upstream GnuTLS, but not for ours.
> 
> Here's the thing: GnuTLS does not trust the system store by default.
> The program has to call 'gnutls_certificate_set_x509_system_trust' to
> use the system trust store.  Therefore, individual programs can still
> allow the user to override the system trust store.
> 
> For example, look at the code for 'wget' (ssl_init in src/gnutls.c).  If
> you put "ca_directory = <DIRECTORY>" in ~/.wgetrc, then wget does not
> call 'gnutls_certificate_set_x509_system_trust'.  Instead, it trusts
> only the certs in the specified user directory.

This is an interesting feature.

> So, in the end, I don't think we should mess around with the way GnuTLS
> was designed.  I think we should provide a hard-coded system-wide
> location to allow 'gnutls_certificate_set_x509_system_trust' to work as
> it was intended, and instead we should make sure that each individual
> program has a way to override that.

I am still uneasy with this situation, even more so as long as we do not
have the gnu system: Currently, the guix gnutls would point to the ssl
certificates that debian installed (or did not install) in /etc; we will
get behaviour that depends a lot on the outside system instead of being
self-contained.

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Ludovic Courtès]

Hello!

Thank you both for looking into this.

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Feb 19, 2014 at 05:13:26AM -0500, Mark H Weaver wrote:

[...]

>> So, in the end, I don't think we should mess around with the way GnuTLS
>> was designed.  I think we should provide a hard-coded system-wide
>> location to allow 'gnutls_certificate_set_x509_system_trust' to work as
>> it was intended, and instead we should make sure that each individual
>> program has a way to override that.
>
> I am still uneasy with this situation, even more so as long as we do not
> have the gnu system: Currently, the guix gnutls would point to the ssl
> certificates that debian installed (or did not install) in /etc; we will
> get behaviour that depends a lot on the outside system instead of being
> self-contained.

Agreed.  However, AIUI, these is just the location of the default
certificates; as Mark wrote, applications, such as wget, can in fact
specify the certificate location independently of that default value.

So, all in all, while this is not ideal, using this configure flag to
point to /etc/ssl/... sounds like a viable option to me.  It’s
consistent with what other distros do, and it’s what we want to do
eventually.

(Also, I think it’s time to really take the final system as the primary
use case.)

WDYT?

Thanks,
Ludo’.

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

On Wed, Feb 19, 2014 at 02:40:42PM +0100, Ludovic Courtès wrote:
> So, all in all, while this is not ideal, using this configure flag to
> point to /etc/ssl/... sounds like a viable option to me.  It’s
> consistent with what other distros do, and it’s what we want to do
> eventually.
> 
> (Also, I think it’s time to really take the final system as the primary
> use case.)

The next question is, where do these certificates come from in our system?
I think a reasonable solution would be to:
- create a package with certificates (maybe inspired from those contained
  in debian);
- have gnutls depend on it, and use the gnutls configure flag to point to
  /nix/store/xxx-our-certificates/etc/ssl/... .

I think this would be more in line with our approach than pointing to /etc.
Also, if a certificate gets compromised and is withdrawn from the certificate
package, this would force gnutls and all its dependencies to be recompiled.

What do you think?

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Sree Harsha Totakura]

On 02/19/2014 03:08 PM, Andreas Enge wrote:
> The next question is, where do these certificates come from in our system?
> I think a reasonable solution would be to:
> - create a package with certificates (maybe inspired from those contained
>   in debian);
> - have gnutls depend on it, and use the gnutls configure flag to point to
>   /nix/store/xxx-our-certificates/etc/ssl/... .
> 
> I think this would be more in line with our approach than pointing to /etc.
> Also, if a certificate gets compromised and is withdrawn from the certificate
> package, this would force gnutls and all its dependencies to be recompiled.
> 
> What do you think?

I like this solution.

Sree

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Feb 19, 2014 at 02:40:42PM +0100, Ludovic Courtès wrote:
>> So, all in all, while this is not ideal, using this configure flag to
>> point to /etc/ssl/... sounds like a viable option to me.  It’s
>> consistent with what other distros do, and it’s what we want to do
>> eventually.
>> 
>> (Also, I think it’s time to really take the final system as the primary
>> use case.)
>
> The next question is, where do these certificates come from in our system?
> I think a reasonable solution would be to:
> - create a package with certificates (maybe inspired from those contained
>   in debian);

Definitely.

> - have gnutls depend on it, and use the gnutls configure flag to point to
>   /nix/store/xxx-our-certificates/etc/ssl/... .
>
> I think this would be more in line with our approach than pointing to /etc.
> Also, if a certificate gets compromised and is withdrawn from the certificate
> package, this would force gnutls and all its dependencies to be recompiled.
>
> What do you think?

That’s the solution I would prefer in many cases.

However, the last point you mention (having to rebuild GnuTLS et
al. when a certificate changes) seems to me like a drawback, because it
makes it unnecessarily costly (storage, bandwidth, time) to deploy a new
certificate bundle.

One way to address that would be to have /etc/ssl/... be a Guix-managed
symlink to /nix/store/...-certificates (this is +/- what NixOS does.)

How does that sound?

Thanks,
Ludo’.

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> The next question is, where do these certificates come from in our system?
> I think a reasonable solution would be to:
> - create a package with certificates (maybe inspired from those contained
>   in debian);
> - have gnutls depend on it, and use the gnutls configure flag to point to
>   /nix/store/xxx-our-certificates/etc/ssl/... .
>
> I think this would be more in line with our approach than pointing to /etc.
> Also, if a certificate gets compromised and is withdrawn from the certificate
> package, this would force gnutls and all its dependencies to be recompiled.
>
> What do you think?

I think you could make this argument for any program or library that
looks for things in /etc.  For example, glibc looks in
/etc/nsswitch.conf, /etc/resolv.conf, /etc/hosts, /etc/passwd,
/etc/group, etc.

Should we put these configuration files in a package, make glibc depend
on that package, and then force the user to recompile the entire system
whenever one of these files needs to change?

While I sympathize with your concerns, I think that this is going too
far, even for your more limited suggestion of recompiling everything
that depends on gnutls.  If I discover that a CA certificate has been
compromised, I don't want to have to recompile a large number of
programs, and then make sure that I don't have old profiles lying around
that still refer to the old CA certificates.  I'd also essentially lose
roll-back functionality, because I wouldn't be able to roll back without
also enabling the compromised cert.

Furthermore, I think that users should be able to use substitutes from
Hydra even if they want to trust a different set of CA certs.

Here's the thing: what is the common case?  Nowadays, the common case is
that each of us has our own personal computer, where we have root and
can thus change /etc/ssl/certs/ as we wish.  In the uncommon case where
we don't have root, or are sharing a system with others, we can still
configure our own trust stores for individual programs that use gnutls.

However, one of the great things about Guix is that it's possible to
keep a local branch with your own changes.  So, if you want to make a
gnutls package with the trust store in a different location
(/home/andreas/.certs or /nix/store/* or whatever), you can do that
quite easily.  (I've started doing that myself, since my xterm changes
were blocked.)

What do you think?

    Regards,
      Mark

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

Concerning yours and Mark's suggestions, I think the best solution would
be if GnutTLS looked in the user profile for certificates. As it does not,
I still think that my suggestion of considering the certificates as an
input is more in style: Admittedly, they are only data, but the functioning
of GnuTLS depends on them, as much as texlive carries its own data (not
in a separate package, as no other package needs to depend on it).

On Wed, Feb 19, 2014 at 10:52:20PM +0100, Ludovic Courtès wrote:
> One way to address that would be to have /etc/ssl/... be a Guix-managed
> symlink to /nix/store/...-certificates (this is +/- what NixOS does.)
> How does that sound?

That is certainly a possibility.

On Thu, Feb 20, 2014 at 01:01:56PM -0500, Mark H Weaver wrote:
> I think you could make this argument for any program or library that
> looks for things in /etc.  For example, glibc looks in
> /etc/nsswitch.conf, /etc/resolv.conf, /etc/hosts, /etc/passwd,
> /etc/group, etc.

I did not think about these cases, but I think there are limits... Moreover,
these files need to be dynamically changed (adapted to the machine etc.),
while certificates are just static data. So the analogy does not hold.

> However, one of the great things about Guix is that it's possible to
> keep a local branch with your own changes.  So, if you want to make a
> gnutls package with the trust store in a different location
> (/home/andreas/.certs or /nix/store/* or whatever), you can do that
> quite easily.  (I've started doing that myself, since my xterm changes
> were blocked.)

Well, it is not that I could not live with one or the other decision; I am
just taking part in the discussion and voicing my opinion.

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Concerning yours and Mark's suggestions, I think the best solution would
> be if GnutTLS looked in the user profile for certificates.

Sounds like a plan, but my understanding is that this would require
patching GnuTLS since it currently only accepts a fixed file name.

What about raising this issue on the GnuTLS mailing list?

> On Wed, Feb 19, 2014 at 10:52:20PM +0100, Ludovic Courtès wrote:
>> One way to address that would be to have /etc/ssl/... be a Guix-managed
>> symlink to /nix/store/...-certificates (this is +/- what NixOS does.)
>> How does that sound?
>
> That is certainly a possibility.
>
> On Thu, Feb 20, 2014 at 01:01:56PM -0500, Mark H Weaver wrote:
>> I think you could make this argument for any program or library that
>> looks for things in /etc.  For example, glibc looks in
>> /etc/nsswitch.conf, /etc/resolv.conf, /etc/hosts, /etc/passwd,
>> /etc/group, etc.
>
> I did not think about these cases, but I think there are limits... Moreover,
> these files need to be dynamically changed (adapted to the machine etc.),
> while certificates are just static data. So the analogy does not hold.

So I think the insight here is that certificates, libc config, etc. are
all dynamic parts of the systems, and it seems we agree that we should
be able to handle them dynamically.

The most flexible approach would be for GnuTLS to honor an environment
variable.  Using /etc/ssl satisfies the dynamicity requirement but is
obviously less flexible.

I guess we should just submit a getenv patch to GnuTLS.  Any volunteers?
:-)

Until it’s accepted, I think we should go with the /etc/ssl approach.

Thanks,
Ludo’.

[PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

I proposed this change a long time ago, but Andreas objected so I never
pushed it.  I've been carrying this patch on my own systems ever since,
but it's getting to be a bit of a drag, because it means no substitutes
for me for an increasingly large amount of software.

Here's the conversation we had last time:

  http://comments.gmane.org/gmane.comp.gnu.guix.devel/1538

Any more thoughts on this?

      Mark



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH] gnu: gnutls: Configure location of system-wide trust store --]
[-- Type: text/x-patch, Size: 1682 bytes --]

From 02bdf748b4c515d6dfc9c264fd48936bd29e04cb Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Tue, 18 Feb 2014 21:30:53 -0500
Subject: [PATCH] gnu: gnutls: Configure location of system-wide trust store.

* gnu/packages/gnutls.scm (gnutls): Configure the location of the system-wide
  trust store.
---
 gnu/packages/gnutls.scm | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gnutls.scm b/gnu/packages/gnutls.scm
index 4f6bd22..d7eeaa8 100644
--- a/gnu/packages/gnutls.scm
+++ b/gnu/packages/gnutls.scm
@@ -80,7 +80,17 @@ specifications.")
      '(#:configure-flags
        (list (string-append "--with-guile-site-dir="
                             (assoc-ref %outputs "out")
-                            "/share/guile/site/2.0"))))
+                            "/share/guile/site/2.0")
+             ;; GnuTLS doesn't consult any environment variables to specify
+             ;; the location of the system-wide trust store.  Instead it has a
+             ;; configure-time option.  Unless specified, its configure script
+             ;; attempts to auto-detect the location by looking for common
+             ;; places in the filesystem, none of which are present in our
+             ;; chroot build environment.  If not found, then no default trust
+             ;; store is used, so each program has to provide its own
+             ;; fallback, and users have to configure each program
+             ;; independently.  This seems suboptimal.
+             "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))
     (native-inputs
      `(("pkg-config" ,pkg-config)))
     (inputs
-- 
2.2.1

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[David Thompson]

Mark H Weaver <mhw@netris.org> writes:

> I proposed this change a long time ago, but Andreas objected so I never
> pushed it.  I've been carrying this patch on my own systems ever since,
> but it's getting to be a bit of a drag, because it means no substitutes
> for me for an increasingly large amount of software.
>
> Here's the conversation we had last time:
>
>   http://comments.gmane.org/gmane.comp.gnu.guix.devel/1538
>
> Any more thoughts on this?

The explanation provided in the comment makes sense to me.  I approve.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> From 02bdf748b4c515d6dfc9c264fd48936bd29e04cb Mon Sep 17 00:00:00 2001
> From: Mark H Weaver <mhw@netris.org>
> Date: Tue, 18 Feb 2014 21:30:53 -0500
> Subject: [PATCH] gnu: gnutls: Configure location of system-wide trust store.
>
> * gnu/packages/gnutls.scm (gnutls): Configure the location of the system-wide
>   trust store.

I support it, OK to push.

The next question will be which certificate bundles should we provide
there in the system distro?  I know NixOS takes them from the cURL web
site, and Debian maintains its own (IIRC.)  Any ideas?

Thank you!

Ludo’.

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Marek Benc]

On 02/03/2015 09:53 PM, Ludovic Courtès wrote:
> Mark H Weaver <mhw@netris.org> skribis:
>
>>  From 02bdf748b4c515d6dfc9c264fd48936bd29e04cb Mon Sep 17 00:00:00 2001
>> From: Mark H Weaver <mhw@netris.org>
>> Date: Tue, 18 Feb 2014 21:30:53 -0500
>> Subject: [PATCH] gnu: gnutls: Configure location of system-wide trust store.
>>
>> * gnu/packages/gnutls.scm (gnutls): Configure the location of the system-wide
>>    trust store.
>
> I support it, OK to push.
>
> The next question will be which certificate bundles should we provide
> there in the system distro?  I know NixOS takes them from the cURL web
> site, and Debian maintains its own (IIRC.)  Any ideas?

If I recall correctly, at one point, the idea was to extract the 
certificates from Icecat, but we were waiting for quidam to update it 
first (it was long stuck on a single version, 24 I think?)

>
> Thank you!
>
> Ludo’.
>

-- 
Marek.

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

Hello,

On Mon, Feb 02, 2015 at 06:11:02PM -0500, Mark H Weaver wrote:
> +             "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))

I would suggest to use --with-default-trust-store-dir=/etc/ssl/certs instead.
The option is available in gnutls-3.3.12, which I am building in the
wip-gnutls branch right now, and which looks good to push.

This would allow us to provide not only a single file, but to potentially
merge different trust stores. We could also, for instance, prepare a package
per certification authority, so that the user could install exactly the
ones he trusts.

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

PS: Ideally, I still think it would be optimal if gnutls used a per user
    environment variable, in the spirit of liberating users and not
    system administrators. I will enquire. But for the time being, the
    global specification looks better than nothing. When I have some time,
    I will try to look into how to package certificates of certification
    authorities. Putting individual certificates into /etc/ssl/certs
    (and running c_rehash before installation) should make them usable
    by gnutls and openssl alike.

PPS: Once the new gnutls is pushed, I would like to also try an update
     of openssl in a wip branch.

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Mon, Feb 02, 2015 at 06:11:02PM -0500, Mark H Weaver wrote:
>> +             "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))
>
> I would suggest to use --with-default-trust-store-dir=/etc/ssl/certs instead.
> The option is available in gnutls-3.3.12, which I am building in the
> wip-gnutls branch right now, and which looks good to push.
>
> This would allow us to provide not only a single file, but to potentially
> merge different trust stores. We could also, for instance, prepare a package
> per certification authority, so that the user could install exactly the
> ones he trusts.

Sounds good to me!  Thanks :)

Since GnuTLS updates require so much rebuilding, I would prefer to wait
for Hydra to finish the rebuild of intel platforms on another branch
before merging into master.

> PS: Ideally, I still think it would be optimal if gnutls used a per user
>     environment variable, in the spirit of liberating users and not
>     system administrators. I will enquire. But for the time being, the
>     global specification looks better than nothing.

I agree it would be good if upstream supported such a variable, so
please do propose it to them!  I think it has to be done upstream
because of the potential security implications of setuid programs, as I
mentioned in the thread a year ago.

>     When I have some time,
>     I will try to look into how to package certificates of certification
>     authorities. Putting individual certificates into /etc/ssl/certs
>     (and running c_rehash before installation) should make them usable
>     by gnutls and openssl alike.

I've been looking into this as well, but will address it in another
message.

     Thanks!
       Mark

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

Hello Mark,

On Wed, Feb 04, 2015 at 10:35:57AM -0500, Mark H Weaver wrote:
> Since GnuTLS updates require so much rebuilding, I would prefer to wait
> for Hydra to finish the rebuild of intel platforms on another branch
> before merging into master.

I just cherry-picked the new gnutls into master.

Could you push your updated patch to wip-gnutls? It is currently just
a copy of master. We can cherry-pick it back once hydra has finished
rebuilding.

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

Hello,

On Wed, Feb 04, 2015 at 10:35:57AM -0500, Mark H Weaver wrote:
> I agree it would be good if upstream supported such a variable, so
> please do propose it to them!  I think it has to be done upstream
> because of the potential security implications of setuid programs, as I
> mentioned in the thread a year ago.

I asked the question on the gnutls mailing list, and Nikos replied that
we should use p11-kit. (Actually a package that is on my git stash,
because it caused problems for reasons I do not remember.) We could try
to get inspiration from fedora as explained in the thread:
   http://lists.gnutls.org/pipermail/gnutls-devel/2015-February/007442.html

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

On Sun, Feb 08, 2015 at 02:36:29PM +0100, Andreas Enge wrote:
> I asked the question on the gnutls mailing list, and Nikos replied that
> we should use p11-kit. (Actually a package that is on my git stash,
> because it caused problems for reasons I do not remember.)

Easy to try again, it fails one of its tests:
# assertion failed (count > 0): (0 > 0)
# in test_multi_initialize() at test-module.c:230
/gnu/store/nx4zd42igyb7ghmv4mxv6ncg8wr7ypa1-bash-4.3.33/bin/bash: line 5: 14885 Aborted                 ${dir}$tst
FAIL: test-module

The failing code before line 230 is the following:
        count = 8;
        rv = module->C_GetSlotList (CK_TRUE, slots, &count);
        assert_num_eq (rv, CKR_OK);
        assert_num_cmp (count, >, 0);

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

Well, the test also fails when compiling by hand (on my debian system after
installing the inputs from guix), so I filed a bug report upstream and
disabled it.

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver]

Hi,

Andreas Enge <andreas@enge.fr> writes:

> On Wed, Feb 04, 2015 at 10:35:57AM -0500, Mark H Weaver wrote:
>> I agree it would be good if upstream supported such a variable, so
>> please do propose it to them!  I think it has to be done upstream
>> because of the potential security implications of setuid programs, as I
>> mentioned in the thread a year ago.
>
> I asked the question on the gnutls mailing list, and Nikos replied that
> we should use p11-kit. (Actually a package that is on my git stash,
> because it caused problems for reasons I do not remember.) We could try
> to get inspiration from fedora as explained in the thread:
>    http://lists.gnutls.org/pipermail/gnutls-devel/2015-February/007442.html

I won't have much time this week to look closely, but in broad terms
this sounds like the right approach to me.

Thanks for working on it!

      Mark

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Mon, Feb 02, 2015 at 06:11:02PM -0500, Mark H Weaver wrote:
>> +             "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))
>
> I would suggest to use --with-default-trust-store-dir=/etc/ssl/certs instead.
> The option is available in gnutls-3.3.12, which I am building in the
> wip-gnutls branch right now, and which looks good to push.
>
> This would allow us to provide not only a single file, but to potentially
> merge different trust stores. We could also, for instance, prepare a package
> per certification authority, so that the user could install exactly the
> ones he trusts.

It turns out there's a problem with our lack of a single-file
certificate bundle.  Curl has two options to specifying the location of
the trust store: CURLOPT_CAINFO names a single file, and CURLOPT_CAPATH
names a directory.  Unfortunately, although CURLOPT_CAINFO is supported
on both GnuTLS and OpenSSL, CURLOPT_CAPATH is only supported on OpenSSL.

Git uses Curl to fetch from https URLs.  Git supports both
GIT_SSL_CAINFO and GIT_SSL_CAPATH environment variables, and pass those
on to CURLOPT_CAINFO and CURLOPT_CAPATH.

I've set GIT_SSL_CAINFO in my environment for a long time to make Git
check certificates properly on GuixSD, but without the single-file
certificate bundle, I've lost certificate checking in Git.

I see a few ways forward:

(1) Curl's GnuTLS backend could grow support for CURLOPT_CAPATH.

(2) We could create single-file certificate bundles in our certificate
    packages and add support to our profile builder to merge them
    together properly.

(3) We could build Curl with OpenSSL for now.

Option (1) seems best, if someone wants to volunteer for that job very
soon.  In the meantime, I like option (2).

What do you think?

      Mark

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

Hello Mark,

I am a bit lost with this explanation:

On Sun, Feb 15, 2015 at 12:17:59AM -0500, Mark H Weaver wrote:
> I've set GIT_SSL_CAINFO in my environment for a long time to make Git
> check certificates properly on GuixSD, but without the single-file
> certificate bundle, I've lost certificate checking in Git.

Is this because upon installing nss-certs, you uninstalled your single file?
Since we had no certificates at all before, I fail to understand how the
situation could be worse now than it was.

Would implementing the p11-kit suggestion for gnutls solve the problem?

Your further analysis might also imply that we need search path definitions
for git and curl (although this does not seem to be enough at the moment).

Andreas

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> Hello Mark,
>
> I am a bit lost with this explanation:
>
> On Sun, Feb 15, 2015 at 12:17:59AM -0500, Mark H Weaver wrote:
>> I've set GIT_SSL_CAINFO in my environment for a long time to make Git
>> check certificates properly on GuixSD, but without the single-file
>> certificate bundle, I've lost certificate checking in Git.
>
> Is this because upon installing nss-certs, you uninstalled your single file?

Yes.  Of course I could make it manually, put it somewhere else, and set
GIT_SSL_CAINFO to point to it, but I'd like to find a solution that
works out of the box for other GuixSD users.

> Since we had no certificates at all before, I fail to understand how the
> situation could be worse now than it was.

No, it's not worse than it was before.  Sorry if I gave that impression.
The only issue is that we might need to generate a single-file
certificate bundle for now, because I haven't found a way to get 'git'
to check certificates on GuixSD without a single-file cert bundle, at
least not when curl is build with GnuTLS.

> Would implementing the p11-kit suggestion for gnutls solve the problem?

Good question!  I don't know the answer.  It seems that when 'git' uses
libcurl built with GnuTLS, it doesn't ask GnuTLS to use the system-wide
trust store.  Maybe that's something we could fix somehow.

> Your further analysis might also imply that we need search path definitions
> for git and curl (although this does not seem to be enough at the moment).

I can't speak for the curl command-line tool, because I never use it,
but we might need one for 'git'.

     Mark

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> No, it's not worse than it was before.  Sorry if I gave that impression.
> The only issue is that we might need to generate a single-file
> certificate bundle for now, because I haven't found a way to get 'git'
> to check certificates on GuixSD without a single-file cert bundle, at
> least not when curl is build with GnuTLS.

It seems like adding this single-file bundle would be the simplest
short-term option.  How would we create that file exactly?  Would it be
OK to keep it in the nss-certs package?

Alternately, how far are “we” (i.e., Andreas ;-)) from getting the
p11-kit flavor?

Thanks,
Ludo’.

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> No, it's not worse than it was before.  Sorry if I gave that impression.
>> The only issue is that we might need to generate a single-file
>> certificate bundle for now, because I haven't found a way to get 'git'
>> to check certificates on GuixSD without a single-file cert bundle, at
>> least not when curl is build with GnuTLS.
>
> It seems like adding this single-file bundle would be the simplest
> short-term option.  How would we create that file exactly?

The single-file bundle is just a concatenation of all the individual PEM
data, starting with "-----BEGIN CERTIFICATE-----" and ending with
"-----END CERTIFICATE-----", including those delimiters.

The only caveat is that the individual PEM files are not required to
have a newline after the "-----END CERTIFICATE-----", but in the
single-file cert bundle, we must ensure that the newline is present.
See <https://bugs.debian.org/635570>.

> Would it be OK to keep it in the nss-certs package?

In order to support multiple packages containing CA certs, it would be
good to handle creation of the single-file cert bundle in the profile
generation code, analogous to our handling of info "dir" files.  This
would allow us to create additional cert packages (e.g. one for
CAcert.org).

I think it belongs in the profile generation code for the benefit of
users running Guix packages on top of another distro, where they might
not have root access.  They can simply set GIT_SSL_CAINFO and
SSL_CERT_FILE to ~/.guix-profile/etc/ssl/ca-certificates.crt

What do you think?

      Mark

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Andreas Enge]

On Tue, Feb 24, 2015 at 03:31:14PM -0500, Mark H Weaver wrote:
> The single-file bundle is just a concatenation of all the individual PEM
> data, starting with "-----BEGIN CERTIFICATE-----" and ending with
> "-----END CERTIFICATE-----", including those delimiters.
> The only caveat is that the individual PEM files are not required to
> have a newline after the "-----END CERTIFICATE-----", but in the
> single-file cert bundle, we must ensure that the newline is present.

I just did a "cat" of two .pem files from nss-certs, and the result
looked good. There are comment lines (starting with #) between the
"-----END CERTIFICATE-----" and the following "-----BEGIN CERTIFICATE-----",
which I hope is okay.

> I think it belongs in the profile generation code for the benefit of
> users running Guix packages on top of another distro, where they might
> not have root access.  They can simply set GIT_SSL_CAINFO and
> SSL_CERT_FILE to ~/.guix-profile/etc/ssl/ca-certificates.crt
> What do you think?

Yes, that sounds like the right approach: Create a concatenation of all the
files in ~/.guix-profile/etc/ssl/certs .

Andreas