On Mon, Nov 02, 2020 at 03:51:58PM +, Dick Franks wrote:
> On Mon, 2 Nov 2020 at 10:47, Christian Heinrich <
>
>
> > Maybe we should define the problems that new end users experience
> > during onboarding instead and address those first?
> >
>
> Better documentation would help enormously.
On Wed, Oct 14, 2020 at 04:36:39PM +, Salz, Rich wrote:
> On 14/10/2020 17:08, Salz, Rich wrote:
> > I am interested in helping out with the deprecation tasks. Should I
> assume that Richard's PR to change how it's done will be going in?
> >
>
> I'm not sure which of
On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote:
> I had an action from the OTC meeting today to raise a vote on the OTC
> list of technical items still to be done. Here is my proposed vote text.
> There will be a subsequent vote on the "beta readiness checklist" which
> is a separate
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
Hi Tim,
On Sat, Jun 20, 2020 at 10:11:04AM +1000, Tim Hudson wrote:
> I suggest everyone takes a read through
> https://en.wikipedia.org/wiki/Long-term_support as to what LTS is actually
> meant to be focused on.
You may have hit on a key aspect of how we are disconnected, here.
I was under the
On Fri, Jun 19, 2020 at 11:46:15PM +0100, Matt Caswell wrote:
>
>
> On 19/06/2020 23:34, Tim Hudson wrote:
> >
> >
> > On Sat, 20 Jun 2020, 8:14 am Benjamin Kaduk, > <mailto:ka...@mit.edu>> wrote:
> >
> > On Sat, Jun 20, 2020 at 08:11:
On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote:
> The general concept is to only fix serious bugs in stable releases.
> Increasing performance is not fixing a bug - it is a feature.
Is remediating a significant performance regression fixing a bug?
-Ben
On Tue, Jun 16, 2020 at 02:03:58PM +0100, Matt Caswell wrote:
> PR 11188 proposes to backport a series of s390x patches to the 1.1.1
> branch. IIUC it includes performance improvements as well as support for
> new hardware instructions.
>
> I think we need to have a much clearer and more explicit
On Tue, Apr 21, 2020 at 11:10:19AM +0100, Matt Caswell wrote:
> The 3.0 developers met via conference call this morning. All the
> functionality that we had planned for alpha 1 has now been merged, so we
> are now thinking that we will do the alpha 1 release on Thursday this
> week. That would
Hi Martin,
Hopefully this response is still useful a few weeks later.
On Thu, Mar 05, 2020 at 04:10:10PM +0100, Martin Ukrop wrote:
> Hi,
>
> I’m the lead of a university project investigating (and improving) the
> usability of certificate validation errors. Our goal is to simplify the
>
On Fri, Feb 14, 2020 at 05:59:32PM +0100, Tomas Mraz wrote:
> On Fri, 2020-02-14 at 16:17 +, Salz, Rich wrote:
> > I think we should delay the deprecation of engine stuff to 4.0.
> > Personally I don't have sense of stability of provider API.
> >
> > I share this concern. This is the first
On Thu, Jan 16, 2020 at 06:57:49AM +1000, Dr Paul Dale wrote:
> I’m not sure what more I can write.
>
> I proposed the vote text around the time I sent the notification here: no
> comments.
> I created the vote, early in the voting period, the clarification was sought
> and made.
> All OMC
Hi Pauli,
On Tue, Jan 14, 2020 at 09:34:40PM +1000, Dr Paul Dale wrote:
> The OMC vote is closed.
>
> The vote text being:
>
> The legacy provider should be disabled by default in 3.0
>
> With the clarification that "disabled" in this context means "not loaded”.
>
> The vote passed (two for,
On Sun, Dec 15, 2019 at 08:25:02PM +, Dr. Matthias St. Pierre wrote:
> Gentle reminder: it's almost a month since a started this thread, but the
> external pyca and krb5
> tests are still failing. Apart from complicating the review process, it also
> happens that people
With apologies for
On Wed, Nov 27, 2019 at 10:38:41AM +0100, Richard Levitte wrote:
> Depending on who you're asking, you get different responses.
>
> The topic is: should we check pointers coming from applications before
> using them or not?
>
> There are two positions on this:
>
> 1. Yes we should so we don't
On Mon, Nov 18, 2019 at 10:12:52PM +, Matt Caswell wrote:
>
>
> On 18/11/2019 21:48, 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?
> > My personal
Hi all,
I note that 1.1.0 goes EOL on 2019-09-11, and the current 1.1.0k release is
from the end of May. On the normal 3-ish-month cycle for letter releases
(to "roll up" accumulated changes in the absence of a security release), we
would be having one soon. Are there any plans to do a final
On Mon, Jul 15, 2019 at 02:19:22PM +0100, Matt Caswell wrote:
>
>
> On 15/07/2019 13:58, Tomas Mraz wrote:
>
> >
> > I understand that for the current digest algos implemented in the
> > legacy provider the problem might not be as pressing as these
> > algorithms are not widely used however
On Tue, Mar 26, 2019 at 02:20:28PM +0100, Kurt Roeckx wrote:
> 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
I also like the provider data approach.
-Ben
On Sat, Mar 23, 2019 at 09:11:23AM +1000, Dr Paul Dale wrote:
> I’ve no issue having a provider data field there. It will be useful for more
> than just this (S390 AES e.g. holds data differently to other
> implementations).
>
> I also don’t think
On Wed, Feb 13, 2019 at 03:28:30PM -0500, Michael Richardson wrote:
>
> Matt Caswell wrote:
> > Please see my blog post for an OpenSSL 3.0 and FIPS Update:
>
> > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
>
> Thank you, it is very useful to have these plans made up
On Wed, Jan 30, 2019 at 09:02:30AM +0100, Kurt Roeckx 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
On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote:
> On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx 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
On Mon, Jan 28, 2019 at 07:10:55AM +0100, Richard Levitte wrote:
> On Mon, 28 Jan 2019 06:17:35 +0100,
> Dr Paul Dale wrote:
> > Richard wrote:
> >
> > Not really, since they are static inline. This is by design, that for
> > any file you want to use
> > a safestack in, you just start
Between last time we discussed it and now, waiting seems to have been
prudent, as the TLS/QUIC interaction got significantly revamped.
The current QUIC drafts have TLS exporting key material and plaintext
handshake messages, with QUIC record protection used on the wire and not
TLS record
I would guess that the misbehaving clients are early openssl betas
that receive the real TLS 1.3 version and then try to interpret
as whatever draft versino they actually implemnet.
-Ben
On Thu, Oct 11, 2018 at 01:18:03PM -0400, Viktor Dukhovni wrote:
>
> Apparently, some SMTP clients set
On Sat, Sep 22, 2018 at 01:02:29AM -0400, Viktor Dukhovni wrote:
>
>
> > On Sep 22, 2018, at 12:59 AM, Richard Levitte wrote:
> >
> > So in summary, do we agree on this, and that it's a good path forward?
> >
> > - semantic versioning scheme good, we should adopt it.
> > - we need to agree on
On Sat, Sep 22, 2018 at 01:12:21AM -0400, Viktor Dukhovni wrote:
>
>
> > On Sep 22, 2018, at 12:50 AM, Tim Hudson wrote:
> >
> > The impact of the breaking change on anyone actually following our
> > documented encoding cannot.
> > i.e. openssh as one example Richard pointed out.
>
> The
penssl/openssl/pull/7158
>
> *** CID 1201571: Error handling issues (CHECKED_RETURN)
> todo
>
> if anybody wants to fix one of the CIDs marked 'todo', no problem. Just drop
> a note on the openssl-project list.
>
> Matthias
>
>
> > -Ursprüng
On Wed, Sep 05, 2018 at 11:59:34PM +0100, Matt Caswell wrote:
> Today's update is that we still have 6 open PRs for 1.1.1. 5 of these
> are the same as yesterday. The 1 that was marked as "ready" yesterday
> has now been merged, and a new PR addressing issue #7014 has been opened.
>
> There are
On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote:
> There are 2 open issues for 1.1.1. One of these is being addressed by
> PR#7073 above. The other one is:
>
> #7014 TLSv1.2 SNI hostname works in 1.1.0h, not in 1.1.1 master (as of
> 18-Aug)
>
> This one seems stuck!! No clear way
On Fri, Aug 17, 2018 at 06:39:54PM +0200, Richard Levitte wrote:
> In message <20180817162909.ga10...@roeckx.be> on Fri, 17 Aug 2018 18:29:09
> +0200, Kurt Roeckx said:
>
> kurt> On Fri, Aug 17, 2018 at 01:55:13PM +0200, Richard Levitte wrote:
> kurt> > Personally, I see this as a showstopper
On Tue, Jul 24, 2018 at 08:34:28PM +0200, Kurt Roeckx wrote:
> 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:
On Tue, Jul 24, 2018 at 02:28:40PM +0200, Kurt Roeckx wrote:
> 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
On Tue, Jun 26, 2018 at 07:43:45PM +, Salz, Rich wrote:
> That's interesting. Would we put a bugfix in 1.1.0, not put the fix in 1.1.1
> until our first "a" release?
>
> Or are you saying that if it's in 1.1.0, then we don't have to fix it until
> after 1.1.1 comes out? That seems
On Tue, Jun 26, 2018 at 04:56:26PM +0100, Matt Caswell wrote:
> I'm thinking that we should maybe re-asses the current milestones in github.
>
> We currently use the following milestones:
>
> Assessed - Anything against this milestone isn't relevant to the 1.1.1
> release (e.g. 1.0.2 specific
On Wed, Jun 20, 2018 at 10:29:37PM +0200, Richard Levitte wrote:
> In message on Wed, 20 Jun
> 2018 19:59:02 +, "Dr. Matthias St. Pierre"
> said:
>
> Matthias.St.Pierre> III) VERSION NUMBER LABELS
> Matthias.St.Pierre>
> Matthias.St.Pierre> It seems like the version number labels
On Fri, Jun 01, 2018 at 06:52:21PM +, Salz, Rich wrote:
> Our INSTALL doesn’t mention it. We have config’s for it. I think we should
> say we support it and update the various docs. Thoughts?
The PR associated with the thread around
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
On Wed, May 23, 2018 at 03:12:30PM +, Dr. Matthias St. Pierre wrote:
> > So do you guys use the ghmerge script or own procedures? I'm curious.
>
> At the beginnning, I tried to use ghmerge but it was not flexible
> enough for my needs. In particular, it only gives me the choice
> between
On Wed, May 23, 2018 at 12:43:58AM +, Salz, Rich wrote:
> > I do the same, but I am reluctant having a script doing it for me using
> some fixed recipe...
>
> >I'm happy doing the build/test manually before merging, too.
>
>
> So do you guys use the ghmerge script or own
On Tue, Apr 24, 2018 at 10:21:28AM -0400, Viktor Dukhovni wrote:
>
>
> > On Apr 24, 2018, at 9:29 AM, Benjamin Kaduk <ka...@mit.edu> wrote:
> >
> > To be clear, the current draft explicitly says "Servers SHOULD issue
> > new tickets wi
On Mon, Apr 23, 2018 at 09:34:18PM -0400, Viktor Dukhovni wrote:
>
>
> > On Apr 22, 2018, at 9:49 PM, Viktor Dukhovni
> > wrote:
> >
> > - Client-side diagnostics -
>
> On the server side I see that even when the ticket callback returns "0" to
> accept
On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote:
> > This is one reason why keeping around old assembly code can have a cost. :(
> >
> > https://github.com/openssl/openssl/pull/5320
>
> There is nothing I can add to what I've already said. To quote myself.
> "None of what I say
On Thu, Mar 29, 2018 at 12:15:39PM +0200, Richard Levitte wrote:
> In message <4e32b364-3ed3-9101-158c-09338f96e...@openssl.org> on Thu, 29 Mar
> 2018 11:06:46 +0100, Matt Caswell said:
>
> matt> How about this for the vote text:
> matt>
> matt> "Feature changes in 1.1.1
On Wed, Mar 21, 2018 at 12:27:13AM +1000, Tim Hudson wrote:
> We have been holding off on post-1.1.1 feature development for a long time
> now - on the grounds that TLSv1.3 was just around the corner etc and the
> release was close - and then we formed a release plan which we pushed back
> a week.
On Wed, Mar 14, 2018 at 01:27:47AM +0100, Kurt Roeckx wrote:
> My solution is to just have 1 master DRBG, and a public and
> private DRBG per thread. The only lock that then is needed is when
> the public or private DRBG needs to reseed. All the rest of the
> code can stay just as it is, but we
mean another PR?
Yup, I meant #3802, sorry.
(tmshort is my team lead at work)
> #3958 approved (in case Richard doesn't get back to it)
> #1130 approved
> #3958 approved
Thanks!
-Ben
> Tim.
>
>
>
> On Wed, Mar 7, 2018 at 2:40 PM, Benjamin Kaduk <ka...@mit.edu>
On Wed, Mar 07, 2018 at 01:20:41AM +, Salz, Rich wrote:
> I think we should make sure to set aside time to review as many of the
> non-project pull requests as possible. I think it is important to show a
> commitment to the larger community.
I agree. I started looking at this last week,
On Sun, Mar 04, 2018 at 05:30:32PM +0100, Kurt Roeckx wrote:
> On Sun, Mar 04, 2018 at 02:44:01PM +, Salz, Rich wrote:
> > I also intend to merge the config file .include PR (5351), and I want us to
> > decide about 4848.
>
> I have to agree that I want to resolv 4848 (reading config file to
Hi all,
There's a pull request open against the TLS 1.3 spec to include the
record header in the AAD for record protection
(https://github.com/tlswg/tls13-spec/pull/1158). We're somewhat on
the fence about this, with the main advantage seeming to be for DTLS
and not plain TLS, but it would
On Sat, Feb 03, 2018 at 11:40:42PM +, Salz, Rich wrote:
> We have cleaned up and posted the release tools as part of the tools
> repository. Thanks to Richard Levitte for a great deal of feedback and
> review.
>
> I had thought someone opened an issue for this, but I can’t find it; anyone
On Tue, Jan 30, 2018 at 04:14:52PM +, Matt Caswell wrote:
>
>
> On 30/01/18 16:13, Salz, Rich wrote:
> > One of our own, Ben Kaduk, was just picked to be the Security Area
> > co-Director in the IETF!
>
> Awesome! Well done Ben!
Thanks!
It does seem likely to imply that I will be spending
It seems that we've started getting issues with a single build
configuration, e.g.,
https://travis-ci.org/openssl/openssl/jobs/335110257
Lots of complaints about alignment, like:
crypto/modes/gcm128.c:1090:36: runtime error: load of misaligned
address 0x02350ce5 for type 'const size_t' (aka
On Tue, Jan 23, 2018 at 06:11:50PM +, Matt Caswell wrote:
>
>
> On 23/01/18 18:05, Benjamin Kaduk wrote:
> > On Tue, Jan 23, 2018 at 05:51:41PM +, Matt Caswell wrote:
> >>
> >>
> >> On 23/01/18 17:49, Matt Caswell wrote:
> >>> I comp
On Tue, Jan 23, 2018 at 05:51:41PM +, Matt Caswell wrote:
>
>
> On 23/01/18 17:49, Matt Caswell wrote:
> > I completed my first pass review of all issues. I still need to look at
> > PRs. I have put all PRs against a milestone using the following criteria:
>
> I have put all *issues*
56 matches
Mail list logo