Forgot your password?

Comment: Re:What about a re-implementation... (Score 1) 288

by blueg3 (#46760067) Attached to: OpenBSD Team Cleaning Up OpenSSL can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.

Only if you've set that part of your stack to locked. Otherwise it could get paged out to disk. Thanks to the fun of timing on computers, the amount of actual time that passes between "receive [into memory]" and "zero out" is arbitrarily long.

Comment: Re:What about a re-implementation... (Score 1) 288

by blueg3 (#46759981) Attached to: OpenBSD Team Cleaning Up OpenSSL

So if C is so bad why should we trust the languages that are implemented in it? You do realize that most of these "safe" languages are written in C, right?

I'm just going to link to a previous comment where I answered the same question.

TLDR: Languages aren't "written in" anything, and the language the compiler is written in has no bearing on the capabilities of the language it compiles. (We're all Turing complete here.)

Comment: Re:It's not just the implementation (Score 1) 445

by blueg3 (#46725319) Attached to: Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

For one, you need to be able to correlate your requests with the other party's responses in a way that is non-replayable (regardless of the encryption used).

The payload is of variable length so that heartbeats can be used for path MTU discovery.

Just because someone "sees no reason" for a design decision doesn't mean there is no reason.

The heartbeat spec isn't necessarily a great design, but it's by no means the problem. If you can't implement what is essentially ping that passes two variable length data fields, what hope do you have of being able to implement anything useful?

Comment: Re:for a library... (Score 2) 445

by blueg3 (#46721973) Attached to: Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

And what languages are these languages themselves written in?

Languages aren't written in anything. (Though, the specification for a language could be written in English, for instance.) Compilers and interpreters are written in a language.

and if those languages are dangerous to directly write apps in, then surely they must be equally dangerous to write the compilers and platforms on which your non-VM language runs.

A program isn't run by a compiler, it's compiled by a compiler. There's a pretty significant difference.

There's also a significant difference between writing an application in C and writing an application in a language that is compiled by a compiler written in C. For one, the compiler has a much smaller attack surface. There is a lot less code in the compiler than there is in the set of applications written in that language. For another, vulnerabilities aren't magically transitive like that. Imagine a language, M, that is just like C, but it is impossible to create a buffer overrun. The M compiler is written in C. It contains a buffer overrun bug. That doesn't magically make M source code compiled with this compiler also contain a buffer overrun. To say it another way: the features of the language the compiler is written in don't really matter for the security of a compiled application, it's the quality of the implementation of the compiler -- the compiler needs to produce a binary that actually has the properties of the language it's compiling for.

At some point you're working with something written in C, C++ or assembler

No, you're not. Traditionally, a compiler is written in the same language that it compiles: so a C++ compiler is written in C++ and a Forth compiler is written in Forth. (Realistically, most are now written in C as a component of GCC.)

Comment: Re:It's not just the implementation (Score 4, Informative) 445

by blueg3 (#46721753) Attached to: Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

As others have indicated, the primary stated use of heartbeat is for DTLS, which is not over TCP.

The payload length is not actually superfluous. The packet has an arbitrary amount of both payload and padding, of which only the payload is echoed to the sender. Roughly: { uint16 payload_len; char payload[]; char padding[]; } The intent of payload_len is to tell you which of the bytes following it are payload rather than padding. Of course, you need to check that it's less than the remaining data in the packet. (Per the spec, at least 16 less -- at least 16 bytes of random padding are required.)

Comment: Re:Modern audiophiles are no different. (Score 2) 469

He didn't say they weren't different. He said people think that vinyl is "more genuine" or "more accurate" than digital. Genuine is a weasel word -- it's ill-defined. (Probably the most reasonable definition here is "closest to how the creator of the music intended for you to hear it". But, I digress. It's hard to measure.) Vinyl is certainly less accurate than a good digital representation.

It can be different, though, because it introduces flaws that the digital representation doesn't have. Maybe those flaws make the music "better" in some sense, but not "more accurate".

The test of intelligent tinkering is to save all the parts. -- Aldo Leopold