Building on Windows in 64 bit mode
Hello gentlemen, I am trying to build openssl 1.0.1e on windows and am running into a few problems. I hope someone will be able to help/advise. Following the instructions in INSTALL.W32 seems to work for 32 bit release mode but not for other combinations. Switching from Release to Debug does not result in the pdb files being installed via the command nmake -f ms\ntdll.mak install. I tried to build in 64 bit by running vcvarsall amd64 then following the build steps. The compilations were successful, with a few warnings about conversions, but I got a linktime error: rc /fo"tmp32dll\libeay32.res" /d CRYPTO ms\version32.rc link /nologo /subsystem:console /opt:ref /debug /dll /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\marlowa\AppData\Local\Temp\nmEFE4.tmp mp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' MAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\amd64\link.EXE"' : return code '0x458' Stop. I am on windows 7 (64 bit) using the Visual Studio 2005 compiler. Googling, I see that others have hit this problem as well: http://comments.gmane.org/gmane.comp.encryption.openssl.devel/16256 http://stackoverflow.com/questions/2559358/fatal-error-lnk1112-module-machine-type-x86-conflicts-with-target-machine-typ http://stackoverflow.com/questions/14704592/fatal-error-lnk1112-module-machine-type-x86-conflicts-with-target-machine-typ It looks to me like the 64 bit build is using some components that came out of the 32 bit build, but I am not sure. Regards, Andrew Marlow ___ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited. Please refer to http://www.bnpparibas.co.uk/en/email-disclaimer/ for additional disclosures. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
enh rqst for util/mkdir -p.pl
Guys, I would like to make an enhancement request for the script mkdir-p.pl. The project I am on is using openssl and for reasons that I won't go into the projects checkout procedure results in the creation of certain sub-directories that mkdir-p.pl is called upon to create. I would like to see mkdir-p.pl check to see if the directory already exists before it tries to create it. Regards, Andrew Marlow There is an emerald here the size of a plover's egg! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Target functionality for 0.9.8?
Please can some kind openSSL developer(s) tell me what the target functionality is for the 0.9.8 release? Judging by the mailing list there are not many outstanding problems at the moment. Does that mean that release will be delayed until there is a real problem detected, then the fix will be released in 0.9.8? The reason I ask is that I am waiting for a performance enhancement to be released that I made for using zlib compression with openSSL. The optimisation avoids repeated mallocs for successive SSL'd compressed packets. Regards, Andrew Marlow There is an emerald here the size of a plover's egg! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
openssl+zlib /MD problem
The openssl FAQ and INSTALL.W32 warn about a corruption problem if an app does not use the multithreaded DLL option /MD, given that the build of openssl uses it. However, I am seeing the exact opposite of this problem. This is a desperate appeal for help. I build openssl using the following steps: cd vcvars32 perl Configure -DZLIB -I VC-WIN32 ms\do_ms nmake -f ms\ntdll.mak This causes it to be built using /MD. I link with a ZLIB that has also been built using /MD. I get what appears to be a C++ exception upon return from SSL_write. This cannot be, since openssl is written in C. I presume that some sort of corruption occurs. When my own app links with a ZLIB that does not use /MD, the problem goes away. I notice that someone else posted that there might be memory corruptions in 0.9.7b so I tried the snapshot that was made last night. Same problem. I also tried adding a call to CRYPTO_malloc_init() as the first line in subroutine main(). Again, no effect. Any ideas? Regards, Andrew Marlow There is an emerald here the size of a plover's egg! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: weird corruption on return from SSL_write
[EMAIL PROTECTED] writes: >On Mon, Jul 21, 2003, Andrew Marlow wrote: >> I am using openssl-0.9.7b on Windoze with the Visual Studio v6 compiler >> and have found a strange problem. [ strange problem snipped ] >Only thing I can immediately think of is that ZLIB might not be compiled >to use the same multithreaded DLL runtime library. The infamous /MD issue. > >Steve. Hmm, this could be it, er, I think, maybe. What exactly *IS* the infamous /MD issue? Regards, Andrew Marlow There is an emerald here the size of a plover's egg! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
weird corruption on return from SSL_write
Guys, I am using openssl-0.9.7b on Windoze with the Visual Studio v6 compiler and have found a strange problem. Maybe someone has some idea what is going wrong. It looks like my program gets some sort of corruption on returning from SSL_write coz VS says that a C++ exception has been thrown. Clearly this is impossible so I figure some sort of corruption has occurred. The thing I am doing that is probably different to most users of openSSL is that I am using on-the-fly ZLIB compression. If I turn off the compression then the problem disappears. Has anyone else tried using ZLIB compression with openSSL? I think there may be some strange sort of interaction between the two dynamic libraries on Windoze. I get no problem on Solaris. Regards, Andrew Marlow There is an emerald here the size of a plover's egg! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RE: more spam
[EMAIL PROTECTED] writes: >At the risk of going *completely* off topic, what is TDMA in this >context? Whoops, I actually meant to say TMDA, which stands for Tagged Message Delivery Agent. See http://tmda.net for details. Regards, Andrew Marlow There is an emerald here the size of a plover's egg! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: more spam
[EMAIL PROTECTED] writes: >I've complained about this member before (and I block him as well). >Auto-responders (whether vacation or anti-spam) are totally inappropriate >on an opt-in mailing list. This sounds like TDMA to me. Does anyone know? I am thinking of using TDMA but msgs like this put me off. I realise that TDMA has some issues with mailing lists. Is anyone else here using TDMA. I prefer the idea of TDMA to spam filters since spam filters always run the risk of false positives (plus the spammers are always trying to get around filters). > >If I was the owner of the list I'd suspend him (with a friendly eMail >warning). You're a harsh man. :-) Regards, Andrew Marlow There is an emerald here the size of a plover's egg! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ZLIB compression performance improvement
Dear openSSLers, Attached is a performance enhancement to the ZLIB compression facility of openSSL. It uses the deflate API rather than the compress API to avoid repeated mallocs. I would be very interested to hear how people get on with this. It has been tested on Solaris 8 and MS-Windows 2000. Regards, apm sslfix.tgz Description: Binary data
scatter/gather buffers and SSL_write
Are there any plans to offer a scatter/gather version
of the SSL_{read,write} interface? Sometimes openSSL
is used as a component in a stream and it gets to
the openSSL bit and finds a bottleneck where a
scatter-gather buffer has to be put into one
contigous block so it can call SSL_write.
I wonder if there are any plans to extend this.
Regards,
Andrew M.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Compression: efficiency and protocol negotiation
This post is about two things: 1) I am curious to know if anyone has tried out the performance enhancement I submitted for using ZLIB with openSSL. 2) I would like to know if anything is going to be done about openSSL ignoring the compression byte during the handshake when the protocol is to be negotiated. I suspect very few people have used openSSL with compression. It was not properly supported in the build until 0.9.7. There is an outstanding problem in the handshake (see below) and the IETF has still not formally agreed on the choice of algorithm numbers. However, there must be other developers who want to be on the bleeding edge! At the moment the only way for compression to work is for the sender to say it is using a protocol explicitly (and it must be either SSLv3 or TLSv1). This is due to the fact that it has to cope with negotiation with a party that only speaks SSLv2 where the compression byte is absent. I realise that I can achieve what I want by negotiating then it it turns out we are both speaking >= SSLv3 then I can tear the connection down and start again with that protocol explicitly selected and with compression specified. But what a bother! And what counterintuitive behaviour. Surely this can be done behind the scenes. What about when TLSv2 comes along? This would disadvantage s/w that uses compression because it would be hardcoded to use TLSv1. Regards, Andrew M. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Fwd: openSSL zlib performance enhancement
Below is a patch I sent to Richard but I think he must be on holiday or something because there has been no response yet. I wonder if other openSSL developers would care to try this out. -Andrew Hello Richard, Attached is a tarfile with some minor changes to c_rle.c and c_zlib.c for a performance improvement in compression. Please consider it and let me know what you think. Basically there were some repeated allocations going on which could be done just once per context. At first I put this information in the context but then I put it in the COMP_METHOD structure (hence comp.h was changed and r_rle.c was affected to initialise it to NULL). Saving repeated heap allocates when compressing lots of relatively small packets really seems to make a dramatic difference. Regards, Andrew M. ossl.tgz Description: Binary data
Re: ssltest and on-the-fly ZLIB compression
[EMAIL PROTECTED] writes: >* Andrew Marlow ([EMAIL PROTECTED]) wrote: >> >> I have done some more investigation and have found that ssltest >> will compress when the TLS1 protocol is explicitly selected. > >I also took a look - it seems the problem is the v23 SSL/TLS method, >it's there to provide a handshake that can negotiate any protocol level, >but it also seems to preclude any negotiation of compression. This is what we find :-( Running ssltest and explicitly selecting the protocol to be other than sslv2 seems to work. >As for why - this could be impossible to get around because of the >implicit constraints of SSLv2 compatibility, I'm not sure. Certainly if >you use the SSLv3 or TLSv1 client methods (and thus give up on talking >with any SSLv2 servers), then you'll probably be OK w.r.t. compression >unless you hit an SSLv2 server. I reckon you are right. >The crap way to address this (something >Lutz mentioned in another thread) is to try connecting with an >SSLv3/TLSv1 method first and if that fails on protocol troubles, retry >with SSLv2. Yes I know, bleurgh. > >Cheers, >Geoff Not ideal but it should work. That's great Geoff, thanks for looking into this, my app now works! Regards, Andrew M. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ssltest and on-the-fly ZLIB compression
[EMAIL PROTECTED] writes: >In message ><[EMAIL PROTECTED]> on Wed, >15 Jan 2003 17:55:05 +, Andrew Marlow <[EMAIL PROTECTED]> said: > >apm35> I have received a disappointing response to this query so far. > >Here's a less disappointing one: I'm looking into it. I've observed >the same as you, that the compression methods aren't called... I have done some more investigation and have found that ssltest will compress when the TLS1 protocol is explicitly selected. So this could all be a mistake on my part. I assumed that on-the-fly-compression was available with ssl version 3 and later. According to RFC 2246 the compression code is an integral part of the TLS v1 standard (although the numbers still have to be formally agreed). It does not seem to be mentioned in the original Netscape SSL v3 document. I note that the compression byte is sent when using the SSL v3 protocol but the value is always zero. The question is: should this byte be there and if so, does that mean that openSSL is wrong not to set it when SSL_COMP_add_compression_method has been called? Regards, Andrew M. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ssltest and on-the-fly ZLIB compression
This post is about my attempts to discover why
the ssltest program does not use compression when -zlib
is given on the command line. My openSSL is version 0.9.7
and was built via the command './Configure shared zlib'.
I have proved that compression does not occur.
I proved it via trace statements in z_clib.c.
The trace is never executed. The performance is
the same whether or not -zlib is given on the
command line.
I have received a disappointing response to this query so far.
I am grateful that people have responded but the responses
have been along the lines of 'use 0.9.7' and 'make sure
you say 'Configure shared zlib'. Well I am and I have
but it doesn't work. What follows below is my attempt
to analyse the code. Hopefully this will shed light as
to what is wrong.
Compression happens if s3->tmp.new_compression
points to a compression method structure.
It never does. There are FOUR files that use
this variable; s3_clnt, s3_srvr, s3_enc and t1_enc.
We will deal with each in turn:
s3_clnt
===
in ssl3_connect for the states SSL3_ST_CW_CHANGE_{A,B}
when there is a change of cipher spec.
in ssl3_get_server_hello where it reads the compression
algorithm number set by the server. It looks up the algorithm
in its own structures if the incoming algorithm number is
non-zero. The server always sends zero.
s3_srvr
===
in ssl3_get_client_hello where it reads the compression
algorithm number set by the client.
In ssl3_send_server_hello after putting the cipher byte
it sends the compression algorithm byte if new_compression
is non-null (otherwise it sends zero). When it checks
new_compression it is null all the time.
s3_enc
==
It is examined in ssl3_change_cipher_state.
ssltest does not call this function but even if it did,
new_compression still has not been set.
In ssl3_setup_key_block it does do a lookup using
ssl_cipher_get_evp. It looks like this is what
should happen. However, ssl_setup_key_block
is not called! (in ssltest).
t1_enc
==
It is examined in tls1_change_cipher but
ssltest does not call this function.
IMO the ssltest program should end up calling either
ssl3_setup_key_block or ssl3_change_cipher_state.
I am not absolutely sure about this, since it does
not enter any state for which this would be the
correct thing to do, but it seems the only way
it is going to get the compression method established.
Please help me.
Regards,
Andrew M.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: openSSL 0.9.7 and COMP_{zlib,rle}
[EMAIL PROTECTED] writes: >In message ><[EMAIL PROTECTED]> on Wed, >15 Jan 2003 10:20:46 +, Andrew Marlow <[EMAIL PROTECTED]> said: > >apm35> I would like to report a bug in openSSL version 0.9.7. >apm35> I cannot get on-the-fly compression to work using >apm35> SSL_COMP_add_compression_method. [snip] >Actually, the way it's done in 0.9.7, there should be no need to call >SSL_COMP_add_compression_method() at all (i.e. there should be no need >at all for the -zlib flag in ssltest). Maybe, but SSL_COMP_add_compression_method is used by ssltest and if I go and do likewise then I should get the same result and the result should be that on-the-fly compression is performed. > >However, for this to work, you MUST configure with the options 'zlib' >or 'zlib-dynamic'. Something like this: > > ./config zlib Indeed. If I don't then the macro ZLIB is not defined and compilation chaos ensues. I *have* configured the build this and for good measure I have hacked c_zlib.c to force on the macros ZLIB and DEBUG_ZLIB. I have also added additional trace statements. Use of ZLIB is definately on. However, the compress/uncompress functions do not get called. The variable 'j', used to denote whether the SSL message has been compressed, is always set to zero. If you force it on then the ZLIB trace is executed but this is an extreme hack. The question is "why does ssl_lib decide that compression is not required?". >If you want to trace the actual calls, you should do it in >crypto/comp/c_zlib.c. Done that. > >I'm pondering making 'zlib-dynamic' the default instead of 'no-zlib'. >Does that sound like a good idea. It does to me for a couple of reasons: 1) you can always turn it off, if you don't want it. Given how common zlib and dynamic libraries are these days it seems like a reasonable default to me. 2) Just because compression support is there doesn't mean you *have* to use it. What it means is that the build >environment must have zlib.h reachable by the compiler. We *could* >have a copy of the relevant lines from zlib.h as part of OpenSSL... No. Sod's Law says the same information held in 2 different places *will* be different. If we include the real zlib.h then we would have to do what most automake/autoconf configuration procedures do, and that is to check that zlib is available and fail to produce Makefiles if it is missing (unless --zlib=no has been specified). Regards, Andrew Marlow. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
openSSL 0.9.7 and COMP_{zlib,rle}
I would like to report a bug in openSSL version 0.9.7.
I cannot get on-the-fly compression to work using
SSL_COMP_add_compression_method. The performance
of the ssltest program is the same with or without
the -zlib command line option. My own program behaves
in a similar way. I have added trace to the ZLIB compress
function and the trace does not come out. By hacking the
code of s3_{clnt,srv} to force it into thinking that
compression is being used the trace statements DO get
executed, but just by calling SSL_COMP_add_compression_method
they do not.
I understand that as of 0.9.7 SSL_COMP_add_compression_method
is all that is needed (i.e no explicit negotiation is
needed unlike 0.9.6) but I do not think it is working
properly.
Regards,
Andrew Marlow.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
shared library not built on linux
Hello, an earlier msg in this archive indicated that there are problems building libssl.so on linux-sparc but I have the same problem just building the shared library on a linux PC. Has the issue of silently not building a shared library even went it has been explicitly asked for been addressed yet please? regards, Andrew Marlow. On Mon, Jun 17, 2002 at 11:44:28AM -0700, Rodney Thayer wrote: > There are other combinations where shared libs don't build. > For example, if you do "./config -d shared" you don't > get shared libraries (RedHat 7.2 Intel). [snip] Shared libs are only built, if the "shared_target" is being set in Configure. This is e.g. the case for some but not all of the debug targets. [snip] Silently ignoring it indeed is not a good policy. Please file an official bug report to [EMAIL PROTECTED], so that the issue is added to the request tracker. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
