| Message ID | 1369031247-2075-1-git-send-email-baruch@tkos.co.il |
|---|---|
| State | Accepted |
| Commit | 1e7f40ebb5cfc58010faf5e8d751de9207dc6a5d |
| Headers | show |
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 >
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
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
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
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>
>>>>> "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.
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
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(-)