Re: Which platforms will be supported in the future on which platforms will be removed?

On 1 June 2014 19:38, Dr. Stephen Henson st...@openssl.org wrote: On Sun, Jun 01, 2014 at 01:39:54PM -0400, Salz, Rich wrote: Make structures opaque when possible and provide accessor functions. Within openssl itself use macros if you want. This has been on my list of things I want to

Minor fixes to openssl ocsp

Hi, I put a couple of fixes as pull requests into github, but haven't seen any movement (eg. reviews). In case it's simply because no one noticed here's a link: https://github.com/openssl/openssl/pulls/richmoore Both are pretty trivial fixes (not security fixes). Cheers Rich.

Re: Minor fixes to openssl ocsp

On 12 June 2014 17:34, Hubert Kario hka...@redhat.com wrote: - Original Message - I put a couple of fixes as pull requests into github, but haven't seen any movement (eg. reviews). In case it's simply because no one noticed here's a link:

Re: Minor fixes to openssl ocsp

On 13 June 2014 11:12, Hubert Kario hka...@redhat.com wrote: -- *From: *Richard Moore richmoor...@gmail.com *To: *openssl-dev@openssl.org *Sent: *Thursday, June 12, 2014 11:13:09 PM *Subject: *Re: Minor fixes to openssl ocsp On 12 June 2014 17:34, Hubert Kario

Re: Do *you* know about Mingw and/or DJGPP?

On 1 July 2014 04:24, Salz, Rich rs...@akamai.com wrote: There are several tickets about mingw and djgpp builds breaking, or building software that crashes, and so on. If you can help me understand the current state of things with those toolchains, please drop me a line. DJGPP was a

Re: Makedepend bug?

On 1 July 2014 22:09, Mike Bland mbl...@acm.org wrote: Yeah, the portability angle is why I'm trying to move forward carefully. That said, isn't GNU Make everywhere these days? Couldn't we eliminate a lot of complexity by relying on its include syntax (and other treats)? I'm still a n00b on

Re: [openssl.org #2814] Bug Report: Cannot compile OpenSSL 1.0.1c with EC

At least some versions of Redhat have patched openssl to disable EC support due to patent concerns. Could explain the problem with using the EC functions. Rich. On 8 September 2014 23:19, Rich Salz via RT r...@openssl.org wrote: Don't know what the Fedora 18 patches are. Cannot reproduce the

Re: [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions

That would introduce security issues such as the TLS renegotiation flaw. Surely a better solution is to make servers that pretend to support TLS but actually only support SSL3 die a horrible death? Rich. On 30 November 2014 at 20:18, Hubert Kario via RT r...@openssl.org wrote: since some

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST

Re: [openssl-dev] More POODLE issues

Purely to give an independent answer - I'm not one of the openssl developers and I've tested this. As expected the ssl3 implementation allows any padding but the invalid padding is rejected with an alert when using TLS. So as Matt has said, it's not a problem for openssl. Cheers Rich.

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

On 10 December 2014 at 19:26, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The

Re: [openssl-dev] The evolution of the 'master' branch

On 3 February 2015 at 22:02, Rich Salz rs...@openssl.org wrote: As we've already said, we are moving to making most OpenSSL data structures opaque. We deliberately used a non-specific term. :) As of Matt's commit of the other day, this is starting to happen now. We know this will

Re: [openssl-dev] The evolution of the 'master' branch

On 10 February 2015 at 23:01, Matt Caswell m...@openssl.org wrote: On the wiki you wrote: session-tlsext_tick_lifetime_hint - we were directly accessing the lifetime hint of the session. I have just pushed (along with some associated documentation) some new ticket API functions, which

Re: [openssl-dev] [openssl.org #3488] OPENSSL_config shouldn't exit()

On 26 January 2015 at 02:53, Rich Salz via RT r...@openssl.org wrote: After discussion, we decided to make the existing function REALLY ignore errors and not print anything and not exit. But it's still deprecated and don't use it :) That's great Rich. So, to be clear, we should be using

Re: [openssl-dev] OPENSSL_NO_SHA is still useful?

On 20 January 2015 at 21:44, Salz, Rich rs...@akamai.com wrote: you think is still necessary to leave in the code #ifndef OPENSSL_NO_SHA and #ifdef OPENSSL_NO_SHA are so many function calls EVP_sha1() (and other similar) that compiling with -DOPENSSL_NO_SHA gives an endless series of

Re: [openssl-dev] Seeking feedback on some #ifdef changes

The only one of all those that matters (to me) is OPENSSL_NO_SSL_INTERN since that provides a way to anticipate the effects of this API change. I'm fine with it going, but it needs a specified replacement (even if the replacement is we'll do that by default). Currently for example Qt won't build

Re: [openssl-dev] [openssl.org #3488] OPENSSL_config shouldn't exit()

On 26 January 2015 at 02:53, Rich Salz via RT r...@openssl.org wrote: After discussion, we decided to make the existing function REALLY ignore errors and not print anything and not exit. But it's still deprecated and don't use it :) That's great Rich. So, to be clear, we should be using

Re: [openssl-dev] The evolution of the 'master' branch

On 3 February 2015 at 22:02, Rich Salz rs...@openssl.org wrote: As we've already said, we are moving to making most OpenSSL data structures opaque. We deliberately used a non-specific term. :) As of Matt's commit of the other day, this is starting to happen now. We know this will

Re: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor)

On 7 March 2015 at 17:14, Randall S. Becker via RT r...@openssl.org wrote: Please forgive the potential red-herring nature of this minor report, however.. Openssl distribution depends on tardy, which in turn, depends on libexplain. According to

Re: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor)

On 7 March 2015 at 18:11, Randall S. Becker via RT r...@openssl.org wrote: On March 7, 2015 1:02 PM Richard Moore via RT [mailto:r...@openssl.org] wrote: On 7 March 2015 at 17:14, Randall S. Becker via RT r...@openssl.org wrote: Please forgive the potential red-herring nature

Re: [openssl-dev] Missing API features

On 20 April 2015 at 21:25, Salz, Rich rs...@akamai.com wrote: What is the information you're looking for? kx=X25519 or kx=2KRSA or ... ? I picked those because sometimes there's a keysize, and other times it's implicit, for example. The internal table is going to need restructuring. In

Re: [openssl-dev] Missing API features

On 20 April 2015 at 15:33, Salz, Rich rs...@akamai.com wrote: Continuing with the problems of making structs opaque, currently the API for querying the information about ciphers is quite weak. Only SSL_CIPHER_description provides access to data such as the key exchange method, and parsing a

Re: [openssl-dev] Missing API features

On 21 April 2015 at 12:50, Dr. Stephen Henson st...@openssl.org wrote: I think what would be useful here would be an API that can determine appropriate characterictics of an SSL_CIPHER. For example a NID corresponding to the key exchange algorithm, signer, cipher and MAC. We have to find

[openssl-dev] Missing API features

Hi All, Continuing with the problems of making structs opaque, currently the API for querying the information about ciphers is quite weak. Only SSL_CIPHER_description provides access to data such as the key exchange method, and parsing a string to obtain this information seems daft. We're missing

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 16 November 2015 at 19:05, Hubert Kario wrote: > Example: CAdES V1.2.2 was published in late 2000, the first serious > attacks on MD2 were not published until 2004. I think it is not > unreasonable for CAdES-A documents to exist today which were originally > signed with MD2

Re: [openssl-dev] On release pre announcements

On 8 July 2015 at 11:34, Hanno Böck ha...@hboeck.de wrote: So may I propose another category that includes only data exfiltration, remote code execution or severe crypto breaks on reasonable default configurations? ​What would be nice would be to have the CVSS Impact scores​ ​that would

Re: [openssl-dev] On release pre announcements

On 9 July 2015 at 12:21, Salz, Rich rs...@akamai.com wrote: it would also be nice to have a bug-ID/CVE to track and organize the upgrades. The concern is that people would then start trying to find the CVE descriptions which aren't available yet. ​Given that NVD is generally quite slow

Re: [openssl-dev] Backporting opaque struct getter/setter functions

On 9 January 2016 at 22:45, Salz, Rich wrote: > > > required to perform many operations. What do people think about > > backporting those accessors into the 1.0.2 branch? > > Another possibility is to have a just a single (new) header file that has > #define's for the accessors

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 19 November 2015 at 19:28, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > On Thu, Nov 19, 2015 at 05:07:38PM +, Richard Moore wrote: > > >​Yes, but a several people (including me) disagree with you. And one of > the > > options that has been suggested i

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 19 November 2015 at 16:56, Blumenthal, Uri - 0553 - MITLL wrote: > ​Heh. I actually tested building all releases of openssl after 0.9.7 a few > months back - several refuse to build with the default options on 64 bit. > In addition my experience shows that compilers get

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

On 12 February 2016 at 18:59, Short, Todd wrote: > Hi, > > In OpenSSL 1.0.2, and 1.0.1i, 3DES-CBC’s bit-strength was changed from 168 > to 112, which makes sense. However, it is still considered a HIGH-strength > cipher. > > RC4 is listed as having a bit strength of MEDIUM,

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

On 12 February 2016 at 21:29, Salz, Rich wrote: > > > Well, it would be a major compatibility break for 1.0.2 and earlier, so > no go > > there. As for 1.1.0, folks > > Or those who trust us to say what HIGH means should, well, not be lied to. > > Something must be changed for

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

On 13 February 2016 at 00:16, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > > > On Feb 12, 2016, at 6:55 PM, Richard Moore <richmoor...@gmail.com> > wrote: > > > > ​Personally I think the fact that HIGH includes ciphersuites that offer > no MIT

Re: [openssl-dev] OpenSSL 1.1.0-pre4 change in SSL_get_version() return value

On 18 March 2016 at 16:20, Hubert Kario wrote: > On Wednesday 16 March 2016 20:40:42 Viktor Dukhovni wrote: > > > On Mar 16, 2016, at 6:44 PM, Viktor Dukhovni us...@dukhovni.org> wrote: > > >> Was the SSL_get_version() behavior changed on purpose in the Beta 1 > > >> release?

Re: [openssl-dev] API Problems in current master

By the way, the serial number accessors are missing from the docs too or is that just a problem with the website? Cheers Rich. On 13 March 2016 at 22:30, Richard Moore <richmoor...@gmail.com> wrote: > On 13 March 2016 at 21:34, Viktor Dukhovni <openssl-us...@dukhovni.

[openssl-dev] API Problems in current master

I'm currently testing the new release by trying to port Qt to use it (with the compatibility stuff disabled). Here are the first problems I've hit: How do we get the certificate serial number? We were doing x509->cert_info->serialNumber to get it as an ASN1_INTEGER.

Re: [openssl-dev] API Problems in current master

That's great, thanks Rainer. I'll give those a try. Rich. On 13 March 2016 at 14:41, Rainer Jung <rainer.j...@kippdata.de> wrote: > Am 13.03.2016 um 14:34 schrieb Richard Moore: > >> I'm currently testing the new release by trying to port Qt to use it >> (with the comp

Re: [openssl-dev] API Problems in current master

On 13 March 2016 at 21:34, Viktor Dukhovni wrote: > > > On Mar 13, 2016, at 10:41 AM, Rainer Jung > wrote: > > > > The docs should be fixed, but there's: > > > > int EVP_PKEY_id(const EVP_PKEY *pkey); > > int EVP_PKEY_base_id(const EVP_PKEY

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

On 9 March 2016 at 05:30, Peter Waltenberg wrote: > No, you got that right, NULL being 'safe' to free varies with OS. > > ​It shouldn't if you're programming in C, from the standard (C89): The free function causes the space pointed to by ptr to be deallocated, that is, made

[openssl-dev] Missing accessor - DSA key length

For RSA we have RSA_bits(), for DH we have DH_bits() for DSA we seem to only have DSA_size(). Cheers Rich. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);

Shouldn't this be EC_KEY *EC_KEY_dup(const EC_KEY *src); Cheers Rich. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);

I meant to ask, should I make tickets for this and the missing DSA_bits()? Cheers Rich. On 24 July 2016 at 21:05, Richard Levitte wrote: > In message < > a62628880fea43fa8505f895c22f0...@usma1ex-dag1mb1.msg.corp.akamai.com> on > Sun, 24 Jul 2016 17:19:05 +, "Salz,

[openssl-dev] Missing API- SSL_CIPHER_get_mac_nid

I noticed that we have: __owur int SSL_CIPHER_get_bits(const SSL_CIPHER *c, int *alg_bits); __owur const char *SSL_CIPHER_get_version(const SSL_CIPHER *c); __owur const char *SSL_CIPHER_get_name(const SSL_CIPHER *c); __owur uint32_t SSL_CIPHER_get_id(const SSL_CIPHER *c); __owur int

Re: [openssl-dev] License change agreement

On 23 March 2017 at 18:04, Salz, Rich via openssl-dev < openssl-dev@openssl.org> wrote: > > The new license also conflicts with the GPLv2. This was immediately > brought > > up as a serious problem when this discussion began in July of 2015. It > > appears that the feedback that the APL does

Re: [openssl-dev] License change agreement

On 24 March 2017 at 02:26, Quanah Gibson-Mount wrote: > --On Friday, March 24, 2017 1:37 AM + Peter Waltenberg < > pwal...@au1.ibm.com> wrote: > > >> OpenSSL has a LOT of commercial users and contributors. Apache2 they can >> live with, GPL not so much. >> There's also the

Re: [openssl-dev] Can I haz TLS 1.3 ?

On 3 October 2017 at 20:45, Hanno Böck wrote: > On Tue, 3 Oct 2017 17:36:03 + > "Salz, Rich via openssl-dev" wrote: > > So I heard chatter about this, but not much details. Which I find > unfortunate and a bit disturbing. (I'm aware of a single case

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: and finally i propose three new values for the Protocol slot of SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. In Qt we've added an enum value for TLS versions that is SecureProtocols so that we could remove

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

On 10 December 2014 at 19:26, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The

Re: [openssl-dev] [openssl.org #3488] OPENSSL_config shouldn't exit()

On 26 January 2015 at 02:53, Rich Salz via RT r...@openssl.org wrote: After discussion, we decided to make the existing function REALLY ignore errors and not print anything and not exit. But it's still deprecated and don't use it :) That's great Rich. So, to be clear, we should be using

Re: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor)

On 7 March 2015 at 17:14, Randall S. Becker via RT r...@openssl.org wrote: Please forgive the potential red-herring nature of this minor report, however.. Openssl distribution depends on tardy, which in turn, depends on libexplain. According to

Re: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor)

On 7 March 2015 at 18:11, Randall S. Becker via RT r...@openssl.org wrote: On March 7, 2015 1:02 PM Richard Moore via RT [mailto:r...@openssl.org] wrote: On 7 March 2015 at 17:14, Randall S. Becker via RT r...@openssl.org wrote: Please forgive the potential red-herring nature

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

On 9 March 2016 at 05:30, Peter Waltenberg wrote: > No, you got that right, NULL being 'safe' to free varies with OS. > > ​It shouldn't if you're programming in C, from the standard (C89): The free function causes the space pointed to by ptr to be deallocated, that is, made

[openssl-dev] [openssl.org #4639] Missing const and docs X509_get_notBefore, X509_get_notAfter

-- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4639 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4638] Fwd: Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);

-- Forwarded message -- From: Richard Moore <richmoor...@gmail.com> Date: 24 July 2016 at 17:38 Subject: Missing const EC_KEY *EC_KEY_dup(EC_KEY *src); To: openssl-dev@openssl.org Shouldn't this be EC_KEY *EC_KEY_dup(const EC_KEY *src); Cheers Rich. -- Ticket here

[openssl-dev] [openssl.org #4637] Fwd: Missing accessor - DSA key length

-- Forwarded message -- From: Richard Moore <richmoor...@gmail.com> Date: 24 July 2016 at 17:31 Subject: Missing accessor - DSA key length To: openssl-dev@openssl.org For RSA we have RSA_bits(), for DH we have DH_bits() for DSA we seem to only have DSA_size(). Cheers