On Thu, Jan 02, 2014 at 12:59:39PM -0500, Daniel Kahn Gillmor wrote:
On 01/02/2014 12:35 PM, Dr. Stephen Henson wrote:
That's just TLS. To add more complete support to OpenSSL including storing
private keys in PEM files and public keys in case we ever use it in ECDH
certificates it needs an
Hi,
I recently ran into this:
http://safecurves.cr.yp.to/
It seems that openssl doesn't support any of the curves that are
listed there as safe.
At least the curve 25519 is popular and has a draft for using it
in TLS. Would it be possible to add at least support for that
curve?
Kurt
On Fri, Dec 20, 2013 at 01:29:39PM -0500, David Miller wrote:
From: Misaki.Miyashita via RT r...@openssl.org
Date: Fri, 20 Dec 2013 06:59:18 +0100
Hi,
We don't have RNG instructions, and calling _sparcv9_random() causes
SIGILL and debug tools (i.e. gdb and mdb) stops when
Hi,
I want to change the default bits from 1024 to 2048 and the
default digest from sha1 to sha256.
There seems to be inconsistencies in how the various apps
handle the defaults:
- genrsa has an #define DEFBITS 1024, you can't modify it in the
config file.
- ca has:
#define ENV_DEFAULT_MD
So this seems to be:
http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List
On Tue, Nov 05, 2013 at 11:43:54PM -0500, Daniel Kahn Gillmor wrote:
I noticed recently that OpenSSL as a client is happy to connect to a
server that offers a trivially-crackable DH group.
You can try it out at https://demo.cmrg.net/
Other modern TLS implementations will refuse to connect
On Wed, Oct 23, 2013 at 12:59:53AM -0500, Nico Williams wrote:
On Wed, Oct 23, 2013 at 08:32:35AM +1000, Peter Waltenberg wrote:
There is no 'safe' way to do this other than hardwired. Admitted, we have a
fairly ugly stack on which to find that out, multiple independently
developed lumps of
It seems that s_server by default use 512 bit for the DHE if it's
not specified, and s_client just accepts that.
Is there a way to set a minimum size? I think think 512 really
is too short and shouldn't be accepted by any client. I think
we should have a minimum of 1024.
Kurt
On Mon, Aug 26, 2013 at 02:45:10PM +0200, Stephen Henson via RT wrote:
What is happening is related to how ENGINE works with dynamically loaded
engines in different contexts.
If you do ENGINE_by_id(foo) it will first look for an engine called foo in
the list of engines and if present
On Fri, Jul 26, 2013 at 12:13:45PM +1000, Peter Waltenberg wrote:
The compiler can't optimize if the symbols are called inter-module either.
If it knows they're hidden, it can. And it clearly can
optimize things if you mark them static so it knows they're
not called inter-module.
And
I've submitted a patch in 2007 to make as much as possible static,
but it never got applied, so I never bothered writing a patch to
make the rest hidden. I think making things static is even better
than hiding them, and should work on all platforms. It's just
that you can't making everything
On Tue, Jun 18, 2013 at 12:30:58AM -0400, Dave Thompson wrote:
Looking at your state_debug.log (which tries 1.2) I see:
read/write preliminary SMTP as normal
write ClientHello: offer 1.2
read ServerHello: agree 1.0 DES-CBC3-SHA
rest of handshake normal
Aside: I notice your build (here
On Tue, Jun 18, 2013 at 05:25:06PM -0400, Dave Thompson wrote:
My conclussions:
- One of the 2 sides doesn't implement
DES-CBC-SHA/DES-CBC3-SHA properly
... I think you're right and I suspect the other side because
openssl interoperates with lots of folks -- unless there's
something
Hi,
When talking to an exchange server I get some weird behaviour when
using the 1.0.1e version. I get a TLS 1.0 connection, but the
problems go away when using -no_tls1_2
An example connection is with:
openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
-quiet
1)
On Thu, Jun 13, 2013 at 08:32:28AM +0200, Kurt Roeckx via RT wrote:
Hi,
When talking to an exchange server I get some weird behaviour when
using the 1.0.1e version. I get a TLS 1.0 connection, but the
problems go away when using -no_tls1_2
An example connection is with:
openssl s_client
On Wed, Jun 05, 2013 at 11:27:43AM +0200, Andy Polyakov wrote:
And do switch on optimization.
Ironically other references found elsewhere suffer from very same
problem. E.g. HAVEGE discussed possibilities of collecting uncertainty
from branch predictor with if (A==0) A++; else A--; but
On Mon, Jun 03, 2013 at 07:25:24AM -0400, John Foley wrote:
Rather than dropping it from the list, another option would be to
re-prioritize the list. Given MD5 is weak, it should be at the end of
the ClientHello signature algorithms extensions. This would facilitate
backwards compatibility,
On Mon, Jun 03, 2013 at 07:25:24AM -0400, John Foley wrote:
Rather than dropping it from the list, another option would be to
re-prioritize the list. Given MD5 is weak, it should be at the end of
the ClientHello signature algorithms extensions. This would facilitate
backwards compatibility,
Hi,
It seems that tls12_get_req_sig_algs() sends that MD5 is a
supported signature algorithm, except in that case of FIPS.
Would it make sense to drop MD5 from that list?
Kurt
__
OpenSSL Project
On Mon, Mar 18, 2013 at 07:43:41PM +0100, Andy Polyakov via RT wrote:
Anyway, other users confirm that
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9ab3ce124616cb12bd39c6aa1e1bde0f46969b29
solves the problem. Thanks for additional information.
I also got 1 confirmation that
On Wed, Mar 13, 2013 at 01:42:07PM +0100, Andy Polyakov via RT wrote:
Actually my intention was to test if the problem can be reproduced with
*same binary*. That's why I suggested that you, Kurt, compile one and
hand it to user. Other way around would also work, i.e. user hands over
the
On Wed, Mar 13, 2013 at 01:42:07PM +0100, Andy Polyakov via RT wrote:
Actually my intention was to test if the problem can be reproduced with
*same binary*. That's why I suggested that you, Kurt, compile one and
hand it to user. Other way around would also work, i.e. user hands over
the
On Mon, Mar 04, 2013 at 08:08:58PM +0100, Andy Polyakov via RT wrote:
Hi,
As soon as user can confirm that
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5702e965d759dde8a098d8108660721ba2b93a7d
does the trick, it goes to stable branches.
Yes, the user confirmed that this
On Thu, Mar 07, 2013 at 10:05:13PM +0100, Andy Polyakov via RT wrote:
I can't either, and yet I have multiple people reporting problems
with the 1.0.1e version saying the 1.0.1c version works without
problems.
This happened recently on Fedora as well.
See:
On Thu, Mar 07, 2013 at 10:05:13PM +0100, Andy Polyakov via RT wrote:
I can't either, and yet I have multiple people reporting problems
with the 1.0.1e version saying the 1.0.1c version works without
problems.
This happened recently on Fedora as well.
See:
On Thu, Feb 28, 2013 at 07:42:26AM -0500, Brad House wrote:
On 2/28/13 5:07 AM, Kurt Roeckx via RT wrote:
Hi,
I've been getting reports from users who see issues with openssl
after the upgrade from 1.0.1c to 1.0.1e
See:
http://bugs.debian.org/678353#10
I tried on my Intel Core i7
On Fri, Mar 01, 2013 at 06:03:18PM +0100, Kurt Roeckx wrote:
On Thu, Feb 28, 2013 at 07:42:26AM -0500, Brad House wrote:
On 2/28/13 5:07 AM, Kurt Roeckx via RT wrote:
Hi,
I've been getting reports from users who see issues with openssl
after the upgrade from 1.0.1c to 1.0.1e
See
On Fri, Mar 01, 2013 at 09:32:21PM +0100, Andy Polyakov via RT wrote:
Hi,
I've been getting reports from users who see issues with openssl
after the upgrade from 1.0.1c to 1.0.1e
See:
http://bugs.debian.org/678353#10
I tried on my Intel Core i7-3770S with 1.0.1e connecting to his
On Fri, Mar 01, 2013 at 09:53:23PM +0100, Andy Polyakov via RT wrote:
The Debian package
is a real 1.0.1e version, not a backport of patches, that does have that
patch applied.
I can't reproduce the problem with 'openssl s_client -connect
mail.uni-paderborn.de:465' from
Hi,
I've been getting reports from users who see issues with openssl
after the upgrade from 1.0.1c to 1.0.1e
See:
http://bugs.debian.org/678353#10
http://bugs.debian.org/701826
Note that the first message in the first bug is unrelated to this.
Kurt
Hi,
It seems to 1.0.1 stable branch contains a commit to reduce version
skew. (commit af454b5bb09bf647b4854dc277f2eefc151b2608) This single
commit has those stats:
86 files changed, 241 insertions(+), 178 deletions(-)
This seems to be a combination of many different patches. Some
just
.
They are in /usr/share/man/man1 and /usr/share/man/man5/, where
they belong.
Kurt
On Sat, Feb 16, 2013 at 6:41 AM, Kurt Roeckx via RT r...@openssl.org wrote:
On Sat, Feb 16, 2013 at 09:41:41AM +0100, Ivailo via RT wrote:
The manual pages placement should use MANPREFIX instead of MANSUFFIX
On Sat, Feb 16, 2013 at 05:02:28PM +0100, Ivailo via RT wrote:
I don't understand what you're trying to fix. You seem to be
renaming req.1 to openssl-req.1 and SSL_new.3 to
openssl-SSL_new.3.
Yes, that is because I was not able to read the manual pages like
passwd.1ssl. When I issue man
On Sat, Feb 16, 2013 at 09:41:41AM +0100, Ivailo via RT wrote:
The manual pages placement should use MANPREFIX instead of MANSUFFIX or the
manual pages can not be read. The following patch does the job:
http://pastebin.com/auK9EFSG.
I don't understand what you're trying to fix. You seem to
On Wed, Feb 13, 2013 at 12:19:19PM +0100, Andy Polyakov via RT wrote:
Probably this strict aliasing 64-bit optimization bug for
crypto/bn/bn_nist.c
What bug are you talking about? There doesn't seem to be a strict
aliasing warning in that file, and they use a union to get around
the
On Mon, Feb 11, 2013 at 05:07:22PM +0100, OpenSSL wrote:
OpenSSL version 1.0.1e released
===
Running the test suite gives me:
[...]
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
1: zlib
On Mon, Feb 11, 2013 at 06:33:39PM +0100, Dr. Stephen Henson wrote:
On Mon, Feb 11, 2013, Kurt Roeckx wrote:
On Mon, Feb 11, 2013 at 05:07:22PM +0100, OpenSSL wrote:
OpenSSL version 1.0.1e released
===
Running the test suite gives me
On Mon, Feb 11, 2013 at 07:22:49PM +0100, Dr. Stephen Henson wrote:
On Mon, Feb 11, 2013, Kurt Roeckx wrote:
On Mon, Feb 11, 2013 at 06:33:39PM +0100, Dr. Stephen Henson wrote:
On Mon, Feb 11, 2013, Kurt Roeckx wrote:
On Mon, Feb 11, 2013 at 05:07:22PM +0100, OpenSSL wrote
On Thu, Feb 07, 2013 at 10:22:24PM +0100, Stephen Henson via RT wrote:
On Thu Feb 07 00:43:10 2013, steve wrote:
On Wed Feb 06 23:01:25 2013, bugs-...@moonlit-rail.com wrote:
I haven't had a chance (yet?) to bisect the code to find the culprit,
but I can take a stab at it if a
On Tue, Feb 05, 2013 at 03:18:28PM +0100, OpenSSL wrote:
OpenSSL Security Advisory [05 Feb 2013]
SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169)
Nadhem Alfardan and Kenny
On Wed, Nov 07, 2012 at 03:47:11PM +0100, Florian Weimer wrote:
Hi,
the attached patch implements wildcard matching and introduces the
X509_CHECK_FLAG_NO_WILDCARDS flag to disable it if necessary.
In addition, it implements case-insensitive comparison of host names
and email address
On Mon, Nov 19, 2012 at 09:09:32PM +0100, Dr. Stephen Henson wrote:
On Mon, Nov 19, 2012, Kurt Roeckx wrote:
On Wed, Nov 07, 2012 at 03:47:11PM +0100, Florian Weimer wrote:
Hi,
the attached patch implements wildcard matching and introduces the
X509_CHECK_FLAG_NO_WILDCARDS flag
On Fri, Nov 09, 2012 at 04:08:07PM +0100, Andy Polyakov wrote:
when Will Openssl 1.1.0 become beta?
What is it you miss in 1.0.x? Note that every new feature can be
considered for back-port [naturally if it doesn't break binary
compatibility].
Maybe his question was what the state of 1.0.2
Hi,
1.0.0 had this:
/* SSL_OP_ALL: various bug workarounds that should be rather harmless.
* This used to be 0x000FL before 0.9.7. */
#define SSL_OP_ALL 0x8FFFL
1.0.1 now has:
#define SSL_OP_NO_TLSv1_1
On Wed, Apr 25, 2012 at 12:40:50AM +0200, Stephen Henson via RT wrote:
Side effect of doing that is any application built againt OpenSSL 1.0.1
or 1.0.1a headers which has an option to set SSL_OP_NO_TLSv1_1 will have
that turned into noop and will have to be recompiled for that to work.
On Thu, Mar 29, 2012 at 09:46:34PM +0200, Kurt Roeckx wrote:
On Sun, Mar 25, 2012 at 01:52:22PM +0200, Stephen Henson via RT wrote:
[steve - Sun Mar 25 13:11:30 2012]:
I've done some more tests and it seems that the size of the client hello
message is significant: all the options
On Wed, Apr 18, 2012 at 08:04:28PM +0200, Andy Polyakov via RT wrote:
I've had 2 users report a crash in RC4() on x86_64. The
backtrace looks like:
#0 RC4 () at rc4-x86_64.s:343
#1 0x012d in ?? ()
#2 0x00df in ?? ()
#3 0x020b5660 in ?? ()
#4
On Thu, Apr 19, 2012 at 09:08:48PM +0200, Kurt Roeckx wrote:
On Wed, Apr 18, 2012 at 08:04:28PM +0200, Andy Polyakov via RT wrote:
I've had 2 users report a crash in RC4() on x86_64. The
backtrace looks like:
#0 RC4 () at rc4-x86_64.s:343
#1 0x012d in ?? ()
#2
Hi,
I've had 2 users report a crash in RC4() on x86_64. The
backtrace looks like:
#0 RC4 () at rc4-x86_64.s:343
#1 0x012d in ?? ()
#2 0x00df in ?? ()
#3 0x020b5660 in ?? ()
#4 0x7fc075f6a9c9 in rc4_hmac_md5_cipher (ctx=optimized out,
out=0x20aae98
On Mon, Oct 31, 2011 at 05:56:53PM +0100, Tomas Mraz via RT wrote:
By default the 0/n split is used but in case the
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first
record with 1/n-1.
There are terminators that also have a problem with this 1/n-1
splitting. You might want to
On Sun, Apr 01, 2012 at 02:42:20PM +0200, Dr. Stephen Henson wrote:
On Sun, Apr 01, 2012, Dr. Stephen Henson wrote:
Did a quick hack modification setting header version to 0x3,0x0 and it now
*will* connect to some sites it didn't before with a long client hello
including paypal. It
On Fri, Apr 13, 2012 at 12:22:56PM +0200, Andy Polyakov wrote:
There is also:
http://bugs.debian.org/665836
I don't quite understand. The problem was reported for i386, but only
amd64 update packages are provided.
I think you have a misunderstanding of how Debian works. I am
using amd64
On Sun, Apr 01, 2012 at 12:17:19PM +0200, Andy Polyakov wrote:
It's empirically found that SSL 2.0 and TLS 1.0
ClientHellos larger than 256 bytes *are* accepted, while TLS 1.1 and 1.2
have to be shorter to be accepted.
TLS version in ClientHello *message* is denoted by corresponding
On Sun, Apr 01, 2012 at 02:42:20PM +0200, Dr. Stephen Henson wrote:
On Sun, Apr 01, 2012, Dr. Stephen Henson wrote:
Did a quick hack modification setting header version to 0x3,0x0 and it now
*will* connect to some sites it didn't before with a long client hello
including paypal. It
On Sat, Mar 31, 2012 at 08:12:54PM +0200, Andy Polyakov wrote:
I've done some more tests and it seems that the size of the client hello
message is significant: all the options that work reduce the size of
client hello. If you use the -debug option and check out the first
message bytes 4
On Sat, Mar 31, 2012 at 11:09:15PM +0200, Andy Polyakov wrote:
Bugs never make sense. But what do you mean by doesn't seem to happen
here? Can you connect with 'openssl s_client -connect
www.paypal.com:443 -cipher DEFAULT:\!AES' and 'openssl s_client -connect
www.paypal.com:443 -cipher ALL'?
On Sun, Apr 01, 2012 at 12:13:44AM +0200, Dr. Stephen Henson wrote:
OpenSSL 1.0 and later will use an *SSLv3* compatible client hello provided no
SSLv2 ciphersuites are requested. The default cipherstring now excludes all
SSLv2 ciphersuites so by default you wont get SSLv2 client hellos. If
On Wed, Mar 28, 2012 at 10:34:49AM +0200, Joe Bew via RT wrote:
Please, consider this bugreport:
https://bugs.archlinux.org/task/29111
There is also:
http://bugs.debian.org/665836
Kurt
__
OpenSSL Project
On Sun, Mar 25, 2012 at 01:52:22PM +0200, Stephen Henson via RT wrote:
[steve - Sun Mar 25 13:11:30 2012]:
I've done some more tests and it seems that the size of the client hello
message is significant: all the options that work reduce the size of
client hello. If you use the -debug
On Fri, Mar 23, 2012 at 06:49:43PM +0100, Stephen Henson via RT wrote:
[ste...@stebalien.com - Fri Mar 23 18:21:39 2012]:
OpenSSL negotiation times out when connecting to Outlook Exchange 2007
both through Outlook Web Access (webmail) and IMAP (POP untested). This
bug appeared between
Hi,
I was looking at the AES-NI support in 1.0.1, and it seems that
it now has been merged in EVP (but test/test_aesni still
exists in HEAD).
This has the following effect:
1.0.0h:
$ openssl speed aes-128-cbc:
type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes
aes-128
On Sun, Mar 18, 2012 at 07:16:27PM +0100, Andy Polyakov wrote:
Hi,
1.0.1:
$ openssl speed aes-128-cbc:
type 16 bytes 64 bytes256 bytes 1024 bytes 8192
bytes
aes-128 cbc 110450.10k 120831.36k 122216.11k 123465.05k
123909.46k
$ openssl speed
On Sun, Mar 18, 2012 at 07:24:25PM +0100, Andy Polyakov wrote:
So if you directly use the AES API you used to have a little better
performance,
but now you don't get the AES-NI support and so are a factor slower when
using it.
Is this the normal and expected behaviour?
I hope
Hi,
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq$64,%rsi# rsi - M2
| leaq296(%rsp),%rcx# rcx - pX2 ; 641 bits, 11
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq
On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT wrote:
On 03/17/2012 09:03 PM, Stephen Henson via RT wrote:
[n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
I captured the handshake (attached), and it seems the client
advertises TLS 1.2. Could it be that the
On Sun, Mar 18, 2012 at 12:20:48AM +0100, Kurt Roeckx via RT wrote:
On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT
wrote:
On 03/17/2012 09:03 PM, Stephen Henson via RT wrote:
[n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
I captured the handshake
On Sun, Mar 18, 2012 at 12:49:35AM +0100, Kurt Roeckx via RT wrote:
I can confirm that removing the no-ssl2 part gets me a TLS
instead of SSLv3 connection.
The problem seems to be this code in s_client.c:
#if !defined(OPENSSL_NO_SSL2) !defined(OPENSSL_NO_SSL3)
meth=SSLv23_client_method
On Wed, Mar 14, 2012 at 02:30:29PM -0400, Mike Frysinger wrote:
On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
On Wed, Mar 14, 2012, Mike Frysinger wrote:
On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
OpenSSL version 1.0.1 released
On Tue, Feb 28, 2012 at 12:08:31AM +0100, Andy Polyakov via RT wrote:
In Debian we ship several versions of the shared libraries on i386.
One that's build the default instruction set of that architecture
(which is still i486 I think), and then 2 optimised versions,
one for 586 and one for
On Tue, Feb 28, 2012 at 12:08:31AM +0100, Andy Polyakov via RT wrote:
In Debian we ship several versions of the shared libraries on i386.
One that's build the default instruction set of that architecture
(which is still i486 I think), and then 2 optimised versions,
one for 586 and one for
Hi,
It seems that the padlock engine does something wrong for
aes192 and aes256. Things work perfectly with aes128.
If I use openssl enc -aes256 -nosalt to encrypt something
it generates something different with and without the padlock
engine loaded.
Also, when the padlock engine is loaded, it
Hi,
It seems that the padlock engine does something wrong for
aes192 and aes256. Things work perfectly with aes128.
If I use openssl enc -aes256 -nosalt to encrypt something
it generates something different with and without the padlock
engine loaded.
Also, when the padlock engine is
On Sat, Jan 14, 2012 at 08:11:30PM +0100, Andy Polyakov wrote:
It's unfortunate and should have been taken care of at 1.0.0 release. I
mean it should have been 1.0 or 10 or something.
I'd just like verification that this is intentional and we can expect
binaries built against the 1.0.0
On Sat, Feb 18, 2012 at 05:28:41PM +0100, Stanislav Meduna wrote:
On 18.02.2012 17:02, Edward Ned Harvey wrote:
So these studies went out and scoured the internet, collecting public keys
from every service they could find, which amounts to something like 1-2
million servers, and they
On Sat, Jan 14, 2012 at 08:11:30PM +0100, Andy Polyakov wrote:
I notice the shared library names (and SONAME) are 1.0.0 on the
OpenSSL 1.0.1 libraries.
It's unfortunate and should have been taken care of at 1.0.0 release. I
mean it should have been 1.0 or 10 or something.
I'd just like
On Mon, Nov 07, 2011 at 03:06:38PM -, Charles Bryant wrote:
You write:
The ppc version of bn_mul_comba4 produces an incorrect result because
one of the products added into r[5] is wrong.
...
Isn't it amazing for how long can a bug go unnoticed? This one was
present in original
On Tue, Sep 20, 2011 at 08:37:35PM +0200, Richard Könning wrote:
Please read http://www.openssl.org/~bodo/tls-cbc.txt, problem #2.
You then see that the problem is already addressed in OpenSSL
0.9.6d, over seven years ago. See also
On Fri, Feb 11, 2011 at 04:47:27PM -0500, Thor Lancelot Simon wrote:
On Fri, Feb 11, 2011 at 10:41:54PM +0100, Kurt Roeckx wrote:
One of my problems with openssl is that changing compile time
options break the ABI. And people don't seem to be willing to
change this.
With every
Hi,
I'm wondering what your plan is with version numbering and
changing sonames for future versions of the library. With
the 1.0.0 release you made it libssl.so.1.0.0 (and
libcrypto.so.1.0.0).
Current CVS HEAD seems to be having 1.1.0 as part of it's soname,
OpenSSL_1_0_1-stable still has
On Fri, Feb 11, 2011 at 03:56:53PM -0500, Thor Lancelot Simon wrote:
On Fri, Feb 11, 2011 at 09:01:01PM +0100, Kurt Roeckx wrote:
I'm planning on uploading a version based on 1.0.0 to Debian
soon. And I would like to keep the current soname for the
rest of the release cycle
Hi,
It seems that with with the change to 0.9.8m postfix and dovecot
don't properly accept connections anymore in all cases.
In postfix's log this look like:
SSL_accept:SSLv3 flush data
read from 7FA27CBE5E70 [7FA27CBEF150] (5 bytes = -1 (0x))
SSL_accept:error in SSLv3 read
On Mon, Mar 22, 2010 at 02:01:23PM +0100, Stephen Henson via RT wrote:
[k...@roeckx.be - Mon Mar 22 09:48:17 2010]:
As far as I can tell client does exactly the same between a connection
that works and one that doesn't work. The server just closes the
connection.
No client
On Mon, Mar 22, 2010 at 02:01:23PM +0100, Stephen Henson via RT wrote:
[k...@roeckx.be - Mon Mar 22 09:48:17 2010]:
As far as I can tell client does exactly the same between a connection
that works and one that doesn't work. The server just closes the
connection.
No client
On Mon, Mar 22, 2010 at 04:30:23PM +0100, Kurt Roeckx wrote:
On Mon, Mar 22, 2010 at 02:01:23PM +0100, Stephen Henson via RT wrote:
I notice that the certificate in question is using SHA256. Do the
affected applications call SSL_library_init() only and not
OpenSSL_add_all_algorithms
On Mon, Mar 22, 2010 at 04:30:23PM +0100, Kurt Roeckx wrote:
On Mon, Mar 22, 2010 at 02:01:23PM +0100, Stephen Henson via RT wrote:
I notice that the certificate in question is using SHA256. Do the
affected applications call SSL_library_init() only and not
OpenSSL_add_all_algorithms
Hi,
With version 0.9.8m we're unable to read encrypted data written by
older versions. The commit that breaks it has this changelog:
The block length for CFB mode was incorrectly coded as 1 all the time. It
should be the number of feedback bits expressed in bytes. For CFB1 mode set
On Fri, Jan 01, 2010 at 11:50:29PM -0500, Richard Salz wrote:
You're missing the point -- your comment is the height of irony, in a way.
Use a suppression to make Valgrind shut up.
Maybe you should try to suppress that in valgrind before telling us
what to do. Try running a simple program
On Sat, Jan 02, 2010 at 10:29:38AM -0500, Richard Salz wrote:
I took a closer look at current valgrind and the client requests. I
assume you mean doing something like this:
if (VG_USERREQ__RUNNING_ON_VALGRIND) memset(st, 0, sizeof st);
It might be a nuisance to fix these, but at
On Tue, Sep 01, 2009 at 02:23:38PM +0200, Mark Phalan wrote:
In OpenSolaris we follow an interface stability classification system
which marks interfaces according to how stable they are believed to be.
You can see more information here if interested:
On Wed, Apr 01, 2009 at 03:03:44PM -0400, Geoff Thorpe wrote:
Fair comment, I'll respond to this as best I can, but this is not any
kind of official statement.
On Wednesday 01 April 2009 14:01:18 Kurt Roeckx wrote:
Hi,
I was under the impression that for the 1.0 version you would
Can some comment on this:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0653
Is this still a problem in 0.9.8 versions?
Kurt
__
OpenSSL Project http://www.openssl.org
Development
On Mon, Mar 02, 2009 at 09:46:55PM +0100, Dr. Stephen Henson wrote:
On Mon, Mar 02, 2009, Kurt Roeckx wrote:
Can some comment on this:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0653
Is this still a problem in 0.9.8 versions?
It was addressed in OpenSSL 0.9.5.
I
Hi,
The documentation for PKCS7_verify says:
PKCS7_verify() returns 1 for a successful verification and zero or a
negative value if an error occurs.
And in apps/smime.c there is this code:
if (PKCS7_verify(p7, other, store, indata, out, flags))
On Mon, Aug 11, 2008 at 02:50:55AM -0700, David Schwartz wrote:
Ted T'so wrote:
At this point, you've just spent reams and reams of electrons stating
the obvious.
Yes, for the second time, because some people *still* don't understand it.
(It's quite obvious to you and me, not so
On Mon, Jun 02, 2008 at 01:54:28PM +0100, Ben Laurie wrote:
Bodo Moeller wrote:
On Mon, Jun 2, 2008 at 12:47 PM, Dr. Stephen Henson [EMAIL PROTECTED]
wrote:
On Sun, Jun 01, 2008, Ben Laurie wrote:
Stop const mismatch warning.
- else if (index_name_cmp(row,rrow))
+ else if
On Thu, Apr 03, 2008 at 05:25:38PM +0200, David Erosa García wrote:
So I ran the command with a random IV:
openssl enc -aes128 -K 188458A6D15034DFE386F23B61D43774 -iv 1 -P
I've tried this on various (Linux) arches with a 0.9.8 version.
On alpha I get:
salt=
Hi,
In Debian we've enabled the TLS extensions and it seems this results in
not being able to connect to some sites.
We've had 2 bug reports so far:
http://bugs.debian.org/471681
http://bugs.debian.org/471896
I can not reproduce the problems when both the server and client are
openssl. I've
0.9.7d (the current 0.9.7 release is
fine).
The oldest I've tried was 0.9.7e which still worked.
The patch in ticket #1629 works for the first problem, since it's
exactly the same problem. It doesn't for the second problem.
Kurt Roeckx via RT wrote:
Hi,
In Debian we've enabled the TLS
401 - 500 of 571 matches
Mail list logo
