[Buildroot] [psa] various server software upgrades

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

the busybox.net software has been languishing for quite a long time,
so i gave it a strong kick today.  just about every piece of software
has been upgraded on the box including bugzilla.  my various testing
looks like it still works, but if you guys notice anything weird, feel
free to let me know.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151202/133c330c/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Lionel Orry]

Hi,

On Wed, Dec 2, 2015 at 8:35 AM, Mike Frysinger <vapier@gentoo.org> wrote:

> the busybox.net software has been languishing for quite a long time,
> so i gave it a strong kick today.  just about every piece of software
> has been upgraded on the box including bugzilla.  my various testing
> looks like it still works, but if you guys notice anything weird, feel
> free to let me know.
> -mike
>

?Thank you for that. I don't know if it's related but the "Recent commits"
and "Recent discussions" streams normally displayed on?

?the buildroot homepage are empty...
?

>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>

?Cheers,
Lionel?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151202/7aedec11/attachment.html>

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Lionel" == Lionel Orry <lionel.orry@gmail.com> writes:

Hi,

 > Hi,
 > On Wed, Dec 2, 2015 at 8:35 AM, Mike Frysinger <vapier@gentoo.org> wrote:

 >> the busybox.net software has been languishing for quite a long time,
 >> so i gave it a strong kick today.  just about every piece of software
 >> has been upgraded on the box including bugzilla.  my various testing
 >> looks like it still works, but if you guys notice anything weird, feel
 >> free to let me know.
 >> -mike

Thanks for doing the update Mike! We had some issues with old (dsa) ssh
keys, but that is fixed now.

 > ?Thank you for that. I don't know if it's related but the "Recent commits"
 > and "Recent discussions" streams normally displayed on?

 > ?the buildroot homepage are empty...

I don't think this is related. Looking closer, it seems like the Google
API the website used is no longer available :/

E.G.:

https://www.google.com/uds/Gfeeds?callback=google.feeds.Feed.RawCompletion&context=0&num=30&hl=en&output=json&q=http%3A%2F%2Frss.gmane.org%2Ftopics%2Fexcerpts%2Fgmane.comp.lib.uclibc.buildroot&key=notsupplied&v=1.0&nocache=1449045352617

Returns:

/* callback */google.feeds.Feed.RawCompletion('0', null, 403, 'This API is no longer available.', 200)

