Re: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Kurt Roeckx
On Wed, Sep 30, 2020 at 01:57:34PM +, Dr. Matthias St. Pierre wrote:
> topic: OTC meeting will be called for next Tuesday

+1, but wondering why this needs a vote.


Kurt



Re: VOTE: Accept the OTC voting policy as defined:

2020-09-30 Thread Kurt Roeckx
On Mon, Sep 28, 2020 at 12:02:07PM +, Dr. Matthias St. Pierre wrote:
> topic: Accept the OTC voting policy as defined:
> 
>The proposer of a vote is ultimately responsible for updating the 
> votes.txt
>file in the repository.  Outside of a face to face meeting, voters 
> MUST reply
>to the vote email indicating their preference and optionally their 
> reasoning.
>Voters MAY update the votes.txt file in addition.
> 
>The proposed vote text SHOULD be raised for discussion before calling 
> the vote.
> 
>Public votes MUST be called on the project list, not the OTC list and 
> the
>subject MUST begin with "VOTE:".  Private votes MUST be called on the
>OTC list with "PRIVATE VOTE:" beginning subject.

+1


Kurt



Re: Freeze?

2020-09-26 Thread Kurt Roeckx
On Thu, Sep 24, 2020 at 12:33:56PM +1000, Dr Paul Dale wrote:
> I’m seeing quite a bit of activity going on which isn’t related to the 
> 3.0beta1 milestone.
> We’re well past the cutoff date announced for new features in the code.
> 
> Should we be limiting the “new” stuff going in?
> 
> I’m fine with bug fixes, they make sense.  I’m fine with the list of beta1 
> pull requests continuing.
> It’s the rest that is more concerning.

I think we should stop accepting any new changes that are not
clearly related to fixing issues that have been introduced during
the development of 3.0. Of course, bugs can always be fixed.

We've previously announced the deadline for beta 1 to be the 8th of
September. Clearly not everything needed is ready. But at some
point we will have to make the beta 1 release.


Kurt



Tracking important issues

2020-09-23 Thread Kurt Roeckx
Hi,

I would like to have a system so that we can tag issues as
important. But I think they fall in a few categories:
- Features for the next minor/major release (so 3.1 or 4.0)
  that we find important. I've created a new milestone for that:
  https://github.com/openssl/openssl/milestone/18 (Post 3.0.0)

  We've also had a Post 1.1.1 milestone, but that seems to be just
  things that didn't block the 1.1.1 release, maybe some more
  things can be moved over.

  I suggest we do not add all feature requests to the new
  milestone, so that we can have some kind of overview.
- Features we want in before beta 1: The 3.0.0 beta1 milestone
- Bugs that need to get fixed before the 3.0.0 release: 
  currently using the 3.0.0 milestone
- Important bugs that affect the stable releases. I've started
  tagging bugs that have "triaged: bug" also with the branches
  that are affected. But that doesn't say how important it is.
  I have 2 proposals for that:
  - Create a milestone for them, like 1.1.1-stable. In cases we
have multiple supported branches, we can add for instance a
3.0-stable and use the oldest branches that's a affected
as the target. This would at least match what we do now
with the "3.0.0" milestone.
  - Create a label for the severity. I'm not sure we need things
like "severity: minor", but it might be useful too.


Kurt



Re: 3.0 beta 1 milestone

2020-09-22 Thread Kurt Roeckx
On Thu, Sep 17, 2020 at 06:49:19PM +0200, Kurt Roeckx wrote:
> - It doesn't go into 3.0. No idea what the best way to tag them
>   is.

So I've created a "Post 3.0.0" milestone for that.


Kurt



Re: 3.0 beta 1 milestone

2020-09-17 Thread Kurt Roeckx
On Thu, Sep 17, 2020 at 01:48:18PM +0100, Matt Caswell wrote:
> So - this leads me to the question - what is the milestone for? Does it
> means these things *must* go in before we can release beta 1? Or does it
> mean we would *like* to get these things in for beta 1?

We need to have a decision about those before beta 1, which can
include:
- It should be in beta 1
- It doesn't block beta 1, before the 3.0 release is fine too,
  which just means that you change the milestone to 3.0
- It doesn't go into 3.0. No idea what the best way to tag them
  is.


Kurt



Re: Beta1 PR deadline

2020-09-11 Thread Kurt Roeckx
On Fri, Sep 11, 2020 at 11:07:48AM +, Dr. Matthias St. Pierre wrote:
> For a more accurate and timely public overview over the current state of the 
> blockers,
> it might be helpful to manage them via the 3.0.0  milestone 
> 
> https://github.com/openssl/openssl/milestone/15
> 
> Some of the tickets listed below were already associated to the milestone, 
> the others
> were added by me now.

I think the 3.0.0 milestone is what we expect to be in the 
3.0.0 release, not the beta release. That is bug fixes don't need
to be in the beta release, but if it adds new functionallity it
needs to be in the beta release.


Kurt



Re: Beta1 PR deadline

2020-09-09 Thread Kurt Roeckx
On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote:
> 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.

So that date has passed now. Can someone give an overview of what
we think is still needed to be done before the beta 1 release? Are
there open PRs for everything? Do we a milestone on github to
indicate which PRs need to go in before beta1?


Kurt



Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Kurt Roeckx
On Fri, Jun 19, 2020 at 10:29:24PM +0100, Matt Caswell wrote:
> 
> My immediate reaction to that is no - it shouldn't go to 1.1.1. That
> would impact a very high proportion of our user base.

So is risk an important factor? How do you judge the risk? By the
size of the change?


Kurt



Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Kurt Roeckx
I think one other thing that has come up is adding support for a
new target, which can just be some small change to configuration
files. Is that something we want to accept?


Kurt


Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Kurt Roeckx
So we currently also have PR #12201 that adds a new constant time
P-384 implementation. Do you think we should backport that to the
1.1.1 branch? If the answer is different than for the assembler,
why?

Does 1.1.1 being an LTS release have any effect on the answer?
For instance, if we add some assembler during the 3.1 development,
and 3.0 is not an LTS release, but 1.1.1 is, and is still supported,
do we backport it to 1.1.1 and not 3.0?

We've at least talked about not adding a feature to the stable
branch. At least one way of looking at that is that we don't add new
functionality. You could argue that new assembler is not a new
feature, just a new implementation of an existing feature.


Kurt



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

2020-06-17 Thread Kurt Roeckx
On Wed, May 27, 2020 at 12:14:13PM +0100, Matt Caswell wrote:
> PR 10787 proposed to reduce the number of security bits for MD5 and SHA1
> in TLS (master branch only, i.e. OpenSSL 3.0):
> 
> https://github.com/openssl/openssl/pull/10787
> 
> This would have the impact of meaning that TLS < 1.2 would not be
> available in the default security level of 1. You would have to set the
> security level to 0.
> 
> In my mind this feels like the right thing to do. The security bit
> calculations should reflect reality, and if that means that TLS < 1.2 no
> longer meets the policy for security level 1, then that is just the
> security level doing its job. However this *is* a significant breaking
> change and worthy of discussion. Since OpenSSL 3.0 is a major release it
> seems that now is the right time to make such changes.
> 
> IMO it seems appropriate to have an OMC vote on this topic (or should it
> be OTC?). Possible wording:

So should that be an OMC or OTC vote, or does it not need a vote?


Kurt



Re: Travis jobs not getting started

2020-06-05 Thread Kurt Roeckx
On Fri, Jun 05, 2020 at 01:27:20PM +0200, Tomas Mraz wrote:
> Apparently the travis jobs are not getting started anymore for some
> reason.
> 
> It happened to me on the GitHub linux-pam project and the solution (or
> workaround) was to migrate the project to the travis-ci.com.
> 
> I just did it by following the instructions in this document:
> https://docs.travis-ci.com/user/migrate/open-source-repository-migration/

I've tried to do it, but it doesn't seem to be working, it says
it can't find the repository.


Kurt



Re: Unexpected EOF handling

2020-05-11 Thread Kurt Roeckx
On Mon, May 11, 2020 at 06:38:40PM +0300, Dmitry Belyavsky wrote:
> Dear Tomas,
> 
> I'm not sure this is the best possible solution because it makes the
> application developers doing extra compile-time checks.

This is a very minimal change they they need to do that doesn't
have much risk.

But if you have a different suggestion, please say so.

> But anyway, is it a final decision and the patch can be amended or we are
> waiting for objections some more time?

I think there is just a concensus that that is the way forward.
There has not been a vote, nor do I see a reason to hold a vote at
this point.


Kurt



Re: Unexpected EOF handling

2020-05-08 Thread Kurt Roeckx
On Fri, May 08, 2020 at 01:27:00PM +0300, Dmitry Belyavsky wrote:
> On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx  wrote:
> >
> > So I think the suggestion is to have this:
> > - By default, SSL_ERROR_SSL is returned with
> >   SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
> >   marked invalid.
> > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session
> >   will stay valid.
> >
> 
> If I remember correctly, session resumption is a way to significantly
> reduce a server's workload.
> So I think that by default (and maybe the only option) we should prefer the
> old behaviour.

If it's a fatal error, the session should be marked as bad. So if
you want that by default we don't mark is as bad, the default
should be that it's a non-fatal error, and we don't want to return
SSL_ERROR_ZERO_RETURN by default.

SSL_ERROR_SYSCALL with errno 0 does not look like a good long term
API to indicate a non-fatal error. And a different error is
also not what people want.


Kurt



Re: Unexpected EOF handling

2020-05-08 Thread Kurt Roeckx
On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> > 
> > On 07/05/2020 12:22, Kurt Roeckx wrote:
> > > So I think we need at least to agree on:
> > > - Do we want an option that makes the unexpected EOF either a fatal
> > >   error or a non-fatal error?
> > > - Which error should we return?
> > 
> > This is an excellent summary of the current situation.
> > 
> > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a
> > long term solution. It's a very confusing API for new applications to
> > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except
> > when its not. SSL_ERROR_SYSCALL should mean fatal error.
> > 
> > That said I also recognise that it is apparently commonplace to shut
> > down a TLS connection without sending close_notify - despite what the
> > standards may say about it (and TBH we can hardly claim the moral
> > high
> > ground here since s_server does exactly this - or at least it does in
> > 1.1.1 and did until very recently in master).
> > 
> > But we do have to consider usages beyond HTTPS. I have no idea if
> > this
> > occurs in other settings or not.
> > 
> > Perhaps what we need is an option for "strict shutdown". With strict
> > shutdown "off" we could treat EOF as if we had received a
> > close_notify
> > gracefully (and don't invalidate the session). Presumably existing
> > code
> > would be able to cope with that???
> 
> Yes, existing code would be able to cope with that with one important
> exception that I am going to talk about below.
> 
> > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in
> > master).
> > 
> > I'm not sure though what the default should be.
> 
> In case we go with this solution, which would be acceptable I think, we
> MUST NOT EVER make it the default because existing applications that
> depend on the existing way how the unclean EOF condition is returned
> might actually depend on it to detect the truncation attack.

I agree that we should not return SSL_ERROR_ZERO_RETURN by default
on an unexpected EOF.

If the default behaviour should be to make it a non-fatal error,
like the old behaviour is, I would really prefer a different
error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL.

So I think the suggestion is to have this:
- By default, SSL_ERROR_SSL is returned with
  SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
  marked invalid.
- With an option, SSL_ERROR_ZERO_RETURN is returned, the session
  will stay valid.


Kurt




Re: Unexpected EOF handling

2020-05-07 Thread Kurt Roeckx
On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote:
> 
> Actually the coincidence is that the errno is set to 0 on EOF. So yes,
> we should explicitly clear the errno on EOF so any leftover value from
> previous calls does not affect this.

On EOF, errno is normally not modified. It's value is not defined
if no error is returned. It is not guaranteed to be 0 on success
or EOF. It can be modified, because the implementation might have
done other system calls that did return an error. But a simple test
shows that it's not modified on my system.


Kurt



Re: Unexpected EOF handling

2020-05-07 Thread Kurt Roeckx
On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote:
> From application developer side of view for protocols that do not
> depend on SSL detecting the truncation I think inventing a different
> behavior for this condition than the existing one as of 1.1.1f would be
> clearly wrong. Switching on a SSL_OP if that newly provided OP is a
> trivial change to an application that needs to accommodate various
> versions of OpenSSL (and I am not talking about forks), however
> switching on a SSL_OP and also add another special error case is much
> more complicated change and has potential for bringing regressions in
> the applications that need to do it.

Of course, just adding a call to get the old behaviour back is a
very easy change. But I currently don't see how a different error
is that much more complicated.

> Is there really another situation where SSL_ERROR_SYSCALL with errno 0
> could be returned apart from the unclean EOF condition?
> 
> I can't really think of any.

It's not because we can't think of any other case that there aren't
any.

I also have a problem with checking errno being 0. We don't set
errno. There is no reason to assume that errno is set to any
value. errno can be modified on a succesful call. That errno is 0
is just a coincidence. If we're going to document that, we should
actually make sure that that is the case.

I think the other property of the old behaviour is that we don't
add anything to the error stack.

> So I would be just for properly documenting the condition and keeping
> it as is if the SSL_OP to ignore unclean EOF is in effect.

And also don't add an option for applications that do want to get
a fatal error?


Kurt



Unexpected EOF handling

2020-05-07 Thread Kurt Roeckx
Hi,

We introduced a change in the 1.1.1e release that changed how we
handled an unexpected EOF. This broke various software which
resulted in the release of 1.1.1f that reverted that change.
In master we still have the 1.1.1e behaviour.

The change itself is small, it just calls SSLfatal() with a new
error code. This has at least 2 effects:
- The error code was changed from SSL_ERROR_SYSCALL with errno 0
  to SSL_ERROR_SSL with reason code
  SSL_R_UNEXPECTED_EOF_WHILE_READING
- The session is marked as in error, and so can't be used to
  resume.

There is code written that now checks for the SSL_ERROR_SYSCALL
with errno 0 case, while we never documented that behaviour. The
1.1.1 manpage of SSL_get_error() currently reports this as a bug
and that it will change to SSL_ERROR_SSL /
SSL_R_UNEXPECTED_EOF_WHILE_READING.

Code that checks the SSL_ERROR_SYSCALL with errno 0 seem to fall
in at least 2 categories:
- Ignore the error
- Check for the error, for instance in a test suite

Not sending the close notify alert is a violation of the TLS
specifications, but there is software out there doesn't send it,
so there is a need to be able to deal with peers that don't send
it.

When the close notify alert wasn't received, but we did get an
EOF, there are 2 cases:
- It's a fatal error, the protocol needs the close notify alert to
  prevent a truncation attack
- The protocol running on top of SSL can detect a truncation
  attack itself, and does so. It doesn't need the close notify
  alert. It's not a fatal error. They just want to check that that
  is what happened.

The problem is that we can't make a distiction between the 2
cases, so the only thing we can do currently is to look at
it as a fatal error. So the documentation was changed to say
that if you're in the 2nd cases, and need to talk to a peer
that doesn't send the close notify alert, you should not wait
for the close notify alert, so that you don't get an error.

The alternative is that we add an option that does tell us if we
should look at it as a fatal error or not.

There is at least a request that we keep returning the old error code
(SSL_ERROR_SYSCALL with errno 0). I think that from an API point
of view this is very confusing. We'd then have SSL_ERROR_SYSCALL
as documented that it's fatal, except when errno is 0. If errno is
0, it can either be fatal or not, and we're not telling you which
one it is. I think we also can't guarantee that SSL_ERROR_SYSCALL
with errno 0 is always the unexpected EOF, we returned that
combination because of a bug in OpenSSL.

So I think we need at least to agree on:
- Do we want an option that makes the unexpected EOF either a fatal
  error or a non-fatal error?
- Which error should we return?


Kurt



Re: Improving X.509 certificate validation errors

2020-03-26 Thread Kurt Roeckx
On Wed, Mar 25, 2020 at 10:21:36PM -0700, Benjamin Kaduk wrote:
> I tihnk it's an interesting idea.  To me, perhaps the most valuable part
> would be to accumulate a corpus of certificates/chains that are malformed
> or fail to validate due to a wide variety of errors, almost akin to a
> fuzzing corpus.  I'd also be curious (though I'm not entirely sure how
> large a practical impact it would have) to perform a clustering analysis
> across different X.509 implementations and see if different implementations
> produce different distributions of errors.  (That is, we might expect each
> implementation to have an error for "not valid yet", "expired", "missing
> required ASN.1 field", etc.; each implementation will have a different
> error string, of course, but if we group all certificates that produce the
> same error with the same implementation together, we have a bunch of
> different clusters.  Repeating the clustering across all implementations
> lets us compare the different distributions, and examine certificates that
> end up in a different cluster in different implementations.)

That's what frankencert did.


Kurt



Re: Deprecations

2020-03-04 Thread Kurt Roeckx
On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
> 
> 
> On 28/02/2020 23:43, Dr Paul Dale wrote:
> > Any suggestions for a consensus on this thread?
> 
> I think we can probably agree that:
> 
> - Command option deprecations should be handled better
> - We should look at whether we can resurrect some of the "old" commands
> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)

What about at least pointing to the alternative function in the
documentation?


Kurt



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

2020-02-28 Thread Kurt Roeckx
On Thu, Feb 27, 2020 at 01:23:16PM +, Salz, Rich wrote:
> Tony Arceri sent me a pure-CSS solution that worked and looked similar.

I was about to mention that the website it just text+css.


Kurt



Re: Deprecations

2020-02-21 Thread Kurt Roeckx
On Fri, Feb 21, 2020 at 11:27:55PM +, Matt Caswell wrote:
> 
> 
> On 21/02/2020 23:18, Kurt Roeckx wrote:
> > On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
> >>
> >> dhparam itself has been deprecated. For that reason we are not
> >> attempting to rewrite it to use non-deprecated APIs. The informed
> >> decision we have made about DH_check use in dhparam is to not build the
> >> whole application in a no-deprecated build:
> >>
> >>   *) The command line utilities dhparam, dsa, gendsa and dsaparam have been
> >>  deprecated.  Instead use the pkeyparam, pkey, genpkey and pkeyparam
> >>  programs respectively.
> >>  [Paul Dale]
> > 
> > For some reason I seem to have missed various things.
> > 
> > But I think deprecating tools like dhparam, dsaparam in favour of
> > genpkey is something that we should reconsider.
> 
> What is your reasoning?
> 
> (I just realised that what the CHANGES entry says is that
> dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I
> think the equivalent functionality is more split between genpkey and
> pkeyparam)

Some equivalants:
openssl dhparam 2048
openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048

openssl dsaparam 2048
openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048


If you search internet, you will more than likely find the first
ones. They are very easy. I have to look up at the manual page
examples to know how to use genpkey.


Kurt



Re: Deprecations

2020-02-21 Thread Kurt Roeckx
On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
> 
> dhparam itself has been deprecated. For that reason we are not
> attempting to rewrite it to use non-deprecated APIs. The informed
> decision we have made about DH_check use in dhparam is to not build the
> whole application in a no-deprecated build:
> 
>   *) The command line utilities dhparam, dsa, gendsa and dsaparam have been
>  deprecated.  Instead use the pkeyparam, pkey, genpkey and pkeyparam
>  programs respectively.
>  [Paul Dale]

For some reason I seem to have missed various things.

But I think deprecating tools like dhparam, dsaparam in favour of
genpkey is something that we should reconsider.


Kurt



Re: Deprecations

2020-02-21 Thread Kurt Roeckx
On Fri, Feb 21, 2020 at 09:50:10AM +, Matt Caswell wrote:
> 
> 
> On 21/02/2020 08:06, Kurt Roeckx wrote:
> > In the apps, a lot of the files define
> > OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do
> > it. We should stop using the deprecated functions ourself. If
> > there is no way to do this using non-deprecated functions, the
> > function should probably not have been deprecated in the first
> > place.
> > 
> > The apps might have functionality that we want to deprecate too,
> > that depends on the deprecated functions. In which case we should
> > also mark that as deprecated, and the apps should always build in
> > no-deprecation mode.
> 
> I think we have a number of strategies for dealing with deprecated APIs
> in the apps depending on the situation:
> 
> 1) Ideally we just rewrite the functionality using non-deprecated APIs

The problem is that many of the apps already define
OPENSSL_SUPPRESS_DEPRECATED so that you don't know that something
you're deprecating is used there without checking for it.

The commit I was looking at was ada66e78ef535fe80e422bbbadffe8e7863d457c:
Deprecate the low level Diffie-Hellman functions.

At least one of the functions being deprecated is DH_check, which
is still used by dhparam. Dhparam is our replacement for dh and gendh.
I don't know if any of the other function that were deprecated are
still used internally or not.

The define was added in commit 1ddf2594e18137aeb7ce861e54f46824db76e36f,
and so when DH_check later got deprecated, nobody noticed that the
now deprecated function is still being used.

I think the replacement function is EVP_PKEY_param_check().

DH_check is not mentioned as deprecated in the manual.


Kurt



Deprecations

2020-02-21 Thread Kurt Roeckx
Hi,

We seem to be deprecating a lot of the old APIs, which I think is
a good thing. But I think we might either be deprecating too much,
or not actually using the alternatives ourself.

In the apps, a lot of the files define
OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do
it. We should stop using the deprecated functions ourself. If
there is no way to do this using non-deprecated functions, the
function should probably not have been deprecated in the first
place.

The apps might have functionality that we want to deprecate too,
that depends on the deprecated functions. In which case we should
also mark that as deprecated, and the apps should always build in
no-deprecation mode.

We might also be deprecating APIs that we don't use ourself, so
it's harder to know if there are alternatives for it.

It would also be nice that if you deprecate a function, that you
point to the alternative way to do the same thing in the manual.


Kurt



Re: Github PR label automation

2020-02-11 Thread Kurt Roeckx
On Sat, Feb 08, 2020 at 03:56:19PM +, Mark J Cox wrote:
> So right now here's what it does:
> 
> Every hour it looks at open PRs that are labelled "approval: done".
> If 24 hours has elapsed since that label was assigned and if there
> have been no comments made to the PR since the label was assigned then
> it is automatically moved to "approval: ready to merge" with a comment
> added to trigger notifications.  So if you want to stop something
> going to "ready to merge" just add any comment to the PR.

Does it also check that the CI says that everything is OK?


Re: Should the return result of CRYPTO_UP_REF() / CRYPTO_DOWN_REF() be checked?

2020-02-10 Thread Kurt Roeckx
On Mon, Feb 10, 2020 at 04:19:20PM +, Matt Caswell wrote:
> 
> 
> On 10/02/2020 00:15, SHANE LONTIS wrote:
> > With the new architecture changes there are quite a few new calls to
> > 
> > CRYPTO_UP_REF()
> > CRYPTO_DOWN_REF()
> > 
> > These methods return an int that is not being checked in lots of places.
> > 
> > This return value only seems to affect fallback code that calls 
> > CRYPTO_atomic_add (which can return 0 on lock or unlock failure)
> > 
> > SO the question is should we be checking this return value?
> 
> Yes, I think we should be.

I think that as long as we have that fallback code, that it should
be checked.


Kurt



Re: crypt(3)

2020-01-19 Thread Kurt Roeckx
On Sun, Jan 19, 2020 at 11:45:07AM +1000, Dr Paul Dale wrote:
> 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?

I would actually like to go for something modern in that case,
like argon2 (argon2id). We have an open issue
(https://github.com/openssl/openssl/issues/4091) and pull request
(https://github.com/openssl/openssl/pull/9444) for argon2. PHP
seems to have made a format for it that's compatible with crypt():
https://wiki.php.net/rfc/argon2_password_hash_enhancements
But the argon2 RFC hasn't been published yet, so I think that
might need to wait.

The only thing that we support currently that makes sense as a
default is -5 (sha256) and -6 (sha512). I suggest you go with -6.


Kurt



Re: crypt(3)

2020-01-18 Thread Kurt Roeckx
On Sat, Jan 18, 2020 at 10:47:04AM +1000, Dr Paul Dale wrote:
> Could the people who work with distros confirm this default choice or suggest 
> what they use please?

I'm not sure what you're asking, but crypt() has moved on from
using DES like 20 years ago, see crypt(5).


Kurt



Re: crypt(3)

2020-01-17 Thread Kurt Roeckx
On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
> I’ve got several choices:
> Leave them public and unchanged — that is, don’t deprecate these two 
> functions yet.
> Deprecate them and add KDFs to replace them.
> Deprecate them, leave them alone and hope they go away painlessly at some 
> point.

I really see no point in adding something that we at the same time
would like to remove. Just deprecate it.


Kurt



Re: Legacy Provider

2020-01-08 Thread Kurt Roeckx
On Tue, Jan 07, 2020 at 09:57:55AM +1000, Dr Paul Dale wrote:
> The refactoring/FIPS work needs the question resolved about loading the 
> legacy provider or not by default.  We’ve been through this before on the 
> project list [1] and in at least one PR [2].
> 
> I expect that its resolution will require an OMC vote.

Why OMC and not OTC?



Kurt



Re: Build failures on master?!

2019-11-18 Thread Kurt Roeckx
On Mon, Nov 18, 2019 at 09:48:38PM +, Dr. Matthias St. Pierre wrote:
> The last 19 commits on https://github.com/openssl/openssl/commits/master,
> starting from Nov 14 have a red cross from the CIs. What's going on again?

I have filed 2 issues on Nov 9 that that caused the CIs to fail,
that that haven't been closed yet.

> My personal impression is that builds on master are failing 50% of the time.
> 
> It is really tedious to check pull requests for build errors just to find 
> that those errors
> are well known failures from master. In particular, the krb5 an pyca tests 
> are notoriously
> failing. Are there any plans to fix them or disable them?
> 
>   95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1)
>   95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1)
> 
> Clean builds on master should have highest priority. Because if there are too 
> many red
> crosses, nobody cares about them anymore.

Note that they are also broken in the 1.1.1-stable branch.

At least pyca is something you should be able to fix with a new
upstream version.


Kurt



New audit before 3.0 release

2019-11-10 Thread Kurt Roeckx
Should we let someone do a new audit before the 3.0 release?


Kurt



Re: Thread sanitiser problems

2019-07-30 Thread Kurt Roeckx
On Tue, Jul 30, 2019 at 12:41:16PM +0200, Matthias St. Pierre wrote:
> On 30.07.19 11:59, Kurt Roeckx wrote:
> > On Tue, Jul 30, 2019 at 12:42:33PM +1000, Dr Paul Dale wrote:
> > > Overly simplified, the problem boils down to the CTR DRBG needing an AES 
> > > CTR cipher context to work.  When creating the former, a recursive call 
> > > is made to get the latter.
> > I'm not sure what you mean with "CTR" both times.
> > 
> > Are you saying that an AES requires a DRBG now?
> > 
> 
> No. Pauli simply meant that the CTR DRBG utilizes an EVP_CIPHER_CTX for its 
> internal implementation.

I currently fail to see how that's a problem, unless that
EVP_CIPHER_CTX tries to use a DRBG.


Kurt



Re: Thread sanitiser problems

2019-07-30 Thread Kurt Roeckx
On Tue, Jul 30, 2019 at 12:42:33PM +1000, Dr Paul Dale wrote:
> Overly simplified, the problem boils down to the CTR DRBG needing an AES CTR 
> cipher context to work.  When creating the former, a recursive call is made 
> to get the latter.

I'm not sure what you mean with "CTR" both times.

Are you saying that an AES requires a DRBG now?


Kurt



Re: Two Travis Jobs are failing on master

2019-07-23 Thread Kurt Roeckx
On Tue, Jul 23, 2019 at 09:15:22PM +, Dr. Matthias St. Pierre wrote:
> It looks like currently two jobs of every travis build are failing on master, 
> each with two different tests.
> Since this affect the builds of the pull requests, it would be nice if they 
> could be fixed. Is anybody taking
> care of the problem already?

Is is related to 9442?

Note that the failing tests are part of the extended tests, so we
don't see a problem during pull requests. Pull requests pass
without problems.

It seems that we don't notice things even if master is broken for
a while, because they are only tested after they've been commited,
and it doesn't affect other pull requests. I wonder if we can
somehow get notificated of that.


Kurt



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

2019-07-16 Thread Kurt Roeckx
On Tue, Jul 16, 2019 at 03:06:28PM -0400, Viktor Dukhovni wrote:
> On Mon, Jul 15, 2019 at 02:27:44PM +, Salz, Rich wrote:
> 
> > >>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.
> 
> 1.  DSA is not supported in TLS 1.3.
> 2.  DSA is almost never used with TLS 1.2, the public
>   CAs and the vast majority of users employ RSA.
> 3.  Historical DSA was limited to 1024-bit keys and SHA-1.
>   IIRC we now support stronger combinations, but these
>   are not widely used.
> 4.  As mentioned key disclosure is more likely than with RSA.
> 5.  Attack-surface reduction.  If DSA is almost never used,
>   why enable it by default?
> 
> I might note that I don't count myself amont the "crypto maximalists"
> And I'm generally of the "raise the ceiling not the floor" mindset,
> RFC7435 and all that.  However, once an algorithm is sufficiently
> disused (raising the ceiling worked, and everybody we care about
> has moved on) it is then time to turn out the lights.

There used to be DSA certificates used in TLS, but the last one
expired years ago. DSS based ciphers are also disabled by default
since 1.1.0.


Kurt



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

2019-07-16 Thread Kurt Roeckx
On Mon, Jul 15, 2019 at 02:58:42PM +0200, Tomas Mraz wrote:
> Wouldn't it be better to make the legacy provider opt-out? I.E. require
> explicit configuration or explicit API call to not load the legacy
> provider.

I'm not even sure why they need to move to a different provider
(at this time). Instead I think we should have a mechanism to
enable/disable the individual algorithms, and still have
everything in the default provider, possibly disabled by default.

At some point in the future we could remove the code from OpenSSL,
and move it to different repository that only contains such legacy
code that we no longer ship as part of OpenSSL.

Kurt



Re: Start up entropy gathering

2019-06-13 Thread Kurt Roeckx
On Thu, Jun 13, 2019 at 05:06:16PM +1000, Dr Paul Dale wrote:
> 
> The second suggestion is broadly similar but requires a file containing 
> entropy that persists across reboots.  This alternative requires a more 
> management: the entropy file once read needs to be rewritten immediately (and 
> ideally on shutdown as well).  It also introduces a new attack vector against 
> the entropy storage.  It also isn’t possible to skip the entropy file 
> read/rewrite sequence because it is impossible to determine if /dev/urandom 
> has actually been seeded.  I’ve not attempted to code this, persistent files 
> containing seed material potentially introduce other problems.

This is what init systems have always done. I see no need to also
do it. They have a policy not to credit that the entropy from that
file, I see no reason why we should override that policy.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-09 Thread Kurt Roeckx
On Sat, Jun 08, 2019 at 09:28:43AM +1000, Dr Paul Dale wrote:
> This vote has been closed, it passed 5 votes to 2 with no abstentions.
> 
> 
> Up for discussion is the text of the next vote.  I’m proposing this:
> 
> Topic: The OpenSSL 3.0.0 release will include mitigation for the low entropy 
> on boot and first boot problems.
> Comment: PR#9084 removed such mitigation due to the negative side effects.
> 
> 
> I’ll make this formal in a day or so, so if anyone wants to suggest 
> alternative wording, that’s the time line.  The vote text is the “topic” 
> line, the comment is explanatory only.
> 
> Note: I’m not mentioning the mechanism used, that still needs to be decided 
> on.  This is just saying that 3.0.0 *will* have some mechanism.

The only mechanisms I can think of are:
- Do something with /dev/random (use it as source, select on it,
  read a byte from it)
- Check for the presence of some file that we require the init
  system to set up to indicate that /dev/urandom is ready, and
  wait until it exists.
- Don't use /dev/urandom at all


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 07:04:57PM -0400, Viktor Dukhovni wrote:
> On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote:
> 
> > On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> > > > 
> > > > For older kernels you install rng-tools that feeds the hwrng in
> > > > the kernel.
> > > 
> > > Which works for me, and is pretty much the point I'm trying to make.
> > > Then, read /dev/random once early at boot, and do nothing special
> > > libcrypto (safely use /dev/urandom).
> > 
> > The only thing rng-tools will actually solve is the starvation
> > issue. No service will depend on it, since they don't have any
> > relationship with it. Nor can you wait for it, it's not because
> > it's started that it has initialized the kernel. I think I've also
> > seen reports that it got started too late, actually after a
> > services that wants to ask the kernel for random numbers.
> 
> Then a different service can be developed that does block just once
> at boot, and tries to obtain entropy from a configurable set of
> sources (to avoid or reduce unbounded delay, and mix in more
> independent sources).

That's all very nice, but nobody is going to run that.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> > 
> > For older kernels you install rng-tools that feeds the hwrng in
> > the kernel.
> 
> Which works for me, and is pretty much the point I'm trying to make.
> Then, read /dev/random once early at boot, and do nothing special
> libcrypto (safely use /dev/urandom).

The only thing rng-tools will actually solve is the starvation
issue. No service will depend on it, since they don't have any
relationship with it. Nor can you wait for it, it's not because
it's started that it has initialized the kernel. I think I've also
seen reports that it got started too late, actually after a
services that wants to ask the kernel for random numbers.

An other solution might be that we enable rdrand/rdseed by default
as entropy source, after getentropy() and before /dev/urandom.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 07:01:30PM +, Salz, Rich wrote:
> 
> >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?

This whole discussion has only been about Linux, we only define
DEVRANDOM_WAIT on Linux.

I think all other OSs have a sane /dev/urandom, but I'm not sure
about NetBSD.

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

Do you have a reference that Solaris allows reading from
/dev/urandom before it's been initialized?


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 03:08:24PM -0400, Viktor Dukhovni wrote:
> > On Jun 7, 2019, at 2:41 PM, Kurt Roeckx  wrote:
> > 
> >> This is not the sort of thing to bolt into the kernel, but is not
> >> unreasonable for systemd and the like.
> > 
> > The kernel actually already does this in recent versions, if
> > configured to do it.
> 
> We're talking about what to do with for older kernels.

For older kernels you install rng-tools that feeds the hwrng in
the kernel.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 02:31:54PM -0400, Viktor Dukhovni wrote:
> 
> That's a different issue.  What I was suggesting was a service that
> waits for seeding to be ready.  So that other services can depend
> on that service, with that service using various sources to adequately
> seed the kernel RNG, with configurable additional sources beyond the
> save file, possibly with a non-zero entropy estimate.  Thus, for example,
> a virtual machine or container might make use of an interface to get a
> a trusted seed from the host hypervisor/OS.  Or a physical host might
> trust its TPM, ...
> 
> This is not the sort of thing to bolt into the kernel, but is not
> unreasonable for systemd and the like.

The kernel actually already does this in recent versions, if
configured to do it.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 06:06:02PM +, Dr. Matthias St. Pierre wrote:
> > Introducing DEVRANDOM_WAIT didn't cause any change for us, because
> > we use getentropy(), and a recent kernel. But even systems that
> > use getentropy() with an older kernel can have a large delay after
> > boot.
> 
> Yes, but that's the crucial difference IMHO: while getentropy() on blocks once
> during the early boot phase until its initial seeding completes, the 
> DEVRANDOM_WAIT
> approach will block several times, depending on how much the other processes 
> drain
> the /dev/random device.

I agree that the solution is not ideal, but I think it's better than
not having it.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 01:28:30PM -0400, Viktor Dukhovni wrote:
> 
> I think that having the RNG behaviour capriciously different on
> different systems based on the whims of whoever built the library
> for that system is not a good idea.  OpenSSL should provide an RNG
> that does not block "unexpectedly", indefinitely, and unpredictably.
> 
> Where "unexpectedly", means except possibly early at boot time, but
> ideally waiting for boot-time entropoy is something that systemd
> and the like take care of, and application start scripts can just
> register a dependency on some sort of "entropy" service, whose
> successful initialization is sufficient to ensure adequately secure
> non-blocking seeding of applications via one of getentropy(),
> getrandom(), /dev/urandom...
> 
> That is, I'd expect most of the work for ensuring adequate entropy
> to happen outside libcrypto, except for perhaps enabling some
> additional sources that may be available on various systems.

It seems unlikely that anything related to this will ever change,
but we can always ask.

The reason I think nothing will change is that the problem is
already solved, use getentropy()/getrandom(). The init system would
need to create this kind of service, and then all software not using
getentropy()/getrandom() would need to depend on that service. It
would be eaier to just switch that software to use
getentropy()/getrandom().

Changing the init system, means that this will only work for new
versions of an OS. But on those new versions we already use
getentropy()/getrandom(). What we want to support is people that
use an old OS, but run a new version of OpenSSL on it. That is,
people that do not use the OS provided OpenSSL version.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 10:18:32AM +0200, Tomas Mraz wrote:
> 
> From the point of view of distribution maintainer of OpenSSL I would
> say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had
> no real problems for us.

Introducing DEVRANDOM_WAIT didn't cause any change for us, because
we use getentropy(), and a recent kernel. But even systems that
use getentropy() with an older kernel can have a large delay after
boot.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 06:03:26PM +1000, Dr Paul Dale wrote:
> 
> My suggestion as a fallback would be Stephan Müller’s CPU Jitter 
> .  He’s collected a large 
> corpus of data from many processors and the scheme works relatively quickly.

I don't think we should be collecting entropy from CPU jitter
ourself. If that's something useful, it should be up to the OS
to provide it to us. But it seems highly unlikely that that will
happen since there seems to be little trust in that it actually
provides the entropy.


Kurt



Vote proposal: votes should get discussed first

2019-05-12 Thread Kurt Roeckx
Hi,

I would like to propose the following vote:
All public votes should be discussed on the openssl-project list
before a vote is called. The minimum time between a proposal
and calling for a vote is 1 week. If the proposal is changed, the
1 week period restarts.


Re: Issues and pull requests are largely getting ignored

2019-03-26 Thread Kurt Roeckx
On Tue, Mar 26, 2019 at 09:53:22AM +, Matt Caswell wrote:
> 
> So the real problem there is a mismatch between the opening rate and the 
> closing
> rate, i.e. it is NOT that we are ignoring these issues. I see it more as a
> resource issue - we are seeing issues raised at a greater rate than we have
> resources to handle.

Or that the resources we do have are spend on the wrong thing.

> I can't do the same analysis for PRs because github doesn't detect properly 
> when
> we merge PRs (because we don't use the github facility for doing that). I 
> would
> expect to see somewhat similar numbers though.

The amount of open pull requests has been around 200 for the last
few months, so it seems we can just keep up with that currently,
but it used to be around 100.

So I think that in general we do not have enough resources to keep up
with both the pull requests and issues.


Kurt



Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-02-06 Thread Kurt Roeckx
On Thu, Jan 31, 2019 at 02:19:28PM -0600, David Benjamin wrote:
> On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell  wrote:
> 
> >
> > On 31/01/2019 18:50, David Benjamin wrote:
> > > We will see if this damage turns out fatal for KeyUpdate, but OpenSSL
> > can at
> > > least help slow its spread by issuing a fix
> >
> > That's precisely what PR 8096 does.
> >
> >
> > > As a heuristic for API design: if the caller needs to know the
> > implementation
> > > details of OpenSSL to understand what this API does, the API is no good.
> > > Existing code cannot possibly predict how OpenSSL's implementation will
> > evolve
> > > over time, so there is no way to use such an API in a future-proof way.
> > Do not
> > > introduce such APIs.
> >
> > The info callback has been around a *long* time. In fact OpenSSL did not
> > introduce it at all - we inherited it from SSLeay. Arguments about whether
> > it is
> > a good API or not don't help the issue at hand. The API exists,
> > applications use
> > it, and so (for now at least) we continue to support it.
> >
> > Given that it already existed we had to make a decision about how it was
> > going
> > to work in the presence of TLSv1.3. We did what we believed to be the
> > correct
> > thing at the time. The changes were pretty minimal and we tried to keep
> > things
> > as close to what existing users of the callback would expect. It turns out
> > we
> > got it wrong.
> >
> 
> Right, but SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END are
> new. It seems best to just omit it, so OpenSSL is not tied to the nebulous
> notion of "post-handshake exchange".
> 
> I.e. don't bracket post-handshake things with START/END at all.

Matt, do you have any comment on this? Can we go forward with
this?


Kurt

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


Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-01-30 Thread Kurt Roeckx
On Wed, Jan 30, 2019 at 10:44:12AM +, Matt Caswell wrote:
> 
> 
> On 29/01/2019 19:27, David Benjamin wrote:
> > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx  > <mailto:k...@roeckx.be>> wrote:
> > 
> > On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote:
> > > So I plan to start the vote soon for merging PR#8096 and backporting 
> > it to
> > > 1.1.1. This is a breaking change as previously discussed.
> > >
> > > My proposed vote text is as follows. Please let me know asap of any 
> > feedback.
> > > Otherwise I will start the vote soon.
> > >
> > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START 
> > and
> > > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post 
> > handshake
> > > message exchange in the info callback (replacing 
> > SSL_CB_HANDSHAKE_START and
> > > SSL_CB_HANDSHAKE_END)."
> > 
> > 
> > What exactly is a post-handshake message exchange? Do the NewSessionTicket 
> > sent
> > by the server at the beginning count as the part of the handshake? Are they 
> > each
> > separate post-handshake exchanges? Are all of them together one exchange?
> > Conversely, what happens when you receive that NewSessionTicket as a client?
> 
> 
> They are each separate post-handshake exchanges. Both on the server and on the
> client.
> 
> > 
> > When you send a KeyUpdate with key_update_requested, is the reply you expect
> > part of the exchange or separate? What if the peer coalesced them to avoid 
> > DoS
> > problems? Conversely, if you receive a KeyUpdate with key_update_requested, 
> > is
> > your reply part of the exchange? What if you coalesced them to avoid DoS 
> > problems?
> > 
> > What if I send a CertificateRequest, but the other side sends me a KeyUpdate
> > with key_update_requested before responding with Certificate, so I respond 
> > with
> > my own KeyUpdate? What and how many exchanges are there?
> > 
> > Is it important that both sides agree what an "exchange" is?
> 
> The answers all depend on how the OpenSSL state machine views them. At the
> moment the peer sending a KeyUpdate sees that as a single standalone exchange.
> If an update has been requested then the receiving peer sees the receiving and
> subsequent sending of the next KeyUpdate as a single exchange.

This "at the moment" sounds a lot like "we can change this at any
time, for whatever reason".

I can actually see a use case for wanting to know if a key update
has been received and sent. Maybe the application wants to make
sure that at regular intervals this is done. I just doubt that
this is the most useful interface for that. The way to do that is
to tell OpenSSL to do that instead.

> Certificate requests are similar, i.e. the server sees the sending of the
> certificate request as a single standalone exchange, and the receipt of the
> subsequent Certificate/Finished as a separate exchange. The client sees the
> receipt of the request and its response as one single exchange.

I think the server really only cares that it's been received, and
you can argue that it should be 1 exchange.


Kurt

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


Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-01-30 Thread Kurt Roeckx
On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote:
> So I plan to start the vote soon for merging PR#8096 and backporting it to
> 1.1.1. This is a breaking change as previously discussed.
> 
> My proposed vote text is as follows. Please let me know asap of any feedback.
> Otherwise I will start the vote soon.
> 
> "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and
> SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake
> message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and
> SSL_CB_HANDSHAKE_END)."

So my proposal would be: Don't call the callback for post
handshake messages. (It could use some rewording.)


Kurt

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


Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-01-29 Thread Kurt Roeckx
On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote:
> I think one clear conclusion from this incident is that this sort of
> low-level API should be avoided, or people will use them in finicky ways
> that break unexpectedly when you change things. Better defer such
> mechanisms to when concrete use cases come up, and then implement direct
> APIs for those use cases, like SSL_OP_NO_RENEGOTIATION.

I have to agree to that.


Kurt

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


Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-01-29 Thread Kurt Roeckx
On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote:
> So I plan to start the vote soon for merging PR#8096 and backporting it to
> 1.1.1. This is a breaking change as previously discussed.
> 
> My proposed vote text is as follows. Please let me know asap of any feedback.
> Otherwise I will start the vote soon.
> 
> "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and
> SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake
> message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and
> SSL_CB_HANDSHAKE_END)."

This will only cover the key update currently? Does that come with
some parameter telling which kind of handshake is happening? If
not, is it more useful to just say that a key update is happening?


Kurt

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


Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-28 Thread Kurt Roeckx
On Mon, Jan 28, 2019 at 03:38:50PM +, Matt Caswell wrote:
> 
> 
> On 24/01/2019 18:12, Sam Roberts wrote:
> > The other changes that TLS1.3 requires, multiple session tickets, a
> > few new APIs to replace some of the SSL_renegotiate use-cases, etc.,
> > all are pretty routine. We could get TLS1.3 support in Node.js fairly
> > quickly if the info callback issue was solved openssl side. I'm even
> > happy to help work on it if that's an issue, it would be more
> > productive than what I've been trying to do in Node.js.
> 
> In case anyone missed it I opened a PR for this over the weekend:
> 
> https://github.com/openssl/openssl/pull/8096
> 
> I'm leaving it there for a day or two for people to comment. Assuming no major
> issues are identified I'll will raise an OMC vote for it.

Can I suggest you just describe what the patch does, and call a
vote on that?


Kurt

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


Re: [openssl-project] inline functions

2019-01-27 Thread Kurt Roeckx
On Sun, Jan 27, 2019 at 08:33:06PM +1000, Tim Hudson wrote:
> From https://github.com/openssl/openssl/pull/7721
> 
> Tim - I think inline functions in public header files simply shouldn't be
> present.
> Matt - I agree
> Richard - I'm ambivalent... in the case of stack and lhash, the generated
> functions we made static inline expressly to get better C type safety, and
> to get away from the mkstack.pl horror.

In general I have to agree that it's not a good thing to do,
specially in cases where it calls other functions. We went away
from making them just defines into functions, but they should
instead be functions in the library, at least for external users
of the library.


Kurt

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


Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-22 Thread Kurt Roeckx
On Tue, Jan 22, 2019 at 02:48:26PM -0500, Viktor Dukhovni wrote:
> As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure
> what to do there, but perhaps we could define a new even for keyUpdates
> that does not mislead applications into assuming a new "handshake".

I think calling anything a handshake that is not a handshake
should either be removed or renamed. KeyUpdate is not a handshake.
I'm not sure what we do in case of a session ticket, but it also
shouldn't send such events, but other events are probably useful
in that case.


Kurt

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


Re: [openssl-project] Vote to update the security policy

2018-12-06 Thread Kurt Roeckx
On Thu, Nov 29, 2018 at 03:34:29PM +, Mark J Cox wrote:
> Changes to policies require an OMC vote which I've called to approve an
> update to the security policy.  This was as discussed at the face to face
> and the details and diff are at https://github.com/openssl/web/pull/96
> 
> 
> topic: Update security policy as per https://github.com/openssl/web/pull/96

This vote failed with 4 votes against and 3 people not voting.

The intend of voting against is to work on the wording and then
call a new vote.


Kurt

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


Re: [openssl-project] Random devices in chroot environments revisited

2018-10-30 Thread Kurt Roeckx
On Tue, Oct 30, 2018 at 07:23:52PM +, Dr. Matthias St. Pierre wrote:
> Hi,
> 
> I'd like to recall that the following issue
> 
> #7419 - RAND_keep_random_devices_open not working
> 
> still needs to be fixed until 1.1.1a and that currently there are two
> alternative approaches for doing it:
> 
> #7429 - Conditionally open random devices on initialization
> #7437 - rand_unix.c: open random devices on first use only 
> 
> A short recall of the background story: In pull request
> 
> #6432 - Keep /dev/random open for seeding
> 
> a regression was fixed that affected applications in chroot environments.
> It compensated the fact that the new OpenSSL CSPRNG now reseeds
> periodically, which the previous one didn't.
> 
> The solution was to open all random devices early and keep them
> open.  An API call (RAND_keep_random_devices_open()) was added
> for the application to opt-out from this behaviour.
> 
> In issue #7419 it was reported that this opt-out did not work as expected.
> 
> *  Pull request #7429 fixes the opt-out issue but remains along the lines of
> the initial solution #7432. This approach has the side effect that the
> random devices are always opened, even if they are never used
> (for example, because getrandom() is available). Even more, if the
> application forks and execs, these handles will be left open and unused
> in the child process.
> 
> An application which does not want this behavior, could explicitly 
> opt-out,
> but this would require a recompilation, which is somewhat contrary to
> the assumptions of the initial chroot problem.
> 
> *  Pull request #7429 works without explicit opt-out, because it opens the

#7437 I guess

> random devices on first use only (and then keeps them open, unless
> the opt-out was called). The advantage of this approach: If getrandom()
> is available and working, the opening will never happen.
> 
> The lazy opening does not add a regression for applications compiled
> against 1.1.0, because the old SSLEAY CSPRNG used to be initialized 
> on first use, too. So also with 1.1.0 it was necessary to initialize the
> CSPRNG properly before chrooting (unless the random device was
> mounted into the chroot jail).
> 
> Your thoughts?

I prefer the option where it doesn't get opened if getrandom() is
avialable.


Kurt

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


Re: [openssl-project] Current priorities

2018-10-16 Thread Kurt Roeckx
On Tue, Sep 18, 2018 at 08:06:12PM +0200, Kurt Roeckx wrote:
> The open PRs were around 100 when 1.1.0 was released, and have
> been around 120 for a very long time, but the last few months it has
> grown to around 150. I guess we have some that are waiting because
> they are new features that didn't go in 1.1.1. But I would like to
> get the number of open PRs to around 100, but even lower is of
> course even better.

We currently at 176 open PR, that's 25 more open PRs 1 month
later.


Kurt

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


Re: [openssl-project] dropping out

2018-10-12 Thread Kurt Roeckx
On Fri, Oct 12, 2018 at 02:01:42PM +0200, Andy Polyakov wrote:
> Another contributing factor is lack of opportunities to pursue
> so to say "fundamental" goals, formal validation of assembly code being
> one example.

Formal validation of the assembly code is something I would
actually like to see, and even talked with some people about it.
But I don't have the time to actually get this done.


Kurt

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


Re: [openssl-project] Minimum C version

2018-10-07 Thread Kurt Roeckx
On Sun, Oct 07, 2018 at 02:01:36PM +0100, David Woodhouse wrote:
> Unfortunately Microsoft still does not support C99, I believe. Or did that 
> get fixed eventually, in a version that can reasonably be required?

That is a very good point, and they never intend to fix that.

So would that mean we say that VC will be unsupported? Or that we
should make it so that it can be build using C++?


Kurt

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


[openssl-project] Minimum C version

2018-10-07 Thread Kurt Roeckx
Hi,

We're currently still targetting C89/C90 + long long, yet use
various features of C99 and even some C11 when it's available.

C99 is now almost 20 years old, can we please move to at least
that?


Kurt

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


Re: [openssl-project] Release strategy updates & other policies

2018-09-26 Thread Kurt Roeckx
On Wed, Sep 26, 2018 at 07:06:18PM +0200, Richard Levitte wrote:
> In message <20180926165825.ga14...@roeckx.be> on Wed, 26 Sep 2018 18:58:26 
> +0200, Kurt Roeckx  said:
> 
> > On Tue, Sep 25, 2018 at 08:13:53PM +1000, Tim Hudson wrote:
> > > On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell  wrote:
> > > 
> > > > On 25/09/18 10:58, Tim Hudson wrote:
> > > > > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte  > > > > <mailto:levi...@openssl.org>> wrote:
> > > > >
> > > > > So what you suggest (and what I'm leaning toward) means that we 
> > > > > will
> > > > > change our habits.
> > > > >
> > > > >
> > > > > Adoption of semantic versioning will indeed require us to change our
> > > > > habits in a number of areas - that is the point of having a single 
> > > > > clear
> > > > > definition of what our version numbers mean.
> > > > >
> > > > > I also do think we need to document a few things like what we mean by
> > > > > bug fix compared to a feature update as there are items which we could
> > > > > argue could either be a PATCH or a MINOR update depending on how we
> > > > > describe such things.
> > > >
> > > > Sometimes we need to add a function in order to fix a bug. How should
> > > > this be handled? e.g. there are 60 functions defined in
> > > > util/libcrypto.num in the current 1.1.0i release that weren't there in
> > > > the original 1.1.0 release.
> > > >
> > > 
> > > 
> > > In semantic versioning those are MINOR releases. The API has changed in a
> > > backward compatible manner.
> > > They cannot be called PATCH releases - those are only for internal changes
> > > that fix incorrect behaviour.
> > > If you change the API you are either doing a MINOR or a MAJOR release.
> > 
> > We might need to add this to multiple branches at the same time.
> > 
> > Assume that we have a 2.0.5 and 2.1.2 version. And in both
> > versions we need to add that a new function, what should the
> > new versions be? My understanding is that you can't actually do
> > it.
> 
> If we have both 2.0.5 and 2.1.2 as current releases, then it means
> we've branched at MINOR releases, i.e. we have a 2.0.x branch and a
> 2.1.x branch.  Semver says that when you add new functionality, the
> next release MUST get its MINOR version number increased.  Since the
> last MINOR release is 2.1.0, it means that we must release 2.2.0, and
> start a new branch for 2.2.x.

2.0.5 could for instance be something like the current version 1.0.0e,
and 2.1.2 the current 1.0.1b.

So 2.0.5 can't get fixed, because we can't give it a new number?

Does that then mean we should leave numbers free, so that it's
possible we can use them later? And that 2.1.2 should have been
named something like 2.10.2 instead?

> If we branch on MAJOR releases, then that situation isn't even
> possible, you just cannot have 2.0.5 and 2.1.2 at the same time...
> unless you sub-branch, an endeavour I was stand very far away from.

So you're saying we should always increase the major number, not
the minor number, in case we make a release with new features?
Minor numbers are in case we need to add new features to an older
version?


Kurt

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


Re: [openssl-project] Release strategy updates & other policies

2018-09-26 Thread Kurt Roeckx
On Tue, Sep 25, 2018 at 08:13:53PM +1000, Tim Hudson wrote:
> On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell  wrote:
> 
> > On 25/09/18 10:58, Tim Hudson wrote:
> > > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte  > > > wrote:
> > >
> > > So what you suggest (and what I'm leaning toward) means that we will
> > > change our habits.
> > >
> > >
> > > Adoption of semantic versioning will indeed require us to change our
> > > habits in a number of areas - that is the point of having a single clear
> > > definition of what our version numbers mean.
> > >
> > > I also do think we need to document a few things like what we mean by
> > > bug fix compared to a feature update as there are items which we could
> > > argue could either be a PATCH or a MINOR update depending on how we
> > > describe such things.
> >
> > Sometimes we need to add a function in order to fix a bug. How should
> > this be handled? e.g. there are 60 functions defined in
> > util/libcrypto.num in the current 1.1.0i release that weren't there in
> > the original 1.1.0 release.
> >
> 
> 
> In semantic versioning those are MINOR releases. The API has changed in a
> backward compatible manner.
> They cannot be called PATCH releases - those are only for internal changes
> that fix incorrect behaviour.
> If you change the API you are either doing a MINOR or a MAJOR release.

We might need to add this to multiple branches at the same time.

Assume that we have a 2.0.5 and 2.1.2 version. And in both
versions we need to add that a new function, what should the
new versions be? My understanding is that you can't actually do
it.


Kurt

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


[openssl-project] Current priorities

2018-09-18 Thread Kurt Roeckx
Hi,

Now that 1.1.1 is released, and before everybody starts to work on
new features, I would like to suggest that we work on reducing the
number of open pull requests and issues.

Fixing issues that are regressions in the 1.1.1 version is
something we really should be doing, and I think that should
currently be our top priority. We should probably also do a new
release after a month or something.

The open PRs were around 100 when 1.1.0 was released, and have
been around 120 for a very long time, but the last few months it has
grown to around 150. I guess we have some that are waiting because
they are new features that didn't go in 1.1.1. But I would like to
get the number of open PRs to around 100, but even lower is of
course even better.

I guess the open issues are also also growing, but I don't have
any numbers for that.


Kurt

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


Re: [openssl-project] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

2018-09-10 Thread Kurt Roeckx
On Sun, Sep 09, 2018 at 11:44:33PM +0100, Matt Caswell wrote:
> 
> As far as the release criteria go we only count the ones shown in the
> Coverity tool. That's not to say we shouldn't fix issues in the tests as
> well (and actually I'd suggest we stop filtering out problems in the
> tests if anyone knows how to do that...perhaps Tim?).

You can change that in the project settings, where it splits the
paths into different groups.


Kurt

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


Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Kurt Roeckx
On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote:
> Current status of the 1.1.1 PRs/issues:

Since we did make a lot of changes, including things that
applications can run into, would it make sense to have an other
beta release?


Kurt

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


Re: [openssl-project] Current status of our release criteria

2018-09-03 Thread Kurt Roeckx
On Mon, Sep 03, 2018 at 05:54:52PM +0100, Matt Caswell wrote:
> 
> #7014: TLSv1.2 SNI hostname works in 1.1.0h, not in 1.1.1 master (as of 18
> 
> Ben has asked for input from the OMC on this one

So SSL_get_servername() was not documented in 1.1.0, but did exist
in it. It's currently documented as:

   SSL_get_servername() returns a servername extension value
   of the specified type if provided in the Client Hello or NULL.

It's clearly a function intended to be used to select which
certificate should be used, during the negotation. But it seems
that someone uses it after the negotation, or the SNI callback,
and now gets NULL in case SNI was sent but not used.

It at least looks like a misuse of the API, but the documentation
does not say when you can call this function, unlike the
SSL_CTX_set_client_hello_cb() documentation.


Kurt

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


Re: [openssl-project] Current status of our release criteria

2018-09-03 Thread Kurt Roeckx
On Mon, Sep 03, 2018 at 05:54:52PM +0100, Matt Caswell wrote:
> 
> #7058: Process handshake messages after we've send a shutdown
> 
> Awaiting updates from @kroeckx...Kurt will you able to do that soon? Or
> alternatively (if you prefer) I can take this one over.

I was waiting for your feedback, but feel free to take it over.
I'm happy to review such changes.

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


Re: [openssl-project] OpenSSL version 1.1.1 pre release 9 published

2018-08-21 Thread Kurt Roeckx
On Tue, Aug 21, 2018 at 12:36:02PM +, OpenSSL wrote:
> 
>OpenSSL version 1.1.1 pre release 9 (beta)

I've uploaded that version to Debian unstable, so it should get
more testers now.


Kurt

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


Re: [openssl-project] Is this still relevant to OpenSSL?

2018-08-21 Thread Kurt Roeckx
On Mon, Aug 20, 2018 at 04:03:13PM -0700, Paul Dale wrote:
> Abstract: This work provides a systematic analysis of primality testing under 
> adversarial conditions, where the numbers being tested for primality are not 
> generated randomly, but instead provided by a possibly malicious party
> 
> https://eprint.iacr.org/2018/749

We got an early copy of that paper. What that paper mostly says is
that we didn't properly document the amount of rounds required in
case you can't trust the input, the documentation has been
changed to make that more clear.

Related to that, since that paper we have increased the number of
Miller-Rabin rounds, but that work started before we saw that
paper.

As result of that paper I've started working on the Lucas prime
test, for which there is an open PR. I intend to create a
Bailie-PSW test after 1.1.1.


Kurt

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


Re: [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves?

2018-08-17 Thread Kurt Roeckx
On Fri, Aug 17, 2018 at 01:55:13PM +0200, Richard Levitte wrote:
> Personally, I see this as a showstopper re a release on Tuesday

You mean a beta release?


Kurt

___
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 Kurt Roeckx
On Tue, Aug 14, 2018 at 12:16:25PM +, Salz, Rich wrote:
> 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.

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?


Kurt

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

Re: [openssl-project] Releases tomorrow

2018-08-14 Thread Kurt Roeckx
On Tue, Aug 14, 2018 at 01:50:39AM +, Salz, Rich wrote:
> >- 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.

I don't think it's about signals, but about write() returning
EPIPE (or ECONNRESET).


Kurt

___
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 Kurt Roeckx
On Mon, Aug 13, 2018 at 02:00:47PM +0100, Matt Caswell wrote:
> Just a reminder that we are doing the 1.0.2p and 1.1.0i releases
> tomorrow so I will be freezing the repo later this afternoon. If you
> still have PRs to merge for the release please get them in asap!

Any plans for the -pre9?


Kurt

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


Re: [openssl-project] Forthcoming OpenSSL releases

2018-08-12 Thread Kurt Roeckx
On Tue, Aug 07, 2018 at 04:52:28PM +0200, Andy Polyakov wrote:
> >>> Forthcoming OpenSSL releases
> >>> 
> >>
> >> I have some RSA hardening fixes in pipeline...
> > 
> > Do you suggest we wait with a release on that, or can we just put
> > it in the next release?
> 
> I should be able to pull it off in before release. What I'm saying is
> that it would probably be appropriate to review them as they appear.

Is it #6915 you're talking about?

I'm not sure we're going to be able to properly review that before
the releases of 1.0.2 and 1.1.0.


Kurt

___
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-08 Thread Kurt Roeckx
On Wed, Aug 08, 2018 at 08:19:24PM +1000, Tim Hudson wrote:
> We don't have a formal policy of no NULL checks - we just have a few
> members that think we should have such a policy but it has never been voted
> on as we had sufficiently varying views for a consensus approach to not be
> possible.
> 
> Personally I'm in favour of high-level APIs having NULL checks as it (in my
> experience) leads to less bogus error crash reports from users and simpler
> handling in error cleanup logic.
> Otherwise you end up writing a whole pile of if(x!=NULL) FOO_free(x); etc

I think at least Rich would not add checks for NULL in functions
that don't expect to be called with NULL, but on the other hand
moves the NULL check into the free() calls. But in that case, we
also clearly document that it can be called with NULL.

So it's at least not general that there shouldn't be a NULL check.


Kurt

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


Re: [openssl-project] Forthcoming OpenSSL releases

2018-08-07 Thread Kurt Roeckx
On Tue, Aug 07, 2018 at 04:15:52PM +0200, Andy Polyakov wrote:
> > Forthcoming OpenSSL releases
> > 
> 
> I have some RSA hardening fixes in pipeline...

Do you suggest we wait with a release on that, or can we just put
it in the next release?


Kurt

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


Re: [openssl-project] Speaking of broken master, have a look at Travis

2018-07-24 Thread Kurt Roeckx
On Tue, Jul 24, 2018 at 07:54:58PM +0200, Richard Levitte wrote:
> ...
> go test: FAILED (ServerNameExtensionServer-TLS1)
> go test: unexpected failure: local error 'read tcp4 
> 127.0.0.1:41729->127.0.0.1:60574: read: connection reset by peer', child 
> error 'signal: segmentation fault (core dumped)', stdout:

This is caused by https://github.com/openssl/openssl/pull/6378


Kurt

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


Re: [openssl-project] To distribute just the repo file, or the result of 'make dist'?

2018-07-24 Thread Kurt Roeckx
On Tue, Jul 24, 2018 at 02:08:46PM +0200, Richard Levitte wrote:
> 
> The original intention (way back, I think we're even talking SSLeay
> time here, but at the very least pre-1.0.0 time) was to make a tarball
> that can be built directly with just a 'make' on any Unix box and
> without requiring perl.

I don't see how that could work our current system. As far as I
know, it's actually confired for a system, and it will not work
properly on an other. It would just work on the same system as
that we ran config on.

> 1.  Don't release pre-configured tarballs.  This is a very simple
> thing to do, all we have to do is use 'make tar' to create
> tarballs instead of 'make dist'.  We could remove the dist target
> entirely while we're at it.

This makes most sense to me.


Kurt

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


Re: [openssl-project] Open Source Summit Europe

2018-06-19 Thread Kurt Roeckx
On Tue, Jun 19, 2018 at 06:01:19PM +0100, Mark J Cox wrote:
> Just as a FYI in case anyone is interested in an OpenSSL-related
> submission (if you want to do something joint with me, I'm interested
> and local lol).
> 
> > Conference: Open Source Summit Europe
> > Location: Edinburgh
> > Dates: October 22 – 24
> >
> > Deadline for speaking submissions: July 1
> 
> https://events.linuxfoundation.org/events/open-source-summit-europe-2018/

You've suggested to do an OMC meeting there before.


Kurt

___
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 Kurt Roeckx
On Thu, Jun 07, 2018 at 12:07:34PM -0500, Benjamin Kaduk wrote:
> On Thu, Jun 07, 2018 at 05:55:27PM +0200, Andy Polyakov wrote:
> > > Regarding general use of other libraries, please think carefully before 
> > > voting, 'cause this *is* tricky. If you have a look, you will see that we 
> > > *currently* depend on certain standard libraries, such as, for example, 
> > > libdl.
> > 
> > One has to recognize that each dependency has to be justified. Sometimes
> > you don't have a choice. For example if you want to talk network on
> > Solaris, you have to link with -lsocket -lnsl. It's just part of the
> > game. But in cases one has a choice, well, one has a choice to *make*.
> > And key question is how do you anchor it. It's only natural to have as
> > little dependencies as possible, so question is what would justify extra
> > dependency.
> 
> Taking off on a bit of a tangent, how much justification did we go
> through when adding pthreads as a dependency.  I have not been
> following very much (Kurt would know more), but apparently in Debian
> there are some issues regarding (statically linked?) applications
> and libraries that use libcrypto but do not explicitly link with
> -pthread.  "Issues" here being, IIRC, crashes at runtime.

I haven't really followed it, I just saw some mentionng of it on
IRC. At least static linkig glibc itself is complicated. I guess
it's also complicated because libc itself contains stubs for the
pthread functions, so at least the order of the libraries will be
important when linking staticly. But I didn't read anything about
crashes, I might have missed things.


Kurt

___
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 Kurt Roeckx
On Thu, Jun 07, 2018 at 05:19:48PM +0200, Richard Levitte wrote:
> Regarding general use of other libraries, please think carefully before 
> voting, 'cause this *is* tricky. If you have a look, you will see that we 
> *currently* depend on certain standard libraries, such as, for example, 
> libdl. And perhaps we should also mention the pile of libraries used with 
> windows.

We also started depending on pthread in 1.1.0 ...


Kurt

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


Re: [openssl-project] Votes on the use of other libraries in general and iconv in particular

2018-06-07 Thread Kurt Roeckx
On Thu, Jun 07, 2018 at 05:09:52PM +0200, Richard Levitte wrote:
> Mm, I was thinking about it, but then, we have already discussed this in 
> circles on github.

I do not follow everything on github, I had no idea that this was
being discussed.

Someone might have convinced you that it's not the right vote, or
that the wording could be improved.


Kurt

___
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-06 Thread Kurt Roeckx
On Wed, Jun 06, 2018 at 09:45:10AM +0200, Richard Levitte wrote:
> Yup.  It seems that BMPString evolved from UCS-2 into UTF-16 at some
> point

The only thing that evolved from UCS-2 to UTF-16 that I know of is
Microsoft Windows. NT used UCS-2, 2000 changed that to UTF-16.


Kurt

___
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-06 Thread Kurt Roeckx
On Wed, Jun 06, 2018 at 11:23:55AM -0400, David Benjamin wrote:
> 
> Is there a spec citation for this, or some documented experiments against
> other implementations' behavior? (What do Microsoft and NSS do here?) I was
> pondering something similar recently, but things do seem to point at UCS-2
> right now. UCS-2 is indeed an unfortunate historical wart, but X.680 says:

I'm not sure which code I was looking at recently, probably NNS or
gnutls, but it really restricted it to UCS-2.


Kurt

___
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-02 Thread Kurt Roeckx
On Fri, Jun 01, 2018 at 07:08:04PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Jun 1, 2018, at 6:47 PM, Richard Levitte  wrote:
> > 
> > Ah, forgot one important detail:  it is well understood that *all*
> > file based objects will get the same requirements, right?  That goes
> > for anything protected through PKCS#5 as well (good ol' PEM
> > encryption, PKCS#8 objects and whatever else I forget...)
> 
> Canonicalize when importing for use with the store API.  Not sure
> whether wchar_t though, just octet string in UTF-8 seems saner.
> That is the password is an opaque byte string, not a character
> string in the platform's encoding of i18n strings.

Whatever we do, it should be clear that we expect the application
to give us the password in a standardized way, so that we can do
with it what is needed.

If it's something the user types, a password really contains
characters, and so whar_t is really a natural way to pass this. It
would at least be very clear to the application what it needs to
do.

whar_t is part of C89, which is still what we target, so it
should be supported. But then we actually have targets that
will most likely not support this and never will.

So the other solution is that this gets passed in a fixed charset
like UTF-8 or UTF-16.


Kurt

___
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 Kurt Roeckx
On Fri, Jun 01, 2018 at 01:20:17PM -0500, Benjamin Kaduk wrote:
> On Fri, Jun 01, 2018 at 12:23:39PM +, Salz, Rich wrote:
> > >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. 
> 
> I think it's pretty clear (at least to me), that such functions do
> not belong in the normal path.  I'd be open to considering them as a
> fallback attempt to read existing data (as opposed to generating new
> encrypted data), but find Andy's argument about nonpredictability
> (combined with David Woodhouse's enumeration of the various cases
> and the minimal utility of such conversions) to be fairly
> compelling.  That is, I am also against the use of functions that
> depend on the current process's locale in libcrypto.  (I phrase this
> slightly differently, in that functions which take an explicit
> locale to use might still be okay, but are not really portable
> enough for us to use, AIUI.)

So it's my understanding that the library functionw will always
work in UTF-8 then, that's just fine for me.

That would then just mean that the apps need to do the correct
thing and convert it to UTF-8.


Kurt

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


Re: [openssl-project] Travis is currently failing

2018-05-01 Thread Kurt Roeckx
On Tue, May 01, 2018 at 11:52:46AM +0200, Kurt Roeckx wrote:
> On Tue, May 01, 2018 at 10:02:31AM +0100, Matt Caswell wrote:
> > 
> > Can anyone shed any light on this error from travis (master branch is
> > failing):
> > 
> > /usr/bin/ld: unrecognized option '--push-state--no-as-needed'
> > /usr/bin/ld: use the --help option for usage information
> > collect2: error: ld returned 1 exit status
> > make[1]: *** [libcrypto.so] Error 1
> > make[1]: Leaving directory `/home/travis/build/openssl/openssl'
> > make: *** [tests] Error 2
> > +/ MAKE TEST FAILED
> 
> We're also not the only one seeing that problem. We also have the
> problem in the 1.1.0-stable branch for the same configuration.
> I have no idea what changed.

And I can't reproduce it.


Kurt

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


Re: [openssl-project] Travis is currently failing

2018-05-01 Thread Kurt Roeckx
On Tue, May 01, 2018 at 10:02:31AM +0100, Matt Caswell wrote:
> 
> Can anyone shed any light on this error from travis (master branch is
> failing):
> 
> /usr/bin/ld: unrecognized option '--push-state--no-as-needed'
> /usr/bin/ld: use the --help option for usage information
> collect2: error: ld returned 1 exit status
> make[1]: *** [libcrypto.so] Error 1
> make[1]: Leaving directory `/home/travis/build/openssl/openssl'
> make: *** [tests] Error 2
> +/ MAKE TEST FAILED

We're also not the only one seeing that problem. We also have the
problem in the 1.1.0-stable branch for the same configuration.
I have no idea what changed.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Entropy seeding the DRBG

2018-04-30 Thread Kurt Roeckx
On Mon, Apr 30, 2018 at 06:00:20PM +0200, Richard Levitte wrote:
> 
> So I'd like to have it confirmed that I'm reading this right, that's
> about 0.08 entropy bits per 8 data bits?  Or is it per data bit?

Per symbol, being 8 bits for what you provided.

> Depending on the interpretation, we either have 1 bit of entropy per
> 12 data bits...  or per 100 data bits...  The latter has my heart
> sinking...

It's per 100 bits, and that's really still an overestimate. One of
the models they used was able to predict it that well. It might be
possible to create a better model.


Kurt

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


Re: [openssl-project] When to enable TLS 1.3

2018-04-29 Thread Kurt Roeckx
On Sat, Apr 28, 2018 at 04:32:42PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 28, 2018, at 2:41 PM, Kurt Roeckx <k...@roeckx.be> wrote:
> > 
> > So should I send that mail?
> 
> I made some editorial changes to the Wiki section on SNI.
> No strong views on sending the mail...

So I've sent it.


Kurt

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


Re: [openssl-project] Entropy seeding the DRBG

2018-04-23 Thread Kurt Roeckx
On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> In the mean time, I've spent a few days going through the docs on all
> kinds of data that you can get out from the VMS kernel, most notably
> through a system service called sys$getrmi()...  there's a gazillion
> data points, a treasure trove for anyone that's into statistics.  And
> I intend to spend some time trying to estimate what kind of entropy I
> can get out of them...
> 
> ... and that's where Kurt came in:
> 
> > Can I suggest you try something like
> > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
> > get an idea? You would need to sample 1 variable and feed that into
> > it.
> 
> And yeah, sure, especially if all it takes is to produce a stream of
> bits from a source and feed that to the assessment program.  As long
> as I don't have to port a C++11 program to VMS, 'cause unfortunately,
> the existing C++ compiler hasn't had a real update for quite a while
> :-/ (I'm sure that VSI is quite busy updating all they can, but they
> haven't let anything out yet)
> 
> But either way, creating a better entropy gatherer is the longer term
> goal.  I hope I get that part done before the release.

Any update on this?


Kurt

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


Re: [openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)

2018-04-20 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 07:16:04PM -0400, Viktor Dukhovni wrote:
> 
>   * Something else?

We could call for testing what really happens on -users? I could
also send one to debian-devel-announce, we already have pre4 in
experimental.

Maybe we can convert the blog post into a wiki, update it to the
current status, and point people to that.


Kurt

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


Re: [openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)

2018-04-19 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 07:16:04PM -0400, Viktor Dukhovni wrote:
> 
> But not all the friction can be eliminated, and likely not
> all providers can be persuaded to be more accommodating.
> Which leaves us with some difficult judgement calls:
> 
>   * Restrict TLS 1.3 support to just applications compiled
> against 1.1.1?  A weak signal, but likely correlates at
> least somewhat with the application being ready.

Applications get rebuild for all sort of reasons, I don't actually
see this as a good signal at all.

>   * Determine whether the application is likely to be compatible
> at runtime by looking at the provided configuration.  Is SNI
> enabled?  Is the certificate chain weird enough to break with
> TLS 1.3.  Has the application turned off critical algorithms?
> 
>   * Do nothing, let the applications adapt or stick with older
> libraries?

I'm for keeping this as they are now. After the release some
things might break. Applications will adapt.


Kurt

___
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 Kurt Roeckx
On Thu, Apr 19, 2018 at 09:15:19PM +0200, Kurt Roeckx wrote:
> 
> It would also be nice that if the client sends an SNI and you have
> a certificate for it that it wouldn't select an anonymous cipher.
> But then postfix is probably the only one that does anonymous
> ciphers, and if it's not sending SNI this will not change much.

An alternative is that if you think the certificate should be
trusted by the peer you don't select an anonymous cipher.


Kurt

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


  1   2   >