> Your report aside, I find portsnap to be far superior in security for > ports and users. If you look at the portsnap build code you'll see that the first thing portsnap does is pull the ports tree from Subversion. It uses the URL svn://svn.freebsd.org/ports. By not using ssl or svn+ssh the entire ports archive is exposed to corruption right from the start. > I wish it knew how to checkout source as well. Aside from the fact that anyone sitting on a hop between svn.freebsd.org and the portsnap build server could MITM the entire ports tree, the main problem here is that the source would have to come from version control, and the version control system used by the FreeBSD project is Subversion. If you distrust Subversion you should be equally distrusting of portsnap and this hypothetical source checkout system. > 1. It only allows a secure checkout. See above. To be fair I think this perception has a lot to do with the fact that the server side code for portsnap and freebsd-update wasn't released publicly until a year ago (I'd requested it from Colin while attempting an audit two years ago). So you, like myself, never really had a fair chance to review it. I'd always just assumed it was rock solid. It was, after all, written by the FreeBSD Chief Security Officer! I'm sure your line of thinking was similar. Portsnap's first release was in 2005 and freebsd-update's was in 2006. That means we went a solid 7 years without a public review of either of those two core components. This is a huge problem, and an important lesson for the project on the subject of transparency; everything relating to FreeBSD needs to be open for review no matter who built it or what their credentials are. > You can't accidentally checkout svn:// or http://. You only have to check out the ports tree once so there's really only one time you're going to have to worry about correctly entering a URL. That and on the rare occasion that you have to call svn switch, which you shouldn't have to call to update ports unless one of the mirrors is down. Checking out /usr/ports creates a record of the URL used in /usr/ports/.svn/wc.db. If entering the https:// prefix is really that big of a deal, which I'm not convinced that it is, why not pre-load an ..svn/ directory into the /usr/ports/ directory at the time the ports tree is installed? This would eliminate the need to call svn checkout altogether. > 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. I'm not familiar with what you're talking about so I can't really respond to it. I guess I'm not clear: you're describing the process whereby a port containing malicious code is checked out by svn update? If the malicious code or metadata pointing to malicious code is on svn it's in portsnap too. I'm not clear on what a "trojaned ports checkout" is. > 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.) The only issue I've ever run into was an error message saying I needed to first run svn upgrade. Why were you using svn revert on your ports tree? Is that a common use case? Maintaining a local ports repository with Subversion requires knowledge of, at a minimum, two commands: svn co, and svn up. Actually you can get away with just one: `svn co https://... /usr/ports`. Any problem a user may encounter can be fixed with `rm -rf /usr/ports; svn co https://... /usr/ports`. If a person is using portsnap it means they're building their own ports. Make is immeasurably more difficult to use than subversion. If they're competent enough to wade through the nightmare that often is building ports on FreeBSD they're certainly competent enough to familiarize themselves with svn co. > 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. If you look at the /root/.subversion/servers configuration file you'll see that one of its parameters is ssl-authority-files. Using this it would be simple to include the server's public keys in base, allowing users to call svn update without having to verify anything. Portsnap hard-codes the public key fingerprint in /etc/portsnap.conf. The line from the config file is: # ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem > 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. Again, if they're using `make` it's safe to say they can handle svn upgrade and svn switch. Worst case scenario we have to document the few edge cases svn can throw in the handbook. > Teaching portsnap how to speak SVN, while still behaving the same, may > cover my concerns. That may be simpler than patching portsnap and freebsd-update. I don't think it would be worth the effort though. I don't see how adding `0 0 * * * svn up /usr/ports` to crontab is any more difficult than adding `0 0 * * * portsnap cron`. -David _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"