Bodo Moeller [EMAIL PROTECTED]:
But doesn't -D_REENTRANT or -D_THREAD_SAFE usually also implicitly
assumes that one _links_ against the reentrant libc and this way
doing only half the way could cause problems?
Well, at least for Linux (with glibc 2) and for Solaris I am pretty sure
Ian Pollard [EMAIL PROTECTED]:
Description: Cannot build OpenSSL-0.9.1c under Solaris 2.6 with Sun C
compiler
OpenSSL-0.9.1c
You should use 0.9.2b (with the no-asm option) or even better 0.9.3,
which unfortunately isn't finished yet though. Or get the current
snapshot.
"bn_mul.c", line
On Fri, Apr 23, 1999 at 02:21:12AM +0200, Bodo Moeller wrote:
[...] Now whether /usr/local/include/openssl is a link or a
directory with copies of all the files doesn't really make a
difference, what counts is that the name-space makes sense.
Since there seems to be mostly agreement
While scanning the libary for remaining include filenames without
the openssl/ prefix, I noticed that crypto/cryptall.h doesn't make any
sense at all. Ever since 0.6.6b (possibly earlier) this header file
included a file "meth.h", which I could not find anywhere in neither
that nor the current
An issue that still is open as of yet is what to do with the exported
header files. Currently, /usr/local/ssl/include/foo.h will
#include "bar.h"
which it should't --
#include bar.h
is better because it cannot conflict with application files.
However, I'd prefer moving everything to
On Thu, Apr 22, 1999 at 07:30:15PM +0200, Anonymous wrote:
[...]
Moving everything to /usr/local/ssl/include/openssl doesn't make much sense
though.
- That will leave /usr/local/ssl/include empty except for the subdir.
True, but that shouldn't hurt anyone. It's just another inode.
-
On Tue, Apr 20, 1999 at 06:14:36PM +0100, Dr Stephen Henson wrote:
proposal to include the .err files instead of copying them in.
Personally I'm against this. It'll just be extra baggage to install (and
get working cross platform) and extra dependencies with IMHO minimal
benefits.
Hoewever
Clifford Heath [EMAIL PROTECTED]:
I believe that this is now wrong, and alreay was wrong in 0.6.6b. ...
if you really want to avoid blocks, you must use non-blocking I/O.
Am I right?
I don't think so. We use select() with blocking I/O on UNIX (async
select on Windows), and rely on
Ben Laurie [EMAIL PROTECTED]:
Bodo Moeller:
[...]
The test in ssl_sess.c (function ssl_get_prev_session) is a little
more paranoid than is usually necessary -- if the SSL_CTX-internal
cache is used, usually one wouldn't really have to care about these,
as the SSL_CTX is enough of a context
"Roger Bodén" [EMAIL PROTECTED]:
I've noticed that the session re-use doesn't work if I turn on
client authentication in my SSL server, [...] A full SSL negotiation
is performed each time my client connects. If I turn off client
authentication the session cache works as intended.
You have
On Thu, Apr 15, 1999 at 11:10:34AM -0400, Titchener, Tom wrote:
I have now added bss_file.c to HEADER, because that is what I think
was originally intended ("EXHEADER" = "exported headers", i.e. files
that should be copied into the "include" directory to be visible for
other programs that
On Wed, Apr 14, 1999 at 11:43:56AM -0400, Tom Titchener wrote:
Here are a handful of minor fixes I had to make to feed 0.9.3 through
VC 6.0.
[...]
4) The apps directory needs a copy of bss_file.c, which lives in
crypto/bio. This is the kind of thing you handle with a symlink
on Unix but
Function ssl2_read, formerly known as SSL2_read and (via a #define in
0.6.6b) also as SSL_read, in file ssl/s2_pkt.c contains the following
confusing code and comment:
/* If a 0 byte packet was sent, return 0, otherwise
* we play havoc with people using select
On Sun, Apr 11, 1999 at 01:17:19PM +0100, Ben Laurie wrote:
(remember that HEADER_ENVELOPE_H is always defined here
because of a previous #include, and that the dummy structure
definitions anyway could fail on some systems because they don't
necessary have the alignment needed for
Down below, as discussed, a patch for getting rid of ctx_size.c and
pem.org follows. The Configure script obviously should be cleaned up
if we do this. The new pem.h will differ from the existing pem.org as
follows (remember that HEADER_ENVELOPE_H is always defined here
because of a previous
The shellscript test/testenc must be told somehow which ciphers have
been configured. After a -DNO_IDEA build, it still tries to run
"../apps/openssl idea-ecb" etc., which of course fails. I usually
just ignored this error because I obviously knew that I explicitly did
not include IDEA, so this
On Fri, Apr 09, 1999 at 11:45:47AM +0200, Richard Levitte - VMS Whacker wrote:
What's the cleanest way to solve this? Exile the command
list
Run something like the following during compilation of the test
directory:
$(CC) $(CFLAGS) -E testenc_methods.c | sed -e 'd/^$/' |\
On Fri, Apr 09, 1999 at 07:29:51PM +0100, Ben Laurie wrote:
Isn't the simplest thing to just #ifdef the test code itself, so the
test programs are always there, just don't do anything if there's
nothing to test?
There are two kinds of tests: First, there are ideatest.c and similar
programs.
Dr Stephen Henson [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
That seems very complicated. How about doing this
in the Makefile
test: cipherlist
cipherlist: cipherlist.c
..usual CC rules.
And cipherlist is
main()
{
#ifndef NO_DES
"Titchener, Tom" [EMAIL PROTECTED]:
Ever try connecting to an SSLeay server that uses
SSLv23_server_method() via a telnet session and then closing the
session without sending any data?
When you do that in our server, it crashes trying to use the
handshake_func function in ssl23_read(),
[EMAIL PROTECTED] (Bodo Moeller):
Mikko Hirvonen [EMAIL PROTECTED]:
I have problems with pipes. I try to use s_client as fetchmail
plugin, but something goes wrong. Transmission over ssl-tunnel will
stop.
I think s_client.c is buggy in that in does a select() loop where in
fact
Mikko Hirvonen [EMAIL PROTECTED]:
I have problems with pipes. I try to use s_client as fetchmail plugin, but
something goes wrong. Transmission over ssl-tunnel will stop.
I think s_client.c is buggy in that in does a select() loop where in
fact it the first thing it should do in each
Tom Titchener [EMAIL PROTECTED]:
Attached please find a compressed tar file containing patches and
sources implementing with the OpenSSL libraries:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-07.txt
Here's a summary of the files you get:
[...]
mk1mf.pl.patch
Niels Poppe [EMAIL PROTECTED]:
In packaging openssl, I change #include "foo.h" to #include ssl/foo.h
and then install all ssl include files into /usr/include/ssl.
This way nothing changes for openssl internally, but once installed in
the system location, external programs can include
I thinkt that it is not a good idea to have files openssl.pod and
openssl.txt in the same directory: The names suggest that the latter
is a formatted version of the former, which is not true.
The X509v3 documentation in openssl.txt (which could get a different
filename) should mention that a
apps/sc.c is a slight variation of apps/s_client.c. It exists in
OpenSSL 0.9.1c, but not yet in SSLeay. The only changes to s_client.c
are Windows-specific (mostly #if(n)defs); according to the comments,
it has only been tested under Win95. Maybe someone who uses NT can
look into it and, if it
I wrote:
pathLenConstraint counts just the CA path -- 0 means that a CA may
sign only end entities --, while verify_depth counts all certificates,
IIRC).
I don't really mean all certificates (unless one starts counting at
0), but all steps on the path: Depth 1 means that CAs sign end-entity
.
+ [Bodo Moeller]
I hope no-one circumenvented the API and used those macros directly in
any applications? The comment in ssl.h was wrong, anyway:
--- ssl.h 1999/03/22 12:22:03 1.17
+++ ssl.h 1999/03/31 12:06:29 1.18
@@ -477,10 +477,9 @@
struct ssl_st
On Mon, Mar 29, 1999 at 05:20:36PM +0200, Bodo Moeller wrote:
What I don't understand though is the redifinition of BN_ASM in
openssl-0.9.2b/crypto/bn/Makefile: [...]
The real definition is in openssl-0.9.2b/Makefile.ssl: [...]
What's this redefinition about, and why does the make procedure
[...] I do not have a file called error.doc on my hard drive.
Actually, it's now part of doc/ssleay.txt.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
On Mon, Mar 29, 1999 at 01:12:03PM +, Chad C. Mulligan wrote:
Bodo Moeller:
What exactly do you mean by "strong" primes? BN_generate_prime() uses
the word "strong" for what is more commonly called a "safe" prime,
I mean a "safe" pri
On Sat, Mar 27, 1999 at 04:03:00AM +0100, Bodo Moeller wrote:
"Safe" primes, where q := (p - 1)/2 is prime, imply that there is
one very large (order q) subgroup of (Z/pZ)*. More generally,
we want a large prime q to be some divisor of p - 1. The order of
the generato
"Chad C. Mulligan" [EMAIL PROTECTED]:
Hmmm... I don't know how _efficient_ it is, but in the tests I did
on it, the average time to create a 1024 bit strong prime (and one
_guaranteed_ strong, by construction) was 1014 seconds, as opposed
to 2301 seconds for BN_generate_prime() with "strong"
Please don't forget the enc_read.c bug fix.
From: Michael Rayment [EMAIL PROTECTED]
Subject: [ssl-bugs] Possible bug in crypto/des/enc_read.c
Date: Mon, 15 Feb 1999 00:45:01 -0330
I am using enc_read.c and enc_write.c to easily read and write data into
and from an encrypted file. I am
+ s=BN_new();
if (s == NULL) ...
+ ret=DSA_SIG_new();
if (ret == NULL) ...
+ s = DSA_SIG_new();
if (s == NULL) ...
__
OpenSSL Project http://www.openssl.org
Development
On Wed, Nov 17, 1999 at 12:40:55PM +, Geoff Thorpe wrote:
It seems that
everything works if you make the calls the way the authors had intended
rather than making the calls the way the authors made available.
How can you tell what
601 - 636 of 636 matches
Mail list logo
