Re: [openssl-dev] [openssl-master 0/1] AFALG: Support AES GCM

[Salz, Rich via openssl-dev]

Please open a GitHub PR; posts to the mailing list won’t make it in.
BTW, the “iov” struct isn’t portable.



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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Salz, Rich via openssl-dev]

  *   The current patch ( PR 5164 ) just changes "can be safely used" to "can 
generally be used safely". Without enough information for a user of the library 
to know whether a given usage is safe, this isn't useful documentation. When it 
comes to threading, "generally safe" is the same as "unsafe". There needs to be 
at least a little bit of guidance.

Pedantically and strictly speaking, you might be correct.  Pragmatically, 
however, many people have been able to write or deploy multi-threaded servers.

I doubt that anyone on the project will do anything approaching a definitive 
thread-safety analysis, let alone documentation.  Even with the “small number 
of API’s” that might be affected.


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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Salz, Rich via openssl-dev]

  *   Well, the most likely fix is to make the “safely” wording be more vague, 
which I doubt you’ll like.  But I doubt anyone on the team has much interest in 
fixing 1.0.2 locking issues.



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


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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Salz, Rich via openssl-dev]

  *   OpenSSL should provide API to retrieve extension by OID.

Yes!  Can you open a github issue for that?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Salz, Rich via openssl-dev]

Create the OID at your program startup and store the NID in a global variable.

From: Yun Jiang <yun.ji...@realvnc.com>
Reply-To: openssl-dev <openssl-dev@openssl.org>
Date: Wednesday, January 24, 2018 at 7:38 AM
To: openssl-dev <openssl-dev@openssl.org>
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

Thanks!

The problem is that I need to get a customized certificate extension based on 
an OID. Until now, I cannot find a solution without dynamically calling 
OBJ_create(OID, NULL. NULL).


Yun



From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Peter 
Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich <rs...@akamai.com>; openssl-dev@openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that 
after threading has started is not going to give good results with or without 
locking.

Peter




From:    "Salz, Rich via openssl-dev" 
<openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>>
To:"openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>" 
<openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>>
Date:24/01/2018 11:19
Subject:Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c
Sent by:"openssl-dev" 
<openssl-dev-boun...@openssl.org<mailto:openssl-dev-boun...@openssl.org>>



  *   OpenSSL APIs, which makes the following OpenSSL documentation statement 
invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html=DwMFAw=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY=>)


  *   "OpenSSL can safely be used in multi-threaded applications provided that 
at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


Well, the most likely fix is to make the “safely” wording be more vague, which 
I doubt you’ll like.  But I doubt anyone on the team has much interest in 
fixing 1.0.2 locking issues.--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=



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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Salz, Rich via openssl-dev]

➢ ah, true, I have those disabled because I use the same account for both my 
personal and my work projects so no single email address is correct for them

At least we figured out the confusion!

I have no good answer other than subject line filtering and forwarding, sorry.

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Salz, Rich via openssl-dev]

➢  github ones require me to go to the web 
UI which is slow

I am confused by that.  When someone posts an issue or comment, I get the text 
emailed to me.  Not just openssl, but all projects I watch.




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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Salz, Rich via openssl-dev]

➢ For the lovers of NNTP: openssl-project has been added to news.gmane.org
as gmane.comp.encryption.openssl.project as readonly list.
  
I will always have a fondness for NNTP :)  But that reminds me to nudge the 
other mailing list distributors, and update the website.  Thanks!

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Salz, Rich via openssl-dev]

➢ this feature sends notifications about _all_ conversations happening.

For me, I get the actual comments that are posted.  Don’t you?  On the mailing 
list, you have to explicitly mark/junk conversation threads in your mail 
program.  You would still have to do that here.

I don’t understand what you see as different?

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Salz, Rich via openssl-dev]

You should be able to just watch the openssl repo (the eyeball/watch notice in 
the upper-right side)

On 1/23/18, 7:00 AM, "Hubert Kario" <hka...@redhat.com> wrote:

On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote:
> There’s a new blog post at 
> https://www.openssl.org/blog/blog/2018/01/18/f2f-london/

> We decided to increase our use of GitHub. In addition to asking that all 
bug
> reports and enhancement requests be reported as issues, we now want all
> major code proposals to be discussed as issues before a large pull request
> shows up. This will let the community discuss the feature, offer input on
> design and such, before having code to look at. We hope this will let us
> all first look at the bigger picture, before getting bogged down in the
> weeds of line-by-line code reviews.

does that mean I have to subscribe to all notifications from the openssl 
github project to notice them? that's really suboptimal

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Salz, Rich via openssl-dev]

➢ It appears to me that you could use openssl-dev instead of openssl-project, 
saving cycles on killing one and creating the other.

We discussed that, but it would be harder to “undo” if things don’t work out, 
we wanted to make it very clear that this is a new way of operating, and 
openssl-project is a moderated list.  Make sense?

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

[openssl-dev] Blog post; changing in email, crypto policy, etc

[Salz, Rich via openssl-dev]

There’s a new blog post at 
https://www.openssl.org/blog/blog/2018/01/18/f2f-london/

It contains some important policy changes we decided at our meeting last month. 
 This includes:
- Closing the openssl-dev mailing list; use GitHub for issues
- New mailing list openssl-project for project discussions
- New policy for accepting crypto algorithms, formats, and protocols.
- .. several others

Please read the posting; the changes described in it affect everyone who uses 
OpenSSL.  Thanks for your interest, and all your efforts to help improve the 
project!



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

Re: [openssl-dev] PKCS12 safecontents bag type deviation from spec

[Salz, Rich via openssl-dev]

OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE OF.  Ouch!  
Will that cause interop problems if we change it?  (I don’t remember the DER 
encoding rules)



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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Salz, Rich via openssl-dev]

I don’t think anyone is talking about OpenSSL depending on or requiring Apache; 
that’s a non-starter.

It would be interesting to see how many changes you need to support your 
platform.

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Salz, Rich via openssl-dev]

➢  We are currently modifying the source from Apache to OpenSSL open source 
licensing for the Speck/OpenSSL integration. Related repositories such 
as the cipher itself will remain under the Apache license. We would love 
input on the following items:

Don’t bother changing the license.  The future direction of OpenSSL is moving 
to Apache, anda it’s unlikely this work would show up in OpenSSL before we 
change the license.

We’ll soon have a blog post about our current thoughts on a crypto policy.  
Watch this space.

For discussion, the future-compatible thing to do :) is open a GitHub issue.  
Then, make a pull request after the issue discussion seems to have died down.

Hope this helps.

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

Re: [openssl-dev] Is X509_free(NULL) ok?

[Salz, Rich via openssl-dev]

Yes you can do so.  It is documented in most of the manpages, and in 1.1.0 and 
later it should be in all of them.

On 1/1/18, 11:19 AM, "Ray Satiro via openssl-dev"  
wrote:

I'm trying to figure out whether it's supported to call X509_free(NULL)
in 1.0.2 and beyond. It's not documented what action occurs when the
pointer is null. Also generally speaking is it supported to call openssl
free functions with null pointers?


-- 
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] Is X509_free(NULL) ok?

[Salz, Rich via openssl-dev]

➢So it's guaranteed for 1.1, mostly guaranteed for recent 1.0.2, but not
guaranteed for older 1.0.2.

yes.


➢ I also think it would be good to backport all to 1.0.2

Yes.  I believe I did that, but I am not absolutely 100% positive.

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

Re: [openssl-dev] Is X509_free(NULL) ok?

[Salz, Rich via openssl-dev]

➢ I think we fixed all such cases in 1.1.0, all *_free() functions
should handle NULL. I don't think we backported to changes to 1.0.2.

Yes, and we fixed the documentation.  I backported all/most of them to 1.0.2 to 
make cherry-picking easier.  I don’t know if I changed the docs.

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

Re: [openssl-dev] [openssl-users] Is X509_free(NULL) ok?

[Salz, Rich via openssl-dev]

>   if (ptr!= NULL) free(ptr);
  
That shouldn’t be necessary for OpenSSL.  If you find places where it is, 
please open an issue.
  
➢ BTW, "can handle" should explicitly say what happens.  Perhaps use the C 
library text, which says:

If ptr is NULL, no operation is performed.
  
That is the wording we use.

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

Re: [openssl-dev] Is X509_free(NULL) ok?

[Salz, Rich via openssl-dev]

Our intent is that all FREE functions can handle NULL.  If you find things 
missing or undocumented, please open an issue on GitHub.  Thanks!
 

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

Re: [openssl-dev] A question DH parameter generation and usage

[Salz, Rich via openssl-dev]

You can re-use the keys, but then you get no forward secrecy, and sessions 
generated with one connection are vulnerable to another.

Why are you using DH?  Unless you have compelling reasons (interop with 
legacy), you really should use ECDHE.

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

Re: [openssl-dev] frequency and size of heartbeat requests

[Salz, Rich via openssl-dev]

The purpose of the HEARTBEAT message is for DTLS applications to determine the 
maximum packet size and tune the application records accordingly. There is 
never any reason to use this in TCP-based TLS; that was an OpenSSL bug that 
enabled it there.

The usefulness of HEARTBEAT even in DTLS is probably pretty small and it is 
probably safer to just turn it off. Spending time and code to “protect it” is 
probably not worth the effort.

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

Re: [openssl-dev] FIPS module for 1.1.x ?

[Salz, Rich via openssl-dev]

FIPS remains a very important goal.  Hopefully we’ll have more details to share 
in early December.

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

Re: [openssl-dev] New crypto algorithms in openSSL engine

[Salz, Rich via openssl-dev]

>@Victor; Are you saying so that the patches that enabled the GOST
ciphersuite be added are not included in openSSL? If so, would that mean
it's not possible for me to fork off openSSL and follow the GOST template?

Not quite.  He’s saying that adding new crypto to TLS requires some static 
tables in libssl to be updated.  Some new “NID” variables in objects.txt, and 
so on.  The implementation of the algorithm can be done as an ENGINE.

>Putting engines aside for a moment, given that I have the appropriate
headers for the crypto library I want to use, and I can build a shared or
static library for it... would it be a viable option to try and integrate
those headers and libraries directly into openSSL? 
  
Maybe. Hence the term “research” :)

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

Re: [openssl-dev] New crypto algorithms in openSSL engine

[Salz, Rich via openssl-dev]

➢ Really, about a ten years ago, when we first developed GOST engine, we
have made patches, that allow to add ciphersuites dynamically.
Unfortunately, that time core team haven't accepted these patches.

Do you still have them available?  We might make a different choice now …

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

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

[Salz, Rich via openssl-dev]

Can the people involved in these Tests please speak up what's going on
here? Particularly can you please name vendor names?


Tbe TLSWG mailing list is probably a more effective place to have that 
discussion; I was just informing the OpenSSL community of the state of play ;)


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

[openssl-dev] Can I haz TLS 1.3 ?

[Salz, Rich via openssl-dev]

Some people have asked why TLS 1.3 isn’t available yet.  This might help; it’s 
a draft of a posting for my company’s blog.


Can I Haz TLS 1.3 ?

Everybody wants to be able to use TLS 1.3. Among the reasons are:
It’s faster – being able to reconnect to a server you’ve 
previously used, and saving a full round-trip latency is impressive.
It’s more reliable – the protocol has been cleaned up and 
simplified. For example, the related concepts of sessions, tickets, and 
pre-shared keys are merged and treated consistently. To a protocol designer, it 
is much more elegant, and therefore much easier to implement
It’s more secure – Many world-class cryptographers have been 
involved in the protocol design, analyzed it, and tried to break it.

TLS has been in the “last call” for several weeks now.  What does that mean, 
and what’s holding it up?

The IETF is the organization that defines most of the standards that define how 
the Internet works. They cover everything from naming (DNS) to routing around 
firewalls, up to and including HTTP. The documents, known as RFCs, are created 
by working groups, passed to a steering committee for review, and then 
published as “Internet Standards.”

Participation in a working group (WG) is, by design, very easy and not a lot of 
overhead.  You just have to join a mailing list.  Every WG has a mailing list 
and there are currently more than 110 working groups hosted at the IETF. Each 
one has a status page, that shows their charter (what they are working on), the 
current sent of documents, and pointers to the mailing lists.  For the TLS 
working group, that page is at https://datatracker.ietf.org/wg/tls/documents/.

Future RFC’s start as Internet-Drafts. Each draft usually goes through multiple 
revisions, as the working group members comment on it, other feedback is 
addressed, and so on.  At some point, the authors or editors will post a new 
draft.  By convention, every working group draft is named 
“draft-ietf-{WGNAME}-{subject}-{nn}” where {WGNAME} is the name of the working 
group, {subject} is the name of the document, and {nn} is the revision number.  
For example, “draft-ietf-tls-tls13-21” is the 21st draft of the TLS 1.3 
specification from the TLS working group.

When the working group thinks a document is done, it enters WGLC, working group 
last call.  This period, usually lasting a couple of weeks, is the last chance 
to make editorial or serious factual fixes.  Since most people are 
deadline-driven, this is usually when many on the WG wake up and read the 
drafts. After WGLC, it goes to the IESG (technical leadership basically) for 
review.  As I said, TLS 1.3 has been in WGLC for weeks.  So why can’t we use it 
yet?

First, the different drafts don’t interoperate. Each represents a different 
milestone on the way to the full specification, and a flag in the header 
identifies which draft is being used. OpenSSL, used by most of the servers on 
the Internet, is currently at draft-21. Chrome and Firefox, two of the most 
popular browsers on the Internet, are staying at draft-18; they don’t want to 
upgrade until we have the final version. (I think that’s silly, but I don’t 
work for either browser.)

