Revert "dependencies: check that SSL certificates are installed"

Submitted by Baruch Siach on May 20, 2013, 6:27 a.m.

Details

Message ID 1369031247-2075-1-git-send-email-baruch@tkos.co.il
State Accepted
Commit 1e7f40ebb5cfc58010faf5e8d751de9207dc6a5d
Headers show

Commit Message

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(-)

Comments

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 hide | download patch | download mbox

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