On 07/01/16 16:44, Daniel J. Luke wrote:
On Jan 7, 2016, at 11:41 AM, Russell Jones <[email protected]>
wrote:
On 07/01/16 16:17, Daniel J. Luke wrote:
On Jan 7, 2016, at 5:53 AM, Russell Jones <[email protected]>
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
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
