Re: PadLock engine SHA1 support
Andy, Ping :-) Did you have time to look at this patch? Should I add/fix something? Thanks! Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1230] static(no-shared) build for VC-32 have wrong codegeneration option
Once again I want to remind openssl-dev subscribers that if you want to make sure that originator of RT tickets, such as this one, receives your comment, reply to [EMAIL PROTECTED], not openssl-dev. Trouble is that RT ticket originator isn't necessarily subscribed to openssl-dev, rather contrary. ** Reply to note from Konstantin Sharenkov via RT [EMAIL PROTECTED] Wed, 26 Oct 2005 11:36:41 +0200 (METDST) Hi, The originator can find the reast of the comment at e.g. http://marc.theaimsgroup.com/?l=openssl-devm=113054929431715w=2. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
CRYPTO_thread_setup CRYPTO_thread_cleanup
Hello guys, I have a problem in implementation of CRYPTO_thread_setup() and cleanup functions. I've already implemented an application which consists of 4 thread. Each thread of those 4 spawns 100 other threads with different gsoap clients. The problem is that I can't separate some Openssl calls such as CRYPTO_set_id_callback, CRYPTO_set_locking_callback, CRYPTO_set_dynlock_create_callback to be different for each of those 4 threads. If I use one CRYPTO_thread_setup and one CRYPTO_thread_cleanup only in one of the threads I will have memory leaks in the other threads. How can I have 4 different openssl environments with its own CRYPTO_* fucntions? Regards, marios __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1230] static(no-shared) build for VC-32 have wrong codegeneration option
but nt.mak contins line CFLAG= /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_KRB5 The first option is /MD - Multithreaded DLL code generation But for static library option should be /MT Multithreaded code generation Not really, IMHO. Note that /MD or /MT is just about whether you want your (static) library to be used with the static C library or with the DLL. One can actually argue that originator might have a viable point! Well, I [also] disagree with formulation, /MD being *wrong*, but one can argue that /MT is simply *more versatile*! Let's just take a level below and figure out what *exactly* /MD vs. /MT means... At the upper level /MD means define _DLL and _MT at compile time and link with MSVCRT at link time, right? At the object module level it effectively means adhere to MT-safe API, prepend CRT functions with __imp__ prefix and tag object module with -defaultlib:MSVCRT. It should be explicitly noted that _DLL macro is effectively responsible for __imp__ prefix. Now what's the deal with /MT? It means define _MT at compile time and link with LIBCMT at link time, right? At the object module level it effectively means adhere to MT-safe API, call CRT functions by *undecorated* name and tag the object module with -defaultlib:LIBCMT. What happens if you try to mix object modules compiled with /MT [from application] and with /MD [from library]? Would it pull in MSVCRT to resolve __imp__ references from library and LIBCMT by means of of -defaultlib from application objects? Appears so... Would it have side effects? Yes, it would... Is there right thing to do? Hmmm What happens if you try to link undecorated symbol, one without __imp__ prefix, against MSVCRT? It's not a problem! Linker will transparently pull in a small stub for every CRT function you call, which would relay say _printf to __imp__printf! Would it work other way around? No! So wouldn't it be appropriate to say that it's actually more versatile option to generate static lib with /MT, i.e. without __imp__-prefixed symbols, and allow application developer decide which library, MSVCRT or LIBCMT, he wants to link with? Yes. But there is a pitfall! Application developer may no longer depend on /MT or /MD at link time, but instead link with /LINK /NODEFAULTLIB[:LIBCMT] and *then* pick either LIBCMT.LIB or MSVCRT.LIB, whichever appropriate. Well, only MSVCRT developer would actually have to bother... In other words. One can actually argue that it's more appropriate to generate static library with /MT instead of /MD, but given that MSVCRT application developers adhere to /LINK /NODEFAULTLIB:LIBCMT MSVCRT.LIB upon target application link. Further opinions? BTW, is there a way to prevent compiler from tagging object module with *any* -defaultlib? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
But I'll take up the cue and see what we can do that works everywhere. Then it would have to be the least common denominator: 97, 98, 100 or independent numbers such as 1, 2, 3. The above was referring to file suffixes. It should be noted that there're platforms, which has no notion of versioning through file suffix, most notably Windows. The only way to get it working on Windows and similar platforms [if any] would be to encode the version into .DLL file name, e.g. crypto098.dll, ...099.dll, ...100.dll [note that at least in Windows context it doesn't prevent us from calling corresponding .lib import library for crypto.lib]. In other words least common denominator would be embedding version number into shared object file name, not its extension. As it's unlikely to be accepted that Unix developers would have link with -lcrypto100, we're stuck with multiple versioning schemes in either case:-( On a side note in respect to problem with cross-polution of global name table from different versions of OpenSSL. Windows would be free from this, because import tables are private to every mapped module, meaning that two modules, one linked with 0.9.7 and another with 0.9.8, would not interfere with each other. Just a side note! A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PadLock engine SHA1 support
Ping :-) (-: Pong Did you have time to look at this patch? No, unfortunately. Are you in hurry? If yes, what's the hurry? Should I add/fix something? Windows support:-) SHA-224 [which differs from SHA-256 only by initial constants and truncated output]. Test programs [extra -e argument perhaps]. BTW, what's the deal with padlock engine in ./config -shared configuration? It doesn't seem to be there... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1218] Status
(2) after install, note: for v0.9.8a: otool -L libssl.dylib: libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/local/lib/libgmp.3.dylib (compatibility version 7.0.0, current version 7.3.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0) v098x builds, for whatever reason, are MISSING the /usr/local/ssl/lib install_name prefixes to the libssl/libcrypto libs. this causes all SORTS of downstream probs ... If you want better response time be more specific describing problems. Even if appears selfobvious to you. Point is that without [daily] access to MacOS X and massive hands-on experiense all SORTS have very little [if any] meaning. Describe at least one problem in more tangible terms. Check tomorrow snapshots as they become available. The case is being dismissed. Well, above was poorly worded. Let me rephrase. 1. The problem is [beleived to be] fixed now. Download and verify a snapshot from ftp://ftp.openssl.org/snapshots/. 2. For better response time *next time* be more specific describing problem. Keep in mind that some targets are community supported. This means that if support for some target was originally submitted by a list subscriber and later related problem report contains any sign of platform-specific lingo, which is not directly recognized by the team, then we kind of expect other [ideally original] subscribers to audit the suggestion and speak in its favor or suggest better solution. The way around it is to get rid of lingo, avoid expressions like go slap them, etc., but instead describe the problem in tangible terms [like application fails to start with this message], present system call traces, quote manual page, refer to on-line documentation, in other words whatever it takes for a person without daily hands-on experience on given platfrom to *judge* the problem and recognize the proposed solution as appropriate. the problem is that applications i'm attempting to link to openssl 0.9.8 -- without these install_name prefixes -- either (a) do not 'find' the lib, despite an LDFLAGS/CPPFLAGS specification, or (b) incorrectly select the Apple-bundled libs on /usr. Can you elaborate on (b)? Can you actually confirm that MacOS X application dynamically linked with 0.9.8 can at run-time end up linked with Apple-bundled 0.9=8 dylib? If yes, can you speculate on or figure out and tell how it happens? This has everything to do with Shared library version numbers thread on openssl-dev, where I mention that it's believed that it can't take place om MacOS X [because OpenSSL encodes full version number into MacOS X analog of DT_SONAME field]. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1218] Status
the problem is that applications i'm attempting to link to openssl 0.9.8 -- without these install_name prefixes -- either (a) do not 'find' the lib, despite an LDFLAGS/CPPFLAGS specification, or (b) incorrectly select the Apple-bundled libs on /usr. Can you elaborate on (b)? Can you actually confirm that MacOS X application dynamically linked with 0.9.8 can at run-time end up linked with Apple-bundled 0.9=8 dylib? I mean Apple-bundled 0.98 dylib, *not* 0.9=8. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
... in PAM case I can imagine problem with GLOBAL_OFFSET_TABLE being cross-polluted by 0.9.7 and 0.9.8 being *both* mapped into same application. Is it the case? Can you elaborate on which symbols were overloaded? You can figure this out by examining dynamic name tables *in pam modules* with objdump -T. If you want an example of things breaking because of the transition from 0.9.7 to 0.9.8, look at: http://bugs.debian.org/334180 In this case, libpq (from postgresql) was linked to libssl0.9.7, and dovecot was linked to libpq and libssl0.9.8. In other words it's exactly the case of cross-pollution of name space by indirect link with different versions of OpenSSL .so. Thanks to -Bsymbolic at least libcrypto.so.0.9.7 doesn't affect libcrypro.so.0.9.8, but libcrypto.so.0.9.7 can affect libssl.so.0.9.8 [and/or vice versa]. For the record. I reckon that -Bsymbolic is more than appropriate in OpenSSL context as it prevents overloading of inner calls by another module. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
move to SVN?
At work I use SVN. It's much better then CVS (IMHO). When will OPENSSL move to SVN? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PadLock engine SHA1 support
Andy Polyakov wrote: Did you have time to look at this patch? No, unfortunately. Are you in hurry? If yes, what's the hurry? No I'm not. I just wanted to move forward... Should I add/fix something? Windows support:-) Uh, eh, ... afterall I don't have a machine to test it on. SHA-224 [which differs from SHA-256 only by initial constants and truncated output]. I see. I'll look at it and send you the patch. Test programs [extra -e argument perhaps]. ... to enable engines? Could be. But should it be run automatically during make? I guess no... BTW, what's the deal with padlock engine in ./config -shared configuration? It doesn't seem to be there... A. I don't know. I don't know much about the support infrastructure for engines. Any pointers where to look? Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PadLock engine SHA1 support
Test programs [extra -e argument perhaps]. ... to enable engines? Yes. On the other hand I suppose one can write a script, which would simply call 'openssl dgst -sha[1|256] -engine padlock' with a set of known input vectors... Could be. But should it be run automatically during make? I guess no... No, but I'd like to *see* some test program and I'd like to hear explicit statement that the implementation passes this test. As you might recall we have tested AES by encypting with software and decrypting with engine and then other way around. We need something even this time:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: move to SVN?
In message [EMAIL PROTECTED] on Mon, 31 Oct 2005 22:27:30 +, [EMAIL PROTECTED] [EMAIL PROTECTED] said: kent At work I use SVN. kent It's much better then CVS (IMHO). kent kent When will OPENSSL move to SVN? Personally, I'd rather it moved to monotone (http://www.venge.net/monotone/). SVN just doesn't go far enough to be a good enough replacement for CVS, in my opinion. Cheers, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
