Re: Still a few issues. Release delayed...
On Tue, 28 Jun 2005, Richard Levitte - VMS Whacker wrote: Hi, The release is delayed again. There are a couple of issues that I think need to be checked. I hope we'll be through with this in a week. Things are looking much better here. The Makefile changes (make depend) are working on my system V makes now. Builds and passes tests on: UnixWare 2.03 w/ native compiler UnixWare 7.1.1 w/ native compiler UnixWare 7.1.4 w/ native compiler OpenServer 5.0.4 w/ native compiler OpenServer 5.0.7 w/ native compiler [1] OpenServer 5.0.7 w/ gcc [1] OpenServer 6.0.0 w/ native compiler OpenLinux 3.1.1 Xandros 2.5 Business Solaris 8 (sparc) w/ gcc [1] Needs a small patch to crypto/ui/ui_openssl.c to work around broken? system headers. -#define _POSIX_C_SOURCE 1 +#define _POSIX_C_SOURCE 199506 (This is OpenServer 5.0.7 specific. That patch will break other platforms.) Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Missing documentation
Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Wed, 29 Jun 2005 06:42:59 +0200, Karsten Ohme [EMAIL PROTECTED] said: widerstand will there be some day, when the the OpenSSL source code widerstand is documented in a some way? In all source files, widerstand explanations to the functions, the parameters and comments widerstand in the code what is done are missing. We're well aware the documentation is lacking. We are adding some all the time. I wish we had the possibility to do *only* that for a while, but that's not what reality looks like. In the Open Source spirit, there's nothing stopping you from helping out. I think before the call for source code documentation is done, the team should decide which format to use. I would suggest doxygen... Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #1105] DTLS HelloVerifyRequest PATCH
So the bug report can be removed, right? Yes, the report can be removed. It is not a bug. (and *please* keep [EMAIL PROTECTED] among the recipients. It's quite hard to follow history in the database when people keep skipping that address) Apologies. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1105] DTLS HelloVerifyRequest PATCH
[EMAIL PROTECTED] - Wed Jun 29 17:43:06 2005]: So the bug report can be removed, right? Yes, the report can be removed. It is not a bug. Thanks. Ticket resolved. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: compiler error
On Mon, Jun 27, 2005, Jrgen Hovland wrote: Hi Does anyone know what to do with this? Im trying to compile a masm version. Thank you. cl /Fotmp32dll\ec_asn1.obj -Iinc32 -Itmp32dll /MD /W3 /WX /G5 /Ox /O2 / Ob2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIA N -DDSO_WIN32 -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK - I. /Fdout32dll -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_KRB5 -D_WINDLL - DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\ec\ec_asn1.c ec_asn1.c crypto\ec\ec_asn1.c(262) : error C2370: 'ECPKPARAMETERS_it' : redefinition; diff erent storage class crypto\ec\ec_asn1.c(259) : see declaration of 'ECPKPARAMETERS_it' crypto\ec\ec_asn1.c(273) : error C2370: 'EC_PRIVATEKEY_it' : redefinition; diffe rent storage class crypto\ec\ec_asn1.c(270) : see declaration of 'EC_PRIVATEKEY_it' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. H:\sdk\openssl-0.9.8-beta6 ** H:\sdk\openssl-0.9.7gnmake -f ms\ntdll.mak Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Building OpenSSL cl /Fotmp32dll\n_pkey.obj -Iinc32 -Itmp32dll /MD /W3 /WX /G5 /Ox /O2 /O b2 /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 -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\n_pkey.c n_pkey.c crypto\asn1\n_pkey.c(96) : error C2370: 'NETSCAPE_ENCRYPTED_PKEY_it' : redefinit ion; different storage class crypto\asn1\n_pkey.c(93) : see declaration of 'NETSCAPE_ENCRYPTED_PKEY_i t' crypto\asn1\n_pkey.c(106) : error C2370: 'NETSCAPE_PKEY_it' : redefinition; diff erent storage class crypto\asn1\n_pkey.c(103) : see declaration of 'NETSCAPE_PKEY_it' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. H:\sdk\openssl-0.9.7g The usual cause of this is forgetting to do: perl Configure VC-WIN32 Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Considering SSL and Cryto libraries for LSB
We recently started looking at some of Desktop specific libraries for including them as part of next LSB (Linux Standard Base www.linuxbase.org) release. This is part of the effort in the newly formed Desktop working group in LSB to focus on the Desktop Linux applications. As a part of this effort we have started looking at the OpenSSL libraries and found the thread http://www.mail-archive.com/openssl-dev@openssl.org/msg19158.html discussing ABI compatibility across different releases. I am specifically referring to comments from Richard below. I will like to find out what the Openssl community think about making the libraries part of next LSB release. Of course, the ABIs will need to become stable before that. What are the plans to achieve this ABI stability (including releasing 1.0 version of the package)? Thanks, -Rajesh The biggest change that's needed in OpenSSL is to hide all the structures and all constants and have them available through functions (creator, destructors and information functions). So speaking of incompatibilites, we've really kept it low compared to what needs to be done and what could be done. Our version numbering is admitedly weird. Basically, we've treated '0.9.' as a prefix to signal that this isn't a 1.0 yet, and drastic changes can be expected, and effectively trated the next digit as a classic major version. This is reflected in the soname we give the shared libraries. We probably should do some drastic changes in our version numbering (which is quite a lesson to me personally. I've been reluctant to make a move to 1.0 because OpenSSL hasn't felt ready for that). --- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Considering SSL and Cryto libraries for LSB
As part of LSB standardization process, we look at the interfaces and corresponding data types and make it part of the specification. If the data types are expected to change and the interfaces do not hide them, then that part of the library may not be a candidate for LSB. Given this, I am just wondering (as I do not know enough details yet) if it makes sense to partially include the crypto library in LSB. I assume at least parts of this library may be stable and not expected to change much. E.g. some of the crypto algorithms. Is that a possibility? From our current analysis of some of the existing OSS applications, function sets like EVP*, RSA*, DSA* etc are quite commonly used. It may be a good idea to identfy some of the stable interfaces from crypto library for inclusion in LSB. Any thoughts/comments? Thanks, -Rajesh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Wednesday, June 29, 2005 1:01 PM To: openssl-dev@openssl.org Subject: Re: Considering SSL and Cryto libraries for LSB On Wed, Jun 29, 2005, Banginwar, Rajesh wrote: We recently started looking at some of Desktop specific libraries for including them as part of next LSB (Linux Standard Base www.linuxbase.org) release. This is part of the effort in the newly formed Desktop working group in LSB to focus on the Desktop Linux applications. As a part of this effort we have started looking at the OpenSSL libraries and found the thread http://www.mail-archive.com/openssl-dev@openssl.org/msg19158.html discussing ABI compatibility across different releases. I am specifically referring to comments from Richard below. I will like to find out what the Openssl community think about making the libraries part of next LSB release. Of course, the ABIs will need to become stable before that. What are the plans to achieve this ABI stability (including releasing 1.0 version of the package)? This ABI stability is not something which can be done quickly and not without some rather large levels of incompatibility with existing applications itself. One of many reason for this is that some APIs, which have been around since the SSLeay days, make use of structures like this: FOO_CTX foo; FOO_CTX_something(foo); Examples of this are the EVP digest and cipher APIs. This is a problem if the size of the structure FOO_CTX increases. There are several reasons why the size of FOO_CTX might change including additional features being added. There are several features which are needed in the digest and cipher APIs which would have this effect. There is a solution which already exists which is instead to do this: FOO_CTX *foo; foo = FOO_CTX_new(); FOO_CTX_something(foo); However, very few applications (at present) use this technique. This means that changing this in the short term is likely to cause widespread application breakage which wouldn't be too popular :-( Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ 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: Considering SSL and Cryto libraries for LSB
On Wed, Jun 29, 2005, Banginwar, Rajesh wrote: As part of LSB standardization process, we look at the interfaces and corresponding data types and make it part of the specification. If the data types are expected to change and the interfaces do not hide them, then that part of the library may not be a candidate for LSB. Given this, I am just wondering (as I do not know enough details yet) if it makes sense to partially include the crypto library in LSB. I assume at least parts of this library may be stable and not expected to change much. E.g. some of the crypto algorithms. Is that a possibility? From our current analysis of some of the existing OSS applications, function sets like EVP*, RSA*, DSA* etc are quite commonly used. It may be a good idea to identfy some of the stable interfaces from crypto library for inclusion in LSB. Any thoughts/comments? Well some of the low level crypto APIs haven't changed for some time but their use is discouraged because it ties an application down to a specific algorithm and a specific implementation. EVP is the preferred interface for accessing crypto algorithms and digests. Both these however commonly use the construct I mentioned which causes binary compatibility issues. That doesn't mean that EVP can't be used in a way that pretty much guarantees binary compatibility: its just that existing applications don't often use it in that way. So its certainly feasible to say that if you use EVP like *this* it wont cause problems. Similar comments apply to RSA and DSA: there are ways to use the APIs that avoid structure access and possible future incompatibilities. There are however some areas where the API is lacking: for example there isn't currently an easy way to populate an RSA structure with its key components. That is there isn't a function: RSA_set_PublicKey(rsa, n, e); but that's not hard to fix. That all applies to applications that use existing algorithms that are part of OpenSSL (or which have been loaded in via an ENGINE). Applications which extend OpenSSL by defining new cryptographic algorithms currently need to access internal structures directly. APIs can of course be developed that remedy that situation, but again existing applications wont use them. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1143] pkg-config files for each lib
with the single openssl.pc pkg-config file we can only link witl -lcrypto -lssl -ldl. it would be better to provide a libcrypto.pc and a libssl.pc so we can create apps and libs, that link with libcrypto only. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Considering SSL and Cryto libraries for LSB
IBM has already done this in creating it's FIPS certified crypto. code which is layered on top of OpenSSL. In our case we can guarantee that IBM code only uses our restricted subset of the OpenSSL API. Unfortunately you'll need to support the older API's to support legacy applications and in won't be possible to ensure that everyone writing new code restricts themselves to the sanitized API's. If you can live with that then the only problem will be getting the necessary changes made to provide a clean API. I'm not claiming that'll be trivial, but we already know it is possible. Peter Dr. Stephen Henson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 30/06/2005 08:14 AM Please respond to openssl-dev To openssl-dev@openssl.org cc Subject Re: Considering SSL and Cryto libraries for LSB On Wed, Jun 29, 2005, Banginwar, Rajesh wrote: As part of LSB standardization process, we look at the interfaces and corresponding data types and make it part of the specification. If the data types are expected to change and the interfaces do not hide them, then that part of the library may not be a candidate for LSB. Given this, I am just wondering (as I do not know enough details yet) if it makes sense to partially include the crypto library in LSB. I assume at least parts of this library may be stable and not expected to change much. E.g. some of the crypto algorithms. Is that a possibility? From our current analysis of some of the existing OSS applications, function sets like EVP*, RSA*, DSA* etc are quite commonly used. It may be a good idea to identfy some of the stable interfaces from crypto library for inclusion in LSB. Any thoughts/comments? Well some of the low level crypto APIs haven't changed for some time but their use is discouraged because it ties an application down to a specific algorithm and a specific implementation. EVP is the preferred interface for accessing crypto algorithms and digests. Both these however commonly use the construct I mentioned which causes binary compatibility issues. That doesn't mean that EVP can't be used in a way that pretty much guarantees binary compatibility: its just that existing applications don't often use it in that way. So its certainly feasible to say that if you use EVP like *this* it wont cause problems. Similar comments apply to RSA and DSA: there are ways to use the APIs that avoid structure access and possible future incompatibilities. There are however some areas where the API is lacking: for example there isn't currently an easy way to populate an RSA structure with its key components. That is there isn't a function: RSA_set_PublicKey(rsa, n, e); but that's not hard to fix. That all applies to applications that use existing algorithms that are part of OpenSSL (or which have been loaded in via an ENGINE). Applications which extend OpenSSL by defining new cryptographic algorithms currently need to access internal structures directly. APIs can of course be developed that remedy that situation, but again existing applications wont use them. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Considering SSL and Cryto libraries for LSB
Dr. Stephen Henson wrote: This means that changing this in the short term is likely to cause widespread application breakage which wouldn't be too popular :-( Speaking as an application developer, I would willingly go through a one-time source code upgrade to achieve binary compatiblity. That is more appealing to me than having to repeatedly deal with binary compatiblity issues, because it's less work in the long run. -- Dan Nuffer Vintela, Inc. http://vintela.com/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Considering SSL and Cryto libraries for LSB
On Thu, Jun 30, 2005, Peter Waltenberg wrote: IBM has already done this in creating it's FIPS certified crypto. code which is layered on top of OpenSSL. In our case we can guarantee that IBM code only uses our restricted subset of the OpenSSL API. Unfortunately you'll need to support the older API's to support legacy applications and in won't be possible to ensure that everyone writing new code restricts themselves to the sanitized API's. Well we could provide compilation options which would result in some applications using non-portable constructs producing warnings or errors. For example the problematical: EVP_CIPHER_CTX ctx; will produce a compilation error if the definition of EVP_CIPHER_CTX is not public. Wheareas: EVP_CIPHER_CTX *ctx; will be OK. Legacy applications are a problem because some behaviour doesn't even have an appropriate API at present. For example so set the public key components you currently have to do: rsa-n = n; rsa-e = e; which is a no-no. If you can live with that then the only problem will be getting the necessary changes made to provide a clean API. I'm not claiming that'll be trivial, but we already know it is possible. Its certainly possible. There is an added complication in that some thought has to be given to future directions of development. For example the current RSA API lacks any easy way to pass additional parameters to some padding types. OAEP and especially PSS really need a way to do that. That could be neatly solved (and some other parts made more efficient) if RSA had a per-thread context structure analagous to EVP_CIPHER_CTX but alas it doesn't. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Considering SSL and Cryto libraries for LSB
On Wed, Jun 29, 2005, Dan Nuffer wrote: Dr. Stephen Henson wrote: This means that changing this in the short term is likely to cause widespread application breakage which wouldn't be too popular :-( Speaking as an application developer, I would willingly go through a one-time source code upgrade to achieve binary compatiblity. That is more appealing to me than having to repeatedly deal with binary compatiblity issues, because it's less work in the long run. Also speaking as an application developer so would I. However there are a hell of a lot of applications out there that depend on the existing APIs not changing (too) much. Can you give details of some of the binary compatibility issues you've come across? Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Considering SSL and Cryto libraries for LSB
On June 29, 2005 05:50 pm, Banginwar, Rajesh wrote: As part of LSB standardization process, we look at the interfaces and corresponding data types and make it part of the specification. If the data types are expected to change and the interfaces do not hide them, then that part of the library may not be a candidate for LSB. Well there are two things that spring to mind. 1. Most use of openssl, at least as might be considered useful from an LSB-perspective, is of the SSL layer itself (libssl). This requires the direct use of certain APIs in the underlying libcrypto layer too, but AFAICT these would be easier to standardise on than the full set of APIs and are probably more ABI-friendly (ie. loading and initialising RSA/X509 objects, etc). NB, that's a cursory thought, I've not attempted to dig terribly far on this. 2. This is a refined variation on the issues distributions already face when distributing openssl in shared-library form and maintaining classes of applications that have dependencies on these libs. The consensus seems to be to use versioning to manage this, where a system can have multiple openssl libraries installed of differing version levels. Eg. 0.9.6, 0.9.7, etc. Bugfix releases to individual versions are expected to maintain binary compatibility, or distributors at least Q/A this at their end and patch around any issues as/where necessary. You'd have to check with the distributions themselves to know more though, that's out of our hands. Mark, any comments from a Redhat perspective? The reasons Steve outlined cover why we can't provide assurances about full ABI compatibility (nor even API compatibility) in a long-term sense. To do so would take a lot of undesirable but legacy aspects of the toolkit and fix them in place. However, the unwritten rule is to ensure that each incremental(/bugfix) release of a given stable branch does preserve binary compatibility, and incorporation into LSB definitions would obviously go a long way turning this into a firmer commitment. Note also that major releases, which we freely admit can break ABI and/or API compatibility where required, are made far less frequently - as a perusal of release history will aptly demonstrate. I should also mention that we're not making vast overhauls of APIs on a regular basis, nor for the mere fun of it, so if adaptations are required long-term to allow future LSB revisions to incorporate newer release levels, this would hardly involve major surgery. Perhaps that's an avenue until such time as openssl does get to some kind of 1.0 plateau. Hope springs eternal. [ Or people wanting LSB compliancy can always statically link any version of openssl they like, but I guess that's not what you're after :-) ] Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.openssl.org/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Considering SSL and Cryto libraries for LSB
-Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Thorpe Sent: Wednesday, June 29, 2005 5:45 PM To: openssl-dev@openssl.org Cc: Banginwar, Rajesh Subject: Re: Considering SSL and Cryto libraries for LSB On June 29, 2005 05:50 pm, Banginwar, Rajesh wrote: As part of LSB standardization process, we look at the interfaces and corresponding data types and make it part of the specification. If the data types are expected to change and the interfaces do not hide them, then that part of the library may not be a candidate for LSB. Well there are two things that spring to mind. 1. Most use of openssl, at least as might be considered useful from an LSB-perspective, is of the SSL layer itself (libssl). This requires the direct use of certain APIs in the underlying libcrypto layer too, but AFAICT these would be easier to standardise on than the full set of APIs and are probably more ABI-friendly (ie. loading and initialising RSA/X509 objects, etc). NB, that's a cursory thought, I've not attempted to dig terribly far on this. So far from the preliminary analysis that we have done (by looking at some of the OSS applications) we see both libssl and libcrypto being used. E.g. from libcrypto I find functions in EVP, RSA, MD5 and DSA sets more commonly used than others. Unfortunately this is not an exhaustive study. Do you or anyone on this project have data suggesting which APIs are candidates for LSB inclusion both from demand and stability point of view? 2. This is a refined variation on the issues distributions already face when distributing openssl in shared-library form and maintaining classes of applications that have dependencies on these libs. The consensus seems to be to use versioning to manage this, where a system can have multiple openssl libraries installed of differing version levels. Eg. 0.9.6, 0.9.7, etc. Bugfix releases to individual versions are expected to maintain binary compatibility, or distributors at least Q/A this at their end and patch around any issues as/where necessary. You'd have to check with the distributions themselves to know more though, that's out of our hands. Mark, any comments from a Redhat perspective? The reasons Steve outlined cover why we can't provide assurances about full ABI compatibility (nor even API compatibility) in a long-term sense. To do so would take a lot of undesirable but legacy aspects of the toolkit and fix them in place. However, the unwritten rule is to ensure that each incremental(/bugfix) release of a given stable branch does preserve binary compatibility, and incorporation into LSB definitions would obviously go a long way turning this into a firmer commitment. Note also that major releases, which we freely admit can break ABI and/or API compatibility where required, are made far less frequently - as a perusal of release history will aptly demonstrate. I should also mention that we're not making vast overhauls of APIs on a regular basis, nor for the mere fun of it, so if adaptations are required long-term to allow future LSB revisions to incorporate newer release levels, this would hardly involve major surgery. Perhaps that's an avenue until such time as openssl does get to some kind of 1.0 plateau. Hope springs eternal. I just checked the release history for openssl and it is encouraging to see the major releases are years apart. I see that with some efforts it may be possible to hide some of the data structure dependencies (as Steve pointed out in other emails on this thread) and get some sets of APIs to a stable level and push for LSB inclusion. There was at least one comment from application developer encouraging this even though it will require major changes. [ Or people wanting LSB compliancy can always statically link any version of openssl they like, but I guess that's not what you're after :-) ] Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.openssl.org/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Considering SSL and Cryto libraries for LSB
On June 29, 2005 08:44 pm, Banginwar, Rajesh wrote: So far from the preliminary analysis that we have done (by looking at some of the OSS applications) we see both libssl and libcrypto being used. E.g. from libcrypto I find functions in EVP, RSA, MD5 and DSA sets more commonly used than others. Unfortunately this is not an exhaustive study. Do you or anyone on this project have data suggesting which APIs are candidates for LSB inclusion both from demand and stability point of view? I'm not sure how you would harvest this kind of information. From a build perspective, it may be quite difficult to disentangle one API from the next. I guess someone truly masoc^H^H^H^H^Hdedicated could create an alternative openssl-lsb.h header to build against - one that declared only the subset of functionality that mattered from an LSB perspective and then see how external apps fare building against that. However there's a lot of macro-abuse in some areas of the code, and if this shimming got tangled up in trying to reproduce ASN1 definitions then I don't even want to contemplate where it might lead... Something to think about I guess. But it certainly seems hairy to attempt to standardise too much invariance across major releases that we expect will ... um ... vary. I just checked the release history for openssl and it is encouraging to see the major releases are years apart. I see that with some efforts it may be possible to hide some of the data structure dependencies (as Steve pointed out in other emails on this thread) and get some sets of APIs to a stable level and push for LSB inclusion. There was at least one comment from application developer encouraging this even though it will require major changes. It sounds like a fairly labourious process though (ie. I doubt we'll be dispersing the volunteers with tear-gas or anything). Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.openssl.org/ __ 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: Considering SSL and Cryto libraries for LSB
In message [EMAIL PROTECTED] on Wed, 29 Jun 2005 17:44:38 -0700, Banginwar, Rajesh [EMAIL PROTECTED] said: rajesh.banginwar Do you or anyone on this project have data rajesh.banginwar suggesting which APIs are candidates for LSB rajesh.banginwar inclusion both from demand and stability point of rajesh.banginwar view? Quick answer, solely based on the header files and looking for the parts that do not expose there structures: EC, ECDH, ECDSA (although it exposes the signature structure, but I think that one's standardardised), pqueue, UI. ENGINE should also be here even though there are some exposed structures. Those structures are fairly well defined and are not subject to change soon, as far as I can predict. Quite honestly, even though I'm quite an enthusiastic OpenSSL developer for years and have been for years (since it started, really), I can't really recommend OpenSSL as an LSB candidate from that point of view, as it stands today. Every major upgrade (which we define as a change of x in 0.9.x) has had some kind of incompatibility with previous versions. 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]
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: make test still failing
Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Tue, 28 Jun 2005 09:29:54 -0700, Rodney Thayer [EMAIL PROTECTED] said: rodney 'make test' never works. in the EC test, it runs a long time rodney (tracing the output gives multiple gigabytes of text, it seems rodney to take on the order of an hour or more). the failure is a rodney memory fault of some kind. After I confirm this isn't a known rodney problem I'll run it again and post the last bit of the rodney output. We will also need to know exactly how you configured it, and what the configuration output was. with openssl-0.9.7g, on fedora core 3 on an intel box: ./config ./config no-shared ./config no-shared no-idea ./config no-shared no-idea no-rc5 ./config no-shared no-idea no-rc5 -dwork with openssl-0.9.8-beta6, on fedora core 3 on an intel box, for example: ./config no-shared no-idea no-rc5 -d FAILS ./config no-shared no-idea no-rc5 works ./config no-shared no-ideaworks ./config no-sharedworks ./config works attached is the config output from 0.9.8 beta 6 in the bad case (with the -d) ./config no-shared no-idea no-rc5 -d Operating system: i686-whatever-linux2 Configuring for debug-linux-elf Configuring for debug-linux-elf no-gmp [default] OPENSSL_NO_GMP (skip dir) no-idea [option] OPENSSL_NO_IDEA (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-mdc2 [default] OPENSSL_NO_MDC2 (skip dir) no-rc5 [option] OPENSSL_NO_RC5 (skip dir) no-shared [option] no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC=gcc CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=pentium -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM EX_LIBS =-lefence -ldl CPUID_OBJ =x86cpuid-elf.o BN_ASM=bn86-elf.o co86-elf.o DES_ENC =dx86-elf.o yx86-elf.o AES_ASM_OBJ =ax86-elf.o BF_ENC=bx86-elf.o CAST_ENC =cx86-elf.o RC4_ENC =rx86-elf.o RC5_ENC =r586-elf.o MD5_OBJ_ASM =mx86-elf.o SHA1_OBJ_ASM =sx86-elf.o s512sse2-elf.o RMD160_OBJ_ASM=rm86-elf.o PROCESSOR = RANLIB=/usr/bin/ranlib ARFLAGS = PERL =/usr/bin/perl THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode RC4_CHUNK is undefined e_os2.h = include/openssl/e_os2.h making links in crypto... make[1]: Entering directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto' crypto.h = ../include/openssl/crypto.h tmdiff.h = ../include/openssl/tmdiff.h opensslv.h = ../include/openssl/opensslv.h opensslconf.h = ../include/openssl/opensslconf.h ebcdic.h = ../include/openssl/ebcdic.h symhacks.h = ../include/openssl/symhacks.h ossl_typ.h = ../include/openssl/ossl_typ.h making links in crypto/objects... make[2]: Entering directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/objects' objects.h = ../../include/openssl/objects.h obj_mac.h = ../../include/openssl/obj_mac.h make[2]: Leaving directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/objects' making links in crypto/md2... make[2]: Entering directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/md2' md2.h = ../../include/openssl/md2.h md2test.c = ../../test/md2test.c make[2]: Leaving directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/md2' making links in crypto/md4... make[2]: Entering directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/md4' md4.h = ../../include/openssl/md4.h md4test.c = ../../test/md4test.c md4.c = ../../apps/md4.c make[2]: Leaving directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/md4' making links in crypto/md5... make[2]: Entering directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/md5' md5.h = ../../include/openssl/md5.h md5test.c = ../../test/md5test.c make[2]: Leaving directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/md5' making links in crypto/sha... make[2]: Entering directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/sha' sha.h = ../../include/openssl/sha.h shatest.c = ../../test/shatest.c sha1test.c = ../../test/sha1test.c sha256t.c = ../../test/sha256t.c sha512t.c = ../../test/sha512t.c make[2]: Leaving directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/sha' making links in crypto/hmac... make[2]: Entering directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/hmac' hmac.h = ../../include/openssl/hmac.h hmactest.c = ../../test/hmactest.c make[2]: Leaving directory `/cj/hotcell/research/ssl/fail/openssl-0.9.8-beta6/crypto/hmac' making links in crypto/ripemd... make[2]: Entering directory
Re: Considering SSL and Cryto libraries for LSB
Richard Levitte - VMS Whacker wrote: Quite honestly, even though I'm quite an enthusiastic OpenSSL developer for years and have been for years (since it started, really), I can't really recommend OpenSSL as an LSB candidate from that point of view, as it stands today. Every major upgrade (which we define as a change of x in 0.9.x) has had some kind of incompatibility with previous versions. http://www.gnu.org/software/gnutls/ exposes two APIs: the OpenSSL api (I gather?), and its own. Has anyone looked at gnutls's api to see if it exposes fewer structures? If so, perhaps that might provide a way forward: apps that need a stable interface can use the gnutls api (which openssl could provide as a wrapper); everyone else could use the openssl api (which gnutls seems to provide as a wrapper, unless I misread the docs). - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1114] Bug: RC4 on IA64 and OpenSSH
Andy Polyakov via RT wrote: Summary can be found at http://cvs.openssl.org/chngview?cn=14145. Point is that I assumed that RC4_KEY structure initialized by RC4_set_key is passed down to RC4 verbatim in its original memory location, while OpenSSH takes freedom to swap the structures initialized in different locations. One can argue that the latter is inappropriate design choice, but it works on too many other platforms to argue. And so IA64 was reduced to common denominator. Case dismissed. A. We need some way to export a cipher's state (key + iv + anything else) to implement privilege separation, where we need to pass encryption state around. If OpenSSL can implement some way to import and export state, then the direct copying can go away in OpenSSH (at least for newer libcryptos). -d __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Considering SSL and Cryto libraries for LSB
What is the benefit of adding parts of OpenSSL to the LSB now? -- 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: Considering SSL and Cryto libraries for LSB
In message [EMAIL PROTECTED] on Wed, 29 Jun 2005 22:05:07 -0700, Dan Kegel [EMAIL PROTECTED] said: dank http://www.gnu.org/software/gnutls/ dank exposes two APIs: the OpenSSL api (I gather?), and its own. About the OpenSSL API, this page answers part of the question. http://www.gnu.org/software/gnutls/reference/gnutls-openssl.html The rest of the answer is in gnutls/openssl.h. They expose some structures to remain compatible with the way OpenSSL currently works, so it's basically a compatibility that's as stripped down as possible. For the rest of GnuTLS, they seem to expose very little, from what I can gather by looking at the public header files. dank If so, perhaps that might provide a way forward: apps that need dank a stable interface can use the gnutls api (which openssl could dank provide as a wrapper); everyone else could use the openssl api dank (which gnutls seems to provide as a wrapper, unless I misread dank the docs). It's a path. Just a small warning about license politics: According to http://www.gnu.org/software/gnutls/gnutls.html, the GnuTLS core library is licensed under the LGPL. Looking at the header files, it looks like there's a mix of GPL and LGPL, and among others, their openssl.h is under the GPL (something I find very interesting). This may have changed with later versions... 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]