The API page (https://developers.google.com/feed/) says:

This API is officially deprecated. See our deprecation policy in our
Terms of Service for details.

Angelo, any idea how to fix this? Googling around I see:

http://blog.superfeedr.com/google-feed-api-alternative/

But ideally we shouldn't depend on any extra external API for this.

-- 
Bye, Peter Korsgaard

[Buildroot] [psa] various server software upgrades

[Nikolay Dimitrov]

Hi Mike,

On 12/02/2015 09:35 AM, Mike Frysinger wrote:
> the busybox.net software has been languishing for quite a long time,
> so i gave it a strong kick today.  just about every piece of software
> has been upgraded on the box including bugzilla.  my various testing
> looks like it still works, but if you guys notice anything weird, feel
> free to let me know.
> -mike

I started seeing this warning in the last few days:

Cloning into 'buildroot'...
remote: warning: unable to access '/root/.config/git/attributes': 
Permission denied
...

Regards,
Nikolay

[Buildroot] [psa] various server software upgrades

[Nikolay Dimitrov]

Oops...

On 12/02/2015 11:25 AM, Nikolay Dimitrov wrote:
> Hi Mike,
>
> On 12/02/2015 09:35 AM, Mike Frysinger wrote:
>> the busybox.net software has been languishing for quite a long time,
>> so i gave it a strong kick today.  just about every piece of software
>> has been upgraded on the box including bugzilla.  my various testing
>> looks like it still works, but if you guys notice anything weird, feel
>> free to let me know.
>> -mike
>
> I started seeing this warning in the last few days:
>
> Cloning into 'buildroot'...
> remote: warning: unable to access '/root/.config/git/attributes':
> Permission denied
> ...
>
> Regards,
> Nikolay

My bad... Please read my comment as follows:

"I observed the issue this morning, when cloning the repo".

Sorry for the confusion :D

Regards,
Nikolay

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 02 Dec 2015 11:25, Nikolay Dimitrov wrote:
> On 12/02/2015 09:35 AM, Mike Frysinger wrote:
> > the busybox.net software has been languishing for quite a long time,
> > so i gave it a strong kick today.  just about every piece of software
> > has been upgraded on the box including bugzilla.  my various testing
> > looks like it still works, but if you guys notice anything weird, feel
> > free to let me know.
> > -mike
> 
> I started seeing this warning in the last few days:
> 
> Cloning into 'buildroot'...
> remote: warning: unable to access '/root/.config/git/attributes': 
> Permission denied
> ...

i fixed that once, but my fix was reset.  i've made it work in a diff
way now though so you shouldn't see that again.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151202/90d0632a/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Nikolay Dimitrov]

Hi Mike,

On 12/02/2015 07:31 PM, Mike Frysinger wrote:
> On 02 Dec 2015 11:25, Nikolay Dimitrov wrote:
>> On 12/02/2015 09:35 AM, Mike Frysinger wrote:
>>> the busybox.net software has been languishing for quite a long time,
>>> so i gave it a strong kick today.  just about every piece of software
>>> has been upgraded on the box including bugzilla.  my various testing
>>> looks like it still works, but if you guys notice anything weird, feel
>>> free to let me know.
>>> -mike
>>
>> I started seeing this warning in the last few days:
>>
>> Cloning into 'buildroot'...
>> remote: warning: unable to access '/root/.config/git/attributes':
>> Permission denied
>> ...
>
> i fixed that once, but my fix was reset.  i've made it work in a diff
> way now though so you shouldn't see that again.
> -mike

Seems to work better now. Thanks!

Regards,
Nikolay

[Buildroot] [psa] various server software upgrades

[Yann E. MORIN]

Hello Mike,

On 2015-12-02 02:35 -0500, Mike Frysinger spake thusly:
> the busybox.net software has been languishing for quite a long time,
> so i gave it a strong kick today.  just about every piece of software
> has been upgraded on the box including bugzilla.  my various testing
> looks like it still works, but if you guys notice anything weird, feel
> free to let me know.

Yes, I've noticed that buildroot.org has switched to https with:
    Strict-Transport-Security: max-age=63072000; includeSubDomains

Unfortunately, we do have subdomains that are not https-enabled, and are
on another machine:
    http://autobuild.buildroot.org/

But now, because of https-sts, this sub-domain is no longer reachable.

To be noted, once a browser has seen the hsts settings once, it will keep
them for how long it has been specified, that is 63072000 seconds in our
case, which is about 730 days, or 2 years.

Which means anyone that has visited buildroot.org will be blocked from
the sub-domains for the next two years (unles sthey switch to https
too).

What can we do about this?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Hello Mike,
 > On 2015-12-02 02:35 -0500, Mike Frysinger spake thusly:
 >> the busybox.net software has been languishing for quite a long time,
 >> so i gave it a strong kick today.  just about every piece of software
 >> has been upgraded on the box including bugzilla.  my various testing
 >> looks like it still works, but if you guys notice anything weird, feel
 >> free to let me know.

 > Yes, I've noticed that buildroot.org has switched to https with:
 >     Strict-Transport-Security: max-age=63072000; includeSubDomains

 > Unfortunately, we do have subdomains that are not https-enabled, and are
 > on another machine:
 >     http://autobuild.buildroot.org/

sources.buildroot.{org,net} is another example (even though that it
normally only accessed from wget, so less critical).

We have the same problem for lists.{buildroot,busybox,uclibc}.*, as that
ends up serving an osuosl certificate.

We also have nightly.buildroot.{org,net} for the nightly generated
manual.

And finally we have patchwork.buildroot.{org,net} which redirects to the
ozlabs patchwork.

 > Which means anyone that has visited buildroot.org will be blocked from
 > the sub-domains for the next two years (unles sthey switch to https
 > too).

:/

 > What can we do about this?

Step 1 should imho be to disable HTST as soon as possible. Then we might
consider if we could HTTPS enable some of these subdomains, but they are
on different hosts, which complicates stuff (E.G. we presumably need to
distribute the buildroot.org private keys and update everywhere every 90
days).

-- 
Bye, Peter Korsgaard

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 06 Dec 2015 23:00, Peter Korsgaard wrote:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> 
>  > Hello Mike,
>  > On 2015-12-02 02:35 -0500, Mike Frysinger spake thusly:
>  >> the busybox.net software has been languishing for quite a long time,
>  >> so i gave it a strong kick today.  just about every piece of software
>  >> has been upgraded on the box including bugzilla.  my various testing
>  >> looks like it still works, but if you guys notice anything weird, feel
>  >> free to let me know.
> 
>  > Yes, I've noticed that buildroot.org has switched to https with:
>  >     Strict-Transport-Security: max-age=63072000; includeSubDomains
> 
>  > Unfortunately, we do have subdomains that are not https-enabled, and are
>  > on another machine:
>  >     http://autobuild.buildroot.org/
> 
> sources.buildroot.{org,net} is another example (even though that it
> normally only accessed from wget, so less critical).

there's really no reason you can't generate a cert for those domains using
let's encrypt.  let's encrypt doesn't require you to own the root domain,
just be in control of the web server the domain resolves to.

> We have the same problem for lists.{buildroot,busybox,uclibc}.*, as that
> ends up serving an osuosl certificate.

those aren't a new issue ... they've always used osuosl certs.  those are
out of my control.

> We also have nightly.buildroot.{org,net} for the nightly generated
> manual.

you should also gen certs for those

> And finally we have patchwork.buildroot.{org,net} which redirects to the
> ozlabs patchwork.

gen certs for them.  if you can't, assign the IP to the main buildroot.org
box and i can take care of it.

>  > Which means anyone that has visited buildroot.org will be blocked from
>  > the sub-domains for the next two years (unles sthey switch to https
>  > too).
> 
> :/
> 
>  > What can we do about this?
> 
> Step 1 should imho be to disable HTST as soon as possible.

i've turned of HTST for subdomains for buildroot.org/buildroot.net.  i'm
leaving it on for the domains served directly off the box, and for all
uclibc.org and busybox.net domains.

> Then we might
> consider if we could HTTPS enable some of these subdomains, but they are
> on different hosts, which complicates stuff (E.G. we presumably need to
> distribute the buildroot.org private keys and update everywhere every 90
> days).

there is no need to distribute the same keys here.  just generate ones
for the domains in question using let's encrypt.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151206/7cc00c66/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

Hi,

 >> > Unfortunately, we do have subdomains that are not https-enabled, and are
 >> > on another machine:
 >> >     http://autobuild.buildroot.org/
 >> 
 >> sources.buildroot.{org,net} is another example (even though that it
 >> normally only accessed from wget, so less critical).

 > there's really no reason you can't generate a cert for those domains using
 > let's encrypt.  let's encrypt doesn't require you to own the root domain,
 > just be in control of the web server the domain resolves to.

Ok, but for sources.buildroot.net I wouldn't want to enforce TLS as
E.G. wget on ancient enterprice dists wont recognize the CA and fail.


 >> We have the same problem for lists.{buildroot,busybox,uclibc}.*, as that
 >> ends up serving an osuosl certificate.

 > those aren't a new issue ... they've always used osuosl certs.  those are
 > out of my control.

Yes, but with the HSTS headers we now force people to access it through
https, and atleast my browser won't allow it because the certificate
doesn't match.


 >> > What can we do about this?
 >> 
 >> Step 1 should imho be to disable HTST as soon as possible.

 > i've turned of HTST for subdomains for buildroot.org/buildroot.net.  i'm
 > leaving it on for the domains served directly off the box, and for all
 > uclibc.org and busybox.net domains.

Ok, great - Thanks. The fact that you still have it enabled on busybox
means that lists.busybox.net (which is referred in the list- headers)
won't work, so it would be good if you could also disable
includeSubDomains there.


 >> Then we might
 >> consider if we could HTTPS enable some of these subdomains, but they are
 >> on different hosts, which complicates stuff (E.G. we presumably need to
 >> distribute the buildroot.org private keys and update everywhere every 90
 >> days).

 > there is no need to distribute the same keys here.  just generate ones
 > for the domains in question using let's encrypt.

I'll have a look at generating letsencrypt keys for nightly.* and
patchwork.*.

Any specific hints about it?

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

Hi,

 >> > Unfortunately, we do have subdomains that are not https-enabled, and are
 >> > on another machine:
 >> >     http://autobuild.buildroot.org/
 >> 
 >> sources.buildroot.{org,net} is another example (even though that it
 >> normally only accessed from wget, so less critical).

 > there's really no reason you can't generate a cert for those domains using
 > let's encrypt.  let's encrypt doesn't require you to own the root domain,
 > just be in control of the web server the domain resolves to.

FYI, there also seems to be an issue with the git.* certificates and
atleast python on the box, as I get this when pushing:

Counting objects: 28, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (28/28), done.
Writing objects: 100% (28/28), 5.06 KiB | 0 bytes/s, done.
Total 28 (delta 19), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote:   File "/usr/bin/irkerhook.py", line 499, in <module>
remote:     ship(extractor, commit, not notify)
remote:   File "/usr/bin/irkerhook.py", line 436, in ship
remote:     privmsg = unicode(metadata)
remote:   File "/usr/bin/irkerhook.py", line 74, in __unicode__
remote:     if urllib.urlopen(webview).getcode() == 404:
remote:   File "/usr/lib/python2.7/urllib.py", line 87, in urlopen
remote:     return opener.open(url)
remote:   File "/usr/lib/python2.7/urllib.py", line 213, in open
remote:     return getattr(self, name)(url)
remote:   File "/usr/lib/python2.7/urllib.py", line 364, in open_http
remote:     return self.http_error(url, fp, errcode, errmsg, headers)
remote:   File "/usr/lib/python2.7/urllib.py", line 377, in http_error
remote:     result = method(url, fp, errcode, errmsg, headers)
remote:   File "/usr/lib/python2.7/urllib.py", line 671, in http_error_301
remote:     return self.http_error_302(url, fp, errcode, errmsg, headers, data)
remote:   File "/usr/lib/python2.7/urllib.py", line 641, in http_error_302
remote:     data)
remote:   File "/usr/lib/python2.7/urllib.py", line 667, in redirect_internal
remote:     return self.open(newurl)
remote:   File "/usr/lib/python2.7/urllib.py", line 213, in open
remote:     return getattr(self, name)(url)
remote:   File "/usr/lib/python2.7/urllib.py", line 443, in open_https
remote:     h.endheaders(data)
remote:   File "/usr/lib/python2.7/httplib.py", line 1049, in endheaders
remote:     self._send_output(message_body)
remote:   File "/usr/lib/python2.7/httplib.py", line 893, in _send_output
remote:     self.send(msg)
remote:   File "/usr/lib/python2.7/httplib.py", line 855, in send
remote:     self.connect()
remote:   File "/usr/lib/python2.7/httplib.py", line 1274, in connect
remote:     server_hostname=server_hostname)
remote:   File "/usr/lib/python2.7/ssl.py", line 352, in wrap_socket
remote:     _context=self)
remote:   File "/usr/lib/python2.7/ssl.py", line 579, in __init__
remote:     self.do_handshake()
remote:   File "/usr/lib/python2.7/ssl.py", line 816, in do_handshake
remote:     match_hostname(self.getpeercert(), self.server_hostname)
remote:   File "/usr/lib/python2.7/ssl.py", line 275, in match_hostname
remote:     % (hostname, dnsnames[0]))
remote: ssl.CertificateError: hostname 'git.busybox.net' doesn't match 'git.buildroot.org'
To ssh://buildroot.net/var/lib/git/buildroot.git
   f8daafd..1682aee  master -> master

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:

 > remote: ssl.CertificateError: hostname 'git.busybox.net' doesn't match 'git.buildroot.org'
 > To ssh://buildroot.net/var/lib/git/buildroot.git
 >    f8daafd..1682aee  master -> master

