RE: Alternate RAND_poll for XP/2003 Server/Vista
Hi Jack, I don't have huge issues with it myself (in terms of entropy generation, CryptGenRandom has been fairly painless compared to some other mechanisms), but CryptoAPI is somewhat big, and there are various annoyances, such as the fact that repeatedly initializing and shutting down CryptoAPI causes a large memory leak on some older systems. Can you elaborate on the situation where repeatedly initializing and shutting down CryptoAPI causes a large memory leak, particularly why you needed to do this. I raised a similar issue where OpenSSL suffers such a leak (though not large) and was told it was an unrealistic scenario. I couldn't think of a great example on the spot, but given the dynamic plugin architecture of large apps it's something that I feel needs addressing. Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Alternate RAND_poll for XP/2003 Server/Vista
That's an interesting blog article. The 2nd comment
is by the author and lists the entropy sources. I recall there was
discussion on this list quite some time ago where it was stated that OpenSSL
wouldn't use only the CryptoAPI random number generator since Microsoft hadn't
provided details of how the entropy was gathered. Perhaps the information
in that post provides enough detail to warrant dropping all of the heap walking
guff that has been known to trip up OpenSSL on occasion.
Adria, RAND_poll already calls CryptGenRandom doesn't
it? You could probably just comment out all of the other code to get the
same result.
Steven
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adrià
MassanetSent: Thursday, 1 December 2005 11:41 PMTo:
openssl-dev@openssl.orgSubject: Alternate RAND_poll for XP/2003
Server/Vista
Hi
all,
Im using
OpenSSL as a module in PHP (php_openssl), and I need to call the CGI page may times per
second
but the
initialization process in RAND_poll is too slow.
Im
thinking to modify OpenSSL to use the rtlGenRandom call available in XP/2003 Server/Vista OSs
(see http://blogs.msdn.com/michael_howard/archive/2005/01/14/353379.aspx
for comments on rtlGenRandom
)
the new
function likes:
int RAND_poll()
{
if_any_error_in_block_return_old_RAND_poll()
{
HMODULE
hlib;
BOOLEAN
(APIENTRY *rtlgenrandom)(void*, ULONG);
char
buffer[1024];
int
c;
hlib=(HMODULE)LoadLibrary("ADVAPI32.DLL");
tlgenrandom=(BOOLEAN
(APIENTRY *)(void*,ULONG))GetProcAddress(hlib,"SystemFunction036");
for(c=0;c1+(ENTROPY_NEEDED/sizeof(buffer));++c)
{
rtlgenrandom(buffer,sizeof(buffer)):
RAND_add(buffer,sizeof(buffer),sizeof(buffer));
}
}
}
a bad idea? Any
thing bad here?
Thanks in
advance,
Adrià
RE: Alternate RAND_poll for XP/2003 Server/Vista
Two sentences after that one are these: To form the seed for the random number generator, a calling application supplies bits it might have-for instance, mouse or keyboard timing input-that are then added to both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is SHA-1 hashed, and the output is used to seed an RC4 stream, which is then used as the random stream and used to update the stored seed. So although all processes access the same PRNG it seems that there is provision to mix it up a little. I imagine that an installed Cryptographic Provider could provide its own PRNG and Windows could be configured to use that instead. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Corinna Vinschen Sent: Friday, 2 December 2005 7:59 AM To: openssl-dev@openssl.org Subject: Re: Alternate RAND_poll for XP/2003 Server/Vista On Dec 1 12:43, Rick Jones wrote: Corinna Vinschen wrote: I'm wondering about this anyway. While the exact code of CryptGenRandom isn't open source, MSDN has a quite extensive description how the random numbers are generated by CryptGenRandom, see the Remarks section in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secc rypto/security/cryptgenrandom.asp which also talks about the entropy sources used. Being otherwise blissfully ignorant of things Windows, does this snippet from the URL above: With Microsoft CSPs, CryptGenRandom uses the same random number generator used by other security components. imply that CryptGenRandom might be satisfied by code other than that from Microsoft described in the URL above? You omited the next sentence: This allows numerous processes to contribute to a system-wide seed. I understand this as every process using one of the Microsoft CSPs will internally access the same random number generator. As if, say, every process uses /dev/random on Linux. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Alternate RAND_poll for XP/2003 Server/Vista
CryptGenRandom is available on all Windows back to Windows 95. RtlGenRandom is only available since XP, however CryptGenRandom makes use of it. Presumably RtlGenRandom has always been around, it's just never been documented or made generally available until now. Why is there a reluctance to deal with CryptoAPI? I've used CryptGenRandom in my own code and never had a problem with it. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jack Lloyd Sent: Friday, 2 December 2005 6:04 AM To: openssl-dev@openssl.org Subject: Re: Alternate RAND_poll for XP/2003 Server/Vista On Fri, Dec 02, 2005 at 12:45:44AM +1100, Steven Reddie wrote: That's an interesting blog article. The 2nd comment is by the author and lists the entropy sources. I recall there was discussion on this list quite some time ago where it was stated that OpenSSL wouldn't use only the CryptoAPI random number generator since Microsoft hadn't provided details of how the entropy was gathered. Perhaps the information in that post provides enough detail to warrant dropping all of the heap walking guff that has been known to trip up OpenSSL on occasion. That wouldn't work if you still wish to support Windows systems prior to XP/2003 - and I know for a fact that people are still deploying new code on NT4 right now, so that decision might be unpopular. That's not to say it is not the right decision (personally I'd love to forget supporting Windows XP/2K3, just as I don't have to make sure my code works on RedHat 5.0 or HP-UX 9), but certainly it will cause complaints. Also, in theory, CryptGenRandom can be better than the new function, since, *if* you have a alternate crypto provider (such as one that pulls in entropy from the old i810 motherboard RNG, or an HSM, or whatever) you might get a better entropy source. Now, the question is if that benefit is worth the overhead and mess of dealing with CryptoAPI... I would tend to say it is not, because so few people will actually have such special hardware/providers installed. But it is worth considering. -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [PATCH] Support for Windows Mobile (on device Console)
The approach I took with wcecompat and integration with OpenSSL was to make OpenSSL have as little special knowledge of CE as possible. This means that wcecompat emulates missing ANSI/Posix functionality so that OpenSSL simply continues to program to the standard interfaces. Wcecompat should be replaceable with very minor changes to OpenSSL, hopefully only where $WCECOMPAT is referenced in VC-32.pl. The submitted patches referenced in the email below are much larger than I'd expect and so I suspect that they were either performed on unclean trees or some files were reformatted or saved with different end-of-line encodings (there are hugh diffs to makefile.bak for example). It makes it difficult to see precisely what changes were made. BTW, I recall that the original version of the CE support in mozilla was using my wcecompat library, although the code looks very different now. So we seem to be talking about integrating two different versions of wcecompat into OpenSSL. Not that there's anything special about my library, but what's the solution should a few more groups want their own CE compatibility layer included? Assuming they all do little more than provide the missing ANSI/Posix functionality then the only changes they should require to OpenSSL (above what have already been made) are to reference the new library in VC-32.pl and select it via config/Configure. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Wednesday, 2 November 2005 1:03 AM To: openssl-dev@openssl.org Subject: Re: [PATCH] Support for Windows Mobile (on device Console) [Code and binaries can be downloaded from http://www.it.uc3m.es/pervasive/wce_lite_compat/ ] This patch makes some fixes to the last OpenSSL official version 0.9.8a. First of all you have to realize that we're reluctant to accept functional patches to released code. Meaning that if you want to see your submission in official OpenSSL distribution, then you *have to* target HEAD branch, not 0.9.8. When we see it working in HEAD, *then* one can discuss back-port to released code base [if of actual interest by that time]. Now as for submission itself. As far as I can tell it essentially boils down to following things. 1. Tiny patches for missing _IONBF definition, #define ftime _ftime, int _fmode declaration in apps/apps.c, #include stdlib.h in couple of places... All in additional #ifdef WCE_ON_DEVICE_CONSOLE/#endif. 2. wce_lite_compat which implements open/read/write/close and stat. 3. Duplicate code in VC-32.pl to allow for extra WCE_ON_DEVICE_CONSOLE and link PortSDK, generate separate makefile for the target. Well, I still fail to see why either is necessary. Still refers to the fact I've earlier commented on submission from you, guys, in similar manner, i.e. why do you want to treat your target so special? Think in more general terms! As for 1. I'd rather #ifndef _IONBF affected code; implement own ftime on all CE [or use some WIN32 API on all WIN32! say GetSystemTime]; get rid of _fmode altogether; #include stdlib.h unconditionally... As for 2. I'd rather eradicate all references to open/read/write/close as well as stat for all Windows CE. It's perfectly possible! As for 3. I'd rather check for an environment variable, say PORTSDK, and emit makefile which would link with it without duplicating code or separate makefile. This way it would be possible to reduce build instructions to setup either WCECOMPAT or PORTSDK environment variable, but not both, and compile. How does it sound? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: ideas on replacing where ERR_STATE is stored?
Michael, What does the thundering herd problem have to do with select vs poll? The only typically useful advantages of poll over select that I am aware of are that poll can monitor more descriptors than select and that it can monitor a large number of descriptors more efficiently -- but this efficiency issue has nothing to do with thundering herd. I'm having trouble with the context here. Rich is talking about simply using select/poll to monitor multiple sockets. Thundering herd is a problem when a large number of threads are monitoring the same events. While select/poll can be used in such a way that thundering herd can be a problem, for the simple single-thread select/poll loop it just isn't in the picture -- how can a single thread suffer from the thundering herd problem? Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Sierchio Sent: Tuesday, 18 October 2005 2:49 AM To: openssl-dev@openssl.org Subject: Re: ideas on replacing where ERR_STATE is stored? Steven Reddie wrote: Hi Michael, I'm familiar with that approach, having used it many times myself. The choice of poll over select isn't important since they're basically the same; in fact, poll is sometimes implemented with select. Who implements poll with select should suffer a fate worse than death -- waking up a thousand sleeping threads to see if one has some i/o ready is what poll was designed to avoid. But that's just my opinion... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: ideas on replacing where ERR_STATE is stored?
Hi Michael, I'm familiar with that approach, having used it many times myself. The choice of poll over select isn't important since they're basically the same; in fact, poll is sometimes implemented with select. I was originally thrown by threads are re-used and the reference to worker threads since the select/poll approach is independent of threadedness and in fact is typically used in single-threaded code. Re-using worker threads sounded more like what happens when a worker thread is finished a job and picks up the next one from a queue, and in that case ERR_remove_state() does the job perfectly just the way it is. I see what Rich is getting at though since he means select/poll, it just wasn't clear at the beginning. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Sierchio Sent: Friday, 14 October 2005 3:07 PM To: openssl-dev@openssl.org Subject: Re: ideas on replacing where ERR_STATE is stored? Steven Reddie wrote: Do you mean using select() to handle multiple simultaneous connections? I'm late in catching this thread, but I'll wager that Rich would use poll rather than select, or /dev/poll, or some such. The model he describes is the most efficient, but makes application programming harder - essentially trading off the ease of single-task worker threads for higher performance, but having to write a state machine. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: ideas on replacing where ERR_STATE is stored?
Ok, the reference to worker threads threw me. Your fix seems not so much related to whether the application is single- or multi-threaded, but for, in effect, cooperatively multitasking jobs within a single thread; ie. you want finer grained control to track error state for jobs (however you choose to define them) rather than threads? -Original Message- From: Rich Salz [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 September 2005 12:15 AM To: Steven Reddie Subject: Re: ideas on replacing where ERR_STATE is stored? Do you mean using select() to handle multiple simultaneous connections? basically, yes. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: ideas on replacing where ERR_STATE is stored?
Rich, How do you mean that the scheme doesn't work with worker threads? Doesn't judicious use of ERR_remove_state overcome any problems of a new job on a given thread remembering the error state of the previous job(s)? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Salz Sent: Wednesday, 28 September 2005 1:30 PM To: openssl-dev@openssl.org Subject: ideas on replacing where ERR_STATE is stored? An ERR_STATE block (crypto/err.c) is stored in a global hashtable keyed by thread-id. If threads are re-used (like the windows worker thread concept), this scheme doesn't work. It looks like replacing the internal int_thread_get_item/int_thread_set_item pair, or the higher-level ERR_get_state/ERR_remove_state pair is the way to go. The complications are (1) the code tries very hard to not expose any functions or function-dispatch structures; and (2) I need to do this at startup-time, and the code tries VERY hard to make err_fns_check calls all over the place -- that latter part means replacing the ERR_get/remove_state seems like the cleaner solution. Attached is a proposed diff. Any comments? /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: ideas on replacing where ERR_STATE is stored?
Do you mean using select() to handle multiple simultaneous connections? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Salz Sent: Wednesday, 28 September 2005 2:28 PM To: Steven Reddie Cc: openssl-dev@openssl.org Subject: RE: ideas on replacing where ERR_STATE is stored? How do you mean that the scheme doesn't work with worker threads? Doesn't judicious use of ERR_remove_state overcome any problems of a new job on a given thread remembering the error state of the previous job(s)? That's a re-usable worker-thread model. Another model is to have n threads, where n is the number of CPU's in the system and use non-blocking I/O to pick up and put down multiple SSL sessions within a single thread. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: openssl for windows mobile
Windows CE has been supported since OpenSSL 0.9.7. Some post 0.9.8 patches seem to have fixed some issues that were preventing eVC4 from being used. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erich Titl Sent: Thursday, 22 September 2005 11:39 PM To: openssl-dev@openssl.org Subject: openssl for windows mobile Hi I know there was a thread a while ago concerning openssl for windoze mobile. Has this become reality in the meantime? Thanks Erich Titl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: openssl for windows mobile
There is no official binary package available, but maybe someone on the list can help. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erich Titl Sent: Friday, 23 September 2005 1:10 AM To: openssl-dev@openssl.org Subject: Re: openssl for windows mobile Steven Reddie wrote: Windows CE has been supported since OpenSSL 0.9.7. Some post 0.9.8 patches seem to have fixed some issues that were preventing eVC4 from being used. Thanks for the info, do you know if anyone has a binary package available, else I will have to dig in embedded VC++ Thanks Erich __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: openssl for windows mobile
OpenSSL 0.9.7 does support Pocket PC (the original and Pocket PC 2002 editions), in fact it should work with anything that eVC3 supports. I think it was Pocket PC 2003 that first required eVC4 and so that release was not supported until the recent post-0.9.8 patches. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Díaz Sánchez Sent: Friday, 23 September 2005 1:23 AM To: openssl-dev@openssl.org Subject: RE: openssl for windows mobile Windows CE is supported since 0.9.7 but no support is given to Pocket PCs or Windows Mobile editions. Windows CE, surname CE: compact edition, is a huge operating system for a Mobile device. To use windows CE in mobiles devices and Mobile phones, profiles named as Mobile or PocketPC has been developped using a subset of Windows CE. A manufacturer uses a tool called Platform Biulder to create a reduced version of Windows CE to be used with his products, there is no guarranty at all that products from different manufacturers with the Windows Mobile label supports the same services, APIs, drivers... To compile and use OpenSSL for Windows Based limited devices (profiles Mobile or Pocket PC) look for a mail i sent about a month ago that helps using eVC4 and specific SDKs to build OpenSSL for Windows Mobile devices: somtehing that works for windows CE does not neecessary works for Windows Mobile or Windows Pocket PC. Appart from that i am porting version 0.9.8 but version 0.9.6 is working. Daniel *´¯`*.¸¸.*´¯`*.¸¸.*´¯`*.¸¸.*´¯`*.¸¸.*´¯`*.¸¸ Daniel Díaz Sánchez /Univ.Carlos III Investigador /Depto.Ing. Telematica [EMAIL PROTECTED] /Edif.Torres Quevedo www.it.uc3m.es/dds /Avd.dela universidad,30 Tlf: 916248816/Leganes,Madrid, 28911 `*.¸¸.*´¯`*.¸¸.*´¯`*.¸¸.*´¯`*.¸¸.*´¯`*.¸¸.*´ -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Steven Reddie Enviado el: jueves, 22 de septiembre de 2005 16:26 Para: openssl-dev@openssl.org Asunto: RE: openssl for windows mobile Windows CE has been supported since OpenSSL 0.9.7. Some post 0.9.8 patches seem to have fixed some issues that were preventing eVC4 from being used. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erich Titl Sent: Thursday, 22 September 2005 11:39 PM To: openssl-dev@openssl.org Subject: openssl for windows mobile Hi I know there was a thread a while ago concerning openssl for windoze mobile. Has this become reality in the meantime? Thanks Erich Titl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Safety of using OpenSSL from multiple components in the one process
Hi All, This is something that I think I've raised before but don't remember getting resolution on. OpenSSL maintains various global variables and structures, and there are cleanup functions that must be used to properly release the resources when finished. One example is the OID database managed by the "add_all_algorithms" function and it's associated release function, EVP_cleanup. All is good when the use of OpenSSL is fairly simple, such as a single component using it for the lifetime of the process. Where things get difficult/dangerous is when multiple seperate components in the one process, withno real knowledge of each other,make use of OpenSSL, and it's even worse if they dynamically load and unload OpenSSL using dlopen/LoadLibrary. With large enterprise applications this is a common situation since different teams develop components that the large product makes us of, and with the increasing use of "plug-in" architectures the dynamic loading/unloading is not uncommon. There seems to be no way offered by the OpenSSL API for these components to behave well. If they each do a dlopen - dlsym - ... - EVP_cleanup - dlclosesequence then it seems that they will trample on each other. If they take the extreme opposite and don't call EVP_cleanup then the process will leak until it falls over. This is a serious issue that I believe impacts the stability and therefore limits the usefulness of OpenSSL in large enterprise applications. Does anyone else have any thoughts on this? Regards, Steven
RE: mk1mf.pl doesn't generate makefile for Windows CE
Satoshi Nakamura wrote: And I'm thinking of creating a list which includes: 1. Environment variables which are set by the batch file. 2. Compiler/Linker options which are set by IDE and how they are expanded. for each major platform and cpu. Hi Satoshi, I did this a couple of years ago (probably pre-wce420), extracted the compiler/linker flags, and put the knowledge into a revamped wcedefs.mak. I don't recall whether I kept the original data. I'll try to dig it up and forward it on. Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safety of using OpenSSL from multiple components in the one process
Ah, the namespacing issue we've discussed
previously.
The module that Imanage at CA
isa higher-level library that adds a
similar abstraction layeras yours, but there's now an internal requirement
to make the underlying OpenSSL interface also available to internal
developers. This was originally allowed for Open Source components that
use OpenSSL (OpenLDAP, Apachefor example) but has been extended to
internal code that is already using OpenSSL. Our higher-level library uses
extensive reference counting to provide a robust interface to callers. We
of course do an EVP_cleanup in our xxx_lib_release() function. However,
with developers now also able to get at OpenSSL anyone of them could call
EVP_cleanup at anytime. Mandating that EVP_cleanup not be called other
than by my module is ludicrous due to the resource leaks, particularly if our
higher-level library isn't also used in the same
process.
I stongly feel that for OpenSSL to advance to the next
level that usability in enterprise applications has to be treated as a
first-class requirement. I don't see how this can be done
withoutbreaking the current interface, but hey, that's why the version
number is 1.0. What I'd like to see
is:
1. A reference counted startup/shutdown function with
all functions that tear-down global structures controlled by these and otherwise
made unavailable to callers (ie. EVP_cleanup, CRYPTO_cleanup_all_ex_data,
ERR_free_strings, etc.). The init functions such as
xxx_add_all_algorithms() may be left as-isbut the associated cleanup
functions are dangerous while public.
2. Namespacing supported. I've implemented this
in my own builds largely using the C preprocessor to "#define
RSA_new CA1_RSA_new" for example with some other changes required in
the perl scripts and some assembler modules. The prefix can be specified
at config time so that, in your case Peter, you could use a prefix of
IBM_. A default OpenSSL build continues to have no prefix. This
means that I no longer have to fear some other OpenSSL build finding its way
into our process at runtime and subverting our FIPS
routines.
An alternative to 2 is to move all functions into a
structure of functions pointers, a la PKCS#11, and have a single function
exported from OpenSSL, eg. OpenSSL_get_functions(), that returns this.
However, I'm guessing that the extra pointer indirection would be considered too
heavy handed. As is evident in the Python world though, trading a few
cycles for increased developer productivity, and in this case determinism and
stability, is a wise move.
I'm happy to contribute the changes, but don't want to
do all of the work unless the OpenSSL core developers agree on the
solution.
Regards,
Steven
From: Peter Waltenberg
[mailto:[EMAIL PROTECTED] Sent: Thursday, 4 August 2005 8:09
AMTo: openssl-dev@openssl.orgCc:
[EMAIL PROTECTED]Subject: RE: Safety of using OpenSSL from multiple
components in the one process
We created new entry points. There's
a very shallow layer over the EVP layer which is mostly just a macro away from
native OpenSSL. That was done to satisfy
other requirements, abstracting the OpenSSL API's a little so we could isolate
IBM apps. from changes in OpenSSL, so we could slide in the FIPS self tests, so
we could keep IBM owned code separate from OpenSSL licenced code etc.
I'm not going to claim that it's impossible
to solve this in other ways, we just didn't have to try anything else since a
solution that mostly worked already was imposed by other considerations in our
case. Our problems have been more
with conflicts with other instances of OpenSSL in customer products. IBM
libraries are used by customers who integrate them with their code as
well. Peter Peter Waltenberg
"Steven Reddie"
[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED]
03/08/2005 10:26 PM
Please respond
toopenssl-dev
To
openssl-dev@openssl.org
cc
Subject
RE: Safety of using
OpenSSL from multiple components in the one
process
Hi Peter, There is a requirement in my case for the OpenSSL
API to be accessible to several components. In your case was your higher
level component the only direct user of OpenSSL? If not, how did you make
the API available to other components? Were the new functions accessed
from one DLL with the OpenSSL functions accessed directly from the other DLL, or
did you have redirecting stubs in your new DLL? Steven
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter
WaltenbergSent: Wednesday, 3 August 2005 8:48 PMTo:
openssl-dev@openssl.orgCc: [EMAIL PROTECTED]Subject: Re:
Safety of using OpenSSL from multiple components in the one processYou are corr
RE: mk1mf.pl doesn't generate makefile for Windows CE
Hi Andy, I haven't been keeping on top of the issues with CE builds (since they worked for me with a few minor tweaks). What was the problem with wcedefs.mak? I had made a whole lot of changes to better support some more CE platforms but with it gone won't be able to role them in so easily. The reason for an external CE-specific makefile is that the settings vary between the different dev kits (eVC3 and eVC4) and so it can take enough code to straighten things out that it would clutter VC-32.pl more than may be liked. It's not a big deal if only ARM is supported, but CE supports several other processors too. One change that you may want to make is turning off the optimisations. I think the flags are /Ox /Ob2 /O2. /Ox and /O2 will cause eVC4 to break with internal compiler errors on a number of modules. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Monday, 1 August 2005 7:32 PM To: openssl-dev@openssl.org Subject: Re: mk1mf.pl doesn't generate makefile for Windows CE OK, I can see that WCEVERSION is defined in 3rd party wcecompat.mak, but I would feel better if we use variable set by VCVARS*.BAR or whatever it's called in embedded C. Meaning that I'd like to rephrase the question. Can you figure out variables set by VC, which we can use? They are OSVERSION, PLATFORM, WCEROOT, SDKROOT, PATH, INCLUDE, LIB, CC, TARGETCPU and CFG. Here is a script from WCEARM.BAT. if %OSVERSION%== set OSVERSION=WCE300 if %PLATFORM%== set PLATFORM=ms pocket pc if %WCEROOT%== set WCEROOT=C:\Program Files\Microsoft eMbedded Visual Tools if %SDKROOT%== set SDKROOT=C:\Program Files\Windows CE Tools set CC=clarm.exe set TARGETCPU=ARM set CFG=none CEVersion is set by IDE, so you cannot utilize it from commandline. And therefore I've decided to eliminate dependency on wcedefs.mak [from wcecompat] and implemented the corresponding logic directly to VC-32.mak. Grab latest snapshot to test it. For reference. Note that this change doesn't eliminate dependency on wcecompat [which is not the goal], but dependency on wcedefs.mak file from wcecompat. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: windows ce port patches
Hi Frank, I've got a lot going on right now, meaning that I don't have time to look at this in detail. Generally speaking though, the goal of wcecompat was to fill the gap between what the Windows CE C Runtime Library offered and what a full ANSI/Posix Runtime Library should offer. Time constraints meant that the gap filled more closely matched the parts of ANSI/Posix that were needed by OpenSSL. I would hope that over time Microsoft would have filled these gaps themselves. It sounds like they've done some of this in eVC4. My recollection is that Microsoft renamed some of the possible TARGETCPU values between eVC++ 3 and 4. ARM to ARMV4 was one of them. Wcecompat and the OpenSSL patches were written against eVC3 so expect the same naming convention. Modifying the WCEARMV4.BAT file included with eVC4 is the wrong approach; a hack! Instead wcecompat and OpenSSL need to be modified to work with both eVC3 and eVC4. This is what I did in my yet-to-be-completed patches which I'm not likely to find any time soon. The changes were trivial though and could easily be repeated. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Farkas Levente Sent: Tuesday, 28 June 2005 12:39 AM To: openssl-dev@openssl.org Subject: Re: windows ce port patches hi Steven, sorry for the delay i was on vacation:-) of course i use you wcecompat lib at the first place, but i've to modify it a bit. first the makefiles to update to the current ce versions: http://www.lfarkas.org/pocket-pc/openssl/make.patch second have to remove a lots of 'fixes' from wcecompat which already fixed in eVC++ 4 sp4 so remove these include files (i'm not 100% check them, but it seems so): include/assert.h include/ctype.h include/malloc.h include/math.h include/memory.h include/setjmp.h include/stdarg.h include/stddef.h include/stdio.h include/stdlib.h include/string.h include/time.h but it would need a bit more time and more carefull examination to see what can be dropped (or fix) in the current wcecompat to update to the latest eVC++ 4 sp4. another patch which i create this one: http://www.lfarkas.org/pocket-pc/openssl/openssl-ce.patch which are mainly bugfix in the current openssl code and only win ce specific so it could be apply without hurt other part of the openssl code. another stange problem for after reading this mail: http://marc.theaimsgroup.com/?l=openssl-usersm=111712574012234w=2 why have to change the TARGETCPU=ARM? since the eVC++ setup use the ARMV4 as the target cpu, but it's true that openssl can't build without it. and there are a few more problems... i look into this port problem again in this week and sen my new results. ps. another note that the current 0.9.8-beta6 is totaly broken and i fall back to the 0.9.7g after start with the new beta:-( yours. Steven Reddie wrote: Hi Levente, I did the Windows CE port but have not found the time to complete an update for the latest compiler and SDKs. I think the last kit I used for the current OpenSSL support was eVC 3.0 for PPC2002. OPENSSL_SYS_WINCE is the correct tag to use; you'll find these in the source code already. I changed the makefiles and wcecompat extensively to support more devices but I don't know when I'll get around to digging it up again. As a minimal fix you shouldn't find that you need to change very much to get things working with eVC 4.x. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Farkas Levente Sent: Tuesday, 14 June 2005 10:54 PM To: openssl-dev@openssl.org Subject: windows ce port hi, it seems to me that no one realy cares about the windows ce port of openssl. so i look around and try to fix the problems with the current stable release 0.9.7g and the current embedded visual c++. i'll send the required patch to be able to compile on windows ce. but i wouldn't like to touch other enviroments, so in some places i'd like to ifdef my modification. which macro should i use for this (what is the prefered way): - WCEPLATFORM - UNDER_CE - WIN32_CE - OPENSSL_SYS_WINCE thanks in advance. yours. ps. does this the right list for sending patches or should i use openssl-users (since i saw previous post on that list)? -- Levente Si vis pacem para bellum! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: windows ce port patches
Yes, simple casting isn't going to result in much other that emergency foot surgery. It's been some time since I did any WinCE work, but I seem to recall that there is only the W variant of most functions on Windows CE. Windows CE, if my memory is correct, is Unicode-only. The original patches that I did for 0.9.7 for CE converted a number of strings from ASCII to Unicode before calling Win32 API functions. I believe I used a for-loop to convert the strings since at the time I didn't know of the MultiByteToWideChar Win32 API function. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Tuesday, 28 June 2005 1:21 AM To: openssl-dev@openssl.org Subject: Re: windows ce port patches another patch which i create this one: http://www.lfarkas.org/pocket-pc/openssl/openssl-ce.patch which are mainly bugfix in the current openssl code and only win ce specific so it could be apply without hurt other part of the openssl code. As for crtypto/dso/dso_win32.c. - h = LoadLibrary(filename); + h = LoadLibrary((LPCTSTR)filename); Just casting to LPCTSTR doesn't make everything right. TCHAR is always WCHAR under CE, while filename is *always* char*. You either have to explicitly call LoadLibraryA or detect when conversion to WCHAR is due and convert. In HEAD branch it's suggested to fix with explicit call to LoadLibraryA. +#ifndef OPENSSL_SYS_WINCE sym = GetProcAddress(*ptr, symname); +#else + sym = GetProcAddress(*ptr, (LPCWSTR)symname); #endif Same applies to GetProcAddress. symnane is *always* char* and casting to LPCWSTR doesn't make it Unicode. See end of http://cvs.openssl.org/getfile/openssl/crypto/dso/dso_win32.c?v=1.22 for proper solution. Idea is to explicitly call GetProcAddressA when available [should be implemented in WCE=3.0] or implement own GetProcAddressA shim, which would interface to native GetProcAddressW. As for crypto/rand/rand_win.c. Why? Then why buf[64]? Its usage below is controlled by more complicated #if statement, meaning that suggested patch will break something. As for crypto/rc2/rc2_skey.c. Would it be enough to initialize ki with NULL? Does it really have to be c? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [ANNOUNCE] OpenSSL 0.9.8 beta 6 released
Hi, I've tested it on the platforms below with no problems. Looking good! Commands executed on Windows (not Cygwin): perl Configure VC-WIN32 ms\do_ms (didn't have MASM/NASM handy) nmake -f ms\ntdll.mak cd out32dll ..\ms\test Commands executed on all other platforms: ./config (Operating system and Configured for below as reported by config) make make test Operating system Configured for Compiler --- -- - Windows 2000 VC-WIN32MSVC 6.0 Cygwin 1.5.5-1i686-whatever-cygwin Cygwin gcc 3.3.1 Red Hat Linux 9 i686-whatever-linux2 linux-elf gcc 3.2.2 FreeBSD 4.6 i586-pc-freebsd4.6 BSD-x86-elf gcc 2.95.3 Solaris 2.6 sun4u-whatever-solaris2 solaris-sparcv9-cc Sun WorkShop 6 update 2 C 5.3 Solaris 2.7 sun4u-whatever-solaris2 solaris-sparcv9-cc Sun WorkShop 6 update 2 C 5.3 AIX 5.1 0050C89A4C00-ibm-aix aix-cc C for AIX Compiler, Version 6 HP-UX 11.11 9000/800-hp-hpux1x hpux-parisc2-cc HP C Compiler B.11.11.08 Tru64 OSF1 V4.0E alpha-dec-tru64 tru64-alpha-cc DEC C V5.8-009 Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: windows ce port
Hi Levente, I did the Windows CE port but have not found the time to complete an update for the latest compiler and SDKs. I think the last kit I used for the current OpenSSL support was eVC 3.0 for PPC2002. OPENSSL_SYS_WINCE is the correct tag to use; you'll find these in the source code already. I changed the makefiles and wcecompat extensively to support more devices but I don't know when I'll get around to digging it up again. As a minimal fix you shouldn't find that you need to change very much to get things working with eVC 4.x. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Farkas Levente Sent: Tuesday, 14 June 2005 10:54 PM To: openssl-dev@openssl.org Subject: windows ce port hi, it seems to me that no one realy cares about the windows ce port of openssl. so i look around and try to fix the problems with the current stable release 0.9.7g and the current embedded visual c++. i'll send the required patch to be able to compile on windows ce. but i wouldn't like to touch other enviroments, so in some places i'd like to ifdef my modification. which macro should i use for this (what is the prefered way): - WCEPLATFORM - UNDER_CE - WIN32_CE - OPENSSL_SYS_WINCE thanks in advance. yours. ps. does this the right list for sending patches or should i use openssl-users (since i saw previous post on that list)? -- Levente Si vis pacem para bellum! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: resources rather than values in openSSL functions
I think you'll find that design decision predates the people on this list. Performance is probably the secondary reason. The first is probably that it makes lifetime management of the objects easier -- you just release your reference to the object and don't have to worry about whether it needs to be freed. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of morchid fatima Sent: Wednesday, 13 April 2005 3:47 AM To: openssl-dev@openssl.org Subject: RE: resources rather than values in openSSL functions -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Michael Southwell Envoyé : samedi 9 avril 2005 00:54 À : openssl-dev@openssl.org Cc : [EMAIL PROTECTED] Objet : resources rather than values in openSSL functions Chris Snyder and I are writing a book entitled Pro PHP Security to be published by Apress. We have written the following there: The openSSL functions tend to deal with resources, in-memory pointers to keys, certificates, etc, rather than the actual values themselves; even on export, you pass a variable to the function and the exported value is returned by reference. Our inference is that the authors of the module wished to limit the number of copies of these values in memory, both for performance and security reasons. Can anyone verify whether this is indeed the reason, or if not, explain what the reason is? Thanks very much in advance. Michael Southwell, Vice President for Education New York PHP http://nyphp.org/twoday - In-depth PHP Training Courses __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
I don't know that the compiler knows anything about write reordering. The
restriction that the write of c must happen before the read of c is
something that the processor itself is aware of. The compiler will generate
code to do the write then read in sequence, and the processor is smart
enough to work out that it can't reorder read/write operations on the same
memory location without breaking the code -- this has nothing to do with
'volatile'. See the Itanium memory reordering PDF I referenced earlier in
this thread for excruciating detail on its reordering model and the
restrictions imposed on it in relation to accesses to the same memory
address.
Regards,
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jim Schneider
Sent: Saturday, 9 April 2005 12:08 AM
To: openssl-dev@openssl.org
Subject: Re: OpenSSL use of DCLP may not be thread-safe on multiple
processors
[snip]
int a;
volatile int c;
void foo(int b)
{
c = b;
a = c;
}
would require that the compiler generate code that stores the value of b
into c, and then stores the value in c into a. While the compiler would
have to take write reordering into account with respect to this particular
process (or it would violate the requirement that c be written before it's
read again), it's free to ignore caching. It's also free to ignore write
reordering with respect to other processes.
[snip]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
FWIW, the Itanium compiler included with the Microsoft Platform SDK does
employ release/aquire semantics when accessing volatile variables. However,
the standard x86 cl.exe does not and although it seems that the Pentium4
does not reorder as much as the spec allows, the spec does still allow it
and so future versions of the x86 line may do so, probably breaking existing
code expecting volatile accesses to be ordered a certain way.
Most compilers up until now probably did't do anything with memory barriers
simply because most processors didn't require them. It's modern processors
that support reordering.
Volatile should really be thought of as only useful for accessing memory
mapped devices -- if you think of it this way then you probably wont go
wrong by trying volatile based hacks. The compiler vendor may well expect
that when volatile is being used that the data segment being accessed has
been setup to disable caching and write combining. As Brian pointed out,
you can hardly expect (or would want) the compiler to generate code to flush
the cache, etc., based on whether caching is enabled in the table
descriptors. Therefore, volatile accesses on cacheable memory segments is
likely to be a candidate for reordering on processes that support it. While
Microsoft's IA64 compiler does do release/aquire for volatile types, the C
standard is vaugue enough in this area that this behaviour shouldn't be
relied upon.
I've been reading these specs very closely recently, though it's more about
finding out what cannot be done rather than what I can get away with.
There's nothing wrong with looking for possible optimisations, but in this
case the specs show that DCLP is not safe and cannot be modified in anyway
(that doesn't result in loosing the optimisation) to make it generally safe.
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Brian Hurt
Sent: Saturday, 9 April 2005 6:07 AM
To: openssl-dev@openssl.org
Cc: [EMAIL PROTECTED]
Subject: RE: OpenSSL use of DCLP may not be thread-safe on multiple
processors
On Fri, 8 Apr 2005, David Schwartz wrote:
No. The C standard is not telling the compiler what to do. It is
saying what the system must do when it runs the particular source
code. If the compiler cannot generate code that makes the system as a
whole comply with the standard, then the compiler does not conform.
Yes, but the standard is only defined in terms of what is visisble from a
single thread, and not in terms of what is visible from external vantage
points (like other threads).
No C compiler I ever worked with issued the memory barrier/cache flush
instructions needed to enforce cache behavior for volatile references.
Specially, neither Visual Studio nor GCC for the x86 issues those sorts of
instructions.
I haven't looked at the code in question, but my general experience has been
if you're relying on some precise memory specification and exacting
standards adherence, you're probably screwing up.
int a;
int c;
void foo(int b)
{
c = b;
a = c;
}
You will probably get code (x86 gas format) like:
movl8(%ebp), %eax ; eax = b
movl%eax, c ; c = b
movl%eax, a ; a = c
into an assembly language sequence that loads the contents of b into a
register, and then stores it into both a and c. The following code:
int a;
volatile int c;
void foo(int b)
{
c = b;
a = c;
}
This will produce code like:
movl8(%ebp), %eax ; eax = b
movl%eax, c ; c = b
movlc, %eax ; eax = c
movl%eax, a
Note the reload of c. Also note the utter lack of MBAR, CFLUSH, and
similiar instructions.
This is actually pretty standard behavior in the face of caches, and write
combining and speculative execution and all the other tricks modern CPUs
are doing. It issued the write, and then issued a seperate read to read
the value back in, and the fact that the CPU short circuited this isn't
the compiler's problem. You can argue to the cows come home wether this
is conformant or not- but that's the behavior on the ground.
The compiler is not free to ignore anything. If the C standard
specifies that the writes must occur in order, then the compiler must
make the writes occur in order. Not generate assembly code that makes it
look like the writes occur in order, but occur in order. The abstract
machine is not about assembly language, it's about what actually
happens.
That's what the compilers do. And if the machine combines the writes- as
most modern CPUs almost certainly would, the compilers will not issue
extra instructions to overcome this. Especially considering that it's
non-trivial to determine if the extra instructions are even needed. I
mean, on the x86 you have the CD and NW flags in CR0, you have the MTRRs,
plus bit 6 of the IA32_MISC_ENABLE MSR all statically controlling various
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
It's all in the interest of increased processing speed. Tighter models, such as strict ordering, are inherently slower than reordering models. The more reordering that can be done the better performance can be. Write combining buffers are an extreme example where overwriting the same address in memory can result in only the final value actually being written to the memory bus (ie. the initial and intermediate writes to the same address never make it to the bus), however these are usually only used for specific memory-mapped devices such as video frame buffers. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David C. Partridge Sent: Thursday, 7 April 2005 6:17 PM To: openssl-dev@openssl.org Subject: RE: OpenSSL use of DCLP may not be thread-safe on multiple processors Thanks all. It strikes me that the H/W designers have played a bit fast and loose with the cache consistency issue here - I believe I understand the C/C++ optimisation issues, and these CAN be worked around (IMHO) within the rules of the standard by using bool in some cases. However I've notified our dev folks to remove the few cases where we've used this technique as it is certainly dangerous. Dave __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
Hi Jim, The C abstract machine definition doesn't take into account multi-processing and therefore ignores memory operation reordering as seen by external observers. Volatile means little more than don't keep this variable in a register, it must be accessed directly from memory. It however doesn't specify anything about whether tha variable can exist in cache, or whether accesses to it can be reordered around other memory accesses. As long as volatile variables aren't kept in a register and are accessed directly from [cached] memory then cache coherency will take care of keeping the cache in sync with external memory (note that for memory-mapped devices, the device driver must have disabled caching for that region of memory). The problem of reordering being dicussed here doesn't result in incorrect values being read (cache coherency, for example, takes care of that), it's to do with assumptions being made about the order of memory operations mapping to the order of operations specified in code. DCLP is based on the assumption that the order of memory operations occurs in the same sequence as specified in the source code, and in modern MP systems that is rarely the case. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Schneider Sent: Friday, 8 April 2005 7:35 AM To: openssl-dev@openssl.org Subject: Re: OpenSSL use of DCLP may not be thread-safe on multiple processors On Thursday 07 April 2005 16:39, David Schwartz wrote: A bit off-topic, but... If you mean 'volatile', no, that doesn't do anything. Specifically, 'volatile' has no special semantics for multi-processors. There may be specific compilers where it has such semantics, but the standard doesn't provide them. According to ISO 9899-1990, section 6.5.3: An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, EXCEPT AS MODIFIED BY THE UNKNOWN FACTORS MENTIONED PREVIOUSLY [emphasis added]. Translation: The compiler can't make assumptions about the state of a variable marked volatile, and MUST generate code that writes every result stored there as well as code that reads the variable EVERY SINGLE TIME it appears in an expression. It has nothing to do with multi-processor coherency. Any compiler that generates code that deviates from this (even a little bit) isn't compliant with the standard. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL use of DCLP may not be thread-safe on multiple processors
Hi All,
OpenSSL makes use of the DCLP (double-checked locking pattern) in a number
of places (rsa_eay.c and at least one engine; I haven't done an exhaustive
search), with code that usually looks like this:
if (x == NULL)
{
CRYPTO_w_lock(CRYPTO_LOCK_XXX);
/* Avoid a race condition by checking again inside this lock */
if (x == NULL)
{
x = ...;
}
CRYPTO_w_unlock(CRYPTO_LOCK_XXX);
}
/* Now, make use of x */
Some recent research I've done in this area, prompted by Scott Meyers' and
Andrei Alexandrescu's article C++ and the Perils of Double-Checked Locking
at http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf, makes me
wonder whether this code is thread-safe on multi-processor machines. As the
article points out, DCLP is dangerous in general, however it is most likely
safe if the thing being tested and set is accessed atomically. On most
32-bit machines a 32-bit quantity will generally be accessed in a single bus
transaction, making it inherently atomic. However, there may be cases where
it is not atomic. An example could be on a machine that allows unaligned
accesses, such as the x86. It may be possible for half of the value to be
updated in another processors cache, and used (since the value is therefore
not NULL), before the other half is updated. It seems that in fact the race
condition that is trying to be avoided may have been reduced rather than
eliminated. While it may be true that the code generated by the compiler
doesn't typically result in unaligned accesses it is still a possibility
that exists, and there may be other ways for non-atomic access to occur
without unalignment being the cause.
I've tried some elaborate workarounds to maintain the optimisation that DCLP
provides, but they turn out to be not entirely safe on other processors such
as the Itanium. The easiest way to fix this would seem to be always
obtaining the lock before using the variables in question, but this could
have an impact on performance. A more involved alternative is to use locked
instructions, such as the Interlocked... Functions on Windows, and some
hand-rolled assembler on other platforms, to ensure that the values are
updated atomically. I'm not offering patches at this point in case there is
too much resistance to a performance hit, so I'm interested to know thoughts
either way. I agree that the margin for error is very, very small, and I
don't know how much of an impact on performance the necessary changes would
have, so I'm partly sending this so that if nothing is done and a future
race-condition is reported it may assist with locating the problem.
Regards,
Steven
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
Hi David,
I know that Scott is very busy at the moment, so he may not respond. I'll
drop his address on the next reply.
The implementations below suffer from the same general problem as the
implementations I've been playing around with recently. On processors that
reorder memory accesses it is possible for the write of 'initialised' to be
seen by another processor before it sees the write of 'x'. The result is
that another processor executing this same section of code could hit the
first !initialised test, see that initialised is true, bypass the body of
the if-statement, and continue on to use x; before x is updated in that
processor's cache. Bus snooping in cache coherency protocols such as MESI
take care of updating/invalidating cached entries as other processors
perform writes to the same locations, however the ordering is not
necessarily preserved and the Itanium is a good example of this.
Regards,
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David C. Partridge
Sent: Wednesday, 6 April 2005 11:08 PM
To: openssl-dev@openssl.org
Cc: [EMAIL PROTECTED]
Subject: RE: OpenSSL use of DCLP may not be thread-safe on multiple
processors
I've just read the paper, and I believe that the following variation on the
code would work and would avoid the MP unsafe issues raised because bool is
defined to be a single byte.
Further-more, I'm pretty certain that it also resolves the issues with the
order of construction and setting of the pointer in the singleton case, and
probably resolves all the other over smart optimisation issues as well
static volatile bool initialised=false;
if (!initialised)
{
CRYPTO_w_lock(CRYPTO_LOCK_XXX);
/* Avoid a race condition by checking again inside this lock */
if (!initialised)
{
x = ...;
initialised=true; // Atomic operation
}
CRYPTO_w_unlock(CRYPTO_LOCK_XXX);
}
/* Now, make use of x */
Or expressed in terms of the Singleton pattern:
in the header for the Singleton class file:
static volatile bool initialised;
in the Source file:
static volatile bool Singleton::initialised=false;
Singleton* Singleton::instance()
{
if (!initialised == 0) // 1st test
{
Lock lock;
if (!initialised) // 2nd test
{
pInstance = new Singleton;
initialised=true; // Atomic
}
}
return pInstance;
}
I've been using this approach for absolutely YEARS, and didn't realise
someone had honoured it with a design pattern name!!!
I've copied this to Scott Meyers for him to comment on whether I've got this
right ...
Dave Partridge
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Steven Reddie
Sent: 06 April 2005 10:02
To: openssl-dev@openssl.org
Subject: OpenSSL use of DCLP may not be thread-safe on multiple processors
Hi All,
OpenSSL makes use of the DCLP (double-checked locking pattern) in a number
of places (rsa_eay.c and at least one engine; I haven't done an exhaustive
search), with code that usually looks like this:
if (x == NULL)
{
CRYPTO_w_lock(CRYPTO_LOCK_XXX);
/* Avoid a race condition by checking again inside this lock */
if (x == NULL)
{
x = ...;
}
CRYPTO_w_unlock(CRYPTO_LOCK_XXX);
}
/* Now, make use of x */
Some recent research I've done in this area, prompted by Scott Meyers' and
Andrei Alexandrescu's article C++ and the Perils of Double-Checked Locking
at http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf, makes me
wonder whether this code is thread-safe on multi-processor machines. As the
article points out, DCLP is dangerous in general, however it is most likely
safe if the thing being tested and set is accessed atomically. On most
32-bit machines a 32-bit quantity will generally be accessed in a single bus
transaction, making it inherently atomic. However, there may be cases where
it is not atomic. An example could be on a machine that allows unaligned
accesses, such as the x86. It may be possible for half of the value to be
updated in another processors cache, and used (since the value is therefore
not NULL), before the other half is updated. It seems that in fact the race
condition that is trying to be avoided may have been reduced rather than
eliminated. While it may be true that the code generated by the compiler
doesn't typically result in unaligned accesses it is still a possibility
that exists, and there may be other ways for non-atomic access to occur
without unalignment being the cause.
I've tried some elaborate workarounds to maintain the optimisation that DCLP
provides, but they turn out to be not entirely safe on other processors such
as the Itanium. The easiest way to fix this would seem to be always
obtaining the lock before using the variables in question, but this could
have an impact on performance. A more involved alternative is to use locked
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
Check out A Formal Specification of Intel Itanium Processor Family Memory Ordering (http://www.intel.com/design/itanium/downloads/25142901.pdf). It describes in excruciating detail how reordering of memory operations can be observed by other processors. Example A.1 (in Appendix A) is a simple example of how writes can be reordered, and A.2 is an example of what can be done to enforce a desired ordering through use of aquire and release semantics. B.5 is an interesting example of how competing writes to the same address on parallel processors can lead to one processor seeing it's own write occur twice. Arch D. Robison's article Understanding memory consistency is essential (http://www.windevnet.com/documents/s=7545/ddj0304d/) explains some of these concepts a lot more clearly and generally than the specification above. While trying to understand these concepts I found it useful to hold a model of a hypothetical processor in my head; one which allows extensive reordering of writes as seen by an external observer (ie. another processor). The reordering could be for a multitude of reasons (and combinations), such as compiler optimisations, on-the-fly processor instruction reordering, cache-lines being flushed in a particular order (and different to the order of the store instructions), and write combining buffers delaying writebacks. I found that the more aggressive a model I kept in mind the easier it was to understand why without aquire and release semantics that it is, dare I say, impossible that a safe optimisation (a la DCLP) exists. Why this doesn't break lots of code: since the issue here is how memory accesses are ordered across multiple processors, it's only when two processors are accessing the same variables that things can go haywire, and this is where locks come in. What I mean is that the reordering doesn't really introduce any additional requirements for thread-safe code, it just causes code that doesn't use locks appropriately to breaks in different ways. Just as code that does not use locks can be thread-unsafe it can be even more thread-unsafe when reordering is involved. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David C. Partridge Sent: Thursday, 7 April 2005 12:56 AM To: openssl-dev@openssl.org Subject: RE: OpenSSL use of DCLP may not be thread-safe on multiple processors ARGH! Are you absolutely sure that this is the case - that's scary - I thought that the whole issue of SMP cache coherency and write order was solved years ago. I mean that if the order of memory write visibility between processors can't be g'teed, than a whole lot MORE than just DCLP crashes and burns ... How in that case can anyone write safe MP code? D. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: How good a random source is Crypto API?
Thanks, I'd missed/forgotten that comment. I've also seen crashes in single-threaded applications due to RAND_poll. One that immediately comes to mind is when the performance counters in the registry are accessed which cause hook DLLS to be loaded and called. I've come across a machine that appeared to be poorly configured due to an unclean Lotus Notes uninstall -- there were some Lotus Notes performance counter hooks left behind when the referenced DLLs had been removed. Actually, I can't recall whether it was an immediate crash or an indefinite hang, but the point is that some of the stuff done in RAND_poll is fairly exotic and can behave irradically depending on the dynamic state of the environment at runtime. Sure, a poorly configured system is hard to work with but when poorly configured systems are easy to come across the applications have to be a bit more robust. I've found at times that I've had little choice other than to disable the portion of RAND_poll that is causing a problem on a particular system. Moving such functionality out-of-process would improve stability, and this is obviously where prngd/egd comes in, but if these are seen as useful for more secure applications then it seems that a default OpenSSL install could settle for CryptoAPI's PRNG. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ferdinand Prantl Sent: Monday, 4 April 2005 3:59 PM To: openssl-dev@openssl.org Subject: RE: How good a random source is Crypto API? You may want to see the threads: BUG: CreateToolhelp32Snapshot First (initializing) call to RAND_status() very slow on Win32 An excerpt: Jeffrey Altman Thu, 14 Aug 2003 11:23:38 -0700 The reason that we go to all this trouble to examine alternative sources of randomness other than CryptGetRandom() is that Microsoft has refused to publish the sources of randomness which are used. Therefore, we have no ability to know whether or not the randomness reported by Windows is in fact random. However, it does not mean, that the method should be thread-unsafe and extremely slow under some circumstances... Ferda From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Reddie Sent: Monday, April 04, 2005 7:45 AM To: openssl-dev@openssl.org Subject: How good a random source is Crypto API? The non-thread-safe nature of RAND_poll for Win32 is something I need to address as it's impossible given the use of my library to expect RAND_poll to be called before other threads exist. This leads me to the question of how good a random source is the CryptGenRandom function on Windows. If it is a good enough source, then why bother with everything else that is done inside RAND_poll? The MSDN documentation makes it sound like similar things are being done for their random number seeding as is done in RAND_poll. Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: How good a random source is Crypto API?
Hi Richard, I'm reasonably familiar with that code, having spent some time debugging it over the years. I've experienced the thread-safety issues (eg. walking the heap snapshot while threads are simultaneously being created/destroyed), slow performance with the same section of code, and the crash/hang I mentioned. I think I also experienced some additional NT4-specific problems some years ago. I'm guessing that Microsoft figure that obscurity adds a little more security -- not to say they're relying on security-through-obscurity, but that if an implementation is secure and private it's possibly a little more secure than an implementation that is secure and public; at least I can understand why they think that. Do you have an idea on how to make things more stable ... No, that's the problem, I don't see much of a way to make this code more secure when it's doing the kind of things that it is. When I say that some of the things that the code do are exotic, I mean that they're not usual operations performed by most applications out there and as such bugs involving those functions are less likely to be found and fixed -- the Lotus Notes uninstall for example produced an unstable environment but when no other applications are exercising that functionality then it's less likely to be found; I doubt the customer cared too much when we told them it was a poor Lotus Notes uninstall, to them it was our application that wouldn't function after install. I have a suspicion that the thread-safety could be improved by doing the heap walking in DllMain (which I believe to be called in a single-threaded mannor) but putting such a mechanism into OpenSSL that would also be used by DLLs that link in the static library build of OpenSSL isn't straight-forward. Regards, Steven -Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED] Sent: Monday, 4 April 2005 5:17 PM To: openssl-dev@openssl.org; [EMAIL PROTECTED] Subject: Re: How good a random source is Crypto API? In message [EMAIL PROTECTED] on Mon, 4 Apr 2005 16:53:21 +1000, Steven Reddie [EMAIL PROTECTED] said: smr Moving such functionality out-of-process would improve stability, smr and this is obviously where prngd/egd comes in, but if these are smr seen as useful for more secure applications then it seems that a smr default OpenSSL install could settle for CryptoAPI's PRNG. Except for the small matter of knowing what the seeding generator uses as sources. As was mentioned, Microsoft is very secretive about the sources used for CryptGetRandom(). prngd/egd are open source... BTW, OpenSSL does use the CryptoAPI PRNG *as well*, just FYI... I do understand the problem with crashing systems. Do you have an idea on how to make things more stable in that kind of situation, and still have a more varied set of randomness sources than just CryptoAPI? Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- 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]
How good a random source is Crypto API?
The non-thread-safe nature of RAND_poll for Win32 is something I need to address as it's impossible given the use of my libraryto expect RAND_poll to be called before other threads exist. This leads me to the question of how good a random source is the CryptGenRandom function on Windows. If it is a good enough source, then why bother with everything else that is done inside RAND_poll? The MSDN documentation makes it sound like similar things are being done for their random number seeding as is done in RAND_poll. Regards, Steven
RAND_poll() crashes on Windows (thread-safety issue)
Hi All, As you are aware, RAND_poll() is not thread safe and must be called with only a single active thread in the process. The section in whichI have experienced crashesis the heap walking. The entire section is protected by a mutex, but the issueseems to bethat the snapshot references structures in memory that get changed by other threads (perhaps as threads are created and destroyed) while the snapshot is being traversed. The crash is usually a bad memory reference because a heap item no longer exists. We've discussed this before, and the "solution" has been to call RAND_poll before creating additional threads. This isn't a satisfactory solution since in this world of complex applications that dynamically load DLLs which in turn load other DLLs it is often the case that an application has multiple threads before OpenSSL has been loaded and therefore before it is even possible to call RAND_poll. We have workarounds for this, such as calling RAND_add with enough data so that RAND_poll wont be called, but a fix inside OpenSSL itself would stop the crashes that people onopenssl-users experiencefrom time to time. Are there any plans to address this, or any thoughts on the best approach to resolve this once, and for all? Regards, Steven
RE: [openssl.org #1021] about Window ce 5.0
Hi Kim, No, I haven't seen Windows CE 5.0 yet so haven't tried to get OpenSSL to build for it. You may find that it's just a matter of adding a few lines to wcedefs.mak around line#20. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbkim via RT Sent: Saturday, 12 March 2005 2:53 AM Cc: openssl-dev@openssl.org Subject: [openssl.org #1021] about Window ce 5.0 Hi, I'm Kim in Korea. First, I'm not good at speaking English.. sorry about that.. I'm wonder about that openssl library is used for windows ce 5.0 I try compile openssl, following install.wce. but, I got the message d:\wcecompat/wcedefs.mak(20) : fatal error U1050: Unexpected OSVERSION environment variable value Stop. Have you any version or any way for Windows CE 5.0? Response to me, please. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1004] dgst: unknown option -md5 ...
openssl dgst -md5 works for me with my 0.9.7c build. It sounds like you
have a dodgy build, or MD5 hasn't been included. Can you see MD5 listed
when executing openssl ciphers -v?
The debugger handling a call like EVP_get_digestbyname as atomic probably
indicates that you don't have debug symbols in that module or that the
source code for that module can't be located by the debugger.
Regards,
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED] via RT
Sent: Monday, 31 January 2005 4:41 AM
Cc: openssl-dev@openssl.org
Subject: [openssl.org #1004] dgst: unknown option -md5 ...
Hi,
unfortuately openssl 0.9.7 apps seem to be broken wrt. EVP_get_digestbyname.
E.g.:
===
openssl dgst -md5
unknown option '-md5'
options are
-c to output the digest with separating colons
..
===
It works with 0.9.6* without any problems.
After digging a little bit around, I've found, that at least in
apps/dgst.c EVP_get_digestbyname(...) always returns NULL :(
I verified this by inserting 'md = EVP_get_digestbyname(md5);'
at line 203 and even inserting OpenSSL_add_all_digests(); as mentioned
in the EVP_md5, does not fix this. I tried to debug/step through the
EVP_get_digestbyname, however, the debugger (gdb with ddd) handles it
as an atomic instruction - does not step into the appropriate source.
So, I'm to able to find a little bit more info about this problem :(
I also tried the example given in EVP_md5 and this works
without any problems - magic ???
Would be nice, if one could fix this problem: It is a little bit
annoying, to always tell the users/students, that they should use
0.9.6 binaries, to get their work done and also a little bit to much
work to maintain two instead of one package ... :(
Buildenv: Linux 2.6.9 i686 athlon; gcc 3.4.1
SHLIBDIRS= crypto ssl
./config --prefix=/opt/openssl --openssldir=/opt/openssl \
-L${ROOT4BUILD}/usr/lib -I${ROOT4BUILD}/usr/include \
zlib-dynamic shared
make all build-shared $MAKELOG
Regards,
jens.
--
+---[ Jens Elkner ]+
| Walther-Rathenau-Str. 58 [EMAIL PROTECTED] |
| 39104 Magdeburg GERMANY http://www.linofee.org/~jel/ |
+--+
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Large difference in exported symbols between Windows DLL and Linux shared builds
There
are a large number of differences in the exported symbols between Windows and
Linux builds. Some of them seem
surprising.
I built 0.9.7d on Windows with the following
commands:
perl Configure
VC-WIN32
ms\do_ms.bat
nmake -f ms\ntdll.mak
And on Linux, after adding EXPORT_VAR_AS_FN to the
linux-pentium target in Configure in an attempt to reduce differences between
the two platforms, I built and extracted exported symbols with the following
commands:
./config sharedmake nm -D libcrypto.so.0.9.7 |
grep ' [DRT] ' symbols
On Windows, there were some minor differences
between the exports listed in ms\libeay32.def and what was actually exported
from the DLL ("dumpbin /exports libeay32.dll"). The DLL contained the
following additional symbols:
CAST_S_table0 CAST_S_table1 CAST_S_table2 CAST_S_table3 CAST_S_table4 CAST_S_table5 CAST_S_table6 CAST_S_table7 DES_SPtrans OSSL_DES_version
OSSL_libdes_version
Differences between Windows and Linux are as
follows.
Windows contained these expected extra
symbols:
RAND_event
RAND_screen
Linux contained these extra text symbols (data
symbols further below):
_CONF_add_string _CONF_free_data_CONF_get_section
_CONF_get_section_values _CONF_get_string _CONF_new_data _CONF_new_section _des_crypt asn1_primitive_clear BIO_ACCEPT_free BIO_ACCEPT_new BIO_CONNECT_free BIO_CONNECT_new BIO_s_log bn_cmp_part_words bn_cmp_words bn_mul_comba4 bn_mul_comba8 bn_mul_high bn_mul_low_normal bn_mul_low_recursive bn_mul_normal
bn_mul_part_recursive bn_mul_recursive bn_sqr_comba4 bn_sqr_comba8 bn_sqr_normal bn_sqr_recursive
d2i_NETSCAPE_ENCRYPTED_PKEY d2i_NETSCAPE_PKEY DHparams_it dsa_pub_internal_it DSA_SIG_it DSAparams_it DSAPrivateKey_it DSAPublicKey_it
ec_GFp_mont_field_decode
ec_GFp_mont_field_encode
ec_GFp_mont_field_mul
ec_GFp_mont_field_set_to_one
ec_GFp_mont_field_sqr
ec_GFp_mont_group_clear_finish
ec_GFp_mont_group_copy
ec_GFp_mont_group_finish
ec_GFp_mont_group_init
ec_GFp_mont_group_set_curve_GFp
ec_GFp_nist_group_init
ec_GFp_recp_group_init ec_GFp_simple_add ec_GFp_simple_cmp ec_GFp_simple_dbl
ec_GFp_simple_field_mul
ec_GFp_simple_field_sqr
ec_GFp_simple_get_Jprojective_coordinates_GFp
ec_GFp_simple_group_clear_finish
ec_GFp_simple_group_copy
ec_GFp_simple_group_finish
ec_GFp_simple_group_get_cofactor
ec_GFp_simple_group_get_curve_GFp
ec_GFp_simple_group_get_order
ec_GFp_simple_group_get0_generator
ec_GFp_simple_group_init
ec_GFp_simple_group_set_curve_GFp
ec_GFp_simple_group_set_generator ec_GFp_simple_invert
ec_GFp_simple_is_at_infinity
ec_GFp_simple_is_on_curve
ec_GFp_simple_make_affine
ec_GFp_simple_oct2point
ec_GFp_simple_point_clear_finish
ec_GFp_simple_point_copy
ec_GFp_simple_point_finish
ec_GFp_simple_point_get_affine_coordinates_GFp
ec_GFp_simple_point_init
ec_GFp_simple_point_set_affine_coordinates_GFp
ec_GFp_simple_point_set_to_infinity
ec_GFp_simple_point2oct
ec_GFp_simple_points_make_affine
ec_GFp_simple_set_compressed_coordinates_GFp
ec_GFp_simple_set_Jprojective_coordinates_GFp
EC_GROUP_clear_free_extra_data
EC_GROUP_free_extra_data
EC_GROUP_get_extra_data
EC_GROUP_set_extra_data
engine_cleanup_add_first
engine_cleanup_add_last engine_free_util engine_set_all_null engine_table_cleanup
engine_table_register engine_table_select
engine_table_unregister
engine_unlocked_finish engine_unlocked_init fcrypt_body
i2d_NETSCAPE_ENCRYPTED_PKEY i2d_NETSCAPE_PKEY md4_block_host_order
md5_block_asm_host_order MGF1
NETSCAPE_ENCRYPTED_PKEY_free
NETSCAPE_ENCRYPTED_PKEY_it
NETSCAPE_ENCRYPTED_PKEY_new NETSCAPE_PKEY_free NETSCAPE_PKEY_it NETSCAPE_PKEY_new OPENSSL_gmtime
ripemd160_block_asm_host_order sha_block_data_order sha_block_host_order
sha1_block_asm_data_order
sha1_block_asm_host_order
X509_ATTRIBUTE_SET_it X509_NAME_ENTRIES_it
X509_NAME_INTERNAL_it
These are the extra data symbols exported on
Linux:
AES_version ASN1_version BF_version BN_version CAST_version cleanse_ctr CONF_def_version CONF_version DH_version DSA_version EVP_version IDEA_version lh_version MD2_version MD4_version D5_version
p_CSwift_AcquireAccContext
p_CSwift_AttachKeyParam
p_CSwift_ReleaseAccContext
p_CSwift_SimpleRequest PEM_version rand_ssleay_meth RAND_version RC2_version RC4_version RC5_version RMD160_version RSA_version SHA_version SHA1_version STACK_version TXT_DB_version v3_akey_id v3_alt v3_bcons v3_cpols v3_crl_hold v3_crl_invdate v3_crl_num v3_crl_reason v3_crld v3_ext_ku v3_info v3_key_usage v3_ns_ia5_list v3_nscert v3_ocsp_accresp v3_ocsp_acutoff v3_ocsp_crlid v3_ocsp_nocheck v3_ocsp_nonce v3_ocsp_serviceloc v3_pkey_usage_period v3_sinfo v3_skey_id v3_sxnet x509_dir_lookup x509_file_lookup x509_name_ff
X509_version
Does anyone know if much of this is
expected. It looks like at least a few of them are incorrect, eg. I expect
that there should be no differences between platforms in relation to
NETSCAPE_ENCRYPTED_PKEY and NETSCAPE_PKEY.
Perhaps all of the symbols similar to
RE: [openssl.org #951] FW: New port to the AS/400 (iSeries)
Hi Richard, I didn't so much mean lack of response from the OpenSSL team, but lack of response from anyone. I assumed there would be many people interested in an OS/400 port so was surprised that there had been no responses stating so. I greatly appreciate the work that you and all members of the OpenSSL team do and appreciate the balance that you must maintain. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Levitte - VMS Whacker Sent: Thursday, 30 September 2004 7:43 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [openssl.org #951] FW: New port to the AS/400 (iSeries) In message [EMAIL PROTECTED] on Thu, 30 Sep 2004 10:15:04 +1000, Steven Reddie [EMAIL PROTECTED] said: smr I'm surprised that nobody has responded. I feel I need to raise a little bit of awareness here. The OpenSSL Project is entirely volunteer driven, and as such, we (those having write access to the repository) are working mostly on our free time. This means that there are a ton of other facets of life playing in, including looking for jobs (and jobs in this field are still a bit scarse), *doing* your job (which may or may not be related to OpenSSL), taking care of the family, taking care of your self. Just to give you a picture of what life can be like, I've been silent to the almost extreme for a while, because I'm dealing with very deep family issues, and have to contemplate seeing my son move to the other side of the Atlantic Ocean, which has had a huge impact on my emotional self, and my capacity to focus. I've used the little external focus I had left to do my job properly, and to plan for my future (next job, other projects that I'm barely keeping alive, ...). I haven't even looked at the OpenSS bugs database for ages (= a few months, which is a lot considering I used to look at the stuff there about twice a day before that). So, I'd like to ask for a little bit of patience with us, as we all have some kind of life we need to take care of and make a priority as well. Thanks for listening. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- 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 [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #951] FW: New port to the AS/400 (iSeries)
Hi George, I'm surprised that nobody has responded. I may have to port an application using OpenSSL to AS/400 at some stage so I would appreciate it if you would post the patches. Perhaps if you post them the team will integrate them. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shaw Graham George via RT Sent: Tuesday, 28 September 2004 11:05 PM Cc: [EMAIL PROTECTED] Subject: [openssl.org #951] FW: New port to the AS/400 (iSeries) Hi, I've made a new port of OpenSSL version 0.9.7d for the AS/400 (iSeries). OS/400 versions V5R1M0 upwards are supported. It is based on a previous port (version 0.9.7b?) by Brian Morris ([EMAIL PROTECTED], ticket #701), and also includes the new EBCDIC patches by Richard Koenning ([EMAIL PROTECTED], ticket #843). But it also adds a few more changes that (IMHO) improve the port and build environment, and extends the port to include service programs (AS/400 version of shared libraries), and ports for different EBCDIC characters sets (CCSIDs). I've also included an extensive README that should prove useful for OpenSSL users in explaining the port, and some of the AS/400-specific issues. Any questions, no problem. Cheers, G. --- George Shaw Senior Software Engineer Axway a Sopra Group company Tel: +44 (0) 7802 452186 Fax: +44 (0) 1454 299684 email: [EMAIL PROTECTED] www.axway.com --- Ce message est exclusivement destiné aux personnes dont le nom figure ci-dessus. Il peut contenir des informations confidentielles dont la divulgation est à ce titre rigoureusement interdite. Dans l'hypothèse où vous avez reçu ce message par erreur, merci de le renvoyer à l'adresse e-mail ci-dessus et de détruire toute copie. This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ 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]
OpenSSL thread safety (was: possibly bug in crypto/rand/rand_win.c)
Hi Jeffrey,
Come to think of it, maybe OpenSSL should simply perform a call to
RAND_poll() as part of the DLL initialization. This would solve many
problems.
No, it would create some. RAND_poll() calls LoadLibrary() which is a no-no
from DllMain(). malloc() is not safe to call from DllMain() when the C
Runtime is being dynamically linked in, and since RAND_poll() is so complex
it is possible that malloc() is being called or will be in the future
without anyone realising it's a no-no.
However, I know where you're going with this, and I agree that it's
something that needs addressing. It's a general problem that has been
troubling me on another project. I don't know that I have the greatest
solution, but I'll do a quick dump of some of the options here.
1. It is safe to create/initialise synchronization objects (ie. a mutex) in
DllMain() for DLL_PROCESS_ATTACH. A single master OpenSSL mutex could be
created to be used for on-demand (first-access) initialisation of
subsystems. I don't recall the equivalent DLL entry point on Unix platforms
or it's semantics, but as an aside does anyone know if such entry points are
standard across all Unix implementations that support threading?
2. Alternatively, each subsystem could use it's own init-on-lock mutex (a la
PTHREAD_MUTEX_INITIALIZER) but such a primitive might not be supported on
all platforms and would introduce tighter coupling which is counter to
OpenSSL's thread library agnostic approach.
3. Point 1 does not address the situation where OpenSSL is built as a static
library and included in some other DLL (and the FIPS support may require
this to be the standard setup for many projects). It would be the
responsibility of the wrapping DLL to call whatever OpenSSL function
initialises the master mutex from it's own DllMain(). This can get hairy
when the static library using OpenSSL is also provided as a static library
-- the responsibility has to be carried carefully up the chain.
4. In it's most basic form (OpenSSL as a DLL) Point 1 bypasses the thread
library agnostic approach that OpenSSL uses because there is no way for the
user to first setup the mutex initialisation callbacks. I can't think of a
good solution to this. Creating a wrapping DLL who's DllMain() sets up the
callbacks and then calls the OpenSSL master mutex initialisation function
would work, but then the ability for the caller of that DLL to customise the
mutex functions has been lost.
Regards,
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jeffrey Altman
Sent: Tuesday, 13 July 2004 11:14 PM
To: [EMAIL PROTECTED]
Subject: Re: possibly bug in crypto/rand/rand_win.c
Suggestion:
This is a usage error. Be sure to initialize openssl when your
application starts or
when your DLL is loaded. Do not wait for the first thread to attempt
to make
a call to OpenSSL to initialize it.
Come to think of it, maybe OpenSSL should simply perform a call to
RAND_poll()
as part of the DLL initialization. This would solve many problems.
Jeffrey Altman
Jiang Lei wrote:
Hi,
Sorry if this message is sent twice.
I got problem running RAND_poll() in multi-threaded programs. The
function sometimes crashes at heap_next(hentry):
...
if (heaplist_first(handle, hlist))
do
{
RAND_add(hlist, hlist.dwSize, 3);
hentry.dwSize = sizeof(HEAPENTRY32);
if (heap_first(hentry,
hlist.th32ProcessID,
hlist.th32HeapID))
{
int entrycnt = 80;
do
RAND_add(hentry,hentry.dwSize, 5);
while (heap_next(hentry)
^
*** this is where the problem is ***
--entrycnt 0);
}
} while (heaplist_next(handle,
hlist));
...
An article at
http://www.codeproject.com/threads/Thelp32ReadProcessMemory.asp
revealed that the function Heap32Next is not appropriate to be used in
threaded
programs:
[QUOTE START]
The snapshot
The toolhelp functions make use of a snapshot to access process,
thread, module, and heap lists in the system. To quote MSDN:
The lists in system memory change when processes are started and
ended, threads are created and destroyed, executable modules are
loaded and unloaded from system memory, and heaps are created and
destroyed. The use of information from a snapshot prevents
inconsistencies. Otherwise, changes to a list could possibly cause a
thread to incorrectly traverse the list or cause an access violation
(a GP fault). For example, if an application traverses the thread
list while other threads are created or terminated, information that
the application is using to traverse the thread list might become
outdated and could cause an error for the application traversing
RE: OpenSSL thread safety (was: possibly bug in crypto/rand/rand_win.c)
Title: Message Hi Peter, Those platforms, minus Mac OS/X, plus OSF Tru64 (Digital Unix), has been my experience also. I was hoping that init might be supported across the board. Thanks for the info. It's my understanding so far that the OpenSSL FIPS certification requires use of a static library build of OpenSSL. There was some discussion about ways to allow shared libraries to be used but I don't think I saw a definitive solution. I'll be happy if I just missed it. Do you think these issues should be addressed in OpenSSL, or are best left for the caller to handle? -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter WaltenbergSent: Wednesday, 14 July 2004 3:26 PMTo: [EMAIL PROTECTED]Subject: Re: OpenSSL thread safety (was: possibly bug in crypto/rand/rand_win.c)1. It is safe to create/initialise synchronization objects (ie. a mutex) inDllMain() for DLL_PROCESS_ATTACH. A single master OpenSSL mutex could becreated to be used for on-demand (first-access) initialisation ofsubsystems. I don't recall the equivalent DLL entry point on Unix platformsor it's semantics, but as an aside does anyone know if such entry points arestandard across all Unix implementations that support threading?Yes to all the new Unix platforms we support with our OpenSSL wrapper. (Solaris, Linux, AIX, HPUX, Mac OS/X). Support isn't uniform however, and is quirky on some older systems. If you want to follow this up I can probably provide example shared library entry point code and link options for quite a few platforms. 3. Point 1 does not address the situation where OpenSSL is built as a staticlibrary and included in some other DLL (and the FIPS support may requirethis to be the standard setup for many projects). Static libraries make it hard to draw the boundary around the FIPS certified code, which means you may end up having to certify the whole ball of wax, (expensive). Shared libraries will probably be more common. It would be theresponsibility of the wrapping DLL to call whatever OpenSSL functioninitialises the master mutex from it's own DllMain(). This can get hairywhen the static library using OpenSSL is also provided as a static library-- the responsibility has to be carried carefully up the chain.A hack we had to add recently to support legacy systems where the shared lib initialization code just doesn't get called. Peter "Steven Reddie" [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/14/04 03:08 PM Please respond toopenssl-dev To [EMAIL PROTECTED] cc Subject OpenSSL thread safety (was: possibly bug in crypto/rand/rand_win.c) Hi Jeffrey, Come to think of it, maybe OpenSSL should simply perform a call to RAND_poll() as part of the DLL initialization. This would solve manyproblems.No, it would create some. RAND_poll() calls LoadLibrary() which is a no-nofrom DllMain(). malloc() is not safe to call from DllMain() when the CRuntime is being dynamically linked in, and since RAND_poll() is so complexit is possible that malloc() is being called or will be in the futurewithout anyone realising it's a no-no.However, I know where you're going with this, and I agree that it'ssomething that needs addressing. It's a general problem that has beentroubling me on another project. I don't know that I have the greatestsolution, but I'll do a quick dump of some of the options here.1. It is safe to create/initialise synchronization objects (ie. a mutex) inDllMain() for DLL_PROCESS_ATTACH. A single master OpenSSL mutex could becreated to be used for on-demand (first-access) initialisation ofsubsystems. I don't recall the equivalent DLL entry point on Unix platformsor it's semantics, but as an aside does anyone know if such entry points arestandard across all Unix implementations that support threading?2. Alternatively, each subsystem could use it's own init-on-lock mutex (a laPTHREAD_MUTEX_INITIALIZER) but such a primitive might not be supported onall platforms and would introduce tighter coupling which is counter toOpenSSL's thread library agnostic approach.3. Point 1 does not address the situation where OpenSSL is built as a staticlibrary and included in some other DLL (and the FIPS support may requirethis to be the standard setup for many projects). It would be theresponsibility of the wrapping DLL to call whatever OpenSSL functioninitialises the master mutex from it's own DllMain(). This can get hairywhen the static library using OpenS
RE: Failure to build in cygwin
Hi Mark, I think I've seen this one before, and it was due to an environment variable. Something like MAKEMODE, MAKE_MODE, MAKE_FLAGS; I don't recall which exactly, but it was definitely a MAKE* or MK* variable. Unsetting it, or setting it to empty did the trick. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jaffe Sent: Saturday, 22 May 2004 6:49 AM To: [EMAIL PROTECTED] Subject: Failure to build in cygwin Once again I am stumped by this stubborn problem. Due to certain support issues, I am using the setup perl Configure for VC-WIN32 and then invoking ms/do_masm.bat followed by nmake /f ms/ntdll.mak. When the last command gets invoked, I receive the error message NMAKE : fatal error U1065: invalid option '-' I have diligently searched the file ntdll.mak and it contains NO '-' options (I converted them all to '/' options with sed.) Even when I invoke it with nmake /d /p /f ms/ntdll.mak I still get this message; the additional flags are supposed to provide debug info but are totally useless. What shall I do to determine where the problem is arising? Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ 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]
RE: Win32 compiles under cygwin
Right, I was flat out today and forgot about that, probably because I don't understand what is significant about how ar/lib is invoked. We're relying on the OpenSSL build to use Cygwin's ar and it turns out that the resulting libcrypto.a is compatible with Microsoft's tools (eg. link ... libcrypto.a works without a problem). If this approach isn't wanted an ar shell script wrapper could be used which invokes lib. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Wednesday, 12 May 2004 5:41 PM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin Howard, Would you be interested in supporting MSVC command-line builds using gcc2cl? Well, if you choose to discuss unrelated matters, at least fulfill previous direct promises first:-):-):-) I'm half kidding and half referring to the question about what do you replace ar with and/or how do you collect final .lib files. Which you intended to answer:-) A. __ 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]
RE: Win32 compiles under cygwin
Yes, I was surprised too. I don't know if it's because Cygwin's ar has been made compatible with Microsoft's lib format, or if the two formats have always been the compatible. One advantage of using gcc2cl is that you don't need to worry about most of the Microsoft specifics such as .obj vs .o. As I mentioned I recall the only changes required in addition to constructing the CygwinMSVC Configure entry was to rename INCLUDE/LIB in the Makefile's; and a do_win32_shared is also required. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Wednesday, 12 May 2004 10:17 PM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin Right, I was flat out today and forgot about that, probably because I don't understand what is significant about how ar/lib is invoked. We're relying on the OpenSSL build to use Cygwin's ar and it turns out that the resulting libcrypto.a is compatible with Microsoft's tools (eg. link ... libcrypto.a works without a problem). Wow! A bit unexpected, because ar is more or less general purpose archiver [at least you can pack literally whatever you wish with it]. Thanks for enlightening. If this approach isn't wanted an ar shell script wrapper could be used which invokes lib. As already mentioned what I find attractive is the idea of using Unix-like make.exe *alone* to produce a Visual C build. A. __ 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]
RE: Win32 compiles under cygwin
Howard, Would you be interested in supporting MSVC command-line builds using gcc2cl? It requires some changes to the autoconf files, but the point of using it is that it appears to the build as if gcc is being used. We've been building openldap this way for a couple of years now. I'm betting that there are many companies out there that have strict standards about the compilers that are used, and that for Windows MSVC is the default choice. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Howard Chu Sent: Wednesday, 12 May 2004 3:32 AM To: [EMAIL PROTECTED] Subject: RE: Win32 compiles under cygwin Speaking as a member of the Openldap core team, I'll just point out that we support building on Windows using MinGW. Normally I build with the Cygwin toolchain, but only in -mno-cygwin mode. When we tested Cygwin (~3 years ago) we found the performance to be unacceptable and so have only used the native Windows APIs. I hear that Cygwin has gotten much improved in recent times but we have no interest in it now. I use the same setup to build OpenSSL on Windows. The MSVC project files for OpenLDAP have also been abandoned in OpenLDAP 2.2. The MinGW build is the only one we continue to develop and test. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steven Reddie I believe I wrote gcc2cl originally to get the OpenLDAP build working (OpenLDAP doesn't seem to support a Windows build out-of-the-box, although the code supports Windows, and a separate IDE project file is needed). Yes, autoconf was the difficulty with OpenLDAP that required gcc2cl. Later when doing some work on our OpenSSL build I switched it to gcc2cl partly because I had it available. It would surely be possible to do it without gcc2cl, I just found that the way to go to minimise changes in OpenSSL. However, the INCLUDE and LIB make variables used in OpenSSL needed to be renamed so that they don't overwrite what is expected by cl. __ 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]
RE: Win32 compiles under cygwin
I believe I wrote gcc2cl originally to get the OpenLDAP build working
(OpenLDAP doesn't seem to support a Windows build out-of-the-box, although
the code supports Windows, and a separate IDE project file is needed). Yes,
autoconf was the difficulty with OpenLDAP that required gcc2cl. Later when
doing some work on our OpenSSL build I switched it to gcc2cl partly because
I had it available. It would surely be possible to do it without gcc2cl, I
just found that the way to go to minimise changes in OpenSSL. However, the
INCLUDE and LIB make variables used in OpenSSL needed to be renamed so that
they don't overwrite what is expected by cl.
The Configure entries are:
CygwinMSVC, gcc2cl:-DWIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32
-MD -W3 -WX -G5 -Ox -O2 -Ob2 -Gs0 -GF -Gy -nologo:::WIN32:advapi32.lib
gdi32.lib wsock32.lib:BN_LLONG EXPORT_VAR_AS_FN
${x86_gcc_opts}:${x86_out_asm}:win32:cygwin-shared:::.dll,
debug-CygwinMSVC, gcc2cl:-g -DWIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN
-DDSO_WIN32 -MDd -W3 -WX -G5 -GF -nologo:::WIN32:advapi32.lib gdi32.lib
wsock32.lib:BN_LLONG EXPORT_VAR_AS_FN
${x86_gcc_opts}:${x86_out_asm}:win32:cygwin-shared:::.dll,
We've been building only static libraries until recently. Support for
-shared required some changes which aren't reflected here. I believe
cygwin-shared was changed to msvc-shared, and /dll was added to the
ldflags, but I don't recally the other changes.
I don't remember what I did with ar. I'll check tomorrow at work and let
you know.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Andy Polyakov
Sent: Tuesday, 11 May 2004 7:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Win32 compiles under cygwin
Since the cygwin environment is different from the MS Run Time
environment, I would not make the assumption that the binaries
produced use exactly the same configuration options. They may but I
would not count on it.
Well, it's all about control and understanding. I mean if we manage to
understand exactly what's going on, we can make it do what we want:-)
Actually the idea of using Unix-like make, cygwin or DJGPP, to invoke cl
is rather attractive and I don't think it's impossible. I even fail to
see why does it have to be a gcc2cl front-end... It should be possible
to invoke cl directly [note that cl is rather forgiving when it comes to
path specifications, e.g. -I../include works as well as -I..\\include].
Of course you need gcc2cl for autoconf purposes, but in OpenSSL context
it should be possible to make it work with cl directly...
I understand what you are attempting to do; I just do not know if the
results will be the same. I know that with other packages such as
Kerberos you absolutely do not get the same result when building under
cygwin because the environment is more Unix like and therefore
different assumptions are made.
What make may not do is to reset INCLUDE and LIB variables and do
something completely different in place for ar, e.g. it can as well
generate a linker answer file to be used when generating .dll. And one
have to add extra rules, most notably .c.obj.
Steven,
I've created a new CygwinMSVC
entry in Configure which uses enough of the Cygwin entry to integrate
with the rest of the build framework, but uses a SYSNAME of WIN32 (not
CYGWIN32) and sets other defines such as DSO_WIN32 so that it picks up
the Microsoft-specific stuff.
Can you post the line? How do you resolve the ar issue? A.
__
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]
RE: Win32 compiles under cygwin
Hi Andy, We have standards for the compilers that we use on each platform, and on Windows it is Microsoft's toolset. In our lab we use cygwin for the build framework so that we can use the same framework on Windows and Unix platforms. What I was trying to say was that rather than using the .bat files and nmake makefiles that come with OpenSSL for Windows builds, we use gcc2cl with cygwin and Microsoft's compiler to piggy-back onto the Unix-ey cygwin build target, thereby avoiding the .bat files and nmake files. We therefore pickup the ability to specify no-idea no-rc5 no-mdc2 in the same way for Unix and Windows builds, and the same goes for using the -shared option. It just makes the Windows OpenSSL build integrate into our build framework in the same way that the Unix builds do. Yes, it's a standard Win32. By fairly standard OpenSSL cygwin build I was referring to the parts of the OpenSSL build process that we are using rather than the compiler. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Tuesday, 11 May 2004 3:13 AM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin Steven, I've written a command-line utility called gcc2cl which acts like a gcc front-end while using Microsoft's compiler/linker at the backend. It translates options and does some munging of cl's stdout/stderr so as to fool autoconf into thinking it is really using gcc. This enables us (I did this at Computer Associates) to do a fairly standard OpenSSL cygwin build while using the Microsoft compiler/linker/libraries/runtime. Could you elaborate on fairly standard OpenSSL cygwin build. What's considered standard? I assume the way Cygwin is currently supported by OpenSSL... What's fair? What is the actual reason for dismissing gcc and trying to compile cygwin library with Microsoft compiler? Trouble is that Microsoft compiler generates code which is dependent on presence of Visual C run-time environment and it's a slippery way. Presense of 3rd party run-time components in a cygwin application might break some interfaces [fork is first one to come to mind]. Of course you might mean that the only cygwin component you use is make and sh [which is actually appealing!] and that resulting OpenSSL build does not contain any run-time dependencies from cygwin1.dll. But can you call it fairly standard *cygwin* build? Shouldn't it be called fairly standard *Win32* build? A. __ 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]
RE: Win32 compiles under cygwin
Mark, When I get time I'll clean up the implementation and post the source to this list. In the meantime I'll send you the binary tomorrow when I'm at work. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jaffe Sent: Monday, 10 May 2004 12:54 PM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin Steven, Thanks for your response. This sounds like it would be an excellent solution to my dilemma. Please feel free to forward your contribution as you see fit. Mark On May 9, 2004, at 5:40 PM, Steven Reddie wrote: Hi Mark, I've written a command-line utility called gcc2cl which acts like a gcc front-end while using Microsoft's compiler/linker at the backend. It translates options and does some munging of cl's stdout/stderr so as to fool autoconf into thinking it is really using gcc. This enables us (I did this at Computer Associates) to do a fairly standard OpenSSL cygwin build while using the Microsoft compiler/linker/libraries/runtime. Would this help you in any way? I've tried to contribute it to cygwin but was surprised that there was no interest. We also use it to build OpenLDAP, libxml2, log4cplus, and others almost out-of-the-box. Being able to avoid the OpenSSL .bat files and nmake makefiles helps us to integrate with our cross platform automated build process. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jaffe Sent: Monday, 10 May 2004 7:03 AM To: [EMAIL PROTECTED] Subject: Win32 compiles under cygwin Greetings to all. I am responsible to the build environment at OSAF, and we are integrating openssl into the Chandler product. I am concerned about generating the correct configuration, and wonder if someone has a solution. What we do when we incorporate an open-source project into ours is to prepare a script which sets up the configuration for each supported platform (Win32, linux, and OS X for now.) When we run make, it untars the source tarball, applies our patches and then does a configure and a make, installing the libraries into our distribution path. Where I am running into problems is in dealing with the Win32 build situation. We use the cygwin environment, and several of our projects already are compatible in that we call nmake and a DOS-path compatible make file which is working nicely. However, applying this method to the openssl tree has presented some difficulty. I have so far been successful in running a patched ms/32all.bat to generate the required xx.mak files, but the results still contain - style option flags rather than the desired / style. I am stumped at this point. Of course, I could do this under a local command-line but this is not available from remote ssh or in the environment in which we run the tinderbox. Any suggestions? Mark Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ 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] Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ 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]
RE: Win32 compiles under cygwin
Jeffrey, Are you saying that using something like gcc2cl to kick off a build the way you do for cygwin, but using the Microsoft compiler, is the wrong way to go? It's working well for us in-house, though we've been using static libraries up until now and are just finishing up changes to support the DLL build. Mark, the naming issue is something that we need to handle also, although we need to use a custom name with the OpenSSL version number included. Whatever we can contribute will include support for altering the name. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman Sent: Tuesday, 11 May 2004 11:07 AM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin The libssl.a and libcrypto.a binaries are linked to cygwin1.dll. This is not what you want. You do not want to be using the cygwin build process but the MS Visual Studio build environment. Perhaps you can use the cygwin environment to kick off a normal OpenSSL build in the background. Jeffrey Altman Mark Jaffe wrote: I have one other issue I need resolution on: when I run the make file under cygwin, the resulting libraries are exactly what I get on unix: libssl.a and libcrypto.a. What I want to know is how do I get ssleay32.dll and libeay32.dll? These are required to link m2crypto on Win32. Mark On May 10, 2004, at 5:17 PM, Steven Reddie wrote: Hi Andy, We have standards for the compilers that we use on each platform, and on Windows it is Microsoft's toolset. In our lab we use cygwin for the build framework so that we can use the same framework on Windows and Unix platforms. What I was trying to say was that rather than using the .bat files and nmake makefiles that come with OpenSSL for Windows builds, we use gcc2cl with cygwin and Microsoft's compiler to piggy-back onto the Unix-ey cygwin build target, thereby avoiding the .bat files and nmake files. We therefore pickup the ability to specify no-idea no-rc5 no-mdc2 in the same way for Unix and Windows builds, and the same goes for using the -shared option. It just makes the Windows OpenSSL build integrate into our build framework in the same way that the Unix builds do. Yes, it's a standard Win32. By fairly standard OpenSSL cygwin build I was referring to the parts of the OpenSSL build process that we are using rather than the compiler. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Tuesday, 11 May 2004 3:13 AM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin Steven, I've written a command-line utility called gcc2cl which acts like a gcc front-end while using Microsoft's compiler/linker at the backend. It translates options and does some munging of cl's stdout/stderr so as to fool autoconf into thinking it is really using gcc. This enables us (I did this at Computer Associates) to do a fairly standard OpenSSL cygwin build while using the Microsoft compiler/linker/libraries/runtime. Could you elaborate on fairly standard OpenSSL cygwin build. What's considered standard? I assume the way Cygwin is currently supported by OpenSSL... What's fair? What is the actual reason for dismissing gcc and trying to compile cygwin library with Microsoft compiler? Trouble is that Microsoft compiler generates code which is dependent on presence of Visual C run-time environment and it's a slippery way. Presense of 3rd party run-time components in a cygwin application might break some interfaces [fork is first one to come to mind]. Of course you might mean that the only cygwin component you use is make and sh [which is actually appealing!] and that resulting OpenSSL build does not contain any run-time dependencies from cygwin1.dll. But can you call it fairly standard *cygwin* build? Shouldn't it be called fairly standard *Win32* build? A. __ 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] Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ OpenSSL
RE: Win32 compiles under cygwin
Ok, I understand where you're coming from. What we have works fine, through we've not played around with Kerberos. I've created a new CygwinMSVC entry in Configure which uses enough of the Cygwin entry to integrate with the rest of the build framework, but uses a SYSNAME of WIN32 (not CYGWIN32) and sets other defines such as DSO_WIN32 so that it picks up the Microsoft-specific stuff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman Sent: Tuesday, 11 May 2004 12:52 PM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin Since the cygwin environment is different from the MS Run Time environment, I would not make the assumption that the binaries produced use exactly the same configuration options. They may but I would not count on it. I understand what you are attempting to do; I just do not know if the results will be the same. I know that with other packages such as Kerberos you absolutely do not get the same result when building under cygwin because the environment is more Unix like and therefore different assumptions are made. Jeffrey Altman Steven Reddie wrote: Jeffrey, Are you saying that using something like gcc2cl to kick off a build the way you do for cygwin, but using the Microsoft compiler, is the wrong way to go? It's working well for us in-house, though we've been using static libraries up until now and are just finishing up changes to support the DLL build. Mark, the naming issue is something that we need to handle also, although we need to use a custom name with the OpenSSL version number included. Whatever we can contribute will include support for altering the name. Steven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Can [EMAIL PROTECTED] be removed from the list(s)? (FW: Mail Returned (550 5.1.1 [EMAIL PROTECTED]... User unknown (RCPT)))
I receive one of the following for every message I send to the list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, 11 May 2004 2:08 PM To: Steven Reddie Subject: Mail Returned (550 5.1.1 [EMAIL PROTECTED]... User unknown (RCPT)) Your mail was returned Reason : 550 5.1.1 [EMAIL PROTECTED]... User unknown (RCPT) Returned mail --- From: Steven Reddie [EMAIL PROTECTED] To : [EMAIL PROTECTED] Subject : RE: Win32 compiles under cygwin --- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Win32 compiles under cygwin
Hi Mark, I've written a command-line utility called gcc2cl which acts like a gcc front-end while using Microsoft's compiler/linker at the backend. It translates options and does some munging of cl's stdout/stderr so as to fool autoconf into thinking it is really using gcc. This enables us (I did this at Computer Associates) to do a fairly standard OpenSSL cygwin build while using the Microsoft compiler/linker/libraries/runtime. Would this help you in any way? I've tried to contribute it to cygwin but was surprised that there was no interest. We also use it to build OpenLDAP, libxml2, log4cplus, and others almost out-of-the-box. Being able to avoid the OpenSSL .bat files and nmake makefiles helps us to integrate with our cross platform automated build process. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jaffe Sent: Monday, 10 May 2004 7:03 AM To: [EMAIL PROTECTED] Subject: Win32 compiles under cygwin Greetings to all. I am responsible to the build environment at OSAF, and we are integrating openssl into the Chandler product. I am concerned about generating the correct configuration, and wonder if someone has a solution. What we do when we incorporate an open-source project into ours is to prepare a script which sets up the configuration for each supported platform (Win32, linux, and OS X for now.) When we run make, it untars the source tarball, applies our patches and then does a configure and a make, installing the libraries into our distribution path. Where I am running into problems is in dealing with the Win32 build situation. We use the cygwin environment, and several of our projects already are compatible in that we call nmake and a DOS-path compatible make file which is working nicely. However, applying this method to the openssl tree has presented some difficulty. I have so far been successful in running a patched ms/32all.bat to generate the required xx.mak files, but the results still contain - style option flags rather than the desired / style. I am stumped at this point. Of course, I could do this under a local command-line but this is not available from remote ssh or in the environment in which we run the tinderbox. Any suggestions? Mark Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ 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]
RE: loading an RSA pubkey that is hex encoded and DER
Hi, I think the term you were looking for was binary, meaning not a text file. If by dgst you mean the openssl command line utility, try adding the parameter -keyform der. If that doesn't work you'll need to convert the key to PEM (base64 encoding of the DER). The command openssl rsa -inform der -in infilename -out outfilename should do the trick. There are other options that handle encryption of the key; run openssl rsa help to see them. If you are talking about the API, there are several ways to load such a key. One is to load the contents of the file into a buffer and use the function d2i_RSAPrivateKey to convert from Der to Internal format. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eleanor Nagai Sent: Sunday, 2 May 2004 9:34 AM To: '[EMAIL PROTECTED]' Subject: loading an RSA pubkey that is hex encoded and DER Hi! I'm somewhat new to the crypto world and openssl so I appologize if this comes across a bit confusing. I have an RSA public key generated by crypto++ that is in DER format and hex (not base64) encoded. I also have a signature created with the associated RSA private key using SHA1 digest and PKCS1v1.5 formatting that I need to verify. Is it possible to load the public key so that I can use dgst to verify the signature? Any help will be greatly appreciated. thanks, Eleanor __ 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]
RE: [openssl.org #873] [Fwd: Bug#243489: openssl: ca segfaults]
This issue has been fixed and committed. The check for NULL that you propose was added to the free_index function itself so that all callers of free_index benefit from the protection. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Martin via RT Sent: Wednesday, 21 April 2004 4:27 PM Cc: [EMAIL PROTECTED] Subject: [openssl.org #873] [Fwd: Bug#243489: openssl: ca segfaults] __ 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]
RE: [openssl.org #866] BUG REPORT: openssl-0.9.7d, ca command, null pointer exception, Visual Studio .NET 2003
This has been fixed in the latest 0.9.7 snapshots.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Fiel Cabral via RT
Sent: Thursday, 1 April 2004 7:59 PM
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #866] BUG REPORT: openssl-0.9.7d, ca command, null
pointer exception, Visual Studio .NET 2003
Hi, this is a bug report for openssl 0.9.7d from Fiel
Cabral.
Synopsis: The openssl ca command dereferences a null
pointer after an invalid CA private key password is entered through stdin.
OpenSSL version: output of 'openssl version -a'
OpenSSL 0.9.7d 17 Mar 2004
built on: Thu Mar 25 21:53:07 2004
platform: VC-WIN32
options: bn(64,32) md2(int) rc4(idx,int)
des(idx,cisc,4,long) idea(int) blowfish(idx)
compiler: cl /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy
/nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32
-DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_KRB5
OPENSSLDIR: /usr/local/ssl
OS Name, Version, Hardware platform
Windows XP Professional Version 5.1 (Build 2600.xpsp2.030422-1633 : Service
Pack 1)
Compiler Details (name, version)
Microsoft Visual C++ .NET (Visual Studio .NET 2003)
- Application Details (name, version)
openssl.exe ca command
- Problem Description (steps that will reproduce the problem, if known)
1. Run the openssl ca command.
openssl ca -config openssl.cnf -out mycert -notext
-batch -passin stdin -policy policy_anything -infiles mycsr
2. Type the wrong CA private key when prompted and press
enter.
3. openssl prints unable to load CA private key.
4. openssl has an access violation:
Unhandled exception at 0x00426156 in openssl.exe:
0xC005: Access violation reading location 0x0004.
Stack trace:
openssl.exe!free_index(ca_db_st * db=0x) Line
1973 + 0x3 C
openssl.exe!ca_main(int argc=1, char * * argv=0x003a4484)
Line 1506 + 0x9C
openssl.exe!do_cmd(lhash_st * prog=0x00a44a00, int
argc=13, char * * argv=0x003a4454) Line 381 + 0xe C
openssl.exe!main(int Argc=13, char * * Argv=0x003a4454)
Line 300 + 0x14 C
openssl.exe!mainCRTStartup() Line 398 + 0x11 C
kernel32.dll!77e814c7()
The free_index function was called with argument 1 of 1, db
= NULL.
void free_index(CA_DB *db)
{
TXT_DB_free(db-db);
OPENSSL_free(db);
}
- Stack Traceback (if the application dumps core)
Stack trace:
openssl.exe!free_index(ca_db_st * db=0x) Line
1973 + 0x3 C
openssl.exe!ca_main(int argc=1, char * * argv=0x003a4484)
Line 1506 + 0x9C
openssl.exe!do_cmd(lhash_st * prog=0x00a44a00, int
argc=13, char * * argv=0x003a4454) Line 381 + 0xe C
openssl.exe!main(int Argc=13, char * * Argv=0x003a4454)
Line 300 + 0x14 C
openssl.exe!mainCRTStartup() Line 398 + 0x11 C
kernel32.dll!77e814c7()
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
__
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]
RE: OpenSSL 0.9.7c Pocket PC 2003 Compile Error
Hi Chris, Can you tell me which line numbers you placed these pragmas at. I'm working on some fixes for the Windows CE support, mainly to support the newer compiler and SDKs, and can incorporate these changes. I've been building 0.9.7d recently with PPC2003 and haven't encountered any problems, however I've been doing debug builds so the optimiser probably hasn't come into play. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Brook Sent: Friday, 2 April 2004 1:57 AM To: [EMAIL PROTECTED] Subject: RE: OpenSSL 0.9.7c Pocket PC 2003 Compile Error Following up on this Pocket PC2003 problem report for any other developers who have encountered similar problems, we have contacted Microsoft and got a workaround as listed below. We applied the #pragma to rs2_setkey.c and everything now compiles and runs correctly. -- From Microsoft tech support: I am able to see the problem here. The problem is with the optimizer for ARMV4. The specific optimizations that cause the problem are in the global optimizations. This is being considered for a fix in a future release of the compiler. For the current release, we have a workaround as follows. Turn off the global optimizations for the specific block of code that is suspected to throw up this compiler error. You can do this by placing the block of suspect code within #pragma optimize( g, off ) . . // suspect code here . #pragma optimize( g, on ) If using the above concept, you can keep all optimizations turned on for the rest of your project. - Hopes this helps. Chris Brook -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steven Reddie Sent: Thursday, March 18, 2004 7:49 PM To: [EMAIL PROTECTED] Subject: RE: OpenSSL 0.9.7c Pocket PC 2003 Compile Error Hi Chris, I haven't seen that particular error before, but I have seen reports of problems with PPC2003. Try removing the /Gs0 option from the makefile are rebuild. It will probably be somewhere under wcecompat or OpenSSL's util, util/pl, or ms directories. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Brook Sent: Friday, 19 March 2004 8:00 AM To: Openssl-Dev (E-mail) Subject: OpenSSL 0.9.7c Pocket PC 2003 Compile Error When compiling OpensSSL 0.9.7c for Pocket PC 2003 using Microsoft EVC 4.0 SP2 with ARMV4 CPU option, we got the following compilation error sequence: clarm.exe /Fotmp32_ARMV4\rc2_skey.obj -Iinc32 -Itmp32_ARMV4 /W3 /WX /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DWCEPLATFORM=MS_POCKET_PC_2003 -DARM -DUNDER_CE=420 -D_WIN32_CE=420 -DUNICODE -D_UNICODE -DWIN32 -D_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DNO_CHMOD -Ic:\openssllib\openssl-0.9.7c-WinCE\wcecompat/include /Fdout32_ARMV4 -DOPENSSL_NO_KRB5 -c .\crypto\rc2\rc2_skey.c Command line warning D4002 : ignoring unknown option '/Gs0' rc2_skey.c c:\openssllib\openssl-0.9.7c-wince\crypto\rc2\rc2_skey.c(137) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'D:\vcmckendric\compiler\utc\src\P2\main.c', line 148) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information NMAKE : fatal error U1077: 'clarm.exe' : return code '0x2' Stop. Has anybody else tried compiling Pocket PC2003 with 0.9.7c? Any problem like this? Any suggested solution? Chris Brook V-ONE __ 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] __ 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]
RE: [openssl.org #853] serial/index file handling broken on Windows in 0.9.7d
Hi Richard, Sorry for the delay. The snapshot from after you asked me to test it the first time (openssl-0.9.7-stable-SNAP-20040327) passed my tests. Thanks, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Levitte via RT Sent: Wednesday, 31 March 2004 7:15 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #853] serial/index file handling broken on Windows in 0.9.7d Hello, I would very much like to know if my fix worked, so I can close this ticket. [levitte - Thu Mar 25 21:10:19 2004]: I think I fixed the problem by moving the definition of Win32_rename() to the end of apps.c. Please check tomorrow's 0.9.7 snapshot and come back to me with any feedback (even hoorays :-)). [EMAIL PROTECTED] - Mon Mar 22 17:17:44 2004]: Re: openssl-dev thread: New CA index subfiles (.attr, .attr.new, . attr.old, .new) OpenSSL 0.9.7d introduces a bug on Windows in the openssl executable in relation to the renaming of temporary serial and index files. The renames are failing since the special WIN32_rename() function (which removes the destination file before the rename) is not being used on Windows due to the rename macro being undefined before it is used. I think the problem was introduced when the serial/index file handling code was tacked onto the end of apps.c. With similar code in a separate module previously the undef was not having such an effect. I've verified that redefining rename by copying line 140 of apps.h and inserting it after line 353 of apps.c fixes all of the problems with serial and index files that I was experiencing: apps.c:352 #undef rename apps.c:353 return rename(from, to); apps.h:140 #define rename(from,to) WIN32_rename((from),(to)) Regards, Steven -- Richard Levitte [EMAIL PROTECTED] __ 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]
RE: Re: document
That was one of the worms doing the rounds at the moment. It sends a 20-30KB zipfile and fakes the sender's email address. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Christensen Sent: Thursday, 25 March 2004 12:22 PM To: [EMAIL PROTECTED] Subject: Re: Re: document It is inherently NOT SAFE to open attachments from people you do not know. Please do not send attachments to the list unless the moderator approves it (and he probably will not). Bruce You wrote on 24/03/2004 3:47:59 PM: Please read the document. __ 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]
[openssl.org #853] serial/index file handling broken on Windows in 0.9.7d
Re: openssl-dev thread: New CA index subfiles (.attr, .attr.new, .attr.old, .new) OpenSSL 0.9.7d introduces a bug on Windows in the openssl executable in relation to the renaming of temporary serial and index files. The renames are failing since the special WIN32_rename() function (which removes the destination file before the rename) is not being used on Windows due to the rename macro being undefined before it is used. I think the problem was introduced when the serial/index file handling code was tacked onto the end of apps.c. With similar code in a separate module previously the undef was not having such an effect. I've verified that redefining rename by copying line 140 of apps.h and inserting it after line 353 of apps.c fixes all of the problems with serial and index files that I was experiencing: apps.c:352 #undef rename apps.c:353 return rename(from, to); apps.h:140 #define rename(from,to) WIN32_rename((from),(to)) Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Patch to support -crlsecs in openssl ca command
Title: Message Hi All, I've attached a simple patch (against 0.9.7d) which adds support for -crlsecs to the ca command. This is useful for testing of components that automatically fetch updated CRLs as they expire -- the current granularity of an hour makes for a long test. Regards, Steven ca.c.crlsecs.patch Description: Binary data
Bug in 0.9.7d apps/ocsp.c
Title: Message Hi All, I'm getting a crash in apps/ocsp.c in the new 0.9.7d kit. Line 876 now calls free_index(rdb) where it used to use TXT_DB_free. If rdb is NULL (as can happen with ocsp when -index isn't specified) free_index fails due to a NULL pointer dereference. free_index at the bottom of apps.c could do with a NULL pointer check. Regards, Steven
FIPS progress
Title: Message Hi Ben, How is the FIPS accreditation progressing? The OSS Institute website doesn't seem to have been updated recently, but I see you're still checking in changes. Do you have any idea of an expected end date? Regards, Steven
RE: Problems with GENERAL_NAMES on IMPLICIT mode
I think I recall that since GeneralName is a CHOICE that using it with
IMPLICIT tags requires the implicit tag to be declared explicitly to avoid
ambiguity. I'm not an ASN.1 expert but I've come across this problem before
and had to work around it by reversing the implicit tag of GeneralName.
I've never been 100% sure of this although I never found a case that
disobeyed this rule. If you find anymore out I'd appreciate hearing about
it.
Steven
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Fernando Moya
Sent: Friday, 30 May 2003 2:20 AM
To: [EMAIL PROTECTED]
Subject: Problems with GENERAL_NAMES on IMPLICIT mode
Hi, I am having problems with GENERAL_NAMES in the following sequence: :
-
DEFINITIONS IMPLICIT TAGS
Seq1 ::= SEQUENCE
{
field1 INTEGER,
field2 Seq2
}
Seq2 ::= SEQUENCE
{
sub_field1 [0] Sub_seq_000 OPTIONAL,
sub_field2 [1] GENERAL_NAMES OPTIONAL,
sub_field3 [2] Sub_seq_200 OPTIONAL
}
-
Implemented by:
ASN1_SEQUENCE(Seq2) = {
ASN1_IMP_OPT(Seq2, Sub_field1, Sub_seq_000,0),
ASN1_IMP_OPT(Seq2, Sub_field2, GENERAL_NAMES,1),
ASN1_IMP_OPT(Seq2, Sub_field3, Sub_seq_200,2),
} ASN1_SEQUENCE_END(Seq2)
IMPLEMENT_ASN1_FUNCTIONS(Seq2)
ASN1_SEQUENCE(Seq1) = {
ASN1_SIMPLE(Seq1, field1,INTEGER),
ASN1_SIMPLE(Seq1, field2, Seq2)
} ASN1_SEQUENCE_END(Seq1)
IMPLEMENT_ASN1_FUNCTIONS(Seq1)
Note: GENERAL_NAMES is defined at crypto/x509v3/x509_v3.h and
crypto/x509v3/v3_genn.c
The problem is when I call to i2d_Seq1 with an example code, the DER
output is:
(output from ASN.1 Dump Utility)
SEQUENCE
{
INTEGER 1
SEQUENCE
{
[0] {
SEQUENCE
{
...
}
}
=== {
[2] 'DNS_GENERALNAMES'
}
[2] {
SEQUENCE
{
...
}
}
}
(Attention to the arrow )
instead of:
SEQUENCE
{
INTEGER 1
SEQUENCE
{
[0] {
SEQUENCE
{
...
}
}
== [1]{
[2] 'DNS_GENERALNAMES'
}
[2] {
SEQUENCE
{
...
}
}
}
The point is, I can't obtain [1] tag in GENERAL_NAMES. I have tried to put
GENERAL_NAMES in other situations (always in IMPLICIT mode) and it never
puts tags. En cambio, I have tried in EXPLICIT mode and it works fine, but I
need IMPLICIT tags.
How can I obtain this IMPLICIT tag in DER output?
Thanks in advance.
Fernando Moya Bernal.
University of Malaga. Spain.
__
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]
RE: Problems with GENERAL_NAMES on IMPLICIT mode
Thanks for the clarification. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dr. Stephen Henson Sent: Friday, 30 May 2003 9:15 AM To: [EMAIL PROTECTED] Subject: Re: Problems with GENERAL_NAMES on IMPLICIT mode On Fri, May 30, 2003, Steven Reddie wrote: I think I recall that since GeneralName is a CHOICE that using it with IMPLICIT tags requires the implicit tag to be declared explicitly to avoid ambiguity. I'm not an ASN.1 expert but I've come across this problem before and had to work around it by reversing the implicit tag of GeneralName. I've never been 100% sure of this although I never found a case that disobeyed this rule. If you find anymore out I'd appreciate hearing about it. While that's correct this case refers to GeneralNames not GeneralName. Since GeneralNames is a SEQUENCE OF GeneralName and has a SEQUENCE tag it can have an IMPLICIT tag itself because that would change the SEQUENCE tag which is not ambiguous. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ 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]
RE: [openssl.org #499] Status update?
I can't speak on behalf of the OpenSSL team, but it's more usual to refer to such ports as OpenSSL for VOS. This has become the standard approach due to lawsuits where Microsoft forced companies to change the names of their products from Windows XXX to XXX for Windows. I think Sun also won a similar suit in the past couple of months to force a product name change from Java XXX to XXX for Java. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Green, Paul Sent: Wednesday, 19 February 2003 7:21 AM To: OpenSSL Development (E-mail) Subject: [openssl.org #499] Status update? I'm looking for status on my request, on behalf of Stratus, to use the term VOS OpenSSL to refer to our port of openssl to our VOS operating system. I originally submitted this request on February 6th. Thanks PG -- Stratus Technologies 111 Powdermill Road Maynard, MA 01754-3409 U.S.A. Paul Green Senior Technical Consultant TEL +1 (978) 461-7557 FAX +1 (978) 461-3610 __ 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]
RE: 0.9.7 Beta 6 testing with WinCE
Thanks for the info Chris. As per our private email these issues are with wcecompat and so don't require any changes to OpenSSL. I'm very busy at the moment so haven't got around to fixing it, but it sounds like it's not a showstopper for you. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Brook Sent: Wednesday, 18 December 2002 8:49 AM To: Openssl-Dev (E-mail) Subject: 0.9.7 Beta 6 testing with WinCE We have built and tested 0.9.7 Beta 6 with the following WinCE devices: HPC Pro 2.11 HPC 2000 PocketPC 2000 PocketPC 2002 All build, link and run fine except that, for HPC Pro 2.11, the WCE Compatibility Library contains two functions that need to be deleted before linking; currently we do this manually. The functions are '_iswctype' and '_towupper' which, in HPC Pro 2.11, are provided in the system libraries, resulting in multiply defined errors when we link. Chris Brook __ 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]
RE: [PATCH] Windows CE (against openssl-0.9.7-stable-SNAP-20021201)
Sure. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Tuesday, 3 December 2002 9:12 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] Windows CE (against openssl-0.9.7-stable-SNAP-20021201) In message [EMAIL PROTECTED] on Tue, 3 Dec 2002 02:38:33 +1100, Steven Reddie [EMAIL PROTECTED] said: smr I've made some changes to wcecompat to support other Windows CE platforms, smr the necessary changes to OpenSSL are attached. I've also included smr cryptlib.h in several files so that the OPENSSL_cleanse prototype is smr declared. Without it I am getting compiler failures, and it's probably a smr general Win32 problem. Thanks for catching that. However, I'm surprised that you didn't include openssl/crypto.h, which is what I encouraged (admitedly in a not very outspoken way...). Mind if I change that? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
RE: Building openssl-0.9.7-beta4
Have you tried the same code on some other platform like Linux or Windows?
I don't have time to look over your code, but I did notice that the first 8
bytes of the output are not what you expected and the remaining data is
decrypted correctly. Seems like maybe you need to initialise a salt/IV
value. I'm running OpenSSL on a StrongARM (Windows CE) and haven't seen any
problems like this.
Steven
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of bepsy paul
Sent: Thursday, 21 November 2002 8:25 AM
To: [EMAIL PROTECTED]
Subject: Building openssl-0.9.7-beta4
Hi,
I am trying to port openssl on vxWorks(Tornado 2.0 vxWorks 5.4) for
StrongArm(ixp1200) platform. I have a problem here. The encryption is not
working for me. My code is as given below. I am using 3DES encryption first.
Then to verify the output I am doing a decryption for the encrypted output.
I am not getting the original input after decryption. I am not enabling
DES_PTR or DES_UNROLL or any other flags in particular. Does anyone know
what is going wrong here?
T_VOID DoCipher(T_VOID* pCipherCtx)
{
int i;
T_UCHAR8 *OutputBuf = calloc(64,sizeof(T_UCHAR8));
T_UCHAR8 *OutputBuf2 = calloc(64,sizeof(T_UCHAR8));
T_UCHAR8 InputBuf[] = {
0x30 ,0x31 ,0x32 ,0x33 ,0x34 ,0x35 ,0x36 ,0x37,
0x38 ,0x39 ,0x0a ,0x61 ,0x62 ,0x63 ,0x64 ,0x65,
0x66 ,0x67 ,0x68 ,0x69 ,0x6a ,0x0a ,0x6b ,0x6c,
0x6d ,0x6e ,0x6f ,0x70 ,0x71 ,0x72 ,0x73 ,0x74,
0x0a ,0x75 ,0x76 ,0x77 ,0x78 ,0x79 ,0x7a ,0x2e,
0x2e ,0x2e ,0x2e ,0x0a ,0x41 ,0x42 ,0x43 ,0x44,
0x45 ,0x46 ,0x47 ,0x48 ,0x49 ,0x4a ,0x0a ,0x4b,
0x4c ,0x4d ,0x4e ,0x4f ,0x50 ,0x51 ,0x52 ,0x53
};
((EVP_CIPHER_CTX*)pCipherCtx)-encrypt = 1; /* Encrypt data first */
printf(\n\r Calling Encryption, EncryptFlag =%d \n\r InputData =
\n\r,((EVP_CIPHER_CTX*)pCipherCtx)-encrypt);
for(i=0;i64;i++)
printf(%x ,*(InputBuf+i));
/* This 'do_cipher' invokes 'des_cbc_ede_cipher' from 'e_cbc_3d.c' file */
((EVP_CIPHER_CTX*)pCipherCtx)-cipher-do_cipher((EVP_CIPHER_CTX*)pCipherCtx
,OutputBuf,
InputBuf,64);/* Encryption function */
printf(\n\r Finished Encryption, EncryptFlag =%d \n\r OutputData =
\n\r,((EVP_CIPHER_CTX*)pCipherCtx)-encrypt);
for(i=0;i64;i++)
printf(%x ,*(OutputBuf+i));
((EVP_CIPHER_CTX*)pCipherCtx)-encrypt = 0; /* Decrypt the output data */
printf(\n\r Calling Decryption, EncryptFlag =%d \n\r InputData =
\n\r,((EVP_CIPHER_CTX*)pCipherCtx)-encrypt);
for(i=0;i64;i++)
printf(%x ,*(OutputBuf+i));
/* This 'do_cipher' invokes 'des_cbc_ede_cipher' from 'e_cbc_3d.c' file */
((EVP_CIPHER_CTX*)pCipherCtx)-cipher-do_cipher((EVP_CIPHER_CTX*)pCipherCtx
,OutputBuf2,
OutputBuf,64); /* Decryption function */
printf(\n\r Finished Decryption, EncryptFlag =%d \n\r OutputData =
\n\r,((EVP_CIPHER_CTX*)pCipherCtx)-encrypt);
for(i=0;i64;i++)
printf(%x ,*(OutputBuf2+i));
return;
}
My printf results are as follows
Calling Encryption, EncryptFlag =1
InputData =
30 31 32 33 34 35 36 37 38 39 a 61 62 63 64 65 66 67 68 69 6a a 6b 6c 6d 6e
6f 70 71 72 73 74 a 75 76 77 78 79 7a 2e 2e 2e 2e a 41 42 43 44 45 46 47 48
49 4a 4b 4c 4d 4e 4f 50 51 52 53
Finished Encryption, EncryptFlag =1
OutputData =
fd cd 8 dc 9a 47 ea c3 d7 dc 12 4e d3 7a 4d 73 a7 ad 29 b7 d4 10 86 62 1f 9d
b4 e3 a6 3a 1f 31 51 43 f5 19 af 98 6f 2c 23 c2 5c 9c c6 9a 30 34 c 59 d6 9f
2a 51 71 55 93 fb 9b a7 18 11 6c 4e
Calling Decryption, EncryptFlag =0
InputData =
fd cd 8 dc 9a 47 ea c3 d7 dc 12 4e d3 7a 4d 73 a7 ad 29 b7 d4 10 86 62 1f 9d
b4 e3 a6 3a 1f 31 51 43 f5 19 af 98 6f 2c 23 c2 5c 9c c6 9a 30 34 c 59 d6 9f
2a 51 71 55 93 fb 9b a7 18 11 6c 4e
Finished Decryption, EncryptFlag =0
OutputData =
a6 1e 90 53 e5 b b7 84 38 39 a 61 62 63 64 65 66 67 68 69 6a a 6b 6c 6d 6e
6f 70 71 72 73 74 a 75 76 77 78 79 7a 2e 2e 2e 2e a 41 42 43 44 45 46 47 48
49 4a a 4 b 4c 4d 4e 4f 50 51 52 53
Does anyone has specific files- Configure/Makefile -for vxworks strongarm
platform? Or anyone knows which all flags need to be enabled for vxWorks
strongarm platform? Or where can I find the detailed procedure for vxWorks
platform compilation/installation?
Please help. I am new to openssl porting area.
Thanks in advance,
Best Regards,
BPaul
From: Chris Jarshant [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: OCSP app bug
Date: Wed, 20 Nov 2002 14:46:19 -0500
The OCSP app seems to not handle the -rother option correctly.
Look at apps/ocsp.c. The 'rcertfile' variable in main() is
set when you give the app the -rother option, but then
it's not used in the load_certs() invocation.
This effectively hangs the ocsp app when the -rother switch
is used, since it's trying to read certs from stdin.
cj
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
__
OpenSSL Project http://www.openssl.org
Development Mailing
RE: [openssl.org #347] DJGPP patch for openssl-0.9.7
Richard, I think the FLAT_INC in ectest.c was something you introduced when committing the Windows CE changes. It looks like other files, like enginetest.c, simply include openssl/e_os2.h. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] via RT Sent: Wednesday, 20 November 2002 2:46 AM Cc: [EMAIL PROTECTED] Subject: [openssl.org #347] DJGPP patch for openssl-0.9.7 The following patch allows openssl-0.9.7 to compile under DJGPP. The process was broken by two recent changes. Gisle's patch left out some required headers. The changes for Cygwin added PATH directives incompatible with the DJGPP path separator of ; rather than :. In addition there seems to be an error in ectest.c. That file is run from the test subdirectory. The FLAT_INC portion of the code doesn't work under DJGPP, and I am not sure how it would under other platforms (referring to ../.. when it is one directory under the top directory). None of the other test files which include e_os.h use this construction. I would think that either all need it, or none of them. I also changed INSTALL.DJGPP to reflect the need to put WATT_ROOT in the environment prior to configuring. I am attaching the patch, since it has long lines that would get munged in the archives. Since I am in the US, I am also sending a copy to the US government site. With the new regulations, it doesn't appear that I can just send a copy of this email. Look for a copy of my notification in openssl-dev with subject TSU Request - encryption. The patch is against the 20001115 snapshot. After applying tha patch, there are no warnings with make depend, make, make test, or make install. This was only tested with Configure no-threads no-idea no-rc5 no-mdc2 386 --prefix=/dev/env/DJDIR DJGPP. Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] __ 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]
RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot)
Richard Levitte - VMS Whacker said:
time_t can be anything. It can be a nose-picking monster for all I
know. All that matters is that it should represent time in some way,
and be usefull in that way for any function that takes a time_t as an
argument. Under VMS (with DEC C), time_t is defined like this:
typedef __time_t time_t;
and __time_t is defined like this:
typedef unsigned long int __time_t;
Ok, so unsigned isn't as uncommon as I thought. Apparently
(http://mail-index.netbsd.org/port-alpha/1996/07/10/.html):
time_t is defined by ANSI/ISO 9899-1990 (7.12.1) as an arithmetic
type capable of representing times.
Not only does the standard *not* say how big time_t is, it doesn't
even say if it is signed or unsigned. And the definition of arithmetic
type includes floats too.
To represent time as a 64-bit blob, one could very well have this:
typedef struct { unsigned long t1, t2; } time_t;
The above reference says that this is impossible, but a long long or an
int64 if the compiler supports it should be okay.
That's why I'm asking you to tell me what problems you have with
time_t. It may be that some of the OpenSSL code does incorrect
assumptions about time_t (for example assumes that it's a long), and
therefore behaves incorrectly and should be corrected.
Since I'm using the MSVC++ /W3 /WX options (max warnings, treat warnings as
errors), the following two numbered lines in x509_vfy.c are giving errors:
time_t offset;
807: offset= -offset;
813: X509_time_adj(atm,-offset*60, cmp_time);
I will simply *not* change time_t to long in OpenSSL. That's going
backwards.
Fair enough, I agree, but in this instance I think it's the right change
since the second parameter of X509_time_adj is a long.
It doesn't make much sense to run VC from Cygwin either, or does it?
No, not from within a bash shell, though it could be done except for running
the batch files for the tests. Since I have Cygwin installed and have it's
/bin directory in the Windows path, I use Cygwin's perl. I'm sure this
isn't an unusual setup for anyone who uses Cygwin. Yeah, maybe it just
makes it sound confusing to mention any of this :-)
Anyway, I'm sorry for the harsch notes. I think you've done a great
job doing this Windows CE port.
No problem, no offence taken, I too want the code to be right. Thanks for
all of your work to get these changes in.
Regards,
Steven
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot)
No worries. That should finish up the Windows CE port now. Thanks for your help. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Tuesday, 19 November 2002 12:00 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot) In message [EMAIL PROTECTED] on Mon, 18 Nov 2002 22:24:18 +1100, Steven Reddie [EMAIL PROTECTED] said: smr Since I'm using the MSVC++ /W3 /WX options (max warnings, treat warnings as smr errors), the following two numbered lines in x509_vfy.c are giving errors: smr time_t offset; smr807: offset= -offset; smr813: X509_time_adj(atm,-offset*60, cmp_time); Hmm, and now I realise I've been staring too much at 'time_t' without looking at the rest of the code there. offset isn't a measurement of time since Epoch, so it's an error to pretend it's a time_t. You're absolutely correct in saying it should be a long. Sorry for all the misdirected fuss... BTW, did you not ask me about some function that calculates the difference between to time_ts? That function is difftime(), and it returns a double. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot)
It may not necessarily be intuitive to CE developers either, it's just the way I chose to do it because it integrates with an automated build system better than the other choice. Maybe appending the following to INSTALL.WCE will make things clearer: This will copy each of the test programs to the Windows CE device and execute them, displaying the output of the tests on this computer. The output should look similar to the output produced by running the tests for a regular Windows build. I've tried the latest snapshot and found that a time_t variable needs to be changed to a long. Windows CE's time_t is unsigned, whereas I think just about every other platform must have it signed. I'm pretty sure that there's an ANSI or standard Unix function that takes or returns a time_t that is an offset from another time_t, so it probably needs to be signed to allow values before the other time. Also, the infamous 2038 bug is due to a signed time_t (unsigned would make it at least give us until 2106). It's the offset = -offset which causes the problem here. Attached is a patch to 20021116 which changes this time_t to long and also makes the output directories tmp32_$(TARGETCPU) and out32_$(TARGETCPU), eg. tmp32_ARM and out32_ARM. Chris, this means that you can do the following steps to build for each processor (though I'd be surprised if most shops need to build for all CPU's since Microsoft has started to drop support for everything but the ARM): perl Configure VC-CE (only do this once) ms\do_ms.bat (only do this once) C:\Program Files\Microsoft eMbedded Tools\EVC\WCE300\BIN\WCEARM.BAT nmake -f ms\ce.mak C:\Program Files\Microsoft eMbedded Tools\EVC\WCE300\BIN\WCEMIPS.BAT nmake -f ms\ce.mak C:\Program Files\Microsoft eMbedded Tools\EVC\WCE300\BIN\WCEx86.BAT nmake -f ms\ce.mak I left the comment in INSTALL.WCE (from INSTALL.W32) about Cygwin's perl since it's a viable option. Even though I'm building in a regular Windows command shell I'm using Cygwin's perl. Maybe it's not worth mentioning though; I'm sure anyone with Cygwin can work out that they don't really need ActiveState's perl. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Saturday, 16 November 2002 8:43 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot) In message [EMAIL PROTECTED] on Sat, 16 Nov 2002 15:18:12 +1100, Steven Reddie [EMAIL PROTECTED] said: smr Everything is done from the Windows box. The test*ce*.bat files use cecopy smr to copy files to the device and cerun to invoke the test programs. The smr output of the tests is redirected back through cerun, kind of like using smr rsh. Thanks. I guess this should be rather clear if you're actually a CE user :-). smr I'll look into the time_t problem and get back to you later today. Thanks. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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-0.9.7-stable-SNAP-20021116-windowsce.patch Description: Binary data
[PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot)
Finally I've finished this port. The patches are very minimal because the majority of the work is in a seperate library available from my website (www.essemer.com.au/windowsce/). After applying the patch: cd openssl-0.9.7-stable-SNAP-20021114 unzip openssl-0.9.7-stable-SNAP-20021114-windowsce.patch.zip patch -Np1 openssl-0.9.7-stable-SNAP-20021114-windowsce.patch follow the build instructions in INSTALL.WCE. I've only tested this on the Compaq iPaq (StrongARM). Regards, Steven openssl-0.9.7-stable-SNAP-20021114-windowsce.patch.zip Description: Zip compressed data
RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot)
I thought that OPENSSL_SYSNAME_* was the new way of doing things, so I changed the Microsoft standard UNDER_CE to OPENSSL_SYSNAME_WINCE at the last minute. I think I had to pull in e_os.h in one of the files to make sure this was defined. I'll change it all back. Whoops, last-minute late-night mistake. The file should be in util/pl, but it's the one in the root directory that is the correct one to use. I'll send a new patch later today. Steven -Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] Sent: Saturday, 16 November 2002 6:41 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot) Thanks! Looks good for the most part, the only thing that's just non-traditional is the direct use of OPENSSL_SYSNAME_WINCE, but that's easily taken care of. Oh, yeah, is there any reason to keep VC-CE.pl (as opposed to util/pl/VC-CE.pl)? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot)
Richard, I just noticed that you've commited the changes, and changed OPENSSL_SYSNAME_WINCE, thanks. Could you please replace util/pl/VC-CE.pl with the one in the root directory, or just change the double quotes around $lflags at line#16 with single quotes. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Steven Reddie Sent: Saturday, 16 November 2002 2:51 PM To: Richard Levitte - VMS Whacker; [EMAIL PROTECTED] Subject: RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot) I thought that OPENSSL_SYSNAME_* was the new way of doing things, so I changed the Microsoft standard UNDER_CE to OPENSSL_SYSNAME_WINCE at the last minute. I think I had to pull in e_os.h in one of the files to make sure this was defined. I'll change it all back. Whoops, last-minute late-night mistake. The file should be in util/pl, but it's the one in the root directory that is the correct one to use. I'll send a new patch later today. Steven -Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] Sent: Saturday, 16 November 2002 6:41 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot) Thanks! Looks good for the most part, the only thing that's just non-traditional is the direct use of OPENSSL_SYSNAME_WINCE, but that's easily taken care of. Oh, yeah, is there any reason to keep VC-CE.pl (as opposed to util/pl/VC-CE.pl)? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot)
Chris, thanks for taking the time to test the patch. I'll take a look at using the %TARGETCPU% to output built files to tmpARM, outARM, outdllARM instead of tmp32, out32, out32dll. Steven -Original Message- From: Chris Brook [mailto:[EMAIL PROTECTED]] Sent: Saturday, 16 November 2002 8:18 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot) We have built Steven's patch successfully for PocketPC and PocketPC 2002. The issue is the many different hardware versions it needs to be compiled for. With the makefile approach (Steven's), a separate build has to be done for each CPU type - a somewhat labour-intensive exercise :-) Martin Erdrich's patch included an MS project file that let one build all N versions at one time. Any suggestions on how this can be handled in OpenSSL? If one is only building a specific CPU, the makefile is fine, but most developers/vendors will build for a larger set of CPU's. Chris Brook -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Friday, November 15, 2002 2:41 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot) Thanks! Looks good for the most part, the only thing that's just non-traditional is the direct use of OPENSSL_SYSNAME_WINCE, but that's easily taken care of. Oh, yeah, is there any reason to keep VC-CE.pl (as opposed to util/pl/VC-CE.pl)? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot)
Everything is done from the Windows box. The test*ce*.bat files use cecopy to copy files to the device and cerun to invoke the test programs. The output of the tests is redirected back through cerun, kind of like using rsh. I'll look into the time_t problem and get back to you later today. Steven -Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] Sent: Saturday, 16 November 2002 8:04 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot) OK, there are a couple of things that are unclear to me: 1. INSTALL.WCE is a very good description, although it should have Perl among the list of requirements at the beginning. I can add that. One thing is unclear, however: does one do everything on the WinCE device? Or everything on a Windows box? My theory is that there's a middle ground, where you build everything on a Windows box, then transfer the result to the WinCE device, and run the tests there. Please give me a way to make this clear. 2. Where did you get that time_t couldn't be unsigned? I assume that if you go with the unsigned value, you get build warnings. If you could point those out, I'd be happier. I'm gonna commit in a few minutes, *without* the changes re time_t. If you coudl send further patches relative to that (i.e. snapshot 1115), it would be great. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
Fixes for some Windows build failures
These are based on the 1113 snapshot. The first two are warnings, but the compiler options being used treat warnings as errors. crypto/aes/aes_cbc.c at lines 84 and 106 need a typecast to avoid signed/unsigned mismatch warning: for(n=0; n len; ++n) becomes: for(n=0; n (int)len; ++n) apps\ca.c line 1339 needs a typecast: if(strlen(outdir) = (j ? BSIZE-j*2-6 : BSIZE-8)) becomes: if((int)strlen(outdir) = (j ? BSIZE-j*2-6 : BSIZE-8)) crytpto/buffer/buffer.h needs to include stddef.h for size_t __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Fixes for some Windows build failures
Yes, that's better. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of Richard Levitte - VMS Whacker Sent: Friday, 15 November 2002 2:55 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Fixes for some Windows build failures In message [EMAIL PROTECTED] on Fri, 15 Nov 2002 02:28:11 +1100, Steven Reddie [EMAIL PROTECTED] said: smr These are based on the 1113 snapshot. The first two are warnings, but the smr compiler options being used treat warnings as errors. smr smr crypto/aes/aes_cbc.c at lines 84 and 106 need a typecast to avoid smr signed/unsigned mismatch warning: smrfor(n=0; n len; ++n) smr becomes: smrfor(n=0; n (int)len; ++n) Does it work if we change: int n; to: unsigned long n; ? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
RE: Reference to unistd.h in Windows build of OpenSSL 0.9.6g
I'm looking at the 0.9.7 version of that file, and the #include unistd.h is inside something like #if !defined(MSDOS) || defined(DJGPP). MSDOS get's defined in e_os2.h for Windows builds, so this block of code should be disabled. Does it look to be the same for the source you have? -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of HOWARD,KEVIN (HP-Seattle,ex1) Sent: Saturday, 9 November 2002 5:49 AM To: '[EMAIL PROTECTED]' Subject: Reference to unistd.h in Windows build of OpenSSL 0.9.6g When I attempt to do a VC++ compilation for a Win32 build of OpenSSL 0.9.6g after running ms\do_ms, I am presented with an error, Cannot open include file: 'unistd.h', for the file \crypto\engine\hw_aep.c (SEE CONSOLE OUTPUT BELOW). The include file, 'unistd.h', is not available for Windows platforms. Is this a bug in this version, should this file be excluded from my make, or is there some other step I need to take to get a Win32 build? Thanks, Kevin Howard - C:\Documents\PPU\OpenSSL\openssl-engine-0.9.6cnmake -f ms\ntdll.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. Building OpenSSL cl /Fotmp32dll\hw_aep.obj -Iinc32 -Itmp32dll /MD /W3 /WX /G5 /Ox /O2 /O b2 /Gs0 /GF /Gy /nologo -DWIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 /Fd out32dll /GD -D_WINDLL -D_DLL -c .\crypto\engine\hw_aep.c hw_aep.c .\crypto\engine\hw_aep.c(61) : fatal error C1083: Cannot open include file: 'uni std.h': No such file or directory NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. -- __ 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]
Bug [and fix] in apps/ca.c in latest 0.9.7 snapshot on Windows
I've just downloaded the November 5th 0.9.7 snapshot and found a bug on Windows. The fix is a single liner, so I haven't gone to the trouble of preparing a patch: apps/ca.c line#96 needs to be changed from: # elif !defined(OPENSSL_SYS_VXWORKS) to: # elif !defined(OPENSSL_SYS_VXWORKS) !defined(OPENSSL_SYS_WINDOWS) to keep sys/file.h from being included on Windows platforms (it doesn't exist). I guess some recent change has resulted in ca.c not indirectly including e_os.h, because it was the inclusion of the definitions in this file that prevented this bug from showing up previously. Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Bug [and fix] in apps/ca.c in latest 0.9.7 snapshot on Windows
Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of Richard Levitte - VMS Whacker Sent: Friday, 8 November 2002 8:40 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Bug [and fix] in apps/ca.c in latest 0.9.7 snapshot on Windows In message [EMAIL PROTECTED] on Fri, 8 Nov 2002 00:14:54 +1100, Steven Reddie [EMAIL PROTECTED] said: smr apps/ca.c line#96 needs to be changed from: smr smr# elif !defined(OPENSSL_SYS_VXWORKS) smr smr to: smr smr# elif !defined(OPENSSL_SYS_VXWORKS) !defined(OPENSSL_SYS_WINDOWS) smr smr to keep sys/file.h from being included on Windows platforms (it doesn't smr exist). Thanks, I just committed that change. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
RE: Windows CE Patch for OpenSSL 0.9.6g
Sure, I've spent far, far too many hours on this so I'm not going to throw it away. I've just finished tying up the last loose ends with redirecting stdin/stdout/stderr between the desktop and Windows CE device which is needed for the automated tests. I should be able to send something in the next day or so. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of Richard Levitte - VMS Whacker Sent: Wednesday, 6 November 2002 2:06 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Windows CE Patch for OpenSSL 0.9.6g In message [EMAIL PROTECTED] on Wed, 6 Nov 2002 01:45:57 +1100, Steven Reddie [EMAIL PROTECTED] said: smr I'm a few days away from submitting my patch. It looks like smr we've done quite similar work which I guess isn't surprising smr since we've both had to plug the holes in the Windows CE CRT smr implementation. My approach differs in that I've seperated out smr this compatibility layer into a seperate library since it will be smr generally useful to other Windows CE development projects. [...] I'd appreciate it if my response to Martin didn't discourage you from contributing your patch. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
RE: Windows CE Patch for OpenSSL 0.9.6g
Hi Martin, I'm a few days away from submitting my patch. It looks like we've done quite similar work which I guess isn't surprising since we've both had to plug the holes in the Windows CE CRT implementation. My approach differs in that I've seperated out this compatibility layer into a seperate library since it will be generally useful to other Windows CE development projects. I've also used the makefiles instead of VC project files. The compatibility layer that I've done goes futher, being general purpose, and allow piping between processes. I've used this to enable automated tests similar to the current Win32 openssl tests. It even allows you to invoke the openssl command-line utility on the device from the desktop and use it as you would the a native Win32 version. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of Martin Erdrich Sent: Wednesday, 6 November 2002 12:52 AM To: [EMAIL PROTECTED] Subject: Windows CE Patch for OpenSSL 0.9.6g Here's a patch that allows OpenSSL to be compiled for Windows CE: - apply the patch to Version 0.9.6g. - runperl Configure VC-WIN32 , ms\do_ms.bat , nmake /f ms\do_nt.mak as usual - the subdirectory wce contains several embedded Visual C++ project files to build dll's and static libraries. The static libraries a trimmed to minimum size with several new NO_XYZ #defines Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: MAIL MALFUNCTION: [openssl.org #322] AutoReply: About RSA_check_key
Someone on the list is infected with the Win32.Bugbear worm, see www.vet.com.au. I've been getting a fair bit of these strange messages recently. Bugbear scans the computer for email, and can compose a message taken from a fragment of email that it finds, fake the from address with an address also from email that it finds, and send it to the email addresses that it finds. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of Alessandro Vesely via RT Sent: Thursday, 31 October 2002 11:22 PM Cc: [EMAIL PROTECTED] Subject: MAIL MALFUNCTION: [openssl.org #322] AutoReply: About RSA_check_key Hello, I received the Original Message below and a shorter message CC'ed to [EMAIL PROTECTED], that I paste further below as Original Message 2. The problem is: I NEVER WROTE THE ORIGINAL QUESTION My e-mail address is correct. The last time I wrote to [EMAIL PROTECTED] has been on Fri, 27 Sep 2002 10:14:26 +0200 asking FAQ: How can I check authenticity of a tarball?. It got ticket number [openssl.org #292]. Presumably, the author of the question did not receive a reply. I include full headers in case you feel like debugging that event. Salutations Ale Original Message Return-Path: [EMAIL PROTECTED] Received: from serv01.aet.tu-cottbus.de (serv01.aet.TU-Cottbus.De [141.43.132.161]) by wmail.tana.it with esmtp for [EMAIL PROTECTED]; Wed, 30 Oct 2002 18:35:45 +0100 Received: from localhost (localhost [127.0.0.1])by serv01.aet.tu-cottbus.de (Postfix) with ESMTP id 31BAD306B for [EMAIL PROTECTED]; Wed, 30 Oct 2002 18:35:42 +0100 (MET) Received: by serv01.aet.tu-cottbus.de (Postfix, from userid 2) id BA03B2FF1; Wed, 30 Oct 2002 18:35:36 +0100 (MET) X-RT-Loop-Prevention: openssl.org Message-Id: [EMAIL PROTECTED] Subject: [openssl.org #322] AutoReply: About RSA_check_key In-Reply-To: [EMAIL PROTECTED] Managed-BY: Request Tracker 2.0.13 (http://www.fsck.com/projects/rt/) From: OpenSSL-Bugs [EMAIL PROTECTED] RT-Ticket: openssl.org #322 X-Mailer: Perl5 Mail::Internet v1.33 Reply-To: [EMAIL PROTECTED] Precedence: bulk RT-Originator: To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Date: Wed, 30 Oct 2002 18:35:36 +0100 (MET) X-Virus-Scanned: by AMaViS snapshot-20011031 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: About RSA_check_key, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #322]. Please include the string: [openssl.org #322] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, - Hi: I want to check my own RSA Key Pair. But I just have : public modulus public exponent private exponent How can I calculate its p and q. Because the RSA_check_key function does not work on RSA public keys that have only the modulus and public exponent elements populated. It performs integrity checks on all the RSA key material, so the RSA key structure must contain all the private key data too. Or what method can let me check this key pair? thx... Frank. Original Message 2 Return-Path: [EMAIL PROTECTED] Received: from usw-sf-list2.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by wmail.tana.it with esmtp for [EMAIL PROTECTED]; Fri, 27 Sep 2002 03:00:38 +0200 Received: from usw-sf-list1-b.sourceforge.net ([10.3.1.13] helo=usw-sf-list1.sourceforge.net) by usw-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))id 17ujUC-00081c-00; Thu, 26 Sep 2002 18:00:04 -0700 Date: Thu, 26 Sep 2002 17:59:02 -0700 From: [EMAIL PROTECTED] Subject: courier-users digest, Vol 1 #1822 - 10 msgs Reply-to: [EMAIL PROTECTED] X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: multipart/mixed; boundary==_wmail-19284-1033088439-0001-2 To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Help: mailto:courier-users-request;lists.sourceforge.net?subject=help List-Post: mailto:courier-users;lists.sourceforge.net List-Subscribe: https://lists.sourceforge.net/lists/listinfo/courier-users,mailto:courier [EMAIL PROTECTED]?subject=subscribe List-Id: Courier mail server mailing list courier-users.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users,mailto:courier [EMAIL PROTECTED]?subject=unsubscribe List-Archive: http://sourceforge.net/mailarchives/forum.php?forum=courier-users Message-Id: [EMAIL PROTECTED] Send courier-users mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit
RE: [openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020915)
Richard, I found that the no-hw option didn't work. After discussing it on the list I agreed to contribute a no-engine option. I understand that no-engine doesn't imply the same thing as no-hw, but it still seems like a good option to have. Until the software crypto gets moved into an engine this option allows building of an OpenSSL classic which is useful when footprint is important, such as when ported to PDA's (and maybe even the next generation of mobile phones). The Windows CE port that I've been working on would require a lot more #ifndef ...CE's to be inserted into the code if no-engine isn't supported. Perhaps these are due to no-hw not being implemented fully. With seemingly silly configuration options like no-evp, no-bio, no-stack being supported, I don't think no-engine is such a bad idea. Perhaps in the future it will not be useful, but for now I need it for my port. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte via RT Sent: Friday, 4 October 2002 10:48 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020915) I have to ask: why do you feel the need to remove the ENGINE framework? I can understand that you might not want to have any built-in engines (the option 'no-hw' to Configure should help. If not, I'm happy to apply a corrective patch). I'd like a good explanation before I consider applying this patch, especially since the ENGINE platform may become a very integral part of OpenSSL. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020915)
I think it was about a month ago and would have mentioned no-hw and no-engine in the messages, in fact there probably aren't too many messages with no-engine in them. I don't recall giving any details about what was wrong with no-hw and don't recall the details now. Though I do remember that if I didn't add the no-engine option that I'd have to add a lot more #ifndef ...WINDOWS_CE blocks and that the code would be messier than need be, and messier than I was happy about. Yes, I was using the word supported loosely. I'm not sure what use a no-evp/no-stack/no-bio OpenSSL would be. :-) Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte via RT Sent: Saturday, 5 October 2002 12:12 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020915) [[EMAIL PROTECTED] - Fri Oct 4 15:32:21 2002]: I found that the no-hw option didn't work. Hmm, I probably need to reread that thread. Could you tell me approximately when it was discussed? After discussing it on the list I agreed to contribute a no-engine option. I understand that no-engine doesn't imply the same thing as no-hw, but it still seems like a good option to have. Until the software crypto gets moved into an engine this option allows building of an OpenSSL classic which is useful when footprint is important, such as when ported to PDA's (and maybe even the next generation of mobile phones). OK, I can accept footprint as an argument. With seemingly silly configuration options like no-evp, no-bio, no-stack being supported, I entirely agree that those are silly. I've some plans for the future to do a major review of those options. Besides, supported is a matter of definition. Just the fact that you can actually give them to the Configure script doesn't really mean they're supported. Just try giving 'no-stack' and you'll probably see the build of OpenSSL fall flat and never recover (until you've caught your senses and reconfigured :-)). -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020918)
Is there any interest in this patch? I was under the impression that it would be commited if I did the work. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Steven Reddie via RT Sent: Friday, 20 September 2002 5:25 PM Cc: [EMAIL PROTECTED] Subject: [openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020918) Here is the patch for configuring-out the engine. This one should work; the previous one had a single misplaced #ifndef. I've tested it both with and without the no-engine option for the following platforms: Cygwin VC-WIN32 (dll and static) VC-CE (dll and static) Linux VC-CE is the Windows CE port that I'm working on and the reason that I need the no-engine option, although I imagine that I'll need it in my day job too when we upgrade. Is it possible to get this into a 0.9.7 snapshot soon? I'll need it before I can finalise the port. Regards, Steven __ 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]
RE: rsa encryption and decryption
The size of the data must be less than the size of the modulus of the key. If it's a 1024-bit key (128 bytes) then the data must be at most 128 bytes. In fact, the data when viewed as a long integer must be of a smaller value than the modulus. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mark W. Webb Sent: Thursday, 26 September 2002 10:29 PM To: [EMAIL PROTECTED] Subject: Re: rsa encryption and decryption that is the problem that I have. What is the correct size ? thanks... On Thu, 2002-09-26 at 04:35, Prasanth wrote: Hello Mark, Yes, you an encrypt data using RSA. The only catch is size of the data to be encypted should be less than size of RSA keys. (i.e modulo n). -Prasanth - Original Message - From: Mark W. Webb [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 26, 2002 1:51 AM Subject: rsa encryption and decryption I am working on a program that I use to encrypt and decrypt data. I am was not sure if I can encrypt and decrypt data, or just keys using the functions RSA_private_encrypt and RSA_public_decrypt. thanks... __ 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]
RE: [PATCH] Bug in the OBJ_txt2obj method.
Welcome to the club. I also sent in for a patch for this one, and then Stephen Henson told me that it had been fixed. It in CVS but not in any of the official releases. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Zoltan Glozik Sent: Monday, 23 September 2002 5:47 PM To: [EMAIL PROTECTED] Subject: [PATCH] Bug in the OBJ_txt2obj method. Hi, The OBJ_txt2obj does not call d2i_ASN1_OBJECT with the correct length parameter, so that method always fails in openssl-0.9.6g (This used to work in previous releases because the length checking was commented out in d2i_ASN1_OBJECT). Please see the patch below. Regards, Zoltan Index: crypto/objects/obj_dat.c === RCS file: /var/cvs/openssl/crypto/objects/obj_dat.c,v retrieving revision 1.1.1.3 retrieving revision 1.1.1.3.2.1 diff -u -r1.1.1.3 -r1.1.1.3.2.1 --- crypto/objects/obj_dat.c2002/09/15 09:55:03 1.1.1.3 +++ crypto/objects/obj_dat.c2002/09/22 18:55:39 1.1.1.3.2.1 @@ -417,7 +417,7 @@ a2d_ASN1_OBJECT(p,i,s,-1); p=buf; - op=d2i_ASN1_OBJECT(NULL,p,i); + op=d2i_ASN1_OBJECT(NULL,p,j); OPENSSL_free(buf); return op; } __ 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]
[PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020918)
Here is the patch for configuring-out the engine. This one should work; the previous one had a single misplaced #ifndef. I've tested it both with and without the no-engine option for the following platforms: Cygwin VC-WIN32 (dll and static) VC-CE (dll and static) Linux VC-CE is the Windows CE port that I'm working on and the reason that I need the no-engine option, although I imagine that I'll need it in my day job too when we upgrade. Is it possible to get this into a 0.9.7 snapshot soon? I'll need it before I can finalise the port. Regards, Steven openssl-0.9.7-stable-SNAP-20020918-NO_ENGINE.patch Description: Binary data
Re: The problem of CLOSE_WAIT
This page (http://mictlan.sfsu.edu/~dachen/documents/Overview.htm) has a good description of the states. CLOSE_WAIT means that the peer shutdown the connection and the application still has it open. - Original Message - From: 周光华 [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 17, 2002 8:26 PM Subject: Re: The problem of CLOSE_WAIT I think CLOSE_WAIT state means it is still waitting for the other side's FD_CLOSE notification, (perhaps shutdown function of ssl or socket will send this notification), but the other side had already exit and successfully closed the connection, (perhaps it exited with exceptions or it is killed by others). so the server stay in CLOSE_WAIT state always. But the child process forked by the server has already exit. - Original Message - From: David Schwartz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 17, 2002 5:31 PM Subject: Re: The problem of CLOSE_WAIT On Tue, 17 Sep 2002 17:07:06 +0800, Öܹ⻪ wrote: After few days, on the server side, there are many ssl socket connection did not exit clean, they are mostly in close_wait state and few in established state. Do you understand what the CLOSE_WAIT state means and how sockets get in that state? DS __ 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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020915)
The patch that I submitted is incomplete. I thought that it was working because I forgot that the tests need to be invoked manually. Looks like a little more work to do. Steven - Original Message - From: Steven Reddie via RT [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, September 17, 2002 5:02 PM Subject: [openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020915) __ 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]
RE: 0.9.7: no-hw
That's pretty much what I've done, although overloading no-hw. I'll change this to no-engine and send on some pacthes. I've totally ifdef'd out the engine related code in RSA_new_method, etc., although these functions are of course still passed an ENGINE* which gets ignored. I wasn't sure about ifdef'ing out the ENGINE* from the RSA and other structures. This would make it complete, but the structure would be different between engine and no-engine builds. I doubt this is a problem, but what do you think. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Geoff Thorpe Sent: Wednesday, 28 August 2002 12:57 AM To: [EMAIL PROTECTED] Subject: Re: 0.9.7: no-hw Hi there, On Wed, 28 Aug 2002, Steven Reddie wrote: Specifying no-hw to config/Configure in 0.9.7 defines OPENSSL_NO_HW but builds the engine directory. Parts of those files are ifdef'd out but there is still a fair amount built. Also, #ifndef OPENSSL_NO_HW isn't used much throughout the code, so engine.h is included even with no-hw, and the openssl utility still contains the engine command. This behaviour is different to the other no- options, such as no-idea, where specifying the option results in the relevant directory not being built, inclusion of the relevant header file being disabled (and trying to include it causes an error), calls to the relevant functions being disabled, and the relevant command being removed from the openssl utility. If you'll accept them I can send in some patches to properly disable the engine. In keeping with the other no- options, no-engine may be a better choice due to the name of the relevant directory. Please let me know if you'd like a patch as I could do with this going into a 0.9.7 snapshot soon to make my porting to Windows CE easier and cleaner. OPENSSL_NO_HW is what one would expect from no-hw but it's less than perfectly clear whether that's the same as would be wanted from no-engine. To truly compile without engine code (or headers) would be a bigger task - eg. the ENGINE glue into RSA_new_method(), RSA_free() (and the DSA, DH, RAND, EVP_CIPHER, and EVP_DIGEST equivalents) would need to be pre-compiled out, ie. using a NULL'd replacement of the ENGINE table-lookups that are currently used. Anyhow, I'm personally not sure that the hw concept is all that relevant any more - the possible implementations are not restricted to hardware at all, eg. the dynamic engine, or a software ENGINE implementing new ciphers. Right now I'm working (with Richard) on ways to have all ENGINE implementations built externally as shared-libs that can be transparently and dynamically loaded/initialised when required - in this scheme it will be even less obvious what it means to not have any engines compiled in. I think the more important configuration option is the one you're looking for: no-engine which would simply prune out the entire ENGINE abstraction completely. However, that requires you to figure out how to tie up the loose-ends the lack of ENGINE would leave you with :-) If you want to work on a no-engine patch, please go ahead and let us know how you get on - I would try and keep it as orthogonal to what exists in the source as possible, eg. by using a OPENSSL_NO_ENGINE directive that literally makes the entire ENGINE abstraction go away as with the other no-*** options. Whether the various fine-grained directives for removing particular (or all) ENGINE modules will survive in their current forms remains to be seen, so I'd recommend trying to work independantly of those if possible. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
0.9.7: no-hw
Specifying no-hw to config/Configure in 0.9.7 defines OPENSSL_NO_HW but builds the engine directory. Parts of those files are ifdef'd out but there is still a fair amount built. Also, #ifndef OPENSSL_NO_HW isn't used much throughout the code, so engine.h is included even with no-hw, and the openssl utility still contains the engine command. This behaviour is different to the other no- options, such as no-idea, where specifying the option results in the relevant directory not being built, inclusion of the relevant header file being disabled (and trying to include it causes an error), calls to the relevant functions being disabled, and the relevant command being removed from the openssl utility. If you'll accept them I can send in some patches to properly disable the engine. In keeping with the other no- options, no-engine may be a better choice due to the name of the relevant directory. Please let me know if you'd like a patch as I could do with this going into a 0.9.7 snapshot soon to make my porting to Windows CE easier and cleaner. Steven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #86] Bug in RSA_check_key
This sounds like the same old problem with passing an RSA public key to this function and getting a segv, which seems to bite new users quite often. Can this function be fixed to do a sanity check on the key before proceeding? I assume it's the same with a hardware key. If a user ends up with an RSA key (public, private, or HSM), how are they to know whether they can safey call this function? Do they need intimate enough knowledge of the RSA structure to check if d is NULL, or check some flag to determine if it's a hardware key? Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL on WinCE
I haven't done any work on it for a while. There were a couple of people going to beta test it for me but they ended up needing x86 emulation and I didn't have the time to get that going. So far, I've only got it working on an iPaq (StrongARM). If you want to try that out, please contact me privately. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Devaraj Das Sent: Friday, 11 January 2002 7:47 PM To: [EMAIL PROTECTED] Subject: OpenSSL on WinCE Hi folks, I am new to this group. I have a question regarding the OpenSSL port to WinCE. I came to know from the mail archive that Steven Reddie was looking at it. Any more updates on the same? If the thing is done, can I have one version? Thanks and regards, Das. __ 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]
RE: [PATCH] PKCS#11 code update
Richard, that was Zoran from Eracom and myself (as a Computer Associates employee). We never got together, but Zoran did submit his code. I put my submission on the back-burner long enough that I think it's irrelevant now. I still haven't looked at Zoran's submission but it sounds like it works in a similar way to my own code. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Thursday, 13 December 2001 8:10 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] PKCS#11 code update Now, for another issue: I haven't quite followed the sequence of events so I'm not completely up to date here. There was a time when there were two persons approaching us with a PKCS11 engine each, and I suggested they join forces. Is this a result of such a join? I'm sorry that my memory doesn't serve me better on this, and I have had a hard time finding the info I need to know how things have developped. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Java SSL
Java has SSL support in the JSSE for v1.3. For v1.4 JSSE has been rolled into the JDK. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sargrad, Dave Sent: Tuesday, 23 October 2001 11:46 PM To: '[EMAIL PROTECTED]' Subject: Java SSL Are there reliable SSL libraries written in Java? Thanks for any info, Dave Sargrad __ 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]
RE: reading in PKCS8 DSA priv key to java
Something like this should do the trick: byte[] encodedKey; // read from file PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(encodedKey); KeyFactory keyFactory = KeyFactory.getInstance(DSA); DSAPrivateKey privKey = (DSAPrivateKey)keyFactory.generatePrivate(keySpec); Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mark W. Webb Sent: Thursday, 30 August 2001 5:53 AM To: [EMAIL PROTECTED] Subject: reading in PKCS8 DSA priv key to java I know this may be off topic, but I wrote some code to create a DSA key pair, and matching certificate. The private key is stored in a file with PKCS8 encoding. I want to be able to read the private key file into my java program. The certificate is used by a C based program. Can someone give me some help as to how and read the private key into my java program. Thank you. -- Mark Webb Software Engineer Dolphin Technology 1300B Floyd Ave Rome, NY 13440 Phone: (315) 334-4892 x222 Fax: (315) 339-4846 Email: [EMAIL PROTECTED] __ 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]
RE: Memory leaks
Yes, you've misinterpreted the output. I added up all of the number= fields and got 899. I'm guessing that you added up the first number on each line. That number represents the order of the allocations. Regards, Steven -Original Message- From: Gleison Santos [mailto:[EMAIL PROTECTED]] Sent: Friday, 27 July 2001 2:04 PM To: [EMAIL PROTECTED] Subject: Memory leaks Hi all. I followed instructions in http://marc.theaimsgroup.com/?l=openssl-usersm=99494629705968w=2 to find memory leaks in my application. The output generated by CRYPTO_mem_leaks_fp (as show below) tells me that 899 bytes were leaked but the sum of all reported bytes is 1608. Is that a bug or I'm reading the output incorrectely? CRYPTO_mem_leaks_fp output: 32 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12D08 805 file=err\err.c, line=769, thread=1, number=65, address=00D136EA 16 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12920 5 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D126A2 60 file=lhash\lhash.c, line=119, thread=1, number=86, address=00D135BE 13 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D12872 61 file=lhash\lhash.c, line=121, thread=1, number=64, address=00D13642 21 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D12A42 29 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D12C12 2 file=objects\o_names.c, line=164, thread=1, number=12, address=00D125F4 10 file=objects\o_names.c, line=164, thread=1, number=12, address=00D127C4 18 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12994 26 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12B64 7 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D12716 15 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D128E6 0 file=objects\o_names.c, line=164, thread=1, number=12, address=00D124E6 23 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D12AB6 4 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12668 62 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D136B0 12 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12838 20 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12A08 1 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D125BA 28 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12BD8 9 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D1278A 31 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D12578 17 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D1295A 25 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D12B2A 6 file=objects\o_names.c, line=164, thread=1, number=12, address=00D126DC 14 file=objects\o_names.c, line=164, thread=1, number=12, address=00D128AC 33 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D12D42 22 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12A7C 30 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12C4C 3 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D1262E 59 file=err\err.c, line=699, thread=1, number=264, address=00D13488 11 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D127FE 19 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D129CE 27 file=lhash\lhash.c, line=193, thread=1, number=12, address=00D12B9E 8 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12750 24 file=objects\o_names.c, line=164, thread=1, number=12, address=00D12AF0 899 bytes leaked in 39 chunks []`s Gleison [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
