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

[Bryan Drewery]

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.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140410/103aeb30/attachment.sig>