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

[Richard Moore]

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 with
> bluetooth HW, but this sounds like this is much more common.)
>
>
​http://bluecoat.force.com/knowledgebase/articles/Technical_Alert/32878​
​​
Cheers

Rich.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] License change agreement

[Richard Moore]

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 point that many of the big consumers (like Apache :))
>> are also under Apache2.
>>
>> Least possible breakage and I think it's a reasonable compromise. Of
>> course I am biased because I work for the one of the commercial users.
>>
>
> Zero people that I know of are saying to switch to the GPL.  What is being
> pointed out is that the incompatibility with the current OpenSSL license
> with the GPLv2 has been a major problem.  Switching to the APLv2 does
> nothing to resolve that problem.  As has been noted, the current
> advertising is a huge problem with the existing license.  One of the
> reasons that has been a big problem is that it makes the license
> incompatible with the GPLv2.  So on the one hand, getting rid of that
> clause is great.  On the other hand, getting rid of it by switching to the
> APL is not great, because it doesn't resolve the fundamental problem of
> being incompatible with the GPLv2.
>
> As was noted back when this was brought up in 2015, there are other,
> better, licenses than the APLv2 which are also GPLv2 compatible.  The MPLv2
> being an example of such a license.  There is also BSD, MIT/X11, etc.  The
> GPLv2 incompatibility of OpenSSL is a major problem.


​Indeed, I don't think GPL2 itself would be a good choice.

Cheers

Rich.​
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] License change agreement

[Richard Moore]

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 not solve these serious
> > problems with how OpenSSL was licensed was ignored.  Sad to see that.
>
> No it was not ignored.  (Just because we disagree doesn't mean we ignore
> the feedback.) The team felt that the Apache license better met our needs.
>


​It's a fairly large elephant in the room that the press release does not
address at all though. ​I think it's reasonable to expect some kind of
reasoning.

Cheers

Rich.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Missing API- SSL_CIPHER_get_mac_nid

[Richard Moore]

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 SSL_CIPHER_get_kx_nid(const SSL_CIPHER *c);
__owur int SSL_CIPHER_get_auth_nid(const SSL_CIPHER *c);
__owur int SSL_CIPHER_is_aead(const SSL_CIPHER *c);

which is great, but we seem to be missing an accessor to get the MAC.

Cheers

Rich.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore via RT]

-- 
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);

[Richard Moore via RT]

-- 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: http://rt.openssl.org/Ticket/Display.html?id=4638
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 #4637] Fwd: Missing accessor - DSA key length

[Richard Moore via RT]

-- 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

Rich.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4637
Please log in as guest with password guest if prompted

-- 
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);

[Richard Moore]

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, Rich"  said:
>
> rsalz>
> rsalz> > Shouldn't this be  EC_KEY *EC_KEY_dup(const EC_KEY *src);
> rsalz>
> rsalz> I think the reason it is not is because the EC_KEY has an ENGINE*
> and that can't be const.
>
> The pointer to ENGINE will be const, yes, but not the ENGINE content
> itself, as if it was defined like this:
>
> ENGINE * const engine;
>
> What happens is that the ENGINE pointer is copied to the new
> structure, and the ENGINE itself will work perfectly, both in the
> source EC_KEY and the new one.
>
> So there's no actual reason not to have const there.  It does,
> however, mean that we need to add const in a few more places.  Now
> many at all, actually, it took me 5 minutes.  PR coming tomorrow.
>
> Cheers,
> Richard
>
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> --
> 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] Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);

[Richard Moore]

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

[openssl-dev] Missing accessor - DSA key length

[Richard Moore]

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

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

[Richard Moore]

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? This function used to return "TLSv1" when TLS v1.0 was
> > >> used
> > >> while it is now in Beta 1 returning "TLSv1.0" for that case.
> > >
> > > I missed this change in the review.  Sorry about that.  It should
> > > perhaps be reverted for beta2.  The reported version string for
> > > TLS 1.0 has been "TLSv1" since support for "TLS 1.0" was introduced.
> > > It should likely stay that way.
> >
> > I think it is reasonable to preserve the backwards compatible "TLSv1"
> > for the string protocol version, but do we also need to preserve the
> > "TLSv1.0" in ciphers(1) output?  If so, the code needs an exception
> > that can otherwise be avoided.
>
> I'd say that ciphers(1) is directed more at human users than on
> applications, I don't think changing it there would be a problem.
>

​Well, the same underlying API change would cause breakage in Qt​. As it
happens I've started a new backend that is openssl 1.1 specific that means
it probably won't matter in this case, but I doubt Qt is the only thing
using this string.

Cheers

Rich.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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.org>
> wrote:
>
>>
>> > On Mar 13, 2016, at 10:41 AM, Rainer Jung <rainer.j...@kippdata.de>
>> 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 *pkey);
>>
>> Thanks for the nudge:
>>
>>
>> https://github.com/openssl/openssl/commit/b36a2efd55078a5fff32b2755046b23cb3c5d8a3
>
>
> ​Nice one!
>
> Rich.​
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 *pkey);
>
> Thanks for the nudge:
>
>
> https://github.com/openssl/openssl/commit/b36a2efd55078a5fff32b2755046b23cb3c5d8a3


​Nice one!

Rich.​
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 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.
>>
>
> ASN1_INTEGER *X509_get_serialNumber(X509 *x);
>
> implemented in crypto/x509/x509_cmp.c:
>
> ASN1_INTEGER *X509_get_serialNumber(X509 *a)
> {
> return >cert_info.serialNumber;
> }
>
> https://www.openssl.org/docs/manmaster/crypto/EVP_PKEY_type.html says:
>> "EVP_PKEY_type() returns the type of key corresponding to the value
>> type. The type of a key can be obtained with EVP_PKEY_type(pkey->type)."
>> except it can't
>> because the structure is now opaque.
>>
>
> The docs should be fixed, but there's:
>
> int EVP_PKEY_id(const EVP_PKEY *pkey);
> int EVP_PKEY_base_id(const EVP_PKEY *pkey);
>
> implemented in crypto/evp/p_lib.c:
>
> int EVP_PKEY_id(const EVP_PKEY *pkey)
> {
> return pkey->type;
> }
>
> int EVP_PKEY_base_id(const EVP_PKEY *pkey)
> {
> return EVP_PKEY_type(pkey->type);
> }
>
> HTH
>
> Regards,
>
> Rainer
> --
> 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] API Problems in current master

[Richard Moore]

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.

https://www.openssl.org/docs/manmaster/crypto/EVP_PKEY_type.html says:
"EVP_PKEY_type() returns the type of key corresponding to the value type.
The type of a key can be obtained with EVP_PKEY_type(pkey->type)." except
it can't
because the structure is now opaque.

Cheers

Rich.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 available for further allocation. If ptr is a null pointer,
no action occurs. Otherwise, if the argument does not match a pointer
earlier returned by the calloc , malloc , or realloc function, or if the
space has been deallocated by a call to free or realloc , the behavior is
undefined.

Cheers

Rich.​
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore via RT]

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 available for further allocation. If ptr is a null pointer,
no action occurs. Otherwise, if the argument does not match a pointer
earlier returned by the calloc , malloc , or realloc function, or if the
space has been deallocated by a call to free or realloc , the behavior is
undefined.

Cheers

Rich.​

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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, and is a 128-bit
> strength cipher (kinda).
>
> This is a bit contradictory. According to the OpenSSL cipher
> documentation, HIGH refers to 128-bit, or stronger, ciphers.
>
> Should 3DES ciphers be moved to the MEDIUM category?
>
>
​I tend to agree with moving it to the medium category, but not with the
reasoning. eg. We could have XOR with a 256 bit key and I still wouldn't
want it to be considered as High.

Rich.
​
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 1.1  Either 3DES moves out of HIGH or the
> definition of HIGH as documented in the manpage must change.
>
>
​Personally I think the fact that HIGH includes ciphersuites that offer no
MITM protection means that those who trust it have already been totally
betrayed.

Rich.

​
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 MITM protection means that those who trust it have already been totally
> betrayed.
>
> The correct way to use high-grade ciphers is.
>
> "DEFAULT:!EXPORT:!LOW:!MEDIUM"
>
> The various individual cipherlist building blocks are properly orthogonal,
> and HIGH/MEDIUM/LOW/EXPORT covers only the symmetric algorithm strength.
>
> One can also use it safely via constructs such as "HIGH:!aNULL:!aDSS:!kRSA"
> (if say one also wants to disable DSA and RSA key transport).
>

​Yeah, the apache docs didn't say this for /many/ years and it was rejected
when I reported it as a security problem. The docs had been correct I
believe with some older versions of openssl but the more general point is
that users need a setting that doesn't require expertise, a decoder ring or
a secret handshake. I think we need to reach a point where DEFAULT is the
only sensible option for users without extensive expertise and means to
ensure that they don't make things worse by mistake. HIGH currently is a
dangerous option.

Rich.
​
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 that turn into raw structure access.
>
>
​That would not help anyone who needs function pointers.​


​Rich.
​
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 is to keep the code but have it disabled
> by
> > default.
>
> Note, we're talking about "disabled" as opposed to "not compiled".
> Stuff that's not compiled by default tends to not get tested, and
> breaks silently when it is needed.  That's not terribly useful.
>

​I haven't seen anything that suggests that actually. ​In fact my
assumption is the opposite of yours.



> (Yes, I know about RC5, which is not compiled by default for IPR
> reasons.  Distributions that have never shipped IDEA compiled-in
> can disable it downstream).
>
> This means that absent explicit compile-time directives, the EVP
> interface will not expose the legacy algorithms.  Middleware that
> provides general-purpose crypto interfaces on top of OpenSSL to
> other software will need to enable the legacy algorithms.
>
> I am not convinced that making people jump through the extra hoops
> would be worth the effort on our part and theirs.  Whom would we
> be helping?
>

​Again, since the old middleware would need to change​ either way, I don't
see why the baggage should be brought along.


> The simplest thing to do is to make legacy libcrypto code maximally
> maintainable, and if removing assembly support does that, than we
> do that.  Beyond that, do nothing.  What algorithms people use on
> their own data is their choice and risk decision not ours.
>
>
​The simplest thing depends on your point of view. The simplest thing if
you only care about openssl is to remove it, however the simplest thing if
you only care about an end product that depends on some weird feature is to
change nothing. You can't just make an absolute statement, as usual there
are trade-offs and work for different people. ​

​Cheers

Rich.​
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 stricter over time, so
> old code will general need changes to work with newer compilers (even when
> you're only talking over a relatively short period such as 5 years). Now if
> this code were included in openssl but disabled by default then these
> problems would exist but simply be hidden until someone tried to use it.
> Given the user would then have to fix them (since no one else cares about
> their favourite dead algorithm) I don't really see what advantage having
> the code in the main tree offers.
>
>
> I did not say “no maintenance costs”. I said that I concur that the
> maintenance costs for such code would be *minimal*, which usually it is.
>
> I’m against “disabling by default”. Removing access to such code from
> libssl is OK, and the correct thing to do from the security point of view.
> Removing from libcrypto is bad, and enough people here explained why well
> enough to avoid repeating the reasons.
>

​Yes, but a several people (including me) disagree with you. And one of the
options that has been suggested is to keep the code but have it disabled by
default.

Rich.
​
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 while it was still considered secure and that are still
> relevant today, just 15 years later.
>
>
​This doesn't explain why the code needs to exist in future versions of
openssl. The previous ones aren't going to vanish and can be compiled and
used to rescue data in theoretical edge cases like this. You're making it
sound like this is making the data totally inaccessible which is not the
case.

Cheers

Rich.​
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] On release pre announcements

[Richard Moore]

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 to get the descriptions (usually a
day or two after an advisory is released) that might not be a problem. It
would make it easier to search bug trackers etc. though. If we just had the
CVSS base vector then there'd be no real risk but people could make more
informed decisions.

Cheers

Rich.
​
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] On release pre announcements

[Richard Moore]

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 give a clear idea of this, or even a full CVSS base vector.

Rich.
​
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Missing API features

[Richard Moore]

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 this stuff out internally but there is no exposed API to do this.

 Enough for an application to write its own version of
 SSL_CIPHER_description
 for example.


Yes, that would be ideal.

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Missing API features

[Richard Moore]

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 the case of Qt both of those would work - the API we provide looks like
this: http://doc.qt.io/qt-5/qsslcipher.html
The basic idea is to provide the information to people using the API so
that they can use it when describing the cipher to users. To be honest, I'm
not sure how much of this users will actually understand in practice, but
that's a different problem.

Cheers

Rich.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Missing API features

[Richard Moore]

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 string to obtain this information seems daft. We're
 missing API for: key exchange, authentication method, encryption
 algorithm, MAC and the export flag.

 (Man, outlook makes it hard to NOT top-post.  Sigh.)

 Since all of those are implied by the cipher spec, could we just have an
 API to return the two-byte cipher identifier?  (That would break if TLS 1.3
 moves to a la carte selection, but I doubt that will happen.)  Export is
 gone :)  And what's the MAC if using an AEAD cipher like AES-GCM?


Just returning the cipher id would mean every app needs to replicate the
table that openssl already has, and keep it updated. Doesn't seem like a
good plan to me. According to the current code in openssl the 'MAC' when
using AES-GCM is AEAD - not ideal perhaps, but what we've got.



  It's also worth noting that SSL_CIPHER_get_version and
 SSL_CIPHER_description should probably be returning const char * not char *.

 Yes, is that a bug to backport or just fix in master, you think?


Changing the return type here should be binary compatible on any sane
platform, but it might cause source incompatibilities.

Cheers

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Missing API features

[Richard Moore]

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 API for:
key exchange, authentication method, encryption algorithm, MAC and the
export flag. It's also worth noting that SSL_CIPHER_get_version and
SSL_CIPHER_description
should probably be returning const char * not char *.

Cheers

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, the
 libexplain maintainer has retired and the package is orphaned. This is
 potentially represents an issue as libexplain is highly embedded in tardy.


This sounds purely a packaging issue with debian and nothing to do with
openssl itself.

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore via RT]

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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, the
 libexplain maintainer has retired and the package is orphaned. This is
 potentially represents an issue as libexplain is highly embedded in tardy.


This sounds purely a packaging issue with debian and nothing to do with
openssl itself.

Rich.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 of this minor report,
   however..
  
   Openssl distribution depends on tardy, which in turn, depends on
   libexplain.
   According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335,
   the libexplain maintainer has retired and the package is orphaned.
   This is potentially represents an issue as libexplain is highly
 embedded in
  tardy.
  
 
  This sounds purely a packaging issue with debian and nothing to do with
  openssl itself.

 Tardy is referenced in the openssl Makefile tar rule, which is there the
 dependency manifests.

 $(TAR) $(TARFLAGS) --files-from ../$(TARFILE).list -cvf - | \
 tardy --user_number=0  --user_name=openssl \
   --group_number=0 --group_name=openssl \
   --prefix=openssl-$(VERSION) - |\
 gzip --best ../$(TARFILE).gz; \


Surely you build your packages from the release tar balls? That means that
this rule is never used.

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore via RT]

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 of this minor report,
   however..
  
   Openssl distribution depends on tardy, which in turn, depends on
   libexplain.
   According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335,
   the libexplain maintainer has retired and the package is orphaned.
   This is potentially represents an issue as libexplain is highly
 embedded in
  tardy.
  
 
  This sounds purely a packaging issue with debian and nothing to do with
  openssl itself.

 Tardy is referenced in the openssl Makefile tar rule, which is there the
 dependency manifests.

 $(TAR) $(TARFLAGS) --files-from ../$(TARFILE).list -cvf - | \
 tardy --user_number=0  --user_name=openssl \
   --group_number=0 --group_name=openssl \
   --prefix=openssl-$(VERSION) - |\
 gzip --best ../$(TARFILE).gz; \


