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

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

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

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

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

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

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

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 s

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

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

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.

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

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

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

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

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

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 d

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

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

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

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

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

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

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

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 ci

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

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

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

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

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 >

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 >

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

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 try

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

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 k

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

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

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

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,

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

[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

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

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

[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

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

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 ___

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

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,

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

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 >

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

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

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

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?

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

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.

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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 vie

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

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

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

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

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 02:02:53PM -0400, Viktor Dukhovni wrote: > > > > On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni > > wrote: > > > > There is no "the name that is being verified". The Postfix SMTP client > > accepts multiple (configurable as a set) names for

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

2018-04-19 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 09:58:26AM +0200, Richard Levitte wrote: > When someone with write access to the main repo makes a PR and it gets > approved, we usually wait for the person to do the final merge. This is also what we agreed to do a long time ago, including that for PRs of a non-commiter,

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

2018-04-18 Thread Kurt Roeckx
On Wed, Apr 18, 2018 at 11:05:05AM -0400, Viktor Dukhovni wrote: > > What I can blame them for is being counter-productively pedantic. Forget the > RFC language, does what they're doing make sense and improve security or is > it just a pointless downgrade justified by RFC text lawyering? I'm

Re: [openssl-project] Constant time by default

2018-04-17 Thread Kurt Roeckx
On Mon, Apr 16, 2018 at 06:06:33PM +0100, Matt Caswell wrote: > > As I say in the PR (marked as WIP) I am seeking feedback as to whether > this is something we should pursue now (i.e. for 1.1.1) or later (post > 1.1.1) or not at all. A related question I have is, do we consider this security

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

2018-04-15 Thread Kurt Roeckx
On Sun, Apr 15, 2018 at 07:38:48AM +0200, Richard Levitte wrote: > In message on Sat, 14 Apr > 2018 21:13:47 +, "Salz, Rich" said: > > rsalz> We have *no* data points, except our tests, that anything fails to > work. >

  1   2   >