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. > > > > 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.
I agree with your analysis. For systems where I'm not developing ports I much prefer portsnap. I'd also add that SVN has limited integrity 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
pgpOsWjaR29XO.pgp
Description: PGP signature