Tests run by various companies, including Google, Mozilla, and Facebook, 
indicate that the “failure rate” of TLS 1.3 is disturbingly high. It appears 
that network hardware such as routers, gateways, load balancers and the like, 
are blocking TLS 1.3 packets because they don’t recognize the protocol. They 
are doing “fail closed” and block the connections because they don’t understand 
it, rather than assuming it’s safe to forward. The IETF often uses the term 
“middlebox” to describe such hardware that operates between endpoints, and this 
type of behavior that blocks new protocols as “ossificiation.”  The various 
companies, and no doubt others, are trying experiments to tweak the protocol to 
lower the failure rate. For example, in some circumstances it might be 
acceptable to make a TLS 1.3 message look like a TLS 1.2 message (after you’ve 
already committed to doing TLS 1.3).

So far nobody has released any details. When it happens, it will be on the 
TLS-WG mailing list, which you can find at the page I referenced above. Until 
then, because of the draft differences, it’s impractical to run even limited 
deployment tests unless you’re willing to work with bleeding edge releases and 
undocumented flags. That’s unfortunate, and we all hope that the situation will 
be improved by the next IETF meeting in November. Until then, we just have to 
sit tight and wait.

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

Re: [openssl-dev] OPenssl 1.1.0 and FIPS

[Salz, Rich via openssl-dev]

> FIPS is not supported for 1.1.0
> 

>jUST A SMALL FIX WILL DO.
  
No.  All of the FIPS supporting code has been pulled out of 1.1.0  Even if you 
get it to compile, it will fail at link or runtime because of missing functions.

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

Re: [openssl-dev] OPenssl 1.1.0 and FIPS

[Salz, Rich via openssl-dev]

Tryong to compile  Fips into OPEnssl-1.1.0  and I run into

FIPS is not supported for 1.1.0

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

Re: [openssl-dev] 20170914 snapshots

[Salz, Rich via openssl-dev]

We did some system upgrades and they were down during the update time.

As I’ve said before, please wait for at least a second day before writing about 
the snapshots.

On 9/14/17, 8:09 AM, "The Doctor"  wrote:

They are missing in action!



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

Re: [openssl-dev] id-kp-OCSPSigning extended key usage

[Salz, Rich via openssl-dev]

➢ Thanks for the clarification. Per the spec, then, a certificate designated to 
sign OCSP responses is required to have the ocsp-sign bit in the key usage 
extensions set.
➢ How does openssl handle cases where this requirement is violated?

Look at check_delegated() in ocsp/ocsp_vfy.c  It returns an error.


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

Re: [openssl-dev] 1.1.1 master consistently fails (was Re: openssl 1-1-0-stable fails)

[Salz, Rich via openssl-dev]

Ø  Config & build script (feel free to suggest improvements, BTW):

Perhaps don’t cut/paste green-on-black color?  Plaintext is probably sufficient.

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

Re: [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors

[Salz, Rich via openssl-dev]

FWIW, there’s a ‘libtls’ library from the libre folks that might be worth 
looking at.

If you come up with useful snippets we can start by posting them to the wiki, 
for example


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

Re: [openssl-dev] [openssl-users] how to compile out selected ciphers

[Salz, Rich via openssl-dev]

What version of openssl are you  building?

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Salz, Rich via openssl-dev]

➢ > Sure I can.  Because the DRBG seeds from the system anyway

➢ You can't assume that will work for all users.

And for places where the systesm doen’t have enough randomness, there is 
nothing we can do.

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Salz, Rich via openssl-dev]

➢ But now we just ignore it and assume every bit with get contains 1
➢ bit of randomness and we're sundenly seriously overestimating the
➢ amount of randomness we're getting. This is a documented public API,
➢ you can't just go and ignore this parameter.

Sure I can.  Because the DRBG seeds from the system anyway

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Salz, Rich via openssl-dev]

➢ I’d like to suggest that any approach other than “immediately mix the 
received randomness into the RNG state” is bad. If a user does RAND_add() now, 
as opposed to 100 source code lines before, there may be a reason for that.

I think the only way to do that in the DRBG model is to treat it as “additional 
input” and do a generate call.  I think that would achieve the same effect, but 
it wouldn’t delay any possible seeding of randomness that the DRBG itself needs 
at some point.


➢ One “API” is how to get a reference/pointer/instance/whatever to the DRBG 
object responsible for the operation I’m now concerned with, and that I want to 
influence/improve. This would probably differ between per-SSL DRBG and 
per-thread DRBG, etc. I haven’t even thought about this part of the API (and 
I’m sure others on the team have more experience and understanding of the 
OpenSSL code to do it better than I would anyway).

  Yes, it is separate.  But I want to make sure that if we are doing a 
comprehensive RAND overhaul that this is included in the requirements.

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Salz, Rich via openssl-dev]

➢ IMHO this interface is a way for the user to improve the quality of the 
randomness it would get from the given RNG, *not* to replace (or diminish) its 
other sources. My proposal is to abolish this parameter, especially since now 
it is simply ignored (and IMHO – for a good reason).

We cannot do this in a minor release; we have to wait until 1.2




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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Salz, Rich via openssl-dev]

➢ An other problem with the current implemenation is that the
➢ randomness parameter that's now given to RAND_add() is just
➢ ignored, it assumes it's the same as the length.

For what it’s worth, this was done deliberately, make RAND_add and RAND_seed 
equivalent.

I am skeptical of the ability to get that estimate correct.

Someone on GH there is a conversation thread about turning that into a 
percentage, which seems like the best thing to do for any new API.


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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Salz, Rich via openssl-dev]

Could you please be more specific wrt. DRBG organization that in your 
opinion could impact the UI? 

From your use-case:  you want to add entropy into a specific DRBG.  You want to 
push it, as opposed to the DRBG “pull when needed” model.  That’s an additional 
API.  Also from your use-case: you want to specify which DRBG instance gets 
that entropy.  If we move to a pair per thread, as opposed to one per SSL and 
two in the global space, how do we make sure that API still works and does the 
right thing.

Does that makes sense, and does it answer your question?


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

Re: [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors

[Salz, Rich via openssl-dev]

Getting the client connect right appears surprisingly messy when one
needs to cope with all kinds of network error situations including
domain name resolution issues and temporarily unreachable servers.
Both indefinitely blocking and non-blocking behavior (i.e., connection
attempts with and without a timeout) should be supported.


It is a complicated issue and hard to get right for all definitions of right 
for all applications ☺

A set of API’s that set up all the TLS “metadata”, and took a connected socket 
might be a way through the maze.  For example:
SSL *SSL_connection(int socket, const char *servername, …whatever…)


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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Salz, Rich via openssl-dev]

dev asap. If there are problems with it we can always revert it before
it makes it into a release.
 
Someone on the OMC called that “flip-flopping” and seemed to be against this 
kind of thing.

If we are going to have an additional API, then we should at least see a draft 
of the header file first.

