<div dir="ltr">See <a href="https://nginx.org/en/linux_packages.html#stable">https://nginx.org/en/linux_packages.html#stable</a><div><br></div><div>PGP key links are hard coded to http URLs:</div><div><br></div><div><div><p></div><div>For Debian/Ubuntu, in order to authenticate the nginx repository signature</div><div>and to eliminate warnings about missing PGP key during installation of the</div><div>nginx package, it is necessary to add the key used to sign the nginx</div><div>packages and repository to the <code>apt</code> program keyring.</div><div>Please download <a href="<a href="http://nginx.org/keys/nginx_signing.key">http://nginx.org/keys/nginx_signing.key</a>">this</div><div>key</a> from our web site, and add it to the <code>apt</code></div><div>program keyring with the following command:</div><div></p></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 22, 2016 at 7:19 PM, Maxim Konovalov <span dir="ltr"><<a href="mailto:maxim@nginx.com" target="_blank">maxim@nginx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8/22/16 8:15 PM, Richard Stanway wrote:<br>
> Could you at least fix the https download page, so it doesn't<br>
> directly link to a HTTP PGP key?<br>
><br>
</span>It works correctly: <a href="https://nginx.org/en/download.html" rel="noreferrer" target="_blank">https://nginx.org/en/download.<wbr>html</a><br>
<span class=""><br>
> On Mon, Aug 22, 2016 at 6:49 PM, Maxim Konovalov <<a href="mailto:maxim@nginx.com">maxim@nginx.com</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:maxim@nginx.com">maxim@nginx.com</a>>> wrote:<br>
><br>
> On 8/22/16 7:41 PM, B.R. wrote:<br>
> > The problem is, if the GPG key is served through HTTP, there is no<br>
> > way to authenticate it, since it could be compromised through<br>
> MITM.<br>
> > I am very surprised to see myself being qualified as 'HTTPS<br>
> despot'<br>
> > when I just spot the obvious.<br>
> ><br>
> But it does not -- our PGP key distributed through a number of<br>
> channels, including HTTPS. Problem solved, case closed?<br>
><br>
> > Compromised repository + GPG key is one very powerful way of<br>
> > impersonating another product.<br>
> ><br>
> > TLS provides both encryption and authentication, based on the<br>
> > initial shared circle of trust.<br>
> > Thus you certify the GPG key is authentic and thus, if it verifies<br>
> > the binaries, you ensure the delivered package are produced by the<br>
> > owner of the key, in the end the real author.<br>
> ><br>
> > In 2016, stating that content served over HTTP is 'secure'<br>
> blows my<br>
> > mind and kills your credibility.<br>
> ><br>
> Who did that? What's his name?<br>
><br>
> > Now, as Richard pointed out, if you truly believe you need to<br>
> > provide HTTP-only, you can. It would be better if it was in a very<br>
> > visible fashion, though.<br>
> > Where was despotism, again?<br>
><br>
</div></div>> <a href="http://nginx.org" rel="noreferrer" target="_blank">nginx.org</a> <<a href="http://nginx.org" rel="noreferrer" target="_blank">http://nginx.org</a>> already has HTTPS therefore it is<br>
<span class="">> not HTTP-only.<br>
><br>
> > ---<br>
> > *B. R.*<br>
> ><br>
> > On Mon, Aug 22, 2016 at 5:40 PM, Richard Stanway<br>
</span>> > <<a href="mailto:r1ch%2Bnginx@teamliquid.net">r1ch+nginx@teamliquid.net</a> <mailto:<a href="mailto:r1ch%252Bnginx@teamliquid.net">r1ch%2Bnginx@<wbr>teamliquid.net</a>><br>
> <mailto:<a href="mailto:r1ch%2Bnginx@teamliquid.net">r1ch+nginx@teamliquid.<wbr>net</a><br>
<span class="">> <mailto:<a href="mailto:r1ch%252Bnginx@teamliquid.net">r1ch%2Bnginx@<wbr>teamliquid.net</a>>>> wrote:<br>
> ><br>
> > 1. You could provide <a href="http://insecure.nginx.org" rel="noreferrer" target="_blank">insecure.nginx.org</a> <<a href="http://insecure.nginx.org" rel="noreferrer" target="_blank">http://insecure.nginx.org</a>><br>
> > <<a href="http://insecure.nginx.org" rel="noreferrer" target="_blank">http://insecure.nginx.org</a>> mirror for such people, make<br>
</span>> > <a href="http://nginx.org" rel="noreferrer" target="_blank">nginx.org</a> <<a href="http://nginx.org" rel="noreferrer" target="_blank">http://nginx.org</a>> <<a href="http://nginx.org" rel="noreferrer" target="_blank">http://nginx.org</a>> secure by<br>
<span class="">> default.<br>
> ><br>
> > 2. Modern server CPUs are already extremely energy efficient,<br>
> > TLS adds negligible load. See <a href="https://istlsfastyet.com/" rel="noreferrer" target="_blank">https://istlsfastyet.com/</a><br>
> ><br>
> ><br>
> ><br>
> > On Mon, Aug 22, 2016 at 12:31 PM, Valentin V. Bartenev<br>
</span>> > <<a href="mailto:vbart@nginx.com">vbart@nginx.com</a> <mailto:<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>> <mailto:<a href="mailto:vbart@nginx.com">vbart@nginx.com</a><br>
<span class="">> <mailto:<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>>>> wrote:<br>
> ><br>
> > On Sunday 21 August 2016 15:56:09 B.R. wrote:<br>
> > > It is surprising, since I remember Ilya Grigorik made a talk about TLS<br>
> > > during the first ever nginx conf in 2014:<br>
> > > <a href="https://www.youtube.com/watch?v=iHxD-G0YjiU" rel="noreferrer" target="_blank">https://www.youtube.com/watch?<wbr>v=iHxD-G0YjiU</a><br>
> <<a href="https://www.youtube.com/watch?v=iHxD-G0YjiU" rel="noreferrer" target="_blank">https://www.youtube.com/<wbr>watch?v=iHxD-G0YjiU</a>><br>
> > <<a href="https://www.youtube.com/watch?v=iHxD-G0YjiU" rel="noreferrer" target="_blank">https://www.youtube.com/<wbr>watch?v=iHxD-G0YjiU</a><br>
> <<a href="https://www.youtube.com/watch?v=iHxD-G0YjiU" rel="noreferrer" target="_blank">https://www.youtube.com/<wbr>watch?v=iHxD-G0YjiU</a>>><br>
> > > <a href="https://istlsfastyet.com/" rel="noreferrer" target="_blank">https://istlsfastyet.com/</a><br>
> ><br>
> > It's just Ilya's opinion. You are free to agree or not.<br>
> ><br>
> ><br>
> > ><br>
> > > Thus, there is no reason for not going full-HTTPS in delivering Web pages.<br>
> ><br>
> > There are at least two reasons to not use HTTPS:<br>
> ><br>
> > 1. Provide easy access to information for people, who can't<br>
> > use encryption<br>
> > by political, legal, or technical reasons.<br>
> ><br>
> > 2. Don't waste resources on encryption, and thus save our<br>
> > planet.<br>
> ><br>
> > Please, don't be a TLS despot and let people to have a<br>
> > choice to use encryption<br>
> > or not.<br>
> ><br>
> > I think the situation when I can't download new version of<br>
> > OpenSSL using old<br>
> > version of OpenSSL is ridiculous, but they have configured<br>
</span>> > <a href="http://openssl.org" rel="noreferrer" target="_blank">openssl.org</a> <<a href="http://openssl.org" rel="noreferrer" target="_blank">http://openssl.org</a>> <<a href="http://openssl.org" rel="noreferrer" target="_blank">http://openssl.org</a>><br>
<span class="im HOEnZb">> that way.<br>
> > How I supposed to use Internet then?<br>
> ><br>
> > wbr, Valentin V. Bartenev<br>
> ><br>
><br>
><br>
> --<br>
> Maxim Konovalov<br>
> Join us at nginx.conf, Sept. 7-9, Austin, TX:<br>
> <a href="http://nginx.com/nginxconf" rel="noreferrer" target="_blank">http://nginx.com/nginxconf</a><br>
><br>
> ______________________________<wbr>_________________<br>
> nginx mailing list<br>
</span><span class="im HOEnZb">> <a href="mailto:nginx@nginx.org">nginx@nginx.org</a> <mailto:<a href="mailto:nginx@nginx.org">nginx@nginx.org</a>><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
> <<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a>><br>
><br>
><br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> nginx mailing list<br>
> <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
><br>
<br>
<br>
--<br>
Maxim Konovalov<br>
Join us at nginx.conf, Sept. 7-9, Austin, TX: <a href="http://nginx.com/nginxconf" rel="noreferrer" target="_blank">http://nginx.com/nginxconf</a><br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a></div></div></blockquote></div><br></div>