Hacker News Reader

Comment by josteink | Hacker News Reader

    2. Affected configurations
    
    OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL that supports AES-GCM.

What would be a good/simple way to test if your system is one of these? How can I check which ciphers my build of OpenSSL supports?

Edit: The following command returns nada on all my systems. I guess that puts me in the clear?

    $ openssl --version 2>&1 | grep gcm

View on HN

What I did is try to use the cipher : ssh -c aes256-gcm@openssh.com (host)

If you get "no cipher found", you're clear, if you can connect you can disable the cipher (while keeping others) with this line in you sshd_config:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

Source: http://www.openssh.com/txt/gcmrekey.adv

"Unknown cipher type" for me, but close enough that it seems to mean the same thing.

I think this is a better test:

$ openssl enc --help 2>&1 | grep gcm -aes-128-ecb -aes-128-gcm -aes-128-ofb -aes-192-ecb -aes-192-gcm -aes-192-ofb -aes-256-ecb -aes-256-gcm -aes-256-ofb

(Tested on ArchLinux with OpenSSL 1.0.1.e-5)

Thanks!

I've never understood why so many applications pipe help output to STDERR.

It's not an error... I asked for the output! shrug

Traditionally applications will print usage (which is usually the same as --help) if arguments are missing or invalid flags are given. This is clearly an error condition, and it would be very bad to print the output to stdout in that case. --help will simply call usage(), so there's no difference in behavior. I think it would be feature bloat / overkill to have programs print usage to stdout or stderr depending on how it's invoked, even if it's easy to implement.

It's not even one extra line of code. usage() should take the output stream as a parameter.

Even so, is it really advantageous to have "foo --help" send usage info to stdout, but for "foo -?" to send "Invalid switch '-?'" followed by usage info to stderr?

More importantly, usage information doesn't conform to the structure of ordinary program output, and can therefore be annoying or even dangerous if inadvertently treated as such, so it really, really does belong on stderr for any program whose stdout might reasonably be used as input to another program.

I appreciate your point, but I still disagree.

> usage information doesn't conform to the structure of ordinary program output

This is weak. Pretty much every command line program will have multiple flags that change the output in some profound way. Why should --help get special treatment?

That's a weird, conceptual argument (and program output is not strongly typed). I just want "program --help | less" to work, especially when there's a lot of options.

Mark Jason Dominus did a quick-and-dirty survey on where usage messages should go: http://blog.plover.com/Unix/usage.html

Most people think stderr (so as not to muck up pipelines when you get the invocation syntax wrong). But then there is also the cleverer option of using stdout if and only if the help is explicitly requested, which seems to be justifiable, popular in the survey, but (I think) not much implemented.

Reply on news.ycombinator.com