Keep in mind that the current DRBG organization might change, and we don’t want 
to lose that freedom.



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

[openssl-dev] CVE 2017-3735 OOB read

[Salz, Rich via openssl-dev]

From https://www.openssl.org/news/secadv/20170828.txt

OpenSSL Security Advisory [28 Aug 2017]


Malformed X.509 IPAdressFamily could cause OOB read (CVE-2017-3735)
===

Severity: Low

If an X.509 certificate has a malformed IPAddressFamily extension,
OpenSSL could do a one-byte buffer overread. The most likely result
would be an erroneous display of the certificate in text format.

As this is a low severity fix, no release is being made. The fix can be
found in the source repository (1.0.2, 1.1.0, and master branches); see
https://github.com/openssl/openssl/pull/4276. This bug has been present
since 2006.


This issue was found by Google's OSS-Fuzz project on August 22.
The fix was developed by Rich Salz of the OpenSSL development team.

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

[openssl-dev] Reseeding at fork time

[Salz, Rich via openssl-dev]

For those interested, there is a lot of discussion going on over at 
https://github.com/openssl/openssl/pull/4239

I consider it bad that the conversation is happening there, not here, but so it 
goes.  If you don’t have a GitHub account and wish to post, forward to me and I 
will post it for you.

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

➢ Even opaque objects usually have some public interface. I think exposing 
RAND_add_ex() would be a good idea for 1.1..1, and it’s likely to serve as an 
acceptable “live forever” API.

That’s my point.  API decisions live forever.  Suppose we move around the 
DRBG’s so that they are per-thread, or per-SSL_CTX or per-SSL object?  Will 
that API still work?  Or will we need a A “RAND_ex_ex” function?  We don’t have 
even consensus on when and how to reseed.


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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

>This is why I want to add things like that by default in the
>additional data.
  
On reseed or generate?

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

>I personally see no harm if these RNG objects are made available to 
> applications that need/use them

But decisions like this live forever.   It is therefore VERY important to spend 
time thinking about what becomes part of the public API and what remains hidden 
so that we can change things later when we have a better understanding.

This concept is new to OpenSSL :)  But we just put out a 1.1.0 release that 
made things opaque, so it’s more fresh in the minds of at least some of the dev 
team.

Personally, since DRBG is new in 1.1.1 I would be quite happy if we didn’t 
expose anything public until the release after that.

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

>An idea that I had was to default to reseed on fork if we know we
>have a working syscall.
  
Or /dev device too?

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

Okay:  https://github.com/openssl/openssl/pull/4239



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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

We should think carefully about what API’s we are exposing, and might want to 
wait for 1.1.2

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

Is this new RNG object available to user programs, or do they need
to reinvent the wheel even though they definitely link against the
OpenSSL library?


You don’t have to re-invent the wheel, but you might have to modify the source 
☺  Did you read the blog posting?  What wasn’t clear?

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

➢ But I’d like the development team to comment on (and ideally – accept) my 
request to add RAND_add() method to the RNG that is used in generation of 
private keys.

Well, I’ve been thinking about this for a bit, since you first raised it.  I am 
still not sure of the need.  And as the blog post says, we’re not convinced 
that the current DRBG arrangement is something that will never change.  But I 
think a new API, RAND_add_ex that took a flag that had values like 
RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE, RAND_LOCAL_PRIVATE 
indicating which to seed. Thoughts?

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

 
The problem with /dev/urandom will go away sooner or later. All major
platforms either have a CPRNG syscall for years or introduced one
recently. BSD has getentropy(2) for a while, Windows has
CryptGenRandom() and Linux has getrandom(2) since Kernel 3.2 and glibc 2.15.


Agreed.

And when we can make –with-rand-seed=syscall the default, then it will be  a 
happier place ☺

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

It seems to me this all depends on the order of things you do to
create a daemon. You could make sure the RNG is inited, chroot,
and then fork for instance. And I suspect there are actually
programs that do it in that order.


Yes.

I think the safest thing is for us to not change the default.  Programs that 
know they are going to fork can do the right/safe thing.  It would be nicer if 
we could automatically always do the right thing, but I don’t think it’s 
possible.

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

\
> somewhere someone is.  And then it’s not about just reseeding, but
> what about when (if) we add other things, like whether or not the
> secure arena gets zero’d in a child?

It's difficult to think of what circumstances this might break existing
code? What scenario did you have in mind?

As excerpted above in my post.

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

And this is a very good answer. Perhaps this guidance deserves being documented 
somewhere besides this mailing list? Something along the lines of 
It is documented in the RAND_add manpage.

➢ I’m not sure I agree here. What effort are you talking about? In order to 
select an order in which available sources are queried, the developers had to 
think (hopefully :). Those thought could be documented in a few lines of text. 

And what would be the point?  Why should someone trust the documentation, which 
can get out of date, more than the source?

➢ So while the team clearly has the right to make changes (especially 
before the interface became public ;), but I’d rather that such changes  are 
guided by an informed consent from the public (such as yours truly ;). 

We aren’t cutting off any avenues of participation.  Email discussion and pull 
requests are always welcome.  But yes, the barrier to useful participation is 
that someone has to first read and understand the source.

➢ I think it is *imperative* for a user to be able to RAND_add() to the DRBG 
that gnerates private keys. I cannot emphasize enough how critical this is.

I am curious to know your justification for this.  It seems to me that if 
you accept the DRBG document, which we do, then the way we do the seeding is 
fine.  If you don’t accept the document, then modify the source.


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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

>>> 3. What should I do if I want a given source to be used in addition to the 
>>> other sources, regardless of whether openssl thinks it got “enough bits” of 
>>> randomness or not?

>> Modify the source :)

>Very bad answer. 

And also a wrong one.  Your application can always call RAND_add().  Sorry for 
mistake.

> I have no problem reading the source code. I do have a problem with (a) 
> important decisions like this not “formalized” and documented, and (b) 
> mechanisms to tune the RNG seeding not provided and clearly and 
> comprehensively documented.
   
This is a mostly volunteer open source project.  We are unlikely to commit to 
something that requires so much effort when, frankly, most of the consumers 
aren’t interested, or qualified, to make an assessment.  I am sorry if that 
sounds obnoxious or conceited.  It shouldn’t; there are many things that I know 
I’m not qualified to comment on :)  And also, we reserve the right to make 
changes.

I expect that the FIPS project, just starting, will be of interest to you. 

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> 1. What’s the default if “with-rand-seed” was not provided? All of the listed 
> supported types? None of them? Some of them…?

As the first bullet says, it’s “os”.   As for the second part of your question, 
it is deliberately not answered.   If you care, you’ll have to read the source. 
 (It’s clean and easy to do so, now.)  We’re not documenting everything.

>2. What is the order in which the seed sources are tried (both when 
>“with-random-seed” was and was not given)? 

Read the source.