FYI, it seems to be because of the redirects:

http://git.buildroot.{org,net} redirects to https://git.busybox.net but
certificate is for git.buildroot.org

https://git.buildroot.org is ok

https://git.buildroot.net is nok as certificate is only for
git.buildroot.org

-- 
Bye, Peter Korsgaard

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 07 Dec 2015 07:34, Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
> 
>  >> > Unfortunately, we do have subdomains that are not https-enabled, and are
>  >> > on another machine:
>  >> >     http://autobuild.buildroot.org/
>  >> 
>  >> sources.buildroot.{org,net} is another example (even though that it
>  >> normally only accessed from wget, so less critical).
> 
>  > there's really no reason you can't generate a cert for those domains using
>  > let's encrypt.  let's encrypt doesn't require you to own the root domain,
>  > just be in control of the web server the domain resolves to.
> 
> Ok, but for sources.buildroot.net I wouldn't want to enforce TLS as
> E.G. wget on ancient enterprice dists wont recognize the CA and fail.

are you sure about that ?  LE's CA is cross-signed and has pretty good support:
https://community.letsencrypt.org/t/which-browsers-and-operating-systems-support-lets-encrypt/4394

>  >> We have the same problem for lists.{buildroot,busybox,uclibc}.*, as that
>  >> ends up serving an osuosl certificate.
> 
>  > those aren't a new issue ... they've always used osuosl certs.  those are
>  > out of my control.
> 
> Yes, but with the HSTS headers we now force people to access it through
> https, and atleast my browser won't allow it because the certificate
> doesn't match.

