xca compilation error on Ubuntu hardy x86_64
Hi, I'm trying to package xca for Ubuntu, and I'm running into the same problem discussed here: http://fixunix.com/openssl/511998-openssl-org-1721-compilation-error-ubuntu-hardy-x86_64-a.html I am using: ii openssl 0.9.8g-4ubuntu3.4 Secure Socket Layer (SSL) binary and related cryptographic I was wondering what the best solution is. The author suggests a change in OpenSSL itself; it seems to me that I have a few choices. 1) Figure out a way to fix it in xca 2) It has already been fixed in the latest openssl, need to package that 3) Patch it locally in the Ubuntu package What do you think? -- Obama Nation | It's not like I'm encrypting... it's more like I've developed a massive entropy deficiency | http://www.subsubpacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Help crash on IO_proc_close/ CRYPTO_free !
Hi, Core 1 -- (gdb) bt #0 0x4021e76e in pclose () from /lib/libc.so.6 #1 0x4021e548 in _IO_proc_close () from /lib/libc.so.6 #2 0x400b4772 in CRYPTO_free (str=0x0) at mem.c:380 (gdb) And if I read that backtrace in the correct direction, Sorry to interrupt, but no, you didn't read it in the correct direction. It's pclose being called by _IO_proc_close which in turn was called by CRYPTO_free... _I_ would suspect my own code and since this yaks about a pclose() my first question to the team would be: what have we got on pipes in our project? And see if you can put some diagnostics around it. Either that or a completely corrupted stack or heap, in which case something like valgrind or purify is probably going to be helpful in finding the _real_ problem. And while you're at it, and assuming you're in a multithreaded app, check whether the OpenSSL thread lock hooks are done properly, just to cover all the bases. (snipp) My bet is some part of your software has gone totally bonkers. With OpenSSL being part of the collateral. Agreed. Regards, Stefan __ 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. __ 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),
x509 parsing
Hi, I want to parse the x509 certficate in my application using the openssl API not the command line tool. Can anybody help me ? Regards, Vinod -- _ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _
Bug in IBM contributed AES-CCM code
The routine AES_CCM_inc() keeps propagating the carry from an overflow,
which means our implementation fails for large blocks of data.
The following code fragment should address that bug.
/*! @brief
Increment the CCM CTR, which is variable length, big endian
@param counter the counter to increment
@param q the number of bytes in the counter
*/
static void AES_CCM_inc(unsigned char *counter,unsigned q) {
int i;
for(i = 15; q 0 ; i--,q--) {
counter[i]++;
if(0 != counter[i] ) break;
}
}
I'll post a full update to the request tracker when things ease up in my
day job.
Peter
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Help crash on IO_proc_close/ CRYPTO_free !
On Wed, Mar 18, 2009 at 11:29 AM, stefan.n...@t-online.de wrote: Hi, Core 1 -- (gdb) bt #0 0x4021e76e in pclose () from /lib/libc.so.6 #1 0x4021e548 in _IO_proc_close () from /lib/libc.so.6 #2 0x400b4772 in CRYPTO_free (str=0x0) at mem.c:380 (gdb) And if I read that backtrace in the correct direction, Sorry to interrupt, but no, you didn't read it in the correct direction. It's pclose being called by _IO_proc_close which in turn was called by CRYPTO_free... Yes, I see that now. Thanks for correcting my assumptions! This implies (assuming a 'good' stacktrace) they've very probably hooked some pipe-based debug hook functions into CRYPTO_free() (one can do that sort of thing), but that's 'advanced usage' and should immediately have led internally to a 'hm, let's check our debug tracing/logging code hooks, eh?' sort of response. Ah well... Either that or a completely corrupted stack or heap, in which case something like valgrind or purify is probably going to be helpful in finding the _real_ problem. Yup. (Reading that stacktrace this way, I'd say it's a plausible trace, which means the error is in an unmatched popen/pclose pair in some user debug code - which is a good case for using purify to help dig this one out - or does valgrind check handles as well these days? The bit that's makes it extra 'hmmm' is no stacktrace beyond the CRYPO_free() invocation.) -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Re: [openssl.org #1867] About OpenSSL crashed in 0.9.8g
2009/3/18 zlgodguy zlgod...@163.com: hi: very thanks for your response. but i have tested it. if i comment this assert. the DTLS will hung in somewhere offten. i also don't know why. any suggestion? No idea; that was the easy try. See these URLs for someone who's actually been using DTLS and offers several bugfixes (was posted on this ML in another thread): http://sctp.fh-muenster.de/dtls-patches.html http://sctp.fh-muenster.de/index.html Maybe those can get you any further. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: x509 parsing
Ger Hobbelt wrote: Depends on what you consider 'parse': check out the sample source in apps/x509.c and apps/asn1parse.c, among others. Also check out the X509_get_() functions documentation (and for actually parsing a cert, there's PEM_read_bio_X509_AUX(), for example). For a completely different approach, you might examine certificateValidate() in the OpenLDAP source code. http://www.openldap.org/devel/cvsweb.cgi/~checkout~/servers/slapd/schema_init.c It uses the OpenLDAP liblber to parse an X.509 certificate. Since we now support GnuTLS and MozillaNSS in addition to OpenSSL, I decided it was better to use our own ASN.1 library instead of the OpenSSL-specific functions we used to use. Our code does pretty minimal actual validation checks, but it shows you how to get at the individual fields if you want to inspect them yourself. As Ger implied, parse can mean a lot of different things. On Wed, Mar 18, 2009 at 4:22 PM, Vinod Chaudhary vinod.chaudh...@einfochips.com wrote: Hi, I want to parse the x509 certficate in my application using the openssl API not the command line tool. Can anybody help me ? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