> 3. What should I do if I want a given source to be used in addition to the 
> other sources, regardless of whether openssl thinks it got “enough bits” of 
> randomness or not?

Modify the source :)

For a few reasons, we’re deliberately not documenting all the details.  
Interested parties will have to read the source.



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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

Thanks everyone for the discussion (mainly in June) about this.  There’s a blog 
post describing what we’ve done for the 1.1.1 release: 
https://www.openssl.org/blog/blog/2017/08/12/random/

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

[openssl-dev] FW: Code health tuesday is back!

[Salz, Rich via openssl-dev]

A reminder: After a short summer vacation, our biweekly code health Tuesday is 
back!

Our topic this time is … documentation.

There have been many updates to the manpages in the past few weeks, typo fixes, 
additional clarifications, and so on.  We hope that folks will be emboldened to 
help fill in the gaps, but any PR to make things better will help.

Please submit your fixes by Tuesday; if you can’t add a label, put ‘code 
health’ somewhere in the commit message.  Please have a CLA on file; if your 
commit is trivial and not copyrightable, put “CLA: trivial” in the commit 
message.  If you have a whole bunch of trivial fixes, put them in one PR 
(separate commits if you want).  Make sure any changes pass find-doc-nits (a 
script in util).  You can also use that script to list places where 
documentation is missing:

   ; ./util/find-doc-nits -u | fgrep '#'
   # Found 4373 in util/libcrypto.num
   # Found 1724 missing from util/libcrypto.num
   # Found 464 in util/libssl.num
   # Found 64 missing from util/libssl.num
   # Checking macros (approximate)
   # Found 246 macros missing (not all should be documnted) 

Thanks for all your help in improving OpenSSL!

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

Re: [openssl-dev] Current master fails to build

[Salz, Rich via openssl-dev]

> After that is fixed, test 80-test_new_ssl.t fails (wstat 256, 0x100).

Do you have core file?  The failure is not repeatable, at least on my system :(
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Code health tuesday is back!

[Salz, Rich via openssl-dev]

After a short summer vacation, our biweekly code health Tuesday is back!

Our topic this time is ... documentation.

There have been many updates to the manpages in the past few weeks, typo fixes, 
additional clarifications, and so on.  We hope that folks will be emboldened to 
help fill in the gaps, but any PR to make things better will help.

Please submit your fixes by Tuesday; if you can't add a label, put 'code 
health' somewhere in the commit message.  Please have a CLA onfile; if your 
commit is trivial and not copyrightable, put "CLA: trivial" in the commit 
message.  If you have a whole bunch of trivial fixes, put them in one PR 
(separate commits if you want).  Make sure any changes pass find-doc-nits (a 
script in util).  You can also use that script to list places where 
documentation is missing:

; ./util/find-doc-nits -u | fgrep '#'
# Found 4373 in util/libcrypto.num
# Found 1724 missing from util/libcrypto.num
# Found 464 in util/libssl.num
# Found 64 missing from util/libssl.num
# Checking macros (approximate)
# Found 246 macros missing (not all should be documnted)

Thanks for all your help in improving OpenSSL!

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

Re: [openssl-dev] Master: test fails

[Salz, Rich via openssl-dev]

So what are your exact config options?  Just the “./config” line.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

From: Blumenthal, Uri - 0553 - MITLL [mailto:u...@ll.mit.edu]
Sent: Saturday, July 22, 2017 10:23 PM
To: Salz, Rich <rs...@akamai.com>; openssl-dev@openssl.org
Subject: Re: [openssl-dev] Master: test fails

Sure looks like that...

Regards,
Uri

Sent from my iPhone

On Jul 22, 2017, at 14:41, Salz, Rich via openssl-dev 
<openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>> wrote:
Wow that green is hard to read ☺

So your config options change the tests for 70-test-tls13messages, but the plan 
isn’t updated, right?
--
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] Master: test fails

[Salz, Rich via openssl-dev]

Wow that green is hard to read ☺

So your config options change the tests for 70-test-tls13messages, but the plan 
isn’t updated, right?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] RNG seeding

[Salz, Rich via openssl-dev]

There has been a great deal of useful discussion about how OpenSSL should seed 
its random number generator (CSPRNG).

There's now a pull request that is mostly complete.  Please  take a look at 
https://github.com/openssl/openssl/pull/3956  and feel free to comment.

In particular,  
https://github.com/richsalz/openssl/blob/rand-seed/crypto/rand/rand_unix.c has 
all supported seeding options for linux/unix systems; you can send feedback to 
me directly or post to the list.


--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

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

Re: [openssl-dev] openssl s_server "-legacy_renegotiation" option was present in version 1.0.1u but removed in version 1.0.2a

[Salz, Rich via openssl-dev]

You might find that the SSL library doesn’t have the code to do the old-style 
insecure renegotiation.

If it does, then it probably makes sense to support this as a debugging option.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Compiler requirements

[Salz, Rich via openssl-dev]

> beldmit> What is the minimal version of the compiler to build openssl?
> beldmit> Is it still required C89 compatibility or C99 standard can be used?
> beldmit>
> beldmit> Unfortunately, I did not find these requirements in documentation.
> 
> At the beginning of INSTALL, you will find a set of requirements.  On of them
> is "an ANSI C compiler".

That doesn't answer the question :)  Which version of ANSI C?

I believe C89 is written down somewhere.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Dynamically adding a NID

[Salz, Rich via openssl-dev]

> I tried using OBJ_create() with NULL or an empty string for the OID, but 
> currently it checks that the given OID is actually a valid one. Is there any 
> workaround to avoid this other than issuing my own OID?

No.  Just get an OID ARC, such as from the IETF Enterprise MIB [it's free] and 
throw it away.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> Just to check my understanding, the claim is that adding more layers of 
> hashing and/or encryption will still be faster than a larger number of 
> syscalls?

In terms of overall system performance?  Yes.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

From: Benjamin Kaduk via openssl-dev [mailto:openssl-dev@openssl.org]
Sent: Tuesday, June 27, 2017 9:22 PM
To: openssl-dev@openssl.org; Paul Dale 
Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL

On 06/27/2017 07:24 PM, Paul Dale wrote:

The hierarchy of RNGs will overcome some of the performance concerns.  Only the 
root needs to call getrandom().
I do agree that having a DRBG at the root level is a good idea though.


Just to check my understanding, the claim is that adding more layers of hashing 
and/or encryption will still be faster than a larger number of syscalls?

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

That's interesting info Ted, thanks. But we don't currently know anything about 
which kernel or glibc version we're building for; maybe that has to change.  
(We barely, and rarely, look at the toolchain version.)  And we need to be able 
to build a version which runs across a whole mess of kernels and x86 CPU's.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> In case it wasn't clear, I think we should use the OS provided source as a
> seed. By default that should be the only source of randomness.

I generally agree.  But some applications might save their state and restore it 
during boot time, for example.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> RAND_set_rand_method(RAND_drbg_method());
> 
> FIPS_drbg_set_reseed_interval()   and
> FIPS_drbg_set_callbacks()

Take a look at https://github.com/openssl/openssl/pull/3789  Thanks!
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> > Getrandom() is a syscall, and I have concerns about the syscall
> > performance.  I would rather feed getrandom (or /dev/random if that’s
> > not available) into a FIPS DRBG generator.
> 
> What is your concerns about syscall performance?  What are your
> performance requirements?  I can tell you that Chrome has been using
> /dev/urandom 

Well, Chrome ultimately works at human-scale.  On the server side, thousands of 
connections per second and one or two syscalls per connection seems like 
something we should avoid.

> My recommendation for Linux is to use getrandom(2) the flags field set to
> zero. 

And for older Linux?

> So if you are going to be trying to design your own RNG
> for OpenSSL --- welcome to my world.

We seem to have moved away from that somewhat.  That's a better place to be.

> find that in the end, it's impossible to make them all happy, and they will 
> end
> up questioning your intelligence, judgement, and in some cases, your
> paternity.  :-)

