From rsalz at akamai.com Thu Feb 2 18:31:10 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 2 Feb 2017 18:31:10 +0000 Subject: [openssl-dev] Heads up -- RT tickets moving to GH issues Message-ID: <549831b2648e466fb66be830fc39a802@usma1ex-dag1mb3.msg.corp.akamai.com> Just to let you know, we found a tool to migrate RT to GitHub issues and will be doing that shortly. This will just about double the number of open issues we have and, unfortunately, push the existing (active ones) down a few pages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at roumenpetrov.info Fri Feb 3 07:08:19 2017 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Fri, 03 Feb 2017 09:08:19 +0200 Subject: [openssl-dev] [openssl.org #4681] Resolved: X.509 load method In-Reply-To: References: Message-ID: <58942C63.90000@roumenpetrov.info> Rich Salz via RT wrote: > According to our records, your request has been resolved. If you have any > further questions or concerns, please respond to this message. Resolved? Hmm, how to implement X.509 lookup method with 1.1+ API? Regards, Roumen Petrov From rsalz at akamai.com Fri Feb 3 14:03:02 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 3 Feb 2017 14:03:02 +0000 Subject: [openssl-dev] [openssl.org #4681] Resolved: X.509 load method In-Reply-To: <58942C63.90000@roumenpetrov.info> References: <58942C63.90000@roumenpetrov.info> Message-ID: > Resolved? > Hmm, how to implement X.509 lookup method with 1.1+ API? It wasn't really resolved, it was moved to GH issue 2531. From yt8mn at virginia.edu Sun Feb 5 06:54:06 2017 From: yt8mn at virginia.edu (yuchi tian) Date: Sun, 5 Feb 2017 01:54:06 -0500 Subject: [openssl-dev] Bug reports and patches for OpenSSL Message-ID: Dear OpenSSL developers, We are software engineering researchers at University of Virginia. As part of a research project, we have built a tool for automatically finding and fixing error handling bugs and are testing it on various cryptographic libraries and applications that use them. In the most recent version of OpenSSL, we discovered various instances where there may be memory leak on error path, potential error propagation or missing check of function call. And we also give a patch for each potential bug. Please let us know how you intend to address these issues. 1: https://github.com/openssl/openssl/blob/master/apps/ts.c line 891, BIO_new_file(data, "rb") bug info: memory leak on error path patch: --- a/apps/ts.c +++ b/apps/ts.c @@ -878,6 +878,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char *data, co { TS_VERIFY_CTX *ctx = NULL; BIO *input = NULL; + BIO *out = NULL; TS_REQ *request = NULL; int ret = 0; int f = 0; @@ -888,7 +889,8 @@ static TS_VERIFY_CTX *create_verify_ctx(const char *data, co f = TS_VFY_VERSION | TS_VFY_SIGNER; if (data != NULL) { f |= TS_VFY_DATA; - if (TS_VERIFY_CTX_set_data(ctx, BIO_new_file(data, "rb")) == NULL) + out = BIO_new_file(data, "rb") + if (TS_VERIFY_CTX_set_data(ctx, out) == NULL) goto err; } else if (digest != NULL) { long imprint_len; @@ -931,6 +933,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char *data, co } BIO_free_all(input); TS_REQ_free(request); + BIO_free_all(out) return ctx; } 2: https://github.com/openssl/openssl/blob/master/crypto/dh/dh_gen.c line 75,77, ret->p = BN_new() bug info: memory leak on error path patch: @@ -126,5 +126,7 @@ static int dh_builtin_genparams(DH *ret, int prime_len, int BN_CTX_end(ctx); BN_CTX_free(ctx); } + if(ret->p!=NULL)BN_free(ret->p); + if(ret->g!=NULL)BN_free(ret->g); return ok; } 3: https://github.com/openssl/openssl/blob/master/crypto/ec/ec_key.c line 117, dest->priv_key = BN_new(); bug info: memory leak on error path patch: @@ -119,9 +119,11 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) return NULL; } if (!BN_copy(dest->priv_key, src->priv_key)) + BN_free(dest->priv_key) return NULL; if (src->group->meth->keycopy && src->group->meth->keycopy(dest, src) == 0) + BN_free(dest->priv_key) return NULL; } } @@ -134,6 +136,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) dest->flags = src->flags; if (!CRYPTO_dup_ex_data(CRYPTO_EX_INDEX_EC_KEY, &dest->ex_data, &src->ex_data)) + BN_free(dest->priv_key) return NULL; if (src->meth != dest->meth) { @@ -146,6 +149,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) } if (src->meth->copy != NULL && src->meth->copy(dest, src) == 0) + BN_free(dest->priv_key) return NULL; return dest; 4:(solved in the recent commit) https://github.com/openssl/openssl/blob/master/crypto/asn1/a_digest.c line 33, str = OPENSSL_malloc(i)); bug info: memory leak on error path patch: OPENSSL_free(str); patch location: 41 5: https://github.com/openssl/openssl/blob/master/crypto/asn1/bio_ndef.c line 116,185, p = OPENSSL_malloc(derlen); bug info: memory leak on error path patch: @@ -122,6 +122,7 @@ static int ndef_prefix(BIO *b, unsigned char **pbuf, int *pl derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); if (!*ndef_aux->boundary) + OPENSSL_free(p); return 0; *plen = *ndef_aux->boundary - *pbuf; @@ -191,6 +192,7 @@ static int ndef_suffix(BIO *b, unsigned char **pbuf, int *pl derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); if (!*ndef_aux->boundary) + OPENSSL_free(p); return 0; *pbuf = *ndef_aux->boundary; *plen = derlen - (*ndef_aux->boundary - ndef_aux->derbuf); 6: https://github.com/openssl/openssl/blob/master/crypto/bio/bss_bio.c line 625, b1->buf = OPENSSL_malloc(b1->size); bug info: memory leak on error path patch: @@ -635,6 +635,7 @@ static int bio_make_pair(BIO *bio1, BIO *bio2) b2->buf = OPENSSL_malloc(b2->size); if (b2->buf == NULL) { BIOerr(BIO_F_BIO_MAKE_PAIR, ERR_R_MALLOC_FAILURE); + OPENSSL_free(b1->buf); return 0; } b2->len = 0; 7: https://github.com/openssl/openssl/blob/master/crypto/ec/ec_ameth.c line 244, ep = OPENSSL_malloc(eplen); bug info: memory leak on error path patch: @@ -255,6 +255,7 @@ static int eckey_priv_encode(PKCS8_PRIV_KEY_INFO *p8, const if (!PKCS8_pkey_set0(p8, OBJ_nid2obj(NID_X9_62_id_ecPublicKey), 0, ptype, pval, ep, eplen)) + OPENSSL_free(ep); return 0; return 1; 8: https://github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c line 1833, return 0; bug info: Error propagation patch: @@ -1830,7 +1830,7 @@ int SSL_COMP_add_compression_method(int id, COMP_METHOD *c if (id < 193 || id > 255) { SSLerr(SSL_F_SSL_COMP_ADD_COMPRESSION_METHOD, SSL_R_COMPRESSION_ID_NOT_WITHIN_PRIVATE_RANGE); - return 0; + return 1; } CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE); 9: https://github.com/openssl/openssl/blob/master/ssl/t1_enc.c line 370, return (1); bug info: Error propagation line 388, p = OPENSSL_malloc(num) bug info: memory leak on error path patch: @@ -367,7 +367,7 @@ int tls1_setup_key_block(SSL *s) int ret = 0; if (s->s3->tmp.key_block_length != 0) - return (1); + return (0); if (!ssl_cipher_get_evp (s->session, &c, &hash, &mac_type, &mac_secret_size, &comp, @@ -448,6 +448,7 @@ int tls1_setup_key_block(SSL *s) ret = 1; err: + OPENSSL_free(p); return (ret); } 10: https://github.com/openssl/openssl/blob/master/ssl/s3_enc.c line 301, bug info: missing check line 270, bug info: error propagation line 295, bug info: memory leak on error path patch: @@ -268,7 +268,7 @@ int ssl3_setup_key_block(SSL *s) SSL_COMP *comp; if (s->s3->tmp.key_block_length != 0) - return (1); + return (0); if (!ssl_cipher_get_evp(s->session, &c, &hash, NULL, NULL, &comp, 0)) { SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, SSL_R_CIPHER_OR_HASH_UNAVAILABLE); @@ -299,6 +299,7 @@ int ssl3_setup_key_block(SSL *s) s->s3->tmp.key_block = p; ret = ssl3_generate_key_block(s, p, num); + if (ret==0) goto err; if (!(s->options & SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS)) { /* @@ -317,11 +318,12 @@ int ssl3_setup_key_block(SSL *s) #endif } } - + ret = 1 return ret; err: SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, ERR_R_MALLOC_FAILURE); + OPENSSL_free(p); return (0); } Others: memory leak on error path test/bntest.c test/evp_test.c Sincerely, Baishakhi Ray, Yuchi Tian -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanno at hboeck.de Sun Feb 5 11:16:57 2017 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Sun, 5 Feb 2017 12:16:57 +0100 Subject: [openssl-dev] Bug reports and patches for OpenSSL In-Reply-To: References: Message-ID: <20170205121657.06511029@pc1> On Sun, 5 Feb 2017 01:54:06 -0500 yuchi tian wrote: > We are software engineering researchers at University of Virginia. As > part of a research project, we have built a tool for automatically > finding and fixing error handling bugs and are testing it on > various cryptographic libraries and applications that use them. I can't answer on how to best report those bugs, but: That sounds like interesting research. Will you make the tool and the corresponding scientific publication public? -- Hanno B?ck https://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From matt at openssl.org Sun Feb 5 13:49:21 2017 From: matt at openssl.org (Matt Caswell) Date: Sun, 5 Feb 2017 13:49:21 +0000 Subject: [openssl-dev] Bug reports and patches for OpenSSL In-Reply-To: References: Message-ID: On 05/02/17 06:54, yuchi tian wrote: > Dear OpenSSL developers, > > We are software engineering researchers at University of Virginia. As > part of a research project, we have built a tool for automatically > finding and fixing error handling bugs and are testing it on > various cryptographic libraries and applications that use them. > > In the most recent version of OpenSSL, we discovered various instances > where there may be memory leak on error path, potential error > propagation or missing check of function call. And we also give a patch > for each potential bug. > > Please let us know how you intend to address these issues. Guidance for how to correctly submit patches is given in the CONTRIBUTING file here: https://github.com/openssl/openssl/blob/master/CONTRIBUTING Please could you submit your fixes as a github pull request? One pull request for all of these issues should be fine. We will also need a CLA from all authors: https://www.openssl.org/policies/cla.html Thanks! Matt > > 1: > https://github.com/openssl/openssl/blob/master/apps/ts.c > line 891, BIO_new_file(data, "rb") > bug info: memory leak on error path > patch: > > --- a/apps/ts.c > +++ b/apps/ts.c > @@ -878,6 +878,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > *data, co > { > TS_VERIFY_CTX *ctx = NULL; > BIO *input = NULL; > + BIO *out = NULL; > TS_REQ *request = NULL; > int ret = 0; > int f = 0; > @@ -888,7 +889,8 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > *data, co > f = TS_VFY_VERSION | TS_VFY_SIGNER; > if (data != NULL) { > f |= TS_VFY_DATA; > - if (TS_VERIFY_CTX_set_data(ctx, BIO_new_file(data, "rb")) > == NULL) > + out = BIO_new_file(data, "rb") > + if (TS_VERIFY_CTX_set_data(ctx, out) == NULL) > goto err; > } else if (digest != NULL) { > long imprint_len; > @@ -931,6 +933,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > *data, co > } > BIO_free_all(input); > TS_REQ_free(request); > + BIO_free_all(out) > return ctx; > } > > > > 2: > https://github.com/openssl/openssl/blob/master/crypto/dh/dh_gen.c > line 75,77, ret->p = BN_new() > bug info: memory leak on error path > patch: > @@ -126,5 +126,7 @@ static int dh_builtin_genparams(DH *ret, int > prime_len, int > BN_CTX_end(ctx); > BN_CTX_free(ctx); > } > + if(ret->p!=NULL)BN_free(ret->p); > + if(ret->g!=NULL)BN_free(ret->g); > return ok; > } > > > 3: > https://github.com/openssl/openssl/blob/master/crypto/ec/ec_key.c > line 117, dest->priv_key = BN_new(); > bug info: memory leak on error path > patch: > > @@ -119,9 +119,11 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > return NULL; > } > if (!BN_copy(dest->priv_key, src->priv_key)) > + BN_free(dest->priv_key) > return NULL; > if (src->group->meth->keycopy > && src->group->meth->keycopy(dest, src) == 0) > + BN_free(dest->priv_key) > return NULL; > } > } > @@ -134,6 +136,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > dest->flags = src->flags; > if (!CRYPTO_dup_ex_data(CRYPTO_EX_INDEX_EC_KEY, > &dest->ex_data, &src->ex_data)) > + BN_free(dest->priv_key) > return NULL; > > if (src->meth != dest->meth) { > @@ -146,6 +149,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > } > > if (src->meth->copy != NULL && src->meth->copy(dest, src) == 0) > + BN_free(dest->priv_key) > return NULL; > > return dest; > > > 4:(solved in the recent commit) > https://github.com/openssl/openssl/blob/master/crypto/asn1/a_digest.c > line 33, str = OPENSSL_malloc(i)); > bug info: memory leak on error path > patch: OPENSSL_free(str); > patch location: 41 > > 5: > https://github.com/openssl/openssl/blob/master/crypto/asn1/bio_ndef.c > line 116,185, p = OPENSSL_malloc(derlen); > bug info: memory leak on error path > patch: > > @@ -122,6 +122,7 @@ static int ndef_prefix(BIO *b, unsigned char **pbuf, > int *pl > derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); > > if (!*ndef_aux->boundary) > + OPENSSL_free(p); > return 0; > > *plen = *ndef_aux->boundary - *pbuf; > @@ -191,6 +192,7 @@ static int ndef_suffix(BIO *b, unsigned char **pbuf, > int *pl > derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); > > if (!*ndef_aux->boundary) > + OPENSSL_free(p); > return 0; > *pbuf = *ndef_aux->boundary; > *plen = derlen - (*ndef_aux->boundary - ndef_aux->derbuf); > > 6: > https://github.com/openssl/openssl/blob/master/crypto/bio/bss_bio.c > line 625, b1->buf = OPENSSL_malloc(b1->size); > bug info: memory leak on error path > patch: > > @@ -635,6 +635,7 @@ static int bio_make_pair(BIO *bio1, BIO *bio2) > b2->buf = OPENSSL_malloc(b2->size); > if (b2->buf == NULL) { > BIOerr(BIO_F_BIO_MAKE_PAIR, ERR_R_MALLOC_FAILURE); > + OPENSSL_free(b1->buf); > return 0; > } > b2->len = 0; > > 7: > https://github.com/openssl/openssl/blob/master/crypto/ec/ec_ameth.c > line 244, ep = OPENSSL_malloc(eplen); > bug info: memory leak on error path > patch: > @@ -255,6 +255,7 @@ static int eckey_priv_encode(PKCS8_PRIV_KEY_INFO > *p8, const > > if (!PKCS8_pkey_set0(p8, OBJ_nid2obj(NID_X9_62_id_ecPublicKey), 0, > ptype, pval, ep, eplen)) > + OPENSSL_free(ep); > return 0; > > return 1; > > > 8: > https://github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c > line 1833, return 0; > bug info: Error propagation > patch: > @@ -1830,7 +1830,7 @@ int SSL_COMP_add_compression_method(int id, > COMP_METHOD *c > if (id < 193 || id > 255) { > SSLerr(SSL_F_SSL_COMP_ADD_COMPRESSION_METHOD, > SSL_R_COMPRESSION_ID_NOT_WITHIN_PRIVATE_RANGE); > - return 0; > + return 1; > } > > CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE); > > > 9: > https://github.com/openssl/openssl/blob/master/ssl/t1_enc.c > line 370, return (1); > bug info: Error propagation > > line 388, p = OPENSSL_malloc(num) > bug info: memory leak on error path > > patch: > @@ -367,7 +367,7 @@ int tls1_setup_key_block(SSL *s) > int ret = 0; > > if (s->s3->tmp.key_block_length != 0) > - return (1); > + return (0); > > if (!ssl_cipher_get_evp > (s->session, &c, &hash, &mac_type, &mac_secret_size, &comp, > @@ -448,6 +448,7 @@ int tls1_setup_key_block(SSL *s) > > ret = 1; > err: > + OPENSSL_free(p); > return (ret); > } > > > > 10: > https://github.com/openssl/openssl/blob/master/ssl/s3_enc.c > line 301, > bug info: missing check > line 270, > bug info: error propagation > line 295, > bug info: memory leak on error path > patch: > > @@ -268,7 +268,7 @@ int ssl3_setup_key_block(SSL *s) > SSL_COMP *comp; > > if (s->s3->tmp.key_block_length != 0) > - return (1); > + return (0); > > if (!ssl_cipher_get_evp(s->session, &c, &hash, NULL, NULL, &comp, 0)) { > SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, > SSL_R_CIPHER_OR_HASH_UNAVAILABLE); > @@ -299,6 +299,7 @@ int ssl3_setup_key_block(SSL *s) > s->s3->tmp.key_block = p; > > ret = ssl3_generate_key_block(s, p, num); > + if (ret==0) goto err; > > if (!(s->options & SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS)) { > /* > @@ -317,11 +318,12 @@ int ssl3_setup_key_block(SSL *s) > #endif > } > } > - > + ret = 1 > return ret; > > err: > SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, ERR_R_MALLOC_FAILURE); > + OPENSSL_free(p); > return (0); > } > > Others: memory leak on error path > test/bntest.c > test/evp_test.c > > Sincerely, > Baishakhi Ray, Yuchi Tian > > From levitte at openssl.org Sun Feb 5 15:47:46 2017 From: levitte at openssl.org (Richard Levitte) Date: Sun, 05 Feb 2017 16:47:46 +0100 (CET) Subject: [openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir Message-ID: <20170205.164746.1808329431647870815.levitte@openssl.org> Hi, I've some ponderings that I need to bounce a bit with you all. Some have talked about replace the X509_LOOKUP_METHOD bit with the STORE module I'm building, and while STORE isn't ready for it yet, I have some thoughts on how the two can approach each other. This would involve one or two hooks / callbacks, that a STORE user could specify (details later) to pick and choose freely among the objects that the STORE module finds (be it on file or whatever else that can be represented as a URI). The troublesome part would be to try to mimic by_dir... It highly depends on the specified paths to really be directories, and that it should find what it wants by adding very specific file names (a hash of the subject name with a ".{n}" or ".r{n}" extension for X.509 certs and for X.509 CRLs). And sure, that works, but will really only work with regular files. What if someone would specify a LDAP URI that can return a bunch of objects? So... my ponderings are going along these lines: 1. Should the directory X509_LOOKUPs be restricted to on disk directories, or should "directory" be redefined as "whatever URI that returns a collection of objects"? The latter would mean that all those objects get loaded and that a hook / callback would then be called to check if it's an object that corresponds to what we search for. 2. For on disk directories, should we preserve the rehash file form? In other words, if we decide to load everything we can find, shall we restrict the loading to files matching the regexp [0-9a-f]{8}\.r?[0-9]+ ? If not, are we about to create a new form of key store for ourselves and our users? Should we? Quite a lot also depends on what OpenSSL version we aim for. I would very much like to see the STORE module itself become part of 1.1.1, but a new key store to replace our current rehash links will obviously have to wait 'til 1.2.0. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From yt8mn at virginia.edu Sun Feb 5 21:02:44 2017 From: yt8mn at virginia.edu (yuchi tian) Date: Sun, 5 Feb 2017 16:02:44 -0500 Subject: [openssl-dev] Bug reports and patches for OpenSSL In-Reply-To: <20170205121657.06511029@pc1> References: <20170205121657.06511029@pc1> Message-ID: > Will you make the tool and the corresponding scientific publication > public? Yes. We are currently in the step of evaluating our tools. We will submit our work and share our tools when the project is done. Sincerely, Yuchi Tian On Sun, Feb 5, 2017 at 6:16 AM, Hanno B?ck wrote: > On Sun, 5 Feb 2017 01:54:06 -0500 > yuchi tian wrote: > > > We are software engineering researchers at University of Virginia. As > > part of a research project, we have built a tool for automatically > > finding and fixing error handling bugs and are testing it on > > various cryptographic libraries and applications that use them. > > I can't answer on how to best report those bugs, but: > That sounds like interesting research. > > Will you make the tool and the corresponding scientific publication > public? > > -- > Hanno B?ck > https://hboeck.de/ > > mail/jabber: hanno at hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yt8mn at virginia.edu Sun Feb 5 21:07:58 2017 From: yt8mn at virginia.edu (yuchi tian) Date: Sun, 5 Feb 2017 16:07:58 -0500 Subject: [openssl-dev] Bug reports and patches for OpenSSL In-Reply-To: References: Message-ID: > Guidance for how to correctly submit patches is given in the > CONTRIBUTING file here: > https://github.com/openssl/openssl/blob/master/CONTRIBUTING > Please could you submit your fixes as a github pull request? One pull > request for all of these issues should be fine. Thank you for the information. I will submit the fixes as a github pull request. Sincerely, Yuchi Tian On Sun, Feb 5, 2017 at 8:49 AM, Matt Caswell wrote: > > > On 05/02/17 06:54, yuchi tian wrote: > > Dear OpenSSL developers, > > > > We are software engineering researchers at University of Virginia. As > > part of a research project, we have built a tool for automatically > > finding and fixing error handling bugs and are testing it on > > various cryptographic libraries and applications that use them. > > > > In the most recent version of OpenSSL, we discovered various instances > > where there may be memory leak on error path, potential error > > propagation or missing check of function call. And we also give a patch > > for each potential bug. > > > > Please let us know how you intend to address these issues. > > Guidance for how to correctly submit patches is given in the > CONTRIBUTING file here: > > https://github.com/openssl/openssl/blob/master/CONTRIBUTING > > Please could you submit your fixes as a github pull request? One pull > request for all of these issues should be fine. > > We will also need a CLA from all authors: > https://www.openssl.org/policies/cla.html > > Thanks! > > Matt > > > > > > > 1: > > https://github.com/openssl/openssl/blob/master/apps/ts.c > > line 891, BIO_new_file(data, "rb") > > bug info: memory leak on error path > > patch: > > > > --- a/apps/ts.c > > +++ b/apps/ts.c > > @@ -878,6 +878,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > > *data, co > > { > > TS_VERIFY_CTX *ctx = NULL; > > BIO *input = NULL; > > + BIO *out = NULL; > > TS_REQ *request = NULL; > > int ret = 0; > > int f = 0; > > @@ -888,7 +889,8 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > > *data, co > > f = TS_VFY_VERSION | TS_VFY_SIGNER; > > if (data != NULL) { > > f |= TS_VFY_DATA; > > - if (TS_VERIFY_CTX_set_data(ctx, BIO_new_file(data, "rb")) > > == NULL) > > + out = BIO_new_file(data, "rb") > > + if (TS_VERIFY_CTX_set_data(ctx, out) == NULL) > > goto err; > > } else if (digest != NULL) { > > long imprint_len; > > @@ -931,6 +933,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > > *data, co > > } > > BIO_free_all(input); > > TS_REQ_free(request); > > + BIO_free_all(out) > > return ctx; > > } > > > > > > > > 2: > > https://github.com/openssl/openssl/blob/master/crypto/dh/dh_gen.c > > line 75,77, ret->p = BN_new() > > bug info: memory leak on error path > > patch: > > @@ -126,5 +126,7 @@ static int dh_builtin_genparams(DH *ret, int > > prime_len, int > > BN_CTX_end(ctx); > > BN_CTX_free(ctx); > > } > > + if(ret->p!=NULL)BN_free(ret->p); > > + if(ret->g!=NULL)BN_free(ret->g); > > return ok; > > } > > > > > > 3: > > https://github.com/openssl/openssl/blob/master/crypto/ec/ec_key.c > > line 117, dest->priv_key = BN_new(); > > bug info: memory leak on error path > > patch: > > > > @@ -119,9 +119,11 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > > return NULL; > > } > > if (!BN_copy(dest->priv_key, src->priv_key)) > > + BN_free(dest->priv_key) > > return NULL; > > if (src->group->meth->keycopy > > && src->group->meth->keycopy(dest, src) == 0) > > + BN_free(dest->priv_key) > > return NULL; > > } > > } > > @@ -134,6 +136,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > > dest->flags = src->flags; > > if (!CRYPTO_dup_ex_data(CRYPTO_EX_INDEX_EC_KEY, > > &dest->ex_data, &src->ex_data)) > > + BN_free(dest->priv_key) > > return NULL; > > > > if (src->meth != dest->meth) { > > @@ -146,6 +149,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > > } > > > > if (src->meth->copy != NULL && src->meth->copy(dest, src) == 0) > > + BN_free(dest->priv_key) > > return NULL; > > > > return dest; > > > > > > 4:(solved in the recent commit) > > https://github.com/openssl/openssl/blob/master/crypto/asn1/a_digest.c > > line 33, str = OPENSSL_malloc(i)); > > bug info: memory leak on error path > > patch: OPENSSL_free(str); > > patch location: 41 > > > > 5: > > https://github.com/openssl/openssl/blob/master/crypto/asn1/bio_ndef.c > > line 116,185, p = OPENSSL_malloc(derlen); > > bug info: memory leak on error path > > patch: > > > > @@ -122,6 +122,7 @@ static int ndef_prefix(BIO *b, unsigned char **pbuf, > > int *pl > > derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); > > > > if (!*ndef_aux->boundary) > > + OPENSSL_free(p); > > return 0; > > > > *plen = *ndef_aux->boundary - *pbuf; > > @@ -191,6 +192,7 @@ static int ndef_suffix(BIO *b, unsigned char **pbuf, > > int *pl > > derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); > > > > if (!*ndef_aux->boundary) > > + OPENSSL_free(p); > > return 0; > > *pbuf = *ndef_aux->boundary; > > *plen = derlen - (*ndef_aux->boundary - ndef_aux->derbuf); > > > > 6: > > https://github.com/openssl/openssl/blob/master/crypto/bio/bss_bio.c > > line 625, b1->buf = OPENSSL_malloc(b1->size); > > bug info: memory leak on error path > > patch: > > > > @@ -635,6 +635,7 @@ static int bio_make_pair(BIO *bio1, BIO *bio2) > > b2->buf = OPENSSL_malloc(b2->size); > > if (b2->buf == NULL) { > > BIOerr(BIO_F_BIO_MAKE_PAIR, ERR_R_MALLOC_FAILURE); > > + OPENSSL_free(b1->buf); > > return 0; > > } > > b2->len = 0; > > > > 7: > > https://github.com/openssl/openssl/blob/master/crypto/ec/ec_ameth.c > > line 244, ep = OPENSSL_malloc(eplen); > > bug info: memory leak on error path > > patch: > > @@ -255,6 +255,7 @@ static int eckey_priv_encode(PKCS8_PRIV_KEY_INFO > > *p8, const > > > > if (!PKCS8_pkey_set0(p8, OBJ_nid2obj(NID_X9_62_id_ecPublicKey), 0, > > ptype, pval, ep, eplen)) > > + OPENSSL_free(ep); > > return 0; > > > > return 1; > > > > > > 8: > > https://github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c > > line 1833, return 0; > > bug info: Error propagation > > patch: > > @@ -1830,7 +1830,7 @@ int SSL_COMP_add_compression_method(int id, > > COMP_METHOD *c > > if (id < 193 || id > 255) { > > SSLerr(SSL_F_SSL_COMP_ADD_COMPRESSION_METHOD, > > SSL_R_COMPRESSION_ID_NOT_WITHIN_PRIVATE_RANGE); > > - return 0; > > + return 1; > > } > > > > CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE); > > > > > > 9: > > https://github.com/openssl/openssl/blob/master/ssl/t1_enc.c > > line 370, return (1); > > bug info: Error propagation > > > > line 388, p = OPENSSL_malloc(num) > > bug info: memory leak on error path > > > > patch: > > @@ -367,7 +367,7 @@ int tls1_setup_key_block(SSL *s) > > int ret = 0; > > > > if (s->s3->tmp.key_block_length != 0) > > - return (1); > > + return (0); > > > > if (!ssl_cipher_get_evp > > (s->session, &c, &hash, &mac_type, &mac_secret_size, &comp, > > @@ -448,6 +448,7 @@ int tls1_setup_key_block(SSL *s) > > > > ret = 1; > > err: > > + OPENSSL_free(p); > > return (ret); > > } > > > > > > > > 10: > > https://github.com/openssl/openssl/blob/master/ssl/s3_enc.c > > line 301, > > bug info: missing check > > line 270, > > bug info: error propagation > > line 295, > > bug info: memory leak on error path > > patch: > > > > @@ -268,7 +268,7 @@ int ssl3_setup_key_block(SSL *s) > > SSL_COMP *comp; > > > > if (s->s3->tmp.key_block_length != 0) > > - return (1); > > + return (0); > > > > if (!ssl_cipher_get_evp(s->session, &c, &hash, NULL, NULL, &comp, > 0)) { > > SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, > > SSL_R_CIPHER_OR_HASH_UNAVAILABLE); > > @@ -299,6 +299,7 @@ int ssl3_setup_key_block(SSL *s) > > s->s3->tmp.key_block = p; > > > > ret = ssl3_generate_key_block(s, p, num); > > + if (ret==0) goto err; > > > > if (!(s->options & SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS)) { > > /* > > @@ -317,11 +318,12 @@ int ssl3_setup_key_block(SSL *s) > > #endif > > } > > } > > - > > + ret = 1 > > return ret; > > > > err: > > SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, ERR_R_MALLOC_FAILURE); > > + OPENSSL_free(p); > > return (0); > > } > > > > Others: memory leak on error path > > test/bntest.c > > test/evp_test.c > > > > Sincerely, > > Baishakhi Ray, Yuchi Tian > > > > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Mon Feb 6 10:15:19 2017 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 06 Feb 2017 11:15:19 +0100 Subject: [openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir In-Reply-To: <20170205.164746.1808329431647870815.levitte@openssl.org> References: <20170205.164746.1808329431647870815.levitte@openssl.org> Message-ID: <1486376119.20592.23.camel@redhat.com> On Sun, 2017-02-05 at 16:47 +0100, Richard Levitte wrote: > Hi, > > I've some ponderings that I need to bounce a bit with you all. > > Some have talked about replace the X509_LOOKUP_METHOD bit with the > STORE module I'm building, and while STORE isn't ready for it yet, I > have some thoughts on how the two can approach each other.??This > would > involve one or two hooks / callbacks, that a STORE user could specify > (details later) to pick and choose freely among the objects that the > STORE module finds (be it on file or whatever else that can be > represented as a URI). Just to add something to your thinking - so there is a p11-kit-trust PKCS11 module which provides all the CA certificates that should be trusted on the system via individual PKCS11 certificate objects. Could it be somehow accommodated with the STORE module approach? Mozilla NSS and GnuTLS can use this PKCS11 module directly as a trust store, we would like to add the same functionality to OpenSSL. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From Lars.Nordin at LNdata.se Mon Feb 6 21:59:54 2017 From: Lars.Nordin at LNdata.se (Lars Nordin) Date: Mon, 6 Feb 2017 22:59:54 +0100 Subject: [openssl-dev] Bug reports and patches for OpenSSL In-Reply-To: References: Message-ID: <7485e4d6-f55e-f4e8-80cf-1f311c28cef1@LNdata.se> On 2017-02-05 07:54, yuchi tian wrote: > Dear OpenSSL developers, > > We are software engineering researchers at University of Virginia. As > part of a research project, we have built a tool for automatically > finding and fixing error handling bugs and are testing it on > various cryptographic libraries and applications that use them. > > In the most recent version of OpenSSL, we discovered various instances > where there may be memory leak on error path, potential error > propagation or missing check of function call. And we also give a > patch for each potential bug. > > Please let us know how you intend to address these issues. > > 1: > https://github.com/openssl/openssl/blob/master/apps/ts.c > line 891, BIO_new_file(data, "rb") > bug info: memory leak on error path > patch: > > --- a/apps/ts.c > +++ b/apps/ts.c > @@ -878,6 +878,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > *data, co > { > TS_VERIFY_CTX *ctx = NULL; > BIO *input = NULL; > + BIO *out = NULL; > TS_REQ *request = NULL; > int ret = 0; > int f = 0; > @@ -888,7 +889,8 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > *data, co > f = TS_VFY_VERSION | TS_VFY_SIGNER; > if (data != NULL) { > f |= TS_VFY_DATA; > - if (TS_VERIFY_CTX_set_data(ctx, BIO_new_file(data, "rb")) > == NULL) > + out = BIO_new_file(data, "rb") > + if (TS_VERIFY_CTX_set_data(ctx, out) == NULL) > goto err; > } else if (digest != NULL) { > long imprint_len; > @@ -931,6 +933,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > *data, co > } > BIO_free_all(input); > TS_REQ_free(request); > + BIO_free_all(out) > return ctx; > } > > > > 2: > https://github.com/openssl/openssl/blob/master/crypto/dh/dh_gen.c > line 75,77, ret->p = BN_new() > bug info: memory leak on error path > patch: > @@ -126,5 +126,7 @@ static int dh_builtin_genparams(DH *ret, int > prime_len, int > BN_CTX_end(ctx); > BN_CTX_free(ctx); > } > + if(ret->p!=NULL)BN_free(ret->p); > + if(ret->g!=NULL)BN_free(ret->g); > return ok; > } > > > 3: > https://github.com/openssl/openssl/blob/master/crypto/ec/ec_key.c > line 117, dest->priv_key = BN_new(); > bug info: memory leak on error path > patch: > > @@ -119,9 +119,11 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > return NULL; > } > if (!BN_copy(dest->priv_key, src->priv_key)) > + BN_free(dest->priv_key) > return NULL; > if (src->group->meth->keycopy > && src->group->meth->keycopy(dest, src) == 0) > + BN_free(dest->priv_key) The tool need can't just add an extra line for an if-statement without {} > return NULL; > } > } > @@ -134,6 +136,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > dest->flags = src->flags; > if (!CRYPTO_dup_ex_data(CRYPTO_EX_INDEX_EC_KEY, > &dest->ex_data, &src->ex_data)) > + BN_free(dest->priv_key) Same comment! > return NULL; > if (src->meth != dest->meth) { > @@ -146,6 +149,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > } > if (src->meth->copy != NULL && src->meth->copy(dest, src) == 0) > + BN_free(dest->priv_key) > return NULL; Another one > return dest; > > > 4:(solved in the recent commit) > https://github.com/openssl/openssl/blob/master/crypto/asn1/a_digest.c > line 33, str = OPENSSL_malloc(i)); > bug info: memory leak on error path > patch: OPENSSL_free(str); > patch location: 41 > > 5: > https://github.com/openssl/openssl/blob/master/crypto/asn1/bio_ndef.c > line 116,185, p = OPENSSL_malloc(derlen); > bug info: memory leak on error path > patch: > > @@ -122,6 +122,7 @@ static int ndef_prefix(BIO *b, unsigned char > **pbuf, int *pl > derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); > if (!*ndef_aux->boundary) > + OPENSSL_free(p); > return 0; And again > *plen = *ndef_aux->boundary - *pbuf; > @@ -191,6 +192,7 @@ static int ndef_suffix(BIO *b, unsigned char > **pbuf, int *pl > derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); > if (!*ndef_aux->boundary) > + OPENSSL_free(p); > return 0; And again > *pbuf = *ndef_aux->boundary; > *plen = derlen - (*ndef_aux->boundary - ndef_aux->derbuf); > > 6: > https://github.com/openssl/openssl/blob/master/crypto/bio/bss_bio.c > line 625, b1->buf = OPENSSL_malloc(b1->size); > bug info: memory leak on error path > patch: > > @@ -635,6 +635,7 @@ static int bio_make_pair(BIO *bio1, BIO *bio2) > b2->buf = OPENSSL_malloc(b2->size); > if (b2->buf == NULL) { > BIOerr(BIO_F_BIO_MAKE_PAIR, ERR_R_MALLOC_FAILURE); > + OPENSSL_free(b1->buf); > return 0; > } > b2->len = 0; > > 7: > https://github.com/openssl/openssl/blob/master/crypto/ec/ec_ameth.c > line 244, ep = OPENSSL_malloc(eplen); > bug info: memory leak on error path > patch: > @@ -255,6 +255,7 @@ static int eckey_priv_encode(PKCS8_PRIV_KEY_INFO > *p8, const > if (!PKCS8_pkey_set0(p8, OBJ_nid2obj(NID_X9_62_id_ecPublicKey), 0, > ptype, pval, ep, eplen)) > + OPENSSL_free(ep); > return 0; Another > return 1; > > > 8: > https://github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c > line 1833, return 0; > bug info: Error propagation > patch: > @@ -1830,7 +1830,7 @@ int SSL_COMP_add_compression_method(int id, > COMP_METHOD *c > if (id < 193 || id > 255) { > SSLerr(SSL_F_SSL_COMP_ADD_COMPRESSION_METHOD, > SSL_R_COMPRESSION_ID_NOT_WITHIN_PRIVATE_RANGE); > - return 0; > + return 1; > } > CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE); > > > 9: > https://github.com/openssl/openssl/blob/master/ssl/t1_enc.c > line 370, return (1); > bug info: Error propagation > > line 388, p = OPENSSL_malloc(num) > bug info: memory leak on error path > > patch: > @@ -367,7 +367,7 @@ int tls1_setup_key_block(SSL *s) > int ret = 0; > if (s->s3->tmp.key_block_length != 0) > - return (1); > + return (0); > if (!ssl_cipher_get_evp > (s->session, &c, &hash, &mac_type, &mac_secret_size, &comp, > @@ -448,6 +448,7 @@ int tls1_setup_key_block(SSL *s) > ret = 1; > err: > + OPENSSL_free(p); > return (ret); > } > > > > 10: > https://github.com/openssl/openssl/blob/master/ssl/s3_enc.c > line 301, > bug info: missing check > line 270, > bug info: error propagation > line 295, > bug info: memory leak on error path > patch: > > @@ -268,7 +268,7 @@ int ssl3_setup_key_block(SSL *s) > SSL_COMP *comp; > if (s->s3->tmp.key_block_length != 0) > - return (1); > + return (0); > if (!ssl_cipher_get_evp(s->session, &c, &hash, NULL, NULL, &comp, > 0)) { > SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, > SSL_R_CIPHER_OR_HASH_UNAVAILABLE); > @@ -299,6 +299,7 @@ int ssl3_setup_key_block(SSL *s) > s->s3->tmp.key_block = p; > ret = ssl3_generate_key_block(s, p, num); > + if (ret==0) goto err; > if (!(s->options & SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS)) { > /* > @@ -317,11 +318,12 @@ int ssl3_setup_key_block(SSL *s) > #endif > } > } > - > + ret = 1 > return ret; > err: > SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, ERR_R_MALLOC_FAILURE); > + OPENSSL_free(p); > return (0); > } > > Others: memory leak on error path > test/bntest.c > test/evp_test.c > > Sincerely, > Baishakhi Ray, Yuchi Tian > > /Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From yt8mn at virginia.edu Mon Feb 6 22:32:30 2017 From: yt8mn at virginia.edu (yuchi tian) Date: Mon, 6 Feb 2017 17:32:30 -0500 Subject: [openssl-dev] Bug reports and patches for OpenSSL In-Reply-To: <7485e4d6-f55e-f4e8-80cf-1f311c28cef1@LNdata.se> References: <7485e4d6-f55e-f4e8-80cf-1f311c28cef1@LNdata.se> Message-ID: Thank you for pointing out. That is not what I expect, but very important point for fix. Sincerely, Yuchi Tian On Mon, Feb 6, 2017 at 4:59 PM, Lars Nordin wrote: > On 2017-02-05 07:54, yuchi tian wrote: > > Dear OpenSSL developers, > > We are software engineering researchers at University of Virginia. As part > of a research project, we have built a tool for automatically finding and > fixing error handling bugs and are testing it on > various cryptographic libraries and applications that use them. > > In the most recent version of OpenSSL, we discovered various instances > where there may be memory leak on error path, potential error propagation > or missing check of function call. And we also give a patch for each > potential bug. > > Please let us know how you intend to address these issues. > > 1: > https://github.com/openssl/openssl/blob/master/apps/ts.c > line 891, BIO_new_file(data, "rb") > bug info: memory leak on error path > patch: > > --- a/apps/ts.c > +++ b/apps/ts.c > @@ -878,6 +878,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > *data, co > { > TS_VERIFY_CTX *ctx = NULL; > BIO *input = NULL; > + BIO *out = NULL; > TS_REQ *request = NULL; > int ret = 0; > int f = 0; > @@ -888,7 +889,8 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > *data, co > f = TS_VFY_VERSION | TS_VFY_SIGNER; > if (data != NULL) { > f |= TS_VFY_DATA; > - if (TS_VERIFY_CTX_set_data(ctx, BIO_new_file(data, "rb")) == > NULL) > + out = BIO_new_file(data, "rb") > + if (TS_VERIFY_CTX_set_data(ctx, out) == NULL) > goto err; > } else if (digest != NULL) { > long imprint_len; > @@ -931,6 +933,7 @@ static TS_VERIFY_CTX *create_verify_ctx(const char > *data, co > } > BIO_free_all(input); > TS_REQ_free(request); > + BIO_free_all(out) > return ctx; > } > > > > 2: > https://github.com/openssl/openssl/blob/master/crypto/dh/dh_gen.c > line 75,77, ret->p = BN_new() > bug info: memory leak on error path > patch: > @@ -126,5 +126,7 @@ static int dh_builtin_genparams(DH *ret, int > prime_len, int > BN_CTX_end(ctx); > BN_CTX_free(ctx); > } > + if(ret->p!=NULL)BN_free(ret->p); > + if(ret->g!=NULL)BN_free(ret->g); > return ok; > } > > > 3: > https://github.com/openssl/openssl/blob/master/crypto/ec/ec_key.c > line 117, dest->priv_key = BN_new(); > bug info: memory leak on error path > patch: > > @@ -119,9 +119,11 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > return NULL; > } > if (!BN_copy(dest->priv_key, src->priv_key)) > + BN_free(dest->priv_key) > return NULL; > if (src->group->meth->keycopy > && src->group->meth->keycopy(dest, src) == 0) > + BN_free(dest->priv_key) > > The tool need can't just add an extra line for an if-statement without {} > > return NULL; > } > } > @@ -134,6 +136,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > dest->flags = src->flags; > if (!CRYPTO_dup_ex_data(CRYPTO_EX_INDEX_EC_KEY, > &dest->ex_data, &src->ex_data)) > + BN_free(dest->priv_key) > > Same comment! > > return NULL; > > if (src->meth != dest->meth) { > @@ -146,6 +149,7 @@ EC_KEY *EC_KEY_copy(EC_KEY *dest, const EC_KEY *src) > } > > if (src->meth->copy != NULL && src->meth->copy(dest, src) == 0) > + BN_free(dest->priv_key) > return NULL; > > Another one > > > return dest; > > > 4:(solved in the recent commit) > https://github.com/openssl/openssl/blob/master/crypto/asn1/a_digest.c > line 33, str = OPENSSL_malloc(i)); > bug info: memory leak on error path > patch: OPENSSL_free(str); > patch location: 41 > > 5: > https://github.com/openssl/openssl/blob/master/crypto/asn1/bio_ndef.c > line 116,185, p = OPENSSL_malloc(derlen); > bug info: memory leak on error path > patch: > > @@ -122,6 +122,7 @@ static int ndef_prefix(BIO *b, unsigned char **pbuf, > int *pl > derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); > > if (!*ndef_aux->boundary) > + OPENSSL_free(p); > return 0; > > > And again > > *plen = *ndef_aux->boundary - *pbuf; > @@ -191,6 +192,7 @@ static int ndef_suffix(BIO *b, unsigned char **pbuf, > int *pl > derlen = ASN1_item_ndef_i2d(ndef_aux->val, &p, ndef_aux->it); > > if (!*ndef_aux->boundary) > + OPENSSL_free(p); > return 0; > > And again > > *pbuf = *ndef_aux->boundary; > *plen = derlen - (*ndef_aux->boundary - ndef_aux->derbuf); > > 6: > https://github.com/openssl/openssl/blob/master/crypto/bio/bss_bio.c > line 625, b1->buf = OPENSSL_malloc(b1->size); > bug info: memory leak on error path > patch: > > @@ -635,6 +635,7 @@ static int bio_make_pair(BIO *bio1, BIO *bio2) > b2->buf = OPENSSL_malloc(b2->size); > if (b2->buf == NULL) { > BIOerr(BIO_F_BIO_MAKE_PAIR, ERR_R_MALLOC_FAILURE); > + OPENSSL_free(b1->buf); > return 0; > } > b2->len = 0; > > 7: > https://github.com/openssl/openssl/blob/master/crypto/ec/ec_ameth.c > line 244, ep = OPENSSL_malloc(eplen); > bug info: memory leak on error path > patch: > @@ -255,6 +255,7 @@ static int eckey_priv_encode(PKCS8_PRIV_KEY_INFO *p8, > const > > if (!PKCS8_pkey_set0(p8, OBJ_nid2obj(NID_X9_62_id_ecPublicKey), 0, > ptype, pval, ep, eplen)) > + OPENSSL_free(ep); > return 0; > > > Another > > return 1; > > > 8: > https://github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c > line 1833, return 0; > bug info: Error propagation > patch: > @@ -1830,7 +1830,7 @@ int SSL_COMP_add_compression_method(int id, > COMP_METHOD *c > if (id < 193 || id > 255) { > SSLerr(SSL_F_SSL_COMP_ADD_COMPRESSION_METHOD, > SSL_R_COMPRESSION_ID_NOT_WITHIN_PRIVATE_RANGE); > - return 0; > + return 1; > } > > CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE); > > > 9: > https://github.com/openssl/openssl/blob/master/ssl/t1_enc.c > line 370, return (1); > bug info: Error propagation > > line 388, p = OPENSSL_malloc(num) > bug info: memory leak on error path > > patch: > @@ -367,7 +367,7 @@ int tls1_setup_key_block(SSL *s) > int ret = 0; > > if (s->s3->tmp.key_block_length != 0) > - return (1); > + return (0); > > if (!ssl_cipher_get_evp > (s->session, &c, &hash, &mac_type, &mac_secret_size, &comp, > @@ -448,6 +448,7 @@ int tls1_setup_key_block(SSL *s) > > ret = 1; > err: > + OPENSSL_free(p); > return (ret); > } > > > > 10: > https://github.com/openssl/openssl/blob/master/ssl/s3_enc.c > line 301, > bug info: missing check > line 270, > bug info: error propagation > line 295, > bug info: memory leak on error path > patch: > > @@ -268,7 +268,7 @@ int ssl3_setup_key_block(SSL *s) > SSL_COMP *comp; > > if (s->s3->tmp.key_block_length != 0) > - return (1); > + return (0); > > if (!ssl_cipher_get_evp(s->session, &c, &hash, NULL, NULL, &comp, > 0)) { > SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, SSL_R_CIPHER_OR_HASH_ > UNAVAILABLE); > @@ -299,6 +299,7 @@ int ssl3_setup_key_block(SSL *s) > s->s3->tmp.key_block = p; > > ret = ssl3_generate_key_block(s, p, num); > + if (ret==0) goto err; > > if (!(s->options & SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS)) { > /* > @@ -317,11 +318,12 @@ int ssl3_setup_key_block(SSL *s) > #endif > } > } > - > + ret = 1 > return ret; > > err: > SSLerr(SSL_F_SSL3_SETUP_KEY_BLOCK, ERR_R_MALLOC_FAILURE); > + OPENSSL_free(p); > return (0); > } > > Others: memory leak on error path > test/bntest.c > test/evp_test.c > > Sincerely, > Baishakhi Ray, Yuchi Tian > > > /Lars > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Tue Feb 7 07:39:22 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 7 Feb 2017 10:39:22 +0300 Subject: [openssl-dev] Internationalized Email Addresses in X.509 certificates Message-ID: Here is a patch designed for the support of the https://tools.ietf.org/html/ draft-ietf-lamps-eai-addresses-06 draft which is in the last call phase of the Lamps WG. The patch https://github.com/openssl/openssl/pull/2560 implements the support of the SmtpUtf8 OTHERNAME value. Current problems related to the patch: 1. It requires libidn with its own memory management. 2. The support via config is not provided yet. 3. It does not implement the canonicalization of the unicode string 4. It does not have tests for the chain verification. We have a preliminary specification of the tests, but currently I am unable to implement them ===== I can give you an outline of a spec. Hopefully that's enough to work with: 1. Local-part a. Internationalized i.e. non-ascii email Local-part is encoded as UTF8 in smtputf8Name. Given a test certificate in ASN.1, the UTF8 Local-part should be extractable and tested. b. Though not recommended, ascii email Local-part may also be represented. So a test certificate in ASN.1 could encode an ascii email local-part, and the ascii should be extractable and tested. Certificate generation through openssl should opt to use rfc822Name for ascii Local-part though. 2. Domain a. U-label in smtputf8Name shall be supported. Given a test certificate in ASN.1, a U-label domain should be extracted and tested. b. A-label in smtputf8Name must not be supported. Given a test certificate in ASN.1, the A-label domain should be rejected. 3. Name constraints a. CA certificate with smtputf8Name name constraint should constrain an entity certificate with smtputf8Name. Given an intermediate CA cert in ASN.1 with a full email address excluded name constraint in smtputf8Name, it can constraint an entity certificate with smtputf8Name. b. CA certificate with rfc822Name name constraint should not constrain an entity certicate with smtputf8Name. Given an intermediate CA cert in ASN.1 with a full email address excluded name constraint in rfc822Name, it does *not* constraint an entity certificate with smtputf8Name. c. CA certificate with smtputf8Name name constraint should not constrain an entity certificiate with rfc822Name. Given an intermediate CA cert in ASN.1 with a full email address excluded name constraint in smtputf8Name, it does *not* constraint an entity certificate with rfc822Name. ===== So could I cooperate with the OpenSSL team to finalize this work and submit the patch to upstream? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From raja.ashok at huawei.com Tue Feb 7 14:55:31 2017 From: raja.ashok at huawei.com (Raja ashok) Date: Tue, 7 Feb 2017 14:55:31 +0000 Subject: [openssl-dev] Doubt regarding process of invalid [D]TLS record Message-ID: Hi All, In dtls1_get_record(), we are calling ssl3_read_n to get 13 bytes of DTLS record header from socket and then based on the length in record header, we again call ssl3_read_n to get record payload from socket. Here we are handling invalid record, like length less 13 bytes or invalid version in record header or invalid epoch etc. If such invalid record comes then we are dropping that record and going to read again from socket, by calling ssl3_read_n again. If a peer is continuously sending invalid DTLS record, then our execution will be just running inside dtls1_get_record function. It wont come out of that function. So if a malicious peer wants to block our DTLS connection thread, then it can do by simply sending invalid DTLS record continuously. This behaviour would be same for both synchronous and asynchronous UDP sockets. This will simply block the application for long time, for the API SSL_connect, SSL_accept or SSL_read. I feel here we should not block the application call for long time, we should have some mechanism to fail the connection and inform application if we get invalid DTLS record continuously. For example, if we receive around 100 invalid DTLS record continuously, then we should come out of this "goto" in dtls1_get_record and return failure to application. And also we can send alert to peer and close the DTLS connection. For similar issue in ssl3_get_record(), we are having a max limit(MAX_EMPTY_RECORDS) for the received empty record. I feel similar limit should be there for invalid DTLS record in dtls1_get_record. Similarly in ssl3_get_message and dtls1_get_message_fragment, if we receive Hello request message continuously, then we are just dropping and continuously going back to read on socket. This also may cause a long time block to application, for the API SSL_connect if malicious peer is continuously sending Hello request msg. I feel blocking of application call for a long time should be avoided. Please check this and clarify me, if my understanding is wrong. Note : I am referring openssl-1.0.2k and asking this doubt. Regards, Ashok ________________________________ [Company_logo] Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ________________________________ ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6737 bytes Desc: image001.jpg URL: From tshort at akamai.com Tue Feb 7 22:16:04 2017 From: tshort at akamai.com (Short, Todd) Date: Tue, 7 Feb 2017 22:16:04 +0000 Subject: [openssl-dev] PR 2351: Place ticket keys into secure memory Message-ID: <514CDB62-80F5-429F-992C-D7F702871798@akamai.com> vdukhovi wrote: I don't think this change is useful at present. Most applications run with a single context for the lifetime of the process, so this makes no difference. We (perhaps I) first need to implement automated key rotation, and only then do I think it make sense to worry about attempting to scrub the ticket keys. richsalz wrote: I undesrstand @vdukhovni's concerns. Let's discuss this on openssl-dev before merging this. *discuss* -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at roumenpetrov.info Wed Feb 8 20:59:45 2017 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Wed, 08 Feb 2017 22:59:45 +0200 Subject: [openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir In-Reply-To: <20170205.164746.1808329431647870815.levitte@openssl.org> References: <20170205.164746.1808329431647870815.levitte@openssl.org> Message-ID: <589B86C1.10800@roumenpetrov.info> Hi Richard, Richard Levitte wrote: > Hi, > > I've some ponderings that I need to bounce a bit with you all. > > Some have talked about replace the X509_LOOKUP_METHOD X.509 lookup method could return certificate , revocation list or EVP_KEY (structure x509_object_st). Unfortunately functionality of EVP_KEY was never implemented. Another point is specific names of structures - x509_lookup_method_st , x509_lookup_st, x509_object_st. Third point is quite specific implementation - functions not just to retrieve objects( X.509 or CRL) but to fill them into "context of X509 store". Current lookup functionality look like "store" but implementation is specific to X.509 store. > bit with the > STORE module I'm building, and while STORE isn't ready for it yet I hope that you store functionality will fill gap between load of keys and load of certificates (+crl). Loadable module (engine) has interface to load key(private or public) but lack load of X.509 certificates or CRL. > , I > have some thoughts on how the two can approach each other. This would > involve one or two hooks / callbacks, that a STORE user could specify > (details later) to pick and choose freely among the objects that the > STORE module finds (be it on file or whatever else that can be > represented as a URI). I think that functionality requires three phases : 1) instantiation : at this point store is created 2) specification (optional): set or check capability of store. For instance store could return only X.509 certificates or to request store to return only keys. 3) inquiry: fetch data based on specified criteria. > The troublesome part would be to try to mimic by_dir... It highly > depends on the specified paths to really be directories, and that it > should find what it wants by adding very specific file names (a hash > of the subject name with a ".{n}" or ".r{n}" extension for X.509 certs > and for X.509 CRLs). And sure, that works, but will really only work > with regular files. I'm not sure what is issue. Lets see X.509 lookup method get_by_subject. - by_dir 2) specification : set directory(path), limit results to X.509 or CRL and may be to inform store that questions will be performed by subject. For instance URI scheme could befile://path?certificate="name" 3) query : from subject calculate hash and then process "{hash}.{n}" or "{hash}.r{n}" depending from URI - Ldap It is similar, URI is described in RFCs - at point 2) set host, port, base distinguished name, attribute (for instance cACertificate), construct filter from specified name. > What if someone would specify a LDAP URI that can return a bunch of > objects? > > So... my ponderings are going along these lines: > > 1. Should the directory X509_LOOKUPs be restricted to on disk > directories, or should "directory" be redefined as "whatever URI > that returns a collection of objects"? The latter would mean that > all those objects get loaded and that a hook / callback would then > be called to check if it's an object that corresponds to what we > search for. I think that replacement of "by_dir" lookup has to be restricted to file system operation. Files could be located on network, memory not only on disk. > 2. For on disk directories, should we preserve the rehash file form? > In other words, if we decide to load everything we can find, shall > we restrict the loading to files matching the regexp > [0-9a-f]{8}\.r?[0-9]+ ? If not, are we about to create a new form > of key store for ourselves and our users? Should we? For hash-dir please keep current file name format. > Quite a lot also depends on what OpenSSL version we aim for. I would > very much like to see the STORE module itself become part of 1.1.1, > but a new key store to replace our current rehash links will obviously > have to wait 'til 1.2.0. > > Cheers, > Richard > Roumen From levitte at openssl.org Wed Feb 8 22:46:36 2017 From: levitte at openssl.org (Richard Levitte) Date: Wed, 08 Feb 2017 23:46:36 +0100 (CET) Subject: [openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir In-Reply-To: <589B86C1.10800@roumenpetrov.info> References: <20170205.164746.1808329431647870815.levitte@openssl.org> <589B86C1.10800@roumenpetrov.info> Message-ID: <20170208.234636.544949886980545503.levitte@openssl.org> In message <589B86C1.10800 at roumenpetrov.info> on Wed, 08 Feb 2017 22:59:45 +0200, Roumen Petrov said: openssl> Hi Richard, openssl> openssl> Richard Levitte wrote: openssl> > Hi, openssl> > openssl> > I've some ponderings that I need to bounce a bit with you all. openssl> > openssl> > Some have talked about replace the X509_LOOKUP_METHOD openssl> X.509 lookup method could return certificate , revocation list or openssl> EVP_KEY (structure x509_object_st). openssl> openssl> Unfortunately functionality of EVP_KEY was never implemented. openssl> Another point is specific names of structures - x509_lookup_method_st openssl> , x509_lookup_st, x509_object_st. openssl> Third point is quite specific implementation - functions not just to openssl> retrieve objects( X.509 or CRL) but to fill them into "context of X509 openssl> store". openssl> openssl> Current lookup functionality look like "store" but implementation is openssl> specific to X.509 store. openssl> openssl> openssl> > bit with the openssl> > STORE module I'm building, and while STORE isn't ready for it yet openssl> openssl> I hope that you store functionality will fill gap between load of keys openssl> and load of certificates (+crl). openssl> openssl> Loadable module (engine) has interface to load key(private or public) openssl> but lack load of X.509 certificates or CRL. So far, key parameters, pkeys, certs and crls are covered... oh, and names, if the given URI would return a list of names (file:/foo/bar/ would typically do that, for example). openssl> > , I openssl> > have some thoughts on how the two can approach each other. This would openssl> > involve one or two hooks / callbacks, that a STORE user could specify openssl> > (details later) to pick and choose freely among the objects that the openssl> > STORE module finds (be it on file or whatever else that can be openssl> > represented as a URI). openssl> I think that functionality requires three phases : openssl> 1) instantiation : at this point store is created openssl> 2) specification (optional): set or check capability of store. For openssl> instance store could return only X.509 certificates or to request openssl> store to return only keys. openssl> 3) inquiry: fetch data based on specified criteria. Previous attempts at a STORE effort were along those lines of thinking. Unfortunately, they got stuck in the exact specification of attributes and how to combine them (i.e. forming a "language" of sorts), and then to figure out how to make that pratical, especially for the engines that would have to intrepret it. So this time around, I'm trying to make OpenSSL fairly agnostic and leave the exact spec up to be specified by the user or application in the URI and letting the diverse engines interpret the URI components at their leasure. Objects would then be returned according to those specs in form of one object at a time, be it parameters, keys, certs, crls or names, for the application or other parts of OpenSSL to do whatever they wish with. Given this, I determined yesterday that there would really just be one hook / callback that makes sense, and that's one that can massage or possibly discard returned objects before they make their way all the way to the calling application. Something like this. openssl> > The troublesome part would be to try to mimic by_dir... It highly openssl> > depends on the specified paths to really be directories, and that it openssl> > should find what it wants by adding very specific file names (a hash openssl> > of the subject name with a ".{n}" or ".r{n}" extension for X.509 certs openssl> > and for X.509 CRLs). And sure, that works, but will really only work openssl> > with regular files. openssl> I'm not sure what is issue. openssl> openssl> Lets see X.509 lookup method get_by_subject. openssl> openssl> - by_dir openssl> 2) specification : set directory(path), limit results to X.509 or CRL openssl> and may be to inform store that questions will be performed by openssl> subject. openssl> openssl> For instance URI scheme could befile://path?certificate="name" openssl> openssl> 3) query : from subject calculate hash and then process "{hash}.{n}" openssl> or "{hash}.r{n}" depending from URI openssl> openssl> - Ldap openssl> It is similar, URI is described in RFCs - at point 2) set host, port, openssl> base distinguished name, attribute (for instance cACertificate), openssl> construct filter from specified name. The issue is there, glaring back at you. How will by_dir know exactly how to massage the URI? Sure, we could program in the big known ones plus our own mangling of the file: scheme, but then what? What about the vendor who runs his own scheme foo:? How do we know how to encode their keystore specs into a URI with their scheme? There needs to be a solution where OpenSSL can be specification agnostic. So far, I've this idea of returned names that form a "directory listing", and it wouldn't be too hard to imagine a by_dir implementation that simply get a list of names, then loads each of them and caches *everything*, or possibly one that uses the hook / callback I mentioned further up to select the one with the subject it's looking for. It is workable, I'm just worried about the sudden huge "directory listing". openssl> > What if someone would specify a LDAP URI that can return a bunch of openssl> > objects? openssl> > openssl> > So... my ponderings are going along these lines: openssl> > openssl> > 1. Should the directory X509_LOOKUPs be restricted to on disk openssl> > directories, or should "directory" be redefined as "whatever URI openssl> > that returns a collection of objects"? The latter would mean that openssl> > all those objects get loaded and that a hook / callback would then openssl> > be called to check if it's an object that corresponds to what we openssl> > search for. openssl> I think that replacement of "by_dir" lookup has to be restricted to openssl> file system operation. That's workable but sub-optimal... we've had a recent complaint from someone who wants to create a X509_LOOKUP_METHOD for his own scheme (hw protected keys, I think). PKCS#11 has been mentioned quite a number of times as well. But sure, for the time being. openssl> Files could be located on network, memory not only on disk. Does that differ from what we have today? openssl> > 2. For on disk directories, should we preserve the rehash file form? openssl> > In other words, if we decide to load everything we can find, shall openssl> > we restrict the loading to files matching the regexp openssl> > [0-9a-f]{8}\.r?[0-9]+ ? If not, are we about to create a new form openssl> > of key store for ourselves and our users? Should we? openssl> openssl> For hash-dir please keep current file name format. Like I said, a changed keystore format isn't possible before 1.2.0 anyway, so at least for now, the hash-dir format stays. What I wonder, generally speaking, is that for a URI that's a directory spec, show the STORE file: scheme return the names of *all* the file names in that directory, or just those matching [0-9a-f]{8}\.r?[0-9]+ ? Either can be done, I just worry about the consequences... openssl> > Quite a lot also depends on what OpenSSL version we aim for. I would openssl> > very much like to see the STORE module itself become part of 1.1.1, openssl> > but a new key store to replace our current rehash links will obviously openssl> > have to wait 'til 1.2.0. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jun.sun at infosecglobal.com Thu Feb 9 16:54:33 2017 From: jun.sun at infosecglobal.com (Jun Sun) Date: Thu, 9 Feb 2017 16:54:33 +0000 Subject: [openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256 In-Reply-To: <20170208.234636.544949886980545503.levitte@openssl.org> References: <20170205.164746.1808329431647870815.levitte@openssl.org> <589B86C1.10800@roumenpetrov.info>, <20170208.234636.544949886980545503.levitte@openssl.org> Message-ID: Hi, I noticed Windows exception handler is added to ecp_nistz256-x86_64.pl. In function full_handler, when restore register contents, rbx is the first one with the smallest offset: 3181 mov -8(%rax),%rbx 3182 mov -16(%rax),%rbp but when do push, rbp is always the first one push to the stack: 497 .Lmul_mont: 498 push %rbp 499 push %rbx That is, the contents of rbx is restored to rbp and the content of rbp is restored to rbx. I think it is probably a bug of the code. Jun This email and any attachments are for the sole use of the intended recipients and may be privileged or confidential. Any distribution, printing or other use by anyone else is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 9 20:35:50 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Feb 2017 20:35:50 +0000 Subject: [openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256 In-Reply-To: References: <20170205.164746.1808329431647870815.levitte@openssl.org> <589B86C1.10800@roumenpetrov.info>, <20170208.234636.544949886980545503.levitte@openssl.org> Message-ID: <35da7f28f7f346359914e9929816935b@usma1ex-dag1mb3.msg.corp.akamai.com> Does this fix it? https://github.com/openssl/openssl/pull/2582 From appro at openssl.org Thu Feb 9 23:49:07 2017 From: appro at openssl.org (Andy Polyakov) Date: Fri, 10 Feb 2017 00:49:07 +0100 Subject: [openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256 In-Reply-To: <35da7f28f7f346359914e9929816935b@usma1ex-dag1mb3.msg.corp.akamai.com> References: <20170205.164746.1808329431647870815.levitte@openssl.org> <589B86C1.10800@roumenpetrov.info> <20170208.234636.544949886980545503.levitte@openssl.org> <35da7f28f7f346359914e9929816935b@usma1ex-dag1mb3.msg.corp.akamai.com> Message-ID: <2b679337-27c0-aeeb-1fd4-8412ef71efab@openssl.org> > Does this fix it? > https://github.com/openssl/openssl/pull/2582 It's unrelated issues. Yes, it's typo in full_handler, will be fixed [tomorrow]... From openssl at openssl.org Mon Feb 13 08:52:42 2017 From: openssl at openssl.org (OpenSSL) Date: Mon, 13 Feb 2017 08:52:42 +0000 (GMT) Subject: [openssl-dev] Forthcoming OpenSSL release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forthcoming OpenSSL release =========================== The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.0e This release will be made available on 16th February 2017 between 1200-1600 UTC, and will include a fix for a security defect classified as severity "High". This issue does not affect OpenSSL versions prior to 1.1.0. Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJYoXCaAAoJEAEKUEB8TIy92GwH+gMIr6v8IQE04/aHWlp+ilep RIPM3x+NAQCkBTSZDhYPRIfJPnbEfGY1hi6Og28SQwHyfClL8Kyg0rkcgEJa9Q1A evhXesZD6xwWiPbqS4yu/iAnjapCPDuNQOeH8toRBs97N4bZ5/SLN6a5UUQg3lQ6 4t3zHJMK3RDRl6O39xmU84qpP7iumGW8Br/0XD2DfPvF0hAJVO+IfvTHK1WEFZg3 j1bYFUEP3lFWnXQDN7h4e9dOKRioSADdl/Tj+Ibh51OBYwaE2xjqqsOs4VAjbG8x V17okImTVhXhKSEOw3wsNirjW/+ui6fDIjszUGTcmNSp+MLXvUB21+8OXaVTDQs= =DVlI -----END PGP SIGNATURE----- From matt at openssl.org Mon Feb 13 16:13:16 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Feb 2017 16:13:16 +0000 Subject: [openssl-dev] SNI by default in s_client Message-ID: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> I'd like to canvas opinion on this PR: https://github.com/openssl/openssl/pull/2614 At the moment s_client does not add the SNI extension by default. You have to explicitly ask for it using the "-servername" option. This can lead to some problems where servers reject connection attempts from s_client, e.g.: https://github.com/openssl/openssl/issues/2580 TLSv1.3 says this about SNI: Additionally, all implementations MUST support use of the "server_name" extension with applications capable of using it. Servers MAY require clients to send a valid "server_name" extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a "server_name" extension by terminating the connection with a "missing_extension" alert. Technically this doesn't really say anything very much other than we MUST support it (which we do), and that servers may refuse to talk to clients that don't send it (which we already know). But the direction of travel seems to be to support SNI where possible. The PR above changes the default behaviour of s_client so that it always sends SNI, and adds a "-noservername" option to suppress sending it if needed. I was targeting this change for 1.1.1. The issue is that this does change command line behaviour between minor versions of the 1.1.x series - which is supposed to preserve API and ABI compatibility. Of course this change affects neither API or ABI as its in the apps only - although we usually extend that compatibility to try to ensure that command line behaviour remains stable too. You could argue that the only change in behaviour here is the addition of an extension by default that wasn't there before - and that we've already decided to add new extensions in 1.1.1 due to the forthcoming TLSv1.3 support. On the other hand you could argue that this could break existing scripts that rely on the current SNI behaviour. So the question is: should this (type of) change be allowed in a 1.1.x release? Or should it only be allowed in some future 1.2.0 (or not at all)? Discuss. Matt From tmraz at redhat.com Mon Feb 13 16:36:47 2017 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 13 Feb 2017 17:36:47 +0100 Subject: [openssl-dev] SNI by default in s_client In-Reply-To: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> References: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> Message-ID: <1487003807.19095.7.camel@redhat.com> On Mon, 2017-02-13 at 16:13 +0000, Matt Caswell wrote: > I'd like to canvas opinion on this PR: > https://github.com/openssl/openssl/pull/2614 .... > The PR above changes the default behaviour of s_client so that it > always > sends SNI, and adds a "-noservername" option to suppress sending it > if > needed. > > I was targeting this change for 1.1.1. The issue is that this does > change command line behaviour between minor versions of the 1.1.x > series > - which is supposed to preserve API and ABI compatibility. Of course > this change affects neither API or ABI as its in the apps only - > although we usually extend that compatibility to try to ensure that > command line behaviour remains stable too. > > You could argue that the only change in behaviour here is the > addition > of an extension by default that wasn't there before - and that we've > already decided to add new extensions in 1.1.1 due to the forthcoming > TLSv1.3 support. On the other hand you could argue that this could > break > existing scripts that rely on the current SNI behaviour. > > So the question is: should this (type of) change be allowed in a > 1.1.x > release? Or should it only be allowed in some future 1.2.0 (or not at > all)? In my opinion the PR should be allowed in 1.1.x release, depending on s_client to not send SNI in some kind of scripts seems to me like a fairly obscure corner case. I would view this change as a simple usability improvement. But if you decide to postpone such changes to 1.2.0 I would recommend to create some intermediate step between fully breaking API/ABI and command line use changes. I mean - release 1.2.0 as something API/ABI compatible with 1.1.x, but allowing such usability changes for command- line and also allowing things like removal of obscure or insecure features but keeping the function signatures intact (they would simply return errors). And also keep the library SONAME so dependencies do not need to be rebuilt. And spare full break of API/ABI for something like 2.0 release. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From rsalz at akamai.com Mon Feb 13 16:55:16 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 13 Feb 2017 16:55:16 +0000 Subject: [openssl-dev] SNI by default in s_client In-Reply-To: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> References: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> Message-ID: > extension by default that wasn't there before - and that we've already > decided to add new extensions in 1.1.1 due to the forthcoming > TLSv1.3 support. You mean adding new extensions in the wire protocol? Or are did we modify any API/ABI behavior? > On the other hand you could argue that this could break > existing scripts that rely on the current SNI behaviour. I would support adding a new -sni flag that is shorter, easier to type, and uses the value of the HOST field. Within the team, we previously had agreement that the CLI was part of the ABI "contract." Waiting for Viktor to weigh in here :) From openssl-users at dukhovni.org Mon Feb 13 17:01:15 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Feb 2017 12:01:15 -0500 Subject: [openssl-dev] SNI by default in s_client In-Reply-To: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> References: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> Message-ID: <8BCD2D04-9A98-4D1E-9227-36E1B771660F@dukhovni.org> > On Feb 13, 2017, at 11:13 AM, Matt Caswell wrote: > > I'd like to canvas opinion on this PR: > https://github.com/openssl/openssl/pull/2614 > > At the moment s_client does not add the SNI extension by default. You > have to explicitly ask for it using the "-servername" option. So long as the "-servername" option remains in place and supports setting the SNI name to something other than the host part of the "-connect" option I think we provide sufficient compatibility with the legacy s_client CLI interface. Adding a "-noservername" option is compatible enough. The change of default behaviour is not an interface change, it is a behaviour change, and could even, with enough squinting, be viewed as a bugfix, given the modern TLS landscape. That said, even behaviour changes in stable releases do merit discussion. Certainly I would not support the proposed change in a patch release. For 1.1.1, I am not opposed, because s_client is not stunnel, it is primarily useful as a diagnostic tool, and while some monitoring tools built around it may behave differently as a result of the change, it is not clear that delaying to 1.2.x helps. If we're going to do this, I think that 1.1.1 is OK, if the interface remains compatible. -- Viktor. From matt at openssl.org Mon Feb 13 17:02:54 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Feb 2017 17:02:54 +0000 Subject: [openssl-dev] SNI by default in s_client In-Reply-To: References: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> Message-ID: <94162403-79b7-442b-546f-9666e5b1a29a@openssl.org> On 13/02/17 16:55, Salz, Rich wrote: >> extension by default that wasn't there before - and that we've already >> decided to add new extensions in 1.1.1 due to the forthcoming >> TLSv1.3 support. > > You mean adding new extensions in the wire protocol? Or are did we modify any API/ABI behavior? Wire protocol. We haven't modified API/ABI behaviour (except to add new APIs). > >> On the other hand you could argue that this could break >> existing scripts that rely on the current SNI behaviour. > > I would support adding a new -sni flag that is shorter, easier to type, and uses the value of the HOST field. Which doesn't really solve the problem I was seeking to address. > > Within the team, we previously had agreement that the CLI was part of the ABI "contract." Waiting for Viktor to weigh in here :) > I'm all in favour of a stable command line interface. What I think is unclear is where the line is drawn between what is and isn't allowed. I'm also waiting for Viktor :-) Matt From bkaduk at akamai.com Mon Feb 13 17:20:29 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 13 Feb 2017 11:20:29 -0600 Subject: [openssl-dev] SNI by default in s_client In-Reply-To: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> References: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> Message-ID: On 02/13/2017 10:13 AM, Matt Caswell wrote: > I was targeting this change for 1.1.1. The issue is that this does > change command line behaviour between minor versions of the 1.1.x series > - which is supposed to preserve API and ABI compatibility. Of course > this change affects neither API or ABI as its in the apps only - > although we usually extend that compatibility to try to ensure that > command line behaviour remains stable too. > > You could argue that the only change in behaviour here is the addition > of an extension by default that wasn't there before - and that we've > already decided to add new extensions in 1.1.1 due to the forthcoming > TLSv1.3 support. On the other hand you could argue that this could break > existing scripts that rely on the current SNI behaviour. > > So the question is: should this (type of) change be allowed in a 1.1.x > release? Or should it only be allowed in some future 1.2.0 (or not at all)? > A few thoughts: I agree that the ecosystem is moving towards using SNI almost all of the time, and this change is probably net helpful to our users. However, it is also the sort of change that I would have expected to be blocked by the ABI stability promise (as I understand it to be, or maybe as I imagine it to be in my wishful thinking). In this particular case, my personal opinion is that the benefit outweighs the compatibility breakage, but I could sympathize with someone who felt differently. Perhaps a reasonable compromise would be to ensure that the -noservername option is accepted (as a noop) in 1.1.0, so that there is a way to write a script that remains compatible between 1.1.0 and 1.1.1 even if the default does change. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Feb 13 17:32:19 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Feb 2017 12:32:19 -0500 Subject: [openssl-dev] SNI by default in s_client In-Reply-To: References: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> Message-ID: > On Feb 13, 2017, at 12:20 PM, Benjamin Kaduk wrote: > > Perhaps a reasonable compromise would be to ensure that the -noservername option is accepted (as a noop) in 1.1.0, so that there is a way to write a script that remains compatible between 1.1.0 and 1.1.1 even if the default does change. We could add a "-ignore_unknown" option, which (if specified first) would more generally allow the CLI to ignore attempts to use features only available in later versions. An environment variable could provide another means to the same end. That said, I don't think that enabling SNI by default *in s_client* is sufficient cause to motivate such a feature. The s_client command adds new options from time to time, and IIRC we've never before back-ported these as NOPs. If an "ignore_unknown" option is warranted, it is for all the other new things we might add in addition to "-noservername". I'd be more concerned with potentially incompatible changes to cms(1), enc(1), req(1), x509(1), ... which are the main day-to-day tools used by users to get useful work done. The s_client(1) and s_server(1) commands are diagnostic utilities, and such it is reasonable to be less strict w.r.t. reasonable behaviour changes. We should still provide a backwards compatible interface, but that does not preclude reasonable differences in the resulting behaviour. -- -- Viktor. From rsalz at akamai.com Mon Feb 13 17:35:07 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 13 Feb 2017 17:35:07 +0000 Subject: [openssl-dev] SNI by default in s_client In-Reply-To: References: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> Message-ID: <546273d4dc0348bfb476d4434ead0a2d@usma1ex-dag1mb3.msg.corp.akamai.com> Having asked for Viktor's opinion, and reading it, I withdraw my concerns about changing the behavior and adding the flag. I think it should be called out in the docs and CHANGES however. From openssl-users at dukhovni.org Mon Feb 13 17:37:11 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Feb 2017 12:37:11 -0500 Subject: [openssl-dev] SNI by default in s_client In-Reply-To: <546273d4dc0348bfb476d4434ead0a2d@usma1ex-dag1mb3.msg.corp.akamai.com> References: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> <546273d4dc0348bfb476d4434ead0a2d@usma1ex-dag1mb3.msg.corp.akamai.com> Message-ID: <7C5C6D5E-9B69-415B-9296-EA1D4EFC53BF@dukhovni.org> > On Feb 13, 2017, at 12:35 PM, Salz, Rich wrote: > > I think it should be called out in the docs and CHANGES however. Yes, definitely. -- Viktor. From openssl-users at dukhovni.org Mon Feb 13 18:58:05 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Feb 2017 13:58:05 -0500 Subject: [openssl-dev] SNI by default in s_client In-Reply-To: References: <11f76d24-e482-e6d5-0408-85be5611f918@openssl.org> Message-ID: <491D1788-B120-4DE1-99E9-8D65A480BB74@dukhovni.org> > On Feb 13, 2017, at 12:32 PM, Viktor Dukhovni wrote: > > That said, I don't think that enabling SNI by default *in s_client* is > sufficient cause to motivate such a feature. The s_client command adds > new options from time to time, and IIRC we've never before back-ported > these as NOPs. If an "ignore_unknown" option is warranted, it is for > all the other new things we might add in addition to "-noservername". One more thing I should note. The implementation should not break the "-dane_tldsa_domain" option. That is, with no explicit "-servername" and with "-dane_tlsa_domain", the SNI name must come from that option, and not the "-connect" hostname. -- Viktor. From appro at openssl.org Mon Feb 13 20:28:13 2017 From: appro at openssl.org (Andy Polyakov) Date: Mon, 13 Feb 2017 21:28:13 +0100 Subject: [openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256 In-Reply-To: <2b679337-27c0-aeeb-1fd4-8412ef71efab@openssl.org> References: <20170205.164746.1808329431647870815.levitte@openssl.org> <589B86C1.10800@roumenpetrov.info> <20170208.234636.544949886980545503.levitte@openssl.org> <35da7f28f7f346359914e9929816935b@usma1ex-dag1mb3.msg.corp.akamai.com> <2b679337-27c0-aeeb-1fd4-8412ef71efab@openssl.org> Message-ID: >> Does this fix it? >> https://github.com/openssl/openssl/pull/2582 > > It's unrelated issues. Yes, it's typo in full_handler, will be fixed > [tomorrow]... Fix has been applied. Thank you for report! From matt at openssl.org Tue Feb 14 09:30:31 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Feb 2017 09:30:31 +0000 Subject: [openssl-dev] OpenSSL Project Bylaws Message-ID: <6a9d61ca-923a-e4ce-f91b-421a77f83f97@openssl.org> I am pleased to be able to announce the publication of our new Project Bylaws. I have written a short blog post about what we are hoping to achieve and some of the thinking that went into these here: https://www.openssl.org/blog/blog/2017/02/13/bylaws/ The bylaws themselves are available here: https://www.openssl.org/policies/bylaws.html The Project Bylaws describe how the OpenSSL Project operates, what the different project roles are and how decisions are made. Incidentally these project bylaws should not be confused with the OpenSSL Software Foundation (OSF) Bylaws which were also recently published and describe how that legal entity operates. Matt From openssl at openssl.org Thu Feb 16 12:18:56 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 16 Feb 2017 12:18:56 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0e published Message-ID: <20170216121856.GA3824@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.0e released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0e of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0e is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0e.tar.gz Size: 5202247 SHA1 checksum: 8bbbaf36feffadd3cb9110912a8192e665ebca4b SHA256 checksum: 57be8618979d80c910728cfc99369bf97b2a1abd8f366ab6ebdee8975ad3874c The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0e.tar.gz openssl sha256 openssl-1.1.0e.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYpZPjAAoJENnE0m0OYESRxHwIAIk2mWe90coHwxhyMNsGswJH sVhGvvLMza+TZWOg5PIu0KGuFQhrGaKFtRUfWCiXApkNhTN5yiUq550sz4wP/+Uv KwE/R2ra5JPdGUmGxHZ14N/E54BursW5EhWpmraqlNyKw0IOOj2amvAjvNiMikuj +2Xc+59rMFInba6w9D5S45jtVY7uSk75RX9P5wtxH/ZG5cYALiqS+V5cpZBWMif4 lvZyc6sTZ77xb6yBNVMpeNmm5vkZrqOvSFnCuk/SwPVyfyWfh3alzx2ryzu6JZj2 57IY1gKK8kFx2o/FAC2kq9Vs9EkJv4ApVqIc90jtMcYHgAtek3yi+GIJ5O6xlak= =mbOM -----END PGP SIGNATURE----- From openssl at openssl.org Thu Feb 16 12:21:24 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 16 Feb 2017 12:21:24 +0000 Subject: [openssl-dev] OpenSSL Security Advisory Message-ID: <20170216122124.GA4307@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [16 Feb 2017] ======================================== Encrypt-Then-Mac renegotiation crash (CVE-2017-3733) ==================================================== Severity: High During a renegotiation handshake if the Encrypt-Then-Mac extension is negotiated where it was not in the original handshake (or vice-versa) then this can cause OpenSSL to crash (dependent on ciphersuite). Both clients and servers are affected. OpenSSL 1.1.0 users should upgrade to 1.1.0e This issue does not affect OpenSSL version 1.0.2. This issue was reported to OpenSSL on 31st January 2017 by Joe Orton (Red Hat). The fix was developed by Matt Caswell of the OpenSSL development team. Note ==== Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20170216.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYpZMiAAoJENnE0m0OYESRMUgH/0UN9sxxgyDewSCMeTOYPauK cSPqyw1pndQI6Lu+d3OCdWd01rdLcm+HxlbW5FOUjGZ4G9YefE0+JcvKkIuLGIpQ 1EE0g/ZuBzWDh7/MkFWcmjHceYVXi5sKewtWcQvO9uePzlPhlSZoNIL1G66n1HAo of3ZlSL5BmibaTiz1WmpDG//0W1pgYP5OdvQ8/AVrJJf8pUnU9Oyubm1yCyK2RHi jfJWLbMx0ENgW4G1sW4s8bPaj4GwLjIrZl8ocqoyAHhghkBv/UXUhv6i62bKHmxW vfYwwiU0GlRVwPXzFKbbE3qqCRyDsq+XLAe/09NZZWA+BtscWuUhUpyEODBqzeY= =zqNG -----END PGP SIGNATURE----- From steffen at sdaoden.eu Thu Feb 16 13:58:18 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 16 Feb 2017 14:58:18 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0e published In-Reply-To: <20170216121856.GA3824@openssl.org> References: <20170216121856.GA3824@openssl.org> Message-ID: <20170216135818.EH_eR%steffen@sdaoden.eu> FYI, and because i don't have a github account, though this could be related to ticket #1635, on a x86_64 GNU LibC based Linux via openssl: cd openssl.git &&\ if [ -f NULL ]; then git checkout `cat NULL`; fi &&\ ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared &&\ make &&\ $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \ { git clean -fxd; git reset --hard HEAD;\ git checkout arena-manager-null; } >/dev/null and MYPREFIX=$HOME/usr/opt/.ssl-1.1.0 the shlibload tests fail ../test/recipes/90-test_shlibload.t ........ 1/3 # Failed test 'running shlibloadtest -crypto_first' # at ../test/recipes/90-test_shlibload.t line 30. ../test/recipes/90-test_shlibload.t ........ 2/3 # Failed test 'running shlibloadtest -ssl_first' # at ../test/recipes/90-test_shlibload.t line 32. # Failed test 'running shlibloadtest -just_crypto' # at ../test/recipes/90-test_shlibload.t line 34. # Looks like you failed 3 tests of 3. ../test/recipes/90-test_shlibload.t ........ Dubious, test returned 3 (wstat 768, 0x300) Failed 3/3 subtests ../test/recipes/90-test_srp.t .............. ok ../test/recipes/90-test_sslapi.t ........... ok ../test/recipes/90-test_threads.t .......... ok ../test/recipes/90-test_v3name.t ........... ok Test Summary Report ------------------- ../test/recipes/90-test_shlibload.t (Wstat: 768 Tests: 3 Failed: 3) Failed tests: 1-3 Non-zero exit status: 3 ... Failed 1/91 test programs. 3/489 subtests failed. --steffen From john at calva.com Fri Feb 17 12:08:11 2017 From: john at calva.com (John Hughes) Date: Fri, 17 Feb 2017 13:08:11 +0100 Subject: [openssl-dev] Problem with Commit 3fd181a8b5b85a1f7383e82438da494a08f7d843, Remove an option related to a deprecated flag. Message-ID: <1f04bf67-e87f-6f05-2404-7e247a4bbb1e@calva.com> This commit removes the cms and smime "-nooldmime" option on the grounds that the flags they use "CMS_NOOLDMIMETYPE" and "PKCS7_NOOLDMIMETYPE" are not used in the pkcs7/cms code. But those flags *are* used. In include/openssl/pkcs7.h we have: # define PKCS7_NOOLDMIMETYPE 0x400 And in include/openssl/cms.h: # define CMS_NOOLDMIMETYPE 0x400 And include/openssl/smime.h # define SMIME_OLDMIME 0x400 And, in crypto/pkcs7/pk7mime.c: int SMIME_write_PKCS7(BIO *bio, PKCS7 *p7, BIO *data, int flags) { ... flags ^= SMIME_OLDMIME; return SMIME_write_ASN1(bio, (ASN1_VALUE *)p7, data, flags, ctype_nid, NID_undef, mdalgs, ASN1_ITEM_rptr(PKCS7)); And, finally in crypto/asn1/asn_mime.c: int SMIME_write_ASN1(BIO *bio, ASN1_VALUE *val, BIO *data, int flags, int ctype_nid, int econt_nid, STACK_OF(X509_ALGOR) *mdalgs, const ASN1_ITEM *it) { ... if (flags & SMIME_OLDMIME) mime_prefix = "application/x-pkcs7-"; else mime_prefix = "application/pkcs7-"; That is to say the effect of setting the flag CMS_NOOLDMIMETYPE or PKCS7_NOOLDMIMETYPE is to *unset* the flag SMIME_OLDMIME in calls to SMIME_write_ASN1, and so tell SMIME_write_ASN1 to write new-style mime headers "application/pkcs7-" instead of the horrid old "application/x-pkcs7-". TL; DR -- the flags "CMS_NOOLDMIMETYPE" and "PKCS7_NOOLDMIMETYPE" *are* used, and shouldn't be deprecated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Feb 21 13:49:25 2017 From: levitte at openssl.org (Richard Levitte) Date: Tue, 21 Feb 2017 14:49:25 +0100 (CET) Subject: [openssl-dev] STORE, the continued story Message-ID: <20170221.144925.567356532533451019.levitte@openssl.org> Hi, last time I talked about the STORE effort, it was about search for specific data. I believe that this PR covers quite a lot of what is desired, and is designed to be easily extensible: https://github.com/openssl/openssl/pull/2688 (it's built on top of PRs #2011 and #1961, making it look quite huge). As a proof of concept, I had a closer look at X509_LOOKUP_METHODs and came up with two integrations with STORE, one being light weight (or cowardly), the other being a bit more radical. lightweight: https://github.com/openssl/openssl/pull/2696 radical: https://github.com/openssl/openssl/pull/2697 These two PRs have not been built on top of the URI and STORE PRs, for demonstration purposes. To make them work, they need to be merged on top of PR #2688. Note: they currently only take straight file / directory specs, no URIs. The change to full blown URI processing isn't very hard but needs a bit more testing. At this point, it's high time for comments in the PRs, and reviews (especially by team members)... so far, there's been very little of that. Also, it's high time to start playing with engines and see how integration with the STORE API works out. The TPM engine would be interesting, and so would the PKCS#11 one. Also, if there's an LDAP engine to adapt, that would be an interesting project as well. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From andrewponomarenko at yandex.ru Wed Feb 22 09:30:54 2017 From: andrewponomarenko at yandex.ru (Andrey Ponomarenko) Date: Wed, 22 Feb 2017 12:30:54 +0300 Subject: [openssl-dev] ABI Navigator for OpenSSL Message-ID: <1918421487755854@web5j.yandex.ru> Hello, I'd like to present a new project called "ABI Navigator" for searching binary symbols (functions, global data, etc.) in OpenSSL and other open-source libraries: https://abi-laboratory.pro/index.php?view=navigator The project allows to find out in which versions of the library some symbol is defined, added, removed or changed. The data is taken from the ABI Tracker project: https://abi-laboratory.pro/tracker/timeline/openssl/ Example for SSL_library_init from libssl.so: https://abi-laboratory.pro/index.php?view=navigator&selected=SSL_library_init#OpenSSL_libssl.so The project aims to help library users and maintainers to resolve issues with missed symbols and navigate through the reports in the ABI Tracker. Have you ever encountered the "undefined reference" error or want to know whether the symbol is _stable_ enough to import in your code? Try to find it in the ABI Navigator! Enjoy! From rschm2 at unh.newhaven.edu Thu Feb 23 04:00:52 2017 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Thu, 23 Feb 2017 04:00:52 +0000 Subject: [openssl-dev] Integrate EVP Cipher into OpenSSL cli Speed Test Message-ID: Hello, I successfully managed to integrate an encryption cipher into the EVP and has been tested to work and now I'd like to get some speed tests of the cipher using openssl's integrated speed test via the command line with the "-evp" flag. What I've done so far to try and integrate it into openssl's speed test.... 1) Confirmed EVP_mycipher() works 2) Noticed ./apps/speed.c was calling: case OPT_EVP: evp_cipher = EVP_get_cipherbyname(opt_arg()); 3) Then modified ./crypto/objects/objects.txt to include the necessary defines # Mycipher : MYCIPHER : mycipher 4) Edited crypto/evp/c_allc.c to include my cipher in the loading of all ciphers EVP_add_cipher(EVP_mycipher()); EVP_add_cipher_alias(SN_mycipher, "mycipher"); 5) Ran a make update then make and saw all necessary defines were generated However, the speed test cannot find my cipher because EVP_get_cipherbyname() returns NULL. Am I missing a step here or did I mis-configure something? It seems as if there's something to edit to tie the NID/SN/LN_mycipher to the algorithm. Any help is much appreciated! Rob Schmicker -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Thu Feb 23 12:54:25 2017 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 23 Feb 2017 05:54:25 -0700 Subject: [openssl-dev] Openssl 1.0.2 snapshot bug Message-ID: <20170223125425.GA77540@doctor.nl2k.ab.ca> Script started on Thu Feb 23 05:41:55 2017 You have mail. root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170223 # makeless /usr/contrib/b in/configopenssl [?1h= #!/usr/local/bin/bash CC=/usr/local/bin/clang39 ./Configure --prefix=/usr/ BSD-x86_64 fips enable-gmp  experimental-jpake enable-rfc3779 enable-shared zlib-dynamic disable-sctp exper imental-store enable-ssl-trace enable-unit-test; make depend /usr/contrib/bin/configopenssl (END) [?1l>root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170223 # make making all in crypto... making all in crypto/objects... making all in crypto/md4... making all in crypto/md5... making all in crypto/sha... making all in crypto/mdc2... making all in crypto/hmac... making all in crypto/ripemd... making all in crypto/whrlpool... making all in crypto/des... making all in crypto/aes... making all in crypto/rc2... making all in crypto/rc4... making all in crypto/idea... making all in crypto/bf... making all in crypto/cast... making all in crypto/camellia... making all in crypto/seed... making all in crypto/modes... making all in crypto/bn... making all in crypto/ec... making all in crypto/rsa... making all in crypto/dsa... making all in crypto/ecdsa... making all in crypto/dh... making all in crypto/ecdh... making all in crypto/dso... making all in crypto/engine... making all in crypto/buffer... making all in crypto/bio... making all in crypto/stack... making all in crypto/lhash... making all in crypto/rand... making all in crypto/err... making all in crypto/evp... making all in crypto/asn1... making all in crypto/pem... making all in crypto/x509... making all in crypto/x509v3... making all in crypto/conf... making all in crypto/txt_db... making all in crypto/pkcs7... making all in crypto/pkcs12... making all in crypto/comp... making all in crypto/ocsp... making all in crypto/ui... making all in crypto/krb5... making all in crypto/cms... making all in crypto/pqueue... making all in crypto/ts... making all in crypto/jpake... making all in crypto/srp... making all in crypto/store... making all in crypto/cmac... if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libcrypto.so.1.0.0); fi [ -z "libcrypto" ] || /usr/local/bin/clang39 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso /usr/local/ssl/fips-2.0/lib/fips_premain.c /usr/local/ssl/fips-2.0/lib/fipscanister.o libcrypto.a libcrypto.a(ec_asn1.o): In function `EC_GROUP_get_basis_type': ec_asn1.c:(.text+0x37): undefined reference to `OSSL_NELEM' ec_asn1.c:(.text+0x64): undefined reference to `OSSL_NELEM' libcrypto.a(ec_asn1.o): In function `ec_asn1_group2pkparameters': ec_asn1.c:(.text+0x116b): undefined reference to `OSSL_NELEM' ec_asn1.c:(.text+0x118d): undefined reference to `OSSL_NELEM' clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[2]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170223 *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170223/crypto *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170223 root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170223 # exit exit Script done on Thu Feb 23 05:42:27 2017 Please fix! -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism God is dead! Yahweh lives! Jesus his only begotten Son is the Risen Saviour!! From matt at openssl.org Thu Feb 23 13:29:19 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Feb 2017 13:29:19 +0000 Subject: [openssl-dev] Openssl 1.0.2 snapshot bug In-Reply-To: <20170223125425.GA77540@doctor.nl2k.ab.ca> References: <20170223125425.GA77540@doctor.nl2k.ab.ca> Message-ID: <5e2de014-70b8-4286-6989-38bf4064aff2@openssl.org> On 23/02/17 12:54, The Doctor wrote: > Please fix! > This fix is already on the way: https://github.com/openssl/openssl/pull/2713 Matt From tshort at akamai.com Thu Feb 23 13:29:48 2017 From: tshort at akamai.com (Short, Todd) Date: Thu, 23 Feb 2017 13:29:48 +0000 Subject: [openssl-dev] Integrate EVP Cipher into OpenSSL cli Speed Test In-Reply-To: References: Message-ID: <1D160066-C27E-4F2D-AAEF-77A84FC1016C@akamai.com> Look at some of the changes to pull in Poly1305 and SipHash in to EVP: https://github.com/openssl/openssl/commit/52ad5b60e3a1fef12a1a5ea01527a90b8f92a34b https://github.com/openssl/openssl/commit/3f5616d734a92fdf99ab827f21e5b6cab85e7194 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Feb 22, 2017, at 11:00 PM, Schmicker, Robert > wrote: Hello, I successfully managed to integrate an encryption cipher into the EVP and has been tested to work and now I'd like to get some speed tests of the cipher using openssl's integrated speed test via the command line with the "-evp" flag. What I've done so far to try and integrate it into openssl's speed test.... 1) Confirmed EVP_mycipher() works 2) Noticed ./apps/speed.c was calling: case OPT_EVP: evp_cipher = EVP_get_cipherbyname(opt_arg()); 3) Then modified ./crypto/objects/objects.txt to include the necessary defines # Mycipher : MYCIPHER : mycipher 4) Edited crypto/evp/c_allc.c to include my cipher in the loading of all ciphers EVP_add_cipher(EVP_mycipher()); EVP_add_cipher_alias(SN_mycipher, "mycipher"); 5) Ran a make update then make and saw all necessary defines were generated However, the speed test cannot find my cipher because EVP_get_cipherbyname() returns NULL. Am I missing a step here or did I mis-configure something? It seems as if there's something to edit to tie the NID/SN/LN_mycipher to the algorithm. Any help is much appreciated! Rob Schmicker -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Feb 23 13:37:43 2017 From: levitte at openssl.org (Richard Levitte) Date: Thu, 23 Feb 2017 14:37:43 +0100 (CET) Subject: [openssl-dev] Openssl 1.0.2 snapshot bug In-Reply-To: <20170223125425.GA77540@doctor.nl2k.ab.ca> References: <20170223125425.GA77540@doctor.nl2k.ab.ca> Message-ID: <20170223.143743.1257054917908014050.levitte@openssl.org> Yup, we have a fix coming up: https://github.com/openssl/openssl/pull/2713 In message <20170223125425.GA77540 at doctor.nl2k.ab.ca> on Thu, 23 Feb 2017 05:54:25 -0700, The Doctor said: doctor> doctor> Script started on Thu Feb 23 05:41:55 2017 doctor> You have mail. doctor> root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170223 # makeless /usr/contrib/b in/configopenssl doctor> doctor> [?1h= doctor> #!/usr/local/bin/bash doctor> CC=/usr/local/bin/clang39 ./Configure --prefix=/usr/ BSD-x86_64 fips enable-gmp  experimental-jpake enable-rfc3779 enable-shared zlib-dynamic disable-sctp exper imental-store enable-ssl-trace enable-unit-test; make depend doctor> /usr/contrib/bin/configopenssl (END) doctor> [?1l>root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170223 # make doctor> doctor> making all in crypto... doctor> making all in crypto/objects... doctor> making all in crypto/md4... doctor> making all in crypto/md5... doctor> making all in crypto/sha... doctor> making all in crypto/mdc2... doctor> making all in crypto/hmac... doctor> making all in crypto/ripemd... doctor> making all in crypto/whrlpool... doctor> making all in crypto/des... doctor> making all in crypto/aes... doctor> making all in crypto/rc2... doctor> making all in crypto/rc4... doctor> making all in crypto/idea... doctor> making all in crypto/bf... doctor> making all in crypto/cast... doctor> making all in crypto/camellia... doctor> making all in crypto/seed... doctor> making all in crypto/modes... doctor> making all in crypto/bn... doctor> making all in crypto/ec... doctor> making all in crypto/rsa... doctor> making all in crypto/dsa... doctor> making all in crypto/ecdsa... doctor> making all in crypto/dh... doctor> making all in crypto/ecdh... doctor> making all in crypto/dso... doctor> making all in crypto/engine... doctor> making all in crypto/buffer... doctor> making all in crypto/bio... doctor> making all in crypto/stack... doctor> making all in crypto/lhash... doctor> making all in crypto/rand... doctor> making all in crypto/err... doctor> making all in crypto/evp... doctor> making all in crypto/asn1... doctor> making all in crypto/pem... doctor> making all in crypto/x509... doctor> making all in crypto/x509v3... doctor> making all in crypto/conf... doctor> making all in crypto/txt_db... doctor> making all in crypto/pkcs7... doctor> making all in crypto/pkcs12... doctor> making all in crypto/comp... doctor> making all in crypto/ocsp... doctor> making all in crypto/ui... doctor> making all in crypto/krb5... doctor> making all in crypto/cms... doctor> making all in crypto/pqueue... doctor> making all in crypto/ts... doctor> making all in crypto/jpake... doctor> making all in crypto/srp... doctor> making all in crypto/store... doctor> making all in crypto/cmac... doctor> if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libcrypto.so.1.0.0); fi doctor> [ -z "libcrypto" ] || /usr/local/bin/clang39 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso /usr/local/ssl/fips-2.0/lib/fips_premain.c /usr/local/ssl/fips-2.0/lib/fipscanister.o libcrypto.a doctor> libcrypto.a(ec_asn1.o): In function `EC_GROUP_get_basis_type': doctor> ec_asn1.c:(.text+0x37): undefined reference to `OSSL_NELEM' doctor> ec_asn1.c:(.text+0x64): undefined reference to `OSSL_NELEM' doctor> libcrypto.a(ec_asn1.o): In function `ec_asn1_group2pkparameters': doctor> ec_asn1.c:(.text+0x116b): undefined reference to `OSSL_NELEM' doctor> ec_asn1.c:(.text+0x118d): undefined reference to `OSSL_NELEM' doctor> clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation) doctor> *** Error code 1 doctor> doctor> Stop. doctor> make[2]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170223 doctor> *** Error code 1 doctor> doctor> Stop. doctor> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170223/crypto doctor> *** Error code 1 doctor> doctor> Stop. doctor> make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170223 doctor> root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170223 # exit doctor> doctor> exit doctor> doctor> Script done on Thu Feb 23 05:42:27 2017 doctor> doctor> Please fix! doctor> doctor> -- doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca doctor> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! doctor> http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism doctor> God is dead! Yahweh lives! Jesus his only begotten Son is the Risen Saviour!! doctor> -- doctor> openssl-dev mailing list doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev doctor> From rsalz at akamai.com Thu Feb 23 14:13:54 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 23 Feb 2017 14:13:54 +0000 Subject: [openssl-dev] Openssl 1.0.2 snapshot bug In-Reply-To: <20170223125425.GA77540@doctor.nl2k.ab.ca> References: <20170223125425.GA77540@doctor.nl2k.ab.ca> Message-ID: <384378c8ce3e4cf0b48a45de16265a23@usma1ex-dag1mb1.msg.corp.akamai.com> Fixed now. From abrahamendre9 at gmail.com Thu Feb 23 14:51:26 2017 From: abrahamendre9 at gmail.com (=?UTF-8?B?w4FicmFow6FtIEVuZHJl?=) Date: Thu, 23 Feb 2017 15:51:26 +0100 Subject: [openssl-dev] Feature discussion - Zero-knowledge-proofs Message-ID: I know, I know, zero knowledge proofs are not crypto. But: We live in the post-snowden era. Providers and centralized hosting services are becomming a larger threat than man-in-the-middle attacks. People (including me) are loosing their trust in cryptography that's only meant to protect sensitive data between the communicating nodes in transit, not on the nodes themselves. OpenSSL's philosophy is to bring primitives for algorithms that provide software-level privacy and otherwise require expertise/academic knowledge. Zero-knowledge technologies will (and already started to) get reputation and currently is in the premature state that cryptography was before OpenSSL. No low-level primitives, no high level "standard" API-s. I'm a researcher of zero-knowledge proofs and would be happy to contribute into openssl introducing this kind of privacy-protecting technology that in my opinion is not that far from cryptography or OpenSSL concept. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rschm2 at unh.newhaven.edu Thu Feb 23 14:38:20 2017 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Thu, 23 Feb 2017 14:38:20 +0000 Subject: [openssl-dev] Integrate EVP Cipher into OpenSSL cli Speed Test In-Reply-To: <1D160066-C27E-4F2D-AAEF-77A84FC1016C@akamai.com> References: , <1D160066-C27E-4F2D-AAEF-77A84FC1016C@akamai.com> Message-ID: Thanks! The moment after I sent that original email I realized in my infinite wisdom that I originally hard coded the NID value in my EVP implementation to get some testing to work. I then never went back and changed it to the define value... Regardless, thank you for the help. Rob From: Short, Todd Sent: Thursday, February 23, 8:29 AM Subject: Re: [openssl-dev] Integrate EVP Cipher into OpenSSL cli Speed Test To: openssl-dev at openssl.org, Schmicker, Robert Look at some of the changes to pull in Poly1305 and SipHash in to EVP: https://github.com/openssl/openssl/commit/52ad5b60e3a1fef12a1a5ea01527a90b8f92a34b https://github.com/openssl/openssl/commit/3f5616d734a92fdf99ab827f21e5b6cab85e7194 -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." On Feb 22, 2017, at 11:00 PM, Schmicker, Robert @unh.newhaven.edu> wrote: Hello, I successfully managed to integrate an encryption cipher into the EVP and has been tested to work and now I'd like to get some speed tests of the cipher using openssl's integrated speed test via the command line with the "-evp" flag. What I've done so far to try and integrate it into openssl's speed test.... 1) Confirmed EVP_mycipher() works 2) Noticed ./apps/speed.c was calling: case OPT_EVP: evp_cipher = EVP_get_cipherbyname(opt_arg()); 3) Then modified ./crypto/objects/objects.txt to include the necessary defines # Mycipher : MYCIPHER : mycipher 4) Edited crypto/evp/c_allc.c to include my cipher in the loading of all ciphers EVP_add_cipher(EVP_mycipher()); EVP_add_cipher_alias(SN_mycipher, "mycipher"); 5) Ran a make update then make and saw all necessary defines were generated However, the speed test cannot find my cipher because EVP_get_cipherbyname() returns NULL. Am I missing a step here or did I mis-configure something? It seems as if there's something to edit to tie the NID/SN/LN_mycipher to the algorithm. Any help is much appreciated! Rob Schmicker -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewponomarenko at yandex.ru Sun Feb 26 06:26:06 2017 From: andrewponomarenko at yandex.ru (Andrey Ponomarenko) Date: Sun, 26 Feb 2017 09:26:06 +0300 Subject: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2 In-Reply-To: <1485847232.6050.11.camel@redhat.com> References: <1485847232.6050.11.camel@redhat.com> Message-ID: <4230281488090366@web22o.yandex.ru> 31.01.2017, 10:21, "Nikos Mavrogiannopoulos": > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev > wrote: >> ?[moving from github to -dev] >> >> ?On 01/27/2017 07:36 AM, mattcaswell wrote: >> ?> 1.0.2 is the software version. >> ?> The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - >> ?> which is different. Software version 1.0.2 is a drop in replacement >> ?> for 1.0.1, which is a drop in replacement for 1.0.0 - hence they >> ?> all have the same ABI version. >> ?> >> >> ?There was some discussion about 1.0.1 being EoL on a FreeBSD list >> ?[0], and whether it would make sense to move to 1.0.2 on their stable >> ?branch, which led to someone making the claim that 1.0.2 has removed >> ?4 symbols compared to 1.0.1, and thus is not strictly ABI compatible, >> ?linking to https://abi-laboratory.pro/tracker/timeline/openssl/ .? If >> ?I start semi-randomly clicking around, I can find a page [1] that >> ?seems to claim the missing symbols are: >> ?ASN1_STRING_clear_free() >> ?ENGINE_load_rsax() >> ?SRP_user_pwd_free() >> ?SRP_VBASE_get1_by_user() > > ... >> ?One (naive?) idea for a home-grown solution would be to come up with >> ?a scheme to serialize the public ABI to a file in the repo, maybe >> ?regenerated as part of 'make test', and ensure that that file is >> ?append-only, at least between releases.? But I don't know if the >> ?state of the art is more advanced than that -- are there better >> ?options? > > The abi-dumper and abi-compliance-checker tools can be used for that > purpose. In fact they are the back-end tools used by the abi-laboratory > you quote above. Hello, These pages on OpenSSL wiki may be helpful: https://wiki.openssl.org/index.php/Binary_Compatibility https://wiki.openssl.org/index.php/ABI_Tracker Thank you. From levitte at openssl.org Sun Feb 26 08:10:35 2017 From: levitte at openssl.org (Richard Levitte) Date: Sun, 26 Feb 2017 09:10:35 +0100 (CET) Subject: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2 In-Reply-To: References: Message-ID: <20170226.091035.1875080190946668032.levitte@openssl.org> In message on Fri, 27 Jan 2017 10:54:35 -0600, Benjamin Kaduk via openssl-dev said: openssl-dev> There was some discussion about 1.0.1 being EoL on a FreeBSD list [0], openssl-dev> and whether it would make sense to move to 1.0.2 on their stable openssl-dev> branch, which led to someone making the claim that 1.0.2 has removed 4 openssl-dev> symbols compared to 1.0.1, and thus is not strictly ABI compatible, openssl-dev> linking to https://abi-laboratory.pro/tracker/timeline/openssl/ . If I openssl-dev> start semi-randomly clicking around, I can find a page [1] that seems openssl-dev> to claim the missing symbols are: openssl-dev> ASN1_STRING_clear_free() openssl-dev> ENGINE_load_rsax() openssl-dev> SRP_user_pwd_free() openssl-dev> SRP_VBASE_get1_by_user() I haven't make a complete analysis over versions, just did a comparison of the files that define what we regard as public symbols (util/libeay.num and util/libssl.num) in the latest 1.0.1 and 1.0.2 releases. Diffs attached. As you can see, ENGINE_load_rsax *did* go away. That happened here: commit 74184b6f21e095dacd6193a78785a47dd515f0dc Author: Dr. Stephen Henson Date: Sun Dec 1 23:06:33 2013 +0000 RSAX no longer compiled. I'm afraid I can't remember the reasoning behind this commit... The rest of those mentioned above haven't moved at all as far as I can see. You may notice that some of the symbols in libssl (ssleay.num) did move between "modules" (which in this case can be defined as a keyword you can say no to when configuring). I'm unsure how that affects your view on our stability, suffice to say that with default configuration, it doesn't affect the ABI one bit. FYI, here's how the diffs were produced: : ; (LANG=C; (cd ../1.0.1; pwd; git status); pwd; git status; diff -u ../1.0.1/util/libeay.num util/libeay.num > /tmp/libeay.num.diff) /home/levitte/gitwrk/openssl.net/official/1.0.1 HEAD detached at OpenSSL_1_0_1u nothing to commit, working tree clean /home/levitte/gitwrk/openssl.net/official/1.0.2 HEAD detached at OpenSSL_1_0_2k nothing to commit, working tree clean : ; (LANG=C; (cd ../1.0.1; pwd; git status); pwd; git status; diff -u ../1.0.1/util/ssleay.num util/ssleay.num > /tmp/ssleay.num.diff) /home/levitte/gitwrk/openssl.net/official/1.0.1 HEAD detached at OpenSSL_1_0_1u nothing to commit, working tree clean /home/levitte/gitwrk/openssl.net/official/1.0.2 HEAD detached at OpenSSL_1_0_2k nothing to commit, working tree clean Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- A non-text attachment was scrubbed... Name: libeay.num.diff Type: text/x-patch Size: 7487 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssleay.num.diff Type: text/x-patch Size: 5497 bytes Desc: not available URL: From kurt at roeckx.be Sun Feb 26 13:26:43 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 26 Feb 2017 14:26:43 +0100 Subject: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2 In-Reply-To: <4230281488090366@web22o.yandex.ru> References: <1485847232.6050.11.camel@redhat.com> <4230281488090366@web22o.yandex.ru> Message-ID: <20170226132643.ybme57dlg4rposmz@roeckx.be> On Sun, Feb 26, 2017 at 09:26:06AM +0300, Andrey Ponomarenko wrote: > 31.01.2017, 10:21, "Nikos Mavrogiannopoulos": > > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev > > wrote: > >> ?[moving from github to -dev] > >> > >> ?On 01/27/2017 07:36 AM, mattcaswell wrote: > >> ?> 1.0.2 is the software version. > >> ?> The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - > >> ?> which is different. Software version 1.0.2 is a drop in replacement > >> ?> for 1.0.1, which is a drop in replacement for 1.0.0 - hence they > >> ?> all have the same ABI version. > >> ?> > >> > >> ?There was some discussion about 1.0.1 being EoL on a FreeBSD list > >> ?[0], and whether it would make sense to move to 1.0.2 on their stable > >> ?branch, which led to someone making the claim that 1.0.2 has removed > >> ?4 symbols compared to 1.0.1, and thus is not strictly ABI compatible, > >> ?linking to https://abi-laboratory.pro/tracker/timeline/openssl/ .? If > >> ?I start semi-randomly clicking around, I can find a page [1] that > >> ?seems to claim the missing symbols are: > >> ?ASN1_STRING_clear_free() > >> ?ENGINE_load_rsax() > >> ?SRP_user_pwd_free() > >> ?SRP_VBASE_get1_by_user() It's normal that you might see some symbols removed if you compare something like 1.0.1t against 1.0.2, but it shouldn't when compared to 1.0.2k. CRYPTO_memcmp was added in 1.0.1d. ASN1_STRING_clear_free was added in 1.0.1m and 1.0.2a In 1.0.1s and 1.0.2g the following were added (for CVE-2016-0798): SRP_VBASE_get1_by_user; SRP_user_pwd_free; ENGINE_load_rsax seems to have been removed because it didn't compile? That looks like the only symbol that has been removed, and it probably shouldn't have. Kurt From appro at openssl.org Sun Feb 26 22:23:42 2017 From: appro at openssl.org (Andy Polyakov) Date: Sun, 26 Feb 2017 23:23:42 +0100 Subject: [openssl-dev] Travis [extended tests] tag Message-ID: <74c15694-0c10-8886-f4f5-0d6df6016b95@openssl.org> In order to improve CI turn-around times Travis config in master branch was tweaked to minimize the time it takes to process pull requests. This is done by "short-circuiting" most expensive tests: sanitizers, coverage, wine-based tests. Thing to keep in mind is that "short-circuited" test come out as passed/green. Rationale is that if minimum tests pass, the build should still be marked green on github. Even though it gives somewhat deceiving picture, in sense that you get green check mark for test that might have failed otherwise. Expensive tests are marked with "EXTENDED_TEST=yes" on the build page, and one can easily see if it was skipped by looking at time it took to skip it, it should be ~1 minute. At the same time it would be inappropriate to deny the mere possibility to exercise complete test set even on per-pull-request basis. [Note that complete tests are always executed for each repo-push.] For this reason possibility to "opt-in" for expensive tests was arranged by adding "[extended tests]" tag to *last* commit. If forgotten (in case you reckoned that request is "worthy" extended tests), or claimed desired afterwards, it's possible to simply amend the last commit, add the tag and force push. In such case minimal tests would be effectively wasted (because they will be executed twice), but overall it should still be resource saving, since majority of pull requests won't require extended testing. And in the context it's worth keeping in mind that it's possible to skip CI tests altogether by tagging commit with "[skip ci]". This option is appropriate for commentary or documentation typo fixes, readme updates, non-x86 code updates... From kurt at roeckx.be Sun Feb 26 22:33:59 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 26 Feb 2017 23:33:59 +0100 Subject: [openssl-dev] Travis [extended tests] tag In-Reply-To: <74c15694-0c10-8886-f4f5-0d6df6016b95@openssl.org> References: <74c15694-0c10-8886-f4f5-0d6df6016b95@openssl.org> Message-ID: <20170226223359.yv7p2o3ebhpu7b25@roeckx.be> On Sun, Feb 26, 2017 at 11:23:42PM +0100, Andy Polyakov wrote: > In order to improve CI turn-around times Travis config in master branch > was tweaked to minimize the time it takes to process pull requests. This > is done by "short-circuiting" most expensive tests: sanitizers, > coverage, wine-based tests. Thing to keep in mind is that > "short-circuited" test come out as passed/green. Rationale is that if > minimum tests pass, the build should still be marked green on github. > Even though it gives somewhat deceiving picture, in sense that you get > green check mark for test that might have failed otherwise. Expensive > tests are marked with "EXTENDED_TEST=yes" on the build page, and one can > easily see if it was skipped by looking at time it took to skip it, it > should be ~1 minute. > > At the same time it would be inappropriate to deny the mere possibility > to exercise complete test set even on per-pull-request basis. [Note that > complete tests are always executed for each repo-push.] For this reason > possibility to "opt-in" for expensive tests was arranged by adding > "[extended tests]" tag to *last* commit. If forgotten (in case you > reckoned that request is "worthy" extended tests), or claimed desired > afterwards, it's possible to simply amend the last commit, add the tag > and force push. In such case minimal tests would be effectively wasted > (because they will be executed twice), but overall it should still be > resource saving, since majority of pull requests won't require extended > testing. > > And in the context it's worth keeping in mind that it's possible to skip > CI tests altogether by tagging commit with "[skip ci]". This option is > appropriate for commentary or documentation typo fixes, readme updates, > non-x86 code updates... Can you explain how to tag it? Kurt From rsalz at akamai.com Sun Feb 26 22:44:19 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 26 Feb 2017 22:44:19 +0000 Subject: [openssl-dev] Travis [extended tests] tag In-Reply-To: <20170226223359.yv7p2o3ebhpu7b25@roeckx.be> References: <74c15694-0c10-8886-f4f5-0d6df6016b95@openssl.org> <20170226223359.yv7p2o3ebhpu7b25@roeckx.be> Message-ID: <480b7f900649456f81bf968181f1489b@usma1ex-dag1mb1.msg.corp.akamai.com> > > tests was arranged by adding "[extended tests]" tag to *last* commit. ... > > And in the context it's worth keeping in mind that it's possible to > > skip CI tests altogether by tagging commit with "[skip ci]". This ... >> > Can you explain how to tag it? Your commit message should have the literal text above in it. From appro at openssl.org Sun Feb 26 22:45:30 2017 From: appro at openssl.org (Andy Polyakov) Date: Sun, 26 Feb 2017 23:45:30 +0100 Subject: [openssl-dev] Travis [extended tests] tag In-Reply-To: <20170226223359.yv7p2o3ebhpu7b25@roeckx.be> References: <74c15694-0c10-8886-f4f5-0d6df6016b95@openssl.org> <20170226223359.yv7p2o3ebhpu7b25@roeckx.be> Message-ID: <775b38a0-53cf-0cec-de38-e85bbd947874@openssl.org> >> In order to improve CI turn-around times Travis config in master branch >> was tweaked to minimize the time it takes to process pull requests. This >> is done by "short-circuiting" most expensive tests: sanitizers, >> coverage, wine-based tests. Thing to keep in mind is that >> "short-circuited" test come out as passed/green. Rationale is that if >> minimum tests pass, the build should still be marked green on github. >> Even though it gives somewhat deceiving picture, in sense that you get >> green check mark for test that might have failed otherwise. Expensive >> tests are marked with "EXTENDED_TEST=yes" on the build page, and one can >> easily see if it was skipped by looking at time it took to skip it, it >> should be ~1 minute. >> >> At the same time it would be inappropriate to deny the mere possibility >> to exercise complete test set even on per-pull-request basis. [Note that >> complete tests are always executed for each repo-push.] For this reason >> possibility to "opt-in" for expensive tests was arranged by adding >> "[extended tests]" tag to *last* commit. If forgotten (in case you >> reckoned that request is "worthy" extended tests), or claimed desired >> afterwards, it's possible to simply amend the last commit, add the tag >> and force push. In such case minimal tests would be effectively wasted >> (because they will be executed twice), but overall it should still be >> resource saving, since majority of pull requests won't require extended >> testing. >> >> And in the context it's worth keeping in mind that it's possible to skip >> CI tests altogether by tagging commit with "[skip ci]". This option is >> appropriate for commentary or documentation typo fixes, readme updates, >> non-x86 code updates... > > Can you explain how to tag it? Oh! Just add it anywhere in commit message, or even subject line. There is only one thing that is essential, it can't be broken between multiple lines. In the nutshell [extented tests] (or [skip ci]) has to be grep-able, that's all. From andrewponomarenko at yandex.ru Mon Feb 27 06:21:22 2017 From: andrewponomarenko at yandex.ru (Andrey Ponomarenko) Date: Mon, 27 Feb 2017 09:21:22 +0300 Subject: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2 In-Reply-To: <20170226132643.ybme57dlg4rposmz@roeckx.be> References: <1485847232.6050.11.camel@redhat.com> <4230281488090366@web22o.yandex.ru> <20170226132643.ybme57dlg4rposmz@roeckx.be> Message-ID: <12580291488176482@web9g.yandex.ru> An HTML attachment was scrubbed... URL: From emilia at openssl.org Mon Feb 27 10:04:59 2017 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Mon, 27 Feb 2017 10:04:59 +0000 Subject: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th) Message-ID: Hi OpenSSL developers! We?re always looking for ways to improve code quality and pay our technical debt. This week we thought we?d run a little experiment. We declare this Tuesday (Feb 28th) Code Health Tuesday. We?ll be setting some time aside to do cleanups in the codebase. The theme is ?Delete?: we?ll be cleaning up unused files, dead code, and obsolete hacks. We invite you all to participate on Github! Cheers, Emilia FAQ: Q: How do I participate? A: Find something to delete. Create a Github pull request and add the ?code-health? label. We?ll be monitoring Github for quick turnaround. Q: Which branches should I target? A: You should target master. In stable branches, code churn comes with a cost, so let?s focus on the next release. Q: What can I delete? A: Normal compatibility rules apply. You cannot delete anything from public headers, remove command-line tool options or prune supported platform configurations. You can delete dead code, obsolete workarounds (16-bit platforms!) and outdated documentation. If you?re not sure about a particular functionality, open a Github issue and add the ?code health? label. Q: Do you have any tools to find what to delete? A: We have a coverage report: https://coveralls.io/github/openssl/openssl We?ll also be setting up a tools repo where you can share any tools that you build. Q: Will you do it again? A: We hope so! This is an experiment but we?ll be looking into making it a habit. We have a list of ideas for themed Tuesdays lined up: Document, Test, Refactor, ... Q: How did you come up with this idea? A: We were looking at this file? *https://github.com/openssl/openssl/blob/master/crypto/pkcs7/pk7_dgst.c * -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Mon Feb 27 14:54:09 2017 From: tshort at akamai.com (Short, Todd) Date: Mon, 27 Feb 2017 14:54:09 +0000 Subject: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th) In-Reply-To: References: Message-ID: <9ECBF19A-3239-440C-B874-B959B6BB912B@akamai.com> I?m not sure us mere mortals can add a label to a PR... -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Feb 27, 2017, at 5:04 AM, Emilia K?sper > wrote: Hi OpenSSL developers! We?re always looking for ways to improve code quality and pay our technical debt. This week we thought we?d run a little experiment. We declare this Tuesday (Feb 28th) Code Health Tuesday. We?ll be setting some time aside to do cleanups in the codebase. The theme is ?Delete?: we?ll be cleaning up unused files, dead code, and obsolete hacks. We invite you all to participate on Github! Cheers, Emilia FAQ: Q: How do I participate? A: Find something to delete. Create a Github pull request and add the ?code-health? label. We?ll be monitoring Github for quick turnaround. Q: Which branches should I target? A: You should target master. In stable branches, code churn comes with a cost, so let?s focus on the next release. Q: What can I delete? A: Normal compatibility rules apply. You cannot delete anything from public headers, remove command-line tool options or prune supported platform configurations. You can delete dead code, obsolete workarounds (16-bit platforms!) and outdated documentation. If you?re not sure about a particular functionality, open a Github issue and add the ?code health? label. Q: Do you have any tools to find what to delete? A: We have a coverage report: https://coveralls.io/github/openssl/openssl We?ll also be setting up a tools repo where you can share any tools that you build. Q: Will you do it again? A: We hope so! This is an experiment but we?ll be looking into making it a habit. We have a list of ideas for themed Tuesdays lined up: Document, Test, Refactor, ... Q: How did you come up with this idea? A: We were looking at this file? https://github.com/openssl/openssl/blob/master/crypto/pkcs7/pk7_dgst.c -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilia at openssl.org Mon Feb 27 15:00:10 2017 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Mon, 27 Feb 2017 15:00:10 +0000 Subject: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th) In-Reply-To: <9ECBF19A-3239-440C-B874-B959B6BB912B@akamai.com> References: <9ECBF19A-3239-440C-B874-B959B6BB912B@akamai.com> Message-ID: Ah... Well, just add "Code Health" to your PR title, and we'll do the labeling. On Mon, Feb 27, 2017 at 3:54 PM Short, Todd wrote: > I?m not sure us mere mortals can add a label to a PR... > -- > -Todd Short > // tshort at akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Feb 27, 2017, at 5:04 AM, Emilia K?sper wrote: > > Hi OpenSSL developers! > > We?re always looking for ways to improve code quality and pay our > technical debt. This week we thought we?d run a little experiment. > > We declare this Tuesday (Feb 28th) Code Health Tuesday. We?ll be setting > some time aside to do cleanups in the codebase. The theme is ?Delete?: > we?ll be cleaning up unused files, dead code, and obsolete hacks. We invite > you all to participate on Github! > > Cheers, > Emilia > > FAQ: > > Q: How do I participate? > A: Find something to delete. Create a Github pull request and add the > ?code-health? label. We?ll be monitoring Github for quick turnaround. > > Q: Which branches should I target? > A: You should target master. In stable branches, code churn comes with a > cost, so let?s focus on the next release. > > Q: What can I delete? > A: Normal compatibility rules apply. You cannot delete anything from > public headers, remove command-line tool options or prune supported > platform configurations. You can delete dead code, obsolete workarounds > (16-bit platforms!) and outdated documentation. If you?re not sure about a > particular functionality, open a Github issue and add the ?code health? > label. > > Q: Do you have any tools to find what to delete? > A: We have a coverage report: https://coveralls.io/github/openssl/openssl > > We?ll also be setting up a tools repo where you can share any tools that > you build. > > Q: Will you do it again? > A: We hope so! This is an experiment but we?ll be looking into making it a > habit. We have a list of ideas for themed Tuesdays lined up: Document, > Test, Refactor, ... > > Q: How did you come up with this idea? > A: We were looking at this file? > *https://github.com/openssl/openssl/blob/master/crypto/pkcs7/pk7_dgst.c > * > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Feb 27 15:24:26 2017 From: levitte at openssl.org (Richard Levitte) Date: Mon, 27 Feb 2017 16:24:26 +0100 (CET) Subject: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th) In-Reply-To: <9ECBF19A-3239-440C-B874-B959B6BB912B@akamai.com> References: <9ECBF19A-3239-440C-B874-B959B6BB912B@akamai.com> Message-ID: <20170227.162426.1454462425132242129.levitte@openssl.org> I'd suggest prefixing the PR subject with "code-health:" or "[code-health]", just like work in progress is prefixed "WIP:" or "[WIP]" Cheers, Richard In message <9ECBF19A-3239-440C-B874-B959B6BB912B at akamai.com> on Mon, 27 Feb 2017 14:54:09 +0000, "Short, Todd" said: tshort> I?m not sure us mere mortals can add a label to a PR... tshort> -- tshort> -Todd Short tshort> // tshort at akamai.com tshort> // "One if by land, two if by sea, three if by the Internet." tshort> tshort> On Feb 27, 2017, at 5:04 AM, Emilia K?sper tshort> wrote: tshort> tshort> tshort> tshort> tshort> Hi OpenSSL developers! tshort> tshort> We?re always looking for ways to improve code quality and pay our tshort> technical debt. This week we thought we?d run a little experiment. tshort> tshort> We declare this Tuesday (Feb 28th) Code Health Tuesday. We?ll be tshort> setting some time aside to do cleanups in the codebase. The theme tshort> is ?Delete?: we?ll be cleaning up unused files, dead code, and tshort> obsolete hacks. We invite you all to participate on Github! tshort> tshort> tshort> Cheers, tshort> Emilia tshort> tshort> FAQ: tshort> tshort> Q: How do I participate? tshort> A: Find something to delete. Create a Github pull request and add tshort> the ?code-health? label. We?ll be monitoring Github for quick tshort> turnaround. tshort> tshort> Q: Which branches should I target? tshort> A: You should target master. In stable branches, code churn comes tshort> with a cost, so let?s focus on the next release. tshort> tshort> Q: What can I delete? tshort> A: Normal compatibility rules apply. You cannot delete anything tshort> from public headers, remove command-line tool options or prune tshort> supported platform configurations. You can delete dead code, tshort> obsolete workarounds (16-bit platforms!) and outdated tshort> documentation. If you?re not sure about a particular tshort> functionality, open a Github issue and add the ?code health? tshort> label. tshort> tshort> Q: Do you have any tools to find what to delete? tshort> A: We have a coverage report: tshort> https://coveralls.io/github/openssl/openssl tshort> We?ll also be setting up a tools repo where you can share any tshort> tools that you build. tshort> tshort> Q: Will you do it again? tshort> A: We hope so! This is an experiment but we?ll be looking into tshort> making it a habit. We have a list of ideas for themed Tuesdays tshort> lined up: Document, Test, Refactor, ... tshort> tshort> Q: How did you come up with this idea? tshort> A: We were looking at this file? tshort> https://github.com/openssl/openssl/blob/master/crypto/pkcs7/pk7_dgst.c tshort> tshort> -- tshort> openssl-dev mailing list tshort> To unsubscribe: tshort> https://mta.openssl.org/mailman/listinfo/openssl-dev tshort> tshort> From beldmit at gmail.com Mon Feb 27 20:25:12 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 27 Feb 2017 23:25:12 +0300 Subject: [openssl-dev] Private key size in req output Message-ID: Hello, Currently the req command prints key size before generating the private key. If the key size can't be determined from the specified parameters, it prints the default value. For some algorithms (e.g GOST ones) the key bits value is fixed and can't be extracted from the parameters. In such situations we have either hardcode number of bits for GOST algorithms or (and it seems better to me) print the information after the key generation when we have the EVP_PKEY object and can print the exact value. What do you think about it? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Mon Feb 27 22:06:32 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 27 Feb 2017 16:06:32 -0600 Subject: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2 In-Reply-To: <20170226132643.ybme57dlg4rposmz@roeckx.be> References: <1485847232.6050.11.camel@redhat.com> <4230281488090366@web22o.yandex.ru> <20170226132643.ybme57dlg4rposmz@roeckx.be> Message-ID: On 02/26/2017 07:26 AM, Kurt Roeckx wrote: > It's normal that you might see some symbols removed if you compare > something like 1.0.1t against 1.0.2, but it shouldn't when compared > to 1.0.2k. I agree, and figured this out at some point after I sent the initial query. Given the low interest leve the thread had at the time, I didn't see a need to send a follow-up clarifying. > CRYPTO_memcmp was added in 1.0.1d. > > ASN1_STRING_clear_free was added in 1.0.1m and 1.0.2a > > In 1.0.1s and 1.0.2g the following were added (for CVE-2016-0798): > SRP_VBASE_get1_by_user; > SRP_user_pwd_free; > > ENGINE_load_rsax seems to have been removed because it didn't > compile? That looks like the only symbol that has been removed, > and it probably shouldn't have. > Someone(TM) should probably make a pull request to put back a stub function, then. (Maybe something for tomorrow's code health exercies...) I wonder if the ABI laboratory has a way to compare specific versions that are not direct successors, so that the tip of 1.0.1 could be compared to the tip of 1.0.2 (which is what would make the most sense to compare, to me). (I couldn't find such a thing with my random clicking around.) -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Mon Feb 27 22:09:53 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 27 Feb 2017 16:09:53 -0600 Subject: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2 In-Reply-To: <20170226.091035.1875080190946668032.levitte@openssl.org> References: <20170226.091035.1875080190946668032.levitte@openssl.org> Message-ID: <7f6416ec-0754-2970-1023-af0411e36bad@akamai.com> On 02/26/2017 02:10 AM, Richard Levitte wrote: > In message on Fri, 27 Jan 2017 10:54:35 -0600, Benjamin Kaduk via openssl-dev said: > > openssl-dev> There was some discussion about 1.0.1 being EoL on a FreeBSD list [0], > openssl-dev> and whether it would make sense to move to 1.0.2 on their stable > openssl-dev> branch, which led to someone making the claim that 1.0.2 has removed 4 > openssl-dev> symbols compared to 1.0.1, and thus is not strictly ABI compatible, > openssl-dev> linking to https://abi-laboratory.pro/tracker/timeline/openssl/ . If I > openssl-dev> start semi-randomly clicking around, I can find a page [1] that seems > openssl-dev> to claim the missing symbols are: > openssl-dev> ASN1_STRING_clear_free() > openssl-dev> ENGINE_load_rsax() > openssl-dev> SRP_user_pwd_free() > openssl-dev> SRP_VBASE_get1_by_user() > > I haven't make a complete analysis over versions, just did a > comparison of the files that define what we regard as public symbols > (util/libeay.num and util/libssl.num) in the latest 1.0.1 and 1.0.2 > releases. Diffs attached. > > As you can see, ENGINE_load_rsax *did* go away. That happened here: > > commit 74184b6f21e095dacd6193a78785a47dd515f0dc > Author: Dr. Stephen Henson > Date: Sun Dec 1 23:06:33 2013 +0000 > > RSAX no longer compiled. > > I'm afraid I can't remember the reasoning behind this commit... > > The rest of those mentioned above haven't moved at all as far as I can > see. You may notice that some of the symbols in libssl (ssleay.num) > did move between "modules" (which in this case can be defined as a > keyword you can say no to when configuring). I'm unsure how that > affects your view on our stability, suffice to say that with default > configuration, it doesn't affect the ABI one bit. > Agreed. Though, just the presence of a function/symbol does not preclude ABI changes for that symbol, if the function signature (or behavior) changed. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilia at openssl.org Tue Feb 28 11:53:20 2017 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Tue, 28 Feb 2017 11:53:20 +0000 Subject: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th) In-Reply-To: <20170227.162426.1454462425132242129.levitte@openssl.org> References: <9ECBF19A-3239-440C-B874-B959B6BB912B@akamai.com> <20170227.162426.1454462425132242129.levitte@openssl.org> Message-ID: This is happening NOW :) https://github.com/openssl/openssl/pulls?q=is%3Apr%20label%3Acode-health On Mon, Feb 27, 2017 at 4:24 PM Richard Levitte wrote: > I'd suggest prefixing the PR subject with "code-health:" or > "[code-health]", just like work in progress is prefixed "WIP:" or > "[WIP]" > > Cheers, > Richard > > In message <9ECBF19A-3239-440C-B874-B959B6BB912B at akamai.com> on Mon, 27 > Feb 2017 14:54:09 +0000, "Short, Todd" said: > > tshort> I?m not sure us mere mortals can add a label to a PR... > tshort> -- > tshort> -Todd Short > tshort> // tshort at akamai.com > tshort> // "One if by land, two if by sea, three if by the Internet." > tshort> > tshort> On Feb 27, 2017, at 5:04 AM, Emilia K?sper > > tshort> wrote: > tshort> > tshort> > tshort> > tshort> > tshort> Hi OpenSSL developers! > tshort> > tshort> We?re always looking for ways to improve code quality and pay > our > tshort> technical debt. This week we thought we?d run a little > experiment. > tshort> > tshort> We declare this Tuesday (Feb 28th) Code Health Tuesday. We?ll > be > tshort> setting some time aside to do cleanups in the codebase. The > theme > tshort> is ?Delete?: we?ll be cleaning up unused files, dead code, and > tshort> obsolete hacks. We invite you all to participate on Github! > tshort> > tshort> > tshort> Cheers, > tshort> Emilia > tshort> > tshort> FAQ: > tshort> > tshort> Q: How do I participate? > tshort> A: Find something to delete. Create a Github pull request and > add > tshort> the ?code-health? label. We?ll be monitoring Github for quick > tshort> turnaround. > tshort> > tshort> Q: Which branches should I target? > tshort> A: You should target master. In stable branches, code churn > comes > tshort> with a cost, so let?s focus on the next release. > tshort> > tshort> Q: What can I delete? > tshort> A: Normal compatibility rules apply. You cannot delete anything > tshort> from public headers, remove command-line tool options or prune > tshort> supported platform configurations. You can delete dead code, > tshort> obsolete workarounds (16-bit platforms!) and outdated > tshort> documentation. If you?re not sure about a particular > tshort> functionality, open a Github issue and add the ?code health? > tshort> label. > tshort> > tshort> Q: Do you have any tools to find what to delete? > tshort> A: We have a coverage report: > tshort> https://coveralls.io/github/openssl/openssl > tshort> We?ll also be setting up a tools repo where you can share any > tshort> tools that you build. > tshort> > tshort> Q: Will you do it again? > tshort> A: We hope so! This is an experiment but we?ll be looking into > tshort> making it a habit. We have a list of ideas for themed Tuesdays > tshort> lined up: Document, Test, Refactor, ... > tshort> > tshort> Q: How did you come up with this idea? > tshort> A: We were looking at this file? > tshort> > https://github.com/openssl/openssl/blob/master/crypto/pkcs7/pk7_dgst.c > tshort> > tshort> -- > tshort> openssl-dev mailing list > tshort> To unsubscribe: > tshort> https://mta.openssl.org/mailman/listinfo/openssl-dev > tshort> > tshort> > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: