Thanks for the guidance. My PR was only for the two OIDs I noticed. There are
about an hundred other entries without OIDs, some just don't have anything
assigned but others might. It sounds, from Richard's comment, that there is no
need to chase these down but that they should be added
> On Mar 15, 2018, at 8:12 AM, Salz, Rich wrote:
I am also concerned about the performance implications of applying
the system settings at every SSL_CTX_new() (if that's the mechanism).
How does this interact with the
in a few hours I will merge pull request
#5462 - Publish the RAND_DRBG API
This pull request removes 14 public symbols (symbols RAND_POOL_*,
numbers 4351 - 4364) and closes the gap by renumbering all following
symbols. Anyone of you who as added new symbols to libcrypto.num in his
The crux of the issue is that this would change SSL_CTX to apply system
defaults when the object is created. In conjunction with the system config file
include stuff, this makes it easy to change the behavior of all applications
running on a system.
On 14/03/18 23:40, Paul Dale wrote:
>> We should have OID's for the things we implement
> Sounds like a policy :)
> Vote time?
In the past we've also put in OIDs on request (i.e. not necessarily for
something we implement) if someone has given a reasonable argument for
In message <20180315.090502.2143972695067215526.levi...@openssl.org> on Thu, 15
Mar 2018 09:05:02 +0100 (CET), Richard Levitte said:
levitte> So can I assume there's a PR coming up?
Ah, saw it!
Richard Levitte levi...@openssl.org
In message <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b@default> on Wed, 14 Mar 2018
16:40:24 -0700 (PDT), Paul Dale said:
paul.dale> > We should have OID's for the things we implement
paul.dale> Sounds like a policy :)
paul.dale> Vote time?
Not sure if there's a