I miss Usenet. :)


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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

For windows RAND_bytes should just call CryptGenRandom (or its equiv).  For 
modern Linux, probably call getrandom(2).  For OpenBSD call arc4random().

Getrandom() is a syscall, and I have concerns about the syscall performance.  I 
would rather feed getrandom (or /dev/random if that’s not available) into a 
FIPS DRBG generator.

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> > Well maybe I can ignore section 10.3?
> >
> 
> That's a nice joke Rich, but the Dual_EC_DRBG chapter has been dropped in
> SP800-90Ar1, which supersedes SP800-90A:

I know.  I was trying to gently point out that even John makes mistakes :)

> - Do you intend to continue supporting RAND_set_rand_method() or will
> there only be one 'perfect' random generator and no choice anymore?

This will continue to work.
 
> - Do you consider the SP800-90A DRBG outdated or will there be a chance
> that it will be added to the OpenSSL master as
>   officially supported RAND method?

That's a great idea, I can work on that now.

> - Will the new OpenSSL RNG support a way to configure reseed intervals and
> external entropy sources in a similar fashion
>   as the FIPS DRBG did?

That's three questions :)  But yes, we should address that.  I'm not sure if 
new RAND API's are the way to go or perhaps a RAND_control API that gives us a 
bit more flexibility.

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

John,

Thanks for pushing.  It can be a thankless task, and I wanted to say thank you 
:)


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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> > Suppose the chip supports RDRAND but the runtime doesn't have
> > getrandom or /dev/random?
> 
> That's an easy one!
> 
> Check the feature-test bit and then call RDRAND yourself.
> Code to do this exists, e.g.

Yeah, that's kinda what I meant we'd do.


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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> As for reliability, I don't know what "mediocre" means.  Usually security-
> critical code is correct or it's not.  For a seed-source, either a lower 
> bound on
> the amount of good "hard" randomness is available and reliable, or it's not.

We run in many environments, and I don't think it's reasonable to say that the 
RNG on someone's personal web server, perhaps on the Internet, is at the same 
level of criticality, say, as the same RNG running on something like a global 
CDN.  I am not trying to back out of our responsibilities here, but rather 
saying that I think a justifiable case can be made for accepting vague words 
like mediocre at times.

> That's moving the outer loop to the inside, for no good reason.

That's a good way to put it, but there is a good reason for doing so.  What 
should OpenSSL do when someone says "build for linux"  Because pretty much 
right now that's all they can say.

>  --  If you trust this particular OS to provide a seed, why not
>   trust it for everything, and not bother to implement an
>   openssl-specfic RNG at all?

Excellent question.  The only answer I have so far is avoiding the syscall 
overhead when not needed.

> If the questions are unanswerable for each individual OS, it seems both
> impossible and pointless to try to answer them for all OSs at once.

> The standard advice that you see on e.g. the crypto list is to use whatever
> the OS provides. 

So is /dev/random to be used in the same way as getrandom(2)?  That's not a 
rhetorical question.

> In particular, if the ambient environment is not secure, it is very unlikely 
> that
> anything openssl can do will make it secure.
 
Suppose the chip supports RDRAND but the runtime doesn't have getrandom or 
/dev/random?

> If what the OS provides isn't good enough, you should file bug reports
> against it.

It's not us, it's the people using it.  We don't have the wherewithal or 
knowledge to do so. 

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

I was asked off-list why we're doing this.  A reasonable question. :)

There are many complains about the OpenSSL RNG.  For started:
https://github.com/openssl/openssl/issues/2168
https://github.com/openssl/openssl/issues/898
https://github.com/openssl/openssl/issues/2457
https://github.com/openssl/openssl/issues/3125

Also, there's things like this:
It uses MD5
It has a global pool, not per-thread so there's locking
It doesn't use getrandom available on modern Linux systems
It uses other bizarre private hashing and mixes in time and getpid

To summarize, perhaps, let's just say that it is really really outdated.  The 
state of the art has advanced, and we have some catching-up to do.

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> Insofar as any hole that is not explicitly closed should be presumed open,
> then yes, there are many holes.

Any hole not known -- presumed open, or presumed closed? :)  It's more about 

> What's your threat model?  I know that sounds like a cliché, but it's actually
> important.

We're trying to do a better job than the current stuff.  We want to provide a 
good cross-platform API that uses the operating system when it's worth doing 
so. 

There are lots of vague words in that.  Deliberately.
 
>  --  If you trust the ambient OS to provide a seed, why not
>   trust it for everything, and not bother to implement an
>   openssl-specfic RNG at all?

Because the ambient OS isn't one, but is one of many possibilities.  A good 
kernel getrandom might exist, a good /dev/random might exist, either might 
exists but be bad, and one might exist and be good.  We want to assume the 
minimum set of O/S facilities, and try to develop code that has the minimum set 
of ifdef's or run-time code paths.  Again, there are vague words there.  But 
code that's perfect but impenetrable does not help our user base.

>  -- Conversely, if you don't trust the OS, what makes you
>   think you can solve a problem the OS failed to solve,
>   especially without knowing why it failed?
> 
> And (!) what do you propose to do when a suitable seed is not available at
> the moment but might be available later?

Leave it up to the application to decide.   It would be nice to say "fix the 
platform" but we run on places where that is not possible.  Right now I believe 
(and this entire note is my opinion) that the best we can realistically do is 
make it possible for portable safe applications to do the right thing.
 
> Are you designing to resist an output-text-only attack?  Or do you also want
> "some" ability to recover from a compromise of the PRNG internal state?

Our TCB border is the process.

> Is there state in a persistent file, or only in memory?

Only memory.

> Just having a pool and a hash function is not enough.  Not even close.

I wasn't suggesting just those.  I was saying that's the pool, and then 
something like chacha.

