Re: Beta1 PR deadline

2020-08-27 Thread Salz, Rich
>Please can anyone with PRs that they wish to have included in OpenSSL
3.0 beta1 ensure that they are merged to master by 8th September.

And how are non-committers supposed to do that



Re: Backports to 1.1.1 and what is allowed

2020-06-22 Thread Salz, Rich
  *   I suggest everyone takes a read through  
https://en.wikipedia.org/wiki/Long-term_support
 as to what LTS is actually meant to be focused on.

For what it’s worth, I think Tim’s comments are spot-on.  An LTS release should 
not change unless there are serious bugs or new security flaws.

It is tempting to add new hardware support, nor improved performance.  “Hey, 
everyone will get this in their long-term offering.”  But you’re thinking the 
wrong way.  Imagine that each new patch to an LTS release requires massive 
effort, such as changing the firmware on a plane. Does the change justify that? 
 Almost always, the answer is no.




The hold on PR 12089

2020-06-10 Thread Salz, Rich
What is the timetable for resolving 
https://github.com/openssl/openssl/pull/12089 ?

The Beta is planned for a July 16 release.  There is a massive RAND/DRBG PR 
(https://github.com/openssl/openssl/pull/11682, the provider-friendly random) 
that is in the pipeline, and 12089 and 11682 will undoubtedly cause merge 
issues whichever gets merged first. That means extra time will be needed to 
reconcile. An OMC vote, once started, can be resolved in as quickly as 24 
hours, but often take one or two weeks if most people abstain.

Being conservative, then, the OMC needs to discuss and vote, before the end of 
this month.

An additional complication is around the question of who votes: the OMC or the 
OTC. It is hard to justify this as requiring OMC action, unless the project is 
committing to avoiding such language in the future as a policy. But if the 
project wants to decide that, it can do so. Regardless of the policy, PR 12089 
could be seen as purely an OTC issue, and OMC involvement is over-reach – what 
in https://www.openssl.org/policies/omc-bylaws.html justifies OMC involvement?. 
Nothing changes but some names; is the naming of things within OMC perview? I 
would love to know what OTC members think.

So, what is the timetable, and what is the plan?



Re: Detecting Bad OpenSSL Usage

2020-05-31 Thread Salz, Rich
It would be really interesting to run this over the apps.  Maybe reach out to 
the author for help with that?

From: Dmitry Belyavsky 
Date: Sunday, May 31, 2020 at 5:44 AM
To: "openssl-project@openssl.org" 
Subject: Detecting Bad OpenSSL Usage

Hello,

Here is a nice article about a tool desired to catch misuse of the OpenSSL API.

https://blog.trailofbits.com/2020/05/29/detecting-bad-openssl-usage/

I'm not sure whether it's worth using by the team but maybe it's worth 
mentioning in OpenSSL Wiki.

--
SY, Dmitry Belyavsky


Re: Reducing the security bits for MD5 and SHA1 in TLS

2020-05-27 Thread Salz, Rich
If you do this, you should add a FAQ (in addition to NEWS) explaining it.




error conversion macro's

2020-05-15 Thread Salz, Rich
Perhaps the next Alpha release can do the error macro conversion?

Add script to convert XXXerr() to XXXerror, 
https://github.com/openssl/openssl/pull/9441

In particular, 
https://github.com/openssl/openssl/pull/9441#issuecomment-522171044

It might need updating if any new “error facility” values have been added, but 
I didn’t notice any of them.



Re: Alpha2

2020-05-13 Thread Salz, Rich
>releases - we would simply do them every 3 weeks or so. I'd like to hear
opinions on that proposal too.

I am in favor of this, but you HAVE to keep the cadence regular:  no slipping.



Re: Stale PR stats @May01

2020-05-01 Thread Salz, Rich
This is great transparency info.

Failed CI's are a problem since it's often the fault of timeouts, or sometimes 
master is broken.  Any thoughts on how to handle that?

>So, ignoring deferred issues too you could summarise this as:

Stale PRs waiting for us to do something: 27 (last months: 29)
Stale PRs waiting for the reporter to do something: 34 (last months: 37)
Stale PRs with unclear next action: 46 (last months: 42)

It would be great to see median days on those, too.




Re: CI build timeouts

2020-04-29 Thread Salz, Rich
  *   Disabling memory leak checking doesn’t sound like a great idea..

On that one platform, no?




Re: Cherry-pick proposal

2020-04-29 Thread Salz, Rich
I suspect that the primary motivation for this proposal is that PR’s against 
master often become stale because nobody on the project looks at them. And then 
submitters are told to rebase, fix conflicts, etc. It gets disheartening. If 
that is the motivation, then perhaps the project should address that root 
cause.  Here are two ideas:


  1.  Mark’s scanning tool complains to the OTC if it has been “X” weeks 
without OTC action.  I would pick X as 2.
  2.  Change the submission rules to be one non-author OTC member review and 
allow OTC/OMC to put a hold for discussion during the 24-hour freeze period. 
That discussion must be concluded, perhaps by a vote, within “Y” weeks (four?).





CI build timeouts

2020-03-30 Thread Salz, Rich
It’s time to disable that build, isn’t it?
It’s timing out *AFTER AN HOUR*

From: Tomáš Mráz 
Reply-To: openssl/openssl 

Date: Monday, March 30, 2020 at 9:51 AM
To: openssl/openssl 
Cc: Subscribed 
Subject: Re: [openssl/openssl] [crypto/ec] blind coordinates in ec_wNAF_mul for 
robustness (#11439)


The CI failure doesn't really make sense to me.

That's just an usual timeout unrelated to this PR.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on 
GitHub,
 or 
unsubscribe.


Re: Deprecations

2020-03-05 Thread Salz, Rich
>Moreover, the deprecated commands print something to the effect of: "The 
>command dsa is deprecated. Use ‘pkey’ instead." when executed.

I hope it only does that
If (isatty(0) && isatty(1) && isatty(2)) {
BIO_printf(bio_errerr, “%s: This command is 
deprecated, use the \”%s\” command instead.\n”,
prog, “replacement”);

That is, only if “interactive and print to stderr


Re: OpenSSL Logo (was: New GitHub Project Landing Page)

2020-02-27 Thread Salz, Rich
For what it’s worth, during the Website redesign I asked if anyone could 
provide a scalable logo so that our website worked on mobile, tablets, etc.  
Tony Arceri sent me a pure-CSS solution that worked and looked similar.



Re: Deprecations

2020-02-21 Thread Salz, Rich
>A small note about the 'no-deprecated' configuration option: this is an 
> option to simulate the far future when the deprecated stuff has been removed 
> from the public eye. Deprecated openssl commands should not build with such a 
> configuration. 
  
How can that work?  If the deprecated command calls deprecated API's then 
you'll get build failures.
 



Re: Deprecation

2020-02-14 Thread Salz, Rich
  *   I think we should delay the deprecation of engine stuff to 4.0. 
Personally I don't have sense of stability of provider API.

I share this concern.  This is the first release of the provider 
infrastructure, and while it will be known to work for FIPS modules, it’s 
hubris to think OpenSSL will get it completely right for other uses.

All other deprecations point to existing API’s or, if they are brand new, are 
not a lot of code/work to implement them.  The provider interface is both brand 
new and significant work.  Deprecating and saying “use providers” without at 
least one release cycle of providers, seems premature.


QUIC support

2020-02-06 Thread Salz, Rich
A month ago Tim said[2] that PR 8797[1] requires on OMC decision on “whether or 
not QUIC in this manner of approach should be added into OpenSSL at this time.”

To save you a click, this PR adds API’s to OpenSSL so that Google’s open source 
QUIC implementation can be built on top of OpenSSL.  For more details, perhaps 
my comment [3] explains the situation best.

I am asking the OMC to come to call a vote on this *NOW*  I am CC’ing 
openssl-users so that the community can comment.


[1] 
https://github.com/openssl/openssl/pull/8797
[2] https://github.com/openssl/openssl/pull/8797#issuecomment-571899829
[3] https://github.com/openssl/openssl/pull/8797#issuecomment-485002590



Re: Travis in solid red mode again

2020-02-03 Thread Salz, Rich
  
  >  Could we add a CI check for PRs that confirms that the target branch is
green in travis?

Looking at 
https://docs.travis-ci.com/user/notifications/#conditional-notifications and 
https://config.travis-ci.com/ref/notifications/email it seems like it should be 
fairly easy configure builds to do "send email to openssl-commits when builds 
on master fail"


 



Re: Travis in solid red mode again

2020-02-03 Thread Salz, Rich
>Oh, actually, maybe I'm wrong. Is it just Appveyor that posts failures
and not Travis?
  
Yes.  You need to config travis to mail failures, as I pointed out in my 
earlier message.




Re: fips mode and key management

2020-01-21 Thread Salz, Rich
>distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
more fitting than FIPS_MODE?
  

Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use 
OPENSSL_BUILDING_OPENSSL ...

There's no reason to use OSSL for internal macros.





Re: crypt(3)

2020-01-20 Thread Salz, Rich
  *   I meant “what default makes the most sense for the passwd command line 
application?”
  *   It was crypt which is deprecated.  Should it be BSD’s MD5?  One of the 
SHA2 based algorithms?  Or should it produce an error if no algorithm is 
selected?

If you change the default, then the program will work differently depending on 
whether or not no-deprecated is configured.  This means that developers who 
want to write portable scripts will find it difficult to do so. People who have 
existing scripts and get a system upgrade could find things broken in a really 
strange way. This is *not* the same as when the default digest mechanism 
changed, because it was still available.



FW: Coverity Scan: Analysis completed for OpenSSL-1.0.2

2020-01-03 Thread Salz, Rich
Someone should turn off 1.0.2 :)

On 1/2/20, 11:48 PM, "scan-ad...@coverity.com"  wrote:


Your request for analysis of OpenSSL-1.0.2 has been completed 
successfully.
The results are available at 
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRakUl6QyjujEohY7rPpoYUEOo3rtGjiQZqYPGgcjfkiXQ-3D-3D_19DGMz38yO7VfzGQuXkecdlEmzBoDG4v8Dvyanv-2F1I2lW0-2BZw7MZMuFrG0u27bOOxjy4p8-2F84zVh7dDZIZNmMsRKAX6NxkpAdv-2BDwIY-2FvlUX-2FkDt3qaNtfzW2FsKugnrtUYdN8FPN16BhlPQAKsnJcvvEMj-2Fb0c4tYaht8-2ByOH4JE66wyaq-2BVXPkmQLp8GqxY61EIKDPvbif6rmn-2Fj-2BuXx2h4n6K6oS9JMdL-2B5Ft-2FQGIOh64FWXD2sq0PHMNzo4k

Build ID: 286891

Analysis Summary:
   New defects found: 0
   Defects eliminated: 0





OTC membership?

2019-12-29 Thread Salz, Rich
The list of committers is at https://www.openssl.org/community/committers.html
The list of OMC members is at https://www.openssl.org/community/omc.html
Will there be a list of OTC members also in the community tab soon?  Or a mark 
in the committers table?




Re: Check NULL pointers or not...

2019-12-02 Thread Salz, Rich
  *   In a production environment, it is almost never appropriate to simply 
crash in an uncontrolled manner (i.e. dereferencing a NULL pointer).

Applications that want this can check parameters themselves before calling the 
function.

Saying “C arguments don’t hold” is only because it goes against your position :)
FILE *f = fopen(“/”, “w”);
fprintf(f, “hello world”);
Is a programming error.  No two ways about it. The C runtime doesn’t protect 
against that programming error.

The OpenSSL contract says things like “foo points to a {some type of object}”  
Except for the free routines – which was new in 1.1 – it says nothing about 
NULL.  (i2d/d2i also excepted)



Re: Check NULL pointers or not...

2019-12-02 Thread Salz, Rich
if (!ossl_assert(ptr != NULL)) {
ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}

If the project decides to do this, I would like a configure option to ONLY turn 
on ossl_assert so that previous behavior can be restored without debug code 
penalties.



Re: Malloc failures check

2019-11-21 Thread Salz, Rich
  *   It would be possible to implement a malloc failure feature in the test 
suite that systematically runs a test many times, failing successive malloc 
calls.

It’s there; look crypto/mem.c, shouldfail() and FAILTEST.

More detail, from off-list discusson:

i=0
while : ; do
   ((i++))
   export MALLOC_FAILURE_CHECKS=${i}@100 openssl foo etc…
   test -f core && echo crashed && exit 1
 done




Re: Malloc failures check

2019-11-21 Thread Salz, Rich
  *   It would be possible to implement a malloc failure feature in the test 
suite that systematically runs a test many times, failing successive malloc 
calls.

It’s there; look crypto/mem.c, shouldfail() and FAILTEST.




Re: #10388

2019-11-14 Thread Salz, Rich
>I’m more concerned about adding these to 3.0.  It means we’ll have to support 
>the new API for a long time and it is one which we are currently trying to 
>move away from.

Will you?  Have you already decided that 3.0 is an LTS release?  Otherwise, you 
have the LTS burden and when the rest of ENGINE goes away, this does as well.


Re: Confirmed bug labels

2019-10-29 Thread Salz, Rich
What about "proposed bug" "proposed feature" etc.  And a single "accepted" 
label?
 



FW: Interview participation request

2019-10-21 Thread Salz, Rich
Folks,

I did a Skype call with James.  You might want to let him talk to you so that 
it’s more than just my view :)

