1.02 then. (0.9.8 is fine. I'm ok with 1.0.0/1.0.1 remaining broken.)
On Fri, Jun 3, 2016 at 10:08 AM, Rich Salz via RT wrote:
> Sorry, but 0.9.8 and 1.0.0 are end of life and getting no updates and 1.0.1 is
> only getting security fixes at this time.
>
> --
> Ticket here: http://rt.openssl.org
The commit
From: "Dr. Stephen Henson"
Date: Fri, 1 Apr 2011 15:46:03 +
Subject: [PATCH] Add additional OPENSSL_init() handling add dummy call to
(hopefully) ensure OPENSSL_init() is always linked into an application.
https://github.com/openssl/openssl/commit/c4acfb1fd049f52fb074b103
Richard Levitte - VMS Whacker wrote:
I've no problem with
OpenSSL *also* being distributed in .tar.bz2, as long as noone in the
team thinks that will eat too much of our disk space.
At the very least, the two latest/most popular downloads
could be provided in both formats. That would give you t
Denis Andreevich wrote:
Ok... ok... If you do not want use 7zip because it is win-app,
but why you don't want use "standard" tool like bzip2?
Now you're asking the right question.
openssl.org should consider offering sources in bzip2 format.
It would cut download time by 18%:
-rw-rw-r--1 d
Denis Andreevich wrote:
Why you don't use 7-Zip for compressing OpenSSL sources?
Just tar "openssl-0.9.8.tar" size 16 281 600 bytes
bzip2"openssl-0.9.8.tar.bz2" size 2 611 152 bytes
7zip "openssl-0.9.8.tar.7z" size 2 123 591 bytes
DK> Because the compression gains
Denis Andreevich wrote:
Why you don't use 7-Zip for compressing OpenSSL sources?
Just tar "openssl-0.9.8.tar" size 16 281 600 bytes
bzip2"openssl-0.9.8.tar.bz2" size 2 611 152 bytes
7zip "openssl-0.9.8.tar.7z" size 2 123 591 bytes
Because the compression gains are
Stanislav Malyshev via RT wrote:
I have discovered something that seems to be a crash in OpenSSL running with
Apache+mod_ssl. It happens when SSL connection times out (I simulate it by
suspending the reader process, but it happens also in production with very slow
clients). Apache gives message
Richard Levitte - VMS Whacker wrote:
dank> If so, perhaps that might provide a way forward: apps that need
dank> a stable interface can use the gnutls api (which openssl could
dank> provide as a wrapper); everyone else could use the openssl api
dank> (which gnutls seems to provide as a wrapper, u
Richard Levitte - VMS Whacker wrote:
Quite honestly, even though I'm quite an enthusiastic OpenSSL
developer for years and have been for years (since it started,
really), I can't really recommend OpenSSL as an LSB candidate from
that point of view, as it stands today. Every "major upgrade" (whic
Ken Goldman via RT wrote:
http://www.openssl.org/docs/crypto/threads.html says
...
"id_function(void) is a function that returns a thread ID. It is not
needed on Windows nor on platforms where getpid() returns a different
ID for each thread (most notably Linux)."
On my Linux system, getpid() re
Andy Polyakov wrote:
I'm looking into http://gcc.gnu.org/PR19923
which claims that gcc-4.0 is slower on 'openssl speed'
than earlier versions. The only huge regression seems
to be in md2. ...
I'm interested in the observed performance regression even with the
hand-coded assembly; that simply
Andy Polyakov wrote:
I'm looking into http://gcc.gnu.org/PR19923
which claims that gcc-4.0 is slower on 'openssl speed'
than earlier versions. The only huge regression seems
to be in md2.
Note that most of the code involved in the report in question is
hand-coded assembler. Meaning that the
I'm looking into http://gcc.gnu.org/PR19923
which claims that gcc-4.0 is slower on 'openssl speed'
than earlier versions. The only huge regression seems
to be in md2. Has anyone else looked at this yet?
I imagine it's a gcc problem, but I thought I'd ask
here just in case.
OpenSSL 0.9.7e 25 Oct
Bodo wrote:
> Dan Kegel <[EMAIL PROTECTED]>:
>
> >> (Your are right that it is strange that the SSL23_methods support
> >> SSL_read but not SSL_peek, but this should be fixed in s23_lib.c
> >> and not in s23_srvr.c.)
>
> > Your wish is my co
Bodo Moeller wrote:
> >>> I just realized I have to accept either SSLV2 or SSLV3 (or TLS)
> >>> connections, so I switched from SSLv3_server_method() to
> >>> SSLv23_server_method(). But oops, that doesn't support SSL_peek()!
> >>> What to do?
>
> >> Use SSL_accept first. It will change the SSL
Guillermo Maturana wrote:
>
> > /**
> > Set the given SSL_CTX's private key to the given PEM file, using the given
>passphrase.
> > @param ctx The ssl context to modify.
> > @param file The name of the PEM file containing the desired private key.
> > @param passphrase The nul-terminated
I just bumped up again against the fact that OpenSSL
still lacks a modern autoconf system.
It *sure would be nice* if you'd use Gnu automake and autoconf
on posix-compliant systems, and keep the old Configure system
for non-posix systems.
Did I mention how nice that would be? Damn, it would be
Bodo Moeller wrote:
> On Sun, Dec 17, 2000 at 04:22:17PM -0800, Dan Kegel wrote:
> >>> I think it is a fool's errand to try to make it possible to
> >>> "share" every data structure across threads.
> >> Noone has said "every",
Rich Salz wrote:
>
> > To play devil's advocate, why don't we get rid of all locks in OpenSSL?
>
> Because, as we found out (back when my team first contributed the locking code
> to SSLeay), if you only have the granularity of a single "openssl lock", then
> only a single thread can do SSL_writ
Richard Levitte - VMS Whacker wrote:
> rsalz> What is the problem you are trying to solve? Who has asked for it?
>
> The problems is operations on one object locking out operations on
> separate objects of the same type (thus making the locking needless in
> that sense). I have asked for it qui
Rich Salz wrote:
> What is the problem you are trying to solve? Who has asked for it?
Inquiring minds want to know.
To play devil's advocate, why don't we get rid of all locks in OpenSSL?
Let's say we split OpenSSL into the classic API, which would consist of
a wrapper that was careful to lock
N. wrote:
> > > Just thought you might know the answer to this one: how is it that
> > > Verisign is selling certificates for 40 bit and 128 bit encryption - the
> > > chosen session key size has nothing to do with the certificate! or am I
> > > completely off here?
> >
> > I don't quite underst
Nagaraj Bagepalli wrote:
> I am looking at the openssl code and there is a comment in ssl3_accept
> routine just before calling buffering bio which says "Buffering bio need
> to be pushed so that the output is sent in a way that TCP likes". What
> does this comment mean, is this related to the TC
coolshal wrote:
> i m new to this list. i m developing web-sites which help on line credit
>transactions for financial institution. so we r using openssl for security. i have to
>study the code , but i have lost up in that. could anyone tell me wats the basic
>structure of openssl code. and how
Isaac Foraker wrote:
>
> Can anyone point me to documentation describing what a password callback
> should look like as set up by this function?
>
> void SSL_CTX_set_default_passwd_cb(SSL_CTX *ctx, pem_password_cb *cb);
>
> I found this callback definition:
>
> int cbPasswd(char *buf, int size
Celine Murphy wrote:
> Can anyone recommend a really good (ie simple) website or book for a
> beginner in openssl?
I've collected links to good web sites and books at
http://www.kegel.com/ssl/
- Dan
__
OpenSSL Project
I'm interested in just how much a singlethreaded nonblocking server
handling N active clients suffers when the N+1th client connects.
(Best to understand one's enemy before one decides to fight.)
According to Rescorla's book, the big CPU hit is in
ssl3_get_client_key_exchange when it calls
R
Alireza Noroozi wrote:
> I downloaded the open-ssl from your site.
> I did its instruction for Win32, and Borland Builder, then a bug was
> reported from Turbo Assembler that the message is coming below:
> "tmp32\rand_win.ASM (791) Illegal instruction for currently selected
> processor(s)"
> I saw
I just got Eric Rescorla's book "SSL and TLS",
and really like it. It's well written, easy to
understand, and even explains not just SSL as it
is, but how it came to be that way.
It's a big improvement over earlier books, IMHO.
Anyone who's been wishing there was a good SSL book,
check it out. T
Bodo Moeller wrote:
> > ... I have the feeling that much of the kludginess of
> > the OpenSSL code is there to handle the fact that input arrives not
> > as whole SSL Record Layer units, but in dribs and drabs, and lots of
> > effort is expended in tracking where you are, and being able to resume
Geoff Thorpe wrote:
> Well the sample size is not immense, but internally hardware usually
> functions in an async manner, and typically the APIs/SDKs are such that
> you can use the stuff in that way. I think you'll find if you delve into
> the vendor_defn/ headers in the engine stuff, and look a
Geoff Thorpe wrote:
> On Tue, 14 Nov 2000, Dan Kegel wrote:
> > I don't think we need nonblocking crypto; it would be enough to be able
> > to shunt the crypto off into another thread. That's what my API proposal
> > was about.
>
> I think that misses th
Bodo Moeller wrote:
> On Mon, Nov 13, 2000 at 07:16:39PM -0800, Dan Kegel wrote:
> > Nonblocking network I/O is tricky with the current API, but doable.
> > I've got working code for that, and there are good examples now.
> > Nonblocking crypto is another matter; it
Richard Levitte - VMS Whacker wrote:
> From: Dan Kegel <[EMAIL PROTECTED]>
>
> dank> BIO's should have been a well-separated layer, not an integral
> dank> part of OpenSSL.
>
> I'm not sure I understand that argument. BIO's *are* separate, in
&g
Dr S N Henson wrote:
> > The revised OpenSSL ASN1 code will eventually have support for I/O based
> > operations in addition to the current memory based operations which need
> > to have the entire structure in memory (tricky if its a 1Gb structure on
> > tape).
> >
> > Doing blocking I/O is fairl
Shridhar Bhat wrote:
> I have written a server which receives connections from
> SSL clients. I accept SSL connections as well as read the
> data from the client in the following function: DoSSLRead.
> Upon the arrival of the client connection, the SSL_read()
> is called 3 times (2 times for hands
"g. labe" wrote:
> i'm trying to compile and install openldap v2.0.6 on my solaris 2.6 machine
> (sparc). openldap requires openssl - i compiled it (v0.9.6) without a problem
> and installed it with `make install` in standard location (`/usr/local/ssl`).
> now, when i run openldap's `configure` i
Amit <[EMAIL PROTECTED]> wrote:
> I want to become a active member of your openSSL
> devloper team can you tell me how to go about this and what skills you require?
I'm just a user of OpenSSL, and a novice at that, but I suspect the only requirement
is that you contribute code that solves a real
open ssl wrote:
>
> I have compiled openSSL on a windows 98 PC and after that have
> tried to run the test ..\ms\test. I keep getting
> out of environment space on one of the tests. Any ideas ?
Yes. This is an FAQ for Windows programmers. The fix is to edit c:\config.sys
and add the line
SH
Matti Aarnio wrote:
>
> On Sat, Oct 28, 2000 at 06:24:32PM -0700, Dan Kegel wrote:
> > I'm writing a server that will often have more than 1024
> > file descriptors open. That means that any code using
> > stdio might fail, since stdio.h can't handle any
Rich Salz wrote:
>
> > IMHO we should ideally have console and file I/O all handled by BIOs in
> > such a way that any platform specific changes only need to be made in
> > one place.
>
> Totally agree.
>
> Wouldn't it be neat if all of openssl (except bio-file) could compile w/o
> stdio.h? :)
Dr S N Henson wrote:
> > > > I'm doing it; right now, I have a single network thread doing all normal
> > > > networking *and* SSL; after I write the load tests that demonstrate
> > > > how woefully inadequate that is :-), I'll split that into two threads:
> > > > one for doing the SSL accept / co
Dan Kegel wrote:
> > > > Then you get what is available.
> > >
> > > Because you're not using a nonblocking socket, the read()
> > > blocks until the number of requested bytes become available.
> > >
> > > You would "get what i
Ben Laurie wrote:
> > > > To avoid blocking, you *must* use nonblocking I/O even if you use select();
> > > > there's no rule saying read() and write() won't block if select()
> > > > says they won't;
> > >
> > > Yes there is!
> >
> > That's debatable. People have been discussing this part of POS
Ben Laurie wrote:
> > > > and doesn't actually
> > > > use nonblocking sockets.
> > >
> > > It doesn't need to! It uses select instead.
> >
> > To avoid blocking, you *must* use nonblocking I/O even if you use select();
> > there's no rule saying read() and write() won't block if select()
> > says
Dr S N Henson wrote:
> Dan Kegel wrote:
> > I'm doing it; right now, I have a single network thread doing all normal
> > networking *and* SSL; after I write the load tests that demonstrate
> > how woefully inadequate that is :-), I'll split that into two threads:
&
Geoff Thorpe wrote:
> > I'm writing a server that will often have more than 1024
> > file descriptors open. That means that any code using
> > stdio might fail, since stdio.h can't handle any
> > fd's higher than 1024 on some systems.
>
> That only gives you a limit *per-process*. :-)
True - bu
I'm writing a server that will often have more than 1024
file descriptors open. That means that any code using
stdio might fail, since stdio.h can't handle any
fd's higher than 1024 on some systems.
I might be able to get by, since I currently don't think
I call any OpenSSL functions that use st
Ben Laurie wrote:
>
> Dan Kegel wrote:
> >
> > I'm adding SSL support to my app, and am finding it
> > tedious, partly because of having to figure out how
> > OpenSSL supports nonblocking sockets.
> >
> > demo/state_machine/state_machine.c is be
I'm adding SSL support to my app, and am finding it
tedious, partly because of having to figure out how
OpenSSL supports nonblocking sockets.
demo/state_machine/state_machine.c is better than nothing,
but it waves its hands a fair bit, and doesn't actually
use nonblocking sockets.
I'd like to se
Dr S N Henson wrote:
> "Reddie, Steven" wrote:
> > We are using BIO_do_handshake() to accept socket connections, which results
> > in a call to BIO_accept(). Calling BIO_accept() on a non-blocking socket
> > with no connections pending results in a fatal error on Win32, but not on
> > other platf
I rely on SSL_peek() to look at the first three bytes of the
decrypted data stream. Unfortunately, if the BIO_read it triggers
doesn't return a full load, it seems to lose its mind, and returns
bytes from the undecrypted datastream. I can demonstrate things working
properly in a test program wh
fordesign <[EMAIL PROTECTED]> is having problems with SSL_CTX_new()
(in ssl_lib.c) under purify. It fails at the line
ssl_create_cipher_list(ret->method,
&ret->cipher_list,&ret->cipher_list_by_id,
SSL_DEFAULT_CIPHER_LIST);
if (ret->cipher_list == NULL
|| sk_SSL_C
Nikhil Sharma wrote:
> I have just started using the SSLeay library
> in my http proxy to handle https. The problem
> I am running into is that SSL_accept returns
> -1. Here is the error-status:
> -1 error:::lib(0) :func(0) :reason(0)
>
> And ssl_get_error() reveals that the error-code
>
Although the learning curve for OpenSSL is steep,
I must say I appreciate not having to write all that code
myself :-)
I'm writing a custom BIO for a multithreaded program on Linux.
It was aborting with SSL_ERROR_SYSCALL but no errno (yech).
I tracked it down by inserting about three hundred call
fordesign wrote:
> OS: SUNOS5.7 GCC
> under 0.9.5a
> without purify , my program runs well, but it cannt construct SSL_CTX after purified.
> this is the log:
> 2000-09-26 11:34:40 #1 INIT: construct SSL_CTX fail, program abort
> 2000-09-26 11:34:40 #1 INIT: SSL: error:140A90A1:SSL routines:SSL_CTX
Ulf Möller wrote:
>
> On Thu, Sep 21, 2000 at 03:09:06PM -0500, Ed Kubaitis wrote:
>
> > > How vulnerable is the current OpenSSL to the Bleichenbacher attack?
> > > Must be old hat by now, but someone brought it up at work.
> > > The source tree does not seem to contain the word 'bleichenbacher'
Ed Kubaitis wrote:
> Dan Kegel wrote:
> > How vulnerable is the current OpenSSL to the Bleichenbacher attack?
> > Must be old hat by now, but someone brought it up at work.
> > The source tree does not seem to contain the word 'bleichenbacher', ...
>
> Typo
(Crypto newbie here.)
How vulnerable is the current OpenSSL to the Bleichenbacher attack?
Must be old hat by now, but someone brought it up at work.
The source tree does not seem to contain the word 'bleichenbacher',
and it's only been mentioned in passing on this list.
TLS ( http://www.ietf.o
Someone just sent me this link:
http://www.columbia.edu/~ariel/ssleay/
It looks like some very helpful, if dated, documentation.
Is this already included with OpenSSL and I just missed it?
Might be nice to at least link to it.
- Dan
_
bc is a standard Unix command.
- Dan
Sascha Wüstemann wrote:
> on a fresh installed Slackware 7.1 I have configured openssl with
> './config --prefix=/usr/local --openssldir=/usr/local/openssl', make
> worked fine without errors, but make test failed for a missing system
> command 'bc' which is
Tom Biggs wrote:
> Anyway, I've been tasked with investigating OpenSSL, with
> an eye towards making it work with yet-to-be-announced
> encryption acceleration hardware.
>
> Has anyone here modified the OpenSSL library to work
> with a hardware accelerator? Do you have any tips or
> suggestions?
Ben Laurie wrote:
>
> All those interested in state machine implementations of SSL will
> probably want to look at the demo I just checked in (to
> demos/state_machine). This is a state machine implementation using
> memory BIOs, sponsored by Nuron (http://www.nuron.com/), a maker of
> hardware e
Gary Feldman wrote:
> It occurs to me that part of the learning curve problem with respect to BIOs
> (and other aspects of OpenSSL) is that they're essentially an
> object-oriented concept implemented in C. Or to put it another way, they're
> a poor-man's polymorphism in C.
Yes, that's exactly r
Is there a clearer example of a nonblocking server
than s_server.c? That source is really quite hard to read.
Reading the double for(;;) loop in main() there is quite
an experience. My head is exploding...
- Dan
__
OpenSSL Proj
Jeffrey Altman wrote:
>
> > > I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
> > > and let the app do all the buffering and I/O.
> >
> > Maybe, but I'm not sure what you mean exactly. Could you describe
> > in terms of an approximate example API?
>
> I think what he would
Geoff Thorpe wrote:
> Anyway, I'm out of here - hope that actually made some sense.
Thanks for the detailed reply, Geoff! It does help.
I've written the loop you described many times for other systems
(including an serial I/O interrupt handler for the IBM PC back in '82)
and there's one in my c
Jeffrey Altman wrote:
> > Jeffrey Altman wrote:
> > > I think what he would like is the ability to do what the Microsoft
> > > SSPI does. Instead of OpenSSL being a layer between the I/O channel
> > > and the app, he would like the app to provide all I/O functions and
> > > have OpenSSL provide r
Bodo Moeller wrote:
> > I'm currently writing a multi-platform webserver using openSSL and I do also
> > experience problems with the fact that the networking code is too tighty
> > integrated with openSSL. ...
> > If openSSL would be more of a library that runs on top af a stream (any
> > stream,
[EMAIL PROTECTED] wrote:
> Yup - I think we can contain this quite easily. I'll grab the new source
> tree asap and start looking over it with you. WHere we need to start is a
> proper design for the datastructures. I like creating a group of function
> calls with a not too long mnemonic... per
[EMAIL PROTECTED] wrote:
> > Whatever we come up with, I'm sure the classic OpenSSL API could
> > be layered on top of it. Perhaps we could consider this effort an
> > experimental refactoring of the OpenSSL codebase to improve its
> > quality and reusability.
>
> I agree with this approach. Th
Ben Laurie wrote:
> I've obviously missed something ... what problem are you trying to
> solve?
Check my original post (I'm copying it below). We're unhappy
with OpenSSL's support for nonblocking I/O on servers; currently,
it either wants you to rewrite your server to let OpenSSL handle
the netw
[EMAIL PROTECTED] wrote:
> I agree with you 100% adn I'm in the same boat. I suggest that if we
> can't get people on board that we just go our own way.
Whatever we come up with, I'm sure the classic OpenSSL API could
be layered on top of it. Perhaps we could consider this effort an
experimen
I'm trying to integrate OpenSSL into a nonblocking
server that already has a firm idea of how it wants
to do its networking. In other words, I want to
use OpenSSL, but *do not* want OpenSSL doing any
networking for me. I also don't want to use any
huge, ungainly abstractions such as BIO pairs.
W
74 matches
Mail list logo
