We're making test on DUnix Tru 64 and we had problem with this library:
make test result:
test BN_sqr
Square test failed!
Our op. sys is: OSF1 link.softax.local V5.1 732 alpha
our compiler is:
Compaq C V6.3-025 on Compaq Tru64 UNIX V5.1 (Rev. 732)
I failed to reproduce the problem with
It turned to be a GCC compiler bug. Basically it's the compiler that
needs to be fixed, but a workaround is merged into HEAD and
OpenSSL_0_9_7-stable branches. The ticket is therefore resolved. A.
__
OpenSSL Project
User has increased optimization level beyond -O2 suggested/recommended
by ./Configure and ran into a compiler bug. As it's not self-obvious
that -O3 signifantly improves performance (OpenSSL has a lot of
source-code optimizations, -O2 is more than sufficient), the case is
therefore dismissed as
User couldn't have been honest with us. There is/was *working*
solaris64-sparcv9-gcc config line. Instead he must have modified
solaris-sparcv9-gcc line replacing -m32 with -m64 and hoping for the
best. The case is dismissed. A.
Do post output from 'apps/openssl version -a' or case will be dismissed
as RTFM. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
OpenSSL version: 0.9.7-beta6-dev
Last change: In asn1_d2i_read_bio() repeatedly call BIO_read() until...
Options: no-krb5
OS (uname): OSF1 pierredelune.i3s.unice.fr V5.0 910 alpha alpha
OS (config): alpha-dec-tru64
Target (default): alpha-cc
Target:
It must be a compiler bug and I'm dismissing this case for the following
reasons:
- you seem to have old compiler, 6.1 vs. currently available 6.4 (which
I have no problems with), ask for patch or consider upgrading;
- SHA is seldomly used algorithm, it probably doesn't worth the effort
to
apps/openssl version -a
OpenSSL 0.9.6g 9 Aug 2002
built on: Mon Dec 9 11:19:16 CET 2002
platform: dist
options: bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) idea(int)
blowfis
h(idx)
compiler: cc -O
This wouldn't work and it would indeed fail in BN_sqr. It looks like as
you've
Case is dismissed as RTFM. User failed to run ./config script. It feels
like we need BN_sqr entry in FAQ. I'll write couple of lines. A.
__
OpenSSL Project http://www.openssl.org
Development
I managed to reproduce the problem and am looking into it. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Do you have the possibility to help out with this? The help needed
would be to tell us exactly what assembler lines are incorrect,
It's not just a couple of lines that needs to be fixed up.
Let's wonder first why are those routines implemented in assembler?
Basically two reasons. To reach
... use up
every damn register and it's really tight there. Now what would it take
to PIC-ify the code? Most likely an extra register! The one you'll be
calculating offsets from. And the problem is that there is no register
to spare ... good news are that there is only one [DES]
module that
Both code relocation (DES code not being PIC) and linking issues (crt1.o
being linked in when it shouldn't) are addressed in HEAD and 0.9.7
branches now. The case is dismissed. A.
__
OpenSSL Project
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
The fix is committed to cvs repository. If you don't feel like pulling
down the cvs tree, apply attached patch, rm crypto/des/asm/*.o and rerun
make.
__
OpenSSL Project http://www.openssl.org
The bugexptest.c problem is already addressed in 0.9.7-beta6. As for
HEAD/0.9.8 it will be addressed next year. Therefore the ticken remains
open.
As for intermittent core dumps in the accelerated bn_sub_words
routine, I couldn't reproduce it and we therefore omit it from further
discussions
* compilation goes fine apart from the following compiler warning:
cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DL
-DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_ASM +DA2.0 +DS2.0 +O3
+Optrs_strongly_typed +Olibcalls -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY -c
...
the warnings and BN test failure seem to be related with the
hpux-parisc2-cc target and no-asm option. without the no-asm option
building goes ok (no warnings, tests succeed) using hpux-parisc2-cc
target.
Yet it's extremely important to get it working with no-asm. For that
i tried this but linking the openssl program as well as the tests fails
with the following message:
cc -o openssl -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DL -DOPENSSL_NO_KRB5 -DOPENSSL_NO_ASM +DA2.0 +DS2.0 +O3 +Optrs_strongly_typed
+Olibcalls -Ae +ESlit
Richard! How come this ticket made to 0.9.[78] STATUS? The question was
originally about 0.9.6h[-engine] and the issue is not relevant in
0.9.[78] context.
test BN_sqr
Square test failed!
Basically it's in the FAQ
(http://www.openssl.org/support/faq.cgi#BUILD11) and is a
misconfiguraiton
I pulled down openssl-0.9.7-stable-SNAP-20021226.tar.gz,
configure, compiled, tested, installed.
Not exactly related to this ticket itself, but I wonder if you could
tell what's your platform exactly. In other words what does
'./apps/openssl version -p' print? If it's hpux-parisc2-cc, then I
I tested this issue on Solaris 8,
??? RT#412 starts with In testing 0.9.7-beta6 on an HP system running
HPUX 11.0, ... and now it turns to be a Solaris 8 issue? I'm lost... A.
__
OpenSSL Project
I can't reproduce this. Not in a directory mounted with binmode
option. In a directory mounted with textmode option it fails already
in test_enc, i.e. much earlier than the originating report implies...
__
OpenSSL Project
This is second attempt to resolve this ticket...
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Make sure the directory you're compiling the toolkit in is mounted
with binmode option.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
I'm resolving this ticket in sincere faith that BN_kronecker issue is a
user environmental problem, i.e. either dependency rules inconsistency
or a compiler bug, and other problems were already addressed.
__
OpenSSL Project
If I understand you correctly, the 0.9.7 related part of the problem is
resolved.
Yes.
Therefore the Milestone should be moved to 0.9.8, shouldn't
it?
Done. A.
__
OpenSSL Project
First of all it would facilitate if you could file a single problem per
report. In which the person who is considering to close the ticket won't
end up judging over things he doesn't feel like capable of judging. Like
me over your previous RT#410:-) I mean e.g. BN_sqr failure was exactly
my cup
cl ... -c .\crypto\asn1\n_pkey.c
.\crypto\asn1\n_pkey.c(96) : error C2370: 'NETSCAPE_ENCRYPTED_PKEY_it' :
redefinition; different storage class
.\crypto\asn1\n_pkey.c(93) : see declaration of
'NETSCAPE_ENCRYPTED_PKEY_it'
Strange, I checked VC++ 6.0 SP3 and had no
As implied in RT#410 closing note it smells like a compiler bug.
changing optimization level from +O3 to +O2 in the hpux-parisc2-cc target
seems to fix the BN_kronecker test problem with the no-asm option.
Meaning that it *is* in fact a compiler bug and is therefore not an
OpenSSL issue.
compare pa-risc.s and pa-risc2.s, I see that reference to Division
would overflow is treated completely different. And I can actually
imagine that the way it's treated in pa-risc2.s is not
positon-independent...
with your patch applied shared library linkage and tests succeed on
Just tried the latest (0.9.7) with no luck, below is the end of the output.
testing req conversions
p - d
p - p
d - d
*** Error code 1
What is your compiler? Well, what version? What happens if you lower
optimization level (see INSTALL for details)? What happens if you copy
Initial support for icc appears first in
ftp://ftp.openssl.org/snapshot/openssl-SNAP-20030103.tar.gz. To
configure run './Configure linux-ia32-icc'. Auto-detection in ./config
will be added at some later point.
As already mentioned it's fruitless to count on libimf.a, as it's a
floating point
... or does size_t matter:-)
I had a look at BRANCH_WIN64 last night and here're some thoughts. First
of all I want to point out that I had rather fast look so that this is
probably not a final judgment:-)
As discussed earlier Win64 implements P64 programming model and so the
discussion started
1. File (socket) handles are ints. Why not create a special type called
file_handle_t, that changes sizes with platforms that have different
requirements of file handle types (read windows)?
Just a side note. As already pointed out in another context, it's
actually *safe* to cast SOCKET to
hpux64-parisc-cc target fails with the following error message both with
and without your pa-risc2.s patch applied:
cc -I../crypto -I.. -I../include +Z -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -Ae +DD64 +O3 +ESlit -z -DB_ENDIAN
-DMD32_XARRAY -c
The case is dismissed. A.
P.S. As for not being honest. If changes were made, you're expected to
state what changes exactly were made and you didn't.
__
OpenSSL Project http://www.openssl.org
Running under a debugging malloc library causes a crash earlier on with
a double free error on something which is only freed once.
Very odd...
What platform is this on?
Does anyone else get a crash with:
openssl ca -infiles
Linux: crash
HP-UX 10.20: no crash when
SUBJECT: Bug in new key generation
--
*** THIS BUG REPORT IS FOR 64 bits ONLY, 32 bits version is working fine ***
--
# cd /opt/src/openssl-0.9.6h
# ./apps/openssl version -a
OpenSSL 0.9.6h 5 Dec 2002
built on: Sun Dec 22 15:17:10 CET 2002
platform: solaris-sparcv9-gcc
options:
+ sx6, cc:-g -DTERMIOS::(unknown):::SIXTY_FOUR_BIT DES_INT:::,
No optimization? Not even lousy -O?
SIXTY_FOUR_BIT? SIXTY_FOUR_BIT aims ILP32 ABIs implemented on 64-bit
CPUs, N32 ABI on IRIX 6 is one example. If your sizeof(long)==8, then
you should use SIXTY_FOUR_BIT_LONG. Please confirm.
A.
(cd asm; /usr/local/bin/perl des-586.pl cpp dx86unix.cpp)
gcc -E -DOUT asm/dx86unix.cpp | as -o asm/dx86-out.o
des-586.s: Assembler messages:
des-586.s:2458: Error: Unimplemented segment type 0 in parse_operand
des-586.s:2645: Error: Unimplemented segment type 0 in parse_operand
*** Error
(cd asm; /usr/local/bin/perl des-586.pl cpp dx86unix.cpp)
gcc -E -DOUT asm/dx86unix.cpp | as -o asm/dx86-out.o
des-586.s: Assembler messages:
des-586.s:2458: Error: Unimplemented segment type 0 in parse_operand
des-586.s:2645: Error: Unimplemented segment type 0 in parse_operand
One is that AES using 192 or 256 bit ciphers produces the wrong result.
Have you traced into it at all?
Try this:-)
--- ./crypto/aes/aes_core.c.origWed Nov 13 15:01:18 2002
+++ ./crypto/aes/aes_core.c Wed Jan 15 01:54:08 2003
@@ -750,7 +750,7 @@
rk[2] = GETU32(userKey +
The ticket is being resolved as being FAQ matter.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Resolved as non OpenSSL problem.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL
No further information provided. Originally reported problem is lack of
support for platform in question in 0.9.6h. We do nothing about that,
but advice to deploy 0.9.7. As for 0.9.7 failing to pass the test. I
find it hard to believe that it's OpenSSL problem, but a compiler bug.
No action needs
If you just can't figure out
Just to clarify. The posted patch is not so to say try-your-luck
thing, it *does* get me through the ms\test.
But then you have to remember to go
fix it some day and remove the #pragma.
??? Fix what? It's the compiler that needs to be fixed... A.
Current version,
openssl-0.9.7, does not support shared libraries on AIX platform.
To openssl-dev mainly. How come did do_aix-shared deserve so special
treatment? I mean SHAREDFLAGS being hardcoded directly in Makefile.org?
Just wondering...
I am sending you the changes
which allow to
Config was adding 386 to the Configure line causing the build
to fail on the assembler modules.
in what way?
Not really.
So you mean that it's not like it fails, but generates not optimal code.
Minimum processor on any current UnixWare is a pentium.
The older
rt To openssl-dev mainly. How come did do_aix-shared deserve so special
rt treatment? I mean SHAREDFLAGS being hardcoded directly in Makefile.org?
rt Just wondering...
Well, that one is an experiment.
Then why AIX specific flags like -bnogc, -bE:lib$$i.exp, -bM:SRE?
rt and aix43-cc.
rt
I already answered this once, but it didn't come through for some
reason...
+ sx6, cc:-g -DTERMIOS::(unknown):::SIXTY_FOUR_BIT DES_INT:::,
No optimization? Not even lousy -O?
-g overrides any optimization you give,
Yes, that's what normally happens...
and i think there's a problem
Config was adding 386 to the Configure line causing the build
to fail on the assembler modules.
in what way?
UX:as: ERROR: asm/sx86-elf.s:35:invalid register for instruction: %al in xchg
Would it work if you add b to xchg mnemonic, i.e. make it look xchgb
Have the 5 section look something like
--
5)
if [ `echo x$VERSION | sed -e 's/\..*//'` = x7 ]; then
echo i586-sco-unixware7; exit 0
elif [ `echo x$VERSION | sed -e 's/\..*//'` = x8 ]; then
echo
All discussed issies are adressed. Ticket is being resolved. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
./Configure aix64-cc ... shared - build fails with
only libcrypto.a built (no libssl.a) and message
+ ld -r -o libcrypto.o -bnogc libcrypto.a
ld: 0711-245 WARNING: No csects or exported symbols have been saved.
+ nm -Pg libcrypto.o
+ grep [BD]
+ cut -f1 -d
+ 1
Wrong button again? I wasn't ready with it...
It builds shared libraries indeed!
Can you test one last thing. Assuming that you have the tree configured
with './Configure aix64-cc shared' left. Would following work:
cc -q64 -Wl,-bnogc,-bautoexp,
'cc -q64 -qmkshrobj -o libcrypto.so
1)Unless I understood you correctly, could you please send me
the complete implementation for aix-shared which you want.
You have to understand that I don't have access to AIX machine and
therefore can't be completely sure what I actually want. What I asked in
previous letter is to run the
As you don't appear to be interested in 64-bit build I've decided to
settle for following. We leave the code as is [as in
openssl-0.9.7-stable-SNAP-20030119.tar.gz or later] and document the
aix64-cc case in PROBLEMS in wait for more appropriate solution
(covering even gcc:-). BTW. Can use verify
1)I just got aix64-cc shared build succeed with -bautoexp. It was possible to
modify Makefile pretty similar to aix43-cc.
^^ But the challenge is to construct the rule which can be
parametrized through configure line. But as already mentioned, I'd
appreciate if you could verify if 'env
The originally reported issue is addressed and the ticket is being
resolved. Temporary workaround for emerged issue with aix64-cc shared
build is documented in PROBLEMS. A.
__
OpenSSL Project
When i type this command, openssl genrsa -des3 -rand certreq.txt 1024
www.mydomain.key i have this error message.
19887:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not
seeded:md_rand.c:53
8:
19887:error:04069003:rsa routines:RSA_generate_key:BN
lib:rsa_gen.c:182:
Hereby i'd like to request the the support for local (source) ip
address binding in bio_conn.c.
You may be able to do this with a BIO callback and making calls when it
has reached the appropriate internal state. That's messy but at least
you wouldn't need to patch the OpenSSL core
Hereby i'd like to request the the support for local (source) ip
address binding in bio_conn.c.
You may be able to do this with a BIO callback and making calls when it
has reached the appropriate internal state. That's messy but at least
you wouldn't need to patch the OpenSSL
We have been building OpenSSL on ppc64 and S390X platforms with Linux
and have found some Configure errors in the 0.9.8 tree when compiling
for 64 bit. These errors include:
1. Building as 64bit on ppc64 or s390x is broken
Platforms are 64bit (ppc64 and s390x) both ReadHat and SuSE need
I tried to install the Openssl and failed on the make test step. Would you
help me with the error message?
./README contains instruction on how to collect information required
when you file problem report.
../util/shlib_wrap.sh ./destest
make[2]: *** [test_des] Segmentation Fault
But if
In the revision 1.9 of file x86cpuid.pl there appeared block with
some setne instructions:
These instructions are translated under Solaris x86 into
setneb assembler instruction which causes Illegal mnemonic error with
/usr/ccs/bin/as
Also, expression
and (edx, ~(128)) is incorrectly
Ping?
it's about 6 weeks since I sent this patch. Is there some problem
with it so it can't be applied?
rules in question are used even in mingw build and why change this build
parameters? especially if we don't even know if suggested flag is
invalid in mingw ld context. i apologize it
please double-check http://cvs.openssl.org/chngview?cn=16237
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Title: Failed to link static openssl libraries (or non-PIC x86_64cpuid.s)
OS: FC4
HARDWARE: AMD x86 64bit
OPENSSL VERSION: 0.9.8e
OPTIONS:
CFLAGS=-fPIC -O2 ./config no-dso no-shared no-threads
no-zlib -fPIC -O2 --prefix=/home/dmitri/php/install
Details:
It worked just fine with all
I am experiencing an issue when run make test during Open SSL 0.9.8e
installation on Sun Solaris 5.10.
Below is the test report and attached the complete test log. Can you
please help me with this?
Testing cipher AES-128-ECB(encrypt)
Key
00 01 02 03 04 05 06 07 08 09 0a 0b 0c
i'm building openssl-0.9.8d on a KUBUNTO OS and under scratchbox 0.9.8.8 to be
able to export it on the pda nokia 770
when i run [sbox-SDK_ARMEL: ~/openssl-0.9.8d] ./config -t i have:
Operating system: i686-whatever-linux2
Does nokia run on x86 processor? I think not. I had an
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
__
OpenSSL Project http://www.openssl.org
Development Mailing
OpenSSL Version: 0.9.9-dev SNAP 20070621
OS. Linux/x86_64/Fedora 7
1. make report testlog attached
2. Getting segfault when running make tests during big number library test.
test BN_mont
*** glibc detected *** ./bntest: free(): invalid next size (fast):
http://cvs.openssl.org/chngview?cn=16325.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
it was not a bug, but http://cvs.openssl.org/chngview?
cn=16331 should keep memory debuggers calm.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Reminder. If openssl-dev subscribers want RT users to hear them, reply
explicitly to [EMAIL PROTECTED]
David Schwartz wrote:
[EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal BUS (invalid
address alignment)
0x7d24fab8: t_delete+0x00f8:stx %o0, [%g4 + 16]
current
thanks!
there is nothing to be thankful about, sorry.
haven't heard anything about it so far.
is there a patch or something?
if you would have checked the ticket, you'd see that there unfortunately
no resources to pursue the issue. i can't reproduce it and have no time
to interrogate you
Hi,
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
No comments on the tracker entry.
Apparently I should have clicked on more buttons, when closing the
ticket, but there *is* comment in RT.
Please
The hpux-parisc2-cc configuration still uses the dlfcn specifier (see
below), it must be renamed to dl as in the other parisc targets.
64-bit PA-RISC is ELF and implements dlfcn-style API. Even though
dl-style API is supported in 64-bit context users are encouraged to
migrate to the dl*
After successfully configuring and building OpenSSL version openssl-0.9.8e
on Sun/Optron under the latest Soalris 10, after executing:
make test
The following errors are detected:
Testing cipher AES-128-ECB(encrypt)
Key
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
On my old Debian box during OpenSSL 0.9.7 build, make fails:
make[2]: Entering directory `/usr/local/openssl/crypto/rand'
gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHA VE_DLFCN_H -DOPENSSL_NO_KRB5 -m64 -DL_ENDIAN -DTERMIO -O3 -Wall
-DMD32_REG_T=int
Suggested method is inappropriate as it affects all targets.
The problem is worked around in
http://cvs.openssl.org/chngview?cn=16551.
__
OpenSSL Project http://www.openssl.org
Development
openSSL v9.8.2 on Windows 2000 Server in support of PostgreSQL 8.2 - my
original bug report to the Postgres developers can be found at:
http://archives.postgresql.org/pgsql-bugs/2006-12/msg00122.php
A follow-up to my report posted by Tom Lane, a member of Postgres' core
dev team, includes
This was discussed multiple times. It's Sun compiler bug [in
both SPARC and x86 version apparently] and there're patches
available. A.
__
OpenSSL Project http://www.openssl.org
Development
as of the latest openbsd (v4.1)
seems it's impossible to compile openssl 0.9.7m package with asm enabled
assembler adds underscores before the names and causes make to fail to build
apps
For example DES_encrypt appears as many U DES_encrypt and one T _DES_encrypt
in the nm output for
fixed. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
apparently was fixed at some point. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
fixed. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
fixed. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
We have some interop issue between TLS 1.0 and TLS 1.1. Our application is
based on OpenSSL 0.9.7 version (Linux - Operation system). This is Radvision
SIP stack and oSIP stack.
I don't quite understand. Does OpenSSL act as server or client? You must
be referring to server...
It doesn't
we are using openssl in an environment with a Windows 2003 PKI/CA.
OpenSSL together with OpenLDAP shall be used to provide Single Sign On.
This is working as long as the servers public key on the Windows AD
server is not getting larger than 1024 bit.
I have tested the following commands
[EMAIL PROTECTED] via RT wrote:
Hi,
I am having a bit of a trouble compiling the openSSL release 0.9.8e
under WinXP SP2.
The version of minGW's the gcc compiler I am using is 3.4.5-20060117-1
and the minGW32-make is 3.80.0-1.
For some reason the build tools use malformed file names
0.9.7 is no longer [actively] supported. Mac OS support is improved in
0.9.8 stable and development versions and we advice to use them instead. A.
__
OpenSSL Project http://www.openssl.org
This was fixed at some point. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
We have been building OpenSSL on PPC64 and S390X platforms with Linux
and have found some type punning errors in both the 0.9.7 tree and the
0.9.8 tree. The self-test test_x509 fails due to this error. This error
only seems to appear on big endien 64 bit machines, whether compiling
for 32 or
There is no problem with C compiler and tools around it under OpenBSD except
assembler. It's assember adds undescores to all the public symbols in the
object files
No. It's not assembler that adds underscores, but OpenSSL modules that
are generated with underscores for OpenBSD-i386 target.
this was fixed at some point. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
this was eventually fixed. thanks for report. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
this was addressed at some point. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
alternative home-developed module was provided at some
point. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List
1 - 100 of 768 matches
Mail list logo
