[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

/etc/ssl/certs and the certificate bundle

[Ludovic Courtès]

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

> 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>.

OK, I’ve implemented this for GuixSD in commit 993300f.  Thanks to you
and Andreas for your help.

> 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?

It’s a good but as of yet unimplemented idea.

Although I now realize we could perhaps simple move the
‘certificate-bundle’ procedure to (guix profile), add the certificate
package to the system profile, and make /etc/ssl a symlink to
/run/current-system/profile/etc/ssl.

However there’s the complication that all the files of ‘nss-certs’ would
still be there in addition to the bundle.  Hmm.

Thoughts?

Ludo’.

Re: /etc/ssl/certs and the certificate bundle

[Mark H Weaver]

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

> Mark H Weaver <mhw@netris.org> skribis:
>
>> 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>.
>
> OK, I’ve implemented this for GuixSD in commit 993300f.  Thanks to you
> and Andreas for your help.

Thank you!

>> 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?
>
> It’s a good but as of yet unimplemented idea.
>
> Although I now realize we could perhaps simple move the
> ‘certificate-bundle’ procedure to (guix profile), add the certificate
> package to the system profile, and make /etc/ssl a symlink to
> /run/current-system/profile/etc/ssl.

I think this would be ideal.

> However there’s the complication that all the files of ‘nss-certs’ would
> still be there in addition to the bundle.  Hmm.

That's a feature, not a bug.  It is more efficient to look up the
individual files by their hash-named symlinks than to read the entire
certificate bundle as one file.  The only problem is that some
combinations of software don't yet support this mode.

For example, libcurl (used by git) only supports the single-file when it
is linked with GnuTLS.  When linked with OpenSSL it supports both modes.
(This is a limitation of libcurl's backend for GnuTLS, not an inherent
problem with GnuTLS.)

    Thanks,
      Mark

[PATCHES] profiles: Produce a single-file CA certificate bundle

[Mark H Weaver]

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

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

> Mark H Weaver <mhw@netris.org> skribis:
>
>> 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?
>
> It’s a good but as of yet unimplemented idea.
>
> Although I now realize we could perhaps simple move the
> ‘certificate-bundle’ procedure to (guix profile), add the certificate
> package to the system profile, and make /etc/ssl a symlink to
> /run/current-system/profile/etc/ssl.

I've attached patches that implement this.  They assume that 993300f and
e979e6d are first reverted.  Comments and suggestions welcome.

It would also be good to add search-path-specifications for
SSL_CERT_FILE to 'openssl' and GIT_SSL_CAINFO to 'git' in core-updates,
but I'm not sure how best to do that.  Would you be willing to do it,
Ludovic?

      Mark


[-- Attachment #2: [PATCH 1/2] profiles: Produce a single-file CA certificate bundle --]
[-- Type: text/x-patch, Size: 5864 bytes --]

From 0229c6c51a9341484a84f4cec112494b4fe67757 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Tue, 3 Mar 2015 02:09:30 -0500
Subject: [PATCH 1/2] profiles: Produce a single-file CA certificate bundle.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* guix/profiles.scm (ca-certificate-bundle): New procedure.
  (profile-derivation): Add 'ca-certificate-bundle?' keyword argument.  If
  true (the default), add the result of 'ca-certificate-bundle' to 'inputs'.

Co-Authored-By: Ludovic Courtès <ludo@gnu.org>
---
 guix/profiles.scm | 91 +++++++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 78 insertions(+), 13 deletions(-)

diff --git a/guix/profiles.scm b/guix/profiles.scm
index a0a259b..5ceba25 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2013, 2014, 2015 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
 ;;; Copyright © 2014 Alex Kost <alezost@gmail.com>
+;;; Copyright © 2015 Mark H Weaver <mhw@netris.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -413,23 +414,87 @@ MANIFEST."
       (gexp->derivation "info-dir" build
                         #:modules '((guix build utils)))))
 
-(define* (profile-derivation manifest #:key (info-dir? #t))
+(define (ca-certificate-bundle manifest)
+  "Return a derivation that builds a single-file bundle containing the CA
+certificates in the /etc/ssl/certs sub-directories of the packages in
+MANIFEST.  Single-file bundles are required by programs such as Git and Lynx."
+  ;; See <http://lists.gnu.org/archive/html/guix-devel/2015-02/msg00429.html>
+  ;; for a discussion.
+
+  (define glibc-utf8-locales                      ;lazy reference
+    (module-ref (resolve-interface '(gnu packages base)) 'glibc-utf8-locales))
+
+  (define build
+    #~(begin
+        (use-modules (guix build utils)
+                     (rnrs io ports)
+                     (srfi srfi-1)
+                     (srfi srfi-26)
+                     (ice-9 ftw))
+
+        (define (pem-file? file)
+          (string-suffix? ".pem" file))
+
+        (define (ca-files top)
+          (let ((cert-dir (string-append top "/etc/ssl/certs")))
+            (map (cut string-append cert-dir "/" <>)
+                 (or (scandir cert-dir pem-file?) '()))))
+
+        (define (concatenate-files files result)
+          "Make RESULT the concatenation of all of FILES."
+          (define (dump file port)
+            (display (call-with-input-file file get-string-all)
+                     port)
+            (newline port))    ;required, see <https://bugs.debian.org/635570>
+
+          (call-with-output-file result
+            (lambda (port)
+              (for-each (cut dump <> port) files))))
+
+        ;; Some file names in the NSS certificates are UTF-8 encoded so
+        ;; install a UTF-8 locale.
+        (setenv "LOCPATH" (string-append #+glibc-utf8-locales "/lib/locale"))
+        (setlocale LC_ALL "en_US.UTF-8")
+
+        (let ((ca-files (append-map ca-files
+                                    '#$(manifest-inputs manifest)))
+              (result   (string-append #$output "/etc/ssl/certs")))
+          (mkdir-p result)
+          (concatenate-files ca-files
+                             (string-append result
+                                            "/ca-certificates.crt")))))
+
+  (gexp->derivation "ca-certificate-bundle" build
+                    #:modules '((guix build utils))
+                    #:local-build? #t))
+
+(define* (profile-derivation manifest
+                             #:key
+                             (info-dir? #t)
+                             (ca-certificate-bundle? #t))
   "Return a derivation that builds a profile (aka. 'user environment') with
-the given MANIFEST.  The profile includes a top-level Info 'dir' file, unless
-INFO-DIR? is #f."
+the given MANIFEST.  The profile includes a top-level Info 'dir' file unless
+INFO-DIR? is #f, and a single-file CA certificate bundle unless
+CA-CERTIFICATE-BUNDLE? is #f."
   (mlet %store-monad ((info-dir (if info-dir?
                                     (info-dir-file manifest)
-                                    (return #f))))
+                                    (return #f)))
+                      (ca-cert-bundle (if ca-certificate-bundle?
+                                          (ca-certificate-bundle manifest)
+                                          (return #f))))
     (define inputs
-      (if info-dir
-          ;; XXX: Here we use the tuple (INFO-DIR "out") just so that the list
-          ;; is unambiguous for the gexp code when MANIFEST has a single input
-          ;; denoted as a string (the pattern (DRV STRING) is normally
-          ;; interpreted in a gexp as "the STRING output of DRV".).  See
-          ;; <http://lists.gnu.org/archive/html/guix-devel/2014-12/msg00292.html>.
-          (cons (list info-dir "out")
-                (manifest-inputs manifest))
-          (manifest-inputs manifest)))
+      ;; XXX: Here we use tuples of the form (DIR "out") just so that the list
+      ;; is unambiguous for the gexp code when MANIFEST has a single input
+      ;; denoted as a string (the pattern (DRV STRING) is normally
+      ;; interpreted in a gexp as "the STRING output of DRV".).  See
+      ;; <http://lists.gnu.org/archive/html/guix-devel/2014-12/msg00292.html>.
+      (append (if info-dir
+                  `((,info-dir "out"))
+                  '())
+              (if ca-cert-bundle
+                  `((,ca-cert-bundle "out"))
+                  '())
+              (manifest-inputs manifest)))
 
     (define builder
       #~(begin
-- 
2.2.1


[-- Attachment #3: [PATCH 2/2] system: Add /etc/ssl symlink; set needed variables in /etc/profile --]
[-- Type: text/x-patch, Size: 2481 bytes --]

From ff4bbad277c43cf17e8a90d9e26daa4ad631ba86 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Tue, 3 Mar 2015 02:14:14 -0500
Subject: [PATCH 2/2] system: Add /etc/ssl symlink; set needed variables in
 /etc/profile.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* gnu/build/activation.scm (activate-etc): Create /etc/ssl symlink.
* gnu/system.scm (etc-directory): Set SSL_CERT_DIR, SSL_CERT_FILE,
  and GIT_SSL_CAINFO in /etc/profile.

Co-Authored-By: Ludovic Courtès <ludo@gnu.org>
---
 gnu/build/activation.scm | 10 ++++++++++
 gnu/system.scm           |  5 +++++
 2 files changed, 15 insertions(+)

diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm
index dfadde3..909e971 100644
--- a/gnu/build/activation.scm
+++ b/gnu/build/activation.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2015 Mark H Weaver <mhw@netris.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -200,6 +201,15 @@ numeric gid or #f."
 
   (format #t "populating /etc from ~a...~%" etc)
 
+  ;; Create the /etc/ssl -> /run/current-system/profile/etc/ssl symlink.  This
+  ;; symlink, to a target outside of the store, probably doesn't belong in the
+  ;; static 'etc' store directory.  However, if it were to be put there,
+  ;; beware that if /run/current-system/profile/etc/ssl doesn't exist at the
+  ;; time of activation (e.g. when installing a fresh system), the call to
+  ;; 'file-is-directory?' below will fail because it uses 'stat', not 'lstat'.
+  (rm-f "/etc/ssl")
+  (symlink "/run/current-system/profile/etc/ssl" "/etc/ssl")
+
   (rm-f "/etc/static")
   (symlink etc "/etc/static")
   (for-each (lambda (file)
diff --git a/gnu/system.scm b/gnu/system.scm
index 8060f74..8075910 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -454,6 +454,11 @@ export EMACSLOADPATH=:/etc/emacs
 # when /etc/machine-id is missing.  Make sure these warnings are non-fatal.
 export DBUS_FATAL_WARNINGS=0
 
+# These variables are honored by OpenSSL (libssl) and Git.
+export SSL_CERT_DIR=/etc/ssl/certs
+export SSL_CERT_FILE=\"$SSL_CERT_DIR/ca-certificates.crt\"
+export GIT_SSL_CAINFO=\"$SSL_CERT_FILE\"
+
 # Allow Aspell to find dictionaries installed in the user profile.
 export ASPELL_CONF=\"dict-dir $HOME/.guix-profile/lib/aspell\"
 "))
-- 
2.2.1

Re: [PATCHES] profiles: Produce a single-file CA certificate bundle

[Mark H Weaver]

I think perhaps that we should be more selective in the certs we add to
ca-certificates.crt.  Debian has a configuration file
/etc/ca-certificates.conf, and only adds certificates that are
explicitly listed there to ca-certificates.crt.

Several of the certs in /etc/ssl/certs have comments like this:

# alias="Bogus Global Trustee"
# trust=
# distrust=CKA_TRUST_CODE_SIGNING CKA_TRUST_EMAIL_PROTECTION CKA_TRUST_SERVER_AUTH
# openssl-distrust=codeSigning emailProtection serverAuth

So it seems that the NSS certificate store may include known-bogus
certificates, perhaps to allow displaying a more severe security warning
than the common case of an unknown CA (e.g. self-signed certificates).

We should find out whether these Bogus untrusted CA certificates are
present in Debian's /etc/ssl/certs, and whether they are present in its
ca-certificates.conf.  We should also determine whether OpenSSL and
GnuTLS pay attention to those "distrust" comments (see above) in the
single-file certificate bundle, and whether they pay attention to them
in the smaller *.pem and hash-named files.

I will investigate later today, but if anyone is inspired to investigate
sooner and report their findings, feel free.  It could be that 993300f6c
and/or e979e6dd523 should be reverted.

      Mark

Re: [PATCHES] profiles: Produce a single-file CA certificate bundle

[Andreas Enge]

On Tue, Mar 03, 2015 at 03:27:57AM -0500, Mark H Weaver wrote:
> I think perhaps that we should be more selective in the certs we add to
> ca-certificates.crt.  Debian has a configuration file
> /etc/ca-certificates.conf, and only adds certificates that are
> explicitly listed there to ca-certificates.crt.

Actually I wondered about the question during the recent Comodo scandal:
Should we remove the Comodo CA certificates from our store?

If we decide to remove certificates, this should not only be done in the
aggregation phase into one file. They should be removed at the end of the
nss-certs build, so that also the single certificate files will disappear.
What is left over can be collected into one file as is done now.

Thanks for looking into this!

Andreas

Re: [PATCHES] profiles: Produce a single-file CA certificate bundle

[Ludovic Courtès]

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

> I think perhaps that we should be more selective in the certs we add to
> ca-certificates.crt.  Debian has a configuration file
> /etc/ca-certificates.conf, and only adds certificates that are
> explicitly listed there to ca-certificates.crt.

Based on what you write, I agree we should be more selective, but I’m
not sure how we can do that.

So far the approach has been to trust Mozilla’s bundle, which is
apparently not such a great idea.  But what can we trust here?

> Several of the certs in /etc/ssl/certs have comments like this:
>
> # alias="Bogus Global Trustee"
> # trust=
> # distrust=CKA_TRUST_CODE_SIGNING CKA_TRUST_EMAIL_PROTECTION CKA_TRUST_SERVER_AUTH
> # openssl-distrust=codeSigning emailProtection serverAuth
>
> So it seems that the NSS certificate store may include known-bogus
> certificates, perhaps to allow displaying a more severe security warning
> than the common case of an unknown CA (e.g. self-signed certificates).
>
> We should find out whether these Bogus untrusted CA certificates are
> present in Debian's /etc/ssl/certs, and whether they are present in its
> ca-certificates.conf.  We should also determine whether OpenSSL and
> GnuTLS pay attention to those "distrust" comments (see above) in the
> single-file certificate bundle, and whether they pay attention to them
> in the smaller *.pem and hash-named files.

Yes.  If not, we may have to look for ‘distrust’ lines in our own code
and get rid of such certificates.

> I will investigate later today, but if anyone is inspired to investigate
> sooner and report their findings, feel free.  It could be that 993300f6c
> and/or e979e6dd523 should be reverted.

That seems orthogonal to me.  What we could do is to change
‘x509-certificates’ to default to an empty bundle, if NSS is deemed
untrustworthy.

Ludo’.

Re: [PATCHES] profiles: Produce a single-file CA certificate bundle

[Ludovic Courtès]

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

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> 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?
>>
>> It’s a good but as of yet unimplemented idea.
>>
>> Although I now realize we could perhaps simple move the
>> ‘certificate-bundle’ procedure to (guix profile), add the certificate
>> package to the system profile, and make /etc/ssl a symlink to
>> /run/current-system/profile/etc/ssl.
>
> I've attached patches that implement this.  They assume that 993300f and
> e979e6d are first reverted.  Comments and suggestions welcome.

Both look good to me.

> It would also be good to add search-path-specifications for
> SSL_CERT_FILE to 'openssl' and GIT_SSL_CAINFO to 'git' in core-updates,
> but I'm not sure how best to do that.  Would you be willing to do it,
> Ludovic?

I just checked the source and OpenSSL itself does not use SSL_CERT_FILE
nor SSL_CERT_DIR at all.  Lynx does use SSL_CERT_FILE, but that’s really
in Lynx, not in libssl.  So I don’t think there should be a search path
specification for OpenSSL.  This is unfortunate, but it looks like we
can’t do much.

We could add that variable to Lynx itself, but it’s not actually a
search path but just a file name.

Thoughts?

> +# These variables are honored by OpenSSL (libssl) and Git.

Replace “OpenSSL (libssl)” by “some applications such as Lynx”.

Thanks,
Ludo’.

Re: [PATCHES] profiles: Produce a single-file CA certificate bundle

[Andreas Enge]

On Tue, Mar 03, 2015 at 01:43:38PM +0100, Ludovic Courtès wrote:
> I just checked the source and OpenSSL itself does not use SSL_CERT_FILE
> nor SSL_CERT_DIR at all.  Lynx does use SSL_CERT_FILE, but that’s really
> in Lynx, not in libssl.  So I don’t think there should be a search path
> specification for OpenSSL.  This is unfortunate, but it looks like we
> can’t do much.

I just did a "strings" and "grep" on the binaries and libs. SSL_CERT_DIR
appears in bin/c_rehash and lib/libcrypto.so, and SSL_CERT_FILE also appears
in the latter.

In the source code,
$ find -type f -exec grep -H SSL_CERT_DIR {} \;
yields:

./crypto/cryptlib.h:# define X509_CERT_DIR_EVP        "SSL_CERT_DIR"
./tools/c_rehash.in:} elsif($ENV{SSL_CERT_DIR}) {
./tools/c_rehash.in:    @dirlist = split /$path_delim/, $ENV{SSL_CERT_DIR};
./tools/c_rehash:} elsif($ENV{SSL_CERT_DIR}) {
./tools/c_rehash:       @dirlist = split /$path_delim/, $ENV{SSL_CERT_DIR};
./doc/apps/c_rehash.pod:processed in turn. If not, then the B<SSL_CERT_DIR> environment variable
./doc/apps/c_rehash.pod:=item B<SSL_CERT_DIR>

and
$ find -type f -exec grep -H SSL_CERT_FILE {} \;

privat@debian:/tmp/openssl-1.0.2$ find -type f -exec grep -H SSL_CERT_FILE {} \;
./crypto/cryptlib.h:# define X509_CERT_FILE_EVP       "SSL_CERT_FILE"

So I think it is used and our search path is fine.

By the way, in the next core-updates round, we may wish to erase the empty
directories ssl/certs and ssl/private.

Andreas

Re: [PATCHES] profiles: Produce a single-file CA certificate bundle

[Mark H Weaver]

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

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I think perhaps that we should be more selective in the certs we add to
>> ca-certificates.crt.  Debian has a configuration file
>> /etc/ca-certificates.conf, and only adds certificates that are
>> explicitly listed there to ca-certificates.crt.
>
> Based on what you write, I agree we should be more selective, but I’m
> not sure how we can do that.
>
> So far the approach has been to trust Mozilla’s bundle, which is
> apparently not such a great idea.  But what can we trust here?

The problem was not Mozilla's certificate bundle, it's how we were using
it.  We initially assumed that it would only contain trusted
certificates, but this is not the case.  They annotate the certificates
with trust metadata that we need to pay attention to.

Debian's ca-certificates package uses a variant of 'certdata2pem.py'
that only outputs trusted certificates.  The variant of that script that
we're using from Fedora outputs untrusted certificates as well, but
Fedora then takes care to install only the trusted ones.

The trust information is more than just a simple boolean.  There are
many distinct "trust types" that can be assigned, e.g. server-auth,
code-signing, email-protection, etc.

Fedora's system for handling CA certificates seems to be vastly more
sophisticated than Debian's.  All of the single-file bundles are
considered "legacy", and Fedora is able to produce multiple bundles
containing certs trusted for different purposes.

Doing this job properly will require more research, but it seems to me
that we should be looking to Fedora for guidance:

  http://pkgs.fedoraproject.org/cgit/ca-certificates.git
  http://pkgs.fedoraproject.org/cgit/openssl.git
  http://pkgs.fedoraproject.org/cgit/gnutls.git

Andreas Enge <andreas@enge.fr> writes:
> If we decide to remove certificates, this should not only be done in the
> aggregation phase into one file. They should be removed at the end of the
> nss-certs build, so that also the single certificate files will disappear.
> What is left over can be collected into one file as is done now.

Agreed.  For now, I've pushed my recently proposed commits (to support
certificate stores in profiles) along with changes to our 'nss-certs'
package to only install certificates that are annotated with a non-empty
"openssl-trust=" comment by our 'certdata2pem.py' (from Fedora).

> On Tue, Mar 03, 2015 at 01:43:38PM +0100, Ludovic Courtès wrote:
>> I just checked the source and OpenSSL itself does not use SSL_CERT_FILE
>> nor SSL_CERT_DIR at all.  Lynx does use SSL_CERT_FILE, but that’s really
>> in Lynx, not in libssl.  So I don’t think there should be a search path
>> specification for OpenSSL.  This is unfortunate, but it looks like we
>> can’t do much.
> 
> I just did a "strings" and "grep" on the binaries and libs. SSL_CERT_DIR
> appears in bin/c_rehash and lib/libcrypto.so, and SSL_CERT_FILE also appears
> in the latter.
> 
> In the source code,
> $ find -type f -exec grep -H SSL_CERT_DIR {} \;
> yields:
> 
> ./crypto/cryptlib.h:# define X509_CERT_DIR_EVP        "SSL_CERT_DIR"
[...]
> ./crypto/cryptlib.h:# define X509_CERT_FILE_EVP       "SSL_CERT_FILE"

Right.  I've forgotten the details, but about a year ago I looked
through the maze of OpenSSL code and determined that at least in some
cases, OpenSSL would honor those variables.  I guess the application can
specify whether or not to load the system trust store.

      Mark

Re: [PATCHES] profiles: Produce a single-file CA certificate bundle

[Ludovic Courtès]

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

> Fedora's system for handling CA certificates seems to be vastly more
> sophisticated than Debian's.  All of the single-file bundles are
> considered "legacy", and Fedora is able to produce multiple bundles
> containing certs trusted for different purposes.
>
> Doing this job properly will require more research, but it seems to me
> that we should be looking to Fedora for guidance:
>
>   http://pkgs.fedoraproject.org/cgit/ca-certificates.git
>   http://pkgs.fedoraproject.org/cgit/openssl.git
>   http://pkgs.fedoraproject.org/cgit/gnutls.git

Indeed, this looks like a useful source of inspiration.

> Andreas Enge <andreas@enge.fr> writes:
>> If we decide to remove certificates, this should not only be done in the
>> aggregation phase into one file. They should be removed at the end of the
>> nss-certs build, so that also the single certificate files will disappear.
>> What is left over can be collected into one file as is done now.
>
> Agreed.  For now, I've pushed my recently proposed commits (to support
> certificate stores in profiles) along with changes to our 'nss-certs'
> package to only install certificates that are annotated with a non-empty
> "openssl-trust=" comment by our 'certdata2pem.py' (from Fedora).

Good.

BTW, since the ‘x509-certificates’ is now gone, I think we should add
‘nss-certs’ to ‘%base-packages’ to get that works-out-of-the-box
property.

WDYT?

Thanks,
Ludo’.

Re: [PATCHES] profiles: Produce a single-file CA certificate bundle

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> privat@debian:/tmp/openssl-1.0.2$ find -type f -exec grep -H SSL_CERT_FILE {} \;
> ./crypto/cryptlib.h:# define X509_CERT_FILE_EVP       "SSL_CERT_FILE"

Indeed, I stand corrected.

And Lynx does fiddle with it, but only when built with GnuTLS:

  #ifdef USE_GNUTLS_INCL
          if ((certfile = LYGetEnv("SSL_CERT_FILE")) != NULL) {

> So I think it is used and our search path is fine.

There’s still the problem that none of these is a search path, though it
works OK for the recommendation that’s printed when installing in a
profile.

So I’ve pushed this as commit da69977 in ‘core-updates’, but we’ll have
to extend ‘search-path-specification’ to describe things like that that
are not search paths.

Thanks,
Ludo’.