Hi Mike,
There appear to be some unrelated changes to ssl/Makefile in the patch
(I think they are changes introduced during a build). I removed those,
the patch applied cleanly against a fresh branch of master, and the
tests pass individually, and during 'make test'.
I took the liberty of cre
Hi Mike,
I downloaded the test and successfully ran it in my local build. Two
changes were required (Ubuntu 13.04. gcc 4.8.1) to satisfy the compiler:
- At line 170, move the declaration of "int i" outside the 'for'
- Replace strlcpy (undefined) with a memcpy, although there may be
bett
On 13 Apr 2014, at 01:54, tolga ceylan wrote:
>
> The RFC has a lot of statements about silently dropping packets in case of
> various anomalies. But the correct action should be to drop the connection.
> This would uncover faulty implementations and other bugs that may
> slide due to 'silently
That's also in github pull request #50
Kurt
On Sun, Apr 13, 2014 at 12:20:37PM +0200, Ben Noordhuis via RT wrote:
> Add the =back that was making pod2man abort. Fixes the `make install`
> target, it was failing at the install_docs sub-target.
> ---
> doc/ssl/SSL_CONF_cmd.pod | 2 ++
> 1 file c
STACKOF -> STACK_OF
See attachment...
--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/
diff --git a/doc/ssl/SSL_get_peer_cert_chain.pod
b/doc/ssl/SSL_get_peer_cert_chain.pod
index 49fb88f..059376c 100644
--- a/doc/ssl/SSL_get_peer_cert_chain.pod
+++ b/do
Add the =back that was making pod2man abort. Fixes the `make install`
target, it was failing at the install_docs sub-target.
---
doc/ssl/SSL_CONF_cmd.pod | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/ssl/SSL_CONF_cmd.pod b/doc/ssl/SSL_CONF_cmd.pod
index bbda10a..552d4a8 100644
--- a/d
I've prepared a proof-of-concept unit/regression test for the Heartbleed
bug that I've posted at: http://goo.gl/wTYD9K
If folks are interested, I can prepare an official patch to add it to
OpenSSL.
Thanks,
Mike
mbl...@acm.org
The RFC has a lot of statements about silently dropping packets in case of
various anomalies. But the correct action should be to drop the connection.
This would uncover faulty implementations and other bugs that may
slide due to 'silently drop' behavior. It'll also make malicious
activity a bit