Reminder to update your machines and invalidate your possibly compromised certs.
cross posted from /g/
Name:
Anonymous2014-04-08 16:22
I hate openssl and everything about it. Those devs need to be executed. They've been the cause of every major crypto problem in the past decade. Other than the fact that they've somehow gained majority market share with one of the worst implementations / APIs in existence.
I hate pgp and everything about it. Those devs need to be executed. They've been the cause of every major crypto problem in the past decade. Other than the fact that they've somehow gained majority market share with one of the worst implementations / APIs in existence.
>>2 The repeated magic numbers in their parsing code are rather alarming. It's really no wonder they get compromised so often...
>>4 Thank goodness GnuTLS has its own problems! It's important for major implementations to have parity with one another.
Name:
Anonymous2014-04-13 11:07
I don't even know what you're all so pissed about. The CIA, NSA and the rest of alphabet-soup agencies can read all your shit no matter whether it's OpenSSL, SexySSL or AnalSSL. You don't have any rights, suck a dick and shut up.
>>12 Or just static analysis of c. You don't need to change the language.
Name:
Anonymous2014-04-13 14:41
>>13 ORLY? Any examples of "static analysis of c"?
Name:
Anonymous2014-04-13 14:44
Do Theo de Raadt and co. have any plans for making their own SSL/TLS library?
Name:
Anonymous2014-04-13 14:48
>>14 A buffer overread can be detected by seeing if there is a path that leads to an indexing of an array by an integer variable that has not been constrained to be shorter than its length.
Name:
Anonymous2014-04-13 14:55
>>16 Of course it can be detected. The question is if it can be detected in C. Can you eliminate runtime array bounds checking with static analysis of C, by the way? Because with ATS you can.
>>21 use a programming language with better typing
Name:
Anonymous2014-04-13 15:48
>>23 Prevention of buffer overreads by typing requires dependent type, which people don't know how to use and syntax obtuse and the existing systems are terrible. You can't get things done when you restrict yourself to a type system. But after the program is written, you can look at each point a routine is invoked, and check that the parameters passed will never cause problem.
Name:
Anonymous2014-04-13 15:50
>>24 I'm dreaming of an easy to use non-shit, non-bloated dependent type functional language
Name:
Anonymous2014-04-13 15:51
>>8 I wonder how this kid knows. I have the right to find and kill you for being a complete defeatist retard who doesn't even know simple cryptography.
>>25 dependent type language forces you to write more for same amount of code. You need type inference if you want same benefits with less typing. But then who knows what inferred type will be.
Name:
Anonymous2014-04-13 16:01
>>28 And what did you want, programs that automatically verify themselves? That would require an AI that would make human programmers obsolete.
This is what happens when technologically becomes popular. Anything that becomes popular turns to shit. fuck steve jobs
Name:
Anonymous2014-04-13 16:13
>>29 A verification that issues a warning if a read or a write to memory occurs outside of its intended region. It may say that it proves that it may happen, or cannot prove that it wont happen. Either case is cause for concern.
Name:
Anonymous2014-04-13 16:28
Why cant we all just use Common Lisp, instead of C/C++?
Name:
Anonymous2014-04-13 16:34
>>33 Languages are intermediate representations for machine code. Sometimes a specific string of machine code is needed and is not easy to express as a string of common lisp and to hope that compiler will translate it as such. A lower level gives you more control over some things. Many things can be done in common lisp, but buffered reads and writes without length checks are still valid things to do as long as they are done safely. common lisp is flexible and capable language that lets you do unsafe things as well.
>>32 The compiler doesn't understand the words "intended region". If it was smart enough to understand them, then it probably would be smart enough to write better code than you.
Yeah, that's right. There's nothing to worry about if we just use encryption. It's not as if encryption software has any vulnerabilities.
Name:
Anonymous2014-04-13 16:48
>>26 If you knew any cryptography you would know that any cypher can be broken with enough computational power. The NSA has that power. And do you know who it might sell your info to? Of course you don't.
Go back to writing RESTful web services for iOS, wimp. Real programming has never been about easiness or prettiness, and will never be.
Name:
Anonymous2014-04-13 17:02
>>36 Intended region in general is loose ended. But if you limit the meaning you can get enough results to catch bugs like buffer over reads and writes.
int* a = malloc(n*sizeof(int)); // a points to a buffer of size n*sizeof(int) int a[34]; // a is a buffer of size 34*sizeof(int)
....
... = a[n]; // Is n always less than a's length in this code path? .... read(fd, buffer, n); // is n shorter than the length of buffer?