Re: CRYPTO_malloc_init undefined in latest snapshot

2000-01-12 Thread Per Nilsson

There's a similar problem that I ran into when I wanted to use the debug dll
version of the runtime library: Things like file handles will also be different.
So this following piece of code will crash:

fp=fopen(cert_file,"rb");
b=BIO_new_fp(fp,0);
cert=d2i_X509_bio(b,0); == This will crash in NTDLL.DLL

Replacing the first two with BIO_new_file(cert_file,"rb") works, but what
I really wanted to do was to use _fsopen to get thread-safe access to a file
that might get updated any time by another thread.

So I propose that a new function be added to OpenSSL:
BIO_new_shared_file(char *filename,char *mode)
where mode can contain sharing modes as well as the normal r/w modes etc.

Of course if I have missed that there is something I could use to achieve
what I wanted someone will surely point it out...

/Per

- Original Message - 
From: Per Nilsson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 05, 2000 1:18 PM
Subject: RE: CRYPTO_malloc_init undefined in latest snapshot


 It needs to be a macro so malloc etc will be the ones from the program,
 and not the ones linked into the DLL. This makes a difference if the DLL
 and the program are linked against different runtime libs. Precisely the
 reason why CRYPTO_set_mem_functions should be used in those cases.
 
 /Per
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS
  Whacker
  Sent: Wednesday, January 05, 2000 10:50 AM
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]
  Subject: Re: CRYPTO_malloc_init undefined in latest snapshot
 
 
  jaltman If the LIBEAY32.DLL is linked to the MSVCRT.DLL library
  and the app
  jaltman is linked to MSVCRTD.DLL it is necessary for
  CRYTPO_malloc_init() to
  jaltman be executed by the app so that the proper memory
  jaltman allocation/deallocations routines are used.
 
  CRYPTO_malloc_init() did the following:
 
  CRYPTO_set_mem_functions(malloc,realloc,free)
 
  This in turn initialises five function pointers in mem.c.  However,
  those variables are already initialised with exactly those values.
  Logically, this makes the CRYPTO_malloc_init() macro redudant and
  needless.
 
  Is this possibly some kind of glitch in Win32 when it links things in
  runtime, or is it some other mystery?
 
  --
  Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
  Redakteur@Stacken  \ S-161 43  BROMMA  \ T: +46-8-26 52 47
  \  SWEDEN   \ or +46-708-26 53 44
  Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
 
  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]

 smime.p7s


Re: Function naming convention.

2000-01-12 Thread Dr Stephen Henson

Arne Ansper wrote:
 
 
 
 one question: do we need those _peek_ functions at all? i think
 not. and i have a proposal how to keep new library and applications
 clean and keep compatibility with older applications:
 

Well not everything has a reference count and not everything is static.

Some of the calls instead return a copy of the structure. If you do this
with everything that doesn't have a reference count you end up with lots
of needless Malloc() functions and you also have problems writing a
compatability wrapper because if you free the copy its gone.

I suppose you could add reference counts to everything but each one can
have a mutex operation associated with it and calling a mutex whenever
any kind of 'get' operation is needed even when you know there will
never be any kind of race condition is inefficient.

[side note the library only uses a small number of mutexes: for example
when you call X509_free(x) it uses a global lock for X509 instead of one
for the 'x' structure]

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: cvs commit: openssl/doc/crypto RSA_blinding_on.pod RSA_check_key.pod RSA_generate_key.pod RSA_get_ex_new_index.pod RSA_new.pod RSA_padding_add_PKCS1_type_1.pod RSA_print.pod RSA_private_encrypt.pod RSA_public_encrypt.pod RSA_set_method.pod RSA_sign.pod RSA_sign_ASN1_OCTET_STRING.pod RSA_size.pod crypto.pod d2i_RSAPublicKey.pod rsa.pod

2000-01-12 Thread Ulf Möller

On Wed, Jan 12, 2000 at 05:22:34PM +, Dr Stephen Henson wrote:

 Anyway on an unrelated note: why does the random number generator have
 to be seeded before using RSA sign/verify?

Got me. I was thinking of something else. I guess I should have checked
with the source...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Doubt about OPENSSL config file

2000-01-12 Thread Bodo Moeller

Richard Levitte - VMS Whacker [EMAIL PROTECTED]:

 raulg What is the meanig of field  
 raulg 
 raulg RANDFILE  = $ENV::HOME/.rnd
 raulg oid_file  = $ENV::HOME/.oid
 raulg 
 raulg in the openssl config file?
 raulg 
 raulg If i have the OpenSSL on a MS NT 4 PC,  what value can i assign to it?

 If you make sure that each user has a HOME environment variable, the
 above lines will work as intended.
 
 Of course, you need to make sure each user gets a *different* HOME
 :-).
 
 $ENV::foo is the notation in the configuration file to fetch the value
 of the environment variable foo.  Therefore $ENV::HOME will get the
 value of HOME...

Also you can put a definition "HOME = whatever" into the main section
of the configuration file, and it will be used if there's no
environment variable of that name (that's the usual fallback to the
default section, $ENV::HOME means "look up HOME in section ENV").  The
current development versions have "HOME = .", i.e. use the working
directory, which is a lot better than having applications fail with an
obscure error messages when HOME is not defined.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: CRYPTO_malloc_init undefined in latest snapshot

2000-01-12 Thread Dr Stephen Henson

Bodo Moeller wrote:
 
 
 I was suspicious about things like that -- and then there's this (now
 removed) note in INSTALL.W32 saying about the original SSLeay
 instructions that "some of this may be out of date and no longer
 applicable.  In particular the Crypto_malloc_init() comment appears to
 be wrong: you always need to use the same runtime library as the DLL
 itself", which would mean that Crypto_malloc_init() is not needed
 after all.  I recently asked for information on this but no-one
 replied.
 

Sorry I must have missed that message. I put that comment in. I can see
the logic behind CRYPTO_malloc_init() but I never got it to work myself. 
I tested it by linking an app with a different runtime library than
OpenSSL was compiled with, calling CRYPTO_malloc_init() then trying to
do some things. It crashed almost immediately.

I can vaguely recall someone saying that if you linked with MFC then
this did work. I haven't tried that: I avoid Win32 development whenever
possible.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



RE: Windows NT installation

2000-01-12 Thread Alex Cosic
Title: Windows NT installation





  -Original Message-From: Yuriy Stul 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, January 11, 2000 7:19 
  PMTo: [EMAIL PROTECTED]Subject: Re: Windows NT 
  installation
  Hello Alex,
   try to do next:
   In Visual Studio open Tools/Options and choose Directories 
  property. Add path G:\OpenSSL-0.9.4\inc32 (in my settings it is first 
  line!)
  
  In source I use include like next:
  #include openssl/pem
  RegardsYuriy Stul
  
  Well, 
  I did add paths for both include and library directories, and as well I added 
  library (ssleay.lib) module in project settings. In addition  I changed 
  :
  #include unistd.h with  #include 
  string.h and
  instead of  openssl/err.h I wrote 
  the "absolute path". However, still some string function are undeclared like 
  strlen, _exit, _sleep, etc. Obviously I have to add another library module, 
  but I do not know which one.
  
  Alex 
  Cosic