On 11/28/2016 06:29 PM, Baptiste Jonglez wrote:
On the other hand, if one day the TLS certificate becomes invalid (expired certificate, untrusted CA, etc), the package would fail to build. I see this as a significant drawback of using git+https://.
When you say drawback, are you referring to TLS performing its intended role? I am really confused as to what you are trying to accomplish here. I thought the whole point of switching to git+https:// is in order that builds should fail when suspicious things happen to the source code, like getting served from a domain with a very suspiciously broken certificate. The CACERT model assumes website owners are still alive and capable of renewing their certificate before people call their customer service (if applicable) number to complain that they can't access the website. On the whole, it tends to be pretty successful. (Leaving aside peoples' questions on the premise of the model, at least when we use it we use it according to spec.) An untrusted CA is, well, untrusted. Why would I want to build a package authenticated by them, if I don't trust them? Seriously, your argument is an argument against using TLS on the World Wide Web. "I don't wanna use TLS, because now I cannot access all these broken websites anymore!" -- Eli Schwartz