> Constructive suggestion:  If you want to see what a RNG looks like when
> designed by cryptographers, take a look at:
>   Elaine Barker and John Kelsey,
>   “Recommendation for Random Number Generation Using Deterministic
> Random Bit Generators”
>   http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
> 
> That design may look complicated, but if you think you can leave out some of
> the blocks in their diagram, proceed with caution.  Every one of those blocks
> is there for a reason.

Well maybe I can ignore section 10.3?
 
> Do you trust the generic
> openssl user, who knows nothing about cryptology, to provide either one?

No, which is why we'll have a mixin-from-system API that will hopefully do the 
right thing.  Ideally on all places where openssl runs.

> Combining many lousy sources and hoping that one of them will do the job is
> not good engineering practice.

But if there are a couple and they're both mediocre?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> Do you think we need to use multiple sources of randomness? I think we
> should only use the one source, the one provided by the kernel.

Yes I think we will need to support it, such as systems that don't have kernel 
support.  Always whitening doesn't hurt, so I would like to see the simpler 
logic of always doing it.  And also for the case where existing applications 
mix in their own. 

> > Each pool should have an atomic counter that is incremented when
> randomness is added.  Descendant pools can compare counters and mix in
> their parent when the counters don’t match.  Then when RAND_poll is
> called, or perhaps a new routine RAND_poll_system, it goes into the global
> pool and eventually all other pools will get it (whitened with their current
> state).  RAND_poll isn’t documented.
> 
> The only thing the pool should care about is that it's been initialized or 
> not,
> and if it needs to add more data to it or not.

In order to maintain conceptual compatibility with the current API, I think 
that when someone does RAND_poll or RAND_add, they are expecting it to be be 
used.  I think having a "added_count" field in every pool, and doing a check is 
simple way to ensure that changes to the global pool propagate down.

> You might also want to take a look at something like:
> https://github.com/smuellerDD/chacha20_drng/blob/master/chacha20_drn
> g.c

Is there any reason why this is better than the other mechanisms?

> > We want to be able to save the current global state – write to a BIO – and
> restore it – read from a BIO.  This will let us reasonably work in low-
> randomness situations like system boot.
> 
> Ideally we should refuse to operate in a situation where the kernel didn't
> initialize it's RNG yet. I only know about Linux being broken in this regard, 
> and
> getrandom() / getentropy() really should be available on them by now. I
> don't think we should add a workaround by reading 1 byte from
> /dev/random if getrandom() isn't available.

We're not yet in the ideal world, and all the world's not a modern Linux kernel 
:)  I believe we need to give applications an "escape hatch" to let them 
read/write the global state.  And also think of embedded devices where perhaps 
the state is in NVRAM.

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> Pseudorandomness of the output has been a design goal/requirement only
> in SHA-3 family. Any prior hash function’s exhibition of this property is
> coincidental.
> 
> Therefore I suggest using SHA3 instead.

Is pseudorandomness a requirement?  Or is it the "50% chance of a bitflip"?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

 
> > Is it worth reposting my thoughts with your suggested wording changes?
> 
> OK.  Off-list or on.  This stuff is important.

Reposting.

My thoughts.

Randomness should be whitened.  Anything feed into an randomness pool, should 
be mixed in and run through SHA256.
pool = SHA256(pool || new-randomness)

The current read and write file routines, and the current routine RAND_poll, 
etc., will add to that global pool.  The idea of cascading pools is neat.  We 
need at least one per thread, using our existing thread-local-storage API.  The 
current “lazy evaluation” will work fine, we don’t need a create-thread API.  
We do need fork/exec protection which is the point of 
https://github.com/openssl/openssl/pull/3754

Each pool should have an atomic counter that is incremented when randomness is 
added.  Descendant pools can compare counters and mix in their parent when the 
counters don’t match.  Then when RAND_poll is called, or perhaps a new routine 
RAND_poll_system, it goes into the global pool and eventually all other pools 
will get it (whitened with their current state).  RAND_poll isn’t documented.

Per-thread pools don’t need a lock.  The global and other pools do.  Putting a 
pool in the SSL_CTX is probably reasonable.  I seriously doubt the SSL object 
needs it because the number of random bytes to generate keys is pretty small – 
we’ll expose things through AES misused first ?  But adding it to the SSL 
object is simple so we might as well.

Then to generate random bytes use ChaCha.  See, for example, 
http://gitweb.dragonflybsd.org/dragonfly.git/blob/2aa3f894bd9b5b8f58a1526adb26663405b91679:/sys/kern/subr_csprng.c
  My first thoughts on reading that code were, wow, is it really that easy?

We want to be able to save the current global state – write to a BIO – and 
restore it – read from a BIO.  This will let us reasonably work in 
low-randomness situations like system boot.

We want to provide a platform-neutral API that makes its best effort attempt to 
get randomness from the system and merge it into the global pool.  That should 
be a new API; I suggested RAND_poll_system above, but don’t really care.

Does this make sense?  Are there holes?

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> > Is it worth reposting my thoughts with your suggested wording changes?
> 
> OK.  Off-list or on.  This stuff is important.

I will repost.  And please also see https://github.com/openssl/openssl/pull/3773

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> Suggestion:  Get rid of every mention of "entropy" from openssl code,
> documentation, design discussions, and everywhere else.

I like this and will do it.  Except for our support of the EGD.

> Suggestion:  In the common case where exact meaning is not important,
> "entropy" can be replaced by a noncommittal nontechnical word such as
> "randomness".  Even so, it should be clearly documented that this term is not
> meant to be quantitative.

Okay.

> Suggestion:  If you mean for something to be hard for the attacker to guess,
> the word "adamance" can be used.

All my attempts to look up a definition of this word came up with a noun for 
for adamant.  Which is often appropriate, but maybe no here :)

> Suggestion:  In the remaining cases, which are not rare, it is important to 
> take
> a step back and figure out what is the actual idea that is being (or should 
> be)
> discussed.  This will not be easy, but it must be done, line by line.  
> Otherwise
> the whole enterprise is likely to be a waste of time.

We are trying hard not to waste anyone's time, a d we appreciate your input.  
Is it worth reposting my thoughts with your suggested wording changes?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] discussion venue policy

[Salz, Rich via openssl-dev]

Discussion should be here on the mailing list.


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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

> Will the new architecture still allow engine-defined RNG methods? It's a 
> critical requirement for our products.

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

My thoughts.

Entropy should be whitened.  Anything feed into an entropy pool, should be 
mixed in and run through SHA256.
pool = SHA256(pool || new-entropy)

The current read and write file routines, and the current routine RAND_poll, 
etc., will add to that global pool.  The idea of cascading pools is neat.  We 
need at least one per thread, using our existing thread-local-storage API.  The 
current “lazy evaluation” will work fine, we don’t need a create-thread API.  
We do need fork/exec protection which is the point of 
https://github.com/openssl/openssl/pull/3754

Each pool should have an atomic counter that is incremented when entropy is 
added.  Descendant pools can compare counters and mix in their parent when the 
counters don’t match.  Then when RAND_poll is called, or perhaps a new routine 
RAND_poll_system, it goes into the global pool and eventually all other pools 
will get it (whitened with their current state).  RAND_poll isn’t documented.

Per-thread pools don’t need a lock.  The global and other pools do.  Putting a 
pool in the SSL_CTX is probably reasonable.  I seriously doubt the SSL object 
needs it because the number of random bytes to generate keys is pretty small – 
we’ll expose things through AES misused first :)  But adding it to the SSL 
object is simple so we might as well.

Then to generate random bytes use ChaCha.  See, for example, 
http://gitweb.dragonflybsd.org/dragonfly.git/blob/2aa3f894bd9b5b8f58a1526adb26663405b91679:/sys/kern/subr_csprng.c
  My first thoughts on reading that code were, wow, is it really that easy?

We want to be able to save the current global state – write to a BIO – and 
restore it – read from a BIO.  This will let us reasonably work in low-entropy 
situations like system boot.

We want to provide a platform-neutral API that makes it’s best effort attempt 
to get entropy from the system and merge it into the global pool.  That should 
be a new API; I suggested RAND_poll_system above, but don’t really care

Does this make sense?  Are there holes?

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

[openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

We are starting to work on a new cryptographically strong pseudo random number 
generator for OpenSSL, known as CSPRNG or PRNG or RNG.

Please take a look at GitHub pull request 
https://github.com/openssl/openssl/pull/3758 which is the start of a series.  
In particular, please take a look at some detailed comments from one of our 
committers, at 
https://github.com/openssl/openssl/pull/3758#issuecomment-310938562, and the 
followon.

We welcome your input.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

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

Re: [openssl-dev] Dynamically adding a NID

[Salz, Rich via openssl-dev]

You can get an OID arc of your own for free.  And then you can use real OID’s 
which you just “throw away”

See https://en.wikipedia.org/wiki/Private_Enterprise_Number

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

[openssl-dev] Code Health Tuesday -- Fix the FAQ

[Salz, Rich via openssl-dev]

It's been awhile since we did a code health Tuesday and we're overdue for one 
next week.

Our online FAQ is really old; it's outdated and incorrect.  We haven't fully 
figured out how much of the older versions and older platforms we should 
document.

So, let's fix it.  Move anything older than 1.0.2 to the new "old" section.  
Move anything about really old platforms that aren't fully supported, or have 
strange wonky compilers, etc., to that same section.  And along the way, let's 
fix up any other entries that come to mind.

The repo is here: https://github.com/openssl/web  The FAQ can be found here: 
https://github.com/openssl/web/tree/master/docs

Feel free to clone the fork the repo and make pull requests.  If that's too 
much work, open an issue with the suggested revisions (but please if it's about 
moving entries, do a PR).  The FAQ is mostly plain text, with some 
markdown-like additions.  It should be easy to figure out.

Thanks!  We'll post a reminder about this after the weekend.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

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

Re: [openssl-dev] [RFC 0/4] Kernel TLS socket API

[Salz, Rich via openssl-dev]

A couple of comments.

First, until this shows up in the kernel adopted by major distributions, it is 
a bit premature to include in OpenSSL.  Including netinet/tcp.h is seriously 
wrong to be part of openssl :)  And finally, as I said before, the best way to 
get things in OpenSSL is to do pull requests on GitHub.

Having said all that, the concept is interesting and exciting, and I hope it 
becomes widespread soon.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Google OSS-Fuzz reward

[Salz, Rich via openssl-dev]

Nicely done!

> Cool.
> 
> On 14 May 2017 at 10:49, Kurt Roeckx  wrote:
> > Google awarded us 1000 USD for the initial integration with OSS-Fuzz.
> > See
> > https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-a
> > nd.html
> >
> > I have asked Google to donate it to European Digital Rights (EDRi,
> > https://edri.org/). Google doubles the amount if you donate it to a
> > non-profit organization, so they should be receiving 2000 USD.
> >
> >
> > Kurt
> >
> > --
> > 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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

[Salz, Rich via openssl-dev]

Current master 1d0f116 fails on my machine.

../test/recipes/90-test_secmem.t ..
1..1
# Subtest: ./secmemtest
1..1
# INFO:  @ test/secmemtest.c:65
# Possible infinite loop: allocate more than available

# INFO:  @ test/secmemtest.c:71
# Possible infinite loop: small arena

# INFO:  @ test/secmemtest.c:79
# Possible infinite loop: 1<<31 limit

crypto/mem_sec.c:428: OpenSSL internal error: assertion failed: sh.map_result 
!= MAP_FAILED
../util/shlib_wrap.sh ./secmemtest => 134
not ok 1 - running secmemtest

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

Re: [openssl-dev] shlibloadtest failure on non-Linux

[Salz, Rich via openssl-dev]

> Sense of OPENSSL_USE_NODELETE has been reversed i.e. you want #ifdef
> and not #ifndef

Argh, you're right.
 
> Also I think its still fair game to try a dlclose() just that the
> dlclose() may return an error if OPENSSL_USE_NODELETE is not defined.

I'll just leave it as-is.  Thanks for looking at this!
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] shlibloadtest failure on non-Linux

[Salz, Rich via openssl-dev]

> doesn't test for whether this is set. I think the shlibloadtest should only 
> test
> the dlclose() return value on if OPENSSL_USE_NODELETE is set.

Please see https://github.com/openssl/openssl/pull/3399
 
> 2) crypto/init.c at line 77 does "atexit(OPENSSL_cleanup)". If I try defining
> OPENSSL_USE_NODELETE then this atexit() handler is meant to cleanup on
> unload of the shared library, but this meaning of atexit() is Linux specific. 
> It is
> not required in POSIX and the Linux manpage lists this usage under the
> "Linux notes" section.

Does changing the guard to this work?
#if !defined(OPENSSL_SYS_UEFI) &&  !defined(OPENSSL_SYS_QNX)

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

Re: [openssl-dev] Null pointer dereferences?

[Salz, Rich via openssl-dev]

> The first was in crypto/async/async_wait.c on line 157. `prev` is assigned to
> NULL on 144, and it doesn't look like it is assigned to anything in the while
> loop.

Line 177.
 
> -OPENSSL_free(clienthello->pre_proc_exts);
> +if(clienthello) {
> +OPENSSL_free(clienthello->pre_proc_exts);
> +}

Without the curly braces :)  yes, this seems like a bug.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Code heatlh delayed a week

[Salz, Rich via openssl-dev]

We are still reviewing several PR's from the previous code health, which was 
about converting tests to use the new test framework.  With this extended time 
period, we'll have ended up converting almost all the tests, which is great.

We'll announce the next project toward the end of the week.  Thanks for all 
your participation, folks!


--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

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

Re: [openssl-dev] 2 snapshots did not generate accordingly

[Salz, Rich via openssl-dev]

 
> And What happened to openssl 1.0.1 ?

We stopped supporting it back in December.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev