The SSH connection protocol is the final SSH protocol; depending on your perspective, it sitseither on top of or after the SSH transport protocol and SSH user authenticationprotocol . It's the level ofSSH where all of the useful things happen, like remote logins,command execution, and port forwarding.

An important thing to know about the connection protocol is thatit's a multiplexed protocol. There is not one logical connectionthat everything happens over but instead multiple channels, alloperating more or less independently. SSH

A while back, I was reading this lobste.rs posting and ran into what struck me as an interesting question from evaryont :

I haven’t taken a deep look at this, but doesn’t OpenSSH needfrequent access to the [user] secret key material? [...]

My gut reaction was that it didn't, but gut reactions are dangerousin crytographic protocols so I decided to find out for sure. Thisturned out to be more involved than I expected, partly because thevarious

You may recall that back in April, OmniTI suspended activedevelopment of OmniOS , leaving its future insome doubt and causing me to wonder what we'd do about our currentgeneration of fileservers . There was a certainamount of back and forth on the OmniOS mailing list , but in generalnothing concrete happened about, say, updates to the current OmniOSrelease, and people started to get nervous. Then just over a weekago, the OmniOS Community Edition was announced ,complete with OmniOSCE.org . Since then,

Ted Unangst recently wrote moving to https ( via ), in which he gave usthe following (in his usual inimitable style):

On the security front, however, there may be a few things tomention. Curiously, some browsers react to the addition of encryptionto a website by issuing a security warning. Yesterday, reading thispage in plaintext was perfectly fine, but today, add some AES to themix, and it’s a terrible menace, unfit for even casual viewing. Butfill out the

Over the years I've written a number of things here about how myFirefox setup seems to be fairly fragile as far as memory usagegoes, in that any number of addons orother changes seem to cause it to leak memory, often rapidly.Sometimes there have been apparently innocuous changes in addons Iuse, like NoScript , thatcause a new version of the addon to make my Firefox sessions explode.

(I've actually bisected some of those changes down to relativelyinnocent changes and found at least one pattern

Through Planet Python I recently woundup reading this article on Python decorators .It has the commendable and generally achieved goal of a clear,easily followed explanation of decorators, starting out by talkingabout how functions can return other functions and then definingdecorators as:

A decorator is a function (such as foobar in the above example)that takes a function object as an argument, and returns a functionobject as a return value.

Some experienced Python people are now jumping up and and down tosay that this definition is not

The Observed Failures slide deck from NASA DASHlink (via many places) isan interesting and even alarming collection of observed failuresin hardware and software, mostly avionics related. I find it bothentertaining and a useful reminder that all of this digital stuffis really analog underneath and that leads to interesting failure modes .Lest you think that all of these were hardware faults and us softwarepeople can be smug, well, not really .There are more; read the whole thing, as they say.

I recently saw a discussion about whether people used the Emacsbindings for readline editing or the Vi bindings (primarily in shells, although there areplenty of other places that use readline). The discussion made merealize that I actually had some opinions here, and that my viewwas that Emacs bindings are better.

(My personal background is that vim has been my primary editor foryears now, but I use Emacs bindings in readline and can't imagineswitching.)

The Emacs bindings for readline aren't better

In reaction to SELinux's problem of keeping up with app development , one obvious suggestion is to have upstreamsdo this work instead. A variant of this idea is what DrScriptt suggested in acomment on that entry:

I would be interested in up stream app developers publishing thingsabout their application, including what it should be doing. [...]

Setting aside the practical issue that upstream developers are notinterested in spending their time on this, I happen to believe thatthere are serious and probably unsolvable problems with