71–80 of 104 posts
Earlier quoted context omitted.
Github says: C 98.2%, Makefile 1.8% https://github.com/awslabs/s2n Where is the OCaml source / repo?
edwintorok is comparing s2n with the OCaml-TLS stack. See the links at the end of his comment (and the one below) https://github.com/mirleft
"Yo sn2, I'm really happy for you, Imma let you finish but Ocaml had one of the best TLS stacks of all time ... one of the best TLS stacks of all time!"
Earlier quoted context omitted.
It's interesting, but isn't 10BTC($2500) prize too low to tell us anything about how secure is this ?
Sadly, we're not so flush with cash that we can significantly up the prize, which was itself a donation from the user community. It was quite amusing when some kind users donated Bitcoins into the piñata though :-) We really like the idea of continuing the self-service security bounties, irrespective of their size. One of the nice things about unikernels is that it makes it easy to link in logic like this -- in a con…
Would self-service security bounties enable a distributed bounty ? where each site developer puts a relatively small bounty in his site and his bounty offers him a certain qualification in the eyes of customers , but from the hacker standpoint , if you hacked one , you hacked them all and hence you can collect multiple bounties ?
I think another implementation is not necessarily a bad thing, but it's a shame that this effort couldn't be combined with LibreSSL and BoringSSL or even OpenSSL under a single project. Having more eyes on one thing would be better it would seem.
Earlier quoted context omitted.
Standards-compliant C is more portable than autotools. Autotools is a workaround for non-portable code.
That's a nice ideal, but reality is that it's really easy to need POSIX APIs and then you're firmly in autotools land. That said, I don't like autotools because it encourages #ifdef style nonsense, but not using it requires a lot more thought and more than a little rolling-your-own code and techniques.
Sure.
and then you're firmly in autotools land
Not at all. If you need the send(2) POSIX system call, what are you going to do if autotools detects that you're on a platform which doesn't have the send(2) system call?
Note that this library is currently only providing server functionality, and doesn't do certificate validation (in fact it appears to not do any of the X.509 parts of SSL/TLS). It's certainly interesting, but one of the reasons it's so small is that it's missing critical functionality for many use cases.
I think that's kind of the point. If your web server's TLS stack is trying to validate client certificates, you're doing it wrong.
If you have a bunch of micro services that need to communicate with each other securely, client cert validation solves a big problem.
Earlier quoted context omitted.
That's a nice ideal, but reality is that it's really easy to need POSIX APIs and then you're firmly in autotools land. That said, I don't like autotools because it encourages #ifdef style nonsense, but not using it requires a lot more thought and more than a little rolling-your-own code and techniques.
reality is that it's really easy to need POSIX APIs Sure. and then you're firmly in autotools land Not at all. If you need the send(2) POSIX system call, what are you going to do if autotools detects that you're on a platform which doesn't have the send(2) system call?
Earlier quoted context omitted.
edwintorok is comparing s2n with the OCaml-TLS stack. See the links at the end of his comment (and the one below) https://github.com/mirleft
It's a bizarre comment to be the top response. "Yo sn2, I'm really happy for you, Imma let you finish but Ocaml had one of the best TLS stacks of all time ... one of the best TLS stacks of all time!"
"I love s2n!"
[edit: oh, c'mon with the downvotes, it was a follow-up kanye ref about beck!]
Earlier quoted context omitted.
libcrypto includes the OpenSSL ASN.1 code, which is worrying as all hell, e.g.: https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/asn1/... Or any file in that directory.
Oh man, that code is just horrible. No comments on some of the functions, no comments on the input parameters and return values pretty much throughout. I really thought OpenSSL was in a much better shape.
Why?
I think another implementation is not necessarily a bad thing, but it's a shame that this effort couldn't be combined with LibreSSL and BoringSSL or even OpenSSL under a single project. Having more eyes on one thing would be better it would seem.
No! Let's have many implementations all with completely separate code bases. Then when the next security bug is found it won't affect the whole internet.
N = number of https sites M = number of tls implementations