[144262] trunk/dports/lang/py-htmldocs/Portfile

Russell Jones russell.jones at physics.ox.ac.uk
Thu Jan 7 08:41:03 PST 2016



On 07/01/16 16:17, Daniel J. Luke wrote:
> On Jan 7, 2016, at 5:53 AM, Russell Jones <russell.jones at physics.ox.ac.uk> wrote:
>> On Daniel's point: checking an SSL cert provides a guarantee from some certificate issuer, given a competent sysadmin, etc, that the host name matches it.
> When you validate an SSL certificate all you end up with is the assurance that some Certificate Authority has issued a certificate for that hostname.
That seems to me to be understating the case.
> There are lots of CAs and they aren't immune to process (or other) issues (see also DigiNotar). There's a reason why there has been interest in public key pinning (and DANE + DNSSEC) - so you end up with a greater assurance.
Yes, and there was Lavabit, of course. But these are rather unusual 
cases. It's fine, important indeed, to exclude them as far as possible 
by ensuring oversight, but the problem still exists even with checksums, 
realistically.
>> Do you have some reason to think there are issuers in the root certificate list that would issue bogus python.org certs? Or are you talking about a cert being stolen? I'm not sure what you mean by "just .. valid".
> I don't have reason to believe either of those things is currently happening - but I have reason to believe either is possible, and we shouldn't decide to rely on neither happening.
I agree. I wasn't suggesting we should in general. Rather, it was a 
suggestion for mitigation until a better one came along (which it did, 
very quickly).
> Even in the non-malicious case, a re-org of files on python.org would yield unknown behavior (the file at that url could change, and in the base case we would get an error - in the worst case anything could be in that file).
>
Well no, not *anything* unless python.org to open it to the public, 
which seems a little far-fetched.

Russell


More information about the macports-dev mailing list