richo

Your patch.. fixes.. one of the issues. Kinda.

I commented with a link to the CPRNG you should be using.

Pretty much immediately I found a bug in his session generation:

https://github.com/davidmoreno/onion/blob/master/src/onion/s...

The fact that in amongst the doc comment is "not really safe" should probably be a big red flag.

Then this happens:

https://github.com/davidmoreno/onion/blob/master/src/onion/s...

Not to mention that here:

https://github.com/davidmoreno/onion/blob/master/src/onion/h...

It'll just let you in if you can guess someone else's session.

Seriously. Systems ship with crypto API's. And uuid libraries.

USE THEM, FFS.

You're assuming that the average HN is in a position to audit crypto code.

We use well audited crypto primitives with formal proofs because they're known safe, or at least orders of magnitude safer than whatever these fools cooked up.

tl;dr provide proof or gtfo. We're not here to audit you.

Amusingly, I went to a meetup with some feds the other day.

Their statutory minimum to investigate is 5k, but they suggested it's worth getting in touch with them either way. If nothing else, it'll give them an excuse to say "cyber" a few more times.

This alone should have blocked your launch. Crypto done right is innately pluggable, by virtue of being composable primitives.

Between this and your "but we totes destroy ciphertext after T seconds" (which is just flat out untennable, and unprovable) I'm pretty spectacularly weary.

I'm also pretty curious to know how you're deriving keys from the users passwords. How is the exchange of key material handled?

"secure"

I weep for all the claims this makes about security.

C++11 is actually really, /really/ nice. If you haven't already you should read up on it.

I was hating c++ for vague reasons I couldn't place. I was wrong.

Would really love to see this with up to date data.

Edit: Just saw the author explain why that won't happen.

In the US 3 years of work experience is good for 1 year of "uni". So 12 years industry experience is a 4 year bachelors degree for immigration purposes.

My understanding was that despite "permanently deleting" if you go back and sign up it'll all magically restore.

Given the username and the domain, I'm thinking not.

Oh, now I see what you're driving at.

I'm still pretty stunned you weren't able to get in touch with them.

When I had issues I just put it through their "how was the ride" thing that pops up after every ride, and they sorted it for me that day.

Not strictly accurate, in the "Why would you want to do this" regard.

Ages ago I was hacking linux onto an ARM soc that claimed to have memory it didn't (it wasn't aware of the display's DMA segment). It was near the top of the address space, so generally speaking it didn't cause too many problems, but until I could debug it I needed to keep memory usage low, wchih meant disabling the disk cache. What a shitshow that was :/

I don't know why he's trying to turn this into some deepseated thought about "knowing your boundaries". It seems to me like his whole point is that naively templating one language with another is a bad idea (is is).

When I read the linkbait title, I implicitly thought "writing code? FIND your boundaries". Think threading is simple? Write something nontrivial with threads. Discover how outrageously hard threads are!

Did they actually do any kind of benchmark to see if it affects performance?

The memory and parse time argument is invalid imo. Lexing a file with wildly abudant whitespace is going to take a delta longer that's insignificant compared to the parse time.

Loading it is normally a concern because of network bandwidth and latency, especially if it'll push you over MTU.

Because if you need to transfer someone who's in cuffs, you don't want to be pissfarting around exchanging keys. Thus most cuffs have the same key.

I hope we've learned a valuable lesson about deserting ops teams today.

I've been struggling to light up new ec2 instances via the API:

<?xml version="1.0" encoding="UTF-8"?> <Response><Errors><Error><Code>Unavailable</Code><Message>The service is unavailable. Please try again shortly.</Message></Error></Errors><RequestID>d063a1f7-9fa9-41bb-8792-xxxxxxxxxxxxxx</RequestID></Response>

Not sure what could be more relevant to devops than idiomatically updating state.

I typically respond fairly abruptly, asking where specifically they got my contact details.

If they respond nicely, and with a plausible explaination I'll generally thank for them for their interest, but tell them I'm not interested and have a nice day.

If they're hostile about it/obviously lie I'll typically blackhole them and mark as spam/internally subscribe them to my "people I will personally ruin when I'm godking of this domain" list.

This is an absurd proposal, but given that the Rio won't let people running pubs in this years call for parties attach stuff to the walls (Can't find the link offhand, but it was in the submission info), I think it's safe to assume that paint guns inside wouldn't happen.

That said, that's the least important reason, the more important one being that you can't just nail people with any kind of gun at an infosec conference, no matter how unconf it is.

Honestly, I doubt it. They had a legit enigma machine last year. It was cool. Their booth was busy because of it.

That said, I doubt anyone interested in working for the NSA would be put off by this/the recent leaks, or that anyone who didn't want to work for the NSA was going to change their mind at DEF CON.

It basically means that spot the fed will be more eventful this year.

It turns out that compression with TLS is hard.

I saw an awesome talk my mnot recently about http/2.0 for which I'm really excited. A large part of it was basically "Lessons we learned from SPDY" which is great, in the longterm.

Personally I feel SPDY was a huge benefit to the internet, but in saying that it was a huge benefit in the form of "a cautionary tale to others"

You can, but then you've got to write this enormous block comment saying "I realise this looks wrong and broken, but ssl is also broken so don't change this constant", until some junior dev inevitably does anyway.

Having known vulnerabilities baked into a standard with "weird looking" mitigation strategies is really poor choice IMO.

That said, I do see your point. There are also other edgecases, like serving statics on a seperate, uncookied domain that benefit greatly from SPDY in the here and now.

Yeah, and if that didn't directly contravene SPDY's specification it'd be a great option: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...

> Secure by default > SPDY

Choose one, SPDY mandates gzip, and gzip in SSL/TLS is vulnerable to leaking repeated plaintext, eg cookies in nearly every implementation.

http://en.wikipedia.org/wiki/CRIME_(security_exploit)