From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 16:05:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B559103; Fri, 11 Apr 2014 16:05:49 +0000 (UTC) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBD3C1C00; Fri, 11 Apr 2014 16:05:47 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id s3BG5ltK039292; Fri, 11 Apr 2014 11:05:47 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id s3BG5lRT039291; Fri, 11 Apr 2014 11:05:47 -0500 (CDT) (envelope-from brooks) Date: Fri, 11 Apr 2014 11:05:47 -0500 From: Brooks Davis To: Bryan Drewery Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] Message-ID: <20140411160547.GA38192@lor.one-eyed-alien.net> References: <53472B7F.5090001@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <53472B7F.5090001@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org, secteam , Colin Percival , David.I.Noel@gmail.com, security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:05:49 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >=20 > > I also think it would be an appropriate time to discuss retiring portsn= ap. > >=20 >=20 > [snip] >=20 > >=20 > > 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. > >=20 > > 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. >=20 > 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. >=20 > 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. >=20 > Teaching portsnap how to speak SVN, while still behaving the same, may > cover my concerns. >=20 > To be fair SVN does have its advantages: >=20 > 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=20 I much prefer portsnap. I'd also add that SVN has limited integrity =20 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 --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iKYEARECAGYFAlNIEtpfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY1NUQ1MTlDMjZBNzgyRTcyNTI5OUJGMDVE OEU4QkU5RjIzODFBRDQACgkQXY6L6fI4GtTxSgCgu9oP6xhumbyu2xlFLLGbeUYg m24AnjXpLDUOSLqZH8UIzOGfUaNcKeK/ =xreO -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1--