SSL Certificates (was Re: [144262] trunk/dports/lang/py-htmldocs/Portfile)

[Russell Jones]

On 07/01/16 16:44, Daniel J. Luke wrote:
> On Jan 7, 2016, at 11:41 AM, Russell Jones <russell.jones at physics.ox.ac.uk> wrote:
>> 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.
> How about a rephrase:
>
> Validating an SSL certificate gives you strong cryptographic proof that a weak human process has occurred.
>
Fair enough, but of course it's relied on for distributing a base 
install of macports itself, along with the port files.
>>> 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.
> Using a checksum is different. It gives you a guarantee that the file you downloaded was the same one that the maintainer intended the portfile to operate on.
>
Yes, and the maintainer can be fooled too.

Anyway, let's take this off list if you'd like to continue the conversation.

Russell