It was fun.  He’s done a lot of number-crunching of OpenSSL through the years, 
including things like complexity (depth of nesting) and such.

Maybe you can do a group-chat during your F2F?  At any rate I encourage you to 
talk with him.


From: James Walden 
Date: Monday, October 21, 2019 at 2:58 PM
To: Rich Salz 
Subject: Interview participation request


I am writing to ask if you would agree to be interviewed online for a research 
project titled "The Evolution of OpenSSL after Heartbleed." This study aims to 
identify software engineering practices and technologies that have helped 
project members improve the security and quality of OpenSSL code in the five 
years since the discovery of the Heartbleed vulnerability.

If you agree to participate, I will interview you for an hour or less via an 
audio conferencing tool, such as Skype. During the interview, I will ask 
questions about your role in the project and about project activities, such as 
code review of potential commits. Interviewees may participate anonymously or 
give permission to be quoted in the resulting paper. All participants will be 
given an opportunity to review the research paper for correctness prior to 
publication.

Can I contact you to set up a time for an interview?

Thank you for your consideration,

James Walden, Ph.D.
Department of Computer Science
Northern Kentucky University
Highland Heights, KY 41099
email: walde...@nku.edu
phone: 859-572-5571
web: 
https://faculty.cs.nku.edu/~waldenj/
James Walden, Ph.D. - 
faculty.cs.nku.edu
Research: Secure Software Engineering, Security Metrics, Web Application 
Security, Machine Learning and Software Engineering
faculty.cs.nku.edu




UK or US spelling in manages?

2019-10-03 Thread Salz, Rich
OpenSSL is in the final stages of a *massive* cleanup of the manpages. Many of 
them are nit-level things, bringing them into conformance with common style, as 
expressed at http://man7.org/linux/man-pages/man7/man-pages.7.html

There is on notable difference: openssl uses a mix of UK and US spelling – 
favouring initialize and such instead of favoring initialize and such. Most 
manpages, and the link above, recommend US spelling. You can see the start of a 
discussion on this at https://github.com/openssl/openssl/pull/10079  While I 
respect the Commonwealth’s impact on SSLeay and OpenSSL :), I believe the right 
thing is to follow US style as everyone else does.

I am asking the OMC to discuss, decide, and vote on a policy.




Re: RAND, FIPS and providers

2019-09-24 Thread Salz, Rich
FWIW, I agree with Matt's points.




Re: Thread sanitiser problems

2019-07-30 Thread Salz, Rich
Do you need to hold the lock across dependant items? For example, why can't the 
DRBG code unlock before fetching the AES-CTR code?





Re: Do we really want to have the legacy provider as opt-in only?

2019-07-17 Thread Salz, Rich
>  If DSA is almost never used, why enable it by default?

I am amused/bemused that, after years of saying we do not know what people are 
doing with OpenSSL, it now is now becoming common practice to blithely assert 
"this is not used" when it fits the personal viewpoint of some folks.




Re: Do we really want to have the legacy provider as opt-in only?

2019-07-15 Thread Salz, Rich
>>DSA
> 
> What is the cryptographic weakness of DSA that you are avoiding?

It's a good question. I don't recall the specific reason why that was added 
to
the list. Perhaps others can comment.

The only weakness I know about is that if you re-use the nonce, the private key 
is leaked. It's more brittle than RSA-PKCS, but not as flawed as RC4.

I think this should be removed from the "legacy" list unless someone can point 
out why it's like the others in the list.




Re: Do we really want to have the legacy provider as opt-in only?

2019-07-15 Thread Salz, Rich

>DSA

What is the cryptographic weakness of DSA that you are avoiding?

 



Re: punycode licensing

2019-07-10 Thread Salz, Rich
I will take the hint and stop commenting on this thread.


Re: punycode licensing

2019-07-10 Thread Salz, Rich
Thank you for the reply.

>The license under which the OpenSSL software is provided does not require 
>"permission" to be sought for use of the software.
See 
https://www.openssl.org/source/apache-license-2.0.txt

Use, as defined by the license, doesn’t just mean end-users, and it is not 
limited to compiling, linking, and running executables.  A recipient can make 
derivative items, redistribute, and so on. All of those things are what OpenSSL 
would do if it “took in” code into the source base.

So why does the project require permission from other Apache-licensed licensed 
software? In other words, why will the project not accept and use the rights, 
covered by copyright and license, that it grants to others?



Re: punycode licensing

2019-07-10 Thread Salz, Rich
Thank you for the update. This brings to mind a few additional questions:


  1.  Does other code which is copyright/licensed under the Apache 2 license 
also require CLAs?
  2.  Does other code which is in the public domain also require CLAs?
  3.  Does OpenSSL expect that anyone using OpenSSL and bundling it with Apache 
2 software must first ask the project for permission?
  4.  Assuming #1 is yes and #3 is no, can you explain why there is a 
difference?




Re: punycode licensing

2019-06-24 Thread Salz, Rich
  *   Unfortunately, the issue isn't the compatibility of the license - they do 
indeed look relatively compatible to me - and the discussion on this thread has 
so far been about that.
  *   However the contributor license agreement requires that the copyright 
owner grants such permission - it is the fundamental basis of contributor 
agreements.

Yes, compatibility is important. CLA’s are required only for new code 
contributed to the project, not for code incorporated from elsewhere.  So if 
it’s compatible, CLA’s are not required.

At least, that was the position of the project and its former counsel during 
the first two years of relicensing.  Perhaps the OMC should raise this issue 
with current counsel if they disagree, but from the public statements on this 
list, it seems all but one agree.

As an aside, I’ve contacted the author and am having a productive exchange.  
Dimitry has seen the emails.



Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Salz, Rich
>So basically, what you're actually saying is that we should add
additional errors up the call stack...  so if some function called
OPENSSL_zalloc(), it should be perfectly OK to raise a
ERR_R_MALLOC_FAILURE, but functions above should *add* things like
WHATEVER_R_KEY_CREATE_FAILURE, etc etc etc, thereby creating that
backtrace that Tim talks about.
  
Yes.

BUT AGAIN, that's a separate issue to the main thread of function names in 
errors. Because, as you point out in the second paragraph (which I did not 
repost), there are still many issues to resolve with that.




Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Salz, Rich
>The proper way to handle this, in my experience, is *DO NOT REUSE ERROR 
> CODES.* Each error code appears in exactly one place, and we could eventually 
> build up documentation explaining what they mean, the causes, and how to 
> address this. This means, we don't use ERR_R_MALLOC when trying to create an 
> RSA key, for example, but rather a handful of new errors for 
> ERR_R_RSA_CANT_CREATE_D, ...CANT_CREATE_N, etc.  That is a big job, albeit 
> mostly a tedious one.
 
I got some feedback on- and off-list about this. Most of it was "surely you 
can't be serious."  I am, and stop calling me Shirley. :) Let me add some 
details.  First, recall that OpenSSL has an error stack, and that as errors are 
"unwound" each function can add its own error code to that stack. This 
naturally leads to the point where the first entry has the most detailed error, 
"malloc failed" and the last entry has the most application-oriented error 
"Could not create RSA key"; along the way are "Could not create d" and "Could 
not create secure bignum" errors.  I hope that makes more sense.

HOWEVER, this point (which got the most comments) was a side-note to the main 
point of my email, which gave some reasons why I think including the function 
code is a bad idea.

Hope this helps.





Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Salz, Rich
I think exposing the function internals is a mistake for a couple of reasons: 
it encourages familiarity with, and dependence on, OpenSSL library internals, 
and it goes against the spirit of layering, and there is no guarantee that the 
function code does not change as internal code gets moved around (refactored, 
removed, etc).

We have the source filename and line number available, although this has the 
some of the same drawbacks as function codes. It's just a little less ugly 
because C provides that data and we don't wedge it into the error code space.

The proper way to handle this, in my experience, is *DO NOT REUSE ERROR CODES.* 
Each error code appears in exactly one place, and we could eventually build up 
documentation explaining what they mean, the causes, and how to address this. 
This means, we don't use ERR_R_MALLOC when trying to create an RSA key, for 
example, but rather a handful of new errors for ERR_R_RSA_CANT_CREATE_D, 
...CANT_CREATE_N, etc.  That is a big job, albeit mostly a tedious one.





Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Salz, Rich

>The kernel actually already does this in recent versions, if
configured to do it.
  
"The" kernel. Which one is that?  Which operating system?

Modern Linux is fine.  Is that all we care about?

No issues were raised when the RSA keylength was increased, or MD5 was replaced 
with SHA1.  In fact, that is a very good example; we get many questions about 
"why can't I decrypt old text" because of this.  And here we got what, one 
posting?

1.1.1c made Solaris (and possibly others) more secure. I would be disappointed 
if 1.1.1d took that away and tried to rationalize that "it's not my job."  
*YOU'RE A CRYPTOGRAPHIC LIBRARY* 



Re: OSSL_PARAMs

2019-06-05 Thread Salz, Rich
  *   Is this workable or should something more significantly different be used 
before things freeze with the 3.0 release?

Well, since you asked: https://github.com/openssl/openssl/pull/8377



Re: OSSL_PARAMs

2019-06-04 Thread Salz, Rich

>Part of the idea was that this would be a means of communication
between application and provider, just like controls are with
libcrypto sub-systems.
  

I can probably find the email thread (or maybe it was a GitHub comment on my 
proposal for params), where you said, quite definitively, that this was *not* a 
general-purpose mechanism but rather a way to expose the necessary internals 
for opaque objects like RSA keys.

What changed your mind?

Perhaps not surprisingly, I agree with Shane's assessment and am strongly 
opposed to the project foisting this on everyone at this time.  @DavidBen, your 
thoughts?




Re: proposed change to committers policy

2019-05-24 Thread Salz, Rich
Nicely worded.  It doesn’t go as far as I’d like, but it’s a step.


Re: No two reviewers from same company

2019-05-24 Thread Salz, Rich
>   In that example the potential conflict of interest comes from the 
> individual's
employment with the third party organisation, not because they are fellows.
  
Do you disagree with my contention that the OMC represents the project, and not 
the fellows?

Regardless of where the conflict of interest comes from, the end result is the 
same, and I encourage the OMC to make the same policy for *its* employees that 
it does for other companies's employees.  Or perhaps this is a matter for the 
foundation to make for its employees.




Re: No two reviewers from same company

2019-05-23 Thread Salz, Rich
> In private email, and 
https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the 
implication is that this was a policy.

AFAIK this is not the case.

Is the comment wrong, either factually or because it is implementing something 
that isn't an official policy?

> In the case of the fellows, they
represent the project directly so there can be no conflict.
  
The OMC represents the project not individual fellows.  Fellows are employees 
of the OMC.  Therefore there can be conflicts. A hypothetical example, some 
hires a fellow or two to port OpenSSL to a new unique platform, not currently 
supported. The OMC doesn't want to support this platform, but it ends up in the 
source.

I encourage the OMC to consider this question carefully.




Re: No two reviewers from same company

2019-05-23 Thread Salz, Rich
> I understand that OpenSSL is changing things so that, by mechanism (and 
maybe by
> policy although it’s not published yet), two members of the same company 
cannot
> approve the same PR.  That’s great.  (I never approved Akamai requests 
unless it
> was trivial back when I was on the OMC.)

No such decision has been made as far as I know although it has been 
discussed
at various times.

In private email, and 
https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the 
implication is that this was a policy.

> Should this policy be extended to OpenSSL’s fellows?

IMO, no.

Why not?  I understand build process is always handled by Matt and Richard 
(despite many attempts in the past to expand this), but I think if Oracle or 
Akamai can't "force a change" then it seems to me that the OMC shouldn't either.




No two reviewers from same company

2019-05-23 Thread Salz, Rich
I understand that OpenSSL is changing things so that, by mechanism (and maybe 
by policy although it’s not published yet), two members of the same company 
cannot approve the same PR.  That’s great.  (I never approved Akamai requests 
unless it was trivial back when I was on the OMC.)

Should this policy be extended to OpenSSL’s fellows?



Re: Update

2019-05-22 Thread Salz, Rich
>>  I'd be opposed to this last option without IANA/IETF being on board. By 
doing so
>we are effectively no longer compliant with IETF TLS since we're using 
certain
>codepoints and version numbers to mean things that IETF/IANA have no 
visibility
>of, i.e. we would be doing exactly what Rich was worried about. I 
don't see
>IANA/IETF doing this anytime soon.
> 
> For the most part, getting IANA on board requires someone in authority 
email to tls-regis...@iana.org asking for code points and pointing to their 
spec.

’someone in authority’ here means the author of the spec who is asking for 
code points?


Yes.  Or someone involved with the spec.



Re: Update

2019-05-21 Thread Salz, Rich
 
 >   I'd be opposed to this last option without IANA/IETF being on board. By 
 > doing so
we are effectively no longer compliant with IETF TLS since we're using 
certain
codepoints and version numbers to mean things that IETF/IANA have no 
visibility
of, i.e. we would be doing exactly what Rich was worried about. I don't see
IANA/IETF doing this anytime soon.
   
For the most part, getting IANA on board requires someone in authority email to 
tls-regis...@iana.org asking for code points and pointing to their spec.



Re: Update

2019-05-20 Thread Salz, Rich
>I don't see it that way. As I understand it this is a completely different
protocol to standard TLS.

That's an interesting point, but ... they use the SSL "name."

> It is not intended to interoperate with it in any way.

Is that true?  I didn't look closely at the protocol changes, but maybe you're 
right.  On the other hand, if so, then why keep the existing IETF numbers?

>As a completely different protocol they can use whatever codepoints they 
> want to
use as they see fit - and there is no conflict with IETF specifications.
  
If you are correct, then yes I agree.  But that makes any OpenSSL integration 
that much harder, doesn't it?  Would the project take on the work of making 
things like the apps and tests work?  In particular, a new global flag saying 
"tnssl" (or such), and failing to interop with existing TLS, checking the 
modified cipher suites (and disallowing them for real TLS), etc.

 



Re: Update

2019-05-20 Thread Salz, Rich


  *   The current requirement for inclusion is “national 
standard”
 or better.  Thus, this change should be accepted.

The problem is that they squatted on codepoints that the IETF controls.  So 
while it is a national standard, it is also in conflict with the IETF 
specifications.


Re: SP 800-90C 10.1.2

2019-04-11 Thread Salz, Rich
No love from Akamai for this: it seems to be done for completionist reasons and 
it seems risky.

From: "paul.d...@oracle.com" 
Date: Tuesday, April 9, 2019 at 8:07 PM
To: "fips-spons...@openssl.org" 
Cc: "openssl-project@openssl.org" 
Subject: SP 800-90C 10.1.2

Do any of the FIPS sponsors or OpenSSL project people think that SP 800-90C 
section 10.1.2 “Accessing a Source DRBG with Prediction Resistance to Obtain 
any Security Strength” is worthwhile including in the code base?

The main use is to allow a stronger DRBG to be seeded from a weaker one.  For 
example: seeding AES-CTR-256-DRBG from AES-CTR-128-DRBG.  The reasons in favour 
don’t seem very compelling:

  *   There are some obscure use cases for which there is a fairly easy work 
around (use stronger DRBGs everywhere).
  *   A low quality hardware source could be used for higher strength 
applications.
  *   It would also provide some benefit for poorly set up DRBG chains.
  *   It can be used to construct randomness of any strength but I’m not aware 
of a current method to compress this down to high quality entropy that is 
directly usable (i.e. preserves the strength).

The PR is done (#8660 
https://github.com/openssl/openssl/pull/8660)
 but I’ve closed it since it seems unloved.  If anyone here does think that 
that would beneficial, say something as justification or it is gone.


Pauli
--
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia



Re: [openssl-project] OpenSSL 3.0 and FIPS Update

2019-02-15 Thread Salz, Rich
>We won't be offering the service to add new platforms onto our own 
> certificate,
but you should be able perform your own validation for your own platforms 
based
on ours (I forget the correct FIPS term for this...perhaps someone more 
FIPSy
than I am can chip in).
  
Vendor-affirmed.  If you follow the documented build procedure exactly, you can 
claim FIPS validation.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Fractional seconds, etc.

2018-08-14 Thread Salz, Rich
I mean keep the *previous* behavior.

On 8/14/18, 9:25 AM, "Salz, Rich"  wrote:

>This seems to have been done in both the 1.0.2 and 1.1.0 after the
release. Do you want to revert it in both branches, but keep it in
1.1.1? Or only revert it in 1.0.2?
  
Keep the existing behavior for 1.0.2, 1.1.0 and 1.1.1.  Sadly.  And fix in 
a future release (I would re-open the PR and tag it)


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Fractional seconds, etc.

2018-08-14 Thread Salz, Rich
>This seems to have been done in both the 1.0.2 and 1.1.0 after the
release. Do you want to revert it in both branches, but keep it in
1.1.1? Or only revert it in 1.0.2?
  
Keep the existing behavior for 1.0.2, 1.1.0 and 1.1.1.  Sadly.  And fix in a 
future release (I would re-open the PR and tag it)


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] Fractional seconds, etc.

2018-08-14 Thread Salz, Rich
I think we should revert https://github.com/openssl/openssl/pull/2668

The stricter RFC compliance turns out to impact many certs embedded in devices. 
 Some estimates had thousands to millions.  It affects interop with IAIK and 
Bouncy Castle.

I looked at the code, and tried to figure out how to just relax the fractional 
second code, but it wasn’t obvious. There is also a testcase that would need to 
be modified. And finally, it’s not clear that the seconds are the only 
compatibility issue we would be introducing.

Unfortunately, this turns out to be a big breaking change, and doesn’t seem 
right for a dot release.

Anyone feel otherwise?
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Releases tomorrow

2018-08-13 Thread Salz, Rich
>- "Updates for RFC8446 (the final TLSv1.3 version)" (PR 6741) needs to
be merged. I have the required approval, just giving Rich some time to
see if he has any further comments.

Thanks, I'm good.

>- If we're going to make any changes for issue 6904 (broken pipe for
clients that only write/server that only reads), then we should do that

Yeah, I don't like the library messing with signals tho.

 

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] FW: Certificate fractional time processing in upcoming openssl releases

2018-08-11 Thread Salz, Rich
FYI.  Quietly ignoring fractional seconds makes sense to me.

From: David McGrew 
Date: Saturday, August 11, 2018 at 9:45 AM
To: Rich Salz , "Barry Fussell (bfussell)" 

Cc: "Marty Loy (mloyjr)" , "Jonathan Felten (jfelten)" 
, "Bill Sulzen (bsulzen)" 
bsul...@cisco.com<mailto:bsul...@cisco.com>
Subject: Re: Certificate fractional time processing in upcoming openssl releases

Hi Barry and Rich,

Thanks for this.   I think that having the rejection of fractional seconds be 
part of the “—strict” option makes sense.

As I understand it, there are fielded certs with fractional seconds in 
GeneralizedTime, which violates the RFC5280 profile but doesn’t introduce any 
vulnerability.   That RFC aims to promote interoperability by making a profile 
of X509 formats and semantics, and fractional seconds is only formatting, and 
not semantics.   So it seems counter to the spirit of the RFC to prevent 
openSSL from being able to interoperate with certs issued by IAIK or whatever 
noncompliant systems.

Thanks,

David

From: "Salz, Rich" mailto:rs...@akamai.com>>
Date: Friday, August 10, 2018 at 12:24 PM
To: "Barry Fussell (bfussell)" mailto:bfuss...@cisco.com>>
Cc: "Marty Loy (mloyjr)" mailto:mlo...@cisco.com>>, "Jonathan 
Felten (jfelten)" mailto:jfel...@cisco.com>>, mcgrew 
mailto:mcg...@cisco.com>>, "Bill Sulzen (bsulzen)" 
mailto:bsul...@cisco.com>>
Subject: Re: Certificate fractional time processing in upcoming openssl releases

Please post to openssl-project@openssl.org<mailto:openssl-project@openssl.org>  
It’s a moderated list, but the posting will get approved very quickly.


From: "Barry Fussell (bfussell)" mailto:bfuss...@cisco.com>>
Date: Friday, August 10, 2018 at 9:34 AM
To: Rich Salz mailto:rs...@akamai.com>>
Cc: "Marty Loy (mloyjr)" mailto:mlo...@cisco.com>>, "Jonathan 
Felten (jfelten)" mailto:jfel...@cisco.com>>, David McGrew 
mailto:mcg...@cisco.com>>, "Bill Sulzen (bsulzen)" 
mailto:bsul...@cisco.com>>
Subject: Certificate fractional time processing in upcoming openssl releases

Rich,

My team was recently made aware of a change in the time comparison
logic in openssl to adhere to RFC5280 requirements . This change will be in
the upcoming 1.0.2p and 1.1.0i releases. We’ve had discussions regarding
the impact to legacy devices in the field and feel the change could be
detrimental if enabled by default.

We've seen fractional time used in many cases, for example the IAIK
crypto library generated fractional times for quite a while. I believe the
issue with the IAIK library has been fixed, but products still have those certs
embedded in them today.

In reading the discussion linked below it seems the only impetus for
this change was to meet RFC5280, not that allowing fractional times
was any specific vulnerability.

https://github.com/openssl/openssl/issues/2620<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_2620=DwMFAg=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=Lwc9LOtfM8pc8gkaABxWdUutvh8gwoL2KvhYe2d4y3Q=7DMTtQYOol3SGlQwP-5nyNTMX8ulbcaYRt5_PF8ol7g=>

Is there any option for this going forward, removal, compile-time
enabled or part of the strict checks ?

Thanks !

Barry Fussell



[http://www.cisco.com/web/europe/images/email/signature/tomorrow_anthem_H.png]



Barry Fussell
Technical Leader
Security & Trust Organization
bfuss...@cisco.com<mailto:bfuss...@cisco.com>
Phone: +1 919 392 2920

Cisco Systems, Inc.
7025-2 Kit Creek Road
Research Triangle Park, NC 27709
United States
Cisco.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cisco.com_=DwMFAg=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=Lwc9LOtfM8pc8gkaABxWdUutvh8gwoL2KvhYe2d4y3Q=jiXJrK_CCjJLudysdejd12bdgw7_tY1mj_o-AtgDeLw=>




[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you 
print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cisco.com_web_about_doing-5Fbusiness_legal_cri_index.html=DwMFAg=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=Lwc9LOtfM8pc8gkaABxWdUutvh8gwoL2KvhYe2d4y3Q=gfKgERtaAUVlAA0GHdXitfmhgtPbojPDaeFPm99y5SU=>
 for Company Registration Information.






___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] TLS 1.3 and the release

2018-08-11 Thread Salz, Rich
You probably know by now that TLS 1.3 was just released as RFC 8446; 
https://www.rfc-editor.org/info/rfc8446
  This note is just trying to forestall a number of question threads.

Our release plan called for one final beta (there were various draft-interop 
things to take out and some other little nits) and then the official release. 
We have had no discussion of changing that plan.

Matt has already prepared a PR (the number escapes me), and there are a couple 
of open issues we still have to resolve. If all goes well, however, the final 
beta should begin very soon.

Thanks to everyone in the OpenSSL community for your help and support!



___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Salz, Rich
>Whether one's for them, or against them, removing a check
from a function that would formerly return an error and
making it crash is a substantial API change. 

I don't disagree.
 

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3

2018-08-09 Thread Salz, Rich
>"We should remove the TLSv1.2 to TLSv1.3 PSK compatibility mechanism as
discussed in issue 6490. If TLSv1.2 PSKs are configured (and not TLSv1.3
PSKs) then we should disable TLSv1.3."
  

This seems reasonable to me, albeit a bit wordy since you could delete the 
first sentence. :)

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Salz, Rich
>it's NULL. Now imagine that this stack was some kind of deny list. If
>entry producer didn't pay attention to error when creating stack and
>putting things into it, consumer would be led to belief that there is
>nothing to deny and let through the requests that are supposed to be
>denied.

This is another reason why I am opposed to NULL checks.

>Oh! Triggering factor was quite a number of unchecked pushes in apps.

Real code often doesn't check return values.  Even ours. :(

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
 sudo cpan Carp::Always

I did this.  Same results for config and the PERLOPT setting.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] master is broken?

2018-07-24 Thread Salz, Rich


On 7/24/18, 1:42 PM, "Richard Levitte"  wrote:

Would you mind installing it?  The package is called
libcarp-always-perl on Debian and derivates, and if my RPM search fu
isn't entirely off, the corresponding RPM package is perl-Carp-Always

Or install with cpan...

Okay.  Does this add a new dependency for openssl?  Maybe reconsider the 
approach --  Things seemed acceptable before the latest change.  Or maybe print 
STDERR ?

; sudo cpan install perl-Carp-Always
Loading internal null logger. Install Log::Log4perl for logging messages
CPAN: Storable loaded ok (v2.41)
Reading '/home/rsalz/.cpan/Metadata'
  Database was generated on Tue, 24 Jul 2018 17:17:02 GMT
;

No what?  Running "./config -d" still gives the same error message output and 
this:
; PERL5OPT=-MCarp::Always ./config
Operating system: x86_64-whatever-linux2
Can't locate Carp/Always.pm in @INC (you may need to install the Carp::Always 
module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 
/usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 
/usr/share/perl/5.18 /usr/local/lib/site_perl .).
BEGIN failed--compilation aborted.
You need Perl 5.
exit 1
;




___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
; env | grep PERL
; PERL5OPT=-MCarp::Always ./config
Operating system: x86_64-whatever-linux2
Can't locate Carp/Always.pm in @INC (you may need to install the Carp::Always 
module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 
/usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 
/usr/share/perl/5.18 /usr/local/lib/site_perl .).
BEGIN failed--compilation aborted.
You need Perl 5.
exit 1
; perl -v 

This is perl 5, version 18, subversion 2 (v5.18.2) built for 
x86_64-linux-gnu-thread-multi
(with 52 registered patches, see perl -V for more detail)

Copyright 1987-2013, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

;

On 7/24/18, 1:33 PM, "Richard Levitte"  wrote:

PERL5OPT=-MCarp::Always ./config

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
; g status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
; g pull
Current branch master is up to date.
;

; ./config
Operating system: x86_64-whatever-linux2
Configuring OpenSSL version 1.1.1-pre9-dev (0x10101009L) for linux-x86_64
Using os-specific seed configuration

Failure!  build file wasn't produced.
Please read INSTALL and associated NOTES files.  You may also have to look over
your available compiler tool chain or change your configuration.


Failure!  build file wasn't produced.
Please read INSTALL and associated NOTES files.  You may also have to look over
your available compiler tool chain or change your configuration.


Failure!  build file wasn't produced.
Please read INSTALL and associated NOTES files.  You may also have to look over
your available compiler tool chain or change your configuration.

Creating configdata.pm
Creating Makefile

**
******
***   If you want to report a building issue, please include the   ***
***   output from this command:***
******
*** perl configdata.pm --dump  ***
******
**
;
; perl configdata.pm --dump

Command line (with current working directory = .):

/usr/bin/perl ./Configure linux-x86_64

Perl information:

/usr/bin/perl
5.18.2 for x86_64-linux-gnu-thread-multi

Enabled features:

aria
asm
async
autoalginit
autoerrinit
autoload-config
bf
blake2
camellia
capieng
cast
chacha
cmac
cms
comp
ct
deprecated
des
dgram
dh
dsa
dso
dtls
dynamic-engine
ec
ec2m
ecdh
ecdsa
engine
err
filenames
gost
hw(-.+)?
idea
makedepend
md4
mdc2
multiblock
nextprotoneg
ocb
ocsp
pic
poly1305
posix-io
psk
rc2
rc4
rdrand
rfc3779
rmd160
scrypt
seed
shared
siphash
sm2
sm3
sm4
sock
srp
srtp
sse2
ssl
static-engine
stdio
tests
threads
tls
ts
ui-console
whirlpool
tls1
tls1-method
tls1_1
tls1_1-method
tls1_2
tls1_2-method
tls1_3
dtls1
dtls1-method
dtls1_2
dtls1_2-method

Disabled features:

afalgeng[too-old-kernel]
asan[default]OPENSSL_NO_ASAN
crypto-mdebug   [default]OPENSSL_NO_CRYPTO_MDEBUG
crypto-mdebug-backtrace [default]OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
devcryptoeng[default]OPENSSL_NO_DEVCRYPTOENG
ec_nistp_64_gcc_128 [default]OPENSSL_NO_EC_NISTP_64_GCC_128
egd [default]OPENSSL_NO_EGD
external-tests  [default]OPENSSL_NO_EXTERNAL_TESTS
fuzz-libfuzzer  [default]OPENSSL_NO_FUZZ_LIBFUZZER
fuzz-afl[default]OPENSSL_NO_FUZZ_AFL
heartbeats  [default]OPENSSL_NO_HEARTBEATS
md2 [default]OPENSSL_NO_MD2 (skip crypto/md2)
msan[default]OPENSSL_NO_MSAN
rc5 [default]OPENSSL_NO_RC5 (skip crypto/rc5)
sctp[default]OPENSSL_NO_SCTP
ssl-trace   [default]OPENSSL_NO_SSL_TRACE
tls13downgrade  [default]OPENSSL_NO_TLS13DOWNGRADE
ubsan   [default]OPENSSL_NO_UBSAN
unit-test   [default]OPENSSL_NO_UNIT_TEST
weak-ssl-ciphers[default]OPENSSL_NO_WEAK_SSL_CIPHERS
zlib[default]
zlib-dynamic[default]
ssl3[default]OPENSSL_NO_SSL3
ssl3-method [default]OPENSSL_NO_SSL3_METHOD

Config target attributes:

AR => "ar",
ARFLAGS => "r",
CC => "gcc",
CFLAGS => "-Wall -O3",
CXX => "g++",
CXXFLAGS => "-Wall -O3",
HASHBANGPERL => "/usr/bin/env perl",
RANLIB => "ranlib",
RC => "windres",
aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s aesni-x86_64.s 
aesni-sha1-x86_64.s aesni-sha256-x86_64.s aesni-mb-x86_64.s",
aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o 
aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o",
apps_aux_src => "",
apps_init_src => "",
apps_obj => "",
bf_asm_src => "bf_enc.c",
bf_obj => "bf_enc.o",
bn_asm_src => "asm/x86_64-gcc.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s 
rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
bn_obj => "asm/x86_64-gcc.o x86_64-mont.o 

[openssl-project] Taking a break

2018-07-20 Thread Salz, Rich
I am going to take a break from most of OpenSSL governance for the rest of the 
month.  As I have been mostly the person handling all those other things, and 
as I am usually very very quick with email, I thought the project should know. 
I’m not going anywhere, it’s really just like the first sentence says.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Finishing up this release

2018-07-12 Thread Salz, Rich
We’re close to finishing the 1.1.1 release.  As we’ve said before, this is our 
next LTS release which means it will be supported for five years.

There are a few things we still need to do and we’re encouraging the community 
to help.  These include:

Address all the “1.1.1” open issues, found at 
https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.1.1
  Any input or advice is appreciated; particularly for issues reported by (or 
against) other projects.

No open 1.1.1 PR’s that are more than two weeks old.  If an issue or a PR 
affects other releases, then it can wait. You can see the PR’s at 
https://github.com/openssl/openssl/pulls, and adding feedback or code-review or 
other comments (particularly to the recent ones) will help.

No open Coverity issues.  You can find the public scan reports at 
https://scan.coverity.com/projects/openssl (you have to register first, we’ll 
approve anyone).  A PR to address issues, or an email pointing out which are 
false positives can help.

Clean builds in travis, Appveyor, and our run-checker script.  We are doing 
well with this.

We are planning on doing one last beta after the TLS 1.3 RFC is published.  
There is little anyone can do about that, except to wait.

Thanks.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Milestones and the 1.1.1 release

2018-07-02 Thread Salz, Rich
Thanks for finishing this off.


https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.1.1

Are 6512 and 6396 the same, and closed because we made things more secure?

Is 6342 a python bug, they'll need to upgrade?

Is 6228 a foolscap issue?

I think we can close 6221 soon.

I will make a PR for 5037.



___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] FW: [openssl-commits] Build failed in Jenkins: master_noec #574

2018-06-26 Thread Salz, Rich
FYI

On 6/26/18, 2:45 PM, "Barry Fussell (bfussell)"  wrote:

The evp_test is failing intermittently because there is an attempt to
malloc zero bytes when running the new test that came in with
this commit.


https://bitbucket-eng-rtp1.cisco.com/bitbucket/projects/TS/repos/ciscossl/commits/7b3e775a6a78650bbd3e8e19a5aa12981880402b#test/evptests.txt


static int pderive_test_run(struct evp_test *t)
{
struct pkey_data *kdata = t->data;
unsigned char *out = NULL;
size_t out_len;
const char *err = "INTERNAL_ERROR";

out_len = kdata->output_len;
out = OPENSSL_malloc(out_len);  <- out is zero because there is no 
SharedSecret
if (!out) {

-Original Message-
From: osslsan...@gmail.com [mailto:osslsan...@gmail.com] 
Sent: Tuesday, June 19, 2018 11:28 AM
To: Barry Fussell (bfussell) ; 
openssl-comm...@openssl.org
Subject: Build failed in Jenkins: master_noec #574

See 


Changes:

[Matthias.St.Pierre] Fix & update documentation about RAND_priv_bytes()

[Matthias.St.Pierre] Improve the output of `make doc-nits`

--
[...truncated 505.72 KB...]
rm -f test/v3ext
${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.   \
-o test/v3ext test/v3ext.o \
 test/libtestutil.a -lcrypto -ldl -pthread gcc  -Iinclude 
-pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG  -MMD -MF 
test/v3nametest.d.tmp -MT test/v3nametest.o -c -o test/v3nametest.o 
test/v3nametest.c rm -f test/v3nametest
${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.   \
-o test/v3nametest test/v3nametest.o \
 test/libtestutil.a -lcrypto -ldl -pthread gcc  -Iinclude 
-pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG  -MMD -MF 
test/verify_extra_test.d.tmp -MT test/verify_extra_test.o -c -o 
test/verify_extra_test.o test/verify_extra_test.c rm -f test/verify_extra_test
${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.   \
-o test/verify_extra_test test/verify_extra_test.o \
 test/libtestutil.a -lcrypto -ldl -pthread gcc  -Iinclude 
-pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG  -MMD -MF 
test/versions.d.tmp -MT test/versions.o -c -o test/versions.o test/versions.c 
rm -f test/versions
${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.   \
-o test/versions test/versions.o \
 -lcrypto -ldl -pthread
gcc  -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG  -MMD -MF 
test/wpackettest.d.tmp -MT test/wpackettest.o -c -o test/wpackettest.o 
test/wpackettest.c rm -f test/wpackettest
${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.   \
-o test/wpackettest test/wpackettest.o \
 libssl.a test/libtestutil.a -lcrypto -ldl -pthread gcc  
-Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG  -MMD -MF 
test/x509_check_cert_pkey_test.d.tmp -MT test/x509_check_cert_pkey_test.o -c -o 
test/x509_check_cert_pkey_test.o test/x509_check_cert_pkey_test.c rm -f 
test/x509_check_cert_pkey_test
${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.   \
-o test/x509_check_cert_pkey_test 
test/x509_check_cert_pkey_test.o \
 test/libtestutil.a -lcrypto -ldl -pthread gcc  -Iinclude 
-pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG  -MMD -MF 
test/x509_dup_cert_test.d.tmp -MT test/x509_dup_cert_test.o -c -o 
test/x509_dup_cert_test.o test/x509_dup_cert_test.c rm -f 
test/x509_dup_cert_test
${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.   \
-o test/x509_dup_cert_test test/x509_dup_cert_test.o \
 test/libtestutil.a -lcrypto -ldl -pthread gcc  -I. -Iinclude 
-pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG  -MMD -MF 
test/x509_internal_test.d.tmp -MT test/x509_internal_test.o -c -o 
test/x509_internal_test.o test/x509_internal_test.c rm -f 
test/x509_internal_test
${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.   \
-o test/x509_internal_test test/x509_internal_test.o \
 test/libtestutil.a libcrypto.a -ldl -pthread gcc  -Iinclude 
-pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG  -MMD -MF 
test/x509_time_test.d.tmp -MT test/x509_time_test.o -c -o test/x509_time_test.o 
test/x509_time_test.c rm -f test/x509_time_test
${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.   \
-o test/x509_time_test test/x509_time_test.o \
 test/libtestutil.a -lcrypto -ldl -pthread gcc  -Iinclude 
-pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG  -MMD -MF test/x509aux.d.tmp 
-MT test/x509aux.o -c -o test/x509aux.o test/x509aux.c rm -f test/x509aux

[openssl-project] GitHub labels

2018-06-20 Thread Salz, Rich
I think it’s a good idea that we periodically review the labels we’re using.  
Please look at https://github.com/openssl/openssl/labels and maybe suggest 
changes.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Beta release today

2018-06-19 Thread Salz, Rich
>It would still be good if someone can freeze the repo though please:

ssh openssl-...@git.openssl.org freeze openssl matt
  
I will do this tonight, eastern time.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
>Except that, because of the way PKCS12_gen_mac() works, this isn't
true.  If the input pass phrase looks like a UTF-8 encoded string
(because there are valid characters in other encodings that will like
like UTF-8 byte sequences), it will be used as if -passutf8 was given
instead.
  
Well, at least I started down the path.  I wonder if one of those flags should 
set the keygen to asc?

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
>I have zero idea what the doc says, because I haven't seen the docs
yet.  Did I miss the PR?
  
No.  It's posted here on the mailing list for discussion and reposted here:


+=item B<-passutf8>, B<-pass8bit>
+
+These flags indicate the character set encoding on the password value.
+By default, non-ASCII characters are rejected. This is new behavior
+with OpenSSL 1.1.1,
+and is used to enforce compliance with the PKCS#12 standard.
+If B<-passutf8> is given, then the password is taken to be valid UTF-8 
encoding,
+and will be used directly.
+If B<-pass8bit> is given, the password is taken to be encoded in the current
+locale, but is still used directly; note that
+a future release might automatically convert the password to valid UTF-8
+encoding if this flag is given.
+


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
>However, what's going to happen is that PKCS12_gen_mac() will generate
this for a BMPString:
  
Which is what we do now, right?

And the docs for this *new flag* explain that the behavior could change in the 
future.

To be "pass8bit" means "pass 8bit bytes through to lower layer"  But if we want 
to bikeshed about the name of the flag, fine.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] [openssl-omc] stepping down from OMC

2018-06-11 Thread Salz, Rich
  *   I'm leaving the project.

https://www.youtube.com/watch?v=YtsZoIe3Czk

You have a great deal to be proud of, and OpenSSL is much better for the time 
you spent here.  We will miss you.  I will miss you.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
> If B<-pass8bit> is given, the password is taken to be encoded in the 
current
> locale, but is still used directly.
> A future release might automatically convert the password to valid UTF-8
> encoding if this flag is given.

I would propose that "-pass8bit" means that each byte of the input is
a unicode code point value (i.e. ASCII or LATIN1 supplement) and we'll
convert to UCS-2 by prepending 0x00 to each one.  If so, I would expect
this flag to NOT ever change its meaning.

I don't see the point of this.

My goal, with the two flags, was to allow users to make explicit what they 
want, and to warn them that *one* of the cases might/will change in the future.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
Here is proposed documentation for what I am suggesting.

=item B<-passutf8>, B<-pass8bit>

These flags indicate the character set encoding on the password value.
By default, non-ASCII characters are rejected. This is new to OpenSSL 1.1.1,
and is used to enforce complains with the PKCS#12 standard.
If B<-passutf8> is given, then the password is taken to be valid UTF-8 encoding,
and will be used directly.
If B<-pass8bit> is given, the password is taken to be encoded in the current
locale, but is still used directly.
A future release might automatically convert the password to valid UTF-8
encoding if this flag is given.


On 6/7/18, 3:42 PM, "Salz, Rich"  wrote:

>So even rejecting correctly encoded utf-8?
  
I think you forgot that this is not what I suggested.  One flag indicates 
it's utf-8 encoded, don't touch it.  The other flag indicates it might have 
high-bit chars, don't touch it.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
>So even rejecting correctly encoded utf-8?
  
I think you forgot that this is not what I suggested.  One flag indicates it's 
utf-8 encoded, don't touch it.  The other flag indicates it might have high-bit 
chars, don't touch it.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
>My main concern is that currently, openssl pkcs12 may create broken pkcs12 
> files (because it misinterprets the pass phrase when constructing a 
> BMPString), and doesn't notify the user at all (doesn't even check). 
 

For those who haven't reada the PR and all its comments, I propose that we 
reject non-ASCII input unless one of two flags is set.  This prevents us from 
unknowingly making the situation worse, and does not break interop with our 
installed base.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
>We don't have to answer the question "how high" now.  I'm fully
prepared to have the use of iconv limited to platforms where we know
it's available

That then means that the pkcs12 program is not compatible in behavior across 
platforms.  This would be a first, for us.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
>Taking off on a bit of a tangent, how much justification did we go
through when adding pthreads as a dependency.

It's an optional, but enabled by default, dependency which is different.

We had a lot of discussion within what was then openssl-team.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
I see you already started the votes.  No time for discussion?

I think OpenSSL should be a "fundamental" system library.  Perhaps the apps are 
different, but it should not require new libraries but could use them if 
available -- either at run-time or via config/build.

I think iconv in particular is a bad thing to require at this time, in a 1.1.1 
release.  It's not clear to me that it meets our API/ABI compatibility 
guarantee.  I also dislike iconv because of its size, the fact that it is a 
gross collection of hacks -- not its fault, it's the nature of charsets -- and 
that it is not universal.  This means that apps that "do the right thing" on 
some platforms, will FAIL to do so on opthers.

It is very very late in the release process to be adding a new dependency.

Finally, I believe that for this particular issue, we can add an API that 
enables applications to do the right thing, and we can add flags and warnings 
to the command-line that make it more clear when a user isn't doing the right 
thing (such as because they have existing files they need to read).

VOTE NO.

On 6/7/18, 8:04 AM, "Richard Levitte"  wrote:

Hi,

This PR has been blocked, forcing a vote:

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

Background: we have been sloppy when producing PKCS#12 files, creating
objects that aren't interoperable.  This can only happen with non-UTF8
input methods, so this PR adds a higher level of control in the
openssl application, so that it will do the best it can to make sure a
pass phrase encoded with something other than UTF-8 gets correctly
re-encoded, and failing that, try and make the user aware that they
are about to create a non-interoperable object.  This triggered the
use of the iconv API, and in the case of Mac OS/X, the use of the
separate libiconv library.

I'm going to make this into two votes, as both topics have come out
because of this.

1. A vote about general use of other libraries, limited to standard
   system libraries, which may be platform dependent (I expect
   libiconv on Mac OS/X to be such a library)

2. A vote about the use of the iconv API

Please discuss here, no in the vote threads.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Is Mac a supported platform?

2018-06-02 Thread Salz, Rich
https://github.com/openssl/openssl/pull/6404

On 6/1/18, 5:33 PM, "Richard Levitte"  wrote:

In message <1bd96940-3b3b-4758-938a-01e576306...@akamai.com> on Fri, 1 Jun 
2018 21:26:12 +0000, "Salz, Rich"  said:

rsalz> >Regarding the original question, it's "supported" insofar that 
we have
rsalz> osx among the Travis builds (at least usually...  there have been
rsalz> times when the osx backlog has been so great that we've 
temporarly
rsalz> disabled it).
rsalz>   
rsalz> So maybe I should just create a PR to update INSTALL with the Mac 
recipe?

I don't understand why.  In this regard, OS X is Unix.  In other
words, the quick recipe is what you already see in INSTALL:

$ ./config
$ make
$ make test
$ make install

Are you telling me that this isn't understood?

The only reason why VMS and Windows are mentioned specially, is that
the commands on those platforms are syntactically different.  Not so
for OS X.

But hey, if that helps, we can always do this:

diff --git a/INSTALL b/INSTALL
index 52e3f2ae6c..851093ec01 100644
--- a/INSTALL
+++ b/INSTALL
@@ -76,7 +76,7 @@
 
  If you want to just get on with it, do:
 
-  on Unix:
+  on Unix (including Mac OS/X):
 
 $ ./config
 $ make


Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Is Mac a supported platform?

2018-06-01 Thread Salz, Rich
>Regarding the original question, it's "supported" insofar that we have
osx among the Travis builds (at least usually...  there have been
times when the osx backlog has been so great that we've temporarly
disabled it).
  
So maybe I should just create a PR to update INSTALL with the Mac recipe?

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-01 Thread Salz, Rich
>I think that the gist of the difference of opinion is whether it's OK
to use locale dependent functions such as mbstowcs in libcrypto or
not.
  

Thanks for the summary.

I am against use locale-dependent functions in libcrypto. 

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Current votes FYI

2018-05-23 Thread Salz, Rich
Dang, you’re right.

I’ll re-run the vote.  But for now I reverted the website commit.

From: Tim Hudson <t...@cryptsoft.com>
Reply-To: "openssl-project@openssl.org" <openssl-project@openssl.org>
Date: Wednesday, May 23, 2018 at 5:00 PM
To: "openssl-project@openssl.org" <openssl-project@openssl.org>
Subject: Re: [openssl-project] Current votes FYI

No that vote does not pass. All votes require participation by a majority of 
active members. Failure to have a majority participation causes a vote to fail.

With only three out of eight members voting this vote simply did not pass.

Tim.

On Thu, 24 May 2018, 12:59 am Salz, Rich, 
<rs...@akamai.com<mailto:rs...@akamai.com>> wrote:
Another update

VOTE: Remove the second paragraph ("Binary compatibility...improve security")
from the release strategy.

 +1: 2
 0: 1
-1: 0
No vote: 5

The vote passed.


___
openssl-project mailing list
openssl-project@openssl.org<mailto:openssl-project@openssl.org>
https://mta.openssl.org/mailman/listinfo/openssl-project<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dproject=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=nzvJc3ymtWOe43oeRGdwI3GgaAQqIFFLzpsIxvWJ4Gc=xWgXumtW5Lnbf9inmYXMQFmVpApZyIIR8BuMkxRICZw=>
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] build/test before merging

2018-05-23 Thread Salz, Rich
>Unfortunately, I didn't have time to follow my vision yet. Also, it would 
> have been easier for me to do it in Python than in Perl.
  
+1 for python! :)

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] FW: [TLS] WGLC for draft-ietf-tls-tls13-vectors

2018-05-08 Thread Salz, Rich
Anyone want to take a look at wedging this into our test suite?

On 5/8/18, 12:31 PM, "Sean Turner"  wrote:

All,

This is the working group last call for the "Example Handshake Traces for 
TLS 1.3" draft available at 
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/.  Please review 
the document and send your comments to the list by 2359 UTC on 22 May 2018.

Thanks - J
___
TLS mailing list
t...@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Beta release on Tuesday

2018-04-30 Thread Salz, Rich
>Nobody else has stepped forward. Are you still available for this?
  
Sure.
  
>I would normally start around 12.00 UTC, but could push it a bit later
if it works better for you.
  
So that's 7am, it would be best to delay an hour.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Freezing the repo

2018-04-30 Thread Salz, Rich
Done.

On 4/30/18, 3:02 PM, "Matt Caswell"  wrote:

Please could someone freeze the repo for me for tomorrow's release:

$ ssh openssl-...@git.openssl.org freeze openssl matt


Thanks

Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Beta release on Tuesday

2018-04-27 Thread Salz, Rich
>As normal we are planning a new beta release on Tuesday. This means that
>we will be freezing the repo from Monday afternoon (UTC).
  
I'm in US but available if nobody "closer" can do it.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-19 Thread Salz, Rich
I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or 
something like that.

David has pointed out valid use-cases.  I think most use-cases will "just 
work."  We should document the known sharp edges.
 

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Salz, Rich

>Self assigning is a good habit...  unless you have my tendencies, to
*ahem* forget that you've self assigned something.
  
There's a built-in filter that says "find my PR's"  It's just on the left side 
of the search box.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-18 Thread Salz, Rich
>Would still like to know what's motivating Google's insistence on SNI...

The TLS WG is probably the place to ask this.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-17 Thread Salz, Rich
So far, if there's no SNI then we shouldn't do TLS 1.3 (as a client).  That 
seems easy to code.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Constant time by default

2018-04-16 Thread Salz, Rich
I think this is a great idea, but that it is way too late for this release.  We 
really should be concentrating on testing and fixes, and open PR's and other 
release criteria.  Ideally the release goes out in a month (IETF RFC editor 
willing)

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


  1   2   >