freebsd security - Dec 2017 - http subversion URLs should be discontinued in favor of https URLs

On 12/12/2017 06:59, Poul-Henning Kamp wrote:
> --------
> In message <86d13kgnfh.fsf at desk.des.no>,
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= w
> rites:
>> "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>>> The only realistic way for the FreeBSD project to implement
end-to-end
>>> trust, is HTTPS with a self-signed cert, distributed and verified
>>> using the projects PGP-trust-mesh and strong social network.
>> Your suggestion does not remove implicit and possibly misplaced trust,
>> it just moves it from one place to another.  Instead of trusting a
>> certificate authority and DNS, you trust the source of the public key,
>> and probably also DNS.  As always, it boils down to a) key distribution
>> is hard and b) what's your threat model?
> I don't think I agree with any of that ?
>
> With respect to authenticity of the FreeBSD SVN repo I cannot
> imagine anybody else being even one percent as qualified and
> trustworth as the FreeBSD projects own core-team.
>
> In particular I would never trust any "In the CA-racket for the
> money" organization to do so.
>
> If you are worried that the FreeBSD project "staff" cannot
> handle a root-cert competently, then the exposure is no
> smaller or larger than if it was a CA-signed cert they fumbled.
>
> Trusting DNS doesn't apply it if the project root-cert was
> stored on my local machine after I used my best judgement of PGP
> signatures to conclude that it was authentic.
>
> And I don't really see distribution of this particular key being
> difficult at all:  We already PGP sign release checksums for
> authenticity and it the FreeBSD root-cert is just another file to
> get same treatment.
>
> Poul-Henning
Agreed.

Now the question becomes this -- is the proper means to handle this via
TLS (using that root cert) OR should the *transport* be fixed so that
https doesn't need to be used?

I argue the second, because the goal when it comes to source
distributions is ensuring that the code you transfer is bit-wise
identical to the code on the FreeBSD project repositories *which can be
mirrored.*

Attempting to "overload" TLS with this responsibility now requires
that
the project take operational and security responsibility for the
integrity of any *mirror* of said code, which is IMHO flatly
unreasonable and thus is simply not going to happen.? Otherwise you can
have all the assurance you want that the bits you get are the bits that
were on the disk at the other end, but no assurance at all that the bits
on the disk *are the same as the bits on the FreeBSD project's machines!*

Solve the problem at the correct location -- either fix svn to sign and
verify updates or dump it for something that can and use that existing
mechanism (e.g. git)

-- 
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/20171212/b20fea93/attachment.bin>

--------
In message <c27552cf-45d8-7686-c60d-256537780edc at denninger.net>, Karl
Denninger
 writes:
>Now the question becomes this -- is the proper means to handle this via
>TLS (using that root cert) OR should the *transport* be fixed so that
>https doesn't need to be used?
I certainly would caution against inventing more encrypted transports
than we already have.

The only feasible alternative I see is SSH, provided we can persuade
it somehow to not authenticate the client.

If this requires a hacked sshd(8) which just says "welcome" I would
be very worried about it coexisting with a untainted sshd on any
system.
>I argue the second, because the goal when it comes to source
>distributions is ensuring that the code you transfer is bit-wise
>identical to the code on the FreeBSD project repositories *which can be
>mirrored.*
I am personally a very big fan of integrity checks which does not
also encrypt the content with an ephemeral key for exactly that
reason.

Most of the people who try to force everything behind HTTPS don't
even know you can do that.

For the FreeBSD SVN tree, this could almost be as simple as posting
an email, maybe once a week, with the exact revision checked out
and the PGP signed output of:

	svn co ... && find ... -print | sort | xargs cat | sha256

Such an archive would also be invaluable for reauthenticating in
case, somebody ever manages to do something evil to our repo.
>Solve the problem at the correct location -- either fix svn to sign and
>verify updates or dump it for something that can and use that existing
>mechanism (e.g. git)
As I mentioned humoursly to you in private email, I don't think
this particular problem will reach consensus any sooner if you 
also tangling it in the SVN vs GIT political issue.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.