http subversion URLs should be discontinued in favor of https URLs

[Karl Denninger]

On 12/11/2017 09:16, Shawn Webb wrote:
> On Mon, Dec 11, 2017 at 03:08:37PM -0000, Christian Weisgerber wrote:
>> On 2017-12-08, Luke Crooks <luke at solentwholesale.com> wrote:
>>
>>> The pull request was rejected for a valid reason, offering http allows
>>> users with limited network access chance to clone or download freebsd where
>>> https is not possible.
>> Do users actually exist who have access to http but not to https?
>> Or is this a myth?  And how do these users access popular sites
>> like Wikipedia, or www.FreeBSD.org for that matter?
> In an effort to enforce encrypted comms, my network is the inverse:
> TCP:80 is disallowed, but TCP:443 is accepted.
>
> Thanks,
Wading back into this; it may be worth one half of 2 bits from other's
points of view....

IMO there are three issues and we're conflating them/.  This is
unfortunate because only one of them matters.

/Https allegedly provides three things:
1. Attestation (you're talking to who you think you are)
2. Data integrity (the data has not been tampered with)
3. Privacy during transport (nobody but the receiving party can observe
the payload except on the sending and terminal ends)

#2 in https comes about because if #1 is true then the payload will not
decode if someone tampers with it or the certificate in use, /provided
/the correct options are enforced.

The problem is that if #1 is false then both #2 and #3 are ALSO false,
because if I can tamper with attestation then I can MITM the data
(insert discussion/debate/whatever on the existing CA structure, etc.
which is really the never-ending debate on key management, distribution
and the vouching process in any given certificate management design) 
This leads to all sorts of other issues (like intentional MITM behavior
via wildcard certs and overrides on certificate checking by corporate IT
departments, possibly ISPs, user anti-virus software, compromise of a CA
by state actors or hackers, etc.)  The premise of https is very pretty
but the implementation -- not so much. Nonetheless a whole lot of
commerce and such depends on it, because all three are required for
commerce so imperfect beats nothing.

But in the context of code distribution I care not about #3.  I care
/very much /that /the code is untampered with/ (#2)/, /but note that I
really _*don't*_ care about #3 at all because the code is /intentionally
published to the public at large/ and I don't care _*much*_ about #1 (if
someone mirrors the source /exactly /then whether I get it from
FreeBSD's server or some interloper doesn't really matter either.)

SVN's shortcoming is that it does nothing for #2 on an inherent basis
and this debate is thus about trying to use a tool that allegedly does
three things when we really only need one of them.

Maybe it's time to move toward something that can for source
distribution to the public (e.g. Git) instead of trying to abuse
something that we know can't actually meet the criteria required?

Just sayin'.....

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20171211/41c68393/attachment.bin>