pkg-oss uses insecure http:// to download sources and link to content

[davidjb]

As ​https://nginx.org uses HTTPS by default, it would be best to update URLs in pkg-oss to ensure that source packages are downloaded securely. As it currently stands, because downloads take place over insecure HTTP, the file downloaded can't be guaranteed to not have been modified in transport (eg man-in-the-middled). In addition, other URLs such as those in the spec files and documentation would benefit from being changed to help avoid potential MitM attacks.

In a local version of pkg-oss, I did a global find-and-replace of http://nginx.org, replacing it with https://nginx.org across all files, and everything continues to work fine when packaging. This was at least for RPM-based packages but DEB-based packaging should be fine to change as well.

There should be no downside or risk to this as nginx.org is already using HTTPS. If any machine using pkg-oss doesn't support HTTPS or has outdated certificates preventing its use, then that's a deeper problem on that machine or OS to resolve.

[Maxim Dounin]

Replying to davidjb@…:

As ​https://nginx.org uses HTTPS by default

Note that this statement is not really true. Rather, we provide a https version of nginx.org. All official links are to http://nginx.org.

[thresh]

I think the better way to ensure the file was not modified in transit would be to hardcode Maxim's GPG key ID and check if the signature of the downloaded .tar.gz actually matches it. https seems like a band-aid, not really solving the issue here.

[davidjb]

@mdounin I forget I have the benefit of HTTPS Everywhere. In that case, I'd strongly encourage you to consider HTTPS by default because browsers are swiftly moving towards marking HTTP as insecure (eg Chrome ​http://www.zdnet.com/article/google-tightens-noose-on-http-chrome-to-stick-not-secure-on-pages-with-search-fields/) and you've already got ​https://nginx.org working.

@thresh The better solution is to do both -- transport security and GPG verification, at least not to afford a user some degree of privacy in the process.

I'd welcome this ticket to be re-opened and addressed as the use of ​https:// links would benefit all users.