[openssl.org #2262] Inconsistent error handling in the load_key function (apps.c)
We've accidently found out that openssl command line utility doesn't
report correcrly why it is unable to load prviate key.
Investigation shows that error reporting in the load_key function
(in apps/apps.c) which is used by most commands of openssl utility,
is incomplete and inconsistent.
1. This function recieves BIO* argument err to report errors to.
But in some cases it uses this BIO, and in some cases global variable
bio_err.
2. It doesn't report any errors encontered in the
ENGINE_load_private_key function at all.
3. It doesn't call ERR_print_errors(err) after printing message Unable
to load private key, while for instance, function load_certificate in
the same file does so.
Attached patch (against 1.0.0-stable branch) fixes these problems.
? load_key_error.patch
Index: apps.c
===
RCS file: /cvs-openssl/openssl/apps/apps.c,v
retrieving revision 1.133.2.8
diff -u -r1.133.2.8 apps.c
--- apps.c 31 Oct 2009 13:34:19 - 1.133.2.8
+++ apps.c 11 May 2010 12:03:15 -
@@ -875,10 +875,17 @@
if (format == FORMAT_ENGINE)
{
if (!e)
- BIO_printf(bio_err,no engine specified\n);
+ BIO_printf(err,no engine specified\n);
else
+ {
pkey = ENGINE_load_private_key(e, file,
ui_method, cb_data);
+ if (!pkey)
+{
+BIO_printf(err,cannot load %s from engine\n,key_descrip);
+ERR_print_errors(err);
+}
+ }
goto end;
}
#endif
@@ -937,8 +944,11 @@
}
end:
if (key != NULL) BIO_free(key);
- if (pkey == NULL)
+ if (pkey == NULL)
+ {
BIO_printf(err,unable to load %s\n, key_descrip);
+ ERR_print_errors(err);
+ }
return(pkey);
}
Re: [openssl.org #2077] openssl 1.0.0 stable does not print all digests with help
On 2009.10.25 at 00:05:36 +0200, Guenter via RT wrote: Hi, I checked with a recent snapshot 1.0.0-stable, and found that although the openssl commandline supports now sha224, sha256, sha384, and sha512 message digests, it still only prints these: Message Digest commands (see the `dgst' command for more details) md4 md5 mdc2 rmd160 sha sha1 Really, there is a problem with digest commands. For instance I never was able to make md_gost94 digest work as digest command, not as option to dgst command. Problem is that command name parsing occurs before initialization of OpenSSL is completed and configuration file read. So, engine-provided algorithms at least, cannot be used as digest command. dgst command prints list of available digests after all inititalization, so it sees them all. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2071] Few more manual page
On 2009.10.15 at 22:02:54 +0200, Roumen Petrov via RT wrote: May be is good to document that numbers in hash dir starts from zero. May be. But just now I think it is much more important to get ANY documentation for these functions into CVS. At least it is quite easy to find out what number it starts from by simple experiment. You don't need to write C program or read code to do so - just run c_rehash and then look into hashed directory using ls. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Few more manual page (was: What does cache field in X509_STORE struct do?)
On 2009.10.13 at 15:25:19 +0200, Dr. Stephen Henson wrote: X509_STORE_CTX, X509_VERIFY_PARAM and X509_LOOKUP_hash_dir/X509_LOOKUP_file documents would follow. OK thanks. I'll have a look at that. I'll add some documentation for X509_VERIFY_PARAM myself when I have time (I'm more familiar with it having written the stuff). Attached manual pages for X509_LOOKUP_ methods, X509_check_issued and X509_check_ca functions. =pod =head1 NAME X509_LOOKUP_hash_dir, X509_LOOKUP_file, X509_load_cert_file, X509_load_crl_file, X509_load_cert_crl_file - Default OpenSSL certificate lookup methods =head1 SYNOPSIS #include openssl/x509_vfy.h X509_LOOKUP_METHOD *X509_LOOKUP_hash_dir(void); X509_LOOKUP_METHOD *X509_LOOKUP_file(void); int X509_load_cert_file(X509_LOOKUP *ctx, const char *file, int type); int X509_load_crl_file(X509_LOOKUP *ctx, const char *file, int type); int X509_load_cert_crl_file(X509_LOOKUP *ctx, const char *file, int type); =head1 DESCRIPTION BX509_LOOKUP_hash_dir and BX509_LOOKUP_file are two certificate lookup methods to use with BX509_STORE, provided by OpenSSL library. Users of the library typically do not need to create instanses of these methods manually, they would be created automatically by LX509_STORE_load_locations(3)|X509_STORE_load_locations(3) or LSSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3) functions. Internally loading of certificates and CRLs is implemented via functions BX509_load_cert_crl_file, BX509_load_cert_file and BX509_load_crl_file. These functions support parameter Itype, which can be one of constants BFILETYPE_PEM, BFILETYPE_ASN1 and BFILETYPE_DEFAULT. They load certificates and/or CRLs from specified file into memory cache of BX509_STORE objects which given Bctx parameter is associated with. Functions BX509_load_cert_file and BX509_load_crl_file can load both PEM and DER formats depending of type value. Because DER format cannot contain more than one certificate or CRL object (while PEM can contain several concatenated PEM objects) BX509_load_cert_crl_file with BFILETYPE_ASN1 is equivalent to BX509_load_cert_file. Constant BFILETYPE_DEFAULT with NULL filename causes these functions to load default certificate store file (see LX509_STORE_set_default_paths. Functions return number of objects loaded from file or 0 in case of error. Both methods support adding several certificate locations into one BX509_STORE. This page documents certificate store formats used by these methods and caching policy. =head2 FILE METHOD BX509_LOOKUP_file method loads entire set of certificates and CRLs into memory immediately when file name is passed to it. File format is ASCII text which contains concatenated PEM certificates and CRLs. This method should be used by applications which work with limited set of CAs. =head2 HASHED DIR METHOD BX509_LOOKUP_hash_dir is more sophisticated method, which loads certificates and CRLs on demand, but caches them in the memory once they are loaded. However, since OpenSSL 1.0.0beta1 it checks for newer CRLs upon each lookup, so if newer CRL would appear in the directory, it would be loaded. Directory should contain each certificate and CRL in the separate file in the PEM format, with file name derived from certificate subject (or CRL issuer) hash, as returned by LX509_NAME_hash(3)|X509_NAME_hash(3) function of with option B-hash of Lx509(1)|x509(1) or Lcrl(1)|crl(1) command. This hash value is appended by suffix .IN for certificates and B.rIN for CRLs where IN is sequentual number among certificates with same hash value, so it is possible to have in the store several certificates with same subject or several CRLs with same issuer (and, for example, different validity period). When checking for new CRLs once one CRL for given hash value is loaded, hash_dir lookup method checks only for certificates with sequentual number greater than one of already cached CRL. Note that hash algorithm used for subject hashing is changed in OpenSSL 1.0, so all certificate stores have to be rehashed upon transitopn from 0.9.8 to 1.0.0. OpenSSL includes utility Lc_rehash(1)|c_rehash(1) which creates symlinks with correct hashed names for all files with .pem suffix in the given directory. =head1 SEE ALSO Lpem(3)|pem(3), Ld2i_X509_bio(3)|d2i_X509_bio(3), LX509_STORE_load_locations(3)|X509_STORE_load_locations(3), LX509_STORE_add_lookup(3)|X609_store_add_lookup(3), LSSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3), =cut =pod =head1 NAME X509_check_issued - checks if certificate is issued by another certificate =head1 SYNOPSIS #include openssl/x509v3.h int X509_check_issued(X509 *issuer, X509 *subject); =head1 DESCRIPTION This function checks if certificate Isubject was issued using CA certificate Iissuer. This function takes into account not only matching of issuer field of Isubject with subject field of Iissuer, but also compares BauthorityKeyIdentifier extension of Isubject
Re: What does cache field in X509_STORE struct do?
On 2009.10.12 at 19:00:30 +0200, Dr. Stephen Henson wrote: Well we are in the middle of a beta relase cycle so making incompatible changes and/or major new functionality isn't an option. Is this (#2) a major new functionality, given that cache field in X509_CTX is already here and applications rely on it? Handling multi-megabyte CRLs is problematical in any cases. OpenSSL typically trebles the size of them at least when storing in memory for example. Servers which use fork() and are not multithreaded will suffer big perormance hits reloading such CRLs. This is why I suggest this feature be controllable using cache field of X509_STORE. Application writer can than decide what is worse for him - performance hit from reloading of CRLs or interrupt of service, required when reload of server needed each time CRL is issued. Documentation I think should really concentrate on the verification mechanism and X509_STORE_CTX. X509_STORE is badly broken and was supposed to have been replaced long ago but that hasn't happened for various reasongs. Documentation should concentrate on how to do the right thing. For most purposes the right thing is to point OpenSSL to the trusted store directory/file, set neccessary X509_V_FLAGs and let it care about the rest. With current API typical application writer never sees X509_STORE_CTX. 1. SSL_CTX allows him to get pointer to X509_STORE, not X509_STORE_CTX in order to set flags or may be cache field. Locations, callbacks and such is set using SSL_CTX API. 2. PKCS7_verify and CMS_verify receive X509_STORE, not X509_STORE_CTX. These two cases cover about 99% of use of the trusted certificate store in the applications. Rest would be probably attempts to implement application-specific lookup method, say store trusted certificates and CRLs in the SQL database. Only application where I myself had to create X509_STORE_CTX in my code was PKI Client application which handles certificates and CRLs received from CA and put it into the right place (doing some checks). There I have to use X509_STORE_CTX to manually check certificates and manually lookup CRLs (because there is no CRL validation function analougue to X509_verify_cert). I think that describing life cycle of CA certificates and CRLs is much more imporaint than details of X509_STORE_CTX API. Although details of verification process are, of course, important. But this process is already documented in the verify(1) man page. Only reference to this page can be made in the X509_verify_cert(3) man page. Some flags can be described just as reference to corresponding verify(1) option. But some flags, such as X509_V_FLAG_USE_CHECK_TIME do not have corresponding command line option in the verify command,. And some (such as X509_V_FLAG_CB_ISSUER_CHECK and X509_V_FLAG_NOTIFY_POLICY) have quite different semantic on API level than on command-line level. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On 2009.10.13 at 14:12:22 +0200, Dr. Stephen Henson wrote: On Tue, Oct 13, 2009, Victor B. Wagner wrote: On 2009.10.12 at 19:00:30 +0200, Dr. Stephen Henson wrote: Well we are in the middle of a beta relase cycle so making incompatible changes and/or major new functionality isn't an option. Is this (#2) a major new functionality, given that cache field in X509_CTX is already here and applications rely on it? If it breaks existing applications yes, if it is a bugfix no. I think in this case it is arguably fixing something which is broken so it could come under that. It shouldn't break existing applications, which do not care about cache field, because X509_STORE_new initializes it to 1 (may be change it to 0xfff for future use of bitfield just now). It would probably fix stunnel, which sets cache for CRL store to 0 and expects CRLs to be reloaded. I'd suggest using a bitfield in this case but you need rather more flags than just each type of object. For example some application which need to verify certificates at times in the past might want to keep expired objects around. So, we have at least two flags for each type of object 1 X509_LU_whaterver and X509_LU_KEEP_EXPIRED X509_LU_whatever Although applications don't use X509_STORE_CTX directly they do use it and related APIs indirectly and some understading of how these structures interact would help. Of course. In that vein we'd need to document X509_STORE_CTX, X509_verify_cert() and X509_VERIFY_PARAM (and related functions). Some of this could just copy and paste or point to some existing documentation for the verify utility. Now I'm attaching a pod file which documents parts of X509_STORE API which is needed to initialize X509_STORE for verifying PKCS7/CMS/TS_response and altering behavoir of SSL_CTX certificate validation, because I've already written it. X509_STORE_CTX, X509_VERIFY_PARAM and X509_LOOKUP_hash_dir/X509_LOOKUP_file documents would follow. =pod =head1 NAME X509_STORE_new, X509_STORE_free, X509_STORE_load_locations, X509_STORE_set_default_paths, X509_STORE_add_cert, X509_STORE_add_crl, X509_verify_cert, X509_STORE_add_lookup, X509_STORE_set_flags, X509_STORE_set_purpose, X509_STORE_set_depth, X509_STORE_set1_param X509_STORE_set_verify_cb_func, X509_STORE_set_trust - manipulate trusted certificate store =head1 SYNOPSIS #include openssl/x509_vfy.h X509_STORE *X509_STORE_new(); void X509_STORE_free(X509_STORE *store); int X509_STORE_load_locations (X509_STORE *store, const char *file, const char *dir); int X509_store_set_default_paths(X509_STORE *store); int X509_STORE_add_cert(X509_STORE *store, X509 *cert); X509_LOOKUP *X509_STORE_add_lookup(X509_STORE *store, X509_LOOKUP_METHOD *m); int X509_STORE_add_crl(X509_STORE *store, X509_CRL *crl); int X509_STORE_set1_param(X509_STORE *store, X509_VERIFY_PARAM *param); int X509_STORE_set_flags(X509_STORE *store, unsigned long flags); int X509_STORE_set_purpose(X509_STORE *store, int purpose); int X509_STORE_set_trust(X509_STORE *store, int trust); int X509_STORE_set_depth(X509_STORE *store, int depth); X509_STORE_set_verify_cb_func(X509_STORE *store, int (*verify_cb)(int ok, X509_STORE_CTX *ctx)) =head1 DESCRIPTION BX509_STORE structure holds information, neccessary for certificate verification process. This information include set of trusted CA certificates and corresponding CRLs, various flags modifying verification process and additional information such as required certificate purpose and policy. This structure can be passed to LPKCS7_verify(3)|PKCS7_verify(#) and LCMS_verify(3)|CMS_verify(3) functions. When SSL_CTX is created, it creates BX509_STORE internally. This store can be obtained using LSSL_CTX_get_cert_store(3)|SSL_CTX_get_cert_store(3) function and its behavoir modified by setting flags and other verification parameters. It is also possible to replace internally created BX509_STORE by custom one using LSSL_CTX_set_cert_store(3)|SSL_CTX_set_cert_store(#). BX509_STORE doesn't neccessary hold all trusted certificates and CRLs in itself. There is flexible mechanism of BX509_LOOKUP_METHODS which allows to implement own certificate storage, for example with relational database backend or LDAP. OpenSSL implements two simple lookup methods: LX509_LOOKUP_file(3)|X509_LOOKUP_file(3) and LX509_LOOKUP_hash_dir(3)|X509_LOOKUP_hash_dir(3). Users typically don't need to create instances of these lookup methods explicitely. They are created in the BX509_STORE_load_locations (or LSSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)). Actual certificate verification, lookup and chain building is performed by BX509_STORE_CTX object, which is created based on BX509_STORE object. Unless application need to check certificates and CRLs by its own, it doesn't need to create BX509_STORE_CTX, it would be created internally by SSL or PKCS7/CMS API functions
Re: What does cache field in X509_STORE struct do?
On 2009.10.13 at 14:30:50 +0200, Dr. Stephen Henson wrote:
On Mon, Oct 12, 2009, Victor B. Wagner wrote:
2. Make X509_LOOKUP_hash_dir lookup method honour cache field in the
X509_STORE structure. (I think that it is better to make this field
a bit mask and interpret constants X509_LU_CERT and X509_LU_CRL as
bit flags, but it would conflict with X509_LU_PKEY constant, which
seems to be unused anyway. But for first time handle this field as
boolean flag is better than nothing)
Ah I just remembered something about how this works which makes disabling
caching more complex.
The X509_LOOKUP API retrieves one matching object: that's a limitation of the
API. It however populates the cache with all matching objects. The API
limitation can be worked around by examining the cache after a lookup.
If you disable the cache without having something equivalent to retrieve
multiple matching objects you can stop verificaion working properly in some
cases, for example:
1. CRLs with only partial scope (deltas and partitioned ones).
2. Certificates with different AKID but same subject names.
3. Historical checks on chains using certificates and/or CRLs that are not
current.
Admittedly #3 isn't likely to be used much but in the case of #1 and #2 some
paths will just fail to verify. We'd at least need to document that: in many
cases such features wont be used so it wont matter.
This can be solved by just one-line patch
--- x509_lu.c.orig 2009-10-13 17:23:48.0 +0400
+++ x509_lu.c 2009-10-13 17:24:15.0 +0400
@@ -290,7 +290,7 @@
tmp=X509_OBJECT_retrieve_by_subject(ctx-objs,type,name);
- if (tmp == NULL || type == X509_LU_CRL)
+ if (!cache || tmp == NULL || type == X509_LU_CRL)
{
for
(i=vs-current_method;
isk_X509_LOOKUP_num(ctx-get_cert_methods);
i++)
{
This solution has drawback that it doesn't save memory used by cache,
but it would make X509_STORE repeat search in the hashed directory each
time if cache is disabled.
And it still allow examining cache for additional matches. after search
I've now noticed that three years ago you've already commited fix
that makes search for CRLs each time.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On 2009.10.13 at 18:20:12 +0200, Dr. Stephen Henson wrote: There is some additional logic for CRLs though. In by_dir.c it stores the last suffix value of a CRL so if you have CRL links: This logic have to be clearly documented in the X509_LOOKUP_hash_dir manual page. I'd write what I've learned from this letter, but I hope, you'll read and improve it. Because it is critically important information for utilities which update hashed directory - that new CRL should be added, rather than replace outdating ones. Of course, keeping history in the hashed directory makes some sense. It notes that r3 is the last CRL looked up if now a new one is added: 12345678.r4 it only looks for r4 and doesn't reload all the (potentially large) previous CRLs. The logic is that CRLs change far more regularly than certificates. Though in certificates the likelihood of matching hash values is far less. This is place I've not got complete understanding from the code reading. In our case we need to perform root certificate rollover each year. But I'm not sure yet, that if new root certificate would be issued with same DN (but, of course, different subjectKeyIdentifier) certificate chains would be constructed properly. Idea is that root certificate is issued with validity period of two years, but is changed year after. And client certificates are issued with validity period 1 year. So root certificate expires same day as last certificate possible signed by it is expired. Of course, it is possible to add something to DN of new root certificate, such as serialNumber or UID, and increment this field each time new certificate is issued. I also have an idea of issuing certificate for old CA key signed by new CA key, so new client which joined system after rollover have to manually install only one, current, CA certificate (manually install means - compare fingerprint with some printed document), and older certificates are verified with chain of length 2. But this is just marginal usablity improvement. So, if chain of two certificates with identical DN cannot be built, it is not a big problem. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
What does cache field in X509_STORE struct do?
Hi, I've found out that default lookup method X509_LOOKUP_hash_dir caches certificates and CRLs very aggressively. Really, it uses X509_load_cert_file and X509_load_crl_file from X509_LOOKUP_file method, which always put object into memory cache, and never frees anything from this cache. From some previous discussions in this mailing list, I've got an impression, that main difference between hash_dir and file lookup method is that hash_dir doesn't keep all CA data (certificates and CRLs) in the memory, but loads them from disk on demand. There are two main reasons to spend CPU cycles for loading CRLs from disk each time: 1. CRLs of big public CAs can be quite big - up to tens of megabytes. 2. For some server applications SSL_CTX and associated X509_STORE can live long enough, and CRL loaded on startup can be superceeded by newly issued CRL. Some applications, such as stunnel use cache field in X509_STORE struct for this very reason - disable memory caching of CRLs. But this doesn't work, because cache field is never used. Only reference to this field in the OpenSSL code is its initialization in X509_STORE_new (I've checked both 0.9.8 and 1.0.0 beta code). Should be it considered a bug, a missing functionality or should cache field be removed from X509_STORE to avoid confusion of application authors? BTW, it seems that most applications which actualy use CRLs, such as Apache, openvpn and stunnel, do implement lookup of certicate in the CRL in its own code, not relying on X509_V_FLAG_CRL_CHECK in X509_STORE. Regards, Victor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On 2009.10.12 at 14:49:23 +0200, Dr. Stephen Henson wrote: On Mon, Oct 12, 2009, Victor B. Wagner wrote: BTW, it seems that most applications which actualy use CRLs, such as Apache, openvpn and stunnel, do implement lookup of certicate in the CRL in its own code, not relying on X509_V_FLAG_CRL_CHECK in X509_STORE. In some cases CRL lookup is done manually because the code originates from a time when OpenSSL didn't perform its own CRL lookup. Some of this mishandles CRLs and doesn't reject CRLs containing unhandled critical extensions. This raises security concerns: for example it would be possible to substitue CRLs of limited scope and fool such applications into thinking revoked certificates were valid. Of course, application-level handling of such important thing as CRL lookup would raise security problems. Authors of crypto library should know better about such problems, then authors of application. But there are serious problems with X509_STORE object and default lookup methods in OpenSSL just now. I think that we should fix this problems first, and then urge authors of applications to use OpenSSL code rather than to reinvent the wheel. First of all, X509_STORE working is not documented at all. Authors of applications just have no source of information how to handle certificate verification except the source code of verify utility. (which is not well suited for server authors, because it is not intended to run for weeks without restart). Second, there is problem with aggressive caching and unused cache field, which I've mentioned in previous letter. Third, there should be guidelines for implementors of custom lookup method. At least such as there exist for implemetors of UI_METHODS which are quite verbose comments in the header file. Fourth, I've spend hours studying of X509_STORE source code and cannot realize how it would handle CA certificate rollover. I.e. is setting of subjectKeyIdentifier and authorityKeyIdentifier sufficient to recognize difference between old and new CA certificate or when I'm issuing new CA certificate I have to make its DN unique. If we want application writers to use OpenSSL code securely, we should somehow provide them clear understanding which security threats we care of, and how we handle them. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On 2009.10.12 at 14:49:23 +0200, Dr. Stephen Henson wrote: On Mon, Oct 12, 2009, Victor B. Wagner wrote: BTW, it seems that most applications which actualy use CRLs, such as Apache, openvpn and stunnel, do implement lookup of certicate in the CRL in its own code, not relying on X509_V_FLAG_CRL_CHECK in X509_STORE. In some cases CRL lookup is done manually because the code originates from a time when OpenSSL didn't perform its own CRL lookup. I can provide in some reasonable timeframe (say, this week) a patch with following functionality: 1. Somehow document X509_STORE object. It would require proofreading, because I do not have experience with big certification authorities with multimegabyte CRLs and multilevel secondary CA hierarchy (where security problems you mention are applicable). But I'm sure it is better than nothing 2. Make X509_LOOKUP_hash_dir lookup method honour cache field in the X509_STORE structure. (I think that it is better to make this field a bit mask and interpret constants X509_LU_CERT and X509_LU_CRL as bit flags, but it would conflict with X509_LU_PKEY constant, which seems to be unused anyway. But for first time handle this field as boolean flag is better than nothing) 3. Make X509_LOOKUP_hash_dir check notAfter field of certificate and nextUpdate field of CRL and attempt to reload CRL/certificate from disk if cached copy in the memory have been expired. Does this plan seems to be acceptable intermediate solution? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1992] RAND_poll() and CreateToolhelp32Snapshot() stability (also for 1.0.0.b3)
On 2009.09.22 at 12:13:45 +0200, Ger Hobbelt via RT wrote: Sorry for late reply; been under the weather lately, healthwise, so this is my first 'on-line' experience in a while ;-) As far as the brain is operational again... I'd say the quickest way to fix this is to wrap the __try/__except chunk in a compiler-specific preproc check a la: #if defined(_MSC_VER) __try ... __except ... #endif No use doing #else branches for that one, as the alternatives are: - I don't think mingw et al have something equivalent to offer anyhow, unless they've come up with some harebrained signal/sigaction scheme of their own instead. Allow me to cringe if they have. Mingw does. It have header except.h, which defines __try1 and __except1 which do some assembler black magic. Unfortunately I don't know windows internals enough to tell from the glance if this magic correct or not. So, I haven't tried to use them in RAND_poll.c. If somebody would provide me a test program which reproducibly generates a SEH, I would give it a try. Really, mingw compiling for Win32 have some advantages and it is no a good idea to drop mingw support entirely (which is effectively done with this fix). 1. You don't need windows to build something with mingw. If you are developing cross-platform applications, you can compile for all platforms on the same machine. 2. You don't have to mess with zillion of versions of msvcrXX.dll Even newest versions of mingw32 compile binaries, which use msvcrt.dll, regardless of debug or release mode, which is compatible with every newer version of MS compiler, and present in every Windows since NT 4.0 at least. So you don't have to include runtime DLLs into your installation package. 3. It's free as free speech. - The choice to 'roll your own' I would strongly advise to stay the hell away from; for a hint of what it might take for starters, see http://www.microsoft.com/msj/0197/Exception/Exception.aspx So unless someone can teach me the error of my current ways regarding SEH and gcc on Win32/64, I'd say that __try/__except encased section Really, mingw have define SEHNOOP, which makes __try and __except empty. But it is not a good thing, because it doesn't actually catch an exception. But for now I use it for my mingw cross-builds. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Rehashing Directories
On 2009.06.04 at 21:31:19 -0400, David Michael wrote: Hi, A certain daemon I am building requires root certificates to have hash links in order to find them. My target OS provides a multi-cert PEM with just about every common root cert out there, so I prefer to have the hash links pointing directly at this. The rehash scripts will only link the PEM to the hash value of the first cert in it. I have implemented the ability to handle multi-cert hash links in scripts for the time being, but I would like to see it upstream so there is one less patch/script people would have to use to setup this project (and others, I'm sure). If this change could be accepted into the project, I can write the code myself in C, Perl, shell, or anything else if need be. Attached is a quick patch to the Perl c_rehash script to show what functionality I am requesting. I think you are missing something with this idea. OpenSSL now provides two X509_LOOKUP_METHODS - lookup_file and lookup_hashed_dir. First one requires big multi-cert file with concatenated PEM certificates - exactly as your OS provided, I suppose. Second requires hashed dir with individual certs and CRLs one per file. And it is done for good reason: If you use lookup_file method, it loads entire file into memory. And this file can be quite big, if you use CRL checks and have big public CAs in your trusted certificate set - big public CA can have multimegabyte CRLs. If you use lookup_dir method, OpenSSL would load only certificates and CRLs when needed, one per time, and thus potentially save you much space. Allowing to put multicertificate file into hashed dir would defeat benefits of lookup_dir method. Although it would work. It is better to fix your daemon so it would allow both files and hashed directories as trusted certificate store. It should be simple - both SSL_CTX_load_verify_locations (which should be used for SSL peer certificate validation) and X509_STORE_load_locations (which should be used for SMIME, timestamping and outher non-SSL uses) accept two arguments - name of file and name of directory. If your daemon uses default cert store location, than corresponding X509_STORE_set_default_paths function supports file and dir too. In this case you probably do not need to change code. You just have to either set environment variable SSL_CERT_FILE pointing to you multicert file, or make symlink pointing to this file named cert.pem in your OPENSSLDIR (run openssl version -d to determine where your OPENSSL dir is). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: TS command docs - bug or I'm missing something?
On 2009.05.28 at 10:40:24 -0700, Kyle Hamilton wrote: default_policy is only mandated if you don't use -policy. It is not quite clear from the documentation. It would be much better, if documentation would contain line, quoted above, than current (Optional) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCSP
On 2009.05.27 at 12:16:53 +0530, Ashish Agrawal wrote: Hi All, I am luking for OCSP API interface support in openssl, can somebody guide me to relevant information source or sample code. Look into the source of ocsp command in openssl source distribution (apps/ocsp.c). You can also find some comments in include/openssl/ocsp.h helpful. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
TS command docs - bug or I'm missing something?
Documentation for openssl ts command says following: Timestamp responce generation ...skip... -policy object_id The default policy to use for the response unless the client explicitly requires a particular TSA policy. The OID can be speci- fied either in dotted notation or with its name. Overrides the default_policy config file option. (Optional) ...skip... CONFIGURATION FILE OPTIONS ...skip... default_policy The default policy to use when the request does not mandate any policy. The same as the -policy command line option. (Optional) However, if I don't specify -policy in the command line, and config doesn't contain default_policy variable, openssl ts -reply command complains variable lookup failed for tsa_section::default_policy Response is not generated. 3082778272:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:335:group=tsa_section name=default_policy Does it mean that default_policy configuration file option should be marked as Mandatory in the documentation, or I'm missing something? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCSP problems
On 2009.05.21 at 11:34:12 +0200, Marc Rios Valles wrote: I'm running the server as is indicated in the openssl web page: openssl ocsp -index index_file.txt -CA ca-cert.pem -rsigner rsigner_cert -rkey rsigner_key -port -text -out log.txt If I send an ocsp petition to the server the server answers correct the response to the client. If I would need to run OCSP server and have no time to write custom server based on OpenSSL OCSP API, I would do following: 1. Install usial http server (i.e. apache). 2. Write CGI script which would run openssl ocsp with option -reqin - i.e do not listen on the port itself, but get request in the file or from stdin 3. may be do some verification of request format in the script before passing it to openssl ocsp (i.e. parse ASN.1 structure using some scripting language which isn't vulnerable to buffer overflows) Thus I would have much more robust http server code, and I make sure that only sanitized input would be passed to openssl ocsp which has access to response signing keys. As side effect, fresh copy of openssl ocsp would be run each time request is processed, so index file would be reread. To run fresh copy each time request is processed, might be not desirable if you have heavy-loaded OCSP server (although you'll notice slowdown only if you have several requests per second, even if you index.txt contain thousands of lines). Another setup is also possible - write CA script which is invoked each time you create or revoke certificate (and actually calls openssl ca with appropriate parameters) which restarts ocsp server process. But I'm affraid that this setup is less scalable than setup described above. Of course several processes reading index.txt each time would eat up more CPU time, but they would process request in parallel. And openssl ocsp in server mode processes requests sequentually, and thus can serve them more slowly than CGI solution, especially on multicore system. apps/ocsp.c:707 if (ridx_filename !rdb) if rdb is not null the index will never be read, so the server only consults one time the index file in all execution. It's this a desired feature? I will correct this line for: apps/ocsp.c:707 if (ridx_filename) Better to store file modification time when file is read, and than reread file if its modification time is changed. Then you'll need only one stat syscall if file is not modified since previous read. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1887] [patch] Fixes in openssl utitity documentation and builtin-help
We've found some typos and omissions in the openssl utility documentation (either builtin messages and pod pages). Following patch fixes some of these problems. We haven't thoroughly reviewed all the manual pages in the docs/app, concentrating on those commands which can use GOST algorithmns via command-line options and commands which perform certificate verification. Description of patch This patch fixes some omission in the documentation and messages of the openssl utility. Fixes in the code: 1. apps/dgst.c Use OBJ_NAME_do_all_sorted to list available digest options instead of hardcoded list of digests (as it is done for simmetric ciphers in the enc command). This allows to pick up digests, provided by engines (such as md_gost94) and also ensures that digests, excluded during compilation (such as mdc2) wouldn't be listed. Added missing options -opt, -mac and -macopt to the usage message. 2. apps/pkeyparam.c Fixed typo in the error message 3. apps/pkeyutl.c Fixed incorrect option name (-signature instead of -sigfile) in the usage message. 4. apps/req.c Make search for digest last option (it was before -extensions and -reqext) Fixes in the manual page 1. -engine option description of most commands incorrectly referred to req command, rather than command described. 2. Removed explicit and incomplete list of ciphers from smime and cms commands and added reference to enc command for full list of ciphers 3. Added list of certificate verification options supported by args_verify function in the apps/app.c to the man pages of smime and cms commands (which use this function) with reference to verify man page, where these options briefly described (description taken from comments in crypto/x509/x509_vfy.h) 4. Documentend -keyform, -engine, -sigopt, -mac and -macopt options of the dgst command 5. Documented options -base64 -salt, -nosalt, -z -md, -none and -engine for enc command 6. Described working with engine-provided ciphers in the enc command 7. Added ciphers, provided by ccgost engine to the list of supported ciphers (marking them as engine-provided) 8. Added manual page for engine command (which was missing) 9. Added section about GOST algorithm parameters to the genpkey manpage 10. Make list of manual pages for individual commands in openssl(1) man page correspond to list of actual commands displayed by openssl running without arguments 11. Documented -engine and -passin for pkeyutl command 12. Removed hardcoded list of digests from req manual 13. Expanded and clarified description of req -newkey 14. Documented briefly -keygen_engine, -no-asn1-kudge, -reqopt, -subject and -subj options for req command. 15. Documented -crl_check and -crl_check_all options for s_client command (they are already documetned for s_server) ? crypto/des/des_enc-sparc.S ? doc/apps/engine.pod Index: Makefile.shared === RCS file: /cvs-openssl/openssl/Makefile.shared,v retrieving revision 1.72 diff -u -r1.72 Makefile.shared --- Makefile.shared 2 Jan 2009 09:02:27 - 1.72 +++ Makefile.shared 2 Apr 2009 10:25:30 - @@ -70,7 +70,7 @@ # The rest is private to this makefile. SET_X=: -#SET_X=set -x +SET_X=set -x top: echo Trying to use this makefile interactively? Don't. Index: apps/Makefile === RCS file: /cvs-openssl/openssl/apps/Makefile,v retrieving revision 1.33 diff -u -r1.33 Makefile --- apps/Makefile 2 Dec 2008 01:21:34 - 1.33 +++ apps/Makefile 2 Apr 2009 10:25:30 - @@ -939,14 +939,13 @@ speed.o: ../include/openssl/opensslv.h ../include/openssl/ossl_typ.h speed.o: ../include/openssl/pkcs7.h ../include/openssl/rand.h speed.o: ../include/openssl/rc2.h ../include/openssl/rc4.h -speed.o: ../include/openssl/ripemd.h ../include/openssl/rsa.h -speed.o: ../include/openssl/safestack.h ../include/openssl/seed.h -speed.o: ../include/openssl/sha.h ../include/openssl/stack.h -speed.o: ../include/openssl/symhacks.h ../include/openssl/txt_db.h -speed.o: ../include/openssl/ui.h ../include/openssl/ui_compat.h -speed.o: ../include/openssl/whrlpool.h ../include/openssl/x509.h -speed.o: ../include/openssl/x509_vfy.h ../include/openssl/x509v3.h apps.h -speed.o: speed.c testdsa.h testrsa.h +speed.o: ../include/openssl/rsa.h ../include/openssl/safestack.h +speed.o: ../include/openssl/seed.h ../include/openssl/sha.h +speed.o: ../include/openssl/stack.h ../include/openssl/symhacks.h +speed.o: ../include/openssl/txt_db.h ../include/openssl/ui.h +speed.o: ../include/openssl/ui_compat.h ../include/openssl/whrlpool.h +speed.o: ../include/openssl/x509.h ../include/openssl/x509_vfy.h +speed.o: ../include/openssl/x509v3.h apps.h speed.c testdsa.h testrsa.h spkac.o: ../e_os.h ../include/openssl/asn1.h ../include/openssl/bio.h spkac.o: ../include/openssl/buffer.h ../include/openssl/conf.h spkac.o:
Missing documentation
I've investigated lacks of documentation in the current OpenSSL snapshot. Method of investigation is quite simple 1. Run util/extract-names.pl on the all pod files in the doc/crypto and doc/ssl and produce sorted list of all function names referenced in the NAME sections. 2. Take lists of exported symbols used in Windows DLL building (utils/libeay.num and utils/ssl.num) 3. Use comm(1) to compare these lists Results are quite discouraging. library| exported | documened | other things documented | | | | (macros, intro pages) | ---+--+---+-+ ssl | 258 | 159 |52 | crypto |4012 | 683 | 159 | ---+--+---+-+ Of course, there are functions which are really documented, just non mentioned in the NAME section of appropriate man page (which means that symlink with such name is not installed, and user would be unable to find documentation for this function) There might be some semi-internal functions or exported variable, which do not deserve its own manual pages. But there are big omissions. For example entire family of X509_STORE functions, OCSP api, TS API are nont documetned. I'm attaching here couple of POD files for EVP_PKEY_METHOD and EVP_PKEY_ASN1_METHOD API, which we have written while developing ccgost engine. Of course it would cover only 19 of more than 3 thousands undocumented names, and not most widely used APIs. We also have some documentation about X509_STORE and OCSP API, published in the PDF format on http://www.cryptocom.ru/OpenSource/OpenSSL_rus.html, but it has to be translated from Russian and converted into POD format. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Missing documentation
I've investigated lacks of documentation in the current OpenSSL snapshot. Method of investigation is quite simple 1. Run util/extract-names.pl on the all pod files in the doc/crypto and doc/ssl and produce sorted list of all function names referenced in the NAME sections. 2. Take lists of exported symbols used in Windows DLL building (utils/libeay.num and utils/ssl.num) 3. Use comm(1) to compare these lists Results are quite discouraging. library| exported | documened | other things documented | | | | (macros, intro pages) | ---+--+---+-+ ssl | 258 | 159 |52 | crypto |4012 | 683 | 159 | ---+--+---+-+ Of course, there are functions which are really documented, just non mentioned in the NAME section of appropriate man page (which means that symlink with such name is not installed, and user would be unable to find documentation for this function) There might be some semi-internal functions or exported variable, which do not deserve its own manual pages. But there are big omissions. For example entire family of X509_STORE functions, OCSP api, TS API are nont documetned. I'm attaching here couple of POD files for EVP_PKEY_METHOD and EVP_PKEY_ASN1_METHOD API, which we have written while developing ccgost engine. Of course it would cover only 19 of more than 3 thousands undocumented names, and not most widely used APIs. We also have some documentation about X509_STORE and OCSP API, published in the PDF format on http://www.cryptocom.ru/OpenSource/OpenSSL_rus.html, but it has to be translated from Russian and converted into POD format. - End forwarded message - =pod =head1 NAME EVP_PKEY_METHOD, ENGINE_set_pkey_meths, EVP_PKEY_meth_new, EVP_PKEY_meth_set_init, EVP_PKEY_meth_free, EVP_PKEY_meth_set_cleanup, EVP_PKEY_meth_set_copy, EVP_PKEY_meth_set_paramgen, EVP_PKEY_meth_set_keygen, EVP_PKEY_meth_set_sign, EVP_PKEY_meth_set_verify, EVP_PKEY_meth_set_verify_recover, EVP_PKEY_meth_set_signctx, EVP_PKEY_meth_set_verifyctx, EVP_PKEY_meth_set_encrypt, EVP_PKEY_meth_set_decrypt, EVP_PKEY_meth_set_derive, EVP_PKEY_meth_set_ctrl - Public key method manupulation routines =head1 SYNOPSIS #include openssl/engine.h int ENGINE_set_pkey_meths(ENGINE *e, ENGINE_PKEY_METHS_PTR pkey_meths); #include openssl/evp.h EVP_PKEY_METHOD* EVP_PKEY_meth_new(int nid, int flags); void EVP_PKEY_meth_free(EVP_PKEY_METHOD *pmeth); void EVP_PKEY_meth_set_init(EVP_PKEY_METHOD *pmeth, int (*init)(EVP_PKEY_CTX *ctx)); void EVP_PKEY_meth_set_cleanup(EVP_PKEY_METHOD *pmeth, void (*cleanup)(EVP_PKEY_CTX *ctx)); void EVP_PKEY_meth_set_copy(EVP_PKEY_METHOD *pmeth, int (*copy)(EVP_PKEY_CTX *dst, EVP_PKEY_CTX *src)); void EVP_PKEY_meth_set_paramgen(EVP_PKEY_METHOD *pmeth, int (*paramgen_init)(EVP_PKEY_CTX *ctx), int (*paramgen)(EVP_PKEY_CTX *ctx, EVP_PKEY *pkey)); void EVP_PKEY_meth_set_keygen(EVP_PKEY_METHOD *pmeth, int (*keygen_init)(EVP_PKEY_CTX *ctx), int (*keygen)(EVP_PKEY_CTX *ctx, EVP_PKEY *pkey)); void EVP_PKEY_meth_set_sign(EVP_PKEY_METHOD *pmeth, int (*sign_init)(EVP_PKEY_CTX *ctx), int (*sign)(EVP_PKEY_CTX *ctx, unsigned char *sig, size_t *siglen, const unsigned char *tbs, size_t tbslen)); void EVP_PKEY_meth_set_verify(EVP_PKEY_METHOD *pmeth, int (*verify_init)(EVP_PKEY_CTX *ctx), int (*verify)(EVP_PKEY_CTX *ctx, const unsigned char *sig, size_t siglen, const unsigned char *tbs, size_t tbslen)); void EVP_PKEY_meth_set_verify_recover(EVP_PKEY_METHOD *pmeth, int (*verify_recover_init)(EVP_PKEY_CTX *ctx), int (*verify_recover)(EVP_PKEY_CTX *ctx, unsigned char *rout, size_t *routlen, const unsigned char *sig, size_t siglen)); void EVP_PKEY_meth_set_signctx(EVP_PKEY_METHOD *pmeth, int (*signctx_init)(EVP_PKEY_CTX *ctx, EVP_MD_CTX *mctx), int (*signctx)(EVP_PKEY_CTX *ctx, unsigned char *sig, size_t *siglen, EVP_MD_CTX *mctx)); void EVP_PKEY_meth_set_verifyctx(EVP_PKEY_METHOD *pmeth, int (*verifyctx_init)(EVP_PKEY_CTX *ctx, EVP_MD_CTX *mctx), int (*verifyctx)(EVP_PKEY_CTX *ctx, const unsigned char *sig,int siglen, EVP_MD_CTX *mctx)); void EVP_PKEY_meth_set_encrypt(EVP_PKEY_METHOD *pmeth, int (*encrypt_init)(EVP_PKEY_CTX *ctx), int (*encrypt)(EVP_PKEY_CTX *ctx, unsigned char *out, size_t *outlen, const unsigned char *in, size_t inlen)); void EVP_PKEY_meth_set_decrypt(EVP_PKEY_METHOD *pmeth, int (*decrypt_init)(EVP_PKEY_CTX *ctx), int (*decrypt)(EVP_PKEY_CTX *ctx, unsigned char *out, size_t *outlen, const unsigned char *in, size_t inlen)); void EVP_PKEY_meth_set_derive(EVP_PKEY_METHOD *pmeth, int (*derive_init)(EVP_PKEY_CTX *ctx),
Re:DB_ERROR_INDEX_CLASH in openssl ca
Recently I've discovered problem with our automated test script, which creates several certificates using openssl ca command. Script used to create two certificates with identical distinguished name, but different public key algorithms (which seems to be a situation which can occur in real world) It works with 0.9.8, and worked with development snapshot for a long time, but recently it began to fail with obscure report TXT DB Error 2. Looking into crypto/txt_db/txt_db.h I've found that it means DB_ERROR_INDEX_CLASH. I've supposed that it means that I'm trying to insert two records with identical primary keys in the database and temporarily fixed situation by adding algorithm name into DN as OU field (which is acceptable for automated tests, but not for real world). But I cannot find any info what is index for database, used by openssl ca command (index.txt file) and how one supposed to handle duplicated indexes. Index.txt database, used by ca command has following fields 1. Certificate validity flag 2. Certificate expiration date 3. Сertificate revocation date (if any) 3. Certificate serial number 4. Revocation reason 5. Certificate DN (in X509_NAME_oneline format which is not quite readable if utf-8 is used for DN fields) So, I cannot see how situation with different certificates with different key usage or different algorithms for same subject can be handled if unique primary key for this database is required. Or may be I'm misunderstanding meaning if INDEX_CLASH error? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1843] Buffer overrun in X509_NAME_hash in the development branch of openssl
Recently (with commit of Jan 15 2009) MD5 hash function in
X509_NAME_hash was replaced by SHA1.
However local variable to hold computed hash value is still 16 bytes
(when 20 is required).
This causes stack corruption and segmentation faults on some platforms
(detected on Debian Linux 4.0 amd64)
Following patch fixes this problem.
This patch use symbolic SHA_DIGEST_LENGTH constant, which makes
correspondence between md variable size and used hash function more
noticeable.
Index: crypto/x509/x509_cmp.c
===
RCS file: /cvs-openssl/openssl/crypto/x509/x509_cmp.c,v
retrieving revision 1.33
diff -u -r1.33 x509_cmp.c
--- crypto/x509/x509_cmp.c 15 Jan 2009 13:22:39 - 1.33
+++ crypto/x509/x509_cmp.c 16 Feb 2009 12:56:04 -
@@ -201,7 +201,7 @@
unsigned long X509_NAME_hash(X509_NAME *x)
{
unsigned long ret=0;
- unsigned char md[16];
+ unsigned char md[SHA_DIGEST_LENGTH];
/* Make sure X509_NAME structure contains valid cached encoding */
i2d_X509_NAME(x,NULL);
Re: Can I create cryptoprovider based on openssl ?
On 2008.12.19 at 14:03:46 -0500, Patrick Patterson wrote: Ok - if you are asking if there is a generic crypto layer in Linux - the answer is no. Today, there is a mix of applications that use their own crypto (eg: parts of KDE, Java, others), applications that use OpenSSL (Apache, Postfix, OpenLDAP, etc.), application that use GNUTLS, applications that use NSS - Netscape Security Services (Evolution, OpenOffice (I think), Mozilla), GPGSM (other parts of KDE), and the Kernel (several of the IPSec implementations). Things are even more complicated. Most of application software out there can be compile-time (or even runtime) configured to use different crypto libraries. Typically, there is a choice between OpenSSL and gcrypt/GNU TLS GPGSM is based on libgcrypt, so it uses same implementation of algorithms as GNU TLS. OpenOffice uses libxmlsec to sign documents, and this library can be compiled with any of three libraries mentioned, as well as MS CryptoProvider (on Windows platform) Most distributions of OpenOffice for Linux, however use NSS for crypto, because libnss contain own ready to use certificate and private key store (one which Firefox and Thunderbird use), and OpenSSL doesn't. Kernel support for cryptography, AFAIC doesn't include public key cryptography. There is no need for it. You need some userspace tool to perform connection initiation and certificate verification. And this tool is typically compiled with OpenSSL or NSS. And only fast simmetric ciphers and digests/macs need to be inside kernel for good fast IPSEC implementation. add Java support), but in general, if you are adding primitives, then you've got A LOT of places to go and add that support to). Realy there is even more work, because most application authors think that there is quite limited set of algorithms. Often some RSA specific routines, such as SSL_use_RSAPrivateKey_file are used in application code, where algorithm independent SSL_use_PrivateKey_file would do. Some other authors hardcode list of ciphersuites which do not include newly added ciphersuites implicitely. For example, couple of years ago I've to submit patches to PostgreSQL database to be able to use GOST ciphersuites with it. Fortunately, they included these patches in 8.3 release. So, if application uses a cryptographic library which supports needed algorithm (which is now a case with OpenSSL and Russian standard GOST algorithms), it doesn't mean, that you can just throw in correct keys and certificates and everything should work. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1671] Configure options are not passed to mkdef.pl in mingw build
On 2008.05.13 at 22:10:12 +0300, Roumen Petrov wrote: Shared build of OpenSSL for Windows platform involves executing of file util/mkdef.pl to creates .def file for each shared library. This file specifies what symbols are exported from the library. Script mkdef.pl expects to receive some configuration options, such as no-alg or zlib. If these options are not passed properly (i.e same way as to Configure), build fails, either when building shared library (in case if some algorithms were disabled and corresponding functions are not available in the object files) or when building openssl.exe binary (in case if some optional features such as zlib compression were enabled and used by object files in the apps directory). However, script mkdef.pl is invoked from the link_a.cygwin target of Makefile.shared without passsing configure arguments. Attached patch fixes this problem It does just to things: 1. Adds variable CONFIGURE_ARGS to the list of variables passed to make subprocess in the BUILDENV macro 2. Passes content of this variable to mkdef.pl invocation in the link_a.cygwin target in the Makefile.shared. But util/mkdef.pl parse OPTIONS in top Makefile. Therefore, it does it incorrectly. I've encountered real errors doing build with ./Configure mingw shared zlib --cross-compile-prefix=i586-mingw32msvc- mkdef.pl does if ($_ eq zlib || $_ eq zlib-dynamic || $_ eq enable-zlib-dynamic) but in this case OPTIONS contain enable-zlib no-zlib-dynamic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HMAC support in engine interface?
On 2008.01.07 at 23:05:09 -0500, Thor Lancelot Simon wrote: The engine interface operates at too low a layer to directly accellerate HMAC. This is unfortunate since it means even on hosts with crypto hardware that can do HMAC quite fast, it ends up using raw digest operations and being slower than software (because of the system call overhead to do each digest operation of the HMAC). The result is that a number of engines disable all hash accelleration. What would be a reasonable way to fix this? I will gladly contribute the code back to OpenSSL if I can get any kind of feedback that it would be accepted. Really, it is already fixed in current 0.9.9 build. There is a way to provide arbitrary MAC algorithms (not only HMAC) using EVP_PKEY_METHOD and calulate MACs using EVP_DigestSign* API. There is also built-in implementation of HMAC algorithm as PKEY_METHOD, which one may study in order to provide own from the engine. Some time ago I've submited few documentation pages which cover this subjects, but they seems not to get into HEAD. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Any Apache/mod_ssl developers out there?
Hi there, Is there somebody involved in development of mod_ssl module for Apache? Question is - since support for GOST cryptography is added to OpenSSL 0.9.9, we are now going to implement support of GOST ciphersuites in the Apache (because https is most frequent use of TLS with national cryptography, at least here, in Russia). We have some experience with our unoffical patch to OpenSSL 0.9.8 and know that adding of new public key type to the Apache/mod_ssl requires a bit more than just recompilation. But there is probably already ongoing effort to add EC ciphersuites support to the mod_ssl. We want coordinate our work and eventually make Apache support all ciphersuites and public key types, supported by OpenSSL out of the box. But I cannot yet find more appropriate place for mod_ssl development discussion or any reference to the work of adding EC cryptography to mod_ssl. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
PKCS#11 wrapper around OpenSSL
I was asked by one user if we are planning to provide PKCS#11 module, based on OpenSSL (it was in the context of adding GOST algorithms support to the Mozilla-based software). I doubt is this solution is technically feasable. As far as I know, most people do it other way around - write interfaces which allow to USE PKCS#11 modules from within OpenSSL. I've seen at least two engines which interface external PKCS#11 modules, and both are incomplete, so if there is a PKCS#11 module which implements new public key algorithm, they wouldn't allow to use it. But question is - is it a good idea to write PKCS#11 module which uses OpenSSL (with all its engine support) for cryptography and supports everything OpenSSL supports. I haven't studied PKCS#11 specification in great detail - it is very huge. From the first glance it looks like just a big enough coding effort - OpenSSL contains all neccessary cryptography routines and ASN.1 support to provide PKCS#11 interface. May be someone on this list hav dug a bit deeper in the PKCS#11 specification and can give more arguments pro or contra? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PKCS#11 wrapper around OpenSSL
On 2007.11.19 at 20:46:36 +1000, Peter Waltenberg wrote: There are some things that are quite hard problems doing it the other way round. FIPS certification with the OpenSSL engine plugin active is probably the worst. With PKCS#11 on top of OpenSSL you have an industry standard API, which most hardware cards support. So you could swap a FIPS certified hardware card with a FIPS certified PKCS#11 on top of OpenSSL. Using OpenSSL with the engine code underneath doesn't make much sense in this context. Since 0.9.9 engine modules can add new algorithms, not only new implementations (i.e. hardware supported) of existing algorithms. My problem is actually to use existing implementation of GOST algorithms (ccgost engine) in the Mozilla-based products. It seems that libnss already includes some support for these algorithms if their implementation is provided by PKCS#11 module. Of course, it has nothing to do with FIPS. In this case, if we would have to certify our solution it would be quite different certification body. Actually, in this case we don't need certification of this module at all (as well as ccgost engine is not certified by Russian authorities). We need open-source implementation which can work in the Mozilla and can be used for testing and debugging. Really, I suppose not all users need FIPS-certified version of cryptographic module. If server is FIPS-certified, client browser need to be interoperable, but non neccessary certified. Suppose that client is under another jurisdiction. It has its own certification bodies. Or even under same jurisdiction it is not neccessary that private person's browser has to be certified. Note that IBM does have an open source PKCS#11 which sits on top of OpenSSL, search for opencryptoki. That doesn't solve the FIPS problem though due to some details of it's design. It is interesting. I'd look into it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PKCS#11 wrapper around OpenSSL
On 2007.11.19 at 14:51:16 -0600, Steven Bade wrote: OpenCryptoki's Soft token based on openssl, was never intended to be a FIPS capable function, its simply intended to be an example for those who might wish to a) test PKCS#11 applications without having to have a card It is what I need. Really there is just two applications I really want to test - Firefox and Thunderbird. But it is interesting to know how fully PKCS#11 specification is implemented in OpenCryptoki. How much effort would be needed to add new profile for new cryptography algorithms, which are supported by recent OpenSSL, but, probably, never taken into account by authors of OpenCryptoki. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Dynamically loading engines into static build of OpenSSL
Static build of OpenSSL is still default one, even in 0.9.9 snapshots. However, engine dynamic is built into it, and makes it possible to load engine modules even into statically build applications. However, engine API of OpenSSL requires any engine to call some functions of libcrypto, such as ENGINE_set_id, ENGINE_set_init_function etc. If there is no shared libcrypto in the system (because it is compiled into application statically) these symbols cannod be resolved during loading and engine loading fail. This problem can be easily solved by exporting appropriate symbols from executable itself. On linux system only one linker option -Wl,-E should be added to the linking command line. On other systems solution can be more complicated, but ability to resolve symbols in the dlopened object from executable's symbol table exists everywhere. However, static build of OpenSSL doesn't add this option when linking openssl utility. It makes loading of any separately compiled engine into static build of openssl utility impossible. This seems to be inconsistent with existence of engine dynamic within this executable. Is it intentionally made decision or just omission? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES openssl/apps/ s_client.c openssl/crypt...
On 2007.10.26 at 14:06:37 +0200, Dr. Stephen Henson wrote: OpenSSL CVS Repository http://cvs.openssl.org/ Modified files: openssl CHANGES openssl/appss_client.c openssl/crypto/dsa dsa_pmeth.c openssl/crypto/evp evp.h pmeth_fn.c pmeth_lib.c openssl/crypto/hmac hm_pmeth.c openssl/crypto/rsa rsa_pmeth.c openssl/crypto/x509 x509type.c openssl/engines/ccgost e_gost_err.c e_gost_err.h gost2001_keyx.c gost94_keyx.c gost_ameth.c gost_crypt.c gost_ctl.c gost_eng.c gost_lcl.h gost_md.c gost_pmeth.c openssl/ssl d1_enc.c s3_clnt.c s3_lib.c s3_srvr.c ssl.h ssl_ciph.c ssl_err.c ssl_lib.c t1_enc.c t1_lib.c openssl/utillibeay.num But where is README.gost which should have been added into engines/ccgost directory? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1526] x86cpuid-elf.s cannot be compiled by Sun assembler on x86
On 2007.05.19 at 20:20:14 +0200, Andy Polyakov via RT wrote: In the revision 1.9 of file x86cpuid.pl there appeared block with some setne instructions: These instructions are translated under Solaris x86 into setneb assembler instruction which causes Illegal mnemonic error with /usr/ccs/bin/as Also, expression and (edx, ~(128)) is incorrectly translated into andl$18446744073441116159,%edx on 32-bit platform (should be andl $4026531839,%edx ) which causes as to complain about Value out of range. It looks like problem somewhere in the perlasm which incorrectly uses 64-bit operations. Well, incorrectly is not the word. Run 'perl -V' on machine in Incorrectly is very precise term. What the matter how perl is configured? I want to produce working assemble code, acceptable for my assembler. What if I'm cross-compiling for pure 32-bit target on pure 64 bit platform? Under incorrectly I mean that number of bits is taken from Perl compilation settings, not from CURRENT openssl compilation settings. I already have one test machine where 32 bit and 64 bit build is done simultaneously (it is Sparc, so it is not a problem now). Tomorrow I might have to set up 64-bit x86 solaris machine and do both 32 and 64 bit builds on it. I don't like idea that I have to build special version of Perl just to build OpenSSL. Next day perl authors stop shipping versions of Perl which don't allow not to use 64-bit integers even on pure 32-bit platforms (and I think they would be right). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ECDSA verify fails when digest is all zeros in 0.9.8e
On 2007.05.16 at 12:35:37 -0700, [EMAIL PROTECTED] wrote: I'm running OpenSSL 0.9.8e. If I set up an ECDSA verify with EC_KEY_new_by_curve_name(NID_X9_62_prime256v1) and call ECDSA_do_verify with dgst (first arg) an array of all zeros and dgst=1 (second arg), the call fails with error 16. As far as I understand, El Gamal signature scheme is not supposed to work when digest is all zeros. GOST signature algorithms (which are simular to DSA/ECDSA) treat this as special case, and GOST R 34.10 specify that if digest (interpreted as BIGNUM) is zero, it should be explicitely set to one. I always wondered why DSA doesn't have such fallback. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1525] ocsp.c doesn't compile for Windows target
ocsp.c (as of CVS state of May 15), revision 1.42 doesn't compile for Win32 target either with native MINGW32 or with Linux-hosted cross-compiler. Problem is that include file sys/select.h included on line 71, doesn't exist under Windows. BTW, this file uses macro OPENSSL_SYS_VMS, but doesn't include e_os2.h file, where this macro defined, and doesn't include ANY of openssl headers (which can include this file) before using of this macro. Following patch fixes these problems Index: ocsp.c === --- ocsp.c (revision 48) +++ ocsp.c (working copy) @@ -56,7 +56,7 @@ * */ #ifndef OPENSSL_NO_OCSP - +#include ../e_os2.h #include stdio.h #include string.h #define _XOPEN_SOURCE_EXTENDED 1 /* Or fd_set, select() and so on won't be @@ -67,7 +67,9 @@ # include time.h #else # include sys/time.h -# include sys/select.h +# ifndef OPENSSL_SYS_WINDOWS +# include sys/select.h +# endif #endif #include apps.h #include openssl/pem.h __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1516] [PATCH] apps/ocsp.c: Fix non-POSIX #include
On 2007.05.16 at 14:20:45 +0200, Stephen Henson via RT wrote: I've attempted to reuse the header files in s_client.c which have used similar select() functionality for quite a while. If this still doesn't work properly on all systems I'd suggest using something similar to s_client.c, s_server.c or speed.c Unfortunately, we don't have good test suite for OCSP, because nobody yet write draft for use GOST algorithms in OCSP and we do not test OCSP with our engines. So, we can only tell whether thing compiles and passes make test. This we would do next time when we import openssl repository in our one. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1526] x86cpuid-elf.s cannot be compiled by Sun assembler on x86
In the revision 1.9 of file x86cpuid.pl there appeared block with some setne instructions: -- xor(eax,eax); cpuid (); xor(eax,eax); cmp(ebx,0x756e6547); # Genu setne (LB(eax)); mov(ebp,eax); cmp(edx,0x49656e69); # ineI setne (LB(eax)); or (ebp,eax); cmp(ecx,0x6c65746e); # ntel setne (LB(eax)); or (ebp,eax); -- These instructions are translated under Solaris x86 into setneb assembler instruction which causes Illegal mnemonic error with /usr/ccs/bin/as Problem is reproduced on Solaris 8, Solaris 9 and Solaris 10 using GCC from www.sunfreeware.com which is configured to use Sun assembler and linker. (of course, patch to fix shared library initialization code applied for all our test machines) Also, expression and (edx, ~(128)) is incorrectly translated into andl$18446744073441116159,%edx on 32-bit platform (should be andl $4026531839,%edx ) which causes as to complain about Value out of range. It looks like problem somewhere in the perlasm which incorrectly uses 64-bit operations. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RE: RE: [openssl.org #1520] request for checking if -in and -out files are same
On 2007.04.20 at 11:57:35 -0700, David Schwartz wrote: On 2007.04.19 at 11:59:39 -0700, David Schwartz wrote: This is not nearly as simple as you might think. Are 'foo.txt' and 'Foo.txt' the same file? What about 'directory/file.txt' and 'symlink/file.txt'? I don't see how you can do this without making assumptions about the semantics of the filesystem involved. These assumptions will sometimes I don't see why these assumptions cannot be done at compile time. There exists few different filesystem semanctics: The filesystem is not known at compile time. No need to Unix one, DOS/Windows one, VMS (versioned) one. These are *OS* semantics. Linux, for example, supports filesystems with Unix semantics, DOS (case-insensitive) semantics, and versioned filesystems. Operating system kernel provides suitable level of isolation. For example, if we are running under Unix-style kernel, we can make stat calls on both files. And if both st_dev and st_ino fields of the resulting stat structures are same, we should consider files same. If DOS-style filesystem is mounted locally or remotely under Unix-style OS, we can rely on OS kernel for emulation of that much of Unix filesystem semantics. If we are running under DOS/Windows kernel, it is impossible to delete open file. So, if we open input file, we can than try to unlink output file, and if this fails, we should consider this fatal error (not neccessary files are same, but it is not safe to write to this file anyway) This is why I proposed my three-step approach 1. Check if input and output looks same, and if so report error. 2. Use special syntax if user really want to override input file with encrypted data 3. If this special syntax is used, take some steps to avoid leaving of unencrypted copies laying around. With this approach step 1 can be made robust enough with technique, described above. And it seems to me, that step 3 also can be implemented so it would work in 99.9% cases without digging into filesystem-specific things. Only dubious case is versioned file system (like VMS) mounted under Unix or DOS/Windows. It can just hide version mechanism from remote system. At least I don't remember tools which allow to manipulate versions of files from DOS DECnet client. But system which works in most often used cases and has clearly documented list of exceptions is better than no check at all. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RE: RE: RE: [openssl.org #1520] request for checking if -in and -out files are same
On 2007.04.25 at 01:55:23 -0700, David Schwartz wrote: For example, if we are running under Unix-style kernel, we can make stat calls on both files. And if both st_dev and st_ino fields of the resulting stat structures are same, we should consider files same. Why? Suppose the filesystem internally uses inodes larger than the st_ino field. Is it guaranteed that a matching st_dev and st_ino field means the files are the same? Where is this guarantee? Because these fields are intended for that very purpose we are using it. So, if some operating system doesn't do it this way, it may be considered bug in OS. Suppose the filesystem uses internal file versioning and the output file is a new version of the input. Will they have the same inodes or different ones? Do you know? I sure don't. (And I could think of reasons to do it either way.) This should be conceptually considered overwriting file and require same syntax. Any way, report an error is much better than silently corrupt the file trying to read unencrypted data and write encrypted data into it same time. Trying to keep the user from shooting himself in the foot risks shooting the user in the foot even when he did not ask. User can easily work around this check using IO redirection, so there is nothing wrong with too much strictness. If we are running under DOS/Windows kernel, it is impossible to delete open file. So, if we open input file, we can than try to unlink output file, and if this fails, we should consider this fatal error (not neccessary files are same, but it is not safe to write to this file anyway) Why unlink the output file if the user didn't ask us to do that? That could destroy version history the user wanted to keep. Yes, this is valid reason. It is not good to perform destructive operation just for checking purpose. But DOS/Windows systems since DOS 2.0 have mandatory file locking (and OpenSSL wouldn't work on DOS 2.0 and early anyway). So, if we open input file in deny write mode (User has asked us to read contents of this file hasn't he?) and then try open output file in write mode, we should get sharing violation. You can perhaps solve this problem by adding complexity, but the problem is that you are forcing the user to to anticipate your smart algorithm, how Why anticipate? It should be documented. I think that saving user from common mistake which can destroy data, deserves adding a bit of complexity which may require some workaround in rare cases. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RE: [openssl.org #1520] request for checking if -in and -out files are same
On 2007.04.19 at 11:59:39 -0700, David Schwartz wrote: This is not nearly as simple as you might think. Are 'foo.txt' and 'Foo.txt' the same file? What about 'directory/file.txt' and 'symlink/file.txt'? I don't see how you can do this without making assumptions about the semantics of the filesystem involved. These assumptions will sometimes I don't see why these assumptions cannot be done at compile time. There exists few different filesystem semanctics: Unix one, DOS/Windows one, VMS (versioned) one. OpenSSL already have sophisticated compile-time configuration system, which handle quite a few semantic differences between these platforms. So, it is possible to add this one. Problem is that somebody should write at least 3 different functions for different filesystem semantic, and test them thoroughly. I can contribute solution for Unix semantic which would work for all Unices I have experience with - Solaris, BSD and Linux. But I cannot be sure that it would work on all other unices supported by OpenSSL. There can be subtle API differences. Solution for Windows/DOS semantic is quite simple, because semantic of filesystem is simplier than Unix one. But I never wrote something for VMS. Consider a filesystem that keeps version history of a file until it's deleted. In this case, the user's request was to replace the unencrypted version of a file with the encrypted version, keeping the unencrypted version in history. Instead, you deleted the file's history. This seems to be wrong idea. If user wants to override unencrypted version with encrypted, he probably don't want unencrypted version to wander around. Otherwise he'd prefer to choose different name for encrypted file. Relatively bullet-proof solution is 1. Check if input and output files are same. Check should depend on filesystem semantics and take into account such things like symlinks, or UNC paths vs mounted volumes. 2. If so, refuse to work unless special command-line switch is specified. (Thus preventing accidential destroying of input file) Switch should look like -inplace and should be specified instead of -out filename. 3. If it is specified, overwrite unencrypted data with encrypted, taking care that no unencrypted copy left in history, or left in another place of filesystem if there were multiple hard links to input file. This covers two most frequent scennarios 1. User accidentialy typed same filenames. 2. User want protect his data, making sure that access to them is not possible without knowning passphrase. This behavoir is easily understandable by user. There is some tension between the desire to keep the 'openssl' command-line tool as an example of how to use the library and the desire to make it useful for real-world tasks. I personally think the former is considerably more important. Interactive prompting where not I think that former functionality is already lost. For me, it is simplier to write code from scratch using documentation, than study and understand code of openssl utility. It have to be refactored and commented before it could be used as examples. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Can openssl-0.9.8e be compiled and used under microsoft windows?
On 2007.03.09 at 09:09:44 +0800, ?? ?? wrote: Hi, I'm learning OpenSSL. Now, I have some questions about OpenSSL that is: 1. Can I compile openssl-0.9.8e directly under microsoft windows VC++ environment? How to do that? You can. But if you are not familiar with importing of BIG projects into Visual Studio enough to do it without asking questions, it is better not to do it. Better to compile with Visusal Studio command line compiler, as described in INSTALL.W32 file in the OpenSSL sources, and then import only headers and import libraries for OpenSSL dlls into your project. You can also compile with mingw32 and then use DLLs and import libraries, created with mingw with Visual studio. 2. Can I use openssl under microsoft windows mobile OS? Read the file INSTALL.WCE which is included into OpenSSL distribution. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Storing certificate in the engine
Hi, All! Does openssl have an API to load certificate from engine module. I've found ENGINE_load_private_key and ENGINE_load_public_key functions, but they both return EVP_PKEY, not X509. Problem is: There is hardware crypto device, say smartcard, which is able to store both private key and certificate. It is not essential, how certificate gets there - it may be loaded with separate tool. But if I want to use this smartcard to authenticate TLS connection I need to get sertificate from the card to pass to SSL_use_certificate. Obvoisly, device has such API, and I can access certificate from my engine, but how to pass it back to OpenSSL? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1483] Missing set of parameters for GOST 28147-89
We've found out that ccgost Engine doesn't support one of parameter sets
for GOST 28147-89 listed in RFC 4357. Actually S-Boxes for this
parameter set present in gost89.c, but are not linked to appropriate
OID. Attached patch fixes this problem and allows to use
Gost28147_89_TestParamSet (1.2.643.2.2.31.0) in the data encryption and
PBKDF function.
Index: gost_crypt.c
===
RCS file: /cvs-openssl/openssl/engines/ccgost/gost_crypt.c,v
retrieving revision 1.4
diff -u -r1.4 gost_crypt.c
--- gost_crypt.c8 Nov 2006 09:45:12 - 1.4
+++ gost_crypt.c9 Feb 2007 13:38:46 -
@@ -158,6 +158,7 @@
{NID_id_Gost28147_89_CryptoPro_B_ParamSet,Gost28147_CryptoProParamSetB,1},
{NID_id_Gost28147_89_CryptoPro_C_ParamSet,Gost28147_CryptoProParamSetC,1},
{NID_id_Gost28147_89_CryptoPro_D_ParamSet,Gost28147_CryptoProParamSetD,1},
+ {NID_id_Gost28147_89_TestParamSet,Gost28147_TestParamSet,1},
{NID_undef,NULL,0}
};
Re: ccgost on DOS
On 2007.01.05 at 17:11:50 +0100, Gisle Vanem wrote: Victor B. Wagner [EMAIL PROTECTED] wrote: It'll be interesting to see if ccgost engine can work at all under DOS - we never intended it to be used on the platform without dynamic loading, and OpenSSL doesn't support dynamic loading, available in DJGPP 2.04. gost_eng.c has some code inside OPENSSL_NO_DYNAMIC_ENGINE. Shouldn't that take care of targets w/o dlls/so? It should, but problem might be outside of engine itself. There is some subtle differences in engine initialization when engine is loaded dynamically using dynamic_path statement in openssl.cnf and when it is compiled statically. Last time I've checked static build, there was some problems with static version of initialization code. ccgost engine is currently only engine which adds new cryptography algorithms rather than providing new implementation of existing ones. It somehow happens, that new algorithms are added successfully into internal OpenSSL lists when engine is loaded dynamically, but something wrong happens (or something right doesn't happen) when just ENGINE_load_gost called. We haven't investigated problem thoroughly, because it has quite low priority in our priority list. We would be very grateful if somebody would help us to debug this case. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ccgost on DOS
On 2007.01.04 at 16:57:35 +0100, Gisle Vanem wrote: There is a problem building OpenSSL on a 8+3 filesystem like DOS due to the files: engines/ccgost/gost2001.c engines/ccgost/gost2001_keyx.c Sorry, when I named files I haven't thought than anybody still use real DOS with no long names support of some sort as development platform. Personally I use linux-hosted cross-compiler when I need to compile something for DJGPP platform. It'll be interesting to see if ccgost engine can work at all under DOS - we never intended it to be used on the platform without dynamic loading, and OpenSSL doesn't support dynamic loading, available in DJGPP 2.04. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Where to dig - strange errors in 0.9.9
On 2006.12.27 at 09:57:30 +0100, Andy Polyakov wrote: turns to be culprit, then note that there are two code pathes, sse2 and integer-only, the latter has separate squaring procedure, and we have to figure out which one fails... To switch off squaring procedure, comment out 'jz (label(bn_sqr_mont));' line #273. To switch off integer-only path altogether replace 'if (0)' around line #248 with 'if (1)'. You Commenting out line #273 fixes problem with following configuration (output of make report): Then it's integer-only squaring code path... Could you please double confirm that commenting out line #273 *alone* fixes the problem, i.e. line #248 still reads as 'if(0)'. I'll have alook at the code, but there might be need for test case, so could you provide sequence of commands to reproduce the problem [or program if it was one]. I'd try to provide minimal isolated test case for gost2001_do_sign function. Actual tests from our automated test suite - using openssl dgst -sign and openssl req might be a bit too complicated to debug. same result is achieved without no-sse2 option - fail without commenting line #273 and pass with it. ??? If you configure without no-sse2 and run on sse2 capable CPU, then line #273 shouldn't affect result. What CPU and OS was the test executed on? uname -a Linux lynx 2.6.16-athlon #1 Tue May 30 12:23:37 MSD 2006 i686 GNU/Linux cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Sempron(tm) 2500+ stepping: 1 cpu MHz : 1747.181 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow ts bogomips: 3498.37 It seems that there I've run tests with SSE2 support on non-sse2-capable CPU. I've repeated tests on PIV machine. Same build which produces errors on machine above passes tests on real P4 with: grep flags /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid cx16 xtpr We ought to fix something in our test farm and run sse2 automated tests on machine which can do SSE2. I for one *would* be interested *if* I had time. But otherwise you should know that it's very much appreciated, that you perform nightly builds on such variety of platforms and escalate problems as they pop up. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Where to dig - strange errors in 0.9.9
On 2006.12.27 at 09:57:30 +0100, Andy Polyakov wrote:
line #248 still reads as 'if(0)'. I'll have alook at the code, but there
might be need for test case, so could you provide sequence of commands
to reproduce the problem [or program if it was one].
Here small test programm is attached.
It should be compiled with few object files from ccgost engine.
gostectest: gostectest.o gost2001.o gost_sign.o gost_params.o e_gost_err.o
$(CC) -o $@ $(LDFLAGS) $+ -lcrypto
There is output from machine that works correctly:
Computing public key for private key
55441196065363246126355624130324183196576709222340016572108097750006097525544
Computed public key
X=FD21C21AB0DC84C154F3D218E9040BEE64FFF48BDFF814B232295B09D0DF72E4
Y=5026DEC9AC4F07061A2A01D7A2307E0659239A82A95862DF86041D1458E45049
Computed test signature
r=74E939C637A79A5B7E39DC15976BEFB324ACDB74E2FA8D434ABA0DA9EBF8DE8F
s=1F3DE74B3906D73920A5B332F5E4DEDF8FDAB3AC8DB157DCE780F3DB4F1A6B0B
Verifying test signature: 1
There is output which I get on machine where bug triggers on
Computing public key for private key
55441196065363246126355624130324183196576709222340016572108097750006097525544
Computed public key
X=B31388A5BC006BF9992CD0709F7DDE33D1542B737F1745F92CD14AD093A2B6D0
Y=646C27DAA450CFBFCB7BE199EAD69ABDE706C427DF0F6363CC3DC6CF714616E4
Computed test signature
r=33C0E8D12FE8444774CF4FDC692F71C4F5070F5228CC2493AB45BDCCA345F7C
s=477AE611BAFDBE639BD934CD4FB3E433BD059CC5BABB8E6A0E17C8C603A0A347
Verifying test signature: 0
Running this program essentially narrows problem down to
function gost2001_compute_public (although, same problem triggers on in _sign
and _verify too)
which consists of (error reporting removed)
int gost2001_compute_public(EC_KEY *ec)
{
const EC_GROUP *group = EC_KEY_get0_group(ec);
EC_POINT *pub_key=NULL;
const BIGNUM *priv_key=NULL;
BN_CTX *ctx=NULL;
int ok=0;
ctx=BN_CTX_new();
BN_CTX_start(ctx);
priv_key=EC_KEY_get0_private_key(ec);
pub_key = EC_POINT_new(group);
EC_POINT_mul(group,pub_key,priv_key,NULL,NULL,ctx);
EC_KEY_set_public_key(ec,pub_key);
ok = 256;
return ok;
}
It seems that there is nothing to fail except EC_POINT_mul function,
and only difference with native tests is usage of RFC 4357 EC_group.
/**
*ectest.c*
* Copyright (c) 2005-2006 Cryptocom LTD *
* This file is distributed under same license as OpenSSL *
**
*GOST R 34.10-2001 algorithm test program*
* Requires libcrypto from OpenSSL 0.9.8 for compilation *
**
**/
#include stdio.h
#include gost_lcl.h
#include gost_params.h
/* Test example from GOST 34.10 - 2001 */
/* Digest value */
unsigned char dgst[]={
0xE5, 0x3E, 0x04, 0x2B, 0x67, 0xE6, 0xEC, 0x67,
0x8E, 0x2E, 0x02, 0xB1, 0x2A, 0x03, 0x52, 0xCE,
0x1F, 0xC6, 0xEE, 0xE0, 0x52, 0x9C, 0xC0, 0x88,
0x11, 0x9A, 0xD8, 0x72, 0xB3, 0xC1, 0xFB, 0x2D};
/* Simulated random generation, which does always produce value from
* example */
int BN_rand_range(BIGNUM *k,BIGNUM *range) {
BN_hex2bn(k,77105C9B20BCD3122823C8CF6FCC7B956DE33814E95B7Fe64FED924594DCEAB3);
return 1;
}
/* Private key from example */
const char *privkey =55441196065363246126355624130324183196576709222340016572108097750006097525544;
int main(int argc, char **argv) {
EC_KEY *pkey;
BIGNUM *pk = NULL,*X=NULL,*Y=NULL;
const EC_POINT *pub_key;
const EC_GROUP *group;
int i;
DSA_SIG *sig;
pkey = EC_KEY_new();
/* Typically engine assigns NIDs to parameter sets dynamically upon
* registartion of OIDs, but we don't need full engine
* initialization here, so just assign arbitrary integers */
/* Set GOST test parameters */
fill_GOST2001_params(pkey,NID_id_GostR3410_2001_CryptoPro_A_ParamSet);
/* Set private key */
BN_dec2bn(pk,privkey);
EC_KEY_set_private_key(pkey,pk);
/* Compute public key. This is first test, that we correctly derive
* public key from private */
printf(Computing public key for private key %s\n,privkey);
gost2001_compute_public(pkey);
printf(Computed public key\n);
/* Output public key */
pub_key = EC_KEY_get0_public_key(pkey);
group = EC_KEY_get0_group(pkey);
X=BN_new(); Y=BN_new();
EC_POINT_get_affine_coordinates_GFp(group,pub_key,X,Y,NULL);
printf(\nX=);BN_print_fp(stdout,X);
printf(\nY=);BN_print_fp(stdout,Y);
printf(\n);
/* Compute signature of test digest */
sig=gost2001_do_sign(dgst,32,pkey);
printf(Computed test signature\nr=);
/* Output it */
BN_print_fp(stdout,sig-r);
printf(\ns=);
BN_print_fp(stdout,sig-s);
printf(\n);
/* And verify */
printf(Verifying test signature: %d\n,
Re: Where to dig - strange errors in 0.9.9
Now tests pass on my workstation. Next morning we'll see results on all other platforms. For reference. In order to test integer-only code paths on sse2 capable system you can run test suite with OPENSSL_ia32cap environment variable set to 0. In other words it's not necessary to have both machines in test farm nor reconfigure with no-sse2 in order to test it. A. It seems that there are a lot of environment variables which do interesting things with OpenSSL behavoir and can be used for testing purposes. I already use OPENSSL_DEBUG_MEMORY - turns on memory leak detecting OPENSSL_ENGINES - modifies default dynamically loadable engine location OPENSSL_CONF - modifies default config location. Now you describe OPENSSL_ia32cap There are also OPENSSL_sparcv9cap (which we probably ought to use, since we now have just one sparc machine in the test farm, and it is v9 since we do 64 builds on it) OPENSSL_DEBUG_LOCKING RANDFILE SSL_CIPHER SSLEAY_CONF (only in apps directory, seems to provide backward compatibility SSL_CERT_DIR SSL_CERT_FILE And most of these are not well documented __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Where to dig - strange errors in 0.9.9
I've encountered following problem yesterday our automated tests for ccgost engine begin to fail on all x86 platforms, but work flawlessly on SPARC and AMD64. Result is same on half of dozen different linux distributions, which use various 3.x or 4.x versions of gcc and three FreeBSD (4.x, 5.x and 6.x) and three Solaris x86 (8, 9 and 10). If I manually recompile with -O2 instead of -O3, problem persists. If I recompile with no-asm, problem goes away. Tests included in OpenSSL distrubution (invoked via make test) pass, so it seems that BIGNUM library as well as elliptic curve library should work. Probably this means that test suite is insufficient. However produced signatures are not verified by either reference build and new build, and signatures, produced by reference known good build are not verified correctly. Failing code - generation and verification of gost2001 signatures do not contain any special assembler code which can be affected with no-asm, but uses OpenSSL elliptic curve and bignum libraries extensively. I haven't yet investigated recent commits which can be related with assembler code. May be somebody, more experienced with OpenSSL assembler code and GCC optimisation can give me some clue, where to search for problem? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1444] Insufficient error reporting in openssl ca
I've encountered following problem in OpenSSL 0.9.8d on Linux platform: When partition where database of my CA resides is full, Openssl ca command fails without reporting cause of problem. Output looks like: openssl ca -config /var/www/openssl-ca//rsa/ca.conf -notext -batch -startdate 061225090853Z -days 365 -in /tmp/wwwreq1533.1167038595.req -out /tmp/wwwreq15 Using configuration from /var/www/openssl-ca//rsa/ca.conf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows organizationalUnitName:PRINTABLE:'OpenSSL team' localityName :PRINTABLE:'Moscow' commonName:PRINTABLE:'lynx.lan.cryptocom.ru' emailAddress :IA5STRING:'[EMAIL PROTECTED]' organizationName :PRINTABLE:'Cryptocom' countryName :PRINTABLE:'RU' Certificate is to be certified until Dec 25 09:23:16 2007 GMT (365 days) Write out database with 1 new entries == At this place CA command exits with exit code 01 but without any explanation of the cause of problem. Files index.txt.old and index.txt.new are left in the ca directory. I haven't yet traced problem down to exact source code line. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1440] [PATCH] Incorrect shared build of ccgost engine
On 2006.12.22 at 10:21:41 +0100, Nils Larsch via RT wrote: patch applied, please test a recent snapshot. Our tests passed, at least on Linux platform. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1440] [PATCH] Incorrect shared build of ccgost engine
File gost_eng.c contains macros IMPLEMENT_DYNAMIG_BIND_FN and IMPLEMENT_DYNAMIC_CHECK_FN, which should be expanded when engine is compiled as shared library, i.e. during default build of OpenSSL after ./config shared However, these macros are under #ifdef DYNAMIC_ENGINE_SUPPORT, and this macro is never defined during default shared build of OpenSSL. As a result, compiled engine shared library cannot be loaded into OpenSSL. Simular problem exist in gmp engine. All other engines, included into OpenSSL distribution use #ifndef OPENSSL_NO_DYNAMIC_ENGINE to hide bind function during static build, so default shared build creates engines which at least can be loaded and display their capabilities by openssl engine -c engine_name (more functionality cannot be tested without actual hardware). Also I've discovered that ccgost engine contains uncommented debug output. Attached patch fixes these problems. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
What means ENGINE_DYNAMIC_SUPPORT macro?
Recently, (08-Nov) #ifdef ENGINE_DYNAMIC_SUPPORT was added around IMPLEMENT_DYNAMIC_BIND function in engines/ccgost/gost_eng.c (in CVS HEAD) By default, this macro is not enabled, even if shared option is passed to configure. This renders compiled shared library unusable, at least without proper installation of freshly compiled OpenSSL. Why it is needed? What is wrong with having bind_engine function in each engine when they are compiled as shared libraries? I can understand that it might lead to problems when more than one engine is compiled statically. But there is NO_DYNAMIC_ENGINE macro for such case. cvs log doesn't tell anything but Fix various warnings Interesting, that specifying -DENGINE_DYNAMIC_SUPPORT in the ./Configure command line breaks everything too. genpkey command reports unsupported algorithm with same config file which works if I just remove #ifdef from ccgost engine. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: What means ENGINE_DYNAMIC_SUPPORT macro?
On 2006.11.14 at 10:59:41 +, Ben Laurie wrote: cvs log doesn't tell anything but Fix various warnings If you compile with -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Werror then you'll see the errors I'm fixing. If people always did that before submitting code, then it wouldn't get broken by fixes :-) Problem is that you probably don't test all the configuration variations. And we don't either. First of all, I suppose no one now except DJGPP users uses static builds. We compile our code with -Wall. And there was only one warning remained, in gost_ameth.c which you really fixed by introducing temporary variable void *_pval. But we by default use ./config shared zlib (Although zlib support should not affect current ccgost code) Second, there are pieces of code not covered by tests. I rather wouldn't touch code I don't understand fully, if I don't have unit test suite to ensure that it would work after my modification. May be we should start from adding test suite for engine. We have some collection of test scripts for PKI and SMIME operations which sometimes catch problems missed by standard make test. May be someone would integrate it into HEAD? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Windows build fail of openssl-SNAP-20061114
On 2006.11.15 at 15:47:40 +1000, Simon McMahon wrote: Hi, Using MSVC++ 6.0 I followed all the instructions in install.w32 including: perl util\mkdef.pl crypto ssl update to get the things not having numbers assigned error to go away. Then: ms\do_ms worked ok. Then: nmake -f ms\ntdll.mak built the .c files but failed on the link: rc /fotmp32dll\libeay32.res /d CRYPTO ms\version32.rc link /nologo /subsystem:console /opt:ref /dll /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\DOCUME~1\simonm\LOCALS~1\Temp\nma02892. LIBEAY32.def : error LNK2001: unresolved external symbol IMPLEMENT_ASN1_SET_OF out32dll\libeay32.lib : fatal error LNK1120: 1 unresolved externals LINK : fatal error LNK1141: failure during build of exports file NMAKE : fatal error U1077: 'link' : return code '0x475' Stop. I went back to openssl-0.9.8d and it built OK for me. Any suggestions? Manually edit libeay.num file after running mkdef.pl crypto ssl update and just remove line containing IMPLEMENT_ASN1_SET_OF. It is not a function, it is a macro, but for some reason I've not found time to investigate, mkdef consider it a function. It is not a problem for those who wish just build OpenSSL. It is problem for people who wish to add new functions and make mkdef.pl see them. Really, someone who have deep understanding of mkdef.pl work should check header files, find out what's wrong with IMPLEMENT_ASN1_SET_OF macro - why mkdef consider it a function, but handles other such macros (there are lot of them) appropriately, and fix either header or mkdef.pl __ 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]
What is old_priv_encode field in evp_pkey_asn1_method_st?
I've found that some tests for ccgost engine segfaults on Solaris/Sparc. Investigation shows that segfault happen wnen i2d_PrivateKey function calls function, pointed by old_priv_encode field in ASN1_METHOD structure This field is commented in the crypto/asn1/asn1/asn1_locl.h as /* Legacy functions for old PEM */ but it is not initialized to NULL in EVP_PKEY_ASN1_new, and no function to set this field is provided. On most platforms it doesn't matter for some unknown reason (may be OPENSSL_malloc initializes memory to zero, but I don't understand why) but sometimes it does result in dereferencing uninitialized memory Fixing this problem is simple - just initialize these pointers to zero in EVP_PKEY_ASN1_new __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1421] EVP_PKEY_asn1_new() improperly initializes structure
In the current OpenSSL 0.9.9 CVS EVP_PKEY_asn1_new() function doesn't initialize fields old_priv_encode and old_priv_decode in the EVP_PKEY_ASN1_METHOD structure. This causes segfaults and bus error on Solaris/Sparc due to call to bogus pointers as functions. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Mingw32 and .def files in 0.9.9-dev
I've encountered following problem with current CVS state of Openssl-dev: When I build OpenSSL with MingW32 cross-compiler on Linux and run make test on various vversions of Windows, on Win2003 server and WinXP it works, but on Windows 2000 attempt to run OpenSSL.exe or any of test programs in test directory bring ups a dialog window telling that DLL library crypto32 is not found. And crypto32.dll is successfully build and presents here. Problem was traced down to .def file generated with util/mkdef.pl If it lists just library name library its not found. If it lists name with extension, everything works. I've thought that problem is with filename case, but uppercasing library name didn't work. I wonder how it worked previously with DLLS compiled with mingw.sh. Or it is binutils incompatibility? I use binutils 2.15.94, quite old. Patch that fixes this problem follows: Index: util/mkdef.pl === RCS file: /cvs-openssl/openssl/util/mkdef.pl,v retrieving revision 1.102 diff -u -r1.102 mkdef.pl --- util/mkdef.pl 9 Jun 2006 15:44:59 - 1.102 +++ util/mkdef.pl 26 Oct 2006 14:43:28 - @@ -1217,7 +1217,7 @@ ; Definition file for the DLL version of the $name library from OpenSSL ; -LIBRARY $libname $liboptions +LIBRARY $libname.dll $liboptions DESCRIPTION '$description' __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
On 2006.10.25 at 13:36:11 +0200, Andy Polyakov wrote: So we have to decide on unified naming convention for both MSC and mingw. Suggestion is to embed version number into name, but remaining questions are: - do we still stick to 8.3 naming? Really I think that time to forget 8.3 naming is already here for five years or so. I suspect that 32-bit openssl applications won't work on Win16 with Win32s anyway. And it is only case where 8.3 matters for 32bit DLLs. As to source file naming, I don't think 8.3 is neccessary even if DJGPP target is supported. It is easier to use cross-compiler or use Windows platform for compiling. - do we want to denote dll origin in its name? Last question means that crypto099 doesn't really give you a hint that it's an OpenSSL library. A. This is good reason. eay suffix did exactly so. But I'm not sure that it is strictly neccessary. At least origin is denoted in VERSION_INFO __ 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]
Results of testing (Re: [CVS] OpenSSL: openssl/ Configure Makefile.org Makefile.shared openssl...)
I've tested current CVS state of OpenSSL with mingw32-cross compiler and found out following: 1. Everything compiles without error 2. make rehash is omitted during build When testing on real Win32 platform with MSYS installed 1. make rehash is omitted again, but shouldn't. 2. attempt to start very first test (destest.exe) causes dialog window to popup saying Application cannot start becouse crypto32.dll is not found. Just renaming created dlls solves the problem. This is quite explainable, because build creates crypto-0.9.8.dll, but def file contains section LIBRARYcrypto32 So, we have either to create crypto32.dll and ssl32 dll instead of crypto-0.9.8.dll and ssl-0.9.8.dll, or modify mkdef.pl so it would put real dll names into the LIBRARY section of .def file. Note that if dll name contain hyphen or dots, it should be quoted and include extension. I.e. section should look like LIBRARY crypto-0.9.8.dll Probably, if we are going to maintain binary compatibility with MSVC build, changing dll name to crypto32.dll and ssl32.dll is better. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
On 2006.10.23 at 11:21:26 +0200, Andy Polyakov wrote: Care to figure out and tell how to do it with windres and ld? I mean It is quite simple. When I finish solving current dll name problem (I.e. manage to do make and make test without manual dll renaming) i'll do this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Results of testing (Re: [CVS] OpenSSL: openssl/ Configure Makefile.org Makefile.shared openssl...)
On 2006.10.23 at 13:35:39 +0400, Victor B. Wagner wrote: I've tested current CVS state of OpenSSL with mingw32-cross compiler and found out following: 1. Everything compiles without error 2. make rehash is omitted during build When testing on real Win32 platform with MSYS installed 1. make rehash is omitted again, but shouldn't. 2. attempt to start very first test (destest.exe) causes dialog window to popup saying Application cannot start becouse crypto32.dll is not found. Just renaming created dlls solves the problem. This is quite explainable, because build creates crypto-0.9.8.dll, but def file contains section LIBRARYcrypto32 So, we have either to create crypto32.dll and ssl32 dll instead of crypto-0.9.8.dll and ssl-0.9.8.dll, or modify mkdef.pl so it would put real dll names into the LIBRARY section of .def file. Note that if dll name contain hyphen or dots, it should be quoted and include extension. I.e. section should look like LIBRARY crypto-0.9.8.dll Probably, if we are going to maintain binary compatibility with MSVC build, changing dll name to crypto32.dll and ssl32.dll is better. Now, I'm developed a patch which solves this problem. With this patch current CVS state of OpenSSL compiles cleanly with either cross-compiler and native Mingw32 compiler and make test runs. Rationale of the patch - make names of created DLLs same that it is written in the .def file by util/mkdef.pl Index: Makefile.shared === RCS file: /cvs-openssl/openssl/Makefile.shared,v retrieving revision 1.59 diff -u -r1.59 Makefile.shared --- Makefile.shared 23 Oct 2006 07:30:18 - 1.59 +++ Makefile.shared 23 Oct 2006 11:00:18 - @@ -260,14 +260,15 @@ link_a.cygwin: @ $(CALC_VERSIONS); \ INHIBIT_SYMLINKS=yes; \ + SHLIB_SOVER=-$(LIBVERSION); \ SHLIB=cyg$(LIBNAME); def=; \ if expr $(PLATFORM) : 'mingw' /dev/null; then \ SHLIB=$(LIBNAME); \ def=$(LIBNAME).def; \ + SHLIB_SOVER=32; \ $(PERL) util/mkdef.pl 32 $(LIBNAME) $$def; \ fi; \ SHLIB_SUFFIX=.dll; \ - SHLIB_SOVER=-$(LIBVERSION); \ ALLSYMSFLAGS='-Wl,--whole-archive'; \ NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \ base=; [ $(LIBNAME) = crypto ] base=-Wl,--image-base,0x6300; \ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
On 2006.10.23 at 11:21:26 +0200, Andy Polyakov wrote:
But there is another problem which Unix-style Configure doesn't solve
now:
dll can include VERSION_INFO resource. Now Configure creates .rc file
only if IsMK1MF is set. I think that if we want to have native Win32
dll, we should include this resource, even if build environment is
completely Unix-style.
Care to figure out and tell how to do it with windres and ld? I mean
I've never done this... This one probably doesn't have to be mingw
specific, cygwin people [Corinna?] might appreciate it just as much. A.
Here is preliminary patch to generate resource sections for DLLs.
I call it preliminary, because:
1. DLL name issue is not permanentely settled. MSVC build creates
libeay32.dll and ssleay32.dll, and Mingw build crypto32.dll and
ssl32.dll. Patch includes code to support this difference, but I'm
not absolutely sure it belongs there.
2. It is good idea to generate VERSION_INFO resource not only for DLLs,
but also for executable files. At least for those which are considered
part of production shipment (i.e. openssl.exe). Patch doesn't include
this now
3. Resources for engine dlls are not generated.
Index: Makefile.org
===
RCS file: /cvs-openssl/openssl/Makefile.org,v
retrieving revision 1.278
diff -u -r1.278 Makefile.org
--- Makefile.org21 Oct 2006 16:28:03 - 1.278
+++ Makefile.org23 Oct 2006 12:17:00 -
@@ -67,6 +67,7 @@
AR=ar $(ARFLAGS) r
RANLIB= ranlib
NM= nm
+WINDRES=windres
PERL= perl
TAR= tar
TARFLAGS= --no-recursion
@@ -175,7 +176,7 @@
BUILDENV= PLATFORM='${PLATFORM}' PROCESSOR='${PROCESSOR}' \
CC='${CC}' CFLAG='${CFLAG}' \
AS='${CC}' ASFLAG='${CFLAG} -c' \
- AR='${AR}' NM='${NM}' RANLIB='${RANLIB}'\
+ AR='${AR}' NM='${NM}' RANLIB='${RANLIB}' WINDRES='${WINDRES}'
\
PERL='${PERL}' \
SDIRS='${SDIRS}' LIBRPATH='${INSTALLTOP}/lib' \
INSTALL_PREFIX='${INSTALL_PREFIX}' \
Index: Makefile.shared
===
RCS file: /cvs-openssl/openssl/Makefile.shared,v
retrieving revision 1.59
diff -u -r1.59 Makefile.shared
--- Makefile.shared 23 Oct 2006 07:30:18 - 1.59
+++ Makefile.shared 23 Oct 2006 12:17:00 -
@@ -16,6 +16,8 @@
NM=nm
+WINDRES=windres
+
# LIBNAME contains just the name of the library, without prefix (lib
# on Unix, cyg for certain forms under Cygwin...) or suffix (.a, .so,
# .dll, ...). This one MUST have a value when using this makefile to
@@ -260,18 +262,21 @@
link_a.cygwin:
@ $(CALC_VERSIONS); \
INHIBIT_SYMLINKS=yes; \
+ SHLIB_SOVER=-$(LIBVERSION); \
SHLIB=cyg$(LIBNAME); def=; \
if expr $(PLATFORM) : 'mingw' /dev/null; then \
SHLIB=$(LIBNAME); \
def=$(LIBNAME).def; \
+ res=$${SHLIB}_rc.o\
+ SHLIB_SOVER=32; \
+ $(WINDRES) -D`echo ${LIBNAME}|tr a-z A-Z` -o $$res
ms/version32.rc;\
$(PERL) util/mkdef.pl 32 $(LIBNAME) $$def; \
fi; \
SHLIB_SUFFIX=.dll; \
- SHLIB_SOVER=-$(LIBVERSION); \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
base=; [ $(LIBNAME) = crypto ] base=-Wl,--image-base,0x6300; \
- SHAREDFLAGS=$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base -Wl,-Bsymbolic
-Wl,--out-implib,lib$(LIBNAME).dll.a $$def; \
+ SHAREDFLAGS=$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base -Wl,-Bsymbolic
-Wl,--out-implib,lib$(LIBNAME).dll.a $$def $$res; \
[ -f apps/$$SHLIB$$SHLIB_SUFFIX ] rm apps/$$SHLIB$$SHLIB_SUFFIX; \
[ -f test/$$SHLIB$$SHLIB_SUFFIX ] rm test/$$SHLIB$$SHLIB_SUFFIX; \
$(LINK_SO_A) || exit 1; \
Index: Configure
===
RCS file: /cvs-openssl/openssl/Configure,v
retrieving revision 1.544
diff -u -r1.544 Configure
--- Configure 23 Oct 2006 07:38:27 - 1.544
+++ Configure 23 Oct 2006 12:17:00 -
@@ -1321,6 +1321,7 @@
s/^AR=\s*/AR= \$\(CROSS_COMPILE_PREFIX\)/;
s/^NM=\s*/NM= \$\(CROSS_COMPILE_PREFIX\)/;
s/^RANLIB=\s*/RANLIB= \$\(CROSS_COMPILE_PREFIX\)/;
+ s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE_PREFIX\)/;
}
else{
s/^CC=.*$/CC= $cc/;
@@ -1616,7 +1617,7 @@
}
# create the ms/version32.rc file if needed
-if ($IsMK1MF) {
+if ($IsMK1MF || $target eq mingw ) {
my ($v1, $v2, $v3, $v4);
if ($version_num =~
/(^[0-9a-f]{1})([0-9a-f]{2})([0-9a-f]{2})([0-9a-f]{2})/i) {
$v1=hex $1;
@@ -1624,6 +1625,8 @@
$v3=hex $3;
$v4=hex $4;
}
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
On 2006.10.23 at 13:54:55 +0100, Martin Simmons wrote: 1. DLL name issue is not permanentely settled. MSVC build creates libeay32.dll and ssleay32.dll, and Mingw build crypto32.dll and ssl32.dll. Patch includes code to support this difference, but I'm not absolutely sure it belongs there. BTW, what is the meaning of 32 in the names? Theoretically there can be 16-bit versions of the DLLS for Win16. In future, when Mingw builds would support x86_64 architecture, there sould be 64-bit versions. (Now, I suppose only MSVC builds can generate 64-bit dlls) And they have to coexist on the same machine. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
On 2006.10.20 at 08:44:14 +0200, Andy Polyakov wrote: Before I making too much modifications, Have anyone succeeded in doing so? I do it routinely. 1. Modify Configure script, adding target mingw-cross (this all should go into one line) mingw-cross, i586-mingw32msvc-gcc:-mno-cygwin -DL_ENDIAN Can you test if './Configure mingw' followed by 'make CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib' works? I mean It seems to work. Although when I start make test on real win32 system after doing make on linux system, it complains about certificate rehashing skipped, openssl program not available. I've tried with 0.9.8 I'd repeat this with current development tree. question is if it's possible to achieve the goal without adding extra target... First of all, nm program name should be overriden to, but openssl Makefile.shared do not define variable for nm, and hardcodes program name instead. Now make complains about file format not recognized multiple times. Second problem with cross build is that make does certificate rehash, using freshly compiled c_rehash program. It doesn't lead to make failure, but it would be nice to be able to redefine c_rehash as well, and use one from host system OpenSSL during build stage (of course, for cross-builds only). If people are interesting, I can publish somewhere results of nightly build on our test farm. Now we have following platforms 1. Various Linux distributions 2. FreeBSD 4.x, 5.x and 6.x on i386, FreeBSD 6.x on AMD 64 3. Solaris x86 8, 9 and 10 4. Solaris Sparc 10 (both 32-bit and 64-bit build) 5. Mingw build on Win32 system using Cygwin compiler and ActiveState Perl. We can add build with real mingw compiler on Win32 and linux-hosted build with mingw compiler. 2. Modify Makefile shared so it would call util/mkdef.pl script. and add generated .def file to linking command Note that DEF file should contain correct DLL name, not just crypteay32 mingw32 builds libcrypto-0.9.8.dll, and this name should exactly appear in the .def file If it's reusable on real mingw and cygwin, then it makes sense to throw it in. A. It is applicable at least to real mingw. I don't remember exact circumstances, but when we've switched from 0.9.8a to 0.9.8b we have problems with deploying mingw32 build (which is used in production environment now) and problem was solved by using proper .def files. It is applicable for both native and linux-hosted builds (although we never tested mingw build with cygwin compiler in production environment). It was related to changes in DSO_WIN32 (which began to find engine modules correctly in this release). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
On 2006.10.20 at 12:05:11 +0400, Victor B. Wagner wrote: Can you test if './Configure mingw' followed by 'make CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib' works? I mean It seems to work. Although when I start make test on real win32 system Oh, it was with our modified Configure. When I've restarted build with unmodified 0.9.9 source tree, I got problem with line 933 of Configure script: $IsMK1MF=1 if ($target eq mingw $^O ne cygwin !is_msys()); Of course it doesn't recongnize that it should not set IsMK1MF to 1 when doing Linux-hosted build. Same problem occurs when doing build with Cygwin compiler, but non-cygwin (i.e. ActiveState) Perl. And we use this setup on our win32 test machine, so this line was patched in Configure script too. We have replaced this line in our patched Configure with my @MK1MF_Builds=qw(VC-WIN64I VC-WIN64A VC-NT VC-CE VC-WIN32 BC-32 OS2-EMX netware-clib netware-libc netware-libc-bsdsock); sMK1MF=scalar grep /^$target$/,@MK1MF_Builds; It is not perfect to, because it assumes that if one uses mingw32 target, there is always some Unix emulation environment (i.e. cygwin, msys or real Unix in case of cross-builds). Function is_msys() as it written, never give correct result in our msys environments. If I run msys rxvt terminal emulator, TERM is xterm, if I start msys shell in console window, it is for some reason cygwin. Really, I think checking for existense of TERM variable is enough to determine that there is some Unix emulation environment. At least, it can be documented, and user who wants MK1MF build might explicitely unset this variable during Configure stage without any harm. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
On 2006.10.20 at 10:56:35 +0200, Andy Polyakov wrote: It is not perfect to, because it assumes that if one uses mingw32 target, there is always some Unix emulation environment (i.e. cygwin, msys or real Unix in case of cross-builds). As implied earlier I'd actually prefer this, i.e. mingw build to *require* Unix emulation environment. Is it really unreasonable? In I think it is reasonable. Unless it would break some non-gcc build (i.e Visual Studio, Borland or some netware one). other words I'd simply scrap $IsMK1MF=1 if ($target eq mingw $^O ne cygwin !is_msys()); line for good. A. Now, some further info. Next problem I've encountered building current CVS state of 0.9.9 was error in e_os.h ws2tcpip.h is not compatible with winsock.h. It was fixed by removal of #include ws2tcpip.h from mentioned file. I'm not an expert on Win32 tcpip history and cannot tell whether it is problem of my mingw32 runtime headers or something also. Next problem was dereferencing pointer to incomplete type in line 728 of b_sock.c. It seems that symbol AF_INET6 is somehow declared (may be cross-compiler picks some native header), but appropriate structures are not defined. I've temporary solved this problem by replacing #if defined(OPENSSL_SYS_BEOS_BONE) /* BONE's IP6 support is incomplete */ #undef AF_INET6 #endif with #if defined(OPENSSL_SYS_BEOS_BONE) || defined(_WIN32) /* BONE's IP6 support is incomplete */ #undef AF_INET6 #endif in line 90 of crypto/bio/b_sock.c. After this static build succeeds. If I attempt to do ./Configure mingw shared and then make CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib\ NM=i586-mingw32msvc-nm (i've patched Makefile.shared to support NM overriding), I get following results: shared library cryptoeay-0.9.8.dll (why not 0.9.9?) is created, but it exports no symbols. So build of ssleay-0.9.8.dll fails due to multiple unresolved symbols. This is why proper .def file is needed. I've not tried ./Configure mingw shared zlib, because I don't have win32 zlib develpment files on machine where I'm doing my experiments. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
On 2006.10.20 at 11:49:39 +0200, Corinna Vinschen wrote: I'm not an expert on Win32 tcpip history and cannot tell whether it is problem of my mingw32 runtime headers or something also. ws2tcpip.h is incompatible with winsock.h since winsock.h is only meant for supporting old Winsock 1.1 applications. A modern Winsock 2 application should include winsock2.h and ws2tcpip.h. So, it is line 455 in e_os.h which is offending, not line 278? And here's another problem. The functions getaddrinfo, getnameinfo and freeaddrinfo are only exported by ws2_32.dll beginning with Windows XP. There's an earlier implementation for Windows 2000 which is exported by a DLL called wship6.dll. There's no v6 for 9x or NT4. Consequentially, on native Windows (not Cygwin) the functions should not be linked against, but instead corresponding function pointers should be loaded at runtime from either ws2_32.dll or wship6.dll using LoadLibrary/GetProcAddress. So, use IPV6 on native windows requires considerable changes anyway? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
On 2006.10.20 at 13:33:37 +0400, Victor B. Wagner wrote:
NM=i586-mingw32msvc-nm
(i've patched Makefile.shared to support NM overriding),
I get following results:
shared library cryptoeay-0.9.8.dll (why not 0.9.9?) is created,
but it exports no symbols. So build of ssleay-0.9.8.dll fails due to
multiple unresolved symbols. This is why proper .def file is needed.
I found way to live without proper .def file.
diff -r1.541 Configure
478c478
mingw, gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-mno-cygwin -shared:.dll.a,
---
mingw, gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG
${x86_gcc_des} ${x86_gcc_opts}
EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-Wl,--export-all -mno-cygwin -shared:.dll.a,
With this option added, shared build completes successfully.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
On 2006.10.20 at 13:01:01 +0200, Corinna Vinschen wrote: So, use IPV6 on native windows requires considerable changes anyway? I wouldn't say it's considerable. Just a tweak to the loading of getaddrinfo/freeaddrinfo in crypto/bio/b_sock.c, AFAICS. Implementing of dynamic loading by hand is tricky thing anyway. One have to declare function pointers and provide code which would fill them with correct value. And this code should be clever enough to find appropriate DLL (provided that most Windows systems out there have both). This code should be somehow called. And since we have to include ws2tcpip.h anyway for structure definitions, we should provide way to avoid name clash between our pointers and functions, declared in that file. After examining few test Win2000 systems around there, I'we found that they all have ws2_32.dll. It was included in some ServicePack. Moreover, mingw runtime includes libws2_32.a (equivalent of MS ws2_32.lib), and not libwship6.a. So it seems that it is relatively harmless to link with -lws2_32. May be that for NT4 and 9x it would be required to make separate binary distribution with IPV6 disabled. But I don't think that it is worth effort to find out whether IPV6 is available at runtime. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
Now I've managed to cross-compile current CVS tree with
Mingw32 crosscompiler both in static and shared version.
Following changes are needed to the source tree:
1. Configure
1.1. Add -Wl,--export-all to the shared library linker command line
1.2. Add -lws2_32 to list of libraries to link IPV6 stuff (not
compatible with old versions of windows, but my MingW32 runtime
doesn't have libwship6.a). I've found that on our test Win2000
system WINNT/System32 folder contains ws2_32.dll which was brought
by some service pack
1.3. Remove setting of IsMK1MF variable to 1 in case of mingw build
(as suggested by Andy Polyakov above in the thread)
2. Makefile.shared
Define NM variable to hold name of nm program (which also differs
from just nm when cross-compiling)
Replace explicit call to nm by reference to this variable.
3. ssl/ssl_sess.c
Move #include ssl_locl.h above
#include openssl/rand.h
because ssl_locl.h includes e_os.h, which includes winsock2 and
ws2tcp.h, and rand.h includes windows.h, which includes winsock.h if
winsock2.h wasn't previously included
4. crypto/bio/b_sock.c
add #include e_os.h to provide neccessary definitions for IPV6
stuff
5. engines/ccgost/gost_eng.c
Remove __declspec(dllexport) before IMPLEMENT_DYNAMIC_CHECK_FN
and IMPLEMENT_DYNAMIC_BIND_FN macros. These macros now include
OPENSSL_EXPORT which expands to appropriate declspec under Win32.
Index: Configure
===
RCS file: /cvs-openssl/openssl/Configure,v
retrieving revision 1.541
diff -u -r1.541 Configure
--- Configure 17 Oct 2006 13:38:08 - 1.541
+++ Configure 20 Oct 2006 11:37:38 -
@@ -475,7 +475,7 @@
BC-32,bcc32WIN32::BN_LLONG DES_PTR RC4_INDEX
EXPORT_VAR_AS_FN:${no_asm}:win32,
# MinGW
-mingw, gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-mno-cygwin -shared:.dll.a,
+mingw, gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lws2_32 -lwsock32 -lgdi32:BN_LLONG
${x86_gcc_des} ${x86_gcc_opts}
EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-Wl,--export-all -mno-cygwin -shared:.dll.a,
# UWIN
UWIN, cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${no_asm}:win32,
@@ -930,7 +930,6 @@
my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds;
-$IsMK1MF=1 if ($target eq mingw $^O ne cygwin !is_msys());
$exe_ext=.exe if ($target eq Cygwin || $target eq DJGPP || $target eq
mingw);
$exe_ext=.pm if ($target =~ /vos/);
@@ -1832,10 +1831,4 @@
return $errorcnt;
}
-# Attempt to detect MSYS environment
-sub is_msys
- {
- return 1 if (exists $ENV{TERM} $ENV{TERM} eq msys);
- return 0;
- }
Index: Makefile.shared
===
RCS file: /cvs-openssl/openssl/Makefile.shared,v
retrieving revision 1.57
diff -u -r1.57 Makefile.shared
--- Makefile.shared 20 May 2006 08:52:34 - 1.57
+++ Makefile.shared 20 Oct 2006 11:37:38 -
@@ -7,6 +7,7 @@
# CC contains the current compiler. This one MUST be defined
CC=cc
+NM=nm
CFLAGS=$(CFLAG)
# LDFLAGS contains flags to be used when temporary object files (when building
# shared libraries) are created, or when an application is linked.
@@ -101,7 +102,7 @@
LIBDEPS=$${LIBDEPS:-$(LIBDEPS)}; \
SHAREDCMD=$${SHAREDCMD:-$(CC)}; \
SHAREDFLAGS=$${SHAREDFLAGS:-$(CFLAGS) $(SHARED_LDFLAGS)}; \
-nm -Pg $$SHOBJECTS | grep ' [BDT] ' | cut -f1 -d' ' lib$(LIBNAME).exp; \
+$(NM) -Pg $$SHOBJECTS | grep ' [BDT] ' | cut -f1 -d' '
lib$(LIBNAME).exp; \
LIBPATH=`for x in $$LIBDEPS; do if echo $$x | grep '^ *-L' /dev/null
21; then echo $$x | sed -e 's/^ *-L//'; fi; done | uniq`; \
LIBPATH=`echo $$LIBPATH | sed -e 's/ /:/g'`; \
LD_LIBRARY_PATH=$$LIBPATH:$$LD_LIBRARY_PATH \
Index: crypto/bio/b_sock.c
===
RCS file: /cvs-openssl/openssl/crypto/bio/b_sock.c,v
retrieving revision 1.46
diff -u -r1.46 b_sock.c
--- crypto/bio/b_sock.c 11 Apr 2006 21:34:18 - 1.46
+++ crypto/bio/b_sock.c 20 Oct 2006 11:37:38 -
@@ -60,6 +60,7 @@
#include stdlib.h
#include errno.h
#define USE_SOCKETS
+#include e_os.h
#include cryptlib.h
#include openssl/bio.h
#if defined(OPENSSL_SYS_NETWARE) defined(NETWARE_BSDSOCK)
Index: ssl/ssl_sess.c
===
RCS file: /cvs-openssl/openssl/ssl/ssl_sess.c,v
retrieving revision 1.62
diff -u -r1.62 ssl_sess.c
--- ssl/ssl_sess.c
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
On 2006.10.20 at 15:41:35 +0400, Victor B. Wagner wrote:
I was to quick to send previous patch. Two additional changes
are required: changing order of
#include openssl/engine.h
and #include apps.h in apps/apps.c
and order of openssl/rand.h and ../e_os.h in test/randtest.c
Updated patch attached.
Index: Configure
===
RCS file: /cvs-openssl/openssl/Configure,v
retrieving revision 1.541
diff -u -r1.541 Configure
--- Configure 17 Oct 2006 13:38:08 - 1.541
+++ Configure 20 Oct 2006 11:49:31 -
@@ -475,7 +475,7 @@
BC-32,bcc32WIN32::BN_LLONG DES_PTR RC4_INDEX
EXPORT_VAR_AS_FN:${no_asm}:win32,
# MinGW
-mingw, gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-mno-cygwin -shared:.dll.a,
+mingw, gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lws2_32 -lwsock32 -lgdi32:BN_LLONG
${x86_gcc_des} ${x86_gcc_opts}
EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-Wl,--export-all -mno-cygwin -shared:.dll.a,
# UWIN
UWIN, cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${no_asm}:win32,
@@ -930,7 +930,6 @@
my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds;
-$IsMK1MF=1 if ($target eq mingw $^O ne cygwin !is_msys());
$exe_ext=.exe if ($target eq Cygwin || $target eq DJGPP || $target eq
mingw);
$exe_ext=.pm if ($target =~ /vos/);
@@ -1832,10 +1831,4 @@
return $errorcnt;
}
-# Attempt to detect MSYS environment
-sub is_msys
- {
- return 1 if (exists $ENV{TERM} $ENV{TERM} eq msys);
- return 0;
- }
Index: Makefile.shared
===
RCS file: /cvs-openssl/openssl/Makefile.shared,v
retrieving revision 1.57
diff -u -r1.57 Makefile.shared
--- Makefile.shared 20 May 2006 08:52:34 - 1.57
+++ Makefile.shared 20 Oct 2006 11:49:31 -
@@ -7,6 +7,7 @@
# CC contains the current compiler. This one MUST be defined
CC=cc
+NM=nm
CFLAGS=$(CFLAG)
# LDFLAGS contains flags to be used when temporary object files (when building
# shared libraries) are created, or when an application is linked.
@@ -101,7 +102,7 @@
LIBDEPS=$${LIBDEPS:-$(LIBDEPS)}; \
SHAREDCMD=$${SHAREDCMD:-$(CC)}; \
SHAREDFLAGS=$${SHAREDFLAGS:-$(CFLAGS) $(SHARED_LDFLAGS)}; \
-nm -Pg $$SHOBJECTS | grep ' [BDT] ' | cut -f1 -d' ' lib$(LIBNAME).exp; \
+$(NM) -Pg $$SHOBJECTS | grep ' [BDT] ' | cut -f1 -d' '
lib$(LIBNAME).exp; \
LIBPATH=`for x in $$LIBDEPS; do if echo $$x | grep '^ *-L' /dev/null
21; then echo $$x | sed -e 's/^ *-L//'; fi; done | uniq`; \
LIBPATH=`echo $$LIBPATH | sed -e 's/ /:/g'`; \
LD_LIBRARY_PATH=$$LIBPATH:$$LD_LIBRARY_PATH \
Index: apps/apps.c
===
RCS file: /cvs-openssl/openssl/apps/apps.c,v
retrieving revision 1.114
diff -u -r1.114 apps.c
--- apps/apps.c 12 May 2006 17:11:58 - 1.114
+++ apps/apps.c 20 Oct 2006 11:49:32 -
@@ -126,6 +126,9 @@
#include openssl/pkcs12.h
#include openssl/ui.h
#include openssl/safestack.h
+#define NON_MAIN
+#include apps.h
+#undef NON_MAIN
#ifndef OPENSSL_NO_ENGINE
#include openssl/engine.h
#endif
@@ -134,9 +137,6 @@
#endif
#include openssl/bn.h
-#define NON_MAIN
-#include apps.h
-#undef NON_MAIN
#ifdef _WIN32
static int WIN32_rename(const char *from, const char *to);
Index: crypto/bio/b_sock.c
===
RCS file: /cvs-openssl/openssl/crypto/bio/b_sock.c,v
retrieving revision 1.46
diff -u -r1.46 b_sock.c
--- crypto/bio/b_sock.c 11 Apr 2006 21:34:18 - 1.46
+++ crypto/bio/b_sock.c 20 Oct 2006 11:49:33 -
@@ -60,6 +60,7 @@
#include stdlib.h
#include errno.h
#define USE_SOCKETS
+#include e_os.h
#include cryptlib.h
#include openssl/bio.h
#if defined(OPENSSL_SYS_NETWARE) defined(NETWARE_BSDSOCK)
Index: crypto/rand/randtest.c
===
RCS file: /cvs-openssl/openssl/crypto/rand/randtest.c,v
retrieving revision 1.8
diff -u -r1.8 randtest.c
--- crypto/rand/randtest.c 28 Aug 2005 22:49:55 - 1.8
+++ crypto/rand/randtest.c 20 Oct 2006 11:49:37 -
@@ -58,9 +58,9 @@
#include stdio.h
#include stdlib.h
+#include ../e_os.h
#include openssl/rand.h
-#include ../e_os.h
/* some FIPS 140-1 random number test */
/* some simple tests */
Index: engines/ccgost/gost_eng.c
===
RCS file: /cvs-openssl/openssl/engines/ccgost/gost_eng.c,v
retrieving revision 1.2
diff -u -r1.2 gost_eng.c
--- engines/ccgost/gost_eng.c 21 Sep 2006 13:24:46 - 1.2
Re: Cross compile OpenSSL in Linux using MinGW32
On 2006.10.20 at 13:01:01 +0200, Corinna Vinschen wrote: On Oct 20 14:28, Victor B. Wagner wrote: On 2006.10.20 at 11:49:39 +0200, Corinna Vinschen wrote: ws2tcpip.h is incompatible with winsock.h since winsock.h is only meant for supporting old Winsock 1.1 applications. A modern Winsock 2 application should include winsock2.h and ws2tcpip.h. So, it is line 455 in e_os.h which is offending, not line 278? Line 455 looks wrong to me. winsock2.h is already included in line 277 so I don't see how another include of winsock.h in line 455 could be right. Further investigation shows that it is OK. Winsock.h wouldn't be included if winsock2.h already included. Problem was in other place File ssl/ssl_sess.c includes openssl/rand.h before ssl_locl.h, and rand.h includes windows.h and windows.h includes winsock.h if winsock2 wasn't already included. So, just changing order of rand.h and ssl_locl.h ssl_sess.c, changing order of openssl/engine.h and apps.h in apps/apps.c, and changing order of openssl/rand.h and ../e_os.h in test/randtest.c fixes this problem __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
On 2006.10.20 at 13:51:47 +0200, Andy Polyakov wrote: Keep in mind that mingw defines _WIN32_WINNT=0x333, i.e. the intention was to target all NT versions [note that 0x333 actually covers even for Windows 9x, which has at least all 0x333 stubs, so that application can actually start]. As for winsock versioning. Upon latest modifications to b_sock.c I considered linking with wsock32 to be sufficient/appropriate for following reason. Systems equipped with ws2_32.dll do have wsock32 too, and this wsock32.dll is actually linked with ws2_32.dll. Meaning that [legacy] application linked with wsock32 alone will actually bring even ws2_32.dll into address space. Now note that b_sock.c makes *global* lookups for getaddrinfo, meaning that application linked with Hmm, actually -lws2_32 is not strictly neccessary. Are there tests for IPV6 in BIO in the test suite? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
On 2006.10.20 at 14:12:44 +0200, Andy Polyakov wrote: 2. Makefile.shared Define NM variable to hold name of nm program (which also differs from just nm when cross-compiling) Replace explicit call to nm by reference to this variable. Haven't you yourself mentioned that one needs to generate .def file as well? Care to add and test that? I've found simplier approach. There is linker option --export-all, which allows to make working DLL without .def files. This I've tested. Probably some eariler version of Mingw32 has this option on by default, and so it was assumed that correct DLLs can be build without any extra effort. Really, .def files are much more flexible thing than just exporting all public symbol as Unix .so files do, but mkdef.pl really does almost same as --export-all. And mkdef.pl needs considerable modification to work correctly with Unix-style Configure and mingw32. Problem is that .def file mentions DLL name which is than used by import libraries to find DLL upon loading. So, this name have to be cryptoeay32-version.dll, not just LIBEAY32 as mkdef.pl now generates. In my modified makefiles for 0.9.8 I'm postprocessing def files with perl. This is way too complicated, and doesn't do any better thing than just adding -Wl,--export-all to shlib linker command line for mingw target. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
c_rehash with cross-compiling or ActiveState perl (Re: Cross compile OpenSSL in Linux using MinGW32)
On 2006.10.20 at 12:05:11 +0400, Victor B. Wagner wrote:
Second problem with cross build is that make does certificate
rehash, using freshly compiled c_rehash program. It doesn't lead to make
failure, but it would be nice to be able to redefine c_rehash as well,
and use one from host system OpenSSL during build stage (of course, for
cross-builds only).
More detailed problem with c_rehash under Win32:
I. Running make rehash in Win32/msys environment using ActiveState perl
1. msys shell pwd command without -W option outputs path which looks
like /h/src/openssl, which confuses ActiveState Perl. It understands
only h:/src/openssl.
2. ActiveState perl doesn't consider util/opensslwrap.sh executable
and reports 'openssl' command not found. Really opensslwrap script is
not needed under win32, because openssl.exe would always search for DLL
in the directory where it resides itself, and DLLs are copied there
during build process. File with .exe suffix is recongnized as
executable, so passing OPENSSL=`pwd -W`/apps/openssl.exe to c_rehash makes
it work under msys+AS perl environment. But due to problem 3 it only
reports a lot of file not found errors.
3. c_rehash uses signle quotes around filename to pass certificate name
to openssl x509 -hash
my ($hash, $fprint) = `$openssl x509 -hash -fingerprint -noout -in
$fname`;
It doesn't work with ActiveState perl (which is most widespread native
Win32 perl implementation). Really, it doesn't work with any
implementation of Perl which uses native Windows command interpreter to
handle backtick commands. Changing single quotes there to double quotes
makes command more universal.
II. Running c_rehash on non-windows build platform.
It only requires way to override OPENSSL variable passed to c_rehash.
Something like HOST_OPENSSL=/usr/bin/openssl
So, if we write make rehash target following way:
rehash: rehash.time
rehash.time: certs
(if [ $$OSTYPE = msys ]; then \
OPENSSL=$${HOST_OPENSSL:-`pwd -W`/apps/openssl.exe};\
else\
OPENSSL=$${HOST_OPENSSL:-`pwd`/util/opensslwrap.sh};\
fi;\
OPENSSL_DEBUG_MEMORY=on; \
echo $$OPENSSL;\
export OPENSSL OPENSSL_DEBUG_MEMORY; \
$(PERL) tools/c_rehash certs)
touch rehash.time
and change signle quotes to double in the c_rehash
functions link_hash_cert and link_hash_crl (this is a bit tricky because need
to escape double quotes properly, counting all rounds of substitution which can
occur),
this would work in msys, and also would allow to make rehash on cross-build
platform by adding HOST_OPENSSL=/usr/bin/openssl (or whereever your native
openssl binary is) when doing make.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
On 2006.10.17 at 19:40:05 +0200, Alon Bar-Lev wrote:
Hello,
I tried to compile OpenSSL using MinGW on Linux, but I could not do
this.
I've tried to modify configurations, converting ms/mingw.bat to
ms/mingw.sh, removing the translation of / into \, and more...
Before I making too much modifications,
Have anyone succeeded in doing so?
I do it routinely.
1. Modify Configure script, adding target
mingw-cross
(this all should go into one line)
mingw-cross, i586-mingw32msvc-gcc:-mno-cygwin -DL_ENDIAN
-fomit-frame-pointer -O3 -march=i486 -Wall
-D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG
${x86_gcc_des} ${x86_gcc_opts}
EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-mno-cygwin
-shared:.dll.a:i586-mingw32msvc-ranlib,
2. Modify Makefile shared so it would call
util/mkdef.pl script. and add generated .def file to linking command
Note that DEF file should contain correct DLL name, not just crypteay32
mingw32 builds libcrypto-0.9.8.dll, and this name should exactly appear
in the .def file
3. Forget about dllwrap and such. Modern Mingw32 produce absolutely
correct dlls with just gcc -shared -o dllname,
if you specify .def file along with object file.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL Engine Specification
On 2006.09.28 at 23:33:53 +0200, Heiko J Schick wrote: Hello, I'm looking into the OpenSSL engine support which was introduced in OpenSSL version 0.9.6 (or 0.9.7). Is there an official engine specification or HOWTO available? The only document I have found so far is [1]. As a first start I have looked into the GMP engine module. If I understand the engine concept correctly I can only use the following functions and methods within an engine: - RSA - DSA - ECDH - ECDSA - DH - RAND Can I implement block ciphers (e.g. DES, etc.) in an engine module or is this not supported (by the API implementation) at the moment. You can at least implement block ciphers and digest algorithns, which are not implemented by OpenSSL itself. OpenSSL uses lhash tables to keep lists of available block ciphers and digest algorithms. You should define your own EVP_CIPHER or EVP_MD structure, fill it with pointers to functions which implement cipher/digest operations and use EVP_add_cipher/EVP_add_digest functions to tell OpenSSL to use your implementation. You can see an example of such engine in the engines/ccgost directory of recent development snapshots of OpenSSL 0.9.9. Public key algorithms in this engine rely on 0.9.9 features, but cipher and digest algorithms are compatible with 0.9.8 implementation. (really there is an implementation of ccgost engine for 0.9.8 on www.cryptocom.ru/OpenSource/OpenSSL_eng.html, but it requires patches for support of adding public key algorithms). Although we never tried to redefine existing cipher algorithms - only to add new ones. I'm quite new in this area and apologize if this questions makes no sense or was already answered on the openssl-dev mailing-list. Really there are serious lack of documentation for these advanced areas of OpenSSL usage (I consider writing an engine an advanced usage). I think that if you write documentation on this subject after you figure it out, OpenSSL developers would be glad to include it into distribution. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1232] [PATCH] Flush s_server stdout after state change completed
openssl s_server command outputs to stdout messages, indicating current state of server, such as ACCEPT, DONE, ERROR. When s_server is run interactively, these messages appear on the console in time, and user can see it. But, when s_server is run from some other process via pipe, standard output is buffered in the s_server process. So, it is not possible to control s_server programmaticaly without allocating pseudoterminal. In some cases it is highly desirable to be able to control s_server and s_client from some script (for instance for automatic tests). Following patch fixes this problem by adding BIO_flush call after outputting of some messages. This approach doesn't have performance penalty of fully unbuffered output, but ensures that reader of s_server standard output would see messages in time (Of course reader process should use unbuffered input, but it is usially no problem). Patch is made against 0.9.8 release. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Plug-in own crypto routines with ssl
On 2005.10.26 at 19:37:34 +0100, upinder singh wrote: 2) I have my own C implementation of the AES(rijndael) algo as also of the SHA-256 hash fn,UMAC,RSA and a PRBG to generate symmetric keys.All these are software implementations only. 3)I want to plug in these and use them instead of the implementations provided as default in the openssl. 4)What I have figured out so far is that I will have to first make my own engine for each of the algos I wish to add.This engine would have You can write just one engine with all the algorithms. Just don't forget to register all these algorithms in engine initialization code, and set engine provided versions as defaults. 5)Once this is done I would figure out where all the encrytpion algo is called by the openvpn framework and replace each such call with a call to my implementation of the algos in openssl. For any well-written application which uses OpenSSL you don't need this. It might be enough to just write openssl.cnf file which tells OpenSSL to load your engine, and set environment variable OPENSSL_CONF pointing to this file. Typically applications, which use libcrypto call so-called EVP layer functions (see EVP manpage in OpenSSL documentation). These functions know about engines and if some non-default engine is loaded and initalized, they would use engine-provided implementation of algorithms. If application is not so well-written (I haven't seen OpenVPN code) you might have to fix some initialization code. Or you may choose to load your engine explictiely from application code, not relying on environment variables and configuration files. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Plugin own crypto routines with ssl
On 2005.10.26 at 04:17:21 +0100, upinder singh wrote:
I have newly atrted working on the ssl.I do not know
much about the way it works and its design also.I want
to integrate my own crypto routines with the ssl.
There is a lot of documentation bundled with OpenSSL. Just libcrypto
documentation (doc/crypto directory) is about 900Kb.
This is thing you've search answers to your questions in.
What you mean under integrate own crypto routines?
I can imagine two cases:
1. You have some alternative (possibly hardware) implementation of
cryptoalgorithms, which are already supported by OpenSSL, and want to
replace default implementations with these. It is what engines are for.
Look into engine directory of openssl distribution. You'll find a bunch
of examples there. See also README.ENGINE in the top level directory.
2. You want to add support for some crypto algorithms, which are not
supported by OpenSSL yet, for instance for some national cryptography
standard. (Are you from India? What is your national standards?).
This thing is more complicated, especially regarding asymmetric
cryptography. Asymmetric algorithms are hardcoded into current OpenSSL
code in many places with code like
switch (someobject-alg) {
case RSA:
break;
case DSA: ...
break;
case ECDSA: ..
break
}
We have developed patch which removes all these hardcoded switches and
replaces it with table lookup, which allows engines to easily add new
algorithms. Unfortunately this patch is not ready for integration into
main OpenSSL code.
See http://www.cryptocom.ru/OpenSource/OpenSSL_eng.html
Things are a bit simplier with symmetric ciphers and digest algorithms.
There are already tables for these algorithms in place. But, as far as I
remember there were some problems with adding new algorithms of these
types using dynamically loading engines, which we fixed in our patch
too.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Options of building openssl for Win32 using gcc
On 2005.10.13 at 12:42:34 -0700, Howard Chu wrote: We already build using the mingw32 compiler under msys. I've been a bit lax about sending back patches lately, but as I recall there were only a few small tweaks to Configure needed. IMO the Cygwin environment is worthless; it is several times slower than MinGW/MSYS for no real benefit. I wouldn't agree that Cygwin environment is completely worthless. At least while there is no sshd in MSys. Cygwin enviornment is quite a good tool for extending mulitplatform Unix-based automated building-testing frameworks to win32 platforms. It is often not important if nightly build on one particular platform runs fifteen minutes or couple of hours, since other builds are done in parallel on other machines anyway. Resulting libraries are in all` cases compatible with Microsoft Visual C. In addition #2 should/will generate .def files and use them when linking .dll. Idea is to be able to generate drop-in replacement .dlls for those compiled with MSVC. It is not done yet? With all the infrastructure in place? I'd look there. GNU C cross-compilers can be invoked in two ways 1. Using -B option to gcc 2. Using name which looks like architecture-system-gcc, in this case i586-mingw32msvc-gcc. I recommend using the second way, because we need to call cross-versions of some binutils programs, such as ranlib, and they do not have -B option. I'd create a /some/place/i586-mingw32mscv catalog, create small wrapper scripts called gcc, ranlib, etc. with 'exec i586-mingw32mscv-$0 $@' line, and prepend your $PATH with /some/place/i586-mingw32mscv prior running make:-) A. I've done this type of setup before, with complete toolchains in /some/place/architecture. You just need to put /some/place/arch in front of your path, then you don't need any wrappers. I don't like idea of fiddling with PATH inside automated build scripts. Of course, this would help with binutils tools. But now we have all our platform-specific logic inside Makefiles. I can just say make FOR=lnx to do native build and make FOR=w32 for mingw crossbuild. Yes, for some projects we also do make FOR=dj for DJGPP cross-build, but openssl is not one of these yet. Resetting CC, RUNLIB and AR variables seems to be much more harmless than changing PATH. This approach allows to treat different compilers for same target platform (say icc and gcc on Linux or MSVC and mingw32 gcc on Win32) same way as compilers for different target platforms. If the idea is to use a single gcc compiler driver to automatically invoke the right cross-compiler based on commandline args, I guess you can go to the trouble of setting up all the pathnames that gcc expects, but it seems like wasted effort to me. It's only useful if you're Main drawback of this approach is that you have to specify BOTH architecture AND version in the command-line explicitely, if your compilers for different architectures are different. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Options of building openssl for Win32 using gcc
On 2005.10.13 at 13:27:47 -0700, Howard Chu wrote: Disregard that comment, I was lost. I don't interchange MSVC / gcc dll's on the fly. I was just thinking about the import libraries; a gcc-compiled DLL will work with an MSVC app if it's linked with the gcc-specific import library, and vice-versa. Haven't tested this with OpenSSL yet, but for some other projects it is no problem. For example, one can get tcl84.lib from ActiveState Tcl (MSVC import library), RENAME it to libtcl8.4.a and link some application with it using Mingw. And vice versa. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Options of building openssl for Win32 using gcc
I've investigated various ways of building OpenSSL (release 0.9.8) for
Win32 with gcc.
There are at least three ways to do this
1. Using mingw32 compiler (from http://www.mingw.org)
2. Using cygwin compiler with -mno-cygwin switch to create executables
which do not depend on cygwin.dll
3. Using cross-compiler on some Unix system. I've used cross-compiler
included in Debian GNU/Linux ver./g 3.1 (sarge) as package mingw32
Resulting libraries are in all cases compatible with Microsoft Visual C.
There is common opinion that mingw32 cannot create .lib libraries. It is
wrong. It just names them differently. If you feed microsoft .lib file
to Unix file command on any unix system around, it would report Current
ar archive. So, if you rename libsomething.a, created by mingw32 to
something.lib, MSVC would be quite happy with it, and vice versa.
All three ways are quite easy to get working.
1. Using mingw32
There is a batch file ms/mingw.bat in OpenSSL distribution. As I could
understand from the discussion in openssl mailing lists, it is mostly
unmaintained and is somewhat behind current state of code. Although it
took few minutes for me to fix it.
So, I decide to use more busy road and use `perl Configure mingw shared'
to do a Unix-style build.
It requires minor modification of Configure script - it thinks that
unix-style builds are possible for mingw only if current perl is a CYGWIN
one.
---
$IsMK1MF=1 if ($target eq mingw $^O ne cygwin);
---
I think that this is wrong assumption. One can use ActiveState Perl while
having all the rest of necessary Cygwin utilities installed, or one can
use other set of POSIX utilities available. So, I've just commented out
this line.
More robust test can be written. For example, we can test for SHELL
environment variable matching regular expression /sh$/. Both CYGWIN and
MSys shells set it, and if this test is documented, user can set it
manually, if he prefers to run `perl Configure' from cmd.exe, but is
sure that he has necessary POSIX utilities.
This way requires some POSIX utilites (such as rm, mv and pwd) to be
available. There is a collection of such utilities, available on mingw
site, called MSys (Minimal SYStem). Unfortunately, version of MSys which
I use doesn't include pwd as standalone utility. There is shell builtin
pwd, but it seems to not be enough for OpensSSL `make links' target.
I've solved this problem by creating file pwd.bat somewhere in my path,
which contains just two letters: 'cd'. Of course, command.com/cmd.exe cd
command would output current directory using DOSish backslashes as
separator. But mingw32 utilities and make seems to be happy with it.
If YOU are not so happy, you can use following small C program:
start pwd.c
#include unistd.h
#include stdio.h
int main(int argc,char **argv) {
char buffer[4096];
char *p;
if (!getcwd(buffer,4096)) {
perror(pwd);
return 1;
}
for (p=buffer;*p;p++) {
if (*p=='\\') *p='/';
}
printf(%s\n,buffer);
return 0;
}
end pwd.c --
2. Using CYGWIN suite.
This is supported way to compile. Only problem I've encountered is that
Configure expects that one would use cygwin perl for cygwin compile,
and I've ActivePerl installed on the machine where I've made this
compilation.
Solution, described above for MSys works here too.
Cygwin have more complete set of POSIX commands, so pwd hack described
above is not need.
3. Using cross-compiler.
GNU C cross-compilers can be invoked in two ways
1. Using -B option to gcc
2. Using name which looks like architecture-system-gcc, in this case
i586-mingw32msvc-gcc.
I recommend using the second way, because we need to call
cross-versions of some binutils programs, such as ranlib, and they do
not have -B option.
Anyway in both cases we need to add additional target to Configure.
I've added following elemet for Configure %table array:
mingw-cross, i586-mingw32msvc-gcc:.
-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall .
-D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:.
BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:.
win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:
-mno-cygwin -shared:.dll.a:i586-mingw32msvc-ranlib,
Line is split here for clarity, using correct perl syntax to concatenate
it back, so it may be just cut'n'pasted from here.
This solution can be further improved - here there is hardcoded
architecture-system prefix for compiler and ranlib. This prefix can
vary from installation to installation, so it is better to use some
varible substitution.
After doing this modification, I've found out that everything compiles
clearly, but all the executables do not have .exe suffix.
This is caused by following line in Configure:
$exe_ext=.exe if ($target eq Cygwin || $target eq DJGPP ||
$target eq mingw);
I've changed the last condition to
$target =~ m/^mingw/
So, it would work for any target STARTED with mingw.
After this
Re: How to debug under Solaris-x86?
On 2005.05.25 at 23:53:13 +0200, Andy Polyakov wrote: I guess it was erroneously omitted in some newer release. Try to patch your run-time environment by executing http://www.openssl.org/~appro/values.c and report back. The patch is designed to work with both old and new GCC releases. A. With this patch it works on both my Solaris x86 machines == first one == uname -a SunOS elk 5.8 Generic_108529-23 i86pc i386 i86pc as -V as: Sun WorkShop 6 99/08/16 ld -V ld: Software Generation Utilities - Solaris-ELF (4.0) gcc -v Reading specs from /usr/local/lib/gcc-lib/i386-pc-solaris2.8/3.3/specs Configured with: ../configure --disable-nls --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld Thread model: posix gcc version 3.3 == second one === uname -a SunOS sol9 5.9 Generic_112234-03 i86pc i386 i86pc as -V as: Forte Developer 7 Compiler Common 7.0 IA32-iteam 2001/12/12 ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.276 gcc -v Reading specs from /usr/local/lib/gcc-lib/i386-pc-solaris2.9/3.3.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.3.2 == Interesting thing is that I have compiled lots of various sofware on both these machines but never before encountered this problem with GCC runtime. What makes OpenSSL so special that it hits this bug in the GCC runtime? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1084] Incorrect RIPEMD160 calculation on Solaris/Sparc-64 bit
Attempt to build Openssl-0.9.8-stable-SNAP-20050530 on Solaris 8 sparc using 64-bit mode (solaris64-sparcv9-gcc target) results in error in RIEMD160 tests. If test_rmd target is excluded from the tests, all other tests pass correctly -- output of make test ../util/shlib_wrap.sh ./rmdtest error calculating RIPEMD160 on '' got f5d0d8106761315059ae6b26b7b8f8d709bbad31 instead of 9c1185a5c5e9fc54612808977ee8f548b2258d31 error calculating RIPEMD160 on 'a' got b043ec680ea550029fa8c516614e87e4b12b6e76 instead of 0bdc9d2d256b3ee9daae347be6f4dc835a467ffe error calculating RIPEMD160 on 'abc' got 0f60a77c70133e49f0e9673a01cc2a3594576b5e instead of 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc error calculating RIPEMD160 on 'message digest' got 7e0241d14c654e046a285674449a450c0a525228 instead of 5d0689ef49d2fae572b881b123a85ffa21595f36 error calculating RIPEMD160 on 'abcdefghijklmnopqrstuvwxyz' got b15da71470095d6395c53a3522a99154000ec885 instead of f71c27109c692c1b56bbdceb5b9d2865b3708dbc error calculating RIPEMD160 on 'abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq' got a9cf9607242ef0bfddf85d5505a17ff806e01f6e instead of 12a053384a9c0c88e405a06c27dcf49ada62eb2b error calculating RIPEMD160 on 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789' got c7b9e967202835df2eb3309032e3937c95c46f07 instead of b0e20b6e3116640286ed3a87a5713079b21f5189 error calculating RIPEMD160 on '12345678901234567890123456789012345678901234567890123456789012345678901234567890' got 9dd5182e0f4062f7dbfcee9b300a26e94bd99301 instead of 9b752e45573d4b39f4dbd3323cab82bf63326bfb make[1]: *** [test_rmd] Error 8 -- output of make report OpenSSL self-test report: OpenSSL version: 0.9.8-beta3 Last change: Correct naming of the 'chil' and '4758cca' ENGINEs. Thi... Options: enable-shared -R/usr/local/lib/sparcv9 -L/usr/local/lib/sparcv9 no-gmp no-krb5 no-mdc2 no-rc5 no-zlib no-zlib-dynamic OS (uname): SunOS sundae 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-1 OS (config): sun4u-whatever-solaris2 Target (default): solaris-sparcv9-gcc Target: solaris64-sparcv9-gcc Compiler: Configured with: ../configure --disable-nls --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld Thread model: posix gcc version 3.3 Test skipped. -- output of as -V as: Sun WorkShop 6 99/08/18 -- output of ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.283 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1084] Ticket Resolved
On 2005.05.31 at 14:40:46 +0200, Andy Polyakov via RT wrote: Hello According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. Bug 1084 was resolved with following diagnositics Not OpenSSL problem. Explicitly mentioned in ./PROBLEMS, case dismissed But I cannot find anything related to my situation: solaris64-sparcv9-gcc, gcc version 3.3, RIPEMD160 algorithm. As far as I can understand, each problem description in the PROBLEMS file starts with asterisk at first position of line. grep -n '^\*' PROBLEMS shows: 1:* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X. 42:* Parallell make leads to errors 51:* Bugs in gcc 3.0 triggered 66:* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler. 74:* Problems with hp-parisc2-cc target when used with no-asm flag 93:* Problems building shared libraries on SCO OpenServer Release 5.0.6 Obvoisly, problem mentioned on line 66 is irrelevant. Problem, mentioned in line 51 seems to not to be relevant to gcc 3.3 too. Please point me out line number which describes my problem. I'm using openssl-0.9.8-stable-SNAP-20050530 With best regards, Victor. P.S. Note a typo on line 42 of PROBLEMS file. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to debug under Solaris-x86?
On 2005.05.23 at 17:30:04 +0200, Andy Polyakov wrote:
./config shared zlib no-sse2 -L/usr/local/lib -R/usr/local/lib
uname -a, ld -V, as -V.
Sorry, I' forgot to attach output of make report
OpenSSL self-test report:
OpenSSL version: 0.9.8-beta2-dev
Last change: Add attribute functions to EVP_PKEY structure.
Modify...
Options: enable-shared enable-zlib -L/usr/local/lib
-R/usr/local/lib no-gmp no-krb5 no-mdc2 no-rc5 no-sse2 no-zlib-dynamic
OS (uname): SunOS elk 5.8 Generic_108529-23 i86pc i386 i86pc
OS (config): i86pc-whatever-solaris2
Target (default): solaris-x86-gcc
Target: solaris-x86-gcc
Compiler: Configured with: ../configure --disable-nls
--with-as=/usr/ ccs/bin/as --with-ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 3.3
Test skipped.
ld -V
ld: Software Generation Utilities - Solaris-ELF (4.0)
as -V
as: Sun WorkShop 6 99/08/16
Usage: as [-V] [-Q{y,n}] [-s]
[-S[aAbBcClL]] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-xF] [-F] [-b] [-i] file.s ...
Problem is that I cannot get any meaningful backtrace from OpenSSL
configured this way.
Buf if you issue disassemble command at debugger prompt, you should see
that you're in _init and if you follow to failing address you're most
likely to spot mov (%eax),%al, right?
Core was generated by `./destest'
Program terminated with signal 11, Segmentation fault.
#0 0xdfb6b7d5 in ?? ()
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) disassemble 0xdfb6b7d5 0xdfb6b7ff
Dump of assembler code from 0xdfb6b7d5 to 0xdfb6b7ff:
0xdfb6b7d5: Cannot access memory at address 0xdfb6b7d5
gdb --version
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-pc-solaris2.8.
Unfortunately, attempt to configure debug version
produces
What's wrong with ./config -g? Though it [or anything else] would hardly
help debugging .init segment:-( A.
The only thing - it is not mentioned in the INSTALL file and not shown by
./config --help
Thanks, I would try to produce more informative report using this option.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1078] OpenSSL 0.9.8-stable-SNAP-20050523 doesn't build with no-aes
Hello. When trying to build openssl with some cipher algorithms disabled I've encountered following result: making all in crypto/engine... gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -c eng_padlock.c In file included from eng_padlock.c:73: ../../include/openssl/aes.h:58:2: #error AES is disabled. *** Error code 1 Platform FreeBSD 5.3 configuration command: ./config shared zlib no-des no-aes no-bf Configuration command outputs Configured for BSD-x86 which seems to be wrong, because BSD-x86-elf target seems to be more appropriate With best regards Victor Wagner __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1079] Openssl config fails to determine architecture on FreeBSD 5.3-RELEASE
Hello, I've found out that OpenSSL fails to build correctly on FreeBSD 5.3-RELEASE machine, producing cryptic assembler messages. Further investingation shows that Openssl is configured for BSD-x86 (a.out) architecture instead of BSD-x86-elf problem is that elf/a.out test in config looks like === *86*-*-*bsd*) case `(file -L /usr/lib/libc.so.*) 2/dev/null` in *ELF*) OUT=BSD-x86-elf ;; *) OUT=BSD-x86; options=$options no-sse2 ;; esac ;; === This test fails, due to absense of files /usr/lib/libc.so.* on my machine ls -l /usr/lib/libc.* -r--r--r-- 1 root wheel 1874022 5 ÎÏÑ 2004 /usr/lib/libc.a lrwxrwxrwx 1 root wheel 14 9 ÍÁÒ 20:05 /usr/lib/libc.so - /lib/libc.so.5 It seems that on newer BSD systems actual shared libc lives in /lib rather than in /usr/lib. Following patch fixes this problem. It is tested on both FreeBSD 5.3-RELEASE (new layout of filesystem) and FreeBSD 4.8-RELEASE (old layout with shared libc in /usr/lib) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to debug under Solaris-x86?
On 2005.05.23 at 17:30:04 +0200, Andy Polyakov wrote: Buf if you issue disassemble command at debugger prompt, you should see that you're in _init and if you follow to failing address you're most likely to spot mov (%eax),%al, right? You are right: Dump of assembler code for function _init: 0xdfb1b7c0 _init+0: call 0xdfa6532c frame_dummy 0xdfb1b7c5 _init+5: add%al,(%eax) 0xdfb1b7c7 _init+7: add%al,(%eax) 0xdfb1b7c9 _init+9: add%al,(%eax) 0xdfb1b7cb _init+11: add%al,(%eax) 0xdfb1b7cd _init+13: add%al,(%eax) 0xdfb1b7cf _init+15: add%ch,%al 0xdfb1b7d1 _init+17: inc%edi 0xdfb1b7d2 _init+18: mov%eax,0x9ebfff4 0xdfb1b7d7 _init+23: nop 0xdfb1b7d8 _init+24: nop x/23cx 0xdfb1b7c0 0xdfb1b7c0 _init: 0xe8 0x67 0x9b 0xf4 0xff 0x00 0x000x00 0xdfb1b7c8 _init+8: 0x00 0x00 0x00 0x00 0x00 0x00 0x000x00 0xdfb1b7d0 _init+16:0xe8 0x47 0xa3 0xf4 0xff 0xeb 0x09 Of course, it is add rather than mov, because add instruction has zero opcode on intel. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to debug under Solaris-x86?
On 2005.05.23 at 18:50:44 +0400, eugeny gladkih wrote: Victor B. Wagner [EMAIL PROTECTED] writes: I'm testing my application with 0penssl-0.9.8 stable snapshot on several platforms. And encounter some problems on most architectures except Linux. do you have troubles only with 0.9.8 and 0.9.7 seems to be working well? Really, I haven't tried to compile 0.9.7 on all these platforms. OpenSSL 0.9.7 comes prepackaged on all these system and I suppose maintainers of these packages already filed bug reports. This part of OpenSSL 0.9.8 is under very active development now. Each new snapshot fixes few bugs and adds some new. For instance, 20050516 snapshot has passed all the tests on Solaris x86 after I've got it to compile. Newer snapshot compiles out of box but segfaults on startup. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1073] Problems with generating SSE2 instructions with no-sse2 configuration options
Hello, I've found following problem with compilation of OpenSSL on Solaris x86 platform: I use gcc 3.3 from www.sunfreeware.com, which is configured to use Sun native assembler. It seems that Sun assembler doesn't know anything about SSE2 instruction, and compilation of assembler file x86cpuid_elf.s fails on PXOR sse instruction. There is configuration option no-sse2 of openssl Configure script, but it doesn't prevent x86cpuid.pl from generating SSE2 pxor instruction. These pxor instructions are skipped anyway if absense of SSE2 is detected run-time. x86cpuid.pl receives full set of C compiler flags, including OPENSS_IA32_SSE2 flag, which is set only if SSE2 instructions are enabled. Attached patch fixes this problem by adding check for OPENSSL_IA32_SSE2 command line flag to x86cpuid.pl and skipping section between runtime SSE2 check and label no_sse2, if this flag is not found. Patch is made against 20050516 CVS snapshot. Sincerely yours, Victor Wagner __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Eliptic curve MQV key agreements
On 2005.01.19 at 22:50:25 +, Ben Laurie wrote: Victor B. Wagner wrote: On 2005.01.19 at 15:26:25 +0100, Nils Larsch wrote: Roger Boden wrote: Hello, It should be obvois next step when we get this infrastructure working. Why would we want to assist patent holders? 1. There is not such thing as world-wide patent. So, we are going to assist users from countries, where particular algorithm is not encumbered. 2. There are several other situation where loadable algorithms desirable. Some applications require goverment ceritification of cryptoalgorithm implementation, while entire application doesn't require certification. It is hard to certify, say, entire Apache+mod_ssl, but much easier to certify just loadable engine with national cryptographic algorithms. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Eliptic curve MQV key agreements
On 2005.01.19 at 15:26:25 +0100, Nils Larsch wrote: Roger Boden wrote: Hello, are there any plans to support eliptic curve MQV key agreements in openssl? afaik no, btw: have a look at [1] Cheers, Nils [1] http://marc.theaimsgroup.com/?l=openssl-usersm=105308047218590w=2 It seems that it is yet another reason to support adding new assymetric algorithms by loadable engines. Providing plugins with patented algorithms is much easier for patent holders than maintaining patched version of openssl. And it is much easier to users to just drop in an engine module. Although our current proposal http://marc.theaimsgroup.com/?l=openssl-devm=109947214028600w=2 doesn't specify a way to automatically load such plugins into all applications which link with libcrypto. It should be obvois next step when we get this infrastructure working. __ 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: Registering custom objects from dynamically-loaded engine
On 2004.12.06 at 15:54:16 +0100, Dr. Stephen Henson wrote: I doubt its related to the NIDs and OBJ_create(). The NIDs and associated objects duplicate strings for use in OpenSSLs internal tables and so there shouldn't be any hanging references when a DLL unloads. Here is trace of our segfault. Address 44339fd0 is address of constant string in our DLL. #0 0x400f7d53 in lh_strhash (c=0x44339fd0 Address 0x44339fd0 out of bounds) at lhash.c:445 445 if ((c == NULL) || (*c == '\0')) (gdb) bt #0 0x400f7d53 in lh_strhash (c=0x44339fd0 Address 0x44339fd0 out of bounds) at lhash.c:445 #1 0x4008a911 in obj_name_hash (a_void=0xb480) at o_names.c:140 #2 0x400f7c69 in getrn (lh=0x4034afa0, data=0xb480, rhash=0xb44c) at lhash.c:406 #3 0x400f77e9 in lh_delete (lh=0x4034afa0, data=0xb480) at lhash.c:224 #4 0x4008ab83 in OBJ_NAME_remove ( name=0x44339fd0 Address 0x44339fd0 out of bounds, type=2) at o_names.c:233 #5 0x4008ae29 in names_lh_free (onp=0x446c0ff0) at o_names.c:332 #6 0x4008ae48 in names_lh_free_LHASH_DOALL (arg=0x446c0ff0) at o_names.c:336 #7 0x400f794e in doall_util_fn (lh=0x4034afa0, use_arg=0, func=0x4008ae31 names_lh_free_LHASH_DOALL, func_arg=0, arg=0x0) at lhash.c:289 #8 0x400f797c in lh_doall (lh=0x4034afa0, func=0x4008ae31 names_lh_free_LHASH_DOALL) at lhash.c:297 #9 0x4008aecb in OBJ_NAME_cleanup (type=2) at o_names.c:353 #10 0x400ff899 in EVP_cleanup () at names.c:132 #11 0x08055dd4 in main (Argc=1, Argv=0xba74) at openssl.c:355 In any case the extra objects are freed up when OBJ_cleanup() is called. Problem is that EVP_cleanup calls OBJ_NAME_cleanup several times with various OBJ_NAME_TYPE flags before it is going to call OBJ_cleanup. Really our problem seems to be located in another place. As dgst command works without segfault, it seems that in our case req doesn't just initialize engine properly. So, engine unload funcion doesn't get called before EVP_cleanup. In dgst it does, and there is no segfault. It looks strange to me, because req uses digest method to generate signature under certificate request. (And since we are generating GOST algorithm key, it use GOST message digest from our engine). Probably we have forgotten something when developed our patches to generalize asymmetric algorithm handling. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Registering custom objects from dynamically-loaded engine
On 2004.12.04 at 00:45:45 -0500, Geoff Thorpe wrote: On December 3, 2004 07:30 pm, Dr. Stephen Henson wrote: On Fri, Dec 03, 2004, Dmitry Belyavsky wrote: On Fri, 3 Dec 2004, Dmitry Belyavsky wrote: I have custom dynamically-loaded engine implementing some non-standard algorithms. So I register NIDs using OBJ_create from engine bind function. Registering code looks like my_NID = OBJ_create(1.2.3.4.5,OID_example,Our example OID); On unload I get segfault in apps_shutdown. It happens in OBJ_NAME_cleanup. It looks like OBJ_NAME_cleanup tries to free memory belongs to unloaded library. ^^ I hacked up a quick dynamic engine that called OBJ_create() only and I couldn't reproduce this. I used the autoconfig mechanism mentioned in config(5) to load it. The object was added, it was recognized by asn1parse and there were no leaks on shutdown. First of all, I should note that there is no problem if we just use OBJ_create. But, if we then register cipher and digest algorithms, using NID returned by the OBJ_create, problem sometimes occur. We were unable so far to pin problems down. Some openssl command cause segfault, and some do not (although debug build reports number of memory leaks). We found out that dgst command never produce segfaults, and does call destroy function, when req command (generating CSR or self-signed certificate) does produce segfault. In both cases message digest algorithm from our engine is used. This is probably another global state-type problem between the loader and loadee. See IMPLEMENT_DYNAMIC_BIND_FN() in engine.h for an peek into the horror. I'm guessing you guys are using different platforms, or at least different methods of compilation/linking? We need to ensure that Of course, not. We are using same compiler for openssl core and our engine. There might be some difference in compilation flags, but it shouldn't matter. the loaded engine use the loading app/lib's state - if necessary by redirecting its OBJ functionality to that of the loader. We have openssl compiled as shared library, so it shouldn't pose any problems in ELF environment. BTW we have traced it with debugger, so we can be reasonable sure that correct version of library gets loaded. I'm out of here for the weekend, but if noone gets to the bottom of this before middle(ish) of next week, I'll take a nosey. Which version are you using BTW? We are now using CVS snapshot of November 29. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Generalized infrastructure for public key algorithms
On 2004.11.16 at 11:17:39 +0100, Nils Larsch wrote:
Hi Victor,
some first short notes:
Victor B. Wagner wrote:
...
--- /home/vitus/src/openssl-SNAP-20041105.orig/apps/req.c2004-11-09
12:35:42.0 +0300
+++ apps/req.c 2004-11-15 14:24:36.0 +0300
@@ -167,9 +167,10 @@
...
else if (strcmp(*argv,-new) == 0)
{
+ as=EVP_get_asymmetricbynid(NID_rsaEncryption);
+if (!as) {
+BIO_printf(bio_err,RSA algorithm is
not supported by this version of OpenSSL\n);
+goto end;
+}
+pkey = EVP_PKEY_new();
newreq=1;
+
}
why ? in case I want to create a new cert request for a dsa key I don't
need rsa support.
For compatibility with existing behavoir. -new creates only RSA keys.
One should specify -newkey with algoritm specification to create other
key. This is documented in the req(1) manual page.
May be there is an error and we are trying to find RSA algorithm
description before we've checked that existing private key is provided.
If it is a case, it would be fixed in next version of the patch.
...
--- /home/vitus/src/openssl-SNAP-20041105.orig/crypto/asn1/x_pubkey.c
2004-11-09 12:35:42.0 +0300
+++ crypto/asn1/x_pubkey.c 2004-11-15 16:08:06.0 +0300
...
-#endif
-else if (1)
-{
-X509err(X509_F_X509_PUBKEY_SET,X509_R_UNSUPPORTED_ALGORITHM);
-goto err;
+if (pkey-save_parameters as-i2d_algor_params) {
+as-i2d_algor_params(pkey,a-parameter);
+} else {
+a-parameter-type=V_ASN1_NULL;
}
this might be a problem if the parameters must be omitted for
some future algorithm
Yes (if this algorithm doesn't accept V_ASN1_NULL as parameters), but if such
an algorithm exists, than X509_ALGOR structure should
be modified. We think that for now it can be left as is, because it
works for existing algorithms, and for all ones we are planning to add.
I'm not sure that X509 standard allows parameters to be entirely
omitted, not just a NULL sequence.
+int nid; //NID of
please don't use c++ style comments
Sorry... Would be fixed
+
+static int d2i_EC_X509_pub_key(EVP_PKEY *key, const unsigned char *buf,
long length) {
+/* Moved from d2i_PublicKey */
+if (!o2i_ECPublicKey((key-pkey.eckey),
+ buf, length))
the name d2i_EC_X509_pubkey isn't appropriate for this function, as it
Why you choose this as example? If d2i isnt appropriate here, it is not
appropriate as name of EVP_ASYMMETRIC structure field at first.
Btw: wouldn't it be better (cleaner) to put these algorithm specific
functions in the corresponding directory (i.e. crypto(rsa etc.)
I think it would be better to do along the way it is done for message
digests and ciphers - put these routines into appropriate named files
in the evp directory.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #973] openssl dgst -rmd160 /tmp/very_large_file fail
On 2004.11.11 at 13:13:53 +0100, [EMAIL PROTECTED] via RT wrote: i try to make a dgst of a 40Gb file, but when the openssl binary try to fopen the file, it's fail .. i think the problem was the fopen, maybe it's dont use the open (2) with the option O_LARGEFILE.. can you fix it ? Have you tried to recompile OpenSSL with -D_LARGEFILE_SOURCE or whatever option your compilation environment need to support large files? Please tell us some more information about your platform and compilation environment. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Generalized infrastructure for public key algorithms
On 2004.11.10 at 11:40:12 +0100, Nils Larsch wrote: please have a look at ec_key_meth_st in ec.h and how it's used in ecdsa_data_st (in ecdsa.h). The type specific key attributes (including a method pointer) are stored in a kind of derived structure (ecdsa_data_st). If you need more information, feel free to ask ;-) Thanks for the hint. But it doesn't contain engine pointer. I'm not sure that engine pointer is strictly neccessary, but it is required at least to properly initalize ECDSA and ECDH structure. Why? lhash tables are already used in OpenSSL to store various tables. Why invent something new instead of reusing existing infrastructure? a hash table is good if you want to have a mapping nid - curve (or, as it's done in crypto/objects, some more keys (nid, sn, ln and oid) - object) in case of ec curve parameters we got quite a lot of parameters and I'm not so sure which of these should be search keys + I don't think the number of groups There are EC_GROUP_new_by_nid function in ec_curve.c and it seems to be only accessor to the list of curves. Function EC_get_builtin_curves is used only for listing of supported curves in the ecparam command. Since there is simular command to list builtin ciphers and digests, lhash tables support enumeration of records. what parameter do the GOST signatures curve have ? (I guess there's no non-russian description of this alg) GOST doesn't specify set of parameters. what does GOST specify ? Doesn't is specifiy certain cryptographic algs to be used for signature generation ? Algorithm is algorithm, and parameter set is quite different beast. For instance, for DSA OpenSSL supports even generation of set of parameters. DSS standard places some requirements on this parameter set, but group of people is free to generate its own parameters. Elliptic curve generation is not supported yet by OpenSSL (it is quite complicated), but it is possible to generate these curves. 8. Provide callbacks for packing and unpacking of a signature objects These callbacks already exist in the message digest structure. ops, I mean a function for the signatureAlgorithm field of a signature May be it would be desirable. We need to investigate a bit furher. If it turns out that several signature algorithms (distinguished by OID in secret key or certificate) can be used to sign/verify same digest type, and these algorithms should have different signature packing rules, may be we would need such an abstraction. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Generalized infrastructure for public key algorithms
On 2004.11.09 at 12:36:56 +0100, Nils Larsch wrote: b) A method which should be stored in the method field of DSA or RSA structure. There are additional problems concerning the ec_key_st structure which doesn't contain the method field and which is the same for two algorithm types - ECDSA and ECDH. These problems need further investigation. the fact that EC_KEY doesn't contain a method pointer is intentional as the EC_KEY structure is/should be (ec) method indepent. Method depend information should be stored in the derived objects (i.e ECDSA_DATA and ECDH_DATA). Yes. Problem is how to pass an information from the PKCS8/X509 parsing to real implementation of method. If EVP_PKEY structure contains pointer to the method, it is easy. With EC_KEY there are two possibilities yet: 1. We don't need to distinguish between ECDH and ECDSA during key loading. Given the EVP_PKEY structure which contain nid of algoritm in the save_type field, we can find out appropriate ECDSA or ECDH method later. 2. We need to store algorithm specific parameters somewhere. In this case current EVP_PKEY structure is inappropriate for passing information from the PKCS8 to actual method implementation. ... 3. To generalize the table of elliptic curves. In the current version of OpenSSL a set of the supported elliptic curve parameters is hardcoded in crypto/ec/ec_curve.c We propose to use the lhash table to handle elliptic curve parameters. I would prefer I linked list instead of lhash Why? lhash tables are already used in OpenSSL to store various tables. Why invent something new instead of reusing existing infrastructure? That would allow engines to add new elliptic curves with their names and OIDs similar to the table of asymmetric algorithms described above. This is necessary because national cryptographic algorithms typically use their own curves. what parameter do the GOST signatures curve have ? (I guess there's no non-russian description of this alg) GOST doesn't specify set of parameters. There are various implementations with different parameters. These parameters are typically choosen by vendors of cryptographic software, and should be approved by appropriate authorities if software is being certified. Several parameter sets are published, others are considered more or less trade secret of vendors. 5. To associate a particular message digest with a digital signature algorithm Also, some asymmetric algorithms require a particular message digest to be used when signing the (self-signed) certificate request. This digest type is required by the established standards and should override the one specified in the command line. don't know if it's good override a command line option but at least it should be the default digest alg OpenSSL already does so for DSA algorithm. Our proposal in this place aims for backward compatibility. For DSA it is dss1, for the GOST signature algorithms it is the GOST message digest and so on. This can be handled also by adding one more field for a message digest identifier to the EVP_ASYMMETRIC structure. this isn't really sufficient, better would something like STACK_OF(digest id) as, for example, the next x9.62 (ecdsa) standard will allow to restrict the use of a public key to a set of digests. I.e. make relation between MDs and signature algorithms bi-directional? MD structure now contains an array of NIDs of appropriate signature algoritms. ... 7. Provide callbacks for packing and unpacking the public keys. 8. Provide callbacks for packing and unpacking of a signature objects These callbacks already exist in the message digest structure. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
