Patchwork Revert "dependencies: check that SSL certificates are installed"

login
register
mail settings
Submitter Baruch Siach
Date May 20, 2013, 6:27 a.m.
Message ID <1369031247-2075-1-git-send-email-baruch@tkos.co.il>
Download mbox | patch
Permalink /patch/244851/
State Accepted
Commit 1e7f40ebb5cfc58010faf5e8d751de9207dc6a5d
Headers show

Comments

Baruch Siach - May 20, 2013, 6:27 a.m.
This reverts commit d66cd067f3dc3d5e2479e1e8c05f24fd82329f7a.

SSL certificates are no always installed in /etc/ssl/certs. For example, on
CentOS 5.6 the default OpenSSL certificates directory is /etc/pki/tls/certs,
and wget can download using https without any problem.

Moreover, the existence of /etc/ssl/certs does not guarantee the presence of a
CA certificates bundle even on Debian. On my current Debian testing
installation the openssl package itself creates an empty /etc/ssl/certs
directory.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
 support/dependencies/dependencies.sh |    9 ---------
 1 file changed, 9 deletions(-)
Baruch Siach - May 26, 2013, 2:47 a.m.
Hi Thomas,

On Mon, May 20, 2013 at 09:27:27AM +0300, Baruch Siach wrote:
> This reverts commit d66cd067f3dc3d5e2479e1e8c05f24fd82329f7a.
> 
> SSL certificates are no always installed in /etc/ssl/certs. For example, on
> CentOS 5.6 the default OpenSSL certificates directory is /etc/pki/tls/certs,
> and wget can download using https without any problem.
> 
> Moreover, the existence of /etc/ssl/certs does not guarantee the presence of a
> CA certificates bundle even on Debian. On my current Debian testing
> installation the openssl package itself creates an empty /etc/ssl/certs
> directory.
> 
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---

As the author of d66cd067f3, what do you think?

baruch

>  support/dependencies/dependencies.sh |    9 ---------
>  1 file changed, 9 deletions(-)
> 
> diff --git a/support/dependencies/dependencies.sh b/support/dependencies/dependencies.sh
> index ce4d9e1..0b44c5a 100755
> --- a/support/dependencies/dependencies.sh
> +++ b/support/dependencies/dependencies.sh
> @@ -200,12 +200,3 @@ if ! perl  -e "require Data::Dumper" > /dev/null 2>&1 ; then
>      /bin/echo -e "On Debian/Ubuntu distributions, install the 'perl' package."
>      exit 1
>  fi
> -
> -# Check that we have the SSL certificates to make https:// downloads
> -# work.
> -if ! test -d /etc/ssl/certs; then
> -    /bin/echo -e "Your system lacks Common CA certificates for SSL."
> -    /bin/echo -e "This prevents https:// downloads from succeeding."
> -    /bin/echo -e "On Debian/Ubuntu distributions, install 'ca-certificates' package."
> -    exit 1
> -fi
> -- 
> 1.7.10.4
>
Spenser Gilliland - May 26, 2013, 3:21 a.m.
Just wanted to chime in say that I can confirm this is a bug on
CentOS/RHEL 5 systems.

Spenser

On Sat, May 25, 2013 at 9:47 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Thomas,
>
> On Mon, May 20, 2013 at 09:27:27AM +0300, Baruch Siach wrote:
>> This reverts commit d66cd067f3dc3d5e2479e1e8c05f24fd82329f7a.
>>
>> SSL certificates are no always installed in /etc/ssl/certs. For example, on
>> CentOS 5.6 the default OpenSSL certificates directory is /etc/pki/tls/certs,
>> and wget can download using https without any problem.
>>
>> Moreover, the existence of /etc/ssl/certs does not guarantee the presence of a
>> CA certificates bundle even on Debian. On my current Debian testing
>> installation the openssl package itself creates an empty /etc/ssl/certs
>> directory.
>>
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> ---
>
> As the author of d66cd067f3, what do you think?
>
> baruch
>
>>  support/dependencies/dependencies.sh |    9 ---------
>>  1 file changed, 9 deletions(-)
>>
>> diff --git a/support/dependencies/dependencies.sh b/support/dependencies/dependencies.sh
>> index ce4d9e1..0b44c5a 100755
>> --- a/support/dependencies/dependencies.sh
>> +++ b/support/dependencies/dependencies.sh
>> @@ -200,12 +200,3 @@ if ! perl  -e "require Data::Dumper" > /dev/null 2>&1 ; then
>>      /bin/echo -e "On Debian/Ubuntu distributions, install the 'perl' package."
>>      exit 1
>>  fi
>> -
>> -# Check that we have the SSL certificates to make https:// downloads
>> -# work.
>> -if ! test -d /etc/ssl/certs; then
>> -    /bin/echo -e "Your system lacks Common CA certificates for SSL."
>> -    /bin/echo -e "This prevents https:// downloads from succeeding."
>> -    /bin/echo -e "On Debian/Ubuntu distributions, install 'ca-certificates' package."
>> -    exit 1
>> -fi
>> --
>> 1.7.10.4
>>
>
> --
>      http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>    - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Thomas Petazzoni - May 26, 2013, 7:49 a.m.
Dear Baruch Siach,

On Sun, 26 May 2013 05:47:07 +0300, Baruch Siach wrote:
> Hi Thomas,
> 
> On Mon, May 20, 2013 at 09:27:27AM +0300, Baruch Siach wrote:
> > This reverts commit d66cd067f3dc3d5e2479e1e8c05f24fd82329f7a.
> > 
> > SSL certificates are no always installed in /etc/ssl/certs. For example, on
> > CentOS 5.6 the default OpenSSL certificates directory is /etc/pki/tls/certs,
> > and wget can download using https without any problem.
> > 
> > Moreover, the existence of /etc/ssl/certs does not guarantee the presence of a
> > CA certificates bundle even on Debian. On my current Debian testing
> > installation the openssl package itself creates an empty /etc/ssl/certs
> > directory.
> > 
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> 
> As the author of d66cd067f3, what do you think?

Well, d66cd067f3 was written because if you install a very minimal
system, you may not have the SSL certificates installed, which prevents
any download from https:// website. So I added a quick check for that.

However, apparently, the location of such certificates is not fixed
between various systems, so clearly my patch doesn't work properly.

I see two options here:

 (1) Apply your patch, and assume that in most systems, SSL
     certificates are always installed. The case I had what when you
     create a very minimal Debian system, but most people probably use
     a more full-featured system, and it's pretty likely that SSL
     certificates are already installed.

 (2) Replace the test by a test that wget some well-known https:// URL,
     and if it doesn't work, say that SSL certificates are not
     available. But I don't like this too much, because this means that
     at every invocation of 'make', Buildroot will try to download
     something from the network.

So, for now, I believe option (1) is the only viable one, unless there
is some local command that allows to check whether SSL certificates are
installed or not.

Best regards,

Thomas
Baruch Siach - May 26, 2013, 8:24 a.m.
Hi Thomas,

On Sun, May 26, 2013 at 09:49:20AM +0200, Thomas Petazzoni wrote:
> On Sun, 26 May 2013 05:47:07 +0300, Baruch Siach wrote:
> > On Mon, May 20, 2013 at 09:27:27AM +0300, Baruch Siach wrote:
> > > This reverts commit d66cd067f3dc3d5e2479e1e8c05f24fd82329f7a.
> > > 
> > > SSL certificates are no always installed in /etc/ssl/certs. For example, on
> > > CentOS 5.6 the default OpenSSL certificates directory is /etc/pki/tls/certs,
> > > and wget can download using https without any problem.
> > > 
> > > Moreover, the existence of /etc/ssl/certs does not guarantee the presence of a
> > > CA certificates bundle even on Debian. On my current Debian testing
> > > installation the openssl package itself creates an empty /etc/ssl/certs
> > > directory.
> > > 
> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > ---
> > 
> > As the author of d66cd067f3, what do you think?
> 
> Well, d66cd067f3 was written because if you install a very minimal
> system, you may not have the SSL certificates installed, which prevents
> any download from https:// website. So I added a quick check for that.

How about adding a config option (disabled by default) that adds 
--no-check-certificate to the wget command? We may event monitor the wget exit 
status and advice the user to enable this options when we see the status = 5 
(SSL verification failure).

> However, apparently, the location of such certificates is not fixed
> between various systems, so clearly my patch doesn't work properly.

Well, 'openssl version -d' does give you the default location where OpenSSL 
expects certificates to be. However, as I said in the commit log, the presence 
of this directory doesn't necessarily mean that you actually have any 
certificate in this location. On Debian if you uninstall ca-certificates 
you'll still have /etc/ssh/certs.

> I see two options here:
> 
>  (1) Apply your patch, and assume that in most systems, SSL
>      certificates are always installed. The case I had what when you
>      create a very minimal Debian system, but most people probably use
>      a more full-featured system, and it's pretty likely that SSL
>      certificates are already installed.
> 
>  (2) Replace the test by a test that wget some well-known https:// URL,
>      and if it doesn't work, say that SSL certificates are not
>      available. But I don't like this too much, because this means that
>      at every invocation of 'make', Buildroot will try to download
>      something from the network.
> 
> So, for now, I believe option (1) is the only viable one, unless there
> is some local command that allows to check whether SSL certificates are
> installed or not.

So is this an Acked-by from you?

baruch
Thomas Petazzoni - May 26, 2013, 8:27 a.m.
Dear Baruch Siach,

On Sun, 26 May 2013 11:24:36 +0300, Baruch Siach wrote:

> > Well, d66cd067f3 was written because if you install a very minimal
> > system, you may not have the SSL certificates installed, which prevents
> > any download from https:// website. So I added a quick check for that.
> 
> How about adding a config option (disabled by default) that adds 
> --no-check-certificate to the wget command? We may event monitor the wget exit 
> status and advice the user to enable this options when we see the status = 5 
> (SSL verification failure).

Hum, I believe it's not very wise to encourage users to use
--no-check-certificate.

> > However, apparently, the location of such certificates is not fixed
> > between various systems, so clearly my patch doesn't work properly.
> 
> Well, 'openssl version -d' does give you the default location where OpenSSL 
> expects certificates to be. However, as I said in the commit log, the presence 
> of this directory doesn't necessarily mean that you actually have any 
> certificate in this location. On Debian if you uninstall ca-certificates 
> you'll still have /etc/ssh/certs.

Ok.

> > So, for now, I believe option (1) is the only viable one, unless there
> > is some local command that allows to check whether SSL certificates are
> > installed or not.
> 
> So is this an Acked-by from you?

Yes:

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Peter Korsgaard - May 26, 2013, 9:14 a.m.
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

 Baruch> This reverts commit d66cd067f3dc3d5e2479e1e8c05f24fd82329f7a.

 Baruch> SSL certificates are no always installed in /etc/ssl/certs. For
 Baruch> example, on CentOS 5.6 the default OpenSSL certificates
 Baruch> directory is /etc/pki/tls/certs, and wget can download using
 Baruch> https without any problem.

 Baruch> Moreover, the existence of /etc/ssl/certs does not guarantee
 Baruch> the presence of a CA certificates bundle even on Debian. On my
 Baruch> current Debian testing installation the openssl package itself
 Baruch> creates an empty /etc/ssl/certs directory.

Committed, thanks.

Patch

diff --git a/support/dependencies/dependencies.sh b/support/dependencies/dependencies.sh
index ce4d9e1..0b44c5a 100755
--- a/support/dependencies/dependencies.sh
+++ b/support/dependencies/dependencies.sh
@@ -200,12 +200,3 @@  if ! perl  -e "require Data::Dumper" > /dev/null 2>&1 ; then
     /bin/echo -e "On Debian/Ubuntu distributions, install the 'perl' package."
     exit 1
 fi
-
-# Check that we have the SSL certificates to make https:// downloads
-# work.
-if ! test -d /etc/ssl/certs; then
-    /bin/echo -e "Your system lacks Common CA certificates for SSL."
-    /bin/echo -e "This prevents https:// downloads from succeeding."
-    /bin/echo -e "On Debian/Ubuntu distributions, install 'ca-certificates' package."
-    exit 1
-fi