Re: [openssl-dev] Continuous Integration for OpenSSL
The URL is https://openssl-sanity.cisco.com:8443/ On 08/24/2015 05:08 AM, Ben Laurie wrote: On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com mailto:rs...@akamai.com wrote: On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com mailto:rs...@akamai.com wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Are these linked from the website somewhere? No. John Foley @Cisco posted bout them, I think, and Matt has a login and is careful about failures. Seems to me they should be on the website. BTW I tracked it down: http://openssl-sanity.cisco.com:8080/ However, doesn't appear to be up. :-( I believe it also (at least when working) sends email on failures - would be nice if those went to a list... ___ 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
[openssl-dev] [openssl.org #4019] [PATCH] dgst.pod: Remove redundant documentation of -hmac
Option -hmac was documented twice. The issue was reported here: https://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=3930 --- doc/apps/dgst.pod | 5 - 1 file changed, 5 deletions(-) diff --git a/doc/apps/dgst.pod b/doc/apps/dgst.pod index 236e1b7..b156097 100644 --- a/doc/apps/dgst.pod +++ b/doc/apps/dgst.pod @@ -13,7 +13,6 @@ Bopenssl Bdgst [B-hex] [B-binary] [B-r] -[B-hmac arg] [B-non-fips-allow] [B-out filename] [B-sign filename] @@ -64,10 +63,6 @@ output the digest or signature in binary form. output the digest in the coreutils format used by programs like Bsha1sum. -=item B-hmac arg - -set the HMAC key to arg. - =item B-non-fips-allow Allow use of non FIPS digest when in FIPS mode. This has no effect when not in -- 1.8.4 ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4018] [BUG] openssl ocsp command returns exist code 0 even if responder returns error
Hi, When doing ocsp query using openssl ocsp command bundled with openssl 1.0.2d, and ocsp responder returns non-successful status code (e.g., trylater(3)), openssl ocsp command still returns exit status code 0. I'm not sure this is intentional, but apparently ocsp query is failed because we didn't get the response back, so it should return non zero status code. The attached patch will fix this issue. BTW, I'm using Debian sid. Best regards, Tatsuhiro Tsujikawa --- openssl-1.0.2d/apps/ocsp.c.orig 2015-08-21 22:57:22.682709126 +0900 +++ openssl-1.0.2d/apps/ocsp.c 2015-08-21 22:58:13.558499890 +0900 @@ -787,7 +787,7 @@ OCSP_response_status_str(i), i); if (ignore_err) goto redo_accept; -ret = 0; + goto end; } ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Sat, 22 Aug 2015 10:21:42 + Alessandro Ghedini via RT r...@openssl.org wrote: Which adds support for Camellia GCM and adds the correspondent TLS cipher suites. Most of the code comes from the AES GCM implementation, so maybe there's an opportunity for some refactoring there. May I ask one question: Why? From what I observed others are moving away from camellia [1]. So why should openssl add more camellia support? From what I'm aware camellia is a block cipher like aes, and there is no serious problem with AES. Does camellia offer any significant advantage in any situation that would justify increasing support? I think a large problem of TLS in general and OpenSSL in particular is feature bloat. In the past features got added not because there was a clear need for them, but because we can. After all the whole heartbleed story can largely be explained by that. I'd propose that OpenSSL doesn't add any new features without a clear explanation what advantage they bring in which situation - and who is likely going to use that feature. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1036765 -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpcZUFWrovNx.pgp Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Mon, Aug 24, 2015 at 05:41:19PM +, Salz, Rich via RT wrote: Does camellia offer any significant advantage in any situation that would justify increasing support? Yes, I'd like to know who needs it. GOST is going to move to an externally-maintained ENGINE (thanks, Dimitry:). We should look at moving other ciphers out of the core the same way. The OID's will need to be maintained, since the run-time really wants to deal with NID's, and figuring out how to make them first-class citizens with an EVP interface would take some thought, but Blowfish, Cast, Camellia, SEED, and Whirlpool could all be pushed out, IMHO. IIRC Camellia is more equal than the others. In particular its inclusion in NESSIE and broad adoption make it a plausible backup block cipher after AES. So while we can consider dropping many of the more obscure and obsolete algorithms, Camellia is probably best retained. It is not clear that Intel et. al. will devoide any chip real-estate to supporting it in hardware, so it will not be quite as attractive as AES for most users, but it seems to be a fine cipher in most other regards. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Sat, 22 Aug 2015 10:21:42 + Alessandro Ghedini via RT r...@openssl.org wrote: Which adds support for Camellia GCM and adds the correspondent TLS cipher suites. Most of the code comes from the AES GCM implementation, so maybe there's an opportunity for some refactoring there. May I ask one question: Why? From what I observed others are moving away from camellia [1]. So why should openssl add more camellia support? From what I'm aware camellia is a block cipher like aes, and there is no serious problem with AES. Does camellia offer any significant advantage in any situation that would justify increasing support? I think a large problem of TLS in general and OpenSSL in particular is feature bloat. In the past features got added not because there was a clear need for them, but because we can. After all the whole heartbleed story can largely be explained by that. I'd propose that OpenSSL doesn't add any new features without a clear explanation what advantage they bring in which situation - and who is likely going to use that feature. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1036765 -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpZa5ZbkffsO.pgp Description: OpenPGP digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
May I ask one question: Why? Excellent question. Because there is an RFC is not a good enough reason any more, I think. Does camellia offer any significant advantage in any situation that would justify increasing support? Yes, I'd like to know who needs it. GOST is going to move to an externally-maintained ENGINE (thanks, Dimitry:). We should look at moving other ciphers out of the core the same way. The OID's will need to be maintained, since the run-time really wants to deal with NID's, and figuring out how to make them first-class citizens with an EVP interface would take some thought, but Blowfish, Cast, Camellia, SEED, and Whirlpool could all be pushed out, IMHO. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
On 24/08/2015 10:08, Ben Laurie wrote: On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com mailto:rs...@akamai.com wrote: On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com mailto:rs...@akamai.com wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Are these linked from the website somewhere? No. John Foley @Cisco posted bout them, I think, and Matt has a login and is careful about failures. Seems to me they should be on the website. BTW I tracked it down: http://openssl-sanity.cisco.com:8080/ However, doesn't appear to be up. :-( It's up; link is wrong: https://openssl-sanity.cisco.com:8443/ Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] FW: Website changing this weekend
https://www.openssl.org/docs/fipsvalidation.html (the UserGuide links lead to nowhere, and a few others as well). I fixed the two that I found, thanks. https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/ (which links to https://www.openssl.org/about/releasestrat.html) https://www.openssl.org/blog/blog/2015/01/05/source-code-reformat/ (which links to https://www.openssl.org/about/roadmap.html) etc... Fixed all the ones I found. Thanks! Also, all the pages refer to a favincon.png file but the file is actually called favicon.ico, so the little browser icon is not shown. Given the quality of that ICO, that's probably a feature not a bug :) Anyone want to build a make a better one? Also^2, the links in the top menu are missing a trailing /, this causes a redirect every time they are clicked (this is not exactly broken, but may be worth fixing as well). Yeah, save the load on our server :) fixed. On a related note, can we get the new logo in image format (ideally svg)? So Funny, others asked for a font/css solution. images on https://github.com/openssl and https://www.openhub.net/p/openssl can be replaced with something less ugly (and ideally the favicon on the main site as well). Shrug, whatever people volunteer we'll look at. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
On Sat, Aug 22, 2015 at 12:55:43am +, Salz, Rich wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Does this mean that you are not oging to enable Travis CI? If anything this buildfarm didn't seem to catch the 25efcb44 build failure. Additionally Travis automatically builds pull requests submitted on GitHUb, in order to give immediate feedback to submitter and reviewer. So I think it still makes sense to have Travis alongside this Cisco buildfarm (as you said, the more the merrier), but if you don't agree then both #63 and #373 pull requests can be closed (if anything, two less open PRs...). Cheers signature.asc Description: Digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com wrote: On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Are these linked from the website somewhere? No. John Foley @Cisco posted bout them, I think, and Matt has a login and is careful about failures. Seems to me they should be on the website. BTW I tracked it down: http://openssl-sanity.cisco.com:8080/ However, doesn't appear to be up. :-( I believe it also (at least when working) sends email on failures - would be nice if those went to a list... ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
On Mon, 24 Aug 2015 at 09:53 Alessandro Ghedini alessan...@ghedini.me wrote: On Sat, Aug 22, 2015 at 12:55:43am +, Salz, Rich wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Does this mean that you are not oging to enable Travis CI? If anything this buildfarm didn't seem to catch the 25efcb44 build failure. Additionally Travis automatically builds pull requests submitted on GitHUb, in order to give immediate feedback to submitter and reviewer. So I think it still makes sense to have Travis alongside this Cisco buildfarm (as you said, the more the merrier), but if you don't agree then both #63 and #373 pull requests can be closed (if anything, two less open PRs...). I've just +1'ed #373 - if another OpenSSL dev will also do that, I'll push it... ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
+1 -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz From: Ben Laurie [mailto:b...@links.org] Sent: Monday, August 24, 2015 5:15 AM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Continuous Integration for OpenSSL On Mon, 24 Aug 2015 at 09:53 Alessandro Ghedini alessan...@ghedini.memailto:alessan...@ghedini.me wrote: On Sat, Aug 22, 2015 at 12:55:43am +, Salz, Rich wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Does this mean that you are not oging to enable Travis CI? If anything this buildfarm didn't seem to catch the 25efcb44 build failure. Additionally Travis automatically builds pull requests submitted on GitHUb, in order to give immediate feedback to submitter and reviewer. So I think it still makes sense to have Travis alongside this Cisco buildfarm (as you said, the more the merrier), but if you don't agree then both #63 and #373 pull requests can be closed (if anything, two less open PRs...). I've just +1'ed #373 - if another OpenSSL dev will also do that, I'll push it... ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Monday 24 August 2015 19:25:24 Hanno Böck wrote: On Sat, 22 Aug 2015 10:21:42 + Alessandro Ghedini via RT r...@openssl.org wrote: Which adds support for Camellia GCM and adds the correspondent TLS cipher suites. Most of the code comes from the AES GCM implementation, so maybe there's an opportunity for some refactoring there. May I ask one question: Why? because it's the only standardised, widely audited and recommended alternative to AES, having a different cryptographic construction (Feistel network) that has been studied even longer is also a good thing After all the whole heartbleed story can largely be explained by that. I'd propose that OpenSSL doesn't add any new features without a clear explanation what advantage they bring in which situation - and who is likely going to use that feature. bugs happen, refusing to accept patches just because they can have bugs is short sighted at best or can I expect you to express the exact same concerns when ChaCha20 patches will be proposed? -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Monday 24 August 2015 19:25:24 Hanno Böck wrote: On Sat, 22 Aug 2015 10:21:42 + Alessandro Ghedini via RT r...@openssl.org wrote: Which adds support for Camellia GCM and adds the correspondent TLS cipher suites. Most of the code comes from the AES GCM implementation, so maybe there's an opportunity for some refactoring there. May I ask one question: Why? because it's the only standardised, widely audited and recommended alternative to AES, having a different cryptographic construction (Feistel network) that has been studied even longer is also a good thing After all the whole heartbleed story can largely be explained by that. I'd propose that OpenSSL doesn't add any new features without a clear explanation what advantage they bring in which situation - and who is likely going to use that feature. bugs happen, refusing to accept patches just because they can have bugs is short sighted at best or can I expect you to express the exact same concerns when ChaCha20 patches will be proposed? -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4015] Bug website changelog Changes between 1.0.2c and 1.0.2d [xx XXX xxxx]
Added the right date, thanks. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] FW: Website changing this weekend
From the https://www.openssl.org/docs/manmaster/crypto/crypto.html page - the links to x509v3, asn1, stack and txt_db are broken. Yes, cross-refs within the manpages are still often broke. We're working on that. - it's unclear what INTERNAL FUNCTIONS means. UTILITY is a better word, I'll change that. - The ec link is under internal functions. A more obvious place would be under PUBLIC KEY CRYPTOGRAPHY AND KEY AGREEMENT. Yup, we'll fix. It wold be nice to document the AES API: Moving forward, the EVP API is the only real public interface we want to expose. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Test failure for windows mingw
Hello On the openssl-SNAP-20150824 daily snapshot on Windows Mingw config, I have a build failure : @@@ START test_ec -- private ec testing ec private conversions p - d read EC key writing EC key p - p read EC key writing EC key d - d read EC key unable to load Key 4764:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:149: 4764:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:1116: 4764:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 error:tasn_dec.c:476:Field=parameters, Type=EC_PRIVATEKEY 4764:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC lib:ec_asn1.c:1001: Didier http://www.qualitesys.com/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4019] [PATCH] dgst.pod: Remove redundant documentation of -hmac
Message d'origine De : Markus Rinne via RT r...@openssl.org Date :24/08/2015 17:42 (GMT+01:00) A : Cc : openssl-dev@openssl.org Objet : [openssl-dev] [openssl.org #4019] [PATCH] dgst.pod: Remove redundant documentation of -hmac Option -hmac was documented twice. The issue was reported here: https://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=3930 --- doc/apps/dgst.pod | 5 - 1 file changed, 5 deletions(-) diff --git a/doc/apps/dgst.pod b/doc/apps/dgst.pod index 236e1b7..b156097 100644 --- a/doc/apps/dgst.pod +++ b/doc/apps/dgst.pod @@ -13,7 +13,6 @@ Bopenssl Bdgst [B-hex] [B-binary] [B-r] -[B-hmac arg] [B-non-fips-allow] [B-out filename] [B-sign filename] @@ -64,10 +63,6 @@ output the digest or signature in binary form. output the digest in the coreutils format used by programs like Bsha1sum. -=item B-hmac arg - -set the HMAC key to arg. - =item B-non-fips-allow Allow use of non FIPS digest when in FIPS mode. This has no effect when not in -- 1.8.4 ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ 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
