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. -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature
