Re: [openssl-dev] libcrypto.pc needs to list libpthread as a dependency
Roumen Petrov wrote:
Howard Chu via openssl-dev wrote:
In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on
libpthread but this is not reflected in the pkgconfig file. As a result,
tools like CMake fail to detect libcrypto properly when linking against the
static library. libpthread should be added to the Libs.private line of the
pkgconfig file.
For example:
https://github.com/monero-project/monero/issues/2402#issuecomment-327514216
Problem is that OpenSSL does not add it directly.
Build process does not know libraries added by compiler flags like -pthread.
Does not look like OpenSSL issue.
That sounds like a lame cop-out. Currently the build process already knows
that -ldl goes in ${EX_LIBS}. The Makefile is full of system-dependent
settings already.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] libcrypto.pc needs to list libpthread as a dependency
In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on libpthread but this is not reflected in the pkgconfig file. As a result, tools like CMake fail to detect libcrypto properly when linking against the static library. libpthread should be added to the Libs.private line of the pkgconfig file. For example: https://github.com/monero-project/monero/issues/2402#issuecomment-327514216 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published
Viktor Dukhovni wrote: On Feb 16, 2016, at 11:17 AM, David Woodhouse <dw...@infradead.org> wrote: If a library (or loadable plugin within an application) uses OpenSSL, how should it clean up after itself? I must do nothing. That's what auto-initialization is for. It is wrong for libraries to initialize OpenSSL, because that can't be done safely. So in libraries that use OpenSSL, no OpenSSL initialization, and no cleanup. I like this direction, but is it actually stable? There are programs out there that dynamically load and then unload modules repeatedly thru their life. We see libldap getting loaded and unloaded this way a lot, and that naturally means libssl/libcrypto go along for the ride too. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der()
Stephen Henson via RT wrote: > On Fri Jan 29 19:14:50 2016, h...@symas.com wrote: >> >> Just to be clear - in our use case we already know the length. But if >> the >> function you're proposing is returning only a success/error code, then >> the >> function should probably also provide the length as a return >> parameter, for >> more general users. > > I've added a new function: > > int X509_NAME_get0_der(const unsigned char **pder, size_t *pderlen, > X509_NAME *nm) > > Let me know if that suits your needs. Thanks, yes, works fine. I saw your commit and merged our support for it already. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=6bb6d5e3c6269589f5e64805bd849174d62bd3ea -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der()
Howard Chu via RT wrote: In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER bytes which we then pass thru our own DN validator/formatter. This no longer works with OpenSSL 1.1 and I don't see any provided method to return the DER bytes. I don't want a malloc'd copy, I just want read-only access to the bytes already cached inside the X509_NAME structure. The attached patch would be sufficient to meet this requirement. We are tracking this here as well: http://www.openldap.org/its/index.cgi/Development?id=8353 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der()
Howard Chu via RT wrote: > In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER > bytes which we then pass thru our own DN validator/formatter. This no longer > works with OpenSSL 1.1 and I don't see any provided method to return the DER > bytes. I don't want a malloc'd copy, I just want read-only access to the bytes > already cached inside the X509_NAME structure. > > The attached patch would be sufficient to meet this requirement. We are tracking this here as well: http://www.openldap.org/its/index.cgi/Development?id=8353 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der()
Stephen Henson via RT wrote: > On Fri Jan 29 15:08:47 2016, h...@highlandsun.com wrote: >> Howard Chu via RT wrote: >>> In OpenLDAP we reference X509_NAME->bytes->data directly, we want the >>> DER >>> bytes which we then pass thru our own DN validator/formatter. This no >>> longer >>> works with OpenSSL 1.1 and I don't see any provided method to return >>> the DER >>> bytes. I don't want a malloc'd copy, I just want read-only access to >>> the bytes >>> already cached inside the X509_NAME structure. >>> >>> The attached patch would be sufficient to meet this requirement. >> >> We are tracking this here as well: >> >> http://www.openldap.org/its/index.cgi/Development?id=8353 > > > I'd rather we didn't return a pointer to the internal BUF_MEM as we might want > to change that at some point. > > Would a function like: > > int X509_NAME_der(const X509_NAME *nm, const char **pder); > > be suitable for your needs? Yes, that would be fine. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der()
Stephen Henson via RT wrote: > On Fri Jan 29 17:35:05 2016, steve wrote: >> On Fri Jan 29 15:08:47 2016, h...@highlandsun.com wrote: >>> Howard Chu via RT wrote: >>>> In OpenLDAP we reference X509_NAME->bytes->data directly, we want >>>> the >>>> DER >>>> bytes which we then pass thru our own DN validator/formatter. This >>>> no >>>> longer >>>> works with OpenSSL 1.1 and I don't see any provided method to >>>> return >>>> the DER >>>> bytes. I don't want a malloc'd copy, I just want read-only access >>>> to >>>> the bytes >>>> already cached inside the X509_NAME structure. >>>> >>>> The attached patch would be sufficient to meet this requirement. >>> >>> We are tracking this here as well: >>> >>> http://www.openldap.org/its/index.cgi/Development?id=8353 >> >> >> I'd rather we didn't return a pointer to the internal BUF_MEM as we >> might want >> to change that at some point. >> >> Would a function like: >> >> int X509_NAME_der(const X509_NAME *nm, const char **pder); >> >> be suitable for your needs? >> > > Thinking about it a better name for comply with our naming convention would be > X509_NAME_get0_der. Just to be clear - in our use case we already know the length. But if the function you're proposing is returning only a success/error code, then the function should probably also provide the length as a return parameter, for more general users. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL 1.1 X509_NAME issues
Quanah Gibson-Mount wrote: --On Thursday, January 21, 2016 5:58 PM + Howard Chu <h...@highlandsun.com> wrote: In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER bytes which we then pass thru our own DN validator/formatter. This no longer works with OpenSSL 1.1 and I don't see any provided method to return the DER bytes. I don't want a malloc'd copy, I just want read-only access to the bytes already cached inside the X509_NAME structure. for reference: https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o. c#L448 https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o. c#L475 Any update on this request? I sent a patch to r...@openssl.org a couple hours ago. Hasn't shown up yet. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der()
In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER
bytes which we then pass thru our own DN validator/formatter. This no longer
works with OpenSSL 1.1 and I don't see any provided method to return the DER
bytes. I don't want a malloc'd copy, I just want read-only access to the bytes
already cached inside the X509_NAME structure.
The attached patch would be sufficient to meet this requirement.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
>From 96cb450f9a41feeea3612be9cff2384a4a30ed77 Mon Sep 17 00:00:00 2001
From: Howard Chu <h...@symas.com>
Date: Tue, 26 Jan 2016 19:18:54 +
Subject: [PATCH] Add X509_NAME_der()
---
crypto/x509/x_name.c | 5 +
include/openssl/x509.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/crypto/x509/x_name.c b/crypto/x509/x_name.c
index f151da4..f22266e 100644
--- a/crypto/x509/x_name.c
+++ b/crypto/x509/x_name.c
@@ -568,3 +568,8 @@ int X509_NAME_print(BIO *bp, X509_NAME *name, int obase)
OPENSSL_free(b);
return 0;
}
+
+BUF_MEM *X509_NAME_der(X509_NAME *name)
+{
+ return name->bytes;
+}
diff --git a/include/openssl/x509.h b/include/openssl/x509.h
index 50a5edd..cf4473a 100644
--- a/include/openssl/x509.h
+++ b/include/openssl/x509.h
@@ -818,6 +818,7 @@ int X509_NAME_print_ex_fp(FILE *fp, X509_NAME *nm, int indent,
unsigned long flags);
# endif
+BUF_MEM *X509_NAME_der(X509_NAME *name);
int X509_NAME_print(BIO *bp, X509_NAME *name, int obase);
int X509_NAME_print_ex(BIO *out, X509_NAME *nm, int indent,
unsigned long flags);
--
1.9.1
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] OpenSSL 1.1 X509_NAME issues
In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER bytes which we then pass thru our own DN validator/formatter. This no longer works with OpenSSL 1.1 and I don't see any provided method to return the DER bytes. I don't want a malloc'd copy, I just want read-only access to the bytes already cached inside the X509_NAME structure. for reference: https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o.c#L448 https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o.c#L475 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] OpenSSL 1.1 SSL_CTX issues
In OpenLDAP we've been using CRYPTO_add(>references, 1, CRYPTO_LOCK_SSL_CTX) to manage our own SSL_CTXs but this is not possible with current 1.1. Making the structures opaque is a good move, but please provide methods to manipulate refcounts. Currently ssl_lib.c appears to bump the ctx refcount twice, in SSL_new. Why is that? https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L670 https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L681 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
Viktor Dukhovni wrote: I can contribute a patch, that addresses many of the issues. Things that I'm not immediately planning to address are: - Separate flag for wildcards in CN vs. wildcards in SAN dnsName. (LDAP case in RFC 6125). Just to add context - the LDAP RFCs always specified wildcards in SAN only, not in the CN. But most commercial CAs seem to have made a practice of issuing wildcard certs using * in the CN, not in a dnsName SAN. For a long time we rejected wildcard CN certs in OpenLDAP but finally started accepting them after multiple users' requests. It's a slippery slope, don't expect to get it right. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient
Viktor Dukhovni wrote: On Tue, Apr 01, 2014 at 07:07:10PM -0700, Howard Chu wrote: Viktor Dukhovni wrote: I can contribute a patch, that addresses many of the issues. Things that I'm not immediately planning to address are: - Separate flag for wildcards in CN vs. wildcards in SAN dnsName. (LDAP case in RFC 6125). Just to add context - the LDAP RFCs always specified wildcards in SAN only, not in the CN. But most commercial CAs seem to have made a practice of issuing wildcard certs using * in the CN, not in a dnsName SAN. For a long time we rejected wildcard CN certs in OpenLDAP but finally started accepting them after multiple users' requests. It's a slippery slope, don't expect to get it right. Thanks, good to know. So is there in your view a real need for separate wildcard flags in SAN vs. CN? It never made much sense to me, and if LDAP implementations are now giving in to CA practice, I am inclined to do what makes more sense, more than I am inclined to support an oddity of the LDAP wildcard matching specifications. By all means, do what makes sense. I'm not sure how relevant it is for LDAP, since OpenLDAP's libldap is pretty much the only LDAP client library around now, and we already have our own cert validation function which behaves identically for OpenSSL, MozillaNSS, and GnuTLS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Custom user-defined BIO
Phillip Hellewell wrote: Hi all, How do I implement my own BIO? Do I just create a function that returns a BIO_METHOD* with pointers to my custom functions? Is there any documentation on how to do this? I searched the mailing list and found that this question has been asked before but no one ever responds. The lack of documentation and responses leads me to believe that the BIO interface is not really meant to be used for user-defined I/O. 1999: http://marc.info/?l=ssl-usersm=91639275613495w=2 http://marc.info/?l=ssl-usersm=91639275613495w=2 2005: http://marc.info/?l=openssl-usersm=110624296809686w=2 http://marc.info/?l=openssl-usersm=110624296809686w=2 2008: http://marc.info/?l=openssl-devm=122959672906832w=2 http://marc.info/?l=openssl-devm=122959672906832w=2 Please, at least will someone respond with one of the following: 1. No, don't even try to do it. You're not supposed to. 2. Yes, you can do it but no one is going to help you. Just look at some of the files in crypto/bio/ and see if you can figure it out. Some things are probably too easy to justify the time it takes to respond. In this case, define a BIO_METHOD struct with your handlers and just use it. One example is in OpenLDAP's libldap/tls_o.c. http://www.openldap.org/devel/cvsweb.cgi/~checkout~/libraries/libldap/tls_o.c?rev=1.16 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Custom user-defined BIO
Phillip Hellewell wrote:
Thanks for the detailed response and the tips. I think I am going to give it
a go and cross my fingers.
The scenario at my company is we have abstract file I/O stream classes called
file_read_random and another that derives from that called file_read_write.
These are C++ classes with the following pure virtual functions: read(),
eof(), seek(), tell(), size(), clone(), and for file_read_write there is also
write(), set_eof(), and reopen_read_only(). We use our I/O classes everywhere
throughout our code, so our functions can handle any kind of stream (could be
a file stream, in-memory stream, socket stream, substream, etc.).
Because all of our code expects and operates on file_read_random et al, in
order to use them with OpenSSL we are currently stuck with the less desirable
method of copying the stream to a temp file on disk and then using that with
BIO_new_fp(). This isn't a big problem when working with PEM and PFX certs
which are relatively small, but now I am writing some code to parse PKCS7
files with enveloped data (S/MIME encrypted emails), so the stream could be
fairly large and I don't want to have to copy it to a temp file.
So the goal is to implement a BIO interface that can wrap a file_read_random
or file_read_write object. I don't think it will be too tough, but after
reading your email I'm sure there will be a couple tricky parts. Thanks for
the hint about using the bio-ptr. I'm pretty sure that is where I will store
a pointer to my stream, but I hope OpenSSL doesn't go mucking with it...
It won't, the ptr is reserved for the BIO implementation's use.
Phillip
On Mon, Apr 12, 2010 at 12:14 PM, Ray Satiro raysat...@yahoo.com
mailto:raysat...@yahoo.com wrote:
Yes you can implement your own BIO. I've done it but I don't recommend it.
I had started writing something similar to osslsigncode but that could
verify Microsoft Authenticode. When hashing the file certain fields must
be excluded. PKCS7_verify() will not take a hash for comparison, only the
content to be hashed, so I couldn't use my own hash function and skip the
fields to be excluded. PKCS7_verify() accepts a BIO for detached content
so instead what I did is a custom BIO that reads in the data but will skip
any excluded field. So when OpenSSL goes to hash the file it calls my
custom BIO's read which skips the excluded fields.
There are a few things you should remember such that BIOs are an
abstraction layer and can have more than one instance so stay away from
static variables (think cpp classes). Instead what I did was use bio-ptr
(pointer) to an internal structure that contains my variables
struct class_variables
{
int fd;
uint64_t filesize;
}
etc
then on construct (ie create function) do something like
assert( ( bio-ptr = malloc( sizeof( struct class_variables ) ) ) );
then on destruct (ie destroy function) free it
so then in your BIO read/whatever function you can do something like this
struct class_variables *variables = (struct class_variables *)bio-ptr;
then variables-whatever
In the case of bytes read BIOs actually have a specific member that
openssl's functions can use internally:
unsigned long num_read; (i.e. bio-num_read)
but the problem with that might be that it's only 32bit. with what i was
doing it was ok to ignore this issue
If that's not enough for you you'll have to watch out for things like
where OpenSSL internal functions copy the pointer to bio data but not the
struct. There's an example of this in PKCS7_verify() where if you pass a
memory BIO it creates a secondary memory BIO and then copies over only the
memory pointer and len from the first BIO, and nothing else, and uses that
secondary BIO for some work. The problem being say you have a callback on
the first BIO to monitor for a read well forget it ever being called.
Probably other stuff I'm not thinking of, but yes it's possible. Can you
share with us what you are trying to do?
--- On *Mon, 4/12/10, Phillip Hellewell /ssh...@gmail.com
mailto:ssh...@gmail.com/* wrote:
From: Phillip Hellewell ssh...@gmail.com mailto:ssh...@gmail.com
Subject: Re: Custom user-defined BIO
To: Howard Chu h...@highlandsun.com mailto:h...@highlandsun.com
Cc: openssl-dev@openssl.org mailto:openssl-dev@openssl.org
Date: Monday, April 12, 2010, 12:27 PM
Thanks for the example. Yeah, my best idea so far was to look at
existing examples, such as bss_mem.c. One question I still have is
which of the BIO_CTRL_* commands does my ctrl function need to
handle? bss_mem.c handles about a dozen of them, but the example you
gave me only handles BIO_CTRL_FLUSH, so is that the only one I'm
required to handle?
Phillip
On Mon, Apr 12, 2010 at 10:15 AM, Howard Chu h...@highlandsun.com
Re: libcrypto safe for library use?
. There is no conflict here please stop implying there is one. What I could do is say that when delivered as part of OpenSolaris OpenSSL assumes the OS's threading model. If an application wants to change that they the application should set its own callbacks. If that's what you want, it's trivial to implement. Simply set callbacks that are safe for the OS' threading model before you call any OpenSSL functions. This is exactly where the issue lies. We know we need to do this (please stop repeating back to us that this is what we need to do). The issue is we can not do this in a thread-safe manner since: * The dynamic linker provides no arbitration (this is who I really blame) * OpenSSL the library provides no arbitration (due to it having a single thread / thread unaware use case). Just to be totally clear. All I'd like to see is a compile-time option (it can be disabled by default) to set a default set of locking callbacks native to the OS it's compiling on. I'm not suggesting that the ability to set locking callbacks be removed. The real resistance to this Mark, is the fact you are now forcing a dependency on libpthread for libcrypto which didn't exist before. Yes I know the single threaded users (thread unaware users) can recompile a special version for their own use but this still poses a problem relating to the DSO name of the library and that fact you are impacting their support issues in the future (for your gain). Maybe what would be better is a libcrypto_r and a libssl_r de-facto standard where multi-threaded support is a requirement and override-able default implementation was already setup to go ? This does not mean we should not fix the real issue, it is just a naming work around until that point in time. This is more a packaging issue than a OpenSSL developer issue. It can do this but only by potentially introducing a race. What is the race exactly? If they're already set, setting them again to precisely the same callbacks is harmless. Just because you have the same threading model doesn't mean you are using the same threading primitive symbols. Managing to publish and agree across many projects the exist symbols and use of OpenSSL is a problem that is completely avoided by better engineering. Trying to push out the solution to a social issue will not guarantee a solution. And if the problem is an application setting them to different callbacks, OpenSSL can't help you -- if an application changes the callbacks from the default to unsafe callbacks, you're still hosed. This appears to be the point where we disagree. Many including mysely are claiming that OpenSSL (or rather I am claiming the dynamic linker) _SHOULD_ be helping us. You are correct in that currently OpenSSL can't help us, but this is why we have a discussion here to resolve that. Existing code that uses OpenSSL will still change those callbacks from the defaults. New applications that don't use OpenSSL at all won't be affected by the change. New libraries could just as easily be coded to always set known safe callbacks. There is only a race if some application either reverts to no callbacks or sets unsafe callbacks. Both of those operations will still be fatal with the suggested change. Setting the callback(s) is unsafe. Since another thread might be using them. Do you not get that ? There is no locking around the setting of them so therefore they are thread-unsafe, the method to set locking is not re-entrant. I harp back to my request for re-entrant thread-safe OpenSSL APIs for setting up the threading callbacks. Of course if the compiler generates code that does a single instruction store (of the native platform bit-width) of the same value over and over, no other thread will ever observe any change in that memory location. The point of the matter is there is no guarantee's provided by the compiler over how it goes about doing that so in order to get an engineering guarantee as required to be thread-safe a mutex would provide assurance. This ignores other issues that are implementation details to outside users of OpenSSL what else is going on inside those OpenSSL API calls that isn't expected to be called from other threads at the same time. The API could work like a hybrid sigaction() allowing get-and-test-and-set in one atomic operation. This will require libpthread runtime linkage in libcrypto. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project
Re: libcrypto safe for library use?
Patrick Patterson wrote: Peter: On 29/03/10 1:15 AM, Peter Waltenberg wrote: Sure - it works if you have a simple application, main - OpenSSL even main -lib doing SSL - OpenSSL still works. What's giving us grief (and I suspect the person who first raised this grief) is: main - lib that needs SSL to do client server comms - OpenSSL - Another lib that does client server comms. -OpenSSL - Another lib that does crypto-OpenSSL All the libraries of the big fat composite application expect to be able to access OpenSSL's function, all were created independently - the top level app doesn't do SSL or crypto. at all - it just uses libraries that need to do SSL or crypto to function. This is a rather specious argument - if an application uses SSL at the lower layers, there has to be some method for that application to at least tell OpenSSL which CA Certificates to use - and yes, it COULD have a wrapper/higher level lib that sets up those locations (like I think OpenLDAP can), but I would consider that a HORRIBLE design flaw of that higher library to not expose SOME method to set the trust store (and revocation information, etc.) globally for the application - otherwise, in the situation that you mention, the poor admin COULD end up with an application where it is almost impossible to troubleshoot why certain connections are failing i.e.: Why do my LDAPS connections work, but my HTTPS don't? (assuming that LDAP is provided by one lib, and HTTP by another). So I would argue that it is the higher level libs problem to: 1: Set threading correctly and consistently on all of it's SUB library dependencies with the model the higher level app tells it to. 2: Expose enough controls that allow for a higher level app to set keys, cert stores, and revocation information locations. If those libraries DON'T do both of the above (and OpenSSL can certainly accommodate both today), then the bugs/feature requests to enable both of these functionalities should be filed there. I'm not one of the core devels, but this is just my 0.02 worth. Since we're using OpenLDAP as an example, I'll note - libldap_r's original raison'd'etre was to provide threading in slapd. It was never intended for use by 3rd party code; there is no IETF specification for thread support in the LDAP C API and we've never advertised or documented libldap_r as anything other than an OpenLDAP-specific (i.e., non-standard) library. So yes, in this case, libldap_r was written with certain assumptions (that the threading model is known, that it won't be unloaded while running, etc...) and it's only known to behave correctly within those assumptions. To your point about providing APIs to set the trust store globally for the application: in a word, No. libldap provides APIs to set up all the required trust settings, for a particular SSL_CONTEXT. It initializes a single context for itself, and typically this single context was used implicitly by any application that used libldap (including slapd). Nowadays slapd uses one context for its main listener, and can use a separate context for each of several other cases - proxy sessions, replication tasks, etc. The fact is that slapd is often used as an LDAP gateway, between unsafe external networks and brain-damaged internal LDAP servers that aren't robust enough to face a real network on their own. In a situation where it must act as a server on one side and as a client on the other side, you very often need separate and distinct trusts / policies in each role. So regarding your comment about ldaps sessions working, but https sessions not - that may seem like a hassle, but it's as it should be. Each protocol and each usage of the protocol has to be able to operate in its own distinct context. They must be able to have their security policies configured separately. The fact that OpenSSL supports this in its most common usage is one of its real strengths. (It is still pretty much impossible to handle this type of requirement using e.g. Mozilla NSS.) * most basic example: when using certificate-based authentication, typically a server only needs to trust a single CA - the one that issued its own cert and all of the users' certs. On the flip side, clients tend to need to be able to talk to multiple servers, in multiple authentication realms. As such they tend to need to be configured with many trusted CAs. When you have a single process that can take on both server and client roles simulataneously, OpenSSL handles the situation easily. Other SSL libraries ... not so much... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List
Re: UTF8 in certificate DN via OpenSSL's x.509 API
Thor Lancelot Simon wrote:
Can I assume that any data returned when I access the DN of a peer's
certificate using OpenSSL are ASCII or UTF8? If not, how do I tell
the difference?
I think I understand that DNs not encoded as UTF8String should not
have high-bit characters in them -- so if I do this:
X509_NAME_oneline(X509_get_subject_name(peer), buf, BUFSIZ), suffix)
I should be able to tell any application using the data that the
character set for the data is UTF8, or, if I don't find any Unicode
sequences in it, ASCII. Is that right? I don't see a way to find
out what ASN.1 type X509_get_subject_name actually fetched the data
from...
X509_NAME_oneline is too coarse for getting this info; if you actually need to
know then you should use the other APIs:
X509_NAME *name;
X509_NAME_ENTRY *ne;
ASN1_OBJECT *obj;
ASN1_STRING *str;
ne = X509_NAME_get_entry( name, i );
obj = X509_NAME_ENTRY_get_object( ne );
str = X509_NAME_ENTRY_get_data( ne );
switch (str-type) {
case V_ASN1_UNIVERSALSTRING:
/* This uses 32-bit ISO 10646-1 */
csize = 4; goto to_utf8;
case V_ASN1_BMPSTRING:
/* This uses 16-bit ISO 10646-1 */
csize = 2; goto to_utf8;
case V_ASN1_T61STRING:
/* This uses 8-bit, assume ISO 8859-1 */
csize = 1;
to_utf8:rc = ldap_ucs_to_utf8s( Val, csize, newAVA-la_value );
newAVA-la_flags |= LDAP_AVA_FREE_VALUE;
if (rc != LDAP_SUCCESS) goto nomem;
newAVA-la_flags = LDAP_AVA_NONPRINTABLE;
break;
case V_ASN1_UTF8STRING:
newAVA-la_flags = LDAP_AVA_NONPRINTABLE;
/* This is already in UTF-8 encoding */
case V_ASN1_IA5STRING:
case V_ASN1_PRINTABLESTRING:
/* These are always 7-bit strings */
newAVA-la_value = Val;
default:
}
You can see the full working example of this code in this older code from
OpenLDAP 2.3:
http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/getdn.c.diff?r1=1.136r2=1.137hideattic=1sortbydate=0f=h
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: UTF8 in certificate DN via OpenSSL's x.509 API
Howard Chu wrote: Thor Lancelot Simon wrote: Can I assume that any data returned when I access the DN of a peer's certificate using OpenSSL are ASCII or UTF8? If not, how do I tell the difference? I think I understand that DNs not encoded as UTF8String should not have high-bit characters in them -- so if I do this: X509_NAME_oneline(X509_get_subject_name(peer), buf, BUFSIZ), suffix) I should be able to tell any application using the data that the character set for the data is UTF8, or, if I don't find any Unicode sequences in it, ASCII. Is that right? I don't see a way to find out what ASN.1 type X509_get_subject_name actually fetched the data from... Keep in mind the definition of a DN: /* A DN is a SEQUENCE of RDNs. An RDN is a SET of AVAs. * An AVA is a SEQUENCE of attr and value. */ Each component of the DN can use a different encoding. It's important not to fall into the trap that so many people do, and think of a DN as an intrinsic property of an object. It is simply a pathname, like a filesystem pathname. Only the most-inferior RDN actually belongs to the object, just like the actual filename of a file (i.e., its relative path, not the absolute path). Nor is it a single contiguous data item, it is a complex sequence of independent items that must be treated individually. Within a DN and AVA, order is significant. Within an RDN, order is *not* significant; this fact has major implications on how you compare DNs to each other... X509_NAME_oneline is too coarse for getting this info; if you actually need to know then you should use the other APIs: You can see the full working example of this code in this older code from OpenLDAP 2.3: http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/getdn.c.diff?r1=1.136r2=1.137hideattic=1sortbydate=0f=h As a footnote, we've been using the above code with no trouble for several years. I deleted it when we added GnuTLS support, and replaced it with a generic function that only uses libldap/liblber rather than having to maintain multiple versions of this function for each TLS library. You can see the generic function at the bottom of tls2.c here: http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/?hideattic=1sortbydate=0 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Determining if client requests ssl handshake
David Schwartz wrote: I've managed to do this without problems for SMTP, POP, HTTP, and a few custom text-based protocols. Note that the protocol must be such that the client sends data first. If the server must send data first, then there is no way for the server to know what to send. Given that SMTP and POP clients wait for a 220 greeting from the server first, this seems disqualify them from this approach. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: s_client -starttls feature request (will pay)
John Carter wrote: Howard, I appreciate that currently the s_client code is plain-text, this would have to change to support ASN.1. As you indicate working ldap once starttls done is hard/insane, but as with all protocols that's the user's problem. Actually we are primarily interested in seeing the certificate, rather than doing anything useful with the connection. try ldapsearch -ZZ -d7 ... I'll see if anyone's interested. John. 2009/6/3 Howard Chuh...@highlandsun.com: John Carter wrote: Hi, Currently the s_client command supports starttls for smtp, ftp etc. We're wanting to do the same for ldap, something like: openssl s_client -connect 1.2.3.4:389 -starttls ldap We're willing to pay (around 200 USD) to have this feature added. Anyone interested? Just what do you expect s_client to be able to do once it's gotten this far? The s_client code only speaks plaintext; LDAP is ASN.1. You're not going to be able to type anything intelligible into s_client once it's done. And aside from that, the OpenLDAP libraries and tools already support StartTLS... -- -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: s_client -starttls feature request (will pay)
John Carter wrote: Thanks Howard, but the problem we found with that was that the cert is dumped in what looks like DER format mixed in with lots of other binary data. However we also go nothing beyond doing -d 3. On the offchance your version of ldap is newer and dumps the certs nicely, what version of ldap have you got? Nope, that's what all versions of OpenLDAP do. It also prints the cert subject DNs, that's been enough for most debugging purposes: 0730: 3a 54 c2 b5 f4 b0 37 29 d0 12 38 ae f0 0c cc 16 :T7)..8. 0740: ba 9d 72 59 be c7 f7 81 39 70 55 e9 37 08 ..rY9pU.7. TLS certificate verification: depth: 1, err: 0, subject: /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas Keymaster/emailaddress=keymas...@symas.com, issuer: /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas Keymaster/emailaddress=keymas...@symas.com TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=California/L=Los Angeles/O=Symas Corp./OU=RD/CN=violino.symas.net, issuer: /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas Keymaster/emailaddress=keymas...@symas.com TLS trace: SSL_connect:SSLv3 read server certificate A tls_read: want=5, got=5 : 16 03 01 00 9f You haven't really explained enough of what you actually want to do yet, to give anyone a clear idea of what you're really asking for. Thanks again, John. 2009/6/4 Howard Chuh...@highlandsun.com: John Carter wrote: Howard, I appreciate that currently the s_client code is plain-text, this would have to change to support ASN.1. As you indicate working ldap once starttls done is hard/insane, but as with all protocols that's the user's problem. Actually we are primarily interested in seeing the certificate, rather than doing anything useful with the connection. try ldapsearch -ZZ -d7 ... I'll see if anyone's interested. John. 2009/6/3 Howard Chuh...@highlandsun.com: John Carter wrote: Hi, Currently the s_client command supports starttls for smtp, ftp etc. We're wanting to do the same for ldap, something like: openssl s_client -connect 1.2.3.4:389 -starttls ldap We're willing to pay (around 200 USD) to have this feature added. Anyone interested? Just what do you expect s_client to be able to do once it's gotten this far? The s_client code only speaks plaintext; LDAP is ASN.1. You're not going to be able to type anything intelligible into s_client once it's done. And aside from that, the OpenLDAP libraries and tools already support StartTLS... -- -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: s_client -starttls feature request (will pay)
John Carter wrote: Hi, Currently the s_client command supports starttls for smtp, ftp etc. We're wanting to do the same for ldap, something like: openssl s_client -connect 1.2.3.4:389 -starttls ldap We're willing to pay (around 200 USD) to have this feature added. Anyone interested? Just what do you expect s_client to be able to do once it's gotten this far? The s_client code only speaks plaintext; LDAP is ASN.1. You're not going to be able to type anything intelligible into s_client once it's done. And aside from that, the OpenLDAP libraries and tools already support StartTLS... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: x509 parsing
Ger Hobbelt wrote: Depends on what you consider 'parse': check out the sample source in apps/x509.c and apps/asn1parse.c, among others. Also check out the X509_get_() functions documentation (and for actually parsing a cert, there's PEM_read_bio_X509_AUX(), for example). For a completely different approach, you might examine certificateValidate() in the OpenLDAP source code. http://www.openldap.org/devel/cvsweb.cgi/~checkout~/servers/slapd/schema_init.c It uses the OpenLDAP liblber to parse an X.509 certificate. Since we now support GnuTLS and MozillaNSS in addition to OpenSSL, I decided it was better to use our own ASN.1 library instead of the OpenSSL-specific functions we used to use. Our code does pretty minimal actual validation checks, but it shows you how to get at the individual fields if you want to inspect them yourself. As Ger implied, parse can mean a lot of different things. On Wed, Mar 18, 2009 at 4:22 PM, Vinod Chaudhary vinod.chaudh...@einfochips.com wrote: Hi, I want to parse the x509 certficate in my application using the openssl API not the command line tool. Can anybody help me ? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: multivalue RDNs don't display correctly in Requests
Dr. Stephen Henson wrote: http://www.openssl.org/support/faq.html#USER13 Doh. Thanks, works fine. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
multivalue RDNs don't display correctly in Requests
Tested with 0.9.6g thru 0.9.8h:
mandolin:/home/software/openssl-0.9.8h/apps ./openssl req -new -newkey
rsa:1024 -out foo.req -nodes -multivalue-rdn -subj /C=US/ST=CA/L=Los
Angeles/CN=foo+SN=bar
Generating a 1024 bit RSA private key
...++
++
writing new private key to 'privkey.pem'
-
mandolin:/home/software/openssl-0.9.8h/apps ./openssl req -in foo.req -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=US, ST=CA, L=Los Angeles, CN=foo, SN=bar
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
The Subject: display should show CN=foo+SN=bar since both AVAs are part of
the same RDN.
I thought the request itself was being generated incorrectly, but examining
the request in DER form showed that it's fine:
reqdec foo.der
dn: cn=foo+sn=bar,l=Los Angeles,st=CA,c=US
reqdec.c
#include stdio.h
#include ldap.h
char buf[4096];
/* Print the DN of a certificate request */
main(int argc, char *argv[])
{
struct berval bv, derdn, dn;
BerElement *ber;
ber_tag_t tag;
ber_len_t len;
ber_int_t val;
bv.bv_val = buf;
bv.bv_len = fread(buf, 1, sizeof(buf), stdin);
ber = ber_init( bv );
tag = ber_skip_tag( ber, len );/* Sequence */
if ( tag != LBER_SEQUENCE ) return LDAP_INVALID_SYNTAX;
tag = ber_skip_tag( ber, len );/* Sequence */
if ( tag != LBER_SEQUENCE ) return LDAP_INVALID_SYNTAX;
tag = ber_peek_tag( ber, len );/* certReqId */
if ( tag != LBER_INTEGER ) return LDAP_INVALID_SYNTAX;
tag = ber_get_int( ber, val );
tag = ber_peek_tag( ber, len );/* DN: Sequence */
if ( tag != LBER_SEQUENCE ) return LDAP_INVALID_SYNTAX;
derdn.bv_val = bv.bv_val + ber_ptrlen( ber );
derdn.bv_len = len + 2;
ldap_X509dn2bv( derdn, dn, NULL, 0 );
printf(dn: %s\n, dn.bv_val );
}
(The above tested with OpenLDAP 2.4 libraries...)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1621] [PATCH] - OS390-Unix (EBCDIC) 0.9.7m
It's a bit disappointing, considering I first wrote those patches back in 2002. It would be nice if someone could comment on what's preventing them from getting incorporated. JBYTuna wrote: Richard, Oh my. So, these patches have not been incorporated? Will they ever get incorporated? We did not know these patches existed. We've been chasing this problem for a couple of years now. Because we've never received response to postings with regard to this problem, we felt we were on our own. We WERE using 0.9.7d, when the problem arose. I've submitted two patches, same patch, but for 97m and 98e. (of course, the patches I've submitted only solve OUR problem, and probably don't address the issue to the extent the patches that have already been created) As the existing patches do not fit directly into 97d and 98e (for 64 bit), I'm not sure how to proceed. Because of several platforms involved, in addition to z/OS (OS390-Unix), we need to use these releases of OpenSSL for our new release. Any advice you might offer would be greatly appreciated. Thanks, John B. Young --- Richard Koenning [EMAIL PROTECTED] wrote: JBYTuna via RT wrote: When an OpenSSL server built on z/OS is using client verification, the following error is incurred: 0x140890b2 - error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned From tracing, we found the correct certificate was being returned. We found the code in crypto/x509/x509_vfy.c will not work in an EBCDIC environment, as the data is in ASCII. The solution is to translate the ASCII to EBCDIC, prior to the validation process. John B. Young Here's the patch, in diff -u form: The patch is already contained in #843: EBCDIC patches for 0.9.7c (http://rt.openssl.org/Ticket/Display.html?id=843user=guestpass=guest), which has been updated to 0.9.7j by Jeremy Grieshop. That patch contains also a second ASCII to EBCDIC conversion after the X509_time_adj in the region of line 960. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question about EBCDIC
Michael Saladin wrote: Additional info: I saw that there is a compiler directive CHARSET_EBCDIC, but this directive is not used at all locations where something is read from a certificate. Is it true that all entries in a certificate are in ASCII? Unicode, more likely. If yes, one just had to add a couple of #ifdef CHARSET_EBCDIC to the code, I suppose one candidate location would be the method X509_cmp_time in ./crypto/x509/x509_vfy.c which in my case returns the error X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD when I receive the certificate on the mainframe (originating from a Linux box). Sounds right. Regards Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Saladin Sent: Donnerstag, 26. Juli 2007 16:14 To: openssl-dev@openssl.org Subject: Question about EBCDIC Hi all, I compiled openssl on a mainframe (mainframe emulation using Hercules (MVS), in the USS (Unix System Services) subsystem), there IBM uses an EBCDIC charset. I receive a Bad time value when I want to check the peer certificate (the peer certificate coming from a LINUX machine). I think that the code in ./crypto/asn1/t_x509.c, in the method ASN1_UTCTIME_print does not work with charsets where '0' and '9' have other values as their ASCII values? E.g. the following code from the method looks like this: for (i=0; i10; i++) if ((v[i] '9') || (v[i] '0')) goto err; which is translated on a machine with ISO-charset to this: for (i=0; i10; i++) if ((v[i] 0x39) || (v[i] 0x30)) goto err; but on a machine using EBCDIC (IBM-1047) charset, it is translated to this: for (i=0; i10; i++) if ((v[i] 0xf9) || (v[i] 0xf0)) goto err; Shouldn't you use the numbers instead of the contants '0' and '9'? I'm just now compiling the code using the values 0x39 and 0x30 ... and it works insofar as the output is now correct, but I still get the error: 26.07.2007 16:13:30,139 [t3.comm.OpenSSLHelper] [ERROR] err: 13(format error in certificate's notBefore field) Therefore, I assume that the constants '0' and '9' are used in other places as well? Any help would be appreciated. Michael __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1346] Re: SSL_accept concurrency in 0.9.7j and 0.9.8b
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 unfortunately was never replied to. Surrounding the SSL_accept call with its own mutex seems to resolve the problem. Is that supposed to be necessary? Given the lack of response here, we're tracking this now as http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4583 The same problem occurs with 0.9.8b. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_accept concurrency in 0.9.7j
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 unfortunately was never replied to. Surrounding the SSL_accept call with its own mutex seems to resolve the problem. Is that supposed to be necessary? Given the lack of response here, we're tracking this now as http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4583 The same problem occurs with 0.9.8b. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
SSL_accept concurrency in 0.9.7j
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 unfortunately was never replied to. Surrounding the SSL_accept call with its own mutex seems to resolve the problem. Is that supposed to be necessary? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1292] SSL_add_dir_cert_subjects_to_stack does not check for read access of file, breaking TLS enabled LDAP clients
[EMAIL PROTECTED] via RT wrote: Hi, initial report at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185080 Imho it's more a OpenSSL than a OpenLDAP client problem. The use of TLS_CACERTDIR / TLSCACertificatePath is discouraged in all of the OpenLDAP documentation. See slapd.conf(5), ldap.conf(5) man pages, and the OpenLDAP Admin Guide section 12.2: http://www.openldap.org/doc/admin23/tls.html Regards, Peter Description of problem: During tracking down, why a LDAP enabled postfix cannot lookup via TLS enabled LDAP client I found that openssl function SSL_add_dir_cert_subjects_to_stack is very optimistic relating to the files found in a specified directory. Version-Release number of selected component (if applicable): openssl-0.9.7a-43.4 also openssl-0.9.7.i (latest 0.9.7 release) also openssl-0.9.8.a (latest 0.9.8 release) in conjunction with openldap-2.2.13-4 also openldap-2.2.30 (latest 2.2 release) also openldap-2.3.20 (latest 2.3 release) How reproducible: Always Steps to Reproduce: 1. Create a directory for local PKI storage, e.g. /etc/pki 2. Store local CA, local server certificates and local keys into this directory 3. Set proper permissions to keys, e.g. chmod o-rwx *.key.pem # ll /etc/pki/ total 120 lrwxrwxrwx 1 root root 23 Sep 14 15:42 592fcc04.0 - ca.crt -r--r--r-- 1 root root 1834 Sep 14 15:39 ca.crt -r--r--r-- 1 root root 2529 Sep 14 15:39 AE-CA-Class4-2005-A.crt -r 1 root root 5875 Sep 14 15:45 ca+cert+key.pem -r--r--r-- 1 root root 4196 Sep 14 16:07 ca+cert.pem -r--r--r-- 1 root root 2362 Sep 14 15:37 cert.crt -r--r- 1 root root 4041 Sep 14 15:50 cert+key.pem -r--r- 1 root ldap 1679 Sep 14 15:37 key.pem (note: group=ldap for LDAP server, which reads key file for server TLS after changing the user to ldap) 4. Configure /etc/openldap/slapd.conf for TLS like TLSCACertificateFile/etc/pki/ca.crt TLSCACertificatePath/etc/pki TLSCertificateFile /etc/pki/crt.crt TLSCertificateKeyFile /etc/pki/key.pem 5. Configure /etc/openldap/ldap.conf related URI ldaps://ldapserver/ #URIldap://ldapserver/ BASE dc=example,dc=com TLS_CACERTDIR /etc/pki# - important! -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Attribute order in name comparison
I guess it's worth pointing out that DN's in X.500 represent a pathname from the root of a tree down to a leaf. I.e., conceptually there is a top-down order just like in a hierarchical filesystem. Unfortunately the X.500 standards never specified an order for displaying the components in text lines. Most X.500 tools followed the filesystem convention, using slashes as delimiters and listing the root first, descending left to right. (e.g., /root/middle/leaf - /c=us/o=my company/cn=some name) A lot of confusion has arisen more recently because the LDAP designers chose to ignore the established convention and specified their string format to list DNs right to left, with the root on the right. (leaf,middle,root - cn=some name,o=my company,c=us) The LDAP designers made a lot of stupid decisions Robert Eiglmaier wrote: Thanks everybody for the replies. I could convince the producer of the PKCS#7 to leave the attribute-order unchanged. So I don't need to modify X509_NAME_cmp(). Robert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Sylvester Sent: Montag, 23. Januar 2006 17:06 To: openssl-dev@openssl.org Subject: Re: Attribute order in name comparison Some openssl does not necessarily display DNs in the same textual order as other tools or as other tools like it as input. try openssl x509 -in yourcert -text -noout -nameopt RFC2253 for example and another without the -nameopt parameter It has happened several times that people create certificates that have the order of the attributes reversed. The only remedy was to remake the PKI since we live with the historical accident of mixing a hierarchy together with typed attributes in x.500, specifying the order means that one attribute is a subordinate of the preceding one. I don't think that common name is a very good candidate for a top level attribute unless for CN=the universal authority or else Or; C=DE/O=Org/CN=Alice and the other way around is not a clear description of the data. what does openssl X509 show? Peter Lev Walkin wrote: Robert Eiglmaier wrote: Hi, I have troubles verifying a PKCS#7 signedMessage because the order of the DN attributes in the signerInfo is different from the order in the certificate. i. e. The cert contains: C=DE/O=Org/CN=Alice The signer info has: CN=Alice/O=Org/C=DE I found that the function int X509_NAME_cmp(const X509_NAME *a, const X509_NAME *b) will only find the names matching if the attribute order is identical. It wouldn't be a big deal to make X509_NAME_cmp() more tolerant, but since appearantly nobody has had such a problem yet I'd like to know if there is a specification somewhere that says something like Thou shalt not turn around the order of thy name attributes. PKIX1 profile for X.509 certificates, as well as X.680 for ASN.1 SEQUENCE. All I found was a statement, that SEQUENCE OF is ordered. (distinguishedName is a SEQUENCE OF nameAttribute) But when I look at an example Certificate I can't see by what it is being ordered here: SEQUENCE ^^ this is a SEQUENCE OF, not SEQUENCE SET SEQUENCE OBJECT :countryName 2.5.4.6 PRINTABLESTRING :DE SET SEQUENCE OBJECT :organizationName 2.5.4.10 PRINTABLESTRING :Company SET SEQUENCE OBJECT :commonName 2.5.4.3 PRINTABLESTRING :Demo CA Can anyone bring some light into the darkness? They are ordered sequence of unordered SET's of each element. The order inside SET OF is not important, but there is exactly one element in each SET OF. However, the order inside SEQUENCE OF is important. And the order is the order of display, i.e. DE/Company/Demo CA. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Fix build for AmigaOS 4
Johan Gill wrote: I'll change a few bits in this patch (make sure to open the console, not stdin) and make a small adjustment to make source changes count for m68k-amigaos as well (the clib I use is available for those OS versions too, it seems) so there's no rush. Is anyone still using m68k here? I wrote a M68K asm implementation of BigNum several years ago for my Atari TT (68030), made a 4:1 speed increase there. Haven't touched it in ages. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Options of building openssl for Win32 using gcc
Andy Polyakov wrote: I've investigated various ways of building OpenSSL (release 0.9.8) for Win32 with gcc. There are at least three ways to do this 1. Using mingw32 compiler (from http://www.mingw.org) 2. Using cygwin compiler with -mno-cygwin switch to create executables which do not depend on cygwin.dll 3. Using cross-compiler on some Unix system. I've used cross-compiler included in Debian GNU/Linux ver./g 3.1 (sarge) as package mingw32 The roadmap is to scrap #1 and make #2 work on both cygwin and msys. We already build using the mingw32 compiler under msys. I've been a bit lax about sending back patches lately, but as I recall there were only a few small tweaks to Configure needed. IMO the Cygwin environment is worthless; it is several times slower than MinGW/MSYS for no real benefit. Resulting libraries are in all cases compatible with Microsoft Visual C. In addition #2 should/will generate .def files and use them when linking .dll. Idea is to be able to generate drop-in replacement .dlls for those compiled with MSVC. This has just worked for me for quite a long time now. 3. Using cross-compiler. GNU C cross-compilers can be invoked in two ways 1. Using -B option to gcc 2. Using name which looks like architecture-system-gcc, in this case i586-mingw32msvc-gcc. I recommend using the second way, because we need to call cross-versions of some binutils programs, such as ranlib, and they do not have -B option. I'd create a /some/place/i586-mingw32mscv catalog, create small wrapper scripts called gcc, ranlib, etc. with 'exec i586-mingw32mscv-$0 $@' line, and prepend your $PATH with /some/place/i586-mingw32mscv prior running make:-) A. I've done this type of setup before, with complete toolchains in /some/place/architecture. You just need to put /some/place/arch in front of your path, then you don't need any wrappers. If the idea is to use a single gcc compiler driver to automatically invoke the right cross-compiler based on commandline args, I guess you can go to the trouble of setting up all the pathnames that gcc expects, but it seems like wasted effort to me. It's only useful if you're spawning multiple builds from the same location, and you don't want to muck with your path for each build. But it's pretty irrelevant - you can setup your Makefile such that make sparcv9-solaris8 make i686-mingw all do the right thing, whatever your toolchain setup is. It's really up to you to do something consistent/easy to manage. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Options of building openssl for Win32 using gcc
Andy Polyakov wrote: 1. Using mingw32 compiler (from http://www.mingw.org) 2. Using cygwin compiler with -mno-cygwin switch to create executables which do not depend on cygwin.dll 3. Using cross-compiler on some Unix system. I've used cross-compiler included in Debian GNU/Linux ver./g 3.1 (sarge) as package mingw32 The roadmap is to scrap #1 and make #2 work on both cygwin and msys. In addition #2 should/will generate .def files and use them when linking .dll. Idea is to be able to generate drop-in replacement .dlls for those compiled with MSVC. This has just worked for me for quite a long time now. ??? .dlls generated by our MSVC procedure export entry points by ordinals, while .dlls generated by cygwin/msys - by names. Therefore it's not drop-in replacement. A. Disregard that comment, I was lost. I don't interchange MSVC / gcc dll's on the fly. I was just thinking about the import libraries; a gcc-compiled DLL will work with an MSVC app if it's linked with the gcc-specific import library, and vice-versa. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Finally time for IPvn support
Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Mon, 04 Oct 2004 15:33:46 -0700, Lev Walkin [EMAIL PROTECTED] said: vlm Richard Levitte - VMS Whacker wrote: [...] vlm So, I'm looking for proposals on a new syntax to separate IP address vlm from port number. Any suggestion? vlm vlm This is how Cisco does that: vlm vlm http://www.cisco.com/en/US/products/sw/iosswrel/ios_abcs_ios_the_abcs_ip_version_60900aecd800c111e.html vlm vlm This is another informal proposal: vlm vlm http://lists.debian.org/debian-ipv6/2000/01/msg00030.html vlm vlm Also see: vlm vlm http://gbiv.com/protocols/uri/drafts/draft-masinter-url-ipv6-02.txt Great response! Thanks! Now, to decide what solution to use. For now, I'm torn between the Cisco solution and the one on the Debian list. The Cisco one has the least amount of surprise in it, in my opinion. The Cisco solution *is* the standard solution: http://www.ietf.org/rfc/rfc2732.txt It would be best to avoid any non-standard formats... -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Finally time for IPvn support
Lev Walkin wrote:
Richard Levitte - VMS Whacker wrote:
Hi,
I've just been hacking around a little bit to add IPv6 capability, and
I thought of syntax for host and port specifications.
As it is now, the syntax used a little everywhere in OpenSSL is
{host}:{port}. Unfortunately, if we're to support IPv6 numeric
addresses, I find myself in a little bit of trouble, as IPv6 numeric
addresses contain colons! That makes it hard to distinguish the port
delimiter with parts of the IP address...
So, I'm looking for proposals on a new syntax to separate IP address
from port number. Any suggestion?
This is how Cisco does that:
http://www.cisco.com/en/US/products/sw/iosswrel/ios_abcs_ios_the_abcs_ip_version_60900aecd800c111e.html
I assumed this was the standard format. The software I've written so far
(in OpenLDAP among other things) uses this approach.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #912] Re: [PATCH] Back-translation of CA.pl into CA.sh
Dan Lukes via RT wrote: BTW, the CA.sh use no extensions of Bourne shell (which is, by default, present on Linux only, AFAIK). It should be interpretable by original Korn shell (old good sh), e.g. on almost every UNIX-like OSs. This comment is backwards - Bourne Shell is the original. Korn shell is an extended one. Linux typically ships with BASH, the GNU Bourne-Again SHell which is an extended version of the original Bourne Shell. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Win32 compiles under cygwin
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov Howard, Would you be interested in supporting MSVC command-line builds using gcc2cl? I toyed with this idea once before; I'm not opposed to it. Feel free to submit your scripts/patches to the OpenLDAP ITS. Well, if you choose to discuss unrelated matters, at least fulfill previous direct promises first:-):-):-) I'm half kidding and half referring to the question about what do you replace ar with and/or how do you collect final .lib files. Which you intended to answer:-) A. I presume that these questions will be fully answered in any forthcoming patch... -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Win32 compiles under cygwin
Speaking as a member of the Openldap core team, I'll just point out that we support building on Windows using MinGW. Normally I build with the Cygwin toolchain, but only in -mno-cygwin mode. When we tested Cygwin (~3 years ago) we found the performance to be unacceptable and so have only used the native Windows APIs. I hear that Cygwin has gotten much improved in recent times but we have no interest in it now. I use the same setup to build OpenSSL on Windows. The MSVC project files for OpenLDAP have also been abandoned in OpenLDAP 2.2. The MinGW build is the only one we continue to develop and test. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steven Reddie I believe I wrote gcc2cl originally to get the OpenLDAP build working (OpenLDAP doesn't seem to support a Windows build out-of-the-box, although the code supports Windows, and a separate IDE project file is needed). Yes, autoconf was the difficulty with OpenLDAP that required gcc2cl. Later when doing some work on our OpenSSL build I switched it to gcc2cl partly because I had it available. It would surely be possible to do it without gcc2cl, I just found that the way to go to minimise changes in OpenSSL. However, the INCLUDE and LIB make variables used in OpenSSL needed to be renamed so that they don't overwrite what is expected by cl. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: small 0.9.7c patch
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Rice On Sun, 5 Oct 2003, Mike Castle wrote: I believe these chmod values are better suited: - chmod 555 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i.new; \ + chmod 755 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i.new; \ I seem to recall there is a performance hit on some platforms (HP ?) if the shared libs are writable. Yes, HPUX 10.xx for sure, perhaps newer releases as well. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
According to your truss output, neither version should work at all; select is
returning 0 in every case which means that no descriptors are ready. Perhaps
AIX's /dev/urandom device driver doesn't support select() functionality. That
would certainly be stupid, but not unheard of.
Your patch introduces a bug - since you only told select to check 1
descriptor, and descriptor number 1 isn't actually set in the fdset, the
select simply times out. This is what the return value 0 means from select.
The if/else clause in this function (hell, the whole loop) is written badly
and doesn't distinguish a timeout from an actual failure. In your case, it
treats the timeout as success and proceeds to read from the descriptor, even
though it should actually skip the read.
I really don't see what the point of using select() here is in the first
place. The fd has already been set to Non-Blocking; either the driver will
honor it or it won't. There's nothing more you can do. If you read from
/dev/urandom and don't get the number of bytes you wanted, you're screwed
anyway.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED] via RT
Hi!
No patch should be required, not even AIX can be that weird. An
official specification for select() is available at
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/c
ommtrf1/select.htm
Ok, is it maybe a PEBKAC. But I cannot find an explanation for the
following behavior:
I use the little programm that Anders Liljegren mailed at
http://www.mail-archive.com/[EMAIL PROTECTED]/msg30771
.html about 2
weeks ago.
#include string.h
#include stdlib.h
#include openssl/rand.h
int main(void)
{
exit(RAND_status());
}
Both times openssl is configured with ./Configure aix43-gcc
and compiled
with gcc-3.2.1
and the IBM linker. The first test is without the patch, the
second with
the patch.
Any ideas?
Andreas Walter
truss ./ssl-test
execve(./ssl-test, 0x2FF22BA4, 0x2FF22BAC) argc: 1
__loadx(0x0A04, 0xD03399AC, 0x0003, 0x1000, 0x2D1D) =
0x
_getpid() = 22600
_getpid() = 22600
open(/dev/urandom, O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
_select(4, 0x2FF20A50, 0x, 0x, 0x2FF22A58) = 0
close(3)= 0
open(/dev/random, O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
_select(4, 0x2FF20A50, 0x, 0x, 0x2FF22A58) = 0
close(3)= 0
open(/dev/srandom, O_RDONLY|O_NOCTTY|O_NONBLOCK) Err#2 ENOENT
socket(1, 1, 0) = 3
connext(3, 0x2FF20850, 19) Err#2 ENOENT
close(3)= 0
socket(1, 1, 0) = 3
connext(3, 0x2FF20850, 15) Err#2 ENOENT
close(3)= 0
socket(1, 1, 0) = 3
connext(3, 0x2FF20850, 15) Err#2 ENOENT
close(3)= 0
socket(1, 1, 0) = 3
connext(3, 0x2FF20850, 14) Err#2 ENOENT
close(3)= 0
_getpid() = 22600
sbrk(0x)= 0x2000B4A8
sbrk(0x0008)= 0x2000B4A8
sbrk(0x00010010)= 0x2000B4B0
getuidx(2) = 0
_getpid() = 22600
_getpid() = 22600
kfcntl(1, F_GETFL, 0x20008F54) = 2
kfcntl(2, F_GETFL, 0x) = 2
_exit(0)
truss ./ssl-test-aixpatch
execve(./ssl-test-aixpatch, 0x2FF22B9C, 0x2FF22BA4) argc: 1
__loadx(0x0A04, 0xD03399AC, 0x0003, 0x1000, 0x2D35) =
0x
_getpid() = 24072
_getpid() = 24072
open(/dev/urandom, O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
_select(1, 0x2FF20A40, 0x, 0x, 0x2FF22A48) = 0
kread(3, @ Z ??- G ?806 W V '.., 32) = 32
close(3)= 0
_getpid() = 24072
sbrk(0x)= 0x2000B4D4
sbrk(0x000C)= 0x2000B4D4
sbrk(0x00010010)= 0x2000B4E0
_getpid() = 24072
getuidx(2) = 0
_getpid() = 24072
_getpid
RE: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
The current code is pretty ineffective. Since select() only tells you that at
least 1 byte is available, you still need to do a read to determine how many
bytes are actually there. Given that the descriptor is already open
non-blocking, this would probably be better:
--- rand_unix.c.O Thu Nov 28 00:08:40 2002
+++ rand_unix.c Wed Apr 2 01:15:22 2003
@@ -164,33 +164,25 @@
int r;
fd_set fset;
- do
+ r=read(fd,(unsigned char *)tmpbuf+n,
+ ENTROPY_NEEDED-n);
+ if (r 0)
+ n += r;
+ if (n ENTROPY_NEEDED)
{
FD_ZERO(fset);
FD_SET(fd, fset);
r = -1;
- if (select(fd+1,fset,NULL,NULL,t) 0)
- t.tv_usec=0;
- else if (FD_ISSET(fd, fset))
+ if (select(fd+1,fset,NULL,NULL,t) == 1)
{
r=read(fd,(unsigned char *)tmpbuf+n,
ENTROPY_NEEDED-n);
if (r 0)
n += r;
- }
- /* Some Unixen will update t, some
- won't. For those who won't, give
- up here, otherwise, we will do
- this once again for the remaining
- time. */
- if (t.tv_usec == 10*1000)
- t.tv_usec=0;
+ }
}
- while ((r 0 || (errno == EINTR || errno == EAGAIN))
-t.tv_usec != 0 n ENTROPY_NEEDED);
-
close(fd);
}
}
I removed the loop; I doubt another one or two milliseconds will make any
difference if it fails to fulfill the original read requests.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Lutz Jaenicke via RT On Mon, Mar 31, 2003 at 10:54:31AM +0200, [EMAIL PROTECTED] via RT wrote: Since 5.2 AIX supports /dev/random and /dev/urandom. Openssl don't use it because the select system call works different on AIX than on linux. As described in the following URL, the select system call expects the number of file describtors as first parameter in AIX. Linux expects the highst numbered fd +1. http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/c ommtrf1/select.htm Are you sure? select() is around since UNIX exists, that means the early 70s, maybe longer. I am not that good when it comes to UNIX history :-) I would not believe that IBM would break more or less all programs by chaning the select() API in an incompatible way. This is a non-issue; they are two different ways of saying the same thing. The AIX description is the same one all Unix systems with select() have used since... 4.2BSD. I don't recall if 4.1 had select() or not. Think about it. The fdset is a bit field. The nfds parameter tells select how far into the field it needs to look. Each bit corresponds to one fd. If you have fd#0, that corresponds to bit #1. This is why the number of fds is *always* the highest numbered fd +1. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dilkie, Lee This is a non-issue; they are two different ways of saying the same thing. The AIX description is the same one all Unix systems with select() have used since... 4.2BSD. I don't recall if 4.1 had select() or not. Think about it. The fdset is a bit field. The nfds parameter tells select how far into the field it needs to look. Each bit corresponds to one fd. If you have fd#0, that corresponds to bit #1. This is why the number of fds is *always* the highest numbered fd +1. They are *not* the same thing. Wrong. I may have only one fd with a value of 100. IBM's select asks that nfdsmsgs (the first parameter) be set to 1. (kind like poll) Wrong. Linux/BSD requires it be set to 101. Not all implementations of fd_set's and hence select() use bit arrays (win32 does not either but it ignores the first parameter of select). The man page on the referenced URL states that the fdset is a bitmask. Please re-read the documentation: http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf2/select. htm#HDRA15691187 Quoting from the above page: NfdsmsgsSpecifies the number of file descriptors and the number of message queues to check. The low-order 16 bits give the length of a bit mask that specifies which file descriptors to check; the high-order 16 bits give the size of an array that contains message queue identifiers. If either half of the Nfdsmsgs parameter is equal to a value of 0, the corresponding bit mask or array is assumed not to be present. The Nfds parameter is the length of the bitmask. This is exactly the same definition as on BSD. Changing this definition would totally break compatibility with all Unix networking software written to date. They're not that stupid. And the behaviour of select() is not consistant across implementations either. Linux has a different behaviour from the standard BSD/UNIX/win32. Just ask anyone who's tried to code select for a non-blocking socket connect Linux was never originally intended to be Just Like Unix. It has been forced into that direction by later generations of hackers, but some of its early design decisions remain to this day. So it goes. As someone once said, Those who don't understand Unix are doomed to reimplement it, badly. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [PATCH] Howard Chu's EBCDIC-Port upgrade patch
-Original Message- From: Martin Kraemer [mailto:[EMAIL PROTECTED] Hello Howard, hello OpenSSL developers, Hello! At http://www.openldap.org/faq/index.cgi?file=745 you print the set of patches to OpenSSL, and I verified them to work on our BS2000 version of OpenSSL as well - the do indeed fix the problems in the openssl application. One minor nit: in apps/ca.c, you subtract the literal EBCDIC-'@' from an EBCDIC-char to construct the control-char; this will not work, you must use 0x40 instead of '@' (fixed in attached patch). Ah, silly me. Thanks for catching that. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [CVS] OpenSSL: openssl Makefile.org
Please please please forget about that allextract nonsense. You will*never* get it portable to all desired platforms. Just take the lib*.a and relink it explicitly: mkdir tmp; cd tmp; ar x ../libcrypto.a; ld -r -o ../libcrypto.o *.o ld -G -o libcrypto.so libcrypto.o -lwhatever -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Monday, December 16, 2002 11:10 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [CVS] OpenSSL: openssl Makefile.org In message [EMAIL PROTECTED] on Mon, 16 Dec 2002 19:54:08 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro Richard, you win but for another reason:-) WorkShop C (as well as other appro vendor compiler drivers) does understand -Wl, *but* some of thier appro (Sun's) compiler drivers (well, one of those I have) collect all -Wl appro options in the beginning of ld command line so that ld is invoked as ld appro -z allextract -z defaultextract ... libcrypto.a ..., while idea is appro basically ld ... -z allextract libcrypto.a -z defaultextract ... Why, appro oh why? A. Eh god... So basically, we not only need to detect if GNU ld is used, but that it's really GNU cc as well? What happens if the compiler isn't GNU but ld is? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [CVS] OpenSSL: openssl Makefile.org
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andy Polyakov Please please please forget about that allextract nonsense. You will*never* get it portable to all desired platforms. The changes being discussed affect Solaris and Solaris only, we're not talking about all desired platforms. Just take the lib*.a and relink it explicitly: mkdir tmp; cd tmp; ar x ../libcrypto.a; ld -r -o ../libcrypto.o *.o ld -G -o libcrypto.so libcrypto.o -lwhatever As mentioned calling /usr/ccs/bin/ld *is* an alternative. Or is it? Imagine following scenario. You compile the toolkit with gcc and link with ld as you suggest. This might leave unresolved references to libgcc. Now if it did, then attempt to cc ... -lssl would fail... A. Never mind the direct invocation of ld in my example above. The point I was trying to get across is to eliminate the dependency on the allextract flag. Use whatever linking step you would normally have used after creating e.g. libcrypto.o. Also, you will find that libgcc is only needed because gcc was used for the link step. It's only because of the C++ constructor/destructor cruft that gcc always throws on there that libgcc becomes a dependency. If you compile with gcc and link with ld you get a perfectly working standalone library, no libgcc required. Even though you guys were only discussing Solaris - for the sake of portability and maintainability, stick to the least common denominator. Don't introduce special cases where none are needed. There is no reason to have 18-zillion different variations on how to create a shared libcrypto or libssl using god knows how many different platform-specific and version-specific LD flags. You can use basic, plain Jane, SVR3/BSD4.2 syntax to get over the main hurdle, and then use the appropriate -shared flag for your linker of choice after the basic object file exists. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [CVS] OpenSSL: openssl Makefile.org
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker In message [EMAIL PROTECTED] on Mon, 16 Dec 2002 21:30:46 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro Just take the lib*.a and relink it appro explicitly: appro mkdir tmp; cd tmp; ar x ../libcrypto.a; ld -r -o ../libcrypto.o *.o appro ld -G -o libcrypto.so libcrypto.o -lwhatever appro appro As mentioned calling /usr/ccs/bin/ld *is* an alternative. Or is it? appro Imagine following scenario. You compile the toolkit with gcc and link appro with ld as you suggest. This might leave unresolved references to appro libgcc. Now if it did, then attempt to cc ... -lssl would fail... A. OK, I lied a message ago. In 0.9.8-dev's Makefile.shared, the first ld is actually an ld, while the second shown above is done through cc or gcc. Right. The first line must use ld to create the relocatable object, the final link can be done by cc / gcc / ld, whichever, as appropriate. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [CVS] OpenSSL: openssl Makefile.org
-Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] In message 005201c2a53d$5f4523f0$0e01a8c0@CELLO on Mon, 16 Dec 2002 11:55:55 -0800, Howard Chu [EMAIL PROTECTED] said: hyc Please please please forget about that allextract nonsense. You hyc will*never* get it portable to all desired platforms. Just take hyc the lib*.a and relink it explicitly: hyc mkdir tmp; cd tmp; ar x ../libcrypto.a; ld -r -o ../libcrypto.o *.o hyc ld -G -o libcrypto.so libcrypto.o -lwhatever BTW, are you sure about 'ld -r' never needing any '-z allextract' or whatever turns the local ld on? The reason I ask is that you provided the do_aix-shared target that's present in 0.9.7. No, I honestly don't recall if I did a lot of hacking into whatever you contributed or not, but I thought you said it looked OK. In that case, I'd take a closer look at the ALLSYMSFLAG example for Solaris. Is that one correct or not? What about the other platforms, are they correct as well? I'll take a look. Sorry I didn't pay closer attention till now, I've had a lot of other loose threads to chase. Yes, ld -r works on every Unix-ish system from the newest of today to going back 30 years ago. There's no magic, you're just extracting the entire contents of the archive file and then telling ld to link all of those objects into a single relocatable object file. This is exactly what an ALLSYMSFLAG *must* do under the covers, but by doing it yourself you have complete control over the procedure. Note that for 0.9.7, I don't care since that method is used exclusively used for AIX and none else. 0.9.8-dev is another story, however, since I simply looked at do_aix-shared and generalised it further (to the point of having a general Makefile that should be possible to use for any library on any of the supported platforms). I know Andy is looking, but I also know his time is short, so if you have the time and inclination to help, please take a look at Makefile.shared in 0.9.8-dev. If you have any question, please ask. I will get back to you in a day or so, I have refresh my rsync config and other such before I can pull the tree down. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL and compression using ZLIB
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Le Saux, Eric In the current implementation of OpenSSL, compression/decompression state is initialized and destroyed per record. It cannot possibly interoperate with a compressor that maintains compression state across records. The decompressor does care, unfortunately. This is surprising. I haven't looked at the code recently, but my experience has been that a special bit sequence is emitted to signal a dictionary flush. I haven't tested it either, so if you say it didn't work I believe you. But plain old LZW definitely does not have this problem, the compressor can do whatever it wants, and the decompressor will stay sync'd up because it detects these reset codes. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
I don't recall what happened to the other email thread, but I also submitted patches for that issue as well. The idea is to keep the OpenSSL internal data structures in ASCII. So I patched a couple of the conf routines to translate EBCDIC (read from a config file) into ASCII, etc. You need to do this anyway, because the ca program was double-translating some of the certificate fields on display, turning them into garbage. (I alluded to that in this msg thread, in fact.) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of Richard Levitte via RT Sent: Thursday, November 14, 2002 10:00 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390 [[EMAIL PROTECTED] - Thu Aug 29 09:12:28 2002]: Ok, so after getting past the previous problems, the testca script failed. Fixing this last problem allows the tests to successfully run to completion. The problem was that the ca app didn't like the result it got from ASN1_PRINTABLE_type() (apps/ca.c, line 1586) because the ASN1_PRINTABLE_type function had been modified to expect EBCDIC strings, and the string being tested is in ASCII. Since passing EBCDIC strings to a function named ASN1_PRINTABLE_type doesn't make a lot of sense to me, I chose to remove the EBCDIC part from crypto/asn1/a_print.c: It does make sense. If you look up the other reference to it in apps/ca.c, you'll see that it gets called with data coming from the configuration file. The configuration might be coded in EBCDIC. Changing this might become a larger can of worms than I think I'm willing to put in right now. We really need to design a better way to handle this, so we are absolutely certain we know what we have at all times. Right now, I can't say I'm sure what's what... -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL PROBLEM on HP-UX 11.00 and 11.11 (11i)
We are using OpenSSL 0.9.6g on HP-UX 11.00 and 11.11 without any trouble. It's bundled into our CDS package (OpenLDAP+OpenSSL+Heimdal+SASL) and is available for free download from www.symas.com. We aren't doing anything fancy here, just using libssl for LDAP connection security, but it works without any issues. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of Lutz Jaenicke Sent: Tuesday, October 22, 2002 12:02 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: OpenSSL PROBLEM on HP-UX 11.00 and 11.11 (11i) On Mon, Oct 21, 2002 at 02:50:43PM -0700, J wrote: Has anyone had trouble with using the OpenSSL library on HP-UX?? I am using version 0.9.6d and there seems to be an intermittent problem with the digest encryption, or just some of the encryption/decryption routines in the OpenSSL toolkit. It does not happen all the time on HP-UX 11i, but it occurs all the time in HP-UX 11.00, in that the encryption and decryptions do not work. This was just recently ported to the HP-UX source tree of the product that is using OpenSSL. We have not had any report about a similar failure. I am using openssl on HP-UX 10.20 and could not see any problem, yet. I am afraid, that without a more specific problem report we will not be able to help you in narrowing down the issue. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Makefile tweak 0.9.6g
Here's a small patch for the shared library build that allows you to re-run
make in a directory without unnecessarily recreating the shared library
files. It moves them into a .libs subdirectory so they'll be out of the way,
instead of using clean-shared to get rid of them. We build OpenSSL inside a
larger project and while fixing problems in other directories we do a lot of
top-level make invocations and it's annoying to have this trigger a rebuild
all the time. (Because we have dependencies on libcrypto/libssl etc.)
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
Index: Makefile.org
===
RCS file: /var/CVSROOT/ssl/Makefile.org,v
retrieving revision 1.1.1.2
retrieving revision 1.6
diff -w -u -r1.1.1.2 -r1.6
--- Makefile.org20 Sep 2002 21:50:37 - 1.1.1.2
+++ Makefile.org23 Sep 2002 01:54:34 - 1.6
-194,9 +194,9
HEADER= e_os.h
# When we're prepared to use shared libraries in the programs we link here
-# we might remove 'clean-shared' from the targets to perform at this stage
+# we might remove 'move-shared' from the targets to perform at this stage
-all: clean-shared Makefile.ssl sub_all
+all: Makefile.ssl sub_all
sub_all:
for i in $(DIRS); \
-211,36 +211,52
if echo $(DIRS) | \
egrep '(^| )(crypto|ssl)( |$$)' /dev/null 21 \
[ -n $(SHARED_LIBS) ]; then \
- $(MAKE) $(SHARED_LIBS); \
+ $(MAKE) setup-shared; \
fi
-libcrypto$(SHLIB_EXT): libcrypto.a
+$(SHARED_CRYPTO): libcrypto.a
if [ $(SHLIB_TARGET) != ]; then \
$(MAKE) SHLIBDIRS=crypto build-shared; \
else \
echo There's no support for shared libraries on this platform 2; \
fi
-libssl$(SHLIB_EXT): libcrypto$(SHLIB_EXT) libssl.a
+$(SHARED_SSL): $(SHARED_CRYPTO) libssl.a
if [ $(SHLIB_TARGET) != ]; then \
$(MAKE) SHLIBDIRS=ssl SHLIBDEPS='-lcrypto' build-shared; \
else \
echo There's no support for shared libraries on this platform 2; \
fi
+setup-shared: $(SHARED_LIBS)
+ $(MAKE) move-shared
+
clean-shared:
for i in $(SHLIBDIRS); do \
if [ -n $(SHARED_LIBS_LINK_EXTS) ]; then \
tmp=$(SHARED_LIBS_LINK_EXTS); \
for j in $${tmp:-x}; do \
- ( set -x; rm -f lib$$i$$j ); \
+ ( set -x; rm -f lib$$i$$j .libs/lib$$i$$j ); \
done; \
fi; \
- ( set -x; rm -f lib$$i$(SHLIB_EXT) ); \
+ ( set -x; rm -f lib $$i$(SHLIB_EXT) .libs/lib$$i$(SHLIB_EXT) ); \
if [ $(PLATFORM) = Cygwin ]; then \
- ( set -x; rm -f cyg$$i$(SHLIB_EXT) lib$$i$(SHLIB_EXT).a ); \
+ ( set -x; rm -f cyg$$i$(SHLIB_EXT) lib$$i$(SHLIB_EXT).a \
+ .libs/cyg$$i$(SHLIB_EXT) .libs/lib$$i$(SHLIB_EXT).a ); \
fi; \
done
+.libs:
+ mkdir .libs
+
+move-shared: .libs
+ for i in $(SHLIBDIRS); do \
+ ( set -x; mv lib$$i$(SHLIB_EXT) .libs ); \
+ tmp=$(SHARED_LIBS_LINK_EXTS); \
+ for j in $${tmp:-x}; do \
+ ( set -x; mv lib$$i$$j .libs ); \
+ done; \
+ done
+
link-shared:
if [ -n $(SHARED_LIBS_LINK_EXTS) ]; then \
tmp=$(SHARED_LIBS_LINK_EXTS); \
-254,7 +270,10
done; \
fi
-build-shared: clean-shared do_$(SHLIB_TARGET) link-shared
+build-shared:
+ $(MAKE) clean-shared
+ $(MAKE) do_$(SHLIB_TARGET)
+ $(MAKE) link-shared
do_bsd-gcc-shared: do_gnu-shared
do_linux-shared: do_gnu-shared
-353,6 +372,7
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( PATH=/usr/ccs/bin:$$PATH ; export PATH; \
set -x; ${CC} ${SHARED_LDFLAGS} \
+ -R ${INSTALLTOP}/lib \
-G -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
-h lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
-z allextract lib$$i.a $$libs ${EX_LIBS} -lc ) || exit 1; \
RE: Makefile tweak 0.9.6g
Argh... That last patch wasn't quite right. This one works a bit better.
(Note that build-shared is serialized to allow parallel builds to work.)
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
Here's a small patch for the shared library build that allows
you to re-run
make in a directory without unnecessarily recreating the
shared library
files. It moves them into a .libs subdirectory so they'll be
out of the way,
instead of using clean-shared to get rid of them. We build
OpenSSL inside a
larger project and while fixing problems in other directories
we do a lot of
top-level make invocations and it's annoying to have this
trigger a rebuild
all the time. (Because we have dependencies on libcrypto/libssl etc.)
Index: Makefile.org
===
RCS file: /var/CVSROOT/ssl/Makefile.org,v
retrieving revision 1.1.1.2
retrieving revision 1.7
diff -w -u -r1.1.1.2 -r1.7
--- Makefile.org20 Sep 2002 21:50:37 - 1.1.1.2
+++ Makefile.org23 Sep 2002 02:27:12 - 1.7
-179,8 +179,8
EDIRS= times doc bugs util include certs ms shlib mt demos perl sf dep VMS
WDIRS= windows
LIBS= libcrypto.a libssl.a
-SHARED_CRYPTO=libcrypto$(SHLIB_EXT)
-SHARED_SSL=libssl$(SHLIB_EXT)
+SHARED_CRYPTO=.libs/libcrypto$(SHLIB_EXT)
+SHARED_SSL=.libs/libssl$(SHLIB_EXT)
SHARED_LIBS=
SHARED_LIBS_LINK_EXTS=
SHARED_LDFLAGS=
-194,9 +194,9
HEADER= e_os.h
# When we're prepared to use shared libraries in the programs we link here
-# we might remove 'clean-shared' from the targets to perform at this stage
+# we might remove 'move-shared' from the targets to perform at this stage
-all: clean-shared Makefile.ssl sub_all
+all: Makefile.ssl sub_all
sub_all:
for i in $(DIRS); \
-211,16 +211,16
if echo $(DIRS) | \
egrep '(^| )(crypto|ssl)( |$$)' /dev/null 21 \
[ -n $(SHARED_LIBS) ]; then \
- $(MAKE) $(SHARED_LIBS); \
+ $(MAKE) .libs; \
fi
-libcrypto$(SHLIB_EXT): libcrypto.a
+$(SHARED_CRYPTO): libcrypto.a
if [ $(SHLIB_TARGET) != ]; then \
$(MAKE) SHLIBDIRS=crypto build-shared; \
else \
echo There's no support for shared libraries on this platform 2; \
fi
-libssl$(SHLIB_EXT): libcrypto$(SHLIB_EXT) libssl.a
+$(SHARED_SSL): $(SHARED_CRYPTO) libssl.a
if [ $(SHLIB_TARGET) != ]; then \
$(MAKE) SHLIBDIRS=ssl SHLIBDEPS='-lcrypto' build-shared; \
else \
-232,15 +232,29
if [ -n $(SHARED_LIBS_LINK_EXTS) ]; then \
tmp=$(SHARED_LIBS_LINK_EXTS); \
for j in $${tmp:-x}; do \
- ( set -x; rm -f lib$$i$$j ); \
+ ( set -x; rm -f lib$$i$$j .libs/lib$$i$$j ); \
done; \
fi; \
- ( set -x; rm -f lib$$i$(SHLIB_EXT) ); \
+ ( set -x; rm -f lib $$i$(SHLIB_EXT) .libs/lib$$i$(SHLIB_EXT) ); \
if [ $(PLATFORM) = Cygwin ]; then \
- ( set -x; rm -f cyg$$i$(SHLIB_EXT) lib$$i$(SHLIB_EXT).a ); \
+ ( set -x; rm -f cyg$$i$(SHLIB_EXT) lib$$i$(SHLIB_EXT).a \
+ .libs/cyg$$i$(SHLIB_EXT) .libs/lib$$i$(SHLIB_EXT).a ); \
fi; \
done
+.libs: $(SHARED_LIBS)
+ -mkdir .libs
+ $(MAKE) move-shared
+
+move-shared:
+ -for i in $(SHLIBDIRS); do \
+ ( set -x; mv lib$$i$(SHLIB_EXT) .libs ); \
+ tmp=$(SHARED_LIBS_LINK_EXTS); \
+ for j in $${tmp:-x}; do \
+ ( set -x; mv lib$$i$$j .libs ); \
+ done; \
+ done
+
link-shared:
if [ -n $(SHARED_LIBS_LINK_EXTS) ]; then \
tmp=$(SHARED_LIBS_LINK_EXTS); \
-254,7 +268,10
done; \
fi
-build-shared: clean-shared do_$(SHLIB_TARGET) link-shared
+build-shared:
+ $(MAKE) clean-shared
+ $(MAKE) do_$(SHLIB_TARGET)
+ $(MAKE) link-shared
do_bsd-gcc-shared: do_gnu-shared
do_linux-shared: do_gnu-shared
RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dr. Stephen Henson On Fri, Aug 30, 2002, Howard Chu wrote: The output from testca is still a little dodgy, there are a few certificate fields that are printed in ASCII that need to be translated to EBCDIC for appearance's sake. But that's simple to fix; if you're interested I'll submit patches for that later. X509v3 extensions weren't handling EBCDIC correctly. Trying to set a subjectAltName resulted in the EBCDIC strings going into the cert, instead of ASCII. Here are the fixes for crypto/x509v3. Also, the ca app needs a small patch to translate DN components from ASCII to EBCDIC when confirming their values. Now I look at this, I'm not sure this is being handled the right way. I don't have access to an EBCDIC box so this analysis may not be 100% accurate... Your analysis sounds correct to me. The current stuff (I think) conf-name EBCDIC but conf-value ASCII (where it works that is). Yes. The reason for the problem is that there are calls to: X509V3_add_value(name, value, sk); but there are two cases. If the call is something like: X509V3_add_value(some_field_name,cert-foo, sk); where cert-foo is some value from a certificate we end up with conf-name using the native character set but conf-value using whatever is in the certificate which will be ASCII. If however we do: X509V3_add_value(some_field_name, unsupported, sk); both conf-name and conf-value have the native character set. This isn't a problem if the native character set is ASCII, but if it isn't the two cases will differ such as if the native is EBCDIC. Yes. So I'd suggest that we decide what values should go in conf-name and conf-value. It might be advisable for both to always use the native character set, then if you do: if (strcmp(conf-value, some_field_value) == 0) it will always work. The current approach is not terribly broken. Changing the convention now will just be a lot of extra work. The bulk of the library is geared for ASCII, and I think this makes the most sense. The arbitrary strcmp's may be a problem, but I think that's a different issue; fields that accept only certain values should have those values defined in only one place. Instead of embedding TRUE string literals all over the source code, it should be a single constant defined once for the entire library. There's an alternate solution to this particular issue, when using the IBM C compiler - you can set a compiler option/pragma to choose the character set that will encode any string/char literals. I use this approach in the OS/390 port of OpenLDAP - again, all library internals are ASCII, and EBCDIC translation only occurs in stdio stubs - reading native config files, and displaying output. Limiting translation to these interfaces means the internals still run at full speed with no translation overhead. Also I'd suggest a new function, X509V3_add_value_native() (or whatever) which does any conversion inside and this is always called where it might be needed. Then in the call to X509V3_add_value_native() we can either just call X509V3_add_value (on ASCII machines) or do the conversion (on EBCDIC). In the spirit of this solution, I'd add X509V3_add_value_ascii() instead, which accepts native strings and stores them as ASCII. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Howard Chu
The output from testca is still a little dodgy, there are a few certificate
fields that are printed in ASCII that need to be translated to EBCDIC for
appearance's sake. But that's simple to fix; if you're interested
I'll submit
patches for that later.
X509v3 extensions weren't handling EBCDIC correctly. Trying to set a
subjectAltName resulted in the EBCDIC strings going into the cert, instead of
ASCII. Here are the fixes for crypto/x509v3. Also, the ca app needs a small
patch to translate DN components from ASCII to EBCDIC when confirming their
values.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
--- v3_alt.c2002/08/31 03:27:11 1.1
+++ v3_alt.c2002/08/31 03:31:54
@@ -99,6 +99,15 @@
return ret;
}
+#ifdef CHARSET_EBCDIC
+static const char _unsup[] = {0x3c,0x75,0x6e,0x73,0x75,0x70,0x70,0x6f,
+ 0x72,0x74,0x65,0x64,0x3e,0 };
+static const char _inval[] = {0x3c,0x69,0x6e,0x76,0x61,0x6c,0x69,0x64,0x3e,0};
+#else
+static const char _unsup[] = unsupported;
+static const char _inval[] = invalid;
+#endif
+
STACK_OF(CONF_VALUE) *i2v_GENERAL_NAME(X509V3_EXT_METHOD *method,
GENERAL_NAME *gen, STACK_OF(CONF_VALUE) *ret)
{
@@ -107,15 +116,15 @@
switch (gen-type)
{
case GEN_OTHERNAME:
- X509V3_add_value(othername,unsupported, ret);
+ X509V3_add_value(othername,_unsup, ret);
break;
case GEN_X400:
- X509V3_add_value(X400Name,unsupported, ret);
+ X509V3_add_value(X400Name,_unsup, ret);
break;
case GEN_EDIPARTY:
- X509V3_add_value(EdiPartyName,unsupported, ret);
+ X509V3_add_value(EdiPartyName,_unsup, ret);
break;
case GEN_EMAIL:
@@ -132,6 +141,9 @@
case GEN_DIRNAME:
X509_NAME_oneline(gen-d.dirn, oline, 256);
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(oline, oline, strlen(oline));
+#endif
X509V3_add_value(DirName,oline, ret);
break;
@@ -139,15 +151,21 @@
p = gen-d.ip-data;
/* BUG: doesn't support IPV6 */
if(gen-d.ip-length != 4) {
- X509V3_add_value(IP Address,invalid, ret);
+ X509V3_add_value(IP Address,_inval, ret);
break;
}
sprintf(oline, %d.%d.%d.%d, p[0], p[1], p[2], p[3]);
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(oline, oline, strlen(oline));
+#endif
X509V3_add_value(IP Address,oline, ret);
break;
case GEN_RID:
i2t_ASN1_OBJECT(oline, 256, gen-d.rid);
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(oline, oline, strlen(oline));
+#endif
X509V3_add_value(Registered ID,oline, ret);
break;
}
@@ -383,6 +401,9 @@
}
if(is_string) {
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(value, value, strlen(value));
+#endif
if(!(gen-d.ia5 = M_ASN1_IA5STRING_new()) ||
!ASN1_STRING_set(gen-d.ia5, (unsigned char*)value,
strlen(value))) {
--- v3_utl.c2002/08/31 03:27:11 1.1
+++ v3_utl.c2002/08/31 03:28:06
@@ -111,6 +111,14 @@
OPENSSL_free(conf);
}
+#ifdef CHARSET_EBCDIC
+static const char _true[] = {0x54, 0x52, 0x55, 0x45, 0x00 };
+static const char _false[] = {0x46, 0x41, 0x4c, 0x53, 0x45, 0x00};
+#else
+static const char _true[] = TRUE;
+static const char _false[] = FALSE;
+#endif
+
int X509V3_add_value_bool(const char *name, int asn1_bool,
STACK_OF(CONF_VALUE) **extlist)
{
--- ca.c2002/08/31 03:38:01 1.1
+++ ca.c2002/08/31 03:39:35
@@ -1596,13 +1596,22 @@
p=(char *)str-data;
for (j=str-length; j0; j--)
{
+#ifdef CHARSET_EBCDIC
+ if ((*p = 0x20) (*p = 0x7e))
+ BIO_printf(bio_err,%c, os_toebcdic[*p]);
+#else
if ((*p = ' ') (*p = '~'))
BIO_printf(bio_err,%c,*p);
+#endif
else if (*p 0x80)
BIO_printf(bio_err,\\0x%02X,*p);
else if ((unsigned char)*p == 0xf7)
BIO_printf(bio_err,^?);
+#ifdef CHARSET_EBCDIC
+ elseBIO_printf(bio_err,^%c,os_toebcdic[*p+'@']);
+#else
elseBIO_printf(bio_err,^%c,*p+'@');
+#endif
p
RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
Damn, sent an incomplete diff for crypto/x509v3/v3_utl.c. Sorry about that.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Howard Chu
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Howard Chu
The output from testca is still a little dodgy, there are a few
certificate
fields that are printed in ASCII that need to be translated to EBCDIC for
appearance's sake. But that's simple to fix; if you're interested
I'll submit
patches for that later.
X509v3 extensions weren't handling EBCDIC correctly. Trying to set a
subjectAltName resulted in the EBCDIC strings going into the cert,
instead of
ASCII. Here are the fixes for crypto/x509v3. Also, the ca app needs a small
patch to translate DN components from ASCII to EBCDIC when confirming their
values.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
--- v3_utl.c2002/08/31 03:27:11 1.1
+++ v3_utl.c2002/08/31 04:59:00
@@ -111,17 +111,25 @@
OPENSSL_free(conf);
}
+#ifdef CHARSET_EBCDIC
+static const char _true[] = {0x54, 0x52, 0x55, 0x45, 0x00 };
+static const char _false[] = {0x46, 0x41, 0x4c, 0x53, 0x45, 0x00};
+#else
+static const char _true[] = TRUE;
+static const char _false[] = FALSE;
+#endif
+
int X509V3_add_value_bool(const char *name, int asn1_bool,
STACK_OF(CONF_VALUE) **extlist)
{
- if(asn1_bool) return X509V3_add_value(name, TRUE, extlist);
- return X509V3_add_value(name, FALSE, extlist);
+ if(asn1_bool) return X509V3_add_value(name, _true, extlist);
+ return X509V3_add_value(name, _false, extlist);
}
int X509V3_add_value_bool_nf(char *name, int asn1_bool,
STACK_OF(CONF_VALUE) **extlist)
{
- if(asn1_bool) return X509V3_add_value(name, TRUE, extlist);
+ if(asn1_bool) return X509V3_add_value(name, _true, extlist);
return 1;
}
RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
I hate buggy compilers! Building crypto/rand/rand_lib.c with -g flag fixes the randtest problem and allows most of the tests to succeed. The treq fails because openssl can't find subjectKeyIdentifier. Rebuilding crypto/x509v3 with -g clears this up. What a pain. (At this point the obvious thing to do is just build all of OpenSSL with -g but the resulting objects with embedded debug symbols are huge, 10x size at least.) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Howard Chu Sent: Thursday, August 22, 2002 3:30 PM To: [EMAIL PROTECTED] Subject: RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390 Removing -O from CFLAGS and recompiling the crypto/des directory fixed the mdc2test error. Getting past this, randtest fails. Rebuilding without optimization hasn't affected that problem. (How ironic, the optimizer gives us random results when we don't want them, and the random number lib doesn't give random results, tho we do want them...) do29:~/openssl-0.9.6g/test ./randtest test 1 failed, X=2694 test 1 done test 2 failed, X=31739.44 test 2 done test 3 failed, bit=0 run=1 num=413 test 3 failed, bit=0 run=2 num=213 test 3 failed, bit=0 run=3 num=199 test 3 failed, bit=0 run=4 num=153 test 3 failed, bit=0 run=5 num=67 test 3 failed, bit=0 run=6 num=711 test 3 failed, bit=1 run=1 num=1248 test 3 failed, bit=1 run=2 num=280 test 3 failed, bit=1 run=3 num=136 test 3 failed, bit=1 run=4 num=59 test 3 failed, bit=1 run=5 num=11 test 3 failed, bit=1 run=6 num=22 test 3 done test 4 failed, bit=0 run=34 num=54 test 4 done -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Howard Chu via RT mdc2test produces different results every time it is executed. Seems like something is uninitialized and filling with random data on every invocation. Does this sound familiar to anyone? All the tests up to this point are correct, many of the tests after this point fail. It seems odd to me since mdc2 uses DES and the destest succeeds. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
Ok, so after getting past the previous problems, the testca script failed.
Fixing this last problem allows the tests to successfully run to completion.
The problem was that the ca app didn't like the result it got from
ASN1_PRINTABLE_type() (apps/ca.c, line 1586) because the ASN1_PRINTABLE_type
function had been modified to expect EBCDIC strings, and the string being
tested is in ASCII. Since passing EBCDIC strings to a function named
ASN1_PRINTABLE_type doesn't make a lot of sense to me, I chose to remove
the EBCDIC part from crypto/asn1/a_print.c:
--- a_print.c 2002/08/28 23:52:53 1.1
+++ a_print.c 2002/08/29 00:05:50
@@ -116,27 +116,18 @@
while ((*s) (len-- != 0))
{
c= *(s++);
-#ifndef CHARSET_EBCDIC
- if (!( ((c = 'a') (c = 'z')) ||
- ((c = 'A') (c = 'Z')) ||
- (c == ' ') ||
- ((c = '0') (c = '9')) ||
- (c == ' ') || (c == '\'') ||
- (c == '(') || (c == ')') ||
- (c == '+') || (c == ',') ||
- (c == '-') || (c == '.') ||
- (c == '/') || (c == ':') ||
- (c == '=') || (c == '?')))
- ia5=1;
if (c0x80)
+ {
t61=1;
-#else
- if (!isalnum(c) (c != ' ')
- strchr('()+,-./:=?, c) == NULL)
+ break;
+ }
+ if (!( ((c 0x40) (c 0x5b)) || /* AZ */
+ ((c 0x60) (c 0x7b)) || /* az */
+ ((c 0x2a) (c 0x3b)) || /* +,-./09: */
+ (c == 0x20) || (c == 0x27) || /* SPC, ' */
+ (c == 0x28) || (c == 0x29) || /* () */
+ (c == 0x3d) || (c == 0x3f)))/* =? */
ia5=1;
- if (os_toascii[c] 0x80)
- t61=1;
-#endif
}
if (t61) return(V_ASN1_T61STRING);
if (ia5) return(V_ASN1_IA5STRING);
The output from testca is still a little dodgy, there are a few certificate
fields that are printed in ASCII that need to be translated to EBCDIC for
appearance's sake. But that's simple to fix; if you're interested I'll submit
patches for that later.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
By the way, here's the end of the successful make test... make[1]: Leaving directory `/c56/c56006/openssl-0.9.6g/test' OpenSSL 0.9.6g 9 Aug 2002 built on: Wed Aug 28 20:11:13 EDT 2002 platform: OS390-Unix options: bn(32,32) md2(char) rc4(idx,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) compiler: c89 -O -D_ALL_SOURCE -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Howard Chu Sent: Wednesday, August 28, 2002 5:19 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390 Ok, so after getting past the previous problems, the testca script failed. Fixing this last problem allows the tests to successfully run to completion. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Small patch to 0.9.6c crypto/objects/obj_dat.c
I just checked the CVS head and this patch should be valid there as well:
diff -u -r1.1 obj_dat.c
--- obj_dat.c 2002/04/18 04:34:17 1.1
+++ obj_dat.c 2002/04/18 04:35:10
@@ -437,8 +437,7 @@
return(0);
}
- nid=OBJ_obj2nid(a);
- if ((nid == NID_undef) || no_name) {
+ if (no_name || (nid=OBJ_obj2nid(a)) == NID_undef) {
len=a-length;
p=a-data;
(Just a slight speedup when I'm munging DNs by OID...) I hope you can commit
this for 0.9.6d/0.9.7 without too much trouble. :)
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: Wrong DNs
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bell Vadim Fedukovich schrieb: On Mon, 15 Apr 2002, Michael Bell wrote: Hi, we found today a big problem with the DNs which OpenSSL displays because our application (OpenCA) produce DNs which are conform to the directorystandards but OpenSSL interprets them in the opposite order. What does this mean? Here an example: The root of our directory is the following: o=HU, c=de The organizational unit for the PKI is Test-CA. So the next DN in the directory must be: ou=Test-CA, o=HU, c=de A certificate would have the DN cn=bell, ou=Test-CA, o=HU, c=de. It is no problem to produce this DN with OpenSSL but then we were a little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc. with OpenSSL. They have all the format c=US, o=VeriSign, ... (openssl-*/cerst/). All these trustcenters use LDAP-servers but these DNs can never be stored in a directoryserver! So it looks like OpenSSL displays the different parts of a DN in the wrong order. Did I make a misinterpretation? If this is a bug then I have the next question, can you fix this in the 0.9.7-tree? It is possible to protect the old index.txt etc. by adding an option -x500 or something like this to get a DN which can be inserted in a directoryserver. The problem is that OpenSSL interprets a correct DN with openssl req -subj 'cn=...,c=de' in the wrong order (so we get a wrong certificate). I know no optimal solution except of adding such an option to every related command or add an option like -oldstyledn to openssl x509 and openssl ca but before starting discussing solutions I will wait for an answer (bug or misinterpretation). Best Regards, Michael Michael, LDAP-style DNs are never of concern while signature verification. Please note LDAP encode names in a different, lightweight manner. One may want to use other (non-openssl) tools to manage that encoding (LDAP trees). What do you want to say with this answer? The problem has nothing to do with signature verification. If you use openssl x509 or any other openssl command then you will see a DN. The question is, why is the order (in which the DN is displayed) different from the one used for LDAP. Use X.500 the opposite order of LDAP? Michael There is no bug, unless you consider LDAP itself a bug. Yes, LDAP uses the opposite order from X.500. OpenSSL is using the correct (X.500) order. Just as an aside, OpenLDAP 2.1 supports X.500 DNs. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Wrong DNs
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bell Howard Chu schrieb: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bell What do you want to say with this answer? The problem has nothing to do with signature verification. If you use openssl x509 or any other openssl command then you will see a DN. The question is, why is the order (in which the DN is displayed) different from the one used for LDAP. Use X.500 the opposite order of LDAP? There is no bug, unless you consider LDAP itself a bug. Yes, LDAP uses the opposite order from X.500. OpenSSL is using the correct (X.500) order. Until now I thought X.500 uses ASN.1 encoded DNs only and LDAP supports UTF-8 too. So there is a definition in X.500 how to transform ASN.1 encoded DNs to UTF-8? The question makes no sense. ASN.1 is a specification for a transmission format, but it doesn't make detailed specifications of the semantics of the transmitted data. Both X.500 and LDAP use ASN.1 for their over-the-wire data transfers. UTF-8 is also simply a specification for the formatting of character-data, it says nothing about the semantics of strings of characters. At its core, LDAP is simply a different front-end for the X.500 information model. A DN is a name that uniquely identifies an object in the X.500 name space. Practically speaking, a DN is a DN. In pure X.500, DNs are specified to be big-endian, most-significant component listed first. An X.500 directory path follows the same convention as a Unix filesystem path in this regard. In LDAP, the convention is to display the DNs in the opposite order, but the semantic meaning of the DN is unchanged. The X.500 representation /c=us/o=foo/ou=people/cn=joe specifies the exact same object as the LDAP DN cn=joe,ou=people,o=foo,c=us The difference is purely a matter of presentation. To answer your question is there a definition of how to transform X.500 DNs to LDAP representation? the answer is yes, it's RFC 2253. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Wrong DNs
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS
Whacker
In message [EMAIL PROTECTED] on Mon, 15 Apr
2002 20:57:00 +0200, Michael Bell [EMAIL PROTECTED] said:
michael.bell we found today a big problem with the DNs which OpenSSL
michael.bell displays because our application (OpenCA) produce DNs
michael.bell which are conform to the directorystandards but OpenSSL
michael.bell interprets them in the opposite order.
michael.bell What does this mean?
If I remember correctly, X.500 subjects are usually ordered as the
inverse of the directory standards you refer to. This means that
rather than O=HU, C=DE, the order would be C=DE, O=HU.
However, with the OpenSSL application ('openssl'), which I assume is
what you've been using, the order of the RDNs entirely depends on the
order of the keys in the policy section from the configuration file.
In the example openssl.cnf, the order is contryName first, followed by
stateOrProvinceName, and so on. I'm sure that if you create a
different policy section where things are reordered the waty you want
them, you'll get the desired result.
All this, of course, said out of memory. I haven't tested anything.
All of the above is true, but I believe it would be a bad idea to go
changing
the order of everything. Certificates are specified in X.509 and are
properly
a part of the X.500 family, and the X.500 DN syntax is clearly specified.
Any software that claims to support X.509 certificates must operate using
X.500 syntax. The LDAP DN specification is backwards, and a cert with
backwards DNs could only be considered to be broken, and certainly will
not be interoperable with the vast majority of already deployed PKI.
Of course, nothing says you can't add a function to the OpenSSL library to
extract certificate DNs in LDAP format instead of X.500 format, it's just a
matter of traversing the Name in the opposite order when parsing/printing it
out. I believe this feature already was added in OpenSSL 0.9.6, so this
whole discussion has been about a non-problem...
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: Wrong DNs
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Joop On 02-04-16 10:51:31 CEST, Howard Chu wrote: In LDAP, the convention is to display the DNs in the opposite order, but the semantic meaning of the DN is unchanged. The X.500 representation /c=us/o=foo/ou=people/cn=joe specifies the exact same object as the LDAP DN cn=joe,ou=people,o=foo,c=us in other words, you mean that the X.500 presentation c=us,cn=John Doe and the LDAP presentation cn=John Doe,c=us have the exact same DER byte stream encoding? can you or anyone else prove this? :-) Remember that LDAP was originally only a front-end for ISODE, an actual X.500 directory. The ldapd spoke LDAP on one side and DAP on the other side. While the LDAP packets are BER-encoded, the DNs in those packets were in string format. In X.500 a DN is encoded as a sequence of OIDs and values, not as a sequence of strings. So of course, the answer to the question of DER-encoding is no! But it was the job of the ldapd to translate between forms. To answer your question is there a definition of how to transform X.500 DNs to LDAP representation? the answer is yes, it's RFC 2253. you mean (RFC 2253, 2.1) [...] the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence (according to 2.2), starting with the last element of the sequence and moving backwards toward the first. with backwards being the key word? seems to make sense, i wasn't aware of that before. thanks. Yes, exactly. And for the X.500 definitions, I refer you to X.501 section 9.2 Names in General : Each initial sub-sequence of the name of an object is also the name an object. The sequence of objects so identified, starting with the root and ending with the object being named, is such that each is the immediate superior of that which follows it in the sequence. And X.501 section 9.7 Distinguished Names: The distinguished name of a given object is defined as that name which consists of the sequence of the RDNs of the entry which represents the object and those of all of its superior entries (in descending order). -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Solaris bc
The last time I checked, dc is only a front-end for bc. It seems odd to me that dc can work correctly if bc is broken... -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of J.P. King Sent: Monday, March 04, 2002 8:45 AM To: [EMAIL PROTECTED] Subject: Solaris bc (Reference, I am looking at the 'failed' test given by make test, and the 'bctest' script) Hi, I do not claim to understand the cryptography, and probably most of the maths involved, but I am puzzled as to why bc being 'broken' is an issue? Not least of all since you have dc which appears to work: draco$ dc EOF AD88C418F31B3FC712D0425001D522B3AE9134FF3A98C13C1FCC1682211195406C 1A6C66C6A\ CEEC1A0EC16950233F77F1C2F2363D56DD71A36C57E0B2511FC4BA8F22D261FE2E 9356D99AF57\ 10F3817C0E05BF79C423C3F66FDF321BE8D3F18F625D91B670931C1EF25F28E489 BDA1C5422D1\ C3F6F7A1AD21585746ECC4F10A14A778AF56F08898E965E9909E965E0CB6F85B51 4150C644759\ 3BE731877B16EA07B552088FF2EA728AC5E0FF3A23EB939304519AB8B60F2C33D6 BA0945B66F0\ 4FC3CADF855448B24A9D7640BCF473Esa DCE91E7D120B983EA9A104B5A96D634DD644C37657B1C7860B45E6838999B3DCE5 A83C6\ 9209E41F413422954175A06E67FFEF6746DD652F0F48AEFECC3D8CAC13523BDAAD 3F5AF4212BD\ 8B3CD64126E1A82E190228020C05B91C8B141F1110086FC2A4C6ED631EBA129D04 BB9A19FC53D\ 3ED0E2017D60A68775B75481449sb la lb / lb * la lb % + la - p EOF 0 draco$ uname -srvmpi SunOS 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-60 Personally I would use dc in preference to bc for all scripted use anyway. I imagine that I am missing something here, of course, but it did seem worth mentioning in case I wasn't. This only came up because someone was concerned about compiling something (OpenSSH) which relied on compiling your library first. Cheers, Julian -- Julian King Computer Officer, University of Cambridge, Unix Support __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [MiNT] M68020 bn_asm
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Zidlicky On Tue, Feb 19, 2002 at 03:43:12PM -0800, Howard Chu wrote: I just checked the 68060 user manual, you're right. That means the plain 68000 code is needed on the 68060. (What a crock...) not the wordsize mul/div, probably best option for 68060 is to use the 32x32=32 instructions with 32x16 bit data. Bye Richard __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Seems like I'm getting a lot of repeated emails from this list. But anyway, I don't see how using the 32x32=32 instructions can save any steps. If you use it with 32x16 data you are still going to get a 48 bit result and lose the upper 16 bits of that. You will still need a total of 3 multiplies to recover the lost bits and get the correct answer. -- Howard __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [MiNT] M68020 bn_asm
From the overwhelming lack of response I guess no one on this list cares about Motorola 68k implementations. Just a final note in case anyone is listening. The previous file I sent works fine, passes all the tests. I noticed that my use of roxl/roxr in the bn_add_words and bn_sub_words functions was a poor choice, so this version avoids those instructions. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Zidlicky Sent: Tuesday, February 19, 2002 9:58 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [MiNT] M68020 bn_asm On Mon, Feb 18, 2002 at 11:43:56AM -0800, Howard Chu wrote: Here is a more thorough assembly implementation of bn_asm for Motorola 680x0 processors. On a 68030 the RSA/DSA test is over 4x faster than gcc -O3 code. I am releasing this version under the terms of the OpenSSL license. thanks, I will test it on linux-m68k as soon as my CPU will have a few spare cycles. One thing I have noted, you use the 64 bit variants of mul/div in many places. This will probbaly make the code much slower than gcc generated code on 68060 CPUs as they do not implemente this insns in hardware and need to emulate them in the OS. Bye Richard bn_m68k.s Description: Binary data
M68020 bn_asm
Here is a more thorough assembly implementation of bn_asm for Motorola 680x0 processors. On a 68030 the RSA/DSA test is over 4x faster than gcc -O3 code. I am releasing this version under the terms of the OpenSSL license. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support bn_m68k.s Description: Binary data
OpenSSL BigNum library
Here is a first attempt at assembly language optimization of the OpenSSL
0.9.6c crypto/bn_asm.c file for Motorola 68020-60. Some of it is written
completely by me, some of it is gcc-output that has been slightly tweaked by
me. It's still a bit rough, there are a few areas that obviously need to be
cleaned up. But it's at least 4 times faster than the original C code for
RSA private/public key stuff, which will make life with SSL much easier. I
will continue to hack on this a bit more, but I wanted to get it out quickly
so you guys can look thru it as well.
The code passed the bntest program, but it appears to have some errors still
in the DSA algorithm. Not quite sure what's going on yet.
Here's also a diff for bn_div.c along similar lines...
viola:/home/software/openssl-0.9.6c/crypto/bn diff -u bn_div.c{.O,}
--- bn_div.c.O Sun Feb 17 09:24:14 2002
+++ bn_div.cSun Feb 17 04:42:27 2002
@@ -139,7 +139,7 @@
*
* [EMAIL PROTECTED]
*/
-# define bn_div_words(n0,n1,d0) \
+# define bn_div_words(n0,n1,d0) \
({ asm volatile ( \
divl %4 \
: =a(q), =d(rem)\
@@ -147,7 +147,22 @@
: cc);\
q; \
})
-# define REMAINDER_IS_ALREADY_CALCULATED
+# define REMAINDER_IS_ALREADY_CALCULATED
+# elif defined(__mc68020__)
+ /* Same rationale as for i386. On the 68020-60/CPU32 the divu
+* instruction will take a 64 bit dividend in a register pair
+* and overwrite that pair with the remainder:quotient.
+* [EMAIL PROTECTED]
+*/
+# define bn_div_words(n0,n1,d0) \
+ ({ asm volatile ( \
+ divu.l %4,%2:%3 \
+ : =d(rem), =d(q)\
+ : 0(n0), 1(n1), d(d0) \
+ : cc);\
+ q; \
+ })
+# define REMAINDER_IS_ALREADY_CALCULATED
# endif /* __cpu */
# endif /* __GNUC__ */
#endif /* NO_ASM */
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
bn_m68k.s
Description: Binary data
compiler optimizations
Speaking of optimizations - Does anyone have a Motorola 68020 version of bn_asm? I used to have one I wrote for SSLeay 0.8.0 but that seems to have vanished from my hard drive. (Read - I deleted it without thinking, when I downloaded the OpenSSL 0.9.6 sources...) It would be nice not to have to recreate it, but I will if no one else has one. My web client with 0.9.6 is now too slow, it cannot finish generating a key before the remote server times out the connection. (Speed tests on 0.8.0 vs 0.9.6 are 2-3x faster, which makes a big difference on my 32MHz 68030.) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stephen Sprunk Sent: Thursday, February 14, 2002 1:59 PM To: [EMAIL PROTECTED] Subject: Re: Pentium Pro compiler optimizations Thus spake Tim Rice: Has anyone been sucessfull using Pentium Pro compiler optimizations on UnixWare or OpenUNIX ? It builds but the md2test fails. All works fine without the -Kpentium_pro (-Kp6 on UW 2.1.x) flag. I see this problem on UnixWare 2.1.3 and OpenUNIX 8.0.0 My UnixWare 7.1.1 box runs a pentium so I can't test it there. I'm suspecting a compiler problem like on UnixWare 2.0x where it fails destest when -O is used. It sounds like your cc has a nasty bug; why not use gcc? I regularly use gcc -O3 -march=pentiumpro -fschedule-insns2; there is currently a bug when you mix -fschedule-insns (not 2) with -O2 or above. This is at least 10% faster than the default -mcpu=pentium that OpenSSL uses on my box. S -- Stephen Sprunk So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSSalways said exactly what pleased me. --Albert Einstein __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: DES changes...
Going back to Ben's original message and the start of this thread, it's not entirely clear what the actual problem was. But it is a fact that static symbols cannot cause linker clashes. Given this fact, and Ben's mention of functions that are declared in certain broken header files, one can only guess that the clashes are at compile-time, due to mismatched function declarations between various header files and the library source. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker From: Jeffrey Altman [EMAIL PROTECTED] jaltman ben The ones I was referring to actually are static. jaltman jaltman Then they should not be a problem, and definitely not a source of jaltman clashing, should they? jaltman jaltman jaltman They are a problem because 'static' has no meaning to the linker. jaltman They are functions in a library and if two libraries have overlapping jaltman names spaces there will be problems. Yeah, but look again at what Ben writes. That's what I'm questioning, because if they were really static (as in defined with the key word static), we wouldn't have a problem, so that statement can't be true. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Shared libraries on AIX...
Not exactly. ld on AIX 4.2+ has the -bexpall flag to export everything, but this flag does bad things on shared libraries, and should only be used on executables. I sent you patches for AIX before. These are the rules I use in our Makefile. They work on all platforms: $(SHRCRYPTO): lib/$(LIBCRYPTO).a ld -r -o $(LIBCRYPTO).o $(ALLSYMSFLAG) lib/$(LIBCRYPTO).a -nm -Pg $(LIBCRYPTO).o | grep ' [BD] ' | cut -f1 -d' ' $(LIBCRYPTO).exp $(CC) $(SHAREDFLAG) -o $@ $(LIBCRYPTO).o $(SHRSSL): lib/$(LIBSSL).a $(SHRCRYPTO) ld -r -o $(LIBSSL).o $(ALLSYMSFLAG) lib/$(LIBSSL).a -nm -Pg $(LIBSSL).o | grep ' [BD] ' | cut -f1 -d' ' $(LIBSSL).exp $(CC) $(SHAREDFLAG) -o $@ $(LIBSSL).o $(SHRCRYPTO) The ALLSYMSFLAG is -bnogc for AIX, which turns off garbage collection and bypasses the step where the linker removes unreferenced objects. For Linux the flag is -whole-archive, for Solaris -z allextract. Obviously the contents of lib/$(LIBXX).a is assumed to be PIC code. I haven't configured this on any other platforms recently, so I don't have the corresponding flags, but it shouldn't be hard to find them. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Friday, April 27, 2001 8:11 AM To: [EMAIL PROTECTED] Subject: Shared libraries on AIX... I'm looking a bit at building shared libraries on AIX, and would like to know if there is a way at all to just tell ld to extract everything from a static library (libcrypto.a), put it in a shared library (libcrypto.a) and export all available global symbols? I know it's possible to create an exported symbols file (libcrypto.exp?) and use that, but I'd like to avoid that if possible, it feels like a very unneeded step, and full of possibilities to make a fool out of yourself (by forgetting). On all other Unixen I've played with, there's the possibility to do what I want to do (hence the diverse do_*-shared targets in Makefile.org), and I just can't believe such a thing wouldn't be possible on AIX... Then perhaps, I'm just too optimistic... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Shared libraries on AIX...
That's right. I actually used: '-bM:SRE -bE:$*.exp -b noentry' I had to add explicit code to the Configure script to set this since I couldn't figure out how to embed colons in the configuration table. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] Sent: Friday, April 27, 2001 2:20 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Shared libraries on AIX... From: Howard Chu [EMAIL PROTECTED] hyc $(SHRSSL): lib/$(LIBSSL).a $(SHRCRYPTO) hyc ld -r -o $(LIBSSL).o $(ALLSYMSFLAG) lib/$(LIBSSL).a hyc -nm -Pg $(LIBSSL).o | grep ' [BD] ' | cut -f1 -d' ' $(LIBSSL).exp hyc $(CC) $(SHAREDFLAG) -o $@ $(LIBSSL).o $(SHRCRYPTO) hyc hyc The ALLSYMSFLAG is -bnogc for AIX, which turns off garbage collection hyc and bypasses the step where the linker removes unreferenced objects. For I assume that for AIX, SHAREDFLAG would be something like -bE:$(LIBSS).exp -bM:SRE, except a lttle bit more generalised, right? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [ANNOUNCEMENT] OpenSSL 0.9.6a Beta 1 released
libdl didn't appear on AIX until 4.2. Jens Uwe-Mager wrote an emulation library for earlier AIX versions, to map the dlopen routines onto AIX's native dynamic loading implementation. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of lgazis Sent: Wednesday, March 14, 2001 7:49 AM To: 'Richard Levitte - VMS Whacker'; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [ANNOUNCEMENT] OpenSSL 0.9.6a Beta 1 released On AIX 4.3, no, I didn't have to add -ldl. I did need to add it on Linux 2.2.17 (to src/Makefile under apache_1.3.19), and we've also had to add it in the past on Solaris. I'm not sure about dl*() and older AIX versions. Lynn Gazis -Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 14, 2001 4:20 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [ANNOUNCEMENT] OpenSSL 0.9.6a Beta 1 released From: lgazis [EMAIL PROTECTED] lgazis OpenSSL 0.9.6a Beta 1 test on AIX 4.3, using engine version: lgazis lgazis This requires two modifications to make it work: -DDSO_DLFCN -DHAVE_DLFCN_H Doesn't that also require linking with -ldl? Also, is dl*() implemented on older AIX versions? -- Richard Levitte \ Spannvgen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: stdout problem on NT only - our fix
This sounds like a problem I've run into before. Remember that a FILE *
structure uses memory malloc'd from a heap, and that Windows DLLs have their
own heaps, distinct from the main app. As such, you cannot set up a pointer
in one space and then use it with malloc/realloc in the other space. Also,
you cannot statically initialize a pointer with "FILE *blah = stdout;"
because "stdout" is not a simple constant; it's value can only be set at
runtime since it is an import from the C runtime DLL. The reason that you
see two different addresses right now is that the value you see is really
the address of an address, one is a pointer to stdout living in the DLL's
space, and the other is a pointer to stdout residing in app space. Assuming
that you have properly #include'd stdio.h the compiler should have
generated the proper code to reference the imported value.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Paul Kudlawiec
Sent: Thursday, November 09, 2000 10:30 AM
To: ZZ) LISTSERV: Openssl-Dev (E-mail)
Subject: stdout problem on NT only - our fix
We discovered a problem running openssl with our application on
WinNT4.0 and
using Visual C++ 6.0.
When we run our application, it makes a call to SSL_write, then an access
violation occurs executing fwrite within the function file_write
of openSSL.
Upon closer inspection, we found the culprit to be stdout. From within our
application, while initializing openSSL, b-ptr (b is type BIO) is set to
stdout. Just before the crash within openSSL, b-ptr is still pointing to
that
address; however, if a variable is set within openSSL to stdout, that
variable
points to a different address.
In other words: If a variable is set to stdout in our application, and a
variable is set to stdout within openSSL, the two point to different
addresses
in NT--in Unix, both point to the same address. In NT, if an
attempt is made
to
use the stdout address set in the calling from application within
openSSL, a
crash occurs.
An earlier message on the listserv indicated a similar problem (see "App
crash
on NT"); the solution suggested using the multithreaded dll version of the
run-time libraries. We verified that the correct libraries are
indeed being
used. Someone else suggested that the library containing the standard
implentation for a console app was missing; we verified that it
was included
within our application as well as openssl.
The solution we developed is to create a function within openssl
that simply
returns the pointer to stdout. This way, the pointer to stdout is
correct in
whatever environment it resides. Our application can then use this to set
b-ptr to the correct address of stdout.
We made the following changes to the NT version:
1) Within
openssl-0.9.4\inc32\openssl\ssl.h
openssl-0.9.4\ssl\ssl.h
the following prototype was added:
FILE *SSLGetSSLstdout(void);
2) Within
openssl-0.9.4\ssl\ssl_lib.c
the following function was added:
FILE *SSLGetSSLstdout(void)
{
return (stdout);
}
3) Within
openssl-0.9.4\ms\ssleay32.def
the following line was added under "EXPORTS":
SSLGetSSLstdout
If we are missing something, please let us know. Thanks!
Paul Kudlawiec
Software Engineer
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: Loading shared libraries under HP-UX on PA32
It's been a long time since I've worked on HPUX, but I recall that the shl* routines support the SHLIB_PATH environment variable, completely analogous to LD_LIBRARY_PATH. I don't see why anyone should be having a problem here. Someone with access to a machine and manpages should of course correct me if I'm misremembering. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Monday, November 06, 2000 11:52 PM To: [EMAIL PROTECTED] Subject: Loading shared libraries under HP-UX on PA32 I've had reports that it seems like shl_load() only loads a file from the current directory if the file given is something like "libcswift.sl". In the man page, the parameter is called "path", so I wouldn't be too surprised if the observation is correct as defined by the implementors of shl_load() or if there's a way for it to look along a path of directories, like dlopen() does. The man pages I've read are unfortunately not completely clear in this matter, so if someone with HP-UX experience could tell me what the story really is, I'd be grateful. Of course, the option is to move everything HP-UX-related to use dl*() instead of shl*() and we'd get rid of the problem (since dlopen() uses LD_LIBRARY_PATH), but that would mean throwing away all DSO support for HP-UX 10.20, and I wonder if we really want to do that... Another option is to implement support for something like LD_LIBRARY_PATH in the DSO code that uses shl_load(). Comments? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: problems with `configure`..
This question probably belongs more in openssl-users, not openssl-dev. More likely, it belongs in [EMAIL PROTECTED] But since I'm on all of these lists anyway, I'll answer here: The Solaris compiler and linker don't know to look in /usr/local/ssl, so you have to tell them explicitly to do so before running openldap's configure script. You do this by setting the CPPFLAGS and LDFLAGS environment variables before running configure: setenv CPPFLAGS -I/usr/local/ssl/include setenv LDFLAGS -L/usr/local/ssl/lib (I use tcsh, thus the setenv commands. For Bourne shell and similar, use the appropriate assignments instead: CPPFLAGS=-I/usr/local/ssl/include; export CPPFLAGS LDFLAGS=-L/usr/local/ssl/lib; export LDFLAGS -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of g. labe Sent: Tuesday, November 07, 2000 2:10 AM Subject: problems with `configure`.. hello. i hope you'd like to help me.. 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 got the following error: [...] checking for openssl/ssl.h... no checking for ssl.h... no configure: warning: Could not locate TLS/SSL package configure: warning: TLS privacy protection not supported! [...] seems like openssl is not installed properly - what should i do to make openldap able to locate it? thanks in advance for any help, gl ps. sorry for my poor english.. -- B Grzegorz Labe yATtech.us.edu.pl O F Centrum Techniki Obliczeniowej Uniwersytetu Slaskiego H FYI: I work for CTO US, but speak for myself. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[PATCH] apps/ca.c
Here are the diffs I mentioned in an earlier email. To recap:
adds the -notext option to the usage info
adds the -nodb option to avoid recording the cert in the database
adds the -mins option to specify cert expiration in minutes
adds the -find DN option to printthe pathname of a cert matching
the given DN
patched to store the actual cert filename in the index.txt database
Howard Chu - Black GTS http://highlandsun.com
http://people.we.mediaone.net/hyc
--- ca.c2000/10/13 12:53:02 1.1
+++ ca.c2000/10/13 13:01:41
@@ -150,6 +150,7 @@
" -startdate YYMMDDHHMMSSZ - certificate validity notBefore\n",
" -enddate YYMMDDHHMMSSZ- certificate validity notAfter (overrides -days)\n",
" -days arg - number of days to certify the certificate for\n",
+" -mins arg - number of minutes to certify the certificate for\n",
" -md arg - md to use, one of md2, md5, sha or sha1\n",
" -policy arg - The CA 'policy' to support\n",
" -keyfile arg- PEM private key file\n",
@@ -163,10 +164,13 @@
" -ss_cert file - File contains a self signed cert to sign\n",
" -preserveDN - Don't re-order the DN\n",
" -batch - Don't ask questions\n",
+" -notext - Don't output decoded cert\n",
+" -nodb - Don't record cert in database\n",
" -msie_hack - msie modifications to handle all those universal strings\n",
" -revoke file- Revoke a certificate (given in file)\n",
" -extensions .. - Extension section (override value in config file)\n",
" -crlexts .. - CRL extension section (override value in config file)\n",
+" -find DN- Output filename where cert for DN is stored\n",
NULL
};
@@ -186,26 +190,28 @@
static int save_serial(char *serialfile, BIGNUM *serial);
static int certify(X509 **xret, char *infile,EVP_PKEY *pkey,X509 *x509,
const EVP_MD *dgst,STACK_OF(CONF_VALUE) *policy,TXT_DB *db,
- BIGNUM *serial, char *startdate,char *enddate, int days,
- int batch, char *ext_sect, LHASH *conf,int verbose);
+ BIGNUM *serial, char *startdate,char *enddate, int mins,
+ int batch, char *ext_sect, LHASH *conf,int verbose,
+ int nodb);
static int certify_cert(X509 **xret, char *infile,EVP_PKEY *pkey,X509 *x509,
const EVP_MD *dgst,STACK_OF(CONF_VALUE) *policy,
TXT_DB *db, BIGNUM *serial,char *startdate,
- char *enddate, int days, int batch, char *ext_sect,
- LHASH *conf,int verbose);
+ char *enddate, int mins, int batch, char *ext_sect,
+ LHASH *conf,int verbose,int nodb);
static int certify_spkac(X509 **xret, char *infile,EVP_PKEY *pkey,X509 *x509,
const EVP_MD *dgst,STACK_OF(CONF_VALUE) *policy,
TXT_DB *db, BIGNUM *serial,char *startdate,
-char *enddate, int days, char *ext_sect,LHASH *conf,
- int verbose);
+char *enddate, int mins, char *ext_sect,LHASH *conf,
+ int verbose,int nodb);
static int fix_data(int nid, int *type);
static void write_new_certificate(BIO *bp, X509 *x, int output_der, int notext);
static int do_body(X509 **xret, EVP_PKEY *pkey, X509 *x509, const EVP_MD *dgst,
STACK_OF(CONF_VALUE) *policy, TXT_DB *db, BIGNUM *serial,
- char *startdate, char *enddate, int days, int batch, int verbose,
- X509_REQ *req, char *ext_sect, LHASH *conf);
+ char *startdate, char *enddate, int mins, int batch, int verbose,
+ int nodb, X509_REQ *req, char *ext_sect, LHASH *conf);
static int do_revoke(X509 *x509, TXT_DB *db);
static int check_time_format(char *str);
+static char *serial_name(char *buf, ASN1_INTEGER *serial);
static LHASH *conf=NULL;
static char *section=NULL;
@@ -236,6 +242,7 @@
char *infile=NULL;
char *spkac_file=NULL;
char *ss_cert_file=NULL;
+ char *find=NULL;
EVP_PKEY *pkey=NULL;
int output_der = 0;
char *outfile=NULL;
@@ -246,9 +253,10 @@
BIGNUM *serial=NULL;
char *startdate=NULL;
char *enddate=NULL;
- int days=0;
+ int mins=0;
int batch=0;
int notext=0;
+ int nodb=0;
X509 *x509=NULL;
X509 *x=NULL;
BIO *in=NULL,*out=NULL,*Sout=NULL,*Cout=NULL;
@@ -316,7 +324,13 @@
else if (strcmp(*argv,"-days") == 0)
{
if (--argc 1) goto bad;
- days=atoi(
RE: more on ranlib
From: Ben Laurie [EMAIL PROTECTED] ben GNU archives it is an optional extra, so failure to do it doesn't really ben hurt. Only problem with that is that we can't really assume we're in a GNU environment... Yes, the best approach was already suggested: do a single ranlib command in the superior makefile, after all the subdirectories have completed. Best is to also use a timestamp file to control when ranlib must be performed: libxxx.a: (whatever rules...) stamp-libxxx.a: libxxx.a $(RANLIB) $? touch $@ all: stamp-libxxx.a -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ca.c patches
I have a couple patches to ca.c that I'd like to contribute back: added a "serial_name" function that's called to generate the serialnumber.pem string. Use this to insert an actual filename in the index.txt file, as well as in the two other places (certify and revoke) where a serial number is referenced. added a "-notext" option for omitting the interpreted text of a generated cert. added a "-mins arg" option for specifying expiration in minutes from now. added a "-nodb" option to omit recording the cert in the database. (the above two options are used together for generating shortlived certs, which we use much like Kerberos tickets.) added a "-find DN" option for printing the pathname of the cert matching the given DN. (which relies on an actual valid filename living in index.txt) On a separate note, we developed a generic "make all-shared" target in the 0.9.4 configure/makefile setup, with support for Solaris and AIX. I see that some rudimentary shared library support is now present in 0.9.6, but it's not very generic yet. Anyone else still working on streamlining this? What's the story on converting the autoconf/ automake and such? How about using libtool for the build process? -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: more on ranlib
On most modern Unix systems the ranlib step is already integrated into ar. I'd guess that only a genuine 4.[23]BSD or SVR1 system would actually need an explicit ranlib. Another approach is to use an overrideable RANLIB macro like so: RANLIB=ranlib libxxx.a: a.o b.o c.o ar r $@ $?; $(RANLIB) $@ On systems that don't need it, invoke make with RANLIB=: and the shell will ignore it. (Combine the ar and ranlib commands one one line, as above, to avoid an unnecessary additional spawn of sh for the possibly unneeded ranlib invocation...) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gary Feldman Sent: Wednesday, October 11, 2000 6:49 AM To: [EMAIL PROTECTED] Subject: RE: more on ranlib In the For What It is Worth department: On Solaris 2.7, at least, /usr/ccs/bin/ranlib is a shell script that just does an exit. While firing up a shell script is not zero overhead, it's still less than a real ranlib pass on a large library. Ideally, this would be the situation on all platforms, i.e. if ranlib is unnecessary, then either it doesn't exist or is bound to a trivial script or program. Of course, one can't assume the ideal situation. Gary Ready-to-Run Software, Inc. Software Porting Specialists. * email: [EMAIL PROTECTED] Gary Feldman fax : 1-978-692-5401 Ready-to-Run Software, Inc. voice: 1-978-251-5431 11 School Street www : http://www.rtr.com North Chelmsford, MA 01863 USA __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Shared library problems with cyrus-sasl-1.5.24
[mailto:[EMAIL PROTECTED]]On Behalf Of Lawrence Greenfield this solves the work problem, but does it in a very inefficient manner. At least on Solaris, this will create a new, process-private, copy of libcrypto.a for every process that dynamical loads libdigestmd5.so. Am I missing something here? I would have thought that linking to create a new .so file, using an existing .a file as one of the inputs would copy all of the relevant units into the .so file, so that ever process that dynamically loads the .so file would share the .so file, and thus share the included libcrypto.a. Is there something that prevents the libcrypto.a code from being shared in this context? (Granted, it's not being shared as much as a fully shared libcrypto.so would be.) Gary You're both correct. Since libcrypto.a was not compiled as PIC, it cannot be shared very much. The library will have static absolute address references that will be relocated at runtime, forcing page copies for every relocated reference. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [STATUS] OpenSSL (Sun 7-May-2000)
I have a number of patches against 0.9.4 supporting shared libraries on AIX, Solaris, and NT. I plan to sync up with 0.9.5a and/or 0.9.6 in the next couple days. Let me know if you're interested in seeing the diffs. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of OpenSSL Project Sent: Sunday, May 07, 2000 11:15 AM To: [EMAIL PROTECTED] Subject: [STATUS] OpenSSL (Sun 7-May-2000) OpenSSL STATUS Last modified at __ $Date: 2000/04/14 23:35:50 $ DEVELOPMENT STATE o OpenSSL 0.9.6: Under development... o OpenSSL 0.9.5a: Released on April 1st, 2000 o OpenSSL 0.9.5: Released on February 28th, 2000 o OpenSSL 0.9.4: Released on August 09th, 1999 o OpenSSL 0.9.3a: Released on May 29th, 1999 o OpenSSL 0.9.3: Released on May 25th, 1999 o OpenSSL 0.9.2b: Released on March22th, 1999 o OpenSSL 0.9.1c: Released on December 23th, 1998 RELEASE SHOWSTOPPERS AVAILABLE PATCHES o CA.pl patch (Damien Miller) IN PROGRESS o Steve is currently working on (in no particular order): Proper (or at least usable) certificate chain verification. Private key, certificate and CRL API and implementation. Developing and bugfixing PKCS#7 (S/MIME code). Various X509 issues: character sets, certificate request extensions. Documentation for the openssl utility. NEEDS PATCH o non-blocking socket on AIX o $(PERL) in */Makefile.ssl o "Sign the certificate?" - "n" creates empty certificate file OPEN ISSUES o internal_verify doesn't know about X509.v3 (basicConstraints CA flag ...) o The Makefile hierarchy and build mechanism is still not a round thing: 1. The config vs. Configure scripts It's the same nasty situation as for Apache with APACI vs. src/Configure. It confuses. Suggestion: Merge Configure and config into a single configure script with a Autoconf style interface ;-) and remove Configure and config. Or even let us use GNU Autoconf itself. Then we can avoid a lot of those platform checks which are currently in Configure. o Support for Shared Libraries has to be added at least for the major Unix platforms. The details we can rip from the stuff Ralf has done for the Apache src/Configure script. Ben wants the solution to be really simple. Status: Ralf will look how we can easily incorporate the compiler PIC and linker DSO flags from Apache into the OpenSSL Configure script. Ulf: +1 for using GNU autoconf and libtool (but not automake, which apparently is not flexible enough to generate libcrypto) o The perl/ stuff needs a major overhaul. Currently it's totally obsolete. Either we clean it up and enhance it to be up-to-date with the C code or we also could replace it with the really nice Net::SSLeay package we can find under http://www.neuronio.pt/SSLeay.pm.html. Ralf uses this package for a longer time and it works fine and is a nice Perl module. Best would be to convince the author to work for the OpenSSL project and create a Net::OpenSSL or Crypt::OpenSSL package out of it and maintains it for us. Status: Ralf thinks we should both contact the author of Net::SSLeay and look how much effort it is to bring Eric's perl/ stuff up to date. Paul +1 o The EVP and ASN1 stuff is a mess. Currently you have one EVP_CIPHER structure for each cipher. This may make sense for things like DES but for variable length ciphers like RC2 and RC4 it is NBG. Need a way to use the EVP interface and set up the cipher parameters. The ASN1 stuff is also foo wrt ciphers whose AlgorithmIdentifier has more than just an IV in it (e.g. RC2, RC5). This also means that EVP_Seal and EVP_Open don't work unless the key length matches the fixed value (some vendors use a key length decided by the size of the RSA encrypted key and expect RC2 to adapt). WISHES o __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project
RE: [STATUS] OpenSSL (Sun 16-Apr-2000)
So how many of these items are actually being worked on at the moment? A lot of them have been on the list for several months now, with no apparent change in status. I've been struggling with getting 0.9.4 to produce shared libraries on AIX and it would make my life a lot easier if this package used autoconf and libtool. I've started converting it myself already because the current build setup is so awkward. While I'm using perl anyway for other parts of my project, it's really inconvenient that this package requires perl for configuration. re: things that don't seem to have moved - what exactly is Steve intending to improve in the certificate chain verification? How will it affect current functionality? -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of OpenSSL Project Sent: Sunday, April 16, 2000 11:15 AM To: [EMAIL PROTECTED] Subject: [STATUS] OpenSSL (Sun 16-Apr-2000) OpenSSL STATUS Last modified at __ $Date: 2000/04/14 23:35:50 $ DEVELOPMENT STATE o OpenSSL 0.9.6: Under development... o OpenSSL 0.9.5a: Released on April 1st, 2000 o OpenSSL 0.9.5: Released on February 28th, 2000 o OpenSSL 0.9.4: Released on August 09th, 1999 o OpenSSL 0.9.3a: Released on May 29th, 1999 o OpenSSL 0.9.3: Released on May 25th, 1999 o OpenSSL 0.9.2b: Released on March22th, 1999 o OpenSSL 0.9.1c: Released on December 23th, 1998 RELEASE SHOWSTOPPERS AVAILABLE PATCHES o CA.pl patch (Damien Miller) IN PROGRESS o Steve is currently working on (in no particular order): Proper (or at least usable) certificate chain verification. Private key, certificate and CRL API and implementation. Developing and bugfixing PKCS#7 (S/MIME code). Various X509 issues: character sets, certificate request extensions. Documentation for the openssl utility. NEEDS PATCH o non-blocking socket on AIX o $(PERL) in */Makefile.ssl o "Sign the certificate?" - "n" creates empty certificate file OPEN ISSUES o internal_verify doesn't know about X509.v3 (basicConstraints CA flag ...) o The Makefile hierarchy and build mechanism is still not a round thing: 1. The config vs. Configure scripts It's the same nasty situation as for Apache with APACI vs. src/Configure. It confuses. Suggestion: Merge Configure and config into a single configure script with a Autoconf style interface ;-) and remove Configure and config. Or even let us use GNU Autoconf itself. Then we can avoid a lot of those platform checks which are currently in Configure. o Support for Shared Libraries has to be added at least for the major Unix platforms. The details we can rip from the stuff Ralf has done for the Apache src/Configure script. Ben wants the solution to be really simple. Status: Ralf will look how we can easily incorporate the compiler PIC and linker DSO flags from Apache into the OpenSSL Configure script. Ulf: +1 for using GNU autoconf and libtool (but not automake, which apparently is not flexible enough to generate libcrypto) o The perl/ stuff needs a major overhaul. Currently it's totally obsolete. Either we clean it up and enhance it to be up-to-date with the C code or we also could replace it with the really nice Net::SSLeay package we can find under http://www.neuronio.pt/SSLeay.pm.html. Ralf uses this package for a longer time and it works fine and is a nice Perl module. Best would be to convince the author to work for the OpenSSL project and create a Net::OpenSSL or Crypt::OpenSSL package out of it and maintains it for us. Status: Ralf thinks we should both contact the author of Net::SSLeay and look how much effort it is to bring Eric's perl/ stuff up to date. Paul +1 o The EVP and ASN1 stuff is a mess. Currently you have one EVP_CIPHER structure for each cipher. This may make sense for things like DES but for variable length ciphers like RC2 and RC4 it is NBG. Need a way to use the EVP interface and set up the cipher parameters. The ASN1 stuff is also foo wrt ciphers whose AlgorithmIdentifier has more than just an IV in it (e.g. RC2, RC5). This also means that EVP_Seal and EVP_Open don't work unless the key length matches the fixed value (some vendors use
RE: the API to load X509 from char*
Yes, it's quite easy. This works for me in 0.9.4: (char *buf; int len; values should already be set) ... BIO *bi = BIO_new(BIO_s_mem()); BUF_MEM bf; X509 *x; bf.length = len; bf.data = buf; bf.max = bf.length; BIO_set_mem_buf(bi, bf, 0); x = PEM_read_bio_X509(bi, NULL, NULL, NULL); -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of hazel Gao Sent: Wednesday, April 05, 2000 8:16 PM To: [EMAIL PROTECTED] Subject: Re: the API to load X509 from char* I'm using openssl-0.9.4 at present. Are any similiar APIs in openssl-0.9.4, or do I have to upgrade to openssl-0.9.5? Hazel They aren't for files they are for fps and BIOs which aren't necessarily files. BIOs in particular can point to all manner of things including a memory buffer. For example in OpenSSL 0.9.5 and later you can call: bio = BIO_new_mem_buf(buffer, length); and then call PEM_read_bio_X509() on it. Steve. -- __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: the API to load X509 from char*
-Original Message- From: [EMAIL PROTECTED] Howard Chu wrote: Yes, it's quite easy. This works for me in 0.9.4: (char *buf; int len; values should already be set) ... BIO *bi = BIO_new(BIO_s_mem()); BUF_MEM bf; X509 *x; bf.length = len; bf.data = buf; bf.max = bf.length; BIO_set_mem_buf(bi, bf, 0); x = PEM_read_bio_X509(bi, NULL, NULL, NULL); Yes that will work. However you should also do BIO_set_close(bi, BIO_NOCLOSE); otherwise it will try to Free() the buffer when you do BIO_free(bi); Steve. Not true - the 3rd argument to BIO_set_mem_buf already takes care of this concern. I wouldn't have said "this works for me" if it in fact was crashing on me, and a Free problem like you describe would make itself known pretty quickly. (I left it out of the above example, but I do call BIO_free(bi) immediately after the PEM_read... Sorry for omitting that detail.) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
socket I/O and EOF
There appears to be a problem with OpenSSL when used with non-blocking I/O on Linux. (Running SuSE 6.0, Linux kernel 2.2.5.) A similar situation seems to be happening on NT as well. The code doesn't seem to detect that a socket has been closed by the remote end. Read loops tend to execute a huge number of times in this case, always returning 0 bytes of data. I haven't figured out how/why the loop ever terminates, but in normal situations, it eventually does. In one case in particular in the OpenLDAP slapd (developer snapshot) if a session is just being started, and SSL_accept fails, slapd will loop forever, retrying the SSL_accept. (This assumes the slapd is configured to require a user certificate. The error can be reproduced by using a client without a user certificate to connect to the slapd.) In slapd the I/O loop is structured around a select(). As you know, select will return "readable" for a socket that was closed, and a read on this socket will return 0 bytes to indicate EOF. Unfortunately, it appears that the SSL library doesn't do anything special when a read returns 0 bytes. In particular, the SSL session handle's rwstate variable remains set to SSL_READING in this case, and the upper levels treat this as "a read was incomplete and should be retried." Of course, none of the retries will ever succeed, and so you have a fine infinite loop. This message is going to both the OpenSSL and the OpenLDAP crew because I haven't figured out yet who's doing the wrong thing. This infinite loop may be caused by the ldap_pvt_tls_accept that we wrap around SSL_accept. The large number of loops even in the successful case seems to be a more general problem. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
socket I/O, EOF, openssl 0.9.4
Following up on my previous email... This patch to ssl23_read_bytes() seems to fix my problem with bogus clients hosing SSL_accept(): --- s23_pkt.c 1999/12/08 17:20:56 1.1.1.1 +++ s23_pkt.c 2000/01/14 19:58:16 @@ -104,9 +104,9 @@ s-rwstate=SSL_READING; j=BIO_read(s-rbio,(char *)(p[s-packet_length]), n-s-packet_length); + s-rwstate=SSL_NOTHING; if (j = 0) return(j); - s-rwstate=SSL_NOTHING; s-packet_length+=j; if (s-packet_length = (unsigned int)n) return(s-packet_length); It strikes me that if BIO_read returns =0, something irrecoverably bad has happened, and there's no point in coming back to try again later. Currently the code in slapd that invokes SSL_accept has a test if (!SSL_want_nothing(ssl)) to decide if the accept should be retried. This works in the normal case, when all the data for the transaction arrives in multiple chunks and can't be read all at once. But without the above patch, it causes the accept to be retried forever on a bogus connection. Perhaps this is the wrong approach, but there doesn't seem to be any obvious way to distinguish "we're OK, just in the middle of a long transaction" from "we're hosed, this connection is invalid" in the SSL_accept return status. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
