Proposed Changes To Win32 Build Environment
Hello, My name is Marton Anka and I have been an OpenSSL user for quite some time. I am the CTO of 3am Labs, and our commercial products (the LogMeIn line and RemotelyAnywhere) have relied on OpenSSL since their inception. I'd like to suggest a few changes to the Win32 build process. Our goal is to: Provide a .pdb file for release builds as well as debug onesName debug libraries and dlls differently from the release buildsLink static libraries to the static C runtime, and DLL builds to the DLL C runtime The first change is to mkdef.pl. mkdef.pl can be invoked like this: perl util\mkdef.pl 32 libeay > ms\libeay32.def We've added an additional parameter that generates a module definition file for debug builds: perl util\mkdef.pl D 32 libeay > ms\libeay32d.def The resulting debug module definition file refers to the library as libeay32d (or ssleay32d) instead of libeay32 (or ssleay32). The other change is to VC-32.pl. It does not modify how the script is invoked, but changes the following: Release static builds are called ssleay32st.lib and libeay32st.libRelease DLL builds are called ssleay32.lib and libeay32.libDebug static builds are called ssleay32std.lib and libeay32std.libDebug DLL builds are called ssleay32d.lib and libeay32d.libStatic builds are linked to the static C runtime, release builds are linked to the DLL C runtimeDebug symbols (pdb files) are generated for both debug and release builds, and the pdb files are named according to the naming convention described in steps 1-4 Finally we've modified /ms/do_masm.bat and /ms/do_ms.bat so they call mkdef.pl for every possible variation: perl util\mkdef.pl 32 libeay > ms\libeay32.def perl util\mkdef.pl D 32 libeay > ms\libeay32d.def perl util\mkdef.pl 32 ssleay > ms\ssleay32.def perl util\mkdef.pl D 32 ssleay > ms\ssleay32d.def Please let me know if this could be rolled into the main codeline. I can post diffs (I presume unified format would work) or the whole files themselves. We have been applying these changes to every release of OpenSSL since the 0.9.6 days, and find them immensely useful. -Marton Anka
Adding -DOPENSSL_NO_COMP gets compile errors in s3_srvr.c
I added -DOPENSSL_NO_COMP in an effort to remove all compression, and I get the following errors when compiling ssl3_send_server_hello() in s3_srvr.c: s3_srvr.c: In function `ssl3_get_client_hello':s3_srvr.c:936: warning: assignment from incompatible pointer types3_srvr.c: In function `ssl3_send_server_hello':s3_srvr.c:1092: error: request for member `id' in something not a structure or union These have to do with the fact that s->s3->tmp.new_compression is defined as a char * when OPENSSL_NO_COMP is enabled. I can fix these errors, but I'm concerned that the ssl3_send_server_hello() is attempting to negotiate compression even though OPENSSL_NO_COMP was specified. In fact, OPENSSL_NO_COMP doesn't appear in the s3_srvr.c file at all. Is this flag up-to-date? Thanks. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Del VecchioSent: Friday, September 23, 2005 11:18 AMTo: openssl-users@openssl.orgSubject: RE: Reducing SSL3 Buffer Requirements I hacked around with the Tx buffer size in the 0.9.8 source. I took these definitions from ssl\ssl3.h: #define SSL3_RT_MAX_PLAIN_LENGTH 16384#define SSL3_RT_MAX_COMPRESSED_LENGTH (1024+SSL3_RT_MAX_PLAIN_LENGTH)#define SSL3_RT_MAX_ENCRYPTED_LENGTH (1024+SSL3_RT_MAX_COMPRESSED_LENGTH)#define SSL3_RT_MAX_PACKET_SIZE (SSL3_RT_MAX_ENCRYPTED_LENGTH+SSL3_RT_HEADER_LENGTH) And separated them into two sets; one for Tx and one for Rx. I replaced all references in the code to my new Tx/Rx versions. Then I (conditionally) redefined SSL3_RT_MAX_PLAIN_LENGTH for Tx to be 2048. It works as expected. I'm wondering about the "1024 +" values for compressed and encrypted length. A previous responder said that compression is "universally unimplemented". And I'm wondering what type of encryption would expand a 16384-byte chunk by 1024 bytes. Are these values appropriate, or are these values appropriate + a large bit extra to prevent buffer overruns? And if I change my plain-length max to 2048, what would be appropriate padding? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marton AnkaSent: Thursday, September 22, 2005 4:08 PMTo: openssl-users@openssl.orgSubject: Re: Reducing SSL3 Buffer Requirements On 9/22/05, Martin Del Vecchio <[EMAIL PROTECTED]> wrote: On the transmit side, OpenSSL currently has the ability to sendarbitrarily large messages,one 16K record at a time. Is there any harm in me deciding to sendlarge messages one 4K recordat a time?This should be perfectly fine. Implementing the "grow-on-demand" feature would be nice, but then I'd also like those buffers to shrink to their original size after a certain amount of time. This should definitely be doable, and I wouldn't mind sponsoring the development. Stephen?-Marton Anka
Re: [openssl.org #1206] FTP USER Authentication
[EMAIL PROTECTED] via RT wrote: > We use DES encryption algorithm.When the user try to add an user with > the password 12345678 ,user couldn't login. So itried printing the DES > decrypted password, it returns junk password. Since it is junk user > couldn't login. Basically we maintain a file which will have the list of > users added and their password, this is a junk user couldn't login as I still don't know what you are doing (an example source code showing the bug would be very helpful !) => it's still not really possible to help you. Anyway this sounds more like a bug in your application than a bug in the openssl code. Cheers, Nils PS: you need to reply to [EMAIL PROTECTED] as otherwise the message is not appended to the ticket. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
