Are you aware that the child zone A(AAAA) records for danube.ns.ptrdns.net differs from the parent zone A(AAA) glue records for danube.ns.ptrdns.net?

Looks like it's the glue records that point to the actual server?

Thanks for letting me know!

This is fixed now, I'll look into why the monitoring tools didn't catch this one as they should have.

It appear to have problems with newer chiphers.

sshd[28670]: fatal: Unable to negotiate with 40.112.150.31 port 47286: no matching cipher found. Their offer: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,3des-cbc,twofish256-ctr,twofish192-ctr,twofish128-ctr,twofish256-cbc,twofish192-cbc,twofish128-cbc,twofish-cbc [preauth]

Hi andreaso, do you happen to have a list of encryption algs on your side? We don't support chacha20-poly1305 (yet) and afaik aes in gcm mode, but e.g. aes ctr are reliable so I find it strange these are not supported on your side.

That sshd only supports the chacha20-poly1305 cipher.

Perfectly fine with that, since I'm the only one logging into that server.

Does it really matter that much what distro it ships with? As long as the laptop ships with any distro preinstalled that hardware tend to be properly supported by the Linux kernel, allowing you to feel safe about installing any other (up-to-date) distro.

From personal experience, yes.

I've got an older dell laptop that came with Ubuntu 12, bought in 2013. I assume everything worked back then, but I needed Windows for school.

Some months ago, wanting to switch, tried Ubuntu 14 and Debian 8. Couldn't get the graphics driver to work on either. Proprietary drivers, other than the ones in the Ubuntu repos, required a mismatch of older/newer library/kernel versions which I couldn't figure out how to get in Ubuntu. The open source driver claimed my hd7670m worked, but in reality I was getting the hd4000 performance out of it.

Everything else worked, a bit noisier though. Either way, I would definitely not feel safe when buying another Linux laptop, proper research is still required.

I'd imagine there are people who consider the article relevant based on its author.

https://en.wikipedia.org/wiki/Adam_Leventhal_%28programmer%2...

To be fair, at least the Tor Project itself makes a rather serious effort to be upfront with its own limitations, etc.

For example, when you use the (recommended) Tor Browser Bundle the start page contains a window containing the following headsup

"Tor is NOT all you need to browse anonymously! You may need to change some of your browsing habits to ensure your identity stays safe."

As well as a link to https://www.torproject.org/download/download.html.en#warning.

That same warning is also present on the main download page: https://www.torproject.org/download/download-easy.html.en

Tor also has extensive documentation about the threat model they protect against, and the limitations of that model.

If there were one thing I could change about security discussions, it's that you can't talk about security in the abstract -- only security relative to some threat or foe.

I think a lot of the conversation would change if we could get people to start talking about security that way.

Well, if you want you can always manually download and verify the the packages.

1) Find list of applicable binary packages, for example by taking a look at https://packages.debian.org/source/wheezy/apt

2) Download http://security.debian.org/dists/wheezy/updates/InRelease, and verify the gpg signature against the archive signing key, found in /etc/apt/trusted.gpg alt. in /etc/apt/trusted.gpg.d/*.gpg

3) Download http://security.debian.org/dists/wheezy/updates/main/binary-..., and verify that its sha256 sum matches what you have in your previously downloaded InRelease file.

4 Inside the downloaded Packages.bz2 you'll find the relative paths as well as the sha256 sums of the packages you want to download.

If nothing else this is a good exercise to see how the different pieces fit together.

Yepp, and there is already an existing tool, which currently supports GitHub as well as Launchpad.

http://manpages.ubuntu.com/manpages/trusty/en/man1/ssh-impor... https://launchpad.net/ssh-import-id

Well, despite its imperfections, how does DNSSEC worsen security compared to regular DNS? Besides, it's not like the use of DNSSEC prevent you from continuing to also rely on additional measures; such as good old fashions CAs, or something better.

Yeah, I'm getting that same premium experience.

Appear to also hit Google Apps as well as any AppeEngine hosted site.

Same problem for weeks now, apparently New York is in Iran

@dcc1: could you please email me at brian@<my username>.com? I work for Google Netops and would like to get some additional info from you so we can debug this.

Well, FreeBSD 9.0 merged those patches into its OpenSSH. Perhaps that was what was floating in the back of your mind?