Surely you build your packages from the release tar balls? That means that
this rule is never used.

Rich.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 should cover the above gap:

 int SSL_SESSION_has_ticket(const SSL_SESSION *s);
 unsigned long SSL_SESSION_get_ticket_lifetime_hint(const SSL_SESSION *s);
 void SSL_SESSION_get0_ticket(const SSL_SESSION *s, unsigned char **tick,
  size_t *len);


Great - I'll port the code to use those when building against 1.1 then with
the fixes I've already made Qt dev branch should build fine against the
current master. I've also updated the wiki to note what got broken in curl
and wget BTW (only one breakage in each AFAIK).

Cheers

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 inconvenience people as some applications
 no longer build.  We want to work with maintainers to help them
 migrate, as we head down this path.

 We have a wiki page to discuss this effort.  It will eventually include
 tips on migration, application and code updates, and anything else the
 community finds useful.  Please visit:

 http://wiki.openssl.org/index.php/1.1_API_Changes


I've documented what got broken in Qt by the changes so far. I've listed
the functions I think we can use instead where they exist, and those where
there does not appear to be a replacement.

Cheers

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 inconvenience people as some applications
 no longer build.  We want to work with maintainers to help them
 migrate, as we head down this path.

 We have a wiki page to discuss this effort.  It will eventually include
 tips on migration, application and code updates, and anything else the
 community finds useful.  Please visit:

 http://wiki.openssl.org/index.php/1.1_API_Changes


I've documented what got broken in Qt by the changes so far. I've listed
the functions I think we can use instead where they exist, and those where
there does not appear to be a replacement.

Cheers

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 something like:
CONF_modules_load_file(NULL, NULL,
CONF_MFLAGS_IGNORE_ERRORS|CONF_MFLAGS_SILENT|CONF_MFLAGS_IGNORE_MISSING_FILE)

If we want roughly equivalent behaviour?

Cheers

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 something like:
CONF_modules_load_file(NULL, NULL,
CONF_MFLAGS_IGNORE_ERRORS|CONF_MFLAGS_SILENT|CONF_MFLAGS_IGNORE_MISSING_FILE)

If we want roughly equivalent behaviour?

Cheers

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore via RT]

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 something like:
CONF_modules_load_file(NULL, NULL,
CONF_MFLAGS_IGNORE_ERRORS|CONF_MFLAGS_SILENT|CONF_MFLAGS_IGNORE_MISSING_FILE)

If we want roughly equivalent behaviour?

Cheers

Rich.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 with OPENSSL_NO_SSL_INTERN defined since there are fields used for
NPN that we need (iirc).

Cheers

Rich.


On 23 January 2015 at 19:11, Salz, Rich rs...@akamai.com wrote:

  Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options
 and we are considering removing nearly a third of them.  Please reply soon
 if the following plan would cause problems. This will happen only in
 master, for post-1.0.2.

  We will remove the following options.  You could argue that the
 OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not
 compile without SHA and SHA1 defined, and we have no interest in spending
 the time to fix it. So for consistency, we will remove all of them.

 GENUINE_DSA (and the broken DSS0 since SHA0 will be removed)

 OPENSSL_NO_BIO

 OPENSSL_NO_BUFFER

 OPENSSL_NO_BUF_FREELISTS

 OPENSSL_NO_CHAIN_VERIFY

 OPENSSL_NO_DESCBCM (also removing the code; no EVP support)

 OPENSSL_NO_EVP

 OPENSSL_NO_FIPS_ERR

 OPENSSL_NO_HASH_COMP

 OPENSSL_NO_LHASH

 OPENSSL_NO_LOCKING

 OPENSSL_NO_MULTIBYTE (also removing the code)

 OPENSSL_NO_OBJECT

 OPENSSL_NO_RFC3779

 OPENSSL_NO_SHA

 OPENSSL_NO_SHA0 (also removing the code for SHA0)

 OPENSSL_NO_SHA1

 OPENSSL_NO_SHA224

 OPENSSL_NO_SHA256

 OPENSSL_NO_SHA384

 OPENSSL_NO_SHA512

 OPENSSL_NO_SPEED

 OPENSSL_NO_SSL_INTERN (first attempt at making things opaque)

 OPENSSL_NO_STACK

 OPENSSL_NO_STORE

 OPENSSL_NO_TLS

 OPENSSL_NO_TLS1

 OPENSSL_NO_TLS1_2_CLIENT

 OPENSSL_NO_TLSEXT

 OPENSSL_NO_X509

 OPENSSL_NO_X509_VERIFY





 --

 Principal Security Engineer, Akamai Technologies

 IM: rs...@jabber.me Twitter: RichSalz



 ___
 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

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

[Richard Moore]

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 errors and warnings.

 Right, it's not useful.  We're looking at cleaning up a whole bunch of
 OPENSSL_NO_xxx options that don't really work.  Details to come.


If you're going to change this, then perhaps at the same time as changing
the API these could be inverted so we have defines that say what /is/
enabled since that's probably a better design overall.

Rich.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore via RT]

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, NEWEST and VULNERABLE.
  |
  |In Qt we've added an enum value for TLS versions that is SecureProtocols
 so
  |that we could remove versions as required without requiring apps to be
  |updated. It's an open question which is more likely to get updated - Qt
 or
  |the apps of course. For Qt 5.4 which is due out this week we've removed
  |SSL3 from this enum so apps will silently get updated to drop support for
  |it.

 I see.  And i think this is the most impressive or, lesser
 enthusiastic, important feature of the slow _CONF_ interface: that
 users can use strings and that those are directly swallowed by the
 OpenSSL library, so that neither recompilation nor understanding
 is necessary on the program side in order to upgrade to a new
 level of security.


The API we offer in Qt isn't tied to openssl so we can't do that. We also
support a Windows RT backend and a SecureTransport backend is under
development too.



 (As a side note: SecureProtocols is such a Volvo wording...
 Doesn't vulnerable energises a deeper feeling of insecurity?
 I think Hitchcock would have used the naked and bare vulnerable.)


That's partly due to the API naming conventions for enums. :-)

Rich.

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] More POODLE issues

[Richard Moore]

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.
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

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

[Richard Moore]

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
 closer OpenSSL can come to that ideal, the more likely its users will
 have reasonably strong crypto without having to learn the dirty dirty
 details and history of TLS and its predecessors.


My experience suggests that while that might be what some developers want,
that's not what users want. They expect that if it works in the browser it
should work everywhere - even when the browser is jumping through hoops
like fetching missing intermediate certificates, downgrading security etc.
If the world were perfect and the browsers didn't do this then life would
be a lot easier.

Cheers

Rich.
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

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

[Richard Moore via RT]

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
 closer OpenSSL can come to that ideal, the more likely its users will
 have reasonably strong crypto without having to learn the dirty dirty
 details and history of TLS and its predecessors.


My experience suggests that while that might be what some developers want,
that's not what users want. They expect that if it works in the browser it
should work everywhere - even when the browser is jumping through hoops
like fetching missing intermediate certificates, downgrading security etc.
If the world were perfect and the browsers didn't do this then life would
be a lot easier.

Cheers

Rich.

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

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

[Richard Moore]

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, NEWEST and VULNERABLE.
  |
  |In Qt we've added an enum value for TLS versions that is SecureProtocols
 so
  |that we could remove versions as required without requiring apps to be
  |updated. It's an open question which is more likely to get updated - Qt
 or
  |the apps of course. For Qt 5.4 which is due out this week we've removed
  |SSL3 from this enum so apps will silently get updated to drop support for
  |it.

 I see.  And i think this is the most impressive or, lesser
 enthusiastic, important feature of the slow _CONF_ interface: that
 users can use strings and that those are directly swallowed by the
 OpenSSL library, so that neither recompilation nor understanding
 is necessary on the program side in order to upgrade to a new
 level of security.


