Attached is an updated version of the test with an additional test
vector. This one happens on 64 bit and not on 32 bit.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password guest if prompted
/*
compile in openssl source tree (1.1 beta or git):
Attached is an updated version of the test with an additional test
vector. This one happens on 64 bit and not on 32 bit.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password guest if prompted
/*
compile in openssl source tree (1.1 beta or git):
Attached is an updated version of the test with an additional test
vector. This one happens on 64 bit and not on 32 bit.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password guest if prompted
/*
compile in openssl source tree (1.1 beta or git):
Attached is a sample code that will test various inputs for the
Poly1305 functions of openssl.
These produce wrong results. The first example does so only on 32 bit,
the other three also on 64 bit.
David Benjamin has already reported incorrect results for Poly1305 in
bug #4439, these are
Attached is a sample code that will test various inputs for the
Poly1305 functions of openssl.
These produce wrong results. The first example does so only on 32 bit,
the other three also on 64 bit.
David Benjamin has already reported incorrect results for Poly1305 in
bug #4439, these are
I wanted to report a behavior of the OpenSSL API that I find at least
highly unusual and unexpected and I suggest to change.
It's regarding these functions to set curve coordinates:
EC_POINT_set_affine_coordinates_GFp
EC_POINT_set_compressed_coordinates_GFp
It is possible to pass them a
The EC_POINT_* API functions accept invalid curve points and don't do
point verification.
Invalid curve points are one of the major implementation pitfalls in
ECC and can lead to attacks [1]. OpenSSL properly validates points in
the _oct2point functions, but I still find this risky. This looks
On Mon, 24 Aug 2015 22:32:24 +0200
Hubert Kario hka...@redhat.com wrote:
After all the whole
heartbleed story can largely be explained by that. I'd propose that
OpenSSL doesn't add any new features without a clear explanation
what advantage they bring in which situation - and who is
On Sat, 22 Aug 2015 10:21:42 +
Alessandro Ghedini via RT r...@openssl.org wrote:
Which adds support for Camellia GCM and adds the correspondent TLS
cipher suites. Most of the code comes from the AES GCM
implementation, so maybe there's an opportunity for some refactoring
there.
May I ask
The code in apps/req.c will use the variable out for both the key and
the csr outfile.
This causes a memory leak because if both a private key and a csr is
written the variable is re-used without freeing it.
See attached patch. (This could also be fixed by using a different var
for both files,
The function obj_cmp() (file crypto/objects/obj_dat.c) can in some
situations call memcmp() with a null pointer and a zero length.
This is invalid behaviour. When compiling openssl with undefined
behaviour sanitizer (add -fsanitize=undefined to compile flags) this
can be seen. One example that
When calling asn1parse -genconf with a nonexistent file this will cause
an access to an uninitialized variable.
Test:
valgrind -q openssl asn1parse -genconf nonexistingfile
The reason is this code in asn1pars.c:
conferr:
if (errline 0)
BIO_printf(bio, Error on line %ld of config
Attached file will crash the asn1 definitions parser.
To test:
openssl asn1parse -genconf segfault.asn
I tried to create a stack trace with gdb to see what's going on and it
is several megabytes in size and contains lines like:
#24353 0x778665be in asn1_multi (cnf=0x7fffd410,
The docs for the verify command here
https://www.openssl.org/docs/apps/verify.html
list a parameter -crlfile.
However this parameter doesn't exist in that spelling. It is called
-CRLfile (uppercase CRL) and the parameter checking is case sensitive.
So the doc and the webpage as it is right now is
Attached patch will allow passing the LDFLAGS variable to the build,
making it possible to pass individual linker flags if wanted. Patch is
taken from Gentoo Linux.
It'd be great if this could be incorporated before 1.0.1
http://bugs.gentoo.org/327421
--- Makefile.org
+++ Makefile.org
@@ -189,6
openssl supports xmpp in the s_client -starttls option, but that only
works to debug client-to-server connections.
For server-to-server connections, a slight change in the xml
(jabber:server instead of jabber:client) is needed.
I've attached a patch that will add a new protocol xmpps (for XMPP
It seems that openssl has a problem with pss certificates and uncommon rsa key
sizes. For all keysizes with keysize mod 8 = 1 (or keysize = n*8+1),
verification of a self-signed test cert fails.
I've not yet investigated if it's the generation or the verification code that
is wrong, it's
This patch allows the Configure script to detect the ar and cc command via
environment variables. Taken from Gentoo package.
Please apply.
--
Hanno Böck Blog: http://www.hboeck.de/
GPG: 3DBD3B20 Jabber/Mail:[EMAIL PROTECTED]
--- Configure
+++ Configure
@@
Taken from Gentoo Linux, please apply.
--
Hanno Böck Blog: http://www.hboeck.de/
GPG: 3DBD3B20 Jabber/Mail:[EMAIL PROTECTED]
respect $MAKE if it is set in the environment so we don't get a mix
of the host `make` and whatever $MAKE is set to when recursing
This patch will create the /lib/engines directory if it doesn't exist on
installation. Please apply.
(Patch taken from gentoo linux)
--
Hanno Böck Blog: http://www.hboeck.de/
GPG: 3DBD3B20 Jabber/Mail:[EMAIL PROTECTED]
--- openssl-0.9.8/engines/Makefile
20 matches
Mail list logo
