We're making the jump from OpenSSL 0.9.8d to 0.9.8l. I noticed
while buiding L (and K for that matter) that HP complains when the
Configure option 'threads' is specified but no system-specific compiler
options were specified. 0.9.8d does not complain this way. I removed
the 'threads'
UTF-8 *IS* perfectly valid Unicode -- it's one of the main Unicode
encodings, and seems entirely appropriate for use in certs, although I
personally have no knowledge of the support in OpenSSL or the X509
standard. UTF-8 is a variable length encoding where the valid UTF-8
characters are from 1 to
hello OpenSSL community.We use OpenSSL 0.9.8d on many platforms,
including z/Linux 64-bit. We are using client certificate
authentication at the server.
When any client that is NOT the same architecture -- i.e. NOT z/Linux
64-bit -- the server complains during SSL_accept() processing the
In our server application we removed all fork()/exec() from
our server once we started using openSSL.At that time, we were using
fork/exec on some platforms, pthreads on others. We swapped the forking
platforms over to use pthreads were very reliable results.
I believe we saw this symptom:
There are many special considerations. The OS/400 operating system is a
decent modern OS and is being enhanced actively. For smaller shops who
had System/36 and 38, AS400 is a logical new generation environment.
We were faced with this same challenge recently. There is no port of the
OpenSSL
I found my own answer, so here it is to get it into the archive to help
the next person who comes across it.
The new type SHA_LONG64 which is defined in sha.h, uses the native
'unsigned long long' in z/OS, and most other platforms probably (NOT
Windows). In the case of the z/OS, the c89 command
Hi all:0.9.8c is only a few days old.I'm trying to build it for
the configure target OS390-Unix, and I'm getting the following compile
error for sha_dgst.c
c89.sh -I.. -I../.. -I../../include -D_LONGMAP -Wc,dll,expo -O
-DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE -c -o
I'm not sure about 0.9.8 yet, but 0.9.7d works well on the
x86_64 platforms.we use no_asm no_idea no_rc5 threads
shared. what exactly is the failure?
Dave McLellan --Consulting Software
Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748
Our experience is successful using TCP_NODELAY with OpenSSL in our
client/server application.
Dave McLellan - Consulting Software Engineer
Storage Platforms, Enablers, and Applications
EMC Corporation
228 South St.
Hopkinton MA 01748
phone: 508-249-1257
fax 508-497-8030
-Original
You can you OpenSSL with IPv6 freely. We
are driving OpenSSL sessions across IPv6 networks with no trouble, AS LONG
AS you do not use BIOs for looking up host names and IP addresses.Based onmy
own experience, you should do your own lookups and make the connections,
then call SSL_set_fd() to
Hi: we're looking at our options for using OpenSSL in the IBM iSeries (AKA
AS400) environment. We already run on a bunch of *nix, Win, and z/OS hosts,
and we are being asked about support for some of our second tier OS's.
Is there anyone who knows of any work being done porting OpenSSL to the
You should take the
OpenSSL tar file for the version you want. All the materials you
need are there. once you un-tar, you should use the
command./Confgure OS390-Unix, and then make. I would recommend Perl
5.6.1, and you need GNU make.
Dave McLellan --Consulting Software Engineer - SPEA
Title: OS/390
We are using OpenSSL 0.9.7d in our product on
z/OS.when I last built and ran the tests, I believe tests ran
successfully, but I might not be remembering properly. z/OS was a
last platformforOpenSSL exploitation, so we had a decent test
program in our server application.
Shall
13 matches
Mail list logo
