djgpp patches

Thanks a lot to Doug Kaufmann for the MSDOS patches for djgpp. But one thing I don't understand. In ./crypto/bn/bn_mul.c: #if defined(OPENSSL_NO_ASM) || !(defined(__i386) || defined(__i386__)) || \ defined(__DJGPP__) /* Assembler implementation exists only for x86 */ I haven't studied the Makef

Re: djgpp patches

On Tue, 18 Jun 2002, Doug Kaufman wrote: > a chance to check this yet. Before doing this routinely for DJGPP, we > should probably verify that there are no instructions that won't work > on a 386 processor. Otherwise tha code won't be portable to many of > the low-powered machines (i.e. 386 and 4

server down?

What's up with the ftp.openssl.org server? It's been unreachable all day. Gisle V. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automa

MSDOS/djgpp patches

Here are some patches for MSDOS and djgpp using Watt-32 tcp/ip stack. Patch against snapshot 11-Nov 2002. 1. sock_init() renamed to ssl_sock_init() in ./apps/s_socket.c due to name-clash with Watt-32. 2. rand() renamed to Rand() in ./crypto/bn/divtest.c due to name-clash with 3. Added cal

Mingw32 build fail

The ms\mingw32.bat build fails with these undefines: out/libcrypto.a(eng_all.o)(.text+0x9):eng_all.c: undefined reference to `ENGINE_load_cswift' out/libcrypto.a(eng_all.o)(.text+0xe):eng_all.c: undefined reference to `ENGINE_load_chil' out/libcrypto.a(eng_all.o)(.text+0x13):eng_all.c: undefined

apps/s_socket.c

The apps/s_socket.c compiles with a warning "call to undefined function SHUTDOWN". The sollution is to move "#define USE_SOCKETS" before including e_os.h: --- apps/s_socket.c.orig Fri Nov 22 09:00:22 2002 +++ apps/s_socket.cThu Nov 28 14:42:56 2002 @@ -62,6 +62,8 @@ #include #include

Patch for unused files

The files. ./crypto/dsa/dsagen.c ./crypto/x509v3/v3conf.c seems no longer used (reference from makefiles). But some functions have wrong number of arguments. The files should IMHO be removed or corrected. Here is a patch: - --- ./cry

wrong read() protype

Some test-files include a protype for read(). Unfortunately this protype doesn't match the one in djgpp's . Can we not removed this prototype? The required system headers are included already I think. Here is a patch to make it compile for djgpp: ---

Re: [openssl.org #428] Patch for unused files

"Richard Levitte via RT" <[EMAIL PROTECTED]> said: > > Which OpenSSL version are you refering to? The latest SNAP-shot. __ OpenSSL Project http://www.openssl.org Development Mailing List

wrong read() prototype

In latest 0.9.8 snapshot, some test-files include a protype for read(). Unfortunately this protype doesn't match the one in djgpp's . Can we not removed this prototype? The required system headers are included already I think. Here is a patch to make it compile for djgpp: --

Re: [openssl.org #428] Patch for unused files

"Richard Levitte - VMS Whacker" <[EMAIL PROTECTED]> said: > levitte> Please name it. The reason that I ask you is that the changes you > levitte> propose are already present in 0.9.7 and 0.9.8-dev. > > Or is your patch a reverse patch? No, not a reverse patch. The snapshot I diff'ed against was

Re: [openssl.org #428] Patch for unused files

"Richard Levitte - VMS Whacker" <[EMAIL PROTECTED]> said: > OK, this is very odd. Can you check against the two attached > archives? In those files, it looks like the result of your proposed > patch. No, the files in you attachment are wrong. It's quite simple; 'DSA_generate_parameters()' shou

Re: wrong read() prototype

I wonder why this earlier post of mine didn't get assigned a ticket. Gisle V. - Original Message - From: "Gisle Vanem" <[EMAIL PROTECTED]> To: "OpenSSL" <[EMAIL PROTECTED]> Sent: Wednesday, January 01, 2003 3:10 PM Subject: wrong read() prototype

OPENSSL_NO_FP_API

Why is OPENSSL_NO_FP_API defined for all MS-DOS targets? I assume it means "No FILE pointer API". Isn't that situation covered already by OPENSSL_NO_STDIO? In : /* Specials for I/O an exit */ #ifdef OPENSSL_SYS_MSDOS # define OPENSSL_NO_FP_API OPENSSL_NO_FP_API is already defined in when

Re: OPENSSL_NO_FP_API

"Richard Levitte - VMS Whacker" <[EMAIL PROTECTED]> said: > The point with the change is that some exported header files depend on > OPENSSL_NO_FP_API (for example bio.h, but in total, it's checked in 15 > of them). e_os2.h is an public header, e_os.h is not. Therefore, we > need to have that de

Win32 build broken

Looks like the build for all Win32 targets (MSVC, MingW) got broken with the introduction of the ./engines directory. I looked at it, but failed to see where the dir is included. Please, someone with more knowledge fix this. --gv _

Macros for getting time

I've made my own makefile for a target that isn't supported by OpenSSL (Open Watcom for Win32 to be exact). I'm wondering about the define in e.g. crypto/des/des_opts.c: #if !defined(OPENSSL_SYS_MSDOS) && (!defined(OPENSSL_SYS_VMS) || ... #define TIMES #endif That assumption is IMHO way to optim

Re: [openssl.org #615] New Mirror

[EMAIL PROTECTED] - Wed May 14 18:31:26 2003]: > Dear OpenSSL Team > > we took the liberity and have created a mirror site for OpenSSL. It can be > accessed at http://www.binarycode.org/openssl > The mirror is being updated daily by cron and the server is located in > Austin, Tx, United States.

select patches for DOS

These are my patches to get "openssl s_client" working on MSDOS / djgpp / Watt-32. The assumtion that DOS in general can do select() on stdin/stdout is wrong (allthough djgpp has some support for it, it's slow and clunky). My patch uses kbhit() as Win32/WinCE does. One other patch: I had to p

Re: select patches for DOS

I didn't get any reaction on this patch. Isn't 32-bit MSDOS targets considered good enough any longer? The original message and patch is here: http://marc.theaimsgroup.com/?l=openssl-dev&m=105943488203763&w=2 --gv __ OpenSSL Pro

Re: select patches for DOS

"Doug Kaufman" <[EMAIL PROTECTED]> said: > In crypto/bio/bss_file.c, you change the way that binary or text is > chosen, and allow binary only if not going to stdout or or from stdin. I > think that the usual way to handle this (at least under DJGPP) is to use > "isatty", and not allow binary if i

Re: select patches for DOS

Here is a revised patch using isatty() to check if stdin/stdin is redirected. If they are allow setting binary mode. Otherwise skip it as doing so prevents terminating a stuck app with ^C/^Break. I can't see any use for making stdin binary while in "interactive" mode except maybe in a password pro

suspicious VxWorks patch

>From latest e_os.h (inside VxWORKS ifdef): #define ioctlsocket(a,b,c) ioctl((a),(b),*(int*)(c)) Can this really be right? I mean using it in BIO_socket_ioctl() expands to: ioctlsocket (fd, type, *(int*)ptr); I would assume VxWorks to expect a pointer in the 3rd arg to it's ioctl(). If so, th

Building DLLs

Is _WINDLL (or OPENSSL_OPT_WINDLL) supposed to be set by apps when linking to the OpenSSL import libs? Or is it enough to simply link with the imports libs? The docs didn't mention these flags. BTW. The following test programs fails to link with the dynamic versions of the libs: crypto/des/de

[Patch] Win32 test programs

The test programs bf_opts.exe and bfspeed.exe fails to compile on MSVC/MingW befause of missing "struct tms" : --- crypto\bf\bf_opts.c.orig Wed Mar 07 12:00:27 2001 +++ crypto\bf\bf_opts.c Thu Oct 30 16:52:58 2003 @@ -63,10 +63,6 @@ #define TIMES #endif +#if defined(WIN32) || defined(_WI

Re: [openssl.org #757] Missing ordinal

"Lutz Jaenicke via RT" <[EMAIL PROTECTED]> said: > Hmm. Between OpenSSL 0.9.6 and 0.9.7, the following change was made > (see the corresponding util/libeay.num files): > OpenSSL_add_all_algorithms 508 EXIST::FUNCTION: > became > OpenSSL_add_all_algorithms 508 NOEXIS

Re: [openssl.org #757] Missing ordinal

"Stephen Henson via RT" <[EMAIL PROTECTED]> said: > Now if this works in one context but not another then I'd say that one > is picking up libeay32.dll from 0.9.6 and the other 0.9.7 or later. This > will depend on the Win32 DLL directories which IIRC depend on PATH, the > current directory and a

Re: A few minor issues building 0.9.8 for Windows

"Verdon Walker" <[EMAIL PROTECTED]> said: > I recently downloaded and compiled for Windows the 0.9.8 snapshot from > 11-24-2003. I had a few minor problems of which you might want to be > aware: > > .\crypto\bio\bss_file.c(218) : error C2065: 'fd' : undeclared > identifier I've sent a patch for

Re: [openssl.org #788] AutoReply: [PATCH] up to 1.4x RSA throughput using SSE2

"[EMAIL PROTECTED] via RT" <[EMAIL PROTECTED]> said: > i've added a second patch > -- the > second patch includes run-time detection of SSE2 and selects between two > implementations of bn_mul_add_words so that it can be used in

x_cinf.c patch

The d2i_X509_CINF() is prototyped through some hairy ifdef's by DECLARE_ASN1_FUNCTIONS(X509_CINF) The implementation in x_cinfo.c is however missing a 'const': --- crypto/asn1/x_cinf.org Thu Mar 20 22:16:08 2004 +++ crypto/asn1/x_cinf.cThu Mar 25 21:40:14 2004 @@ -97,7 +97,7 @@

MSDOS/djgpp patches

Just a little detail, so it doesn't create Watt-32 debug-files unconditionally: --- apps\s_socket.c.orig Sat Dec 27 16:00:40 2003 +++ apps\s_socket.c Sat Mar 27 12:56:50 2004 @@ -171,8 +171,11 @@ { #ifdef WATT32 extern int _watt_do_exit; - _watt_do_exit = 0; +c

WSAEINPROGRESS

Is there any reason why this error isn't among the non-fatal errors in BIO_sock_non_fatal_error() (in crypto/bio/bss_file.c) ? MSDN has this to say: WSAINPROGRESS: A blocking Windows Sockets 1.1 call is in progress, or the service provider is still processing a callback function. ... A bl

Re: [openssl.org #880] Client error

"Gisle Vanem via RT" <[EMAIL PROTECTED]> said: > 4008:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 > error:crypto/asn1/tasn_dec.c:395:Type=X509 > 4008:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 > lib:ssl/s3_clnt.c:842: I

SSE2 speed

With SSE2 disabled: > openssl speed sha-512: ... type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes sha-512 1050.62k 4223.53k 6141.97k 8488.01k 9480.48k with SSE2 enabled: type 16 bytes 64 bytes256 bytes 1024 bytes 8192

Re: SSE2 speed

"Andy Polyakov" <[EMAIL PROTECTED]> said: > >>400% on large blocks. > > 4x? What gcc version? 3x mentioned in commentary section is also for > largest block and with gcc 2.95.3. Well, not that 4x is worse result... I used gcc 3.3.1 with -O2 -fno-strength-reduce -fomit-frame-pointer. > As for O

Re: SSE2 speed

> I got that part. But AFAICS, when strtol(env,NULL,0) is used to set > OPENSSL_ia32cap and env = "0x0400", strtol() treats the value > as octal. From mn strtol: > The string may begin with an arbitrary amount of white space (as > determined by isspace(3)) followed by a single optional + o

Re: SSE2 speed

There's some more problems with OPENSSL_ia32cap. In crypto\bn\asm\bn.586.pl it says: if ($sse2) { &picmeup("eax","OPENSSL_ia32cap"); but on my target (gcc/djgpp) that should actually be "_OPENSSL_ia32cap". I tried with prefixing with $under, but didn't work since I know next to nothi

Re: SSE2 speed

"Andy Polyakov" <[EMAIL PROTECTED]> said: > As far as I can see "stock" OpenSSL doesn't generate assembler moduler > for DJGPP, so you've got to tell more details about how do you generate > assembler modules. Note that &picmeup is used in des assembler modules. > Can you figure out how it work

Re: SSE2 speed

"Andy Polyakov" <[EMAIL PROTECTED]> said: > > gcc -E -DBSDI tmp\tmp.c | as -o obj\bn-586.o > > Any particular reason why you use BSDI? I can see that there're #if > defined(__DJGPP__) in generated assembler, but those in turn are guarded > by #if defined(OUT). Have you tried -DOUT? Tried it

Common Name and IDNA

How is the /CN= supposed to be encoded for a host/domain- name using international characters? In some specified charset (utf8?) or in the ASCII Compatible Encoded form? I ask since in an application here (using libidn), I get the subject with X509_get_subject_name() and check the CN (or wildcard

Re: Common Name and IDNA

"Lev Walkin" <[EMAIL PROTECTED]> said: > > No, fnmatch() is fairly portable across Unixes though. > > > Please note that fnmatch() use is against RFC2818. Please explain why. --gv __ OpenSSL Project

[patch] djgpp and OPENSSL_ia32cap

Allthough djgpp isn't Unix, it does have opendir() and friends: --- ./orig/crypto/o_dir.cSat Jul 10 15:15:58 2004 +++ ./crypto/o_dir.cSun Jul 18 20:15:46 2004 @@ -70,7 +70,7 @@ #include "o_dir.h" #define LPDIR_H -#if defined OPENSSL_SYS_UNIX +#if defined OPENSSL_SYS_UNIX || defined DJGP

SSE2 speed revisited

>From snapshot in May with SSE2 enabled: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes sha-512 3171.75k12757.93k22761.88k34514.56k40059.42k But now it's back to non-SSE2 speed: type 16 bytes 64 bytes256 bytes 102

Re: Patch for DJGPP / OpenSSL 0.9.7-stable

"Doug Kaufman" wrote: > I also looked at the problem of DJGPP not having had a good way of > getting entropy to seed the PNRG. I made a change to let DJGPP use the > rand_egd mechanism. I don't see any reason why it can't work in DJGPP > and now seems to be polling the socket when tested. The ran

Re: SSE2 speed revisited

"Andy Polyakov" wrote: > Latest relevant update is more picky and requires yet another assembler > module compiled and linked in. You mean x86cpuid.o? Got that. > I'd rather discuss proper and complete support for assembler modules in > DJGPP than trying to figure out what went wrong with your

Re: Test of 0.9.8 under DJGPP (was Re: [openssl.org #932] Patch for 0.9.8 (DJGPP))

Doug Kaufman wrote: > OpenSSL 0.9.8-dev XX xxx > built on: Mon Sep 6 09:04:18 PST 2004 > platform: DJGPP > options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx) > compiler: gcc -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 > -I/dev/env/WATT_ROOT/inc -DTERMIO

Dumping DLL certs

Is there a openssl command to dump the details of a signed DLL under Win-XP? With a command like CertMgr -add -all ipworks6.dll copy.crt I can extract the security part of the IPWorks6.dll. Now I want to dump and process the contents of copy.crt using OpenSSL tools. pedump says the format is

e_os2.h patch

I tried compiling for MingW and with OPENSSL_EXPORT_VAR_AS_FUNCTION defined. But struck a gcc 3.4.1 error because of "extern static ...". Patch: --- orig/e_os2.h Tue Jul 27 16:00:12 2004 +++ e_os2.h Sun Sep 26 15:07:24 2004 @@ -268,7 +268,7 @@ */ #ifdef OPENSSL_EXPORT_VAR_AS_FUNCTION

sha512t link fail

I tried building all the sample programs by linking to the DLL import libs. All okay except for sha512t.exe: sha512t.o(.text+0x42):sha512t.c: undefined reference to `OPENSSL_ia32cap_loc' AFAICS because OPENSSL_ia32cap_loc() isn't in the libeay32.def file. It's neither in the util/libeay32.num fil

X509_vfy.h and C++

This file has a 'explicit' struct x509_store_ctx_st member. This words is unfortunetely a C++ reserved word in g++ 3.4.1 at least. And from a bit of googling, has been a reserved word for more than 6 years. I suggest we replace with 'explicit_policy'. --- crypto/x509v3/x509_vfy.h.orig Sat Se

todays snapshot

All the snapshot files for today are all zero bytes. E.g. ftp://ftp.openssl.org/snapshot/openssl-SNAP-20041122.tar.gz What's causing this? --gv __ OpenSSL Project http://www.openssl.org Development M

Undefined reference

I'm trying to build OpenSSL 0.9.4 (Aug 1999) with djgpp under DOS. Everything is going well except this error while linking hmactest.exe and others: libcrypto.a(rsa_eay.o)(.text+0x138):rsa_eay.c: undefined reference to `RSA_padding_add_PKCS1_OAEP' I've searched through all sources, but it's n

Re: Undefined reference

On Mon, 17 Jan 2000, Ulf Möller wrote: :> libcrypto.a(rsa_eay.o)(.text+0x138):rsa_eay.c: undefined reference to :> `RSA_padding_add_PKCS1_OAEP' :> :> I've searched through all sources, but it's not found anywhere. : :It's in crypto/rsa/rsa_oaep.c : :Maybe you're using a DOS filesystem which can

Re: Undefined reference

Seem you mailing-list program doesn't allow replying from a different account from the one I'm subscribed to. Hence the retry: Ulf Möller <[EMAIL PROTECTED]> wrote: > The randomness code in ./apps was named app_rand.c to avoid that kind > of problems. So I guess we should rename one of the files

Undefined reference

I'm trying to build OpenSSL 0.9.4 (Aug 1999) with djgpp under DOS. Everything is going well except this error while linking hmactest.exe: libcrypto.a(rsa_eay.o)(.text+0x138):rsa_eay.c: undefined reference to `RSA_padding_add_PKCS1_OAEP' I've searched through all sources, but it's not found any

Re: Undefined reference

> The randomness code in ./apps was named app_rand.c to avoid that kind > of problems. So I guess we should rename one of the files. > (crypto/asn1/pkcs8.c to crypto/asn1/p8_key.c or something?) Good, thanks. >> BTW2. After compiling 0.9.5-SNAPSHOT16012000, more undefined have crept >> up; SHA

bignum divtest fails

This is the output of ./crypto/bn/divtest.c after some minutes of running: d:\net\openssl.095\bin>divtest.exe BN_div_recp failed! a=21CC27865629353755638C3726DF4C2D1C976729D1CD3C3FFC01039CE01B6687959E2BB84BAB54 D798D9873CAED7007AB955B025F799BDE5AE4C84D79DE7B35E7ED2A43 b=1 BN_div_recp failed! a=7F

Re: bignum divtest fails

Andy Polyakov <[EMAIL PROTECTED]> said: >> > BN_div_recp failed! >> > a=21CC27865629353755638C3726DF4C2D1C976729D1CD3C3FFC01039CE01B6687959E2BB84BAB54 >> > D798D9873CAED7007AB955B025F799BDE5AE4C84D79DE7B35E7ED2A43 >> > b=1 >> >> > d:\net\openssl.095\bin>openssl.exe version -a >> > OpenSSL 0.9.5

Re: bignum divtest fails

On Tue, 29 Feb 2000, Ulf Möller wrote: > On Tue, Feb 29, 2000 at 09:36:53AM +0100, Gisle Vanem wrote: > > > I didn't use ./configure, but my single big homemade makefile > > Please have a look at how it is done for Mingw32, and try to adopt > that do DJGPP. In fac

tcpdump and SSL

Is anyone aware of a tcpdump extension parser for the SSL protocol? The debugging available in OpenSSL is IMHO not well suited in debugging the handshake and CONNECT transactions. I would be nice to trace this in real-time using tcpdump. Gisle V.

Re: DJGPP patches for 0.9.8 and 0.9.7

"Doug Kaufman" wrote: The code for watt-32 debugging didn't appear to be implemented correctly. This should only be called when desired; otherwise large files will be created, documenting every byte going through tcp. In addition dbug_init() should be called only once, but was being called multiple

multiple AES symbols

AES_set_encrypt_key() etc. are multiple defined (in aes-586.pl and aes_core.c). Patch: --- aes_core.c.orig 2004-12-23 21:00:10.0 +0100 +++ aes_core.c 2005-01-15 11:13:02.0 +0100 @@ -736,6 +736,7 @@ 0x1B00, 0x3600, /* for 128-bit blocks, Rijndael never uses more than 10 r

[Patch] ssltest.c

Currently ssltest.exe prints to stdout/stderr using binary mode on DOS/Win32. So the screen output is all screwed: ssltest.exe -d -v -time -server_auth Using BIO pair (-bio_pair) Warning: For accurate timings, use more connections (e .g. -num 1000) Available

Re: [Patch] ssltest.c

My previous message seems to have got lost somewhere; it is not in the archive. - Original Message - From: "Gisle Vanem" <[EMAIL PROTECTED]> To: "OpenSSL-dev" Sent: Tuesday, January 18, 2005 2:23 PM Subject: [Patch] ssltest.c Currently ssltest.exe prints to

Missing openssl_fcast

Using the snapshot from today, linking fails due to missing 'openssl_fcast': crypto/asn1/p5_pbe.c: In function 'PKCS5_pbe_set': crypto/asn1/p5_pbe.c:109: warning: implicit declaration of function 'openssl_fcast' crypto/asn1/p5_pbev2.c: In function 'PKCS5_pbe2_set': crypto/asn1/p5_pbev2.c:167: warn

ts/*.c files

Some of the new ts/ files are too long for a 8+3 filesystem. ts_req_print.c ts_req_utils.c ts_resp_print.c ts_resp_sign.c ts_resp_utils.c ts_resp_verify.c ts_verify_ctx.c I only ask if the ts_resp_*.c files could be renamed to ts_rsp_*.c. --gv ___

Re: ts/*.c files

"Mike Frysinger" <[EMAIL PROTECTED]> wrote: On Tuesday 14 February 2006 11:26, Gisle Vanem wrote: Some of the new ts/ files are too long for a 8+3 filesystem. a ton of files are too long for 8+3 filesystem in the openssl tarball None of the *.[ch] files. They are all 8+3 un

s/snprintf/BIO_snprintf/g

As the comment in b_print.c says; "As snprintf is not available everywhere, we provide our own implementation" So we should use BIO_snprintf() in apps/s_client.c and ssl/ssltest.c. The other patch to ssltest.c fixes the missing newline problem under DOS and Windows. Patch attached. --gv ---

obj_dat.c doesn't compile

Since a few days back, crypto/objects/obj_dat.c doesn't compile. Here are the errors from gcc: 2112: error: `NID_id_GostR3410_94_cc' undeclared here (not in a function) 2112: error: initializer element is not constant 2112: error: (near initialization for `nid_objs[797].nid') 2113: error: initia

[Patch] apps/apps.c

Do as the apps/apps.h prototypes: --- apps\apps.c.origSun Apr 09 12:00:11 2006 +++ apps\apps.c Wed Apr 12 17:57:37 2006 @@ -2673,7 +2673,7 @@ #endif #if defined(_WIN32) && defined(STD_OUTPUT_HANDLE) -int raw_write_stdout(void *buf,int siz) +int raw_write_stdout(const void *buf,int siz)

exporting evp.h functions

Why is it that (not all?) functions in evp.h and pem.h isn't exported? That is; there are no entries in util\libeay.num for them. Because of this, I'm unable to bind to OpenSSL dynamically when building openssl.exe. Just curious. --gv _

Re: exporting evp.h functions

"Dr. Stephen Henson" <[EMAIL PROTECTED]> wrote: Do you mean those in 0.9.9-dev? Occasionally when something isn't quite stabilized libeay.num isn't updated straight away. You can update it yourself using the info in INSTALL.W32. Note however that the numbers it assigns may change when these beco

Re: exporting evp.h functions

But then this patch: --- util\ssleay.num.origWed Apr 12 20:11:22 2006 +++ util\ssleay.num Wed Apr 12 18:25:52 2006 @@ -231,3 +231,5 @@ SSL_get_psk_identity_hint 280EXIST::FUNCTION: SSL_get_psk_identity281EXIST::FUNCTION: SSL_use_psk_identity_h

[Patch] util/libeay.num

With the following patch I'm able to link openssl.exe using the DLL (and not the static libs): --- orig/util/libeay.num Mon Apr 17 15:01:06 2006 +++ util/libeay.num Fri May 12 16:52:48 2006 @@ -3683,3 +3683,6 @@ EVP_PKEY_verify_recover 4079 EXIST::FUNCTION: EVP_PKEY_asn1_se

[Patch] test-programs

Some patches needed to build the test-programs on MingW: * 'struct tms' is not available on MingW. So don't define TIMES. * main() returns an int. * don't use deprecated BN_CTX_init(). Use BN_CTX_new() instead. * added header-guard to crypto/des/spr.h * include and to surpress warnings. Patche

[Patch] th-lock.c

There should be no reason to typecast the argument to CRYPTO_set_locking_callback(): diff -u3 -Hb -r openssl-SNAP-20060713\crypto\threads\th-lock.c crypto\threads\th-lock.c --- openssl-SNAP-20060713\crypto\threads\th-lock.c Fri Mar 21 18:15:34 2003 +++ crypto\threads\th-lock.c Thu Jul 13 15:08:

Re: what the heck is with camellia update?

One other thing is that cmll_loc.h includes for non-MSCV targets. This header is not omni-present. A patch for djgpp at least: --- crypto\camellia\cmll_loc.org2006-07-20 17:01:50 +0200 +++ crypto\camellia\cmll_loc.h 2006-07-20 16:57:54 +0200 @@ -77,6 +77,8 @@ typedef unsigned char uint8

[patch] rsa_locl.h

crypto/rsa/rsa_locl.h wrongly uses 'size_t' in some arguments. It should match the implementation in crypto/rsa/rsa_sign.c (what happened to this file?). A patch: --- orig/crypto/rsa/rsa_locl.h 2006-08-28 19:01:02 +0200 +++ crypto/rsa/rsa_locl.h 2006-08-29 15:30:50 +0200 @@ -1,4 +1,4

Re: rsa_locl.h

Bodo Moeller wrote: Makes sense. I'll put this into the CVS (applicable to the 0.9.9-dev branch only, if anyone is wondering -- i.e., this mismatch isn't in any of the releases). The change is in the CVS, but it's still not in the snapshot at: ftp://ftp.openssl.org/snapshot/openssl-SNAP-200

OPENSSL_RFC3779

As it is now one must add OPENSSL_RFC3779 to the CFLAGS to make todays snapshot to build. Otherwise I'm getting link errors like: Cannot export ASIdOrRange_free: symbol not defined Shouldn't defines like: #ifdef OPENSSL_RFC3779 be replaced with: #ifndef OPENSSL_NO_RFC3779 Or is it required

ccgost on DOS

There is a problem building OpenSSL on a 8+3 filesystem like DOS due to the files: engines/ccgost/gost2001.c engines/ccgost/gost2001_keyx.c The latter overwrites the first using djgpp's tar. Could you please rename them to something like: engines/ccgost/gost01.c engines/ccgost/gost01_keyx.c so t

Re: ccgost on DOS

"Victor B. Wagner" <[EMAIL PROTECTED]> wrote: It'll be interesting to see if ccgost engine can work at all under DOS - we never intended it to be used on the platform without dynamic loading, and OpenSSL doesn't support dynamic loading, available in DJGPP 2.04. gost_eng.c has some code inside

[Patch] crypto/des/spr.h

This file lacks a header-guard. It's needed since it is included multiple times in crypto/des/des_opts.c (via des_enc.c). Patch: --- orig/crypto/des/spr.h 2002-03-04 18:01:16 +0100 +++ crypto/des/spr.h2007-03-19 18:32:56 +0100 @@ -56,6 +56,9 @@ * [including the GNU Public Licence.] */ +#

Missing seed functions

Where are functions like EVP_seed_ecb() and other functions inside "#ifndef OPENSSL_NO_SEED" implemented? Now I have to build using '-DOPENSSL_NO_SEED' to get things to link. I've built everything fresh from a tar-ball from 3 days ago: ftp://ftp.openssl.org/snapshot/openssl-SNAP-20080107.tar.gz

Re: Missing seed functions

Where are functions like EVP_seed_ecb() and other functions inside "#ifndef OPENSSL_NO_SEED" implemented? Forget it; found it in crypto/evp/e_seed.c. --gv __ OpenSSL Project http://www.openssl.or

lh_test.c build failure

Suddenly crypto/lhash/lh_test.c no longer compiles. From todays snapshot (on MingW): crypto/lhash/lh_test.c:65: warning: return type defaults to `int' crypto/lhash/lh_test.c: In function `main': crypto/lhash/lh_test.c:66: error: `LHASH' undeclared (first use in this function) crypto/lhash/lh_tes

Missing symbols

Once again I'm getting unresolved symbols trying to compile the latest snapshot: PKCS7_it PKCS7_ATTR_SIGN_it PKCS7_ATTR_VERIFY_it PKCS7_ISSUER_AND_SERIAL_it PKCS12_it PKCS12_SAFEBAGS_it PKCS12_AUTHSAFES_it RSAPublicKey_it RSAPrivateKey_it Those are the missing symbols while linking openssl.exe.

Patches

Here are some patches for some files. Some files are unused (not in makefiles, but in snapshot). All diffs are on "diff -tBHu3" format against 19-Aug snapshot. +++ ./crypto/des/cbc3_enc.c Tue Jul 31 10:13:42 2001 --- ./crypto/des/cbc3_enc.oldFri Aug 13 18:00:24 1999 @@ -70,13 +70,13 @@

Long file names

I'm building OpenSSL on MSDOS, but have problems with long filenames. My untar program silently overwrites e.g. ./crypto/engine/engine_err.c with ./crypto/engine/engine_evp.c. Could you *please* make the "engine- files" 8+3 compliant. Gisle V.

Re: Long file names

On Thu, 6 Sep 2001, Jeffrey Altman wrote: > > I'm building OpenSSL on MSDOS, but have problems with long filenames. > > My untar program silently overwrites e.g. ./crypto/engine/engine_err.c > > with ./crypto/engine/engine_evp.c. Could you *please* make the "engine- > > files" 8+3 compliant. > >

snapshot directory

I can see the ftp://ftp.openssl.org has changed. Now there is no /snapshot directory. Where are daily tar-balls uploaded? Gisle V. __ OpenSSL Project http://www.openssl.org Development Mailing Lis

ECDSA: unresolved function

I get unresolved symbol `EC_GROUP_get_group_by_name' when linking openssl.exe. In what file should this function exist? Gisle V. __ OpenSSL Project http://www.openssl.org Development Mailing List

Re: [openssl.org #61] OPENSSL_SYS_MSDOS is confusing

"Richard Levitte via RT" <[EMAIL PROTECTED]> > The macro OPENSSL_SYS_MSDOS is a bit confusing. It *should* designate > systems that are based on MSDOS, i.e. are 16-bit in nature. What about djgpp? It's a 32-bit environment for DOS. Better introduce a OPENSSL_SYS_MSDOS_16 for true 16-bit tar

[openssl.org #428] Patch for unused files

The files. ./crypto/dsa/dsagen.c ./crypto/x509v3/v3conf.c seems no longer used (reference from makefiles). But some functions have wrong number of arguments. The files should IMHO be removed or corrected. Here is a patch: - --- ./cr

[openssl.org #669] select patches for DOS

These are my patches to get "openssl s_client" working on MSDOS / djgpp / Watt-32. The assumtion that DOS in general can do select() on stdin/stdout is wrong (allthough djgpp has some support for it, it's slow and clunky). My patch uses kbhit() as Win32/WinCE does. One other patch: I had to

[openssl.org #752] [Patch] Win32 test programs

The test programs bf_opts.exe and bfspeed.exe fails to compile on MSVC/MingW befause of missing "struct tms" : --- crypto\bf\bf_opts.c.orig Wed Mar 07 12:00:27 2001 +++ crypto\bf\bf_opts.c Thu Oct 30 16:52:58 2003 @@ -63,10 +63,6 @@ #define TIMES #endif +#if defined(WIN32) || defined(_W

[openssl.org #757] Missing ordinal

MingW / gcc 3.3.1 / Win-XP / OpenSSL 0.9.8-dev (29 Oct 2003) libeay32.dll is missing orinal 508 in it's export table. c:\> pedump libeay32.dll: exports table: Name:libeay32.dll Characteristics: TimeDateStamp: 3FA1832D -> Thu Oct 30 22:31:25 2003 Version: 0

Re: [openssl.org #757] Missing ordinal

"Lutz Jaenicke via RT" <[EMAIL PROTECTED]> said: > Hmm. Between OpenSSL 0.9.6 and 0.9.7, the following change was made > (see the corresponding util/libeay.num files): > OpenSSL_add_all_algorithms 508 EXIST::FUNCTION: > became > OpenSSL_add_all_algorithms 508 NOEXI

Re: [openssl.org #757] Missing ordinal

"Stephen Henson via RT" <[EMAIL PROTECTED]> said: > Now if this works in one context but not another then I'd say that one > is picking up libeay32.dll from 0.9.6 and the other 0.9.7 or later. This > will depend on the Win32 DLL directories which IIRC depend on PATH, the > current directory and a

[openssl.org #880] Client error

Using the 24 April snapshort compiled on Windows (MingW) and running: echo GET /ucgi/browsercheck.exe | openssl.exe s_client -connect www.thawte.com:443 produces these errors: Loading 'screen' into random state - done 4008:error:2507006C:DSO support routines:DSO_load:functionality not supporte

  1   2   >