so click through the warning message.  firefox/chrome/etc... have no problem
here.

>  >> Then we might
>  >> consider if we could HTTPS enable some of these subdomains, but they are
>  >> on different hosts, which complicates stuff (E.G. we presumably need to
>  >> distribute the buildroot.org private keys and update everywhere every 90
>  >> days).
> 
>  > there is no need to distribute the same keys here.  just generate ones
>  > for the domains in question using let's encrypt.
> 
> I'll have a look at generating letsencrypt keys for nightly.* and
> patchwork.*.
> 
> Any specific hints about it?

$ letsencrypt certonly --webroot --webroot-path /path/to/your/webserver/ \
	-d main-dns-name -d an-alias-if-you-have-one -d more...

so for bugzilla i used:
$ letsencrypt certonly --webroot \
	--webroot-path /var/www/bugstest.busybox.net/htdocs/ \
	-d bugstest.busybox.net -d bugstest.uclibc.org -d bugstest.buildroot.net \
	-d bugstest.buildroot.org
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151207/b2df0a80/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 07 Dec 2015 09:00, Peter Korsgaard wrote:
> FYI, there also seems to be an issue with the git.* certificates and
> atleast python on the box, as I get this when pushing:

the certs shouldn't be causing issues with `git push` ...
i'll take a look at that
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151207/384f3b17/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 07 Dec 2015 13:52, Mike Frysinger wrote:
> On 07 Dec 2015 09:00, Peter Korsgaard wrote:
> > FYI, there also seems to be an issue with the git.* certificates and
> > atleast python on the box, as I get this when pushing:
> 
> the certs shouldn't be causing issues with `git push` ...
> i'll take a look at that

was there a commit bot operating in #buildroot ?  i can't find references
to the client that actually connected to freenode.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151207/9c3caea2/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Yann E. MORIN]

Mike, All,

On 2015-12-07 14:57 -0500, Mike Frysinger spake thusly:
> On 07 Dec 2015 13:52, Mike Frysinger wrote:
> > On 07 Dec 2015 09:00, Peter Korsgaard wrote:
> > > FYI, there also seems to be an issue with the git.* certificates and
> > > atleast python on the box, as I get this when pushing:
> > 
> > the certs shouldn't be causing issues with `git push` ...
> > i'll take a look at that
> 
> was there a commit bot operating in #buildroot ?  i can't find references
> to the client that actually connected to freenode.

Yes, we add a commit bot, but it disapeared a while ago.

I tried to follow the explanations to launmch it again, but it did not
work (and I'm no longer sudoer, so I could not dedicate mor etime on it).

It would be nice if you could re-launch it, yes! ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

Hi,

>> Ok, but for sources.buildroot.net I wouldn't want to enforce TLS as
 >> E.G. wget on ancient enterprice dists wont recognize the CA and fail.

 > are you sure about that ?  LE's CA is cross-signed and has pretty good support:
 > https://community.letsencrypt.org/t/which-browsers-and-operating-systems-support-lets-encrypt/4394

I'm not 100% sure, but we have had various issues in the
past. E.G. checking with an old wget version here I see it can no longer
download our tarballs:

wget http://buildroot.org/downloads/buildroot-2015.11.1.tar.gz
--2015-12-07 21:29:37--  http://buildroot.org/downloads/buildroot-2015.11.1.tar.gz
Resolving buildroot.org... 140.211.167.224
Connecting to buildroot.org|140.211.167.224|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://buildroot.org/downloads/buildroot-2015.11.1.tar.gz [following]
--2015-12-07 21:29:37--  https://buildroot.org/downloads/buildroot-2015.11.1.tar.gz
Connecting to buildroot.org|140.211.167.224|:443... connected.
ERROR: certificate common name `bugs.busybox.net' doesn't match requested host name `buildroot.org'.
To connect to buildroot.org insecurely, use `--no-check-certificate'.

(this is with wget 1.12 from 2009).

Now, this isn't about the letsencrypt CA as such, but presumably because
it doesn't understand SNI - But the end result is the same.

I would actually prefer if we only enforce https where it matters,
E.G. on bugs.*. We can (and SHOULD now that we've uses the HSTS headers)
support https on the other subdomains, but I don't think we should
redirect http to https.

 >> >> We have the same problem for lists.{buildroot,busybox,uclibc}.*, as that
 >> >> ends up serving an osuosl certificate.
 >> 
 >> > those aren't a new issue ... they've always used osuosl certs.  those are
 >> > out of my control.

Yes, but when we sent HSTS headers with includeSubDomains I atleast get
the following error in chromium:

lists.busybox.net normally uses encryption to protect your
information. When Chromium tried to connect to lists.busybox.net this
time, the website sent back unusual and incorrect credentials. Either an
attacker is trying to pretend to be lists.busybox.net, or a Wi-Fi
sign-in screen has interrupted the connection. Your information is still
secure because Chromium stopped the connection before any data was
exchanged.

You cannot visit lists.busybox.net right now because the website uses
HSTS. Network errors and attacks are usually temporary, so this page
will probably work later.

NET::ERR_CERT_COMMON_NAME_INVALID

With no option of continuing.


>> Yes, but with the HSTS headers we now force people to access it through
 >> https, and atleast my browser won't allow it because the certificate
 >> doesn't match.

 > so click through the warning message.  firefox/chrome/etc... have no problem
 > here.

See above, not possible with atleast chromium after it has seen HSTS
with includeSubDomains.


 >> > there is no need to distribute the same keys here.  just generate ones
 >> > for the domains in question using let's encrypt.
 >> 
 >> I'll have a look at generating letsencrypt keys for nightly.* and
 >> patchwork.*.
 >> 
 >> Any specific hints about it?

 > $ letsencrypt certonly --webroot --webroot-path /path/to/your/webserver/ \
 > 	-d main-dns-name -d an-alias-if-you-have-one -d more...

Thanks!

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

 > On 07 Dec 2015 09:00, Peter Korsgaard wrote:
 >> FYI, there also seems to be an issue with the git.* certificates and
 >> atleast python on the box, as I get this when pushing:

 > the certs shouldn't be causing issues with `git push` ...
 > i'll take a look at that

It is from the irkerhook.py script.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 07 Dec 2015 21:37, Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
> 
> >> Ok, but for sources.buildroot.net I wouldn't want to enforce TLS as
>  >> E.G. wget on ancient enterprice dists wont recognize the CA and fail.
> 
>  > are you sure about that ?  LE's CA is cross-signed and has pretty good support:
>  > https://community.letsencrypt.org/t/which-browsers-and-operating-systems-support-lets-encrypt/4394
> 
> I'm not 100% sure, but we have had various issues in the
> past. E.G. checking with an old wget version here I see it can no longer
> download our tarballs:
> 
> wget http://buildroot.org/downloads/buildroot-2015.11.1.tar.gz
> --2015-12-07 21:29:37--  http://buildroot.org/downloads/buildroot-2015.11.1.tar.gz
> Resolving buildroot.org... 140.211.167.224
> Connecting to buildroot.org|140.211.167.224|:80... connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://buildroot.org/downloads/buildroot-2015.11.1.tar.gz [following]
> --2015-12-07 21:29:37--  https://buildroot.org/downloads/buildroot-2015.11.1.tar.gz
> Connecting to buildroot.org|140.211.167.224|:443... connected.
> ERROR: certificate common name `bugs.busybox.net' doesn't match requested host name `buildroot.org'.
> To connect to buildroot.org insecurely, use `--no-check-certificate'.
> 
> (this is with wget 1.12 from 2009).
> 
> Now, this isn't about the letsencrypt CA as such, but presumably because
> it doesn't understand SNI - But the end result is the same.

right, this has nothing to do with any CA, it's because that version lacks
SNI support.  the current buildroot.org cert is only for that domain, and
buildroot.org/downloads is off that vhost.  but the client has to support
SNI to select the correct vhost during the SSL handshaking otherwise it is
sent to the default ("bugs.busybox.net" in this case).

looking at lib/server/client support, it seems like wget is the biggest
red flag:
https://en.wikipedia.org/wiki/Server_Name_Indication
it didn't include support until 1.14 in 2012.

i can see about changing the default vhost to a stub domain so it'll be
more clear what the issue is as that log is misleading -- at its face, it
makes no sense why the client was sent to bugs.busybox.net.

> I would actually prefer if we only enforce https where it matters,
> E.G. on bugs.*. We can (and SHOULD now that we've uses the HSTS headers)
> support https on the other subdomains, but I don't think we should
> redirect http to https.

i guess we disagree on the "where it matters" part.  any unencrypted
connection can be injected with ads/javascript which can redirect the
content to any site or capture any state the user has.

imo, if a dev's system is so old it doesn't support SNI, then it's their
problem to workaround it.  even if they get the latest buildroot version,
they're going to keep having the same problem when they try to download
and build software as other servers use SNI.  are we now responsible for
bootstrapping openssl/ca-certificates/wget as host tools so SNI/etc...
are supported ?  how do you get the software for those packages in order
to bootstrap ?  do you bundle the openssl/ca-certificates/wget tarballs
inside of buildroot itself ?  let's just rip the band aid off and be done.

>  >> >> We have the same problem for lists.{buildroot,busybox,uclibc}.*, as that
>  >> >> ends up serving an osuosl certificate.
>  >> 
>  >> > those aren't a new issue ... they've always used osuosl certs.  those are
>  >> > out of my control.
> 
> Yes, but when we sent HSTS headers with includeSubDomains I atleast get
> the following error in chromium:
> 
> lists.busybox.net normally uses encryption to protect your
> information. When Chromium tried to connect to lists.busybox.net this
> time, the website sent back unusual and incorrect credentials. Either an
> attacker is trying to pretend to be lists.busybox.net, or a Wi-Fi
> sign-in screen has interrupted the connection. Your information is still
> secure because Chromium stopped the connection before any data was
> exchanged.
> 
> You cannot visit lists.busybox.net right now because the website uses
> HSTS. Network errors and attacks are usually temporary, so this page
> will probably work later.
> 
> NET::ERR_CERT_COMMON_NAME_INVALID
> 
> With no option of continuing.

mine has an "Advanced" link after that which includes "Proceed".  i went
to bugs.busybox.net first, then to lists.busybox.net, and it worked fine.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151207/9afeea0c/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

Hi,

 >> (this is with wget 1.12 from 2009).
 >> 
 >> Now, this isn't about the letsencrypt CA as such, but presumably because
 >> it doesn't understand SNI - But the end result is the same.

 > right, this has nothing to do with any CA, it's because that version lacks
 > SNI support.  the current buildroot.org cert is only for that domain, and
 > buildroot.org/downloads is off that vhost.  but the client has to support
 > SNI to select the correct vhost during the SSL handshaking otherwise it is
 > sent to the default ("bugs.busybox.net" in this case).

Indeed.

 >> I would actually prefer if we only enforce https where it matters,
 >> E.G. on bugs.*. We can (and SHOULD now that we've uses the HSTS headers)
 >> support https on the other subdomains, but I don't think we should
 >> redirect http to https.

 > i guess we disagree on the "where it matters" part.  any unencrypted
 > connection can be injected with ads/javascript which can redirect the
 > content to any site or capture any state the user has.

Well, what I mean is that this is always about trade offs. The risk of
man in the middle attacks / ads vs the risks of various breakage because
of missing/invalid certs/old clients/whatever.

Bugzilla is a bit special as we have user authentication, the other sub
domains less so.

Don't get me wrong, I find it very good that we are improving the
security situation - I just would prefer we keep the amount of breakage
to a minimum while we configure this.

So how about if we drop the global HSTS headers and http->https
redirects for now and then move a bit more slowly forward sub domain by
subdomain:

1: Enable https next to http and verify that it works
2: Add http->https redirect and verify that it works
3: add HSTS header


 > imo, if a dev's system is so old it doesn't support SNI, then it's their
 > problem to workaround it.  even if they get the latest buildroot version,
 > they're going to keep having the same problem when they try to download
 > and build software as other servers use SNI.  are we now responsible for
 > bootstrapping openssl/ca-certificates/wget as host tools so SNI/etc...
 > are supported ?  how do you get the software for those packages in order
 > to bootstrap ?  do you bundle the openssl/ca-certificates/wget tarballs
 > inside of buildroot itself ?  let's just rip the band aid off and be done.

I agree, old systems are a pain - But we do try to keep buildroot
working on various enterprise distributions when possible. So far we've
worked around SNI issues by using http URLs from those locations instead
(and verifying against our local hashes).


 >> You cannot visit lists.busybox.net right now because the website uses
 >> HSTS. Network errors and attacks are usually temporary, so this page
 >> will probably work later.
 >> 
 >> NET::ERR_CERT_COMMON_NAME_INVALID
 >> 
 >> With no option of continuing.

 > mine has an "Advanced" link after that which includes "Proceed".  i went
 > to bugs.busybox.net first, then to lists.busybox.net, and it worked fine.

I can do that as well in iceweasel, but not in Chromium :/

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 07 Dec 2015 23:16, Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
> 
>  >> I would actually prefer if we only enforce https where it matters,
>  >> E.G. on bugs.*. We can (and SHOULD now that we've uses the HSTS headers)
>  >> support https on the other subdomains, but I don't think we should
>  >> redirect http to https.
> 
>  > i guess we disagree on the "where it matters" part.  any unencrypted
>  > connection can be injected with ads/javascript which can redirect the
>  > content to any site or capture any state the user has.
> 
> Well, what I mean is that this is always about trade offs. The risk of
> man in the middle attacks / ads vs the risks of various breakage because
> of missing/invalid certs/old clients/whatever.
> 
> Bugzilla is a bit special as we have user authentication, the other sub
> domains less so.
> 
> Don't get me wrong, I find it very good that we are improving the
> security situation - I just would prefer we keep the amount of breakage
> to a minimum while we configure this.
> 
> So how about if we drop the global HSTS headers and http->https
> redirects for now and then move a bit more slowly forward sub domain by
> subdomain:
> 
> 1: Enable https next to http and verify that it works
> 2: Add http->https redirect and verify that it works
> 3: add HSTS header

we're already at (3).  even if we weren't, i don't see how transitioning
would affect the SNI issue.  the question is simple: how long do you want
to (try to) support old systems where people refuse to fix their setup ?
we're talking about systems that are over three years old (wget-1.14 was
released in Aug 2012).  what is your cut off ?  3 years ?  4 years ?  i'd
also highlight <wget-1.16 versions have@least one security vuln that
can be remotely exploited (when you download via ftp -- CVE-2014-4877).

>  > imo, if a dev's system is so old it doesn't support SNI, then it's their
>  > problem to workaround it.  even if they get the latest buildroot version,
>  > they're going to keep having the same problem when they try to download
>  > and build software as other servers use SNI.  are we now responsible for
>  > bootstrapping openssl/ca-certificates/wget as host tools so SNI/etc...
>  > are supported ?  how do you get the software for those packages in order
>  > to bootstrap ?  do you bundle the openssl/ca-certificates/wget tarballs
>  > inside of buildroot itself ?  let's just rip the band aid off and be done.
> 
> I agree, old systems are a pain - But we do try to keep buildroot
> working on various enterprise distributions when possible. So far we've
> worked around SNI issues by using http URLs from those locations instead
> (and verifying against our local hashes).

that doesn't help when sites transition to http->https redirects such as
uclibc.org now does.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151207/72336cb1/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Yann E. MORIN]

Mike, All,

On 2015-12-07 17:54 -0500, Mike Frysinger spake thusly:
> we're already at (3).  even if we weren't, i don't see how transitioning
> would affect the SNI issue.  the question is simple: how long do you want
> to (try to) support old systems where people refuse to fix their setup ?
> we're talking about systems that are over three years old (wget-1.14 was
> released in Aug 2012).  what is your cut off ?  3 years ?  4 years ?

A lot of companies are still using RHEL5, which was released in 2007.

Yes, that's old. But once an enterprise has settled on their "production
environment", it lasts years, up to the decade or more. Yes, we are
still trying to have Buildroot work in such an old environment...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 08 Dec 2015 00:02, Yann E. MORIN wrote:
> On 2015-12-07 17:54 -0500, Mike Frysinger spake thusly:
> > we're already at (3).  even if we weren't, i don't see how transitioning
> > would affect the SNI issue.  the question is simple: how long do you want
> > to (try to) support old systems where people refuse to fix their setup ?
> > we're talking about systems that are over three years old (wget-1.14 was
> > released in Aug 2012).  what is your cut off ?  3 years ?  4 years ?
> 
> A lot of companies are still using RHEL5, which was released in 2007.
> 
> Yes, that's old. But once an enterprise has settled on their "production
> environment", it lasts years, up to the decade or more. Yes, we are
> still trying to have Buildroot work in such an old environment...

to be clear, the initial download doesn't necessarily have to happen on
the RHEL system itself, and it is possible to work around -- the wget
command itself already suggested a "fix" by adding the no check flag:
--no-check-certificate
in this mode, it's basically equiv to using http, and it works with
wget versions that don't support SNI.

and it doesn't address the other issue i raised: is buildroot going to
bootstrap wget and such to be sure SNI is supported ?  otherwise, even
if you get the buildroot source, sticking to http doesn't help when the
server transparently redirects you to https.  like getting busybox or
uclibc archives :).  or will buildroot detect wget is old and then use
--no-check-certificate everywhere ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151207/c9c6dd56/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 07 Dec 2015 20:59, Yann E. MORIN wrote:
> On 2015-12-07 14:57 -0500, Mike Frysinger spake thusly:
> > On 07 Dec 2015 13:52, Mike Frysinger wrote:
> > > On 07 Dec 2015 09:00, Peter Korsgaard wrote:
> > > > FYI, there also seems to be an issue with the git.* certificates and
> > > > atleast python on the box, as I get this when pushing:
> > > 
> > > the certs shouldn't be causing issues with `git push` ...
> > > i'll take a look at that
> > 
> > was there a commit bot operating in #buildroot ?  i can't find references
> > to the client that actually connected to freenode.
> 
> Yes, we add a commit bot, but it disapeared a while ago.
> 
> I tried to follow the explanations to launmch it again, but it did not
> work (and I'm no longer sudoer, so I could not dedicate mor etime on it).
> 
> It would be nice if you could re-launch it, yes! ;-)

should be restored.  lemme know if you see any other issues.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151207/1b263203/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 07 Dec 2015 23:16, Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
> 
>  >> You cannot visit lists.busybox.net right now because the website uses
>  >> HSTS. Network errors and attacks are usually temporary, so this page
>  >> will probably work later.
>  >> 
>  >> NET::ERR_CERT_COMMON_NAME_INVALID
>  >> 
>  >> With no option of continuing.
> 
>  > mine has an "Advanced" link after that which includes "Proceed".  i went
>  > to bugs.busybox.net first, then to lists.busybox.net, and it worked fine.
> 
> I can do that as well in iceweasel, but not in Chromium :/

i've disabled HSTS on subdomains for busybox.net for now and started a
thread with the OSU guys about getting lists.busybox.net fixed finally.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151207/7d758c90/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

Hi,

>> So how about if we drop the global HSTS headers and http->https
 >> redirects for now and then move a bit more slowly forward sub domain by
 >> subdomain:
 >> 
 >> 1: Enable https next to http and verify that it works
 >> 2: Add http->https redirect and verify that it works
 >> 3: add HSTS header

 > we're already at (3).  even if we weren't, i don't see how transitioning
 > would affect the SNI issue.  the question is simple: how long do you want
 > to (try to) support old systems where people refuse to fix their setup ?