The API we offer in Qt isn't tied to openssl so we can't do that. We also
support a Windows RT backend and a SecureTransport backend is under
development too.



 (As a side note: SecureProtocols is such a Volvo wording...
 Doesn't vulnerable energises a deeper feeling of insecurity?
 I think Hitchcock would have used the naked and bare vulnerable.)


That's partly due to the API naming conventions for enums. :-)

Rich.
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

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

[Richard Moore via RT]

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 versions as required without requiring apps to be
updated. It's an open question which is more likely to get updated - Qt or
the apps of course. For Qt 5.4 which is due out this week we've removed
SSL3 from this enum so apps will silently get updated to drop support for
it.

Cheers

Rich.

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

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

[Richard Moore]

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 TLS1.0 servers are extension intolerant, it is necessary to
 not advertise any extensions to be able to connect to them.

 This patch implements command line options as well as SSL_CONF_cmd()
 options to disable sending TLS extensions completely

 https://github.com/openssl/openssl/pull/198

 --
 Regards,
 Hubert Kario

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

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

[Richard Moore]

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 issue, old release, closing ticket.
 --
 Rich Salz, OpenSSL dev team; rs...@openssl.org

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

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

[Richard Moore]

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 port of gcc for DOS and I can't imagine anyone actively using
it these days, so I'd suggest you can close those ones straight away. Mingw
on the otherhand is widely used, but since it's updated on a regular basis
I'd say it would be safe to close bugs on old versions of openssl.

Rich.

Re: Makedepend bug?

[Richard Moore]

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 this scene, so I don't aim to
 offend anyone, but it's an honest, if naive question.


nmake is the make generally used by windows developers. There are also more
modern tools like cmake that will generate the build files for a wide range
of systems.

Rich.

Re: Minor fixes to openssl ocsp

[Richard Moore]

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 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:
 
  https://github.com/openssl/openssl/pulls/richmoore

 Both look good. Could you also add description of -header to man page?


 I think that's a good idea, but I'd rather do it as a commit that resolved
 that by syncing up the man page properly. I've not checked the code but I
 doubt that -header is the only undocumented option. If fixing the man page
 is a requirement to get this merged is a requirement then yes, I'll do it,
 but I'd rather minimise the amount of times I have to mess around with pod
 files.


 I know that the man pages are missing description of many options. The
 point is that at least we can keep them from getting worse.
 Then the occasional additional fix will be able to bring them closer to
 the 100% documented, not bring them back to the 90% documented.


Perhaps I wasn't clear. I'm saying that once these have gone through, *I*
will spend the time to make sure the ocsp man page covers 100% of the
available options as a follow up commit.

Rich.

Minor fixes to openssl ocsp

[Richard Moore]

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

[Richard Moore]

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:
 
  https://github.com/openssl/openssl/pulls/richmoore

 Both look good. Could you also add description of -header to man page?


I think that's a good idea, but I'd rather do it as a commit that resolved
that by syncing up the man page properly. I've not checked the code but I
doubt that -header is the only undocumented option. If fixing the man page
is a requirement to get this merged is a requirement then yes, I'll do it,
but I'd rather minimise the amount of times I have to mess around with pod
files.

Cheers

Rich.

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

[Richard Moore]

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 see happen for a long time
  too.  Together we removing some APIs.  I also want to help getting
  open source packages fixed so they still work.
 

 That's something I'd like to see too. I've added some support for libssl in
 OpenSSL 1.0.1 (you can make all libssl structures opaque by setting
 OPENSSL_NO_SSL_INTERN). I'd like to see the same happen across libcrypto
 but
 it's a significant task and likely to cause considerable application
 breakage.


I tried using this flag with Qt a few weeks back and noticed that some
stuff such as the tlsext_tick_lifetime_hint didn't seem to have accessors.
At the moment, I don't think it's very clear to people using openssl which
structures are intended to be internal and which aren't too.

Cheers

Rich.