Date: Fri, 11 Apr 2014 20:04:35 +0200 From: Matthew Rezny <matthew@reztek.cz> To: freebsd-hackers@freebsd.org Subject: Re: MITM attacks against portsnap and freebsd-update Message-ID: <2012148.SzKMgBGQYg@desktop.reztek> In-Reply-To: <CAHAXwYCGkP-o0VvMXj5S8-KNA45aTvy%2BsrjDL_=8-x9Dza5z5Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Retiring Portsnap > > 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. The inclusion of svnlite is more a replacement for CVSup/csup than it is a replacement for portsnap. They serve different use cases. SVNlite (and csup before it) allow hackers to fetch both src and ports trees at any point in time. Portsnap gives the end user, who only wishes to build ports but never modify them, a fast way to fetch and update the ports tree. I used CVSup for years and was very thankful when we got csup in base, thus alleviating the need to do the dance of extract the ports tarball, install CVSup (without X11 but with lots of other deps) and then checkout the ports tree. SVNlite was a necessity to replace csup for those who wish to do a checkout. It even has benefits over csup; svnlite makes it much easier to maintain local patches in the ports tree. However, it has a major drawback too; it's slooooww. The main advantage of portsnap over csup was the speed of the fetch and extract. SVNlite is much slower than csup for initial checkout. I agree portsnap could be replaced, but SVNlite isn't the answer. Instead, I suggest rsync. Rsync is fast to do the initial fetch and even faster to do the update. Setting up a few rsync servers that host the current version of the ports tree (and /usr/src too) would be trivial. There are other projects using rsync exactly for this purpose (e.g. Gentoo Linux, macports) for quite some time. The biggest effort would be adding rsync to base, but being that we have svn(lite) in base it should not be a big deal to add rsync. The only reasons I see it as any effort is that the license is non-ideal (so it will take some convincing) and SSL/TLS support is not yet mainstream, so we would need to maintain patches or push those for inclusion upstream. As an alternative, or in addition to, SSL/TLS support for the TCP connection, the trees could be fetched not as thousand of files, but as a couple tar files (src.tar and ports.tar), the hashes of which could be verified before extraction. Those tar files should be uncompressed in order to allow the rsync algorithm to work its magic during updates. For best performance in all cases, the initial fetch could download (or copy from install media) tar.xz files, which, after hash verification, are decompressed and extracted in separate steps, saving the uncompressed tar files for subsequent updates. Then each update is a matter of rsync the tar files, verify the new hashes, and extract into the final destination. It would be a bonus if the scripts to do this optionally triggered a snapshot before extraction to allow easy rollback.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2012148.SzKMgBGQYg>