Retiring portsnap [was MITM attacks against portsnap and freebsd-update]

[Brooks Davis]

On Thu, Apr 10, 2014 at 06:38:39PM -0500, Bryan Drewery wrote:
> On 4/10/2014 12:03 PM, David Noel wrote:
> > I found a few bugs in portsnap and freebsd-update that I'd like to
> > bring to the community's attention and hopefully recruit people to
> > help fix. I mentioned them to Colin (their author) a few years ago and
> > he agreed that they're issues that need to be addressed, but in the
> > time since neither he nor I have been able to get around to fixing
> > them. I'm hoping that someone reading this is able and willing to
> > pitch in. I've also taken this to secteam@, but no one there's made
> > any progress on them in the past 6 months so I figured it was time to
> > approach the broader community. Surely there's a benevolent sh-savvy
> > hacker out there who has time to take these on. They're pretty simple
> > fixes -- the functionality that's needed exists in the scripts
> > already, it just needs to be reused in a few key places.
> > 
> > I also think it would be an appropriate time to discuss retiring portsnap.
> > 
> 
> [snip]
> 
> > 
> > With the inclusion of svnlite in 10 I think the valid question comes
> > up as to whether we really need the portsnap system or whether it
> > could be safely retired. Obviously if the conclusion of that
> > discussion is that we don't need it then these bug fixes would be
> > unnecessary.
> > 
> > The reason I see for it to be retired is that subversion allows us to
> > easily and securely check out the ports tree. It's a one-line command:
> > `svn co https://...`. Keeping it up-to-date it is another one-liner:
> > `cd /usr/ports; svn update`. With the inclusion of svnlite in base,
> > the portsnap code and servers acting as mirrors become redundant and
> > seem like a waste of resources.
> 
> Your report aside, I find portsnap to be far superior in security for
> ports and users. I wish it knew how to checkout source as well.
> 
> 1. It only allows a secure checkout. You can't accidentally checkout
> svn:// or http://.
> 2. It blows away directories with updates. I've witnessed a trojaned
> ports checkout before. 'svn update' does not remove unexpected files,
> nor remove changes. Yes this is a decrease in usability when you've
> modified the file and want to keep the changes, but you can easily make
> a wrapper script to merge in your changes, or use SVN if you really want.
> 3. SVN too often gets into confusing situations on 'svn update' that
> require knowledge of how SVN works to resolve the conflict. Even I with
> my ~10 years of SVN experience I get confused often and frustrated when
> not even 'svn revert -R dir; svn up dir' will revert to the upstream
> version (I may have my example off, but that's the point, it's confusing.)
> 4. SVN asks the user to confirm the public key when first using the
> HTTPS repository. I worry this step will be done poorly by users.
> 5. SVN requires 'svn upgrade' sometimes, this is also confusing for users.
> 6. The way we do HTTPS is through mirrors only, if you pick the wrong
> mirror it's against hard for the user who doesn't know SVN to change to
> a different mirror. Portsnap already handles mirrors excellently by geo
> location.
> 
> Teaching portsnap how to speak SVN, while still behaving the same, may
> cover my concerns.
> 
> To be fair SVN does have its advantages:
> 
> 1. Quicker updates for users.
> 2. Easier patch generation for PR submission.
> 3. Similarly, viewing your changes more easily.

I agree with your analysis.  For systems where I'm not developing ports 
I much prefer portsnap.  I'd also add that SVN has limited integrity   
insurance so even if you verify the certificate you're relying
exclusively on SSL/TLS to ensure correct transmission.  This year alone
much less the whole history of SSL implementations suggests this isn't
the best place to put a single point of failure.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 326 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140411/463b7675/attachment.sig>