> On Sat, Jul 16, 2011 at 5:22 PM, Theo de Raadt <dera...@cvs.openbsd.org> > wrote: > >> It does look like an open source result of some talented people, not > >> an OpenBSD or BSD specific result. > > > > OpenSSH happened as a *direct result* of the types of decisions that > > OpenBSD developers make. > > Hi, Theo. That would be a compelling point if those decisions were > automatically good ones. Simply being "the types of decisions that > OpenBSD developers make" is not automatically a selling point, as > evidenced by the relatively small market share of OpenBSD itself. I'm > gong to dig into some history here. > > The result of "the types of decisions that OpenBSD developers make" > are precisely why it is marginalized. The core technology is robust > and excellent, but the featureset is not only limited, but actively > dangerous. I'll explain why: this gots into some serious way-back > history, but I'm not seeing any change.
Fascinating. > First is the amazing foolishness of having the default key generators > accept blank passphrases without even requiring a special command line > option. Second is lack of a reliable key expiration mechanism. Once a > blank passphrase is in use, clearing them up is very difficult to > detect and very awkward to revoke the keys. These are deadly aspects > of the SSH protocol and toolkits that could, and should, have been > addressed a decade ago, even before OpenSSH existed. The result is > that I've personally had one hell of a time getting people off of less > technologically secure tools, such as HTTPS access for Subverson which > stores passwords in clear text on UNIX and Linux clients. This tool > has SSH based access available to avoid the UNIX or Linux client > password storage of HTTPS, but lacks an integral chroot cage or > dedicated shell to restrict the users: the results are various weird, > homegrown integrations. (Sourceforge uses one, and it's messy due to > the lack of chroot cage compatible integration for Subversion.) Git > does a better job of this, by the way, which is a good reason to > prefer it. Wow, it's a real bummer that OpenBSD has caused you so much harm. Have you considered trying to live 100% without our software? Of course, if you did that, you'd have to keep your mouth shut, wouldn't you. That does not seem in your nature.. > But I've dealt with.... 6 such source control integration efforts in > the last 5 years, and it's painful to deal with the passphrase free > keys and having to hand-build an expiration mechanism *eveyr single > time*, even if I do keep my old notes. This could be eased by client > side software changes, such as refusing to accept a blank password > without a special command line option or user privilege, or even a > setting in ssh_config to block such behavior. If a client can override > that, then it's their problem, but the lack of any significant barrier > to generating such keys is a long standing issue I've had to clean up > after again, and again, and again. Your pain runs very deep. Have you considered suicide? > This is compounded by the longstanding refusal to accept chroot cage > integration for SSH or SCP. (Yes, it's me: I was one of the people > publishing such patches over a decade ago.) Debian has actually > provided some tools for helping set that up, Ah, yes, Debian. They have an amazing history when it comes to patching our code.... good luck with that. > and they're quite useful > for at least raising the bar for clients with locally authorized > access to escape their cages. SFTP does a better job of it, and its > relatively new built-in chroot cages are welcome. But the chroot cages > for SSH are long-desired for Subversion and CVS repository access, and > software regression testing environments. (By the way, the better > security models of "git" with its dedicated shell and good key > management tools well justify switching to it from CVS or Subversion, > along with its vastly better "merge" behavior.) > > If we couple all of those decisions, mostly policy decisions, with the > longstanding incapability to transfer symlinks as symlinks, rather > than as the targets of the symlink, by both SFTP and SCP, and the > direct result of those decisions doesn't look so hot, even though the > underlying protocol and implementation in OpenSSH have much to > recommend them. Your grief would seem more sincere if didn't look like a shopping list. Except your name or those you work for do not occur in the donations list or anywhere else... > This last one is actually built into the RFC's, but if > a new RFC is needed, then it's about time. We don't author the RFC. But thanks for trying to make us responsible for that, too. Pray tell, what are you responsible for, besides bitching out other people's efforts? > The result is that I'd *rather* trust the end-to-end encryption of the > underlying SSH protocol. But the missing basic security features, > whose absence is either tacitly accepted (such as making passphrase > keys more difficult to use), or a matter of deliberate policy (such as > refusal to work with chroot cages for SSH or SCP) have seriuosly > impeded the use and security of OpenSSH itself. So I have some > longstanding, and I think well-founded, concerns about "the types of > decisions that OpenBSD developers make". Wow, you are just about the biggest prick I've read a message from in months. Try to have a better day, ok?
