/me also misses IRC from the times where you could type --<--{@ and you could be sure it looked just the same on the other end. Monospace was the norm, not the exception and all the IRC clients displayed all lines aligned (to the left, however unbelievable that sounds) regardless of the length of the users name. Today I have to pay attention not to write (b) or (c) because it might turn into a beer or coffee. We often forget to appreciate the simplicity of things.

I have Lync at work and have accidentally sent some kisses when talking about retirement... 401(k)

Last year you could crash lync by dragging a link from the conversation box into the text input box. Instead of fixing the problem they disallowed that behavior.

That behaviour sounds great, although I’m curious which old IRC clients you are referring to. I actually make use of an old Power Mac G3 (B&W) running Mac OS 9 for connecting to some IRC servers (using ircle) and in its case, at least, nicks are assumed to be 10 characters or less. This is quite annoying since there are active users on the channels who have nicks longer than that, so the client simply displays their messages with the extra characters of their nick cut off (to keep the messages left aligned). While I suppose ircle could dynamically resize the area for nicks based on the length of the longest nick that has posted a message, that could be pretty inefficient… not to mention if the channel messages are being logged in a text file with messages left-aligned in there as well (which is what ircle does); the whole file would have to be recreated.

> While I suppose ircle could dynamically resize the area for nicks based on the length of the longest nick that has posted a message, that could be pretty inefficient

XChat does exactly this. So do a few other clients still.

irssi? good basic client that will never let you down. it can grow with you

So... that still works fine on freenode?

It depends on which IRC client you use.

⚘

I continue to use Dropbox as my company is paying for it anyway which makes my dropbox limit bigger than my hard-drive will ever be and it doesn't make sense to make my own life harder for political reasons. On the other hand I also use TOR :)

I never wrote too many C or C++ on the desktop, but often ended up refactoring my embedded code from one style to an other. After a while I realized this is simply my way of understanding the code better, and making sure I haven't missed anything. The direction (inlining or breaking things to functions) almost doesn't matter. What matters is working with the code. It's not so strange If you think about it, designers understand things by sketching and taking notes, that's why you see designers run around with their moleskins.

I believe there will be plenty of linux NASs that will be vulnerable for the forseeable future. NASs are usually bigger and more functional than routers, they tend to run a more full system. Many of these for exampe run bash as far as I remember: http://www.amazon.com/s/field-keywords=QNAP

Just FYI to other owners:

Synology DSM 5.0-4493 Update 5 here: it uses busybox, so not vulnerable.

    synology> which bash
    synology> which sh
    /bin/sh
    synology> which ash
    /bin/ash
    synology> ls -l /bin/sh
    lrwxrwxrwx    1 root     root             7 Jun  5 11:27 /bin/sh -> busybox
    synology> ls -l /bin/ash
    lrwxrwxrwx    1 root     root             7 Jun  5 11:27 /bin/ash -> busybox

Thank you for checking out DSM! This comment saved me a bunch of time.

Given the rate at which QNAP issues updates I'm not expecting it to be fixed for at least another month, and that will most likely be a beta release. I like my QNAP NAS but I don't think I'd buy another QNAP product. They are just too unresponsive to these sorts of things.

Is it possible to update bash on the QNAP? I know you can install an SVN server using Optware IPKG but would this work with the updated Bash? These QNAPs do way to many things with barely any software updates. Its a disaster waiting to happen.

just ssh'd into my WD mycloud.. yep it's vulnerable

WDMyCloud:~# ls -l /bin/sh lrwxrwxrwx 1 root root 4 Jun 30 08:38 /bin/sh -> bash

There are a bunch of daemons running on a fully configured My Cloud. I haven't had much success in finding anything yet, but yeah, it has the bug.

  nas:~# bash --version | head -1
  GNU bash, version 4.2.37(1)-release (arm-unknown-linux-gnueabihf)
  nas:~# uname -a
  Linux nas 3.2.26 #1 SMP Tue Jun 17 15:53:22 PDT 2014 wd-2.2-rel armv7l GNU/Linux
  nas:~# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
  vulnerable
  this is a test

EDIT: formatting.

And indeed I just received an email from QNAP:

http://qnap.benchmarkmails26.com/c/v?e=53F45E&c=47C09&l=149F...

ReadyNAS (Netgear's NAS) uses dash by default, and bash can be upgraded to "4.2+dfsg-0.1+deb7u3"[1].

[1]: https://security-tracker.debian.org/tracker/CVE-2014-6271

Synology released a security advisory outlining the affected Synology NASs: https://www.synology.com/en-global/support/security/bash_she...

import os os.putenv("ANYTHING", "() { :;}; echo bu") os.system("bash")

If this works (and it does) that means it's enough for a CGI script to invoke bash. It doesn't even have to be written in bash.

CDNs are used to deliver static, highly cacheable content, like assets, images, media content, stuff that will be delivered to many users. It is very rare that a website serves this type of content under the same domain as the dynamic content (think cdn1.whatnot.com, assets-myapp.com). In fact for applications with a lot of assets this is a must because of domain sharding and to avoid the overhead of sending the cookies on every single request. Since you need a different domain, you can (you don't have to) use a different certificate, so it's not a strech to use a different private key.

Then there are the applications where security is more important than latency - online banking, payment gateways, tax filing. Those applications don't have too much cache-able content so they simply won't benefit from CDNs.

I also don't see how is this faster. Sure, CloudFlare Keyless SSL is faster than serving the content yourself, but sending that packet over the internet is always going to be slower than not. So now I have a slower (compared to the CDN having my key), more complicated option that requires me to run an additional keyserver and doesn't provide me additional security. The only upside of this seems to be good PR.

Depending how sensitive the content is, in fact if I could I would choose to deliver it over plain HTTP and sign it somehow. That would be best of both worlds.

Edit: I admit I totally missed the point about DDoS protection.

Cloudflare isn't just a CDN. They protect against DDoS attacks. That is what financial instututions are interested in.

You should read eastdakota's blog post from yesterday: https://news.ycombinator.com/item?id=8334933

I think you may be missing that one of CloudFlare's key features is DDoS protection (and in fact it was a DDoS that initially caused the banks to approach them), including at the application layer. That functionality cannot be fulfilled without CloudFlare having access to the content of the communications, nor can any of their other application-layer security functions.