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 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 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 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 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, 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
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 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
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
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 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, 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, 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 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
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 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*
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 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,
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 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
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 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 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 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
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
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
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
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
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 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
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 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 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
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 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
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 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 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,
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 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
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
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 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 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:
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 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.
56 matches
Mail list logo