MITM attacks against portsnap and freebsd-update
Matthew Rezny
matthew at reztek.cz
Fri Apr 11 18:04:46 UTC 2014
> 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.
More information about the freebsd-hackers
mailing list