On Fri, Mar 02, 2007 at 02:06:09PM +1100, Erik de Castro Lopo wrote:
Hi all,
I'm working with version 0.9.8c distributed as part of Ubuntu but
I have also veryfied that the same problem exists with the latest
release 0.9.8e.
Please see:
On Fri, Mar 02, 2007 at 10:19:31AM -0500, Richard Salz wrote:
Maybe valgrind should have a rule put in place which resets the
uninitialized data bit in the memory bitmap over the block of data
returned by the low level RAND_() functions provided by OpenSSL.
Yes, exactly my point.
On Sun, May 20, 2007 at 02:42:59PM +0200, Andy Polyakov via RT wrote:
Title: Failed to link static openssl libraries (or non-PIC x86_64cpuid.s)
OS: FC4
HARDWARE: AMD x86 64bit
OPENSSL VERSION: 0.9.8e
OPTIONS:
CFLAGS=-fPIC -O2 ./config no-dso no-shared no-threads
no-zlib -fPIC -O2
On Sun, May 20, 2007 at 03:21:56PM +0200, Andy Polyakov wrote:
The problem is that he's trying to make a shared library linked to a
static library, and the static library isn't built with -fPIC.
No. The way I read it, his static library is build with -fPIC. The user
Right, it seems that it
On Tue, May 22, 2007 at 02:34:47PM +0400, Dmitri Dmitrienko wrote:
With that change, I can actually create a shared libcrypto.so without
using -Bsymbolic.
Great work, Kurt!
Would you please send me a patch? or patch openssl sources directly?
Here is a patch that works for me. I've only
On Fri, Jun 08, 2007 at 05:00:37PM -0700, David Schwartz wrote:
Using the Intel 9.1 compiler on an IA64 system the performance of
AES and (to a lesser extent) other algorithms implemented in
assembly language is less than that using gcc. I've included the
speed output for several of the
Hi,
I've just been informed that there has been a CVE published about
openssl. You can see some of it at:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3108
http://www.securityfocus.com/bid/25163/solution
http://openssl.org/news/patch-CVE-2007-3108.txt
But I haven't seen an
On Tue, Sep 04, 2007 at 05:22:43PM +0200, Stephen Henson via RT wrote:
An alternative technique is mentioned in:
http://marc.info/?l=openssl-devm=118001266831974w=2
There patch from that thread is at:
http://marc.info/?l=openssl-devm=117983173402236w=2
There is also:
Hi,
It seems that in 0.9.8f you did an ABI change in struct ssl_st.
The problem is this change:
+ unsigned int max_send_fragment;
This will break things when something was build against the headers
from 0.9.8e or an older 0.9.8 versions and runs with a 0.9.8f versions.
Such a change needs
On Sat, Oct 13, 2007 at 01:59:38PM +0200, Kurt Roeckx wrote:
Hi,
It seems that in 0.9.8f you did an ABI change in struct ssl_st.
The problem is this change:
+ unsigned int max_send_fragment;
This will break things when something was build against the headers
from 0.9.8e or an older
Hi,
The security announcement had this in it:
Recommendation
--
Either
a) Upgrade to the latest version of OpenSSL (0.9.8f) and rebuild all
packages using OpenSSL for DTLS.
or,
b) Disable DTLS.
How do I disable DTLS?
Is there an easy way I can build the library so
On Tue, Oct 16, 2007 at 01:54:44AM +0200, Dr. Stephen Henson wrote:
On Mon, Oct 15, 2007, Kurt Roeckx wrote:
Hi,
The security announcement had this in it:
Recommendation
--
Either
a) Upgrade to the latest version of OpenSSL (0.9.8f) and rebuild all
On Wed, Oct 17, 2007 at 02:25:13PM +0200, [EMAIL PROTECTED] via RT wrote:
I found this problem originally when trying to use OpenSSH linked
against the new OpenSSL. I get the following error:
$ ssh -V
OpenSSL version mismatch. Built against 90805f, you have 908070
[...]
So OpenSSH stops
On Mon, Oct 22, 2007 at 12:07:30PM +0200, Simon Vallet via RT wrote:
Hi,
On 10/22/07, Andy Polyakov via RT [EMAIL PROTECTED] wrote:
avc: denied { execmod } for pid=1875 comm=ntpdate \
path=/usr/lib/i686/cmov/libcrypto.so.0.9.8 dev=sda8 ino=325290 \
On Sat, Oct 27, 2007 at 08:58:59PM +0200, Andy Polyakov via RT wrote:
Double-checking yields the following buried between 0x0013 relocs :
[EMAIL PROTECTED]:~$ readelf -r
/usr/src/openssl-0.9.8e/i686/cmov/libcrypto.so.0.9.8
[...]
0006354c 000ce102 R_386_PC3200062630
On Sat, Nov 03, 2007 at 10:26:14PM +0100, Andy Polyakov wrote:
[EMAIL PROTECTED]:~$ readelf -r
/usr/src/openssl-0.9.8e/i686/cmov/libcrypto.so.0.9.8
[...]
0006354c 000ce102 R_386_PC3200062630 DES_encrypt2
...
0006bd93 000c3e02 R_386_PC320006b820 BF_decrypt
[...]
On Mon, Nov 05, 2007 at 10:39:58AM +0100, Andy Polyakov wrote:
I believe that -Bsymbolic only gives you a fall sense of security and only
makes it a little harder to replace some functions, but not that much.
Consider following snippet:
void foo(){}
void bar(){foo();}
[...]
-Bsymbolic
Hi,
I would like to remove as many as possible symbols from the symbol table
that are not part of any API. One way of doing that is making those
symbols static. This might also have other positive side effects.
I've tried to find all variables and functions that are only used in 1
file, and
On Wed, Nov 07, 2007 at 08:51:45PM +0100, Simon Vallet via RT wrote:
Hi,
The system in question is indeed a Debian machine -- I should have
mentioned that previously. I can confirm that the libcrypto bundled
in e.g. FC7 does not contain such relocs (which, since it doesn't seem
to be an
On Thu, Jan 17, 2008 at 07:07:48PM -0500, Dave Thompson wrote:
3. Also (in g only) if aes-*-ige is included in the test set,
as it (now) is by default, subsequent tests or shutdown may fail
in any of various ways, because that mode uses IV of 2block = 32B
but only 1AESblock = 16B is
On Sat, Jan 19, 2008 at 03:40:12PM -0500, Brad House wrote:
I compiled OpenSSL (0.9.8g) with my own random number engine - in order to
generate
pseudo random numbers that are not based on unitialized values (if you run
openssl
without doing this you get infinite warnings - of course).
The
On Mon, Jan 21, 2008 at 09:24:34AM +0100, Tomas Mraz wrote:
On Sun, 2008-01-20 at 11:59 -0800, David Schwartz wrote:
I should be able to create a multithreaded application using
a non-multithreaded openssl build provided that I have an ssl
context per thread.
Most definitely not. At
On Mon, Jan 21, 2008 at 05:34:43PM -0800, David Schwartz wrote:
- there is no difference between
multithreaded and non-multithreaded _compilation_ (surely not for errno
and malloc).
Really? So 'errno' refers to a process global in both cases?! (Note that I
said the definition, not the
On Mon, Jan 28, 2008 at 02:22:09PM -0800, David Schwartz wrote:
errno is stored in Thread Local Storage (TLS). You can't link to the
global errno anymore.
For a single-threaded process, there is no distinction between thread-local
storage and a global variable. For a multi-threaded
On Tue, Jan 29, 2008 at 10:22:16PM +0200, Paul Sheer wrote:
I find it hard to believe that there exists a platform where:
On FreeBSD/OpenBSD my program outright core dumped and I could not
figure out why for days and days. Now I have two separate builds - one built
with -D_REENTRANT
On Tue, Jan 29, 2008 at 07:54:54AM -0800, David Schwartz wrote:
There is no global variable named errno, it only exist in the TLS. You
could say that because there is only 1 TLS, that it's global, and it
acts that way. But it's not really the same as a normal global
variable. You
On Sat, Feb 23, 2008 at 10:44:15AM +0100, Dominik Herrmann wrote:
Hi all,
the TLS spec allows for padding TLS record messages with random length
(up to 256 bytes) which helps to disguise the actual length of messages.
I wondered if this has been implemented in openssl yet, but apparently
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=
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 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
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
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
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 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, Oct 25, 2005 at 05:13:17PM +0200, Bruce Stephens via RT wrote:
The following trivial C file fails to compile in 0.9.8a:
#include openssl/sha.h
I think the following files have that problem:
md2.h
md4.h
md5.h
ripemd.h
sha.h
They should all add an include to stddef.h
Kurt
On Fri, Oct 28, 2005 at 09:46:30AM +0200, Andy Polyakov wrote:
Now question to Johnny Lam [who is complaining that we don't bump
versions] and Christoph Martin [who suggests to add versioning on all
symbols]. What exactly didn't work for you? As far as I understand both
NetBSD and Debian
On Sat, Oct 29, 2005 at 03:12:24AM +0100, [EMAIL PROTECTED] wrote:
Hi,
Then when the dynamic linker looks for a symbol, it looks at it
by name. It will go over all objects to see if it exists in it.
It will use the symbol from the first library it finds it in.
This means,
Hi,
Mikael Magnusson found a problem in the handling of fragmented
DTLS handshake packets and has provided a patch for it.
See http://bugs.debian.org/335703 for more information and the
patch.
Kurt
__
OpenSSL Project
On Sat, Oct 29, 2005 at 02:45:51PM +0100, [EMAIL PROTECTED] wrote:
Hi,
If you simply use the -Bsymbolic flag when building libA, doesn't
that solve the problem as well? And in a more portable way, since
vrsioned symbols don't exist on many platforms?
AFAIK, the idea of the
On Fri, Oct 28, 2005 at 09:46:30AM +0200, Andy Polyakov wrote:
Now question to Johnny Lam [who is complaining that we don't bump
versions] and Christoph Martin [who suggests to add versioning on all
symbols]. What exactly didn't work for you? As far as I understand both
NetBSD and Debian
On Tue, Nov 01, 2005 at 10:18:42AM +0100, Kurt Roeckx via RT wrote:
So this looks like an error that doesn't get cleared, and I have
to wonder who should clear it. I don't think COMP_zlib() should
return that it was actually succesful in opening the library,
so it should atleast return
On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote:
Hi,
the appended patch makes libcrypto.so compile without executable stack
requirements. it should be portable accross all versions of binutils (and
doesn't affect any non-linux platform anyway).
The problem is that
On Fri, Nov 11, 2005 at 09:20:58PM +0100, Andy Polyakov wrote:
Concensus was that the failure is caused by a hardware
deficiency. What's your hardware?
Mostly Sun Ultra 10s, running Solaris 8. I can produce the error on more
than
one host, too.
Then it can't be hardware...
platform:
On Tue, Nov 15, 2005 at 09:57:59AM +0100, Andy Polyakov wrote:
Can you test if
http://cvs.openssl.org/chngview?cn=14621 fixes the problem?
Initial tests look good. I haven't seen a failure yet; I'm running a
script to
see if I can stress the problem into reappearing.
On Thu, Dec 29, 2005 at 02:44:18PM +0100, Peter Sylvester wrote:
I saw in the lastest snapshots that in the ssl library the fundction
time has been casted to an unsigned long.
This seems to be some hack to cover the 2038 problem on 32 bit machines.
I am not sure
whether the attempted
Hi,
It seems tht when building a shared version of the library, all
the engines in crypto/engine/ get compiled in, but are
unavailable. Those in engines/ get compiled as a shared library
and are available.
If you make a static library, or link against the static library
they do work as
On Mon, Jan 02, 2006 at 06:57:59PM +0100, Andy Polyakov wrote:
So let's make it a vote.
1. Should there be or not option for built-in engine in shared library
context, or should all engines without exclusion be available as
loadable modules?
My vote is there should be an option for
On Fri, Jan 20, 2006 at 10:28:24AM +0100, [EMAIL PROTECTED] via RT wrote:
... hmmm, where is the patch ?
I did mail it, and it seems to be in the bug report at:
http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1204
But it wasn't in the mail send to the list.
I've attached it
On Sat, Jan 28, 2006 at 05:38:18AM -0800, Joe Gluck wrote:
In which library is that gettime() function in? I did not find it.
(I did not find it in any C library)
He probably meant time(2), but you could also use gettimeofday(2).
Kurt
Hi,
The attached patch makes some function that are only used in that
file static. There doesn't seem to be a reason to export those
functions.
Kurt
Index: crypto/asn1/tasn_new.c
===
RCS file:
Hi,
The attached patch fixes some warnings.
2 of them actually show up using gcc -Wall:
pkcs12.c:508: warning: 'chain2' may be used uninitialized in this function
s_socket.c:288: warning: 'accept_socket' may be used uninitialized in this
function
They're both cases where gcc can inline the
On Wed, Feb 08, 2006 at 09:54:22AM +0100, Jason McIntyre via RT wrote:
-This document conatains all the information necessary to succesfully set up
+This document contains all the information necessary to succesfully set up
You forgot successfully.
Kurt
On Tue, Mar 07, 2006 at 04:20:16PM +1100, Damien Miller wrote:
On Sun, 5 Mar 2006, Kurt Roeckx wrote:
Hi,
I would like to properly place the documetation in the 1SSL,
3SSL, 5SSL and 7SSL section.
It might be proper for your operating system, but it certainly
isn't correct
Hi,
I've attached a patch that fixed a warning about the arguments to
a printf function. strlen() returns an size_t, so it should have
the z modifier. I've also changed it from %d to %u, since it's
unsigned.
Since the BIO printf() doesn't actually support, I've also added
support for that.
On Sun, Mar 12, 2006 at 11:52:30PM +0200, Roumen Petrov wrote:
Kurt Roeckx wrote:
Hi,
I've attached a patch that fixed a warning about the arguments to
a printf function. strlen() returns an size_t, so it should have
the z modifier.
Is the patch tested on windows ?
z modifier - I'm
Hi,
Various places in the source say that old des support is going to
be removed before 1.0. I think it's time to move forward.
I think we have 2 options:
- Completly drop the old des support, including des_old.h
- Drop the libdes compatibility, so that it's only compatible
with older openssl
Hi,
The attached patch converts destest.c to use DES_* function
instead of des_* functions. It's the only part of the source
that is still using the old names.
Kurt
Index: crypto/des/destest.c
===
RCS file:
On Sun, Mar 19, 2006 at 10:34:42PM -0800, Ted Mittelstaedt wrote:
I think we have 2 options:
- Completly drop the old des support, including des_old.h
- Drop the libdes compatibility, so that it's only compatible
with older openssl versions, and people can still use the des_*
versions.
Hi,
When debbuging applications that make use of openssl using
valgrind, it can show alot of warnings about doing a conditional
jump based on an unitialised value. Those unitialised values are
generated in the random number generator. It's adding an
unintialiased buffer to the pool.
The code
On Tue, May 02, 2006 at 12:34:12AM +0200, Ulf Möller wrote:
Kurt Roeckx schrieb:
What I currently see as best option is to actually comment out
those 2 lines of code. But I have no idea what effect this
really has on the RNG. The only effect I see is that the pool
might receive less entropy
On Tue, May 02, 2006 at 08:08:10AM +0200, Marco Roeland wrote:
On Tuesday May 2nd 2006 at 00:34 Ulf Möller wrote:
Not much. If it helps with debugging, I'm in favor of removing them.
(However the last time I checked, valgrind reported thousands of bogus
error messages. Has that
On Fri, Jun 09, 2006 at 12:58:56PM +0200, Howard Chu via RT wrote:
Howard Chu wrote:
I'm seeing a lot of bad record mac errors when receiving a lot of
connection requests at once. It sounds the same as this email
http://www.redhat.com/archives/rhl-list/2005-May/msg01506.html
which
On Mon, Jun 12, 2006 at 04:48:07PM +0200, authesserre samuel wrote:
- fragmentation seems to not work too (based on MTU move on network
interface so I'm not sure that the test is correct)
Is this related to:
http://www.aet.TU-Cottbus.DE/rt2/Ticket/Display.html?id=1245
Kurt
On Tue, Jun 20, 2006 at 02:06:25PM +0200, Bodo Moeller wrote:
On Fri, Jun 09, 2006 at 07:02:36PM +0200, Kurt Roeckx wrote:
On Fri, Jun 09, 2006 at 12:58:56PM +0200, Howard Chu via RT wrote:
Given the lack of response here, we're tracking this now as
http://www.openldap.org/its/index.cgi
On Fri, Jun 23, 2006 at 04:36:07PM +0100, Joe Orton wrote:
Log:
New functions CRYPTO_set_idptr_callback(),
CRYPTO_get_idptr_callback(), CRYPTO_thread_idptr() for a 'void *' type
thread ID, since the 'unsigned long' type of the existing thread ID
does not always work
On Sun, Oct 15, 2006 at 08:18:59PM +0200, ThMO via RT wrote:
Hello,
I've attached a small unified diff, fixing a problem:
· crypto/rand/rand_unix.c:
linux kernel v2.0.35 doesn't support the `poll' system call, so this
file will only compile with the patch applied.
I've enclosed
On Mon, Oct 16, 2006 at 11:47:48AM +0200, ThMO via RT wrote:
What I would like to see is a single Makefile doing both in one go, which
simplies things a lot, e.g. considering the openssl binary, the following
procedure is needed:
· make -f Makefile.shared
· installing the stuff
· make -f
On Wed, Nov 08, 2006 at 12:47:03PM -0800, David Schwartz wrote:
But it gets cast back to the correct type before it is called. These
casts are done the way they are to get type-safety. Removing that option
strikes me as a bad thing.
It does not. Look closely at how these functions work:
On Sat, Dec 16, 2006 at 08:03:43PM +0100, Goetz Babin-Ebell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Ralf,
via RT wrote:
[EMAIL PROTECTED] ~]$ openssl s_client -connect mail.buu.ch:25
-starttls smtp -debug
[...]
I have a patch for s_client which allows
On Fri, Dec 22, 2006 at 05:34:08PM -0500, Mike Frysinger wrote:
On Friday 22 December 2006 10:58, Andy Polyakov wrote:
right now you need to include sys/types.h yourself before trying to
include openssl/sha.h or the build fails ... this patch does what some of
other openssl headers do
On Fri, Jan 05, 2007 at 12:06:15AM +0100, Andy Polyakov wrote:
Guys,
I've written some ARM assembler and would like to benchmark it. So if
anybody on the list has access to linux-arm hardware, please contact me
for instructions. A lot of thanks in advance. A.
I have access to one of
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
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
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
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 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 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 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:
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 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 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 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
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
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 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 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 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 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 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 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
1 - 100 of 571 matches
Mail list logo