The new setup causes more problems than just SNI. The wget issues are
important for sources.buildroot.{net,org}, but not for E.G. bugzilla.

As I said, it is a question about tradeoffs, and the tradeoffs may be
different for each subdomain.


> we're talking about systems that are over three years old (wget-1.14 was
 > released in Aug 2012).  what is your cut off ?  3 years ?  4 years ?  i'd
 > also highlight <wget-1.16 versions have@least one security vuln that
 > can be remotely exploited (when you download via ftp -- CVE-2014-4877).

For sources.* (and preferably the buildroot tarballs themselves) I would
prefer it to work even with a wget without SNI support.

I haven't checked the autobuilders (I believe the build script uses
curl), but there we possibly have the same issue.

For bugzilla I don't have any issues requiring SNI and HTTPS.


 >> I agree, old systems are a pain - But we do try to keep buildroot
 >> working on various enterprise distributions when possible. So far we've
 >> worked around SNI issues by using http URLs from those locations instead
 >> (and verifying against our local hashes).

 > that doesn't help when sites transition to http->https redirects such as
 > uclibc.org now does.

Indeed, which is why I would prefer to disable that for
*.buildroot.{org,net}, with the possibly exception of
bugs.buildroot.{org,net}.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

Hi,

 > and it doesn't address the other issue i raised: is buildroot going to
 > bootstrap wget and such to be sure SNI is supported ?  otherwise, even
 > if you get the buildroot source, sticking to http doesn't help when the
 > server transparently redirects you to https.  like getting busybox or
 > uclibc archives :).  or will buildroot detect wget is old and then use
 > --no-check-certificate everywhere ?

I don't believe we will ever bootstrap wget, but we might add
--no-check-certificates in the future (with the download hashes,
checking certificates doesn't add much).

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

 > On 07 Dec 2015 23:16, Peter Korsgaard wrote:
 >> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
 >> 
 >> >> You cannot visit lists.busybox.net right now because the website uses
 >> >> HSTS. Network errors and attacks are usually temporary, so this page
 >> >> will probably work later.
 >> >> 
 >> >> NET::ERR_CERT_COMMON_NAME_INVALID
 >> >> 
 >> >> With no option of continuing.
 >> 
 >> > mine has an "Advanced" link after that which includes "Proceed".  i went
 >> > to bugs.busybox.net first, then to lists.busybox.net, and it worked fine.
 >> 
 >> I can do that as well in iceweasel, but not in Chromium :/

 > i've disabled HSTS on subdomains for busybox.net for now and started a
 > thread with the OSU guys about getting lists.busybox.net fixed finally.

Thanks! I saw you only removed it for the main busybox.net, and not from
E.G. git.busybox.net:

curl -s -I --insecure https://busybox.net | grep Strict
Strict-Transport-Security: max-age=63072000

But ok, I don't think we will be adding subdomains under git, so it
doesn't really matter.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 08 Dec 2015 08:55, Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
> 
>  > i've disabled HSTS on subdomains for busybox.net for now and started a
>  > thread with the OSU guys about getting lists.busybox.net fixed finally.
> 
> Thanks! I saw you only removed it for the main busybox.net, and not from
> E.G. git.busybox.net:

correct, i dropped it only because of lists.busybox.net.  when that's
fixed, i'll re-add it.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151208/e37848cf/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 08 Dec 2015 08:52, Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
> 
>  > and it doesn't address the other issue i raised: is buildroot going to
>  > bootstrap wget and such to be sure SNI is supported ?  otherwise, even
>  > if you get the buildroot source, sticking to http doesn't help when the
>  > server transparently redirects you to https.  like getting busybox or
>  > uclibc archives :).  or will buildroot detect wget is old and then use
>  > --no-check-certificate everywhere ?
> 
> I don't believe we will ever bootstrap wget, but we might add
> --no-check-certificates in the future (with the download hashes,
> checking certificates doesn't add much).

except there is no checking on the initial download.  imo, people wanting
to use old/insecure versions and fetch things insecurely should be forced
to opt in.  i.e. they use --no-check-certificates.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151208/30bfd95f/attachment.asc>

[Buildroot] [psa] various server software upgrades

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

 >> I don't believe we will ever bootstrap wget, but we might add
 >> --no-check-certificates in the future (with the download hashes,
 >> checking certificates doesn't add much).

 > except there is no checking on the initial download.

With initial download I take it you mean Buildroot, right? That we have
alternatives for (gpg signatures, git clones, download though browser) -
But sources.buildroot.{net,org} is almost exclusively used by wget, so I
prefer to not break it for non-sni capable versions.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [psa] various server software upgrades

[Mike Frysinger]

On 08 Dec 2015 17:43, Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
> 
>  >> I don't believe we will ever bootstrap wget, but we might add
>  >> --no-check-certificates in the future (with the download hashes,
>  >> checking certificates doesn't add much).
> 
>  > except there is no checking on the initial download.
> 
> With initial download I take it you mean Buildroot, right? That we have
> alternatives for (gpg signatures, git clones, download though browser) -
> But sources.buildroot.{net,org} is almost exclusively used by wget, so I
> prefer to not break it for non-sni capable versions.

realistically, how many people do you think actually leverage gpg
signatures ?  having transparent https is better imo than people
running old insecure setups and just telling them to use the one
flag when downloading the initial file.  if they're running wget,
then they're probably reading some doc right ?  just put a foot
note in there mentioning the flag and old clients.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151208/8af0243f/attachment.asc>