Re: [gentoo-mirrors] HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

2019-04-26 Thread Carlos Carvalho 
I've added https to gentoo.c3sl.ufpr.br.

Robin H. Johnson (robb...@gentoo.org) wrote on Wed, Apr 17, 2019 at 06:38:34PM 
-03:
> On Sat, Apr 13, 2019 at 10:54:36AM +0200, Erwin Bronkhorst - Studenten Net 
> Twente wrote:
> > > It this reply enough to get this fixed in the distfiles.xml,
> > or do I have to mention/fix it somewhere else?
...
> 
> I'll consider this formal assent to add it to distfiles.xml, thank you!

So please add us.

What about ftp crap? Can I get rid of ftp suppport in the gentoo mirror?? I've
already removed it for most repositories...

Re: [gentoo-mirrors] HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

2019-04-17 Thread Robin H. Johnson 
On Sun, Apr 14, 2019 at 12:27:51PM +0200, SoEasyTo Mirrors Manager wrote:
> Hi,
> 
> Being the maintainer of mirrors.soeasyto.com, which is currently 
> HTTP-only, having already the setup in place for LetsEncrypt on my 
> server, I'm about to set it up for my mirror.
Thank you.

> Anyway, does it have to be HTTPS only ? ie., do I also have to set it up 
> to redirect HTTP requests over HTTPS (it's possible) ?
Ideally, but not required (better security to do so).

> And same question as another maintainer before, do I have to create a 
> ticket on b.g.o. in order to notify of that change ?
I'll update it, thanks.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: PGP signature

Re: [gentoo-mirrors] HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

2019-04-17 Thread Robin H. Johnson 
On Sat, Apr 13, 2019 at 10:54:36AM +0200, Erwin Bronkhorst - Studenten Net 
Twente wrote:
> > Of the HTTP-only mirrors, I went to test if of them had working HTTPS 
> > that wasn't documented in distfiles.xml, and if not, what responses 
> > there were 
> I am a maintainer of the Gentoo mirror at ftp.snt.utwente.nl
>  . In the distfiles.xml [1] we are listed as HTTP
> only, but I am happy to tell you that HTTPS works as well and we are fully
> supporting it. It this reply enough to get this fixed in the distfiles.xml,
> or do I have to mention/fix it somewhere else?
Yes, UTwente was one of the two mirrors that I detected with it.

I'll consider this formal assent to add it to distfiles.xml, thank you!

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: PGP signature

Re: [gentoo-mirrors] HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

2019-04-14 Thread SoEasyTo Mirrors Manager 

Hi,

Being the maintainer of mirrors.soeasyto.com, which is currently 
HTTP-only, having already the setup in place for LetsEncrypt on my 
server, I'm about to set it up for my mirror.


Anyway, does it have to be HTTPS only ? ie., do I also have to set it up 
to redirect HTTP requests over HTTPS (it's possible) ?


And same question as another maintainer before, do I have to create a 
ticket on b.g.o. in order to notify of that change ?


Thanks in advance,

Regards,

Xavier - SoEasyTo Mirrors Manager

Le 2019-04-14 10:10, Fredrik Eriksson a écrit :


Hi,

I'm the maintainer of mirror.mdfnet.se. The future of this mirror is 
not

entirely clear (it may have to be removed in a few weeks/months), but
for now I've added a letsencrypt certificate, opened it up for https 
and

will make sure to maintain it for as long as the mirror is available.

/Feffe

On 2019-04-13 08:28, Robin H. Johnson wrote:


Hi!

Upstream Chrome is discussing a potential change that we try to block
users following a HTTPS->HTTP for high-risk files, including tarballs.
https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html

Further below is some quick analysis I did on the state of HTTP for 
the mirrors

that are presently listed only as HTTP.

In the era of LetsEncrypt, how many mirror administrators have a 
little time to

add HTTPS to their mirrors, along with a cronjob to auto-refresh the
certificates?

The state of HTTP/HTTPS on Gentoo mirrors:
59 mirrors total
=
1 HTTPS-only
27 HTTP+HTTPS
31 HTTP-only

Of the HTTP-only mirrors, only 1 is on a non-standard port.

Of the HTTP-only mirrors, I went to test if of them had working HTTPS
that wasn't documented in distfiles.xml, and if not, what responses
there were (I think I got an off-by-one try to summarize the errors).

2 200 OK
24 No connection: Connection refused, Connection timed out, No route 
to host

3 Horrible SSL certs
2 SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match 
the expected, but everything else was otherwise good.

1 HTTP on port 443 (SSL_ERROR_RX_RECORD_TOO_LONG)

32 errors

Horrible SSL certs, error breakdown; some mirrors had MORE than one 
error in their cert:

3 - SEC_ERROR_UNKNOWN_ISSUER/The certificate issuer is unknown [1]
2 - The certificate chain uses insecure algorithm (RSA-SHA1)
3 - SEC_ERROR_EXPIRED_CERTIFICATE/The certificate chain uses expired 
certificate [2]
3 - SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not 
match the expected.

1 - SEC_ERROR_UNRECOGNIZED_OID [3]

[1] SEC_ERROR_UNKNOWN_ISSUER:
- self-signed
- defunct CA
- missing intermediate

[2] SEC_ERROR_EXPIRED_CERTIFICATE:
Past-expiry ranges 1 month to 4 years ago!

[3] SEC_ERROR_UNRECOGNIZED_OID:
OpenSSL & GnuTLS handled this cert, but NSS failed on it.

Re: [gentoo-mirrors] HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

2019-04-14 Thread Fredrik Eriksson 
Hi,

I'm the maintainer of mirror.mdfnet.se. The future of this mirror is not
entirely clear (it may have to be removed in a few weeks/months), but
for now I've added a letsencrypt certificate, opened it up for https and
will make sure to maintain it for as long as the mirror is available.

/Feffe


On 2019-04-13 08:28, Robin H. Johnson wrote:
> Hi!
> 
> Upstream Chrome is discussing a potential change that we try to block
> users following a HTTPS->HTTP for high-risk files, including tarballs.
> https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html
> 
> Further below is some quick analysis I did on the state of HTTP for the 
> mirrors
> that are presently listed only as HTTP.
> 
> In the era of LetsEncrypt, how many mirror administrators have a little time 
> to
> add HTTPS to their mirrors, along with a cronjob to auto-refresh the
> certificates?
> 
> The state of HTTP/HTTPS on Gentoo mirrors:
>   59 mirrors total
>   =
>1 HTTPS-only
>   27 HTTP+HTTPS
>   31 HTTP-only
> 
> Of the HTTP-only mirrors, only 1 is on a non-standard port.
> 
> Of the HTTP-only mirrors, I went to test if of them had working HTTPS
> that wasn't documented in distfiles.xml, and if not, what responses
> there were (I think I got an off-by-one try to summarize the errors).
> 
>   2 200 OK
>  24 No connection: Connection refused, Connection timed out, No route to host
>   3 Horrible SSL certs
>   2 SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the 
> expected, but everything else was otherwise good.
>   1 HTTP on port 443 (SSL_ERROR_RX_RECORD_TOO_LONG)
> 
>  32 errors
> 
> Horrible SSL certs, error breakdown; some mirrors had MORE than one error in 
> their cert:
> 3 - SEC_ERROR_UNKNOWN_ISSUER/The certificate issuer is unknown [1]
> 2 - The certificate chain uses insecure algorithm (RSA-SHA1)
> 3 - SEC_ERROR_EXPIRED_CERTIFICATE/The certificate chain uses expired 
> certificate [2]
> 3 - SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the 
> expected.
> 1 - SEC_ERROR_UNRECOGNIZED_OID [3]
> 
> [1] SEC_ERROR_UNKNOWN_ISSUER:
> - self-signed
> - defunct CA
> - missing intermediate
> 
> [2] SEC_ERROR_EXPIRED_CERTIFICATE:
> Past-expiry ranges 1 month to 4 years ago!
> 
> [3] SEC_ERROR_UNRECOGNIZED_OID:
> OpenSSL & GnuTLS handled this cert, but NSS failed on it.
>

RE: [gentoo-mirrors] HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

2019-04-13 Thread Erwin Bronkhorst - Studenten Net Twente 
Hello,

 

> Of the HTTP-only mirrors, I went to test if of them had working HTTPS 
> that wasn't documented in distfiles.xml, and if not, what responses 
> there were 

 

I am a maintainer of the Gentoo mirror at ftp.snt.utwente.nl
<ftp://ftp.snt.utwente.nl> . In the distfiles.xml [1] we are listed as HTTP
only, but I am happy to tell you that HTTPS works as well and we are fully
supporting it. It this reply enough to get this fixed in the distfiles.xml,
or do I have to mention/fix it somewhere else?

 

Greetings,

 

Erwin Bronkhorst

SNT FTPCom

 

[1] https://api.gentoo.org/mirrors/distfiles.xml

 

Van: Robin H. Johnson  
Verzonden: zaterdag 13 april 2019 08:28
Aan: gentoo-mirrors@lists.gentoo.org
Onderwerp: [gentoo-mirrors] HTTPS deployments for mirrors: Potential Chrome
changes; stats on the existing mirrors

 

Hi! 

Upstream Chrome is discussing a potential change that we try to block 
users following a HTTPS->HTTP for high-risk files, including tarballs. 
https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html 

Further below is some quick analysis I did on the state of HTTP for the
mirrors 
that are presently listed only as HTTP. 

In the era of LetsEncrypt, how many mirror administrators have a little time
to 
add HTTPS to their mirrors, along with a cronjob to auto-refresh the 
certificates? 

The state of HTTP/HTTPS on Gentoo mirrors: 
  59 mirrors total 
  = 
   1 HTTPS-only 
  27 HTTP+HTTPS 
  31 HTTP-only 

Of the HTTP-only mirrors, only 1 is on a non-standard port. 

Of the HTTP-only mirrors, I went to test if of them had working HTTPS 
that wasn't documented in distfiles.xml, and if not, what responses 
there were (I think I got an off-by-one try to summarize the errors). 

  2 200 OK 
 24 No connection: Connection refused, Connection timed out, No route to
host 
  3 Horrible SSL certs 
  2 SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the
expected, but everything else was otherwise good.

  1 HTTP on port 443 (SSL_ERROR_RX_RECORD_TOO_LONG) 
 
 32 errors 

Horrible SSL certs, error breakdown; some mirrors had MORE than one error in
their cert: 
3 - SEC_ERROR_UNKNOWN_ISSUER/The certificate issuer is unknown [1] 
2 - The certificate chain uses insecure algorithm (RSA-SHA1) 
3 - SEC_ERROR_EXPIRED_CERTIFICATE/The certificate chain uses expired
certificate [2] 
3 - SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the
expected. 
1 - SEC_ERROR_UNRECOGNIZED_OID [3] 

[1] SEC_ERROR_UNKNOWN_ISSUER: 
- self-signed 
- defunct CA 
- missing intermediate 

[2] SEC_ERROR_EXPIRED_CERTIFICATE: 
Past-expiry ranges 1 month to 4 years ago! 

[3] SEC_ERROR_UNRECOGNIZED_OID: 
OpenSSL & GnuTLS handled this cert, but NSS failed on it. 

-- 
Robin Hugh Johnson 
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer 
E-Mail   : robb...@gentoo.org <mailto:robb...@gentoo.org>  
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[gentoo-mirrors] HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

2019-04-13 Thread Robin H. Johnson 
Hi!

Upstream Chrome is discussing a potential change that we try to block
users following a HTTPS->HTTP for high-risk files, including tarballs.
https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html

Further below is some quick analysis I did on the state of HTTP for the mirrors
that are presently listed only as HTTP.

In the era of LetsEncrypt, how many mirror administrators have a little time to
add HTTPS to their mirrors, along with a cronjob to auto-refresh the
certificates?

The state of HTTP/HTTPS on Gentoo mirrors:
  59 mirrors total
  =
   1 HTTPS-only
  27 HTTP+HTTPS
  31 HTTP-only

Of the HTTP-only mirrors, only 1 is on a non-standard port.

Of the HTTP-only mirrors, I went to test if of them had working HTTPS
that wasn't documented in distfiles.xml, and if not, what responses
there were (I think I got an off-by-one try to summarize the errors).

  2 200 OK
 24 No connection: Connection refused, Connection timed out, No route to host
  3 Horrible SSL certs
  2 SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the 
expected, but everything else was otherwise good.
  1 HTTP on port 443 (SSL_ERROR_RX_RECORD_TOO_LONG)

 32 errors

Horrible SSL certs, error breakdown; some mirrors had MORE than one error in 
their cert:
3 - SEC_ERROR_UNKNOWN_ISSUER/The certificate issuer is unknown [1]
2 - The certificate chain uses insecure algorithm (RSA-SHA1)
3 - SEC_ERROR_EXPIRED_CERTIFICATE/The certificate chain uses expired 
certificate [2]
3 - SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the 
expected.
1 - SEC_ERROR_UNRECOGNIZED_OID [3]

[1] SEC_ERROR_UNKNOWN_ISSUER:
- self-signed
- defunct CA
- missing intermediate

[2] SEC_ERROR_EXPIRED_CERTIFICATE:
Past-expiry ranges 1 month to 4 years ago!

[3] SEC_ERROR_UNRECOGNIZED_OID:
OpenSSL & GnuTLS handled this cert, but NSS failed on it.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: PGP signature