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

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

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] Open Source Summit Europe

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] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

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] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

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)

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)

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] Travis is currently failing

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

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

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

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] Style guide updates

On Sat, Jan 27, 2018 at 01:03:04PM +0100, Kurt Roeckx wrote: > > It's just that there seem to be 2 camps, one saying that all types > should be signed except when it's to access the bits. The other > that a size can't be negative so you go for an unsigned type. If > it's a signed

Re: [openssl-project] Style guide update -- summary so far

On Mon, Feb 05, 2018 at 08:43:04PM +0100, Dr. Matthias St. Pierre wrote: > > > Am 05.02.2018 um 19:13 schrieb Salz, Rich: > > > > > > Do not put a size after sizeof; do use parens. > > > > nit: Do not put a /space /after sizeof. > > > > > > > Treat a single-statement with comment as if it

Re: [openssl-project] VOTE on travel reimbursement policy

On Wed, Feb 14, 2018 at 04:06:44PM +, Salz, Rich wrote: > The policy is in the bureau (not a public repo) so that we have something > concrete to vote on. It is exactly the same as I posted to the project list > before. I would like to see all votes contain the full text and not a

Re: [openssl-project] VOTE on travel reimbursement policy

On Wed, Feb 14, 2018 at 10:40:29PM +0100, Richard Levitte wrote: > In message <20180214212414.ga13...@roeckx.be> on Wed, 14 Feb 2018 22:24:14 > +0100, Kurt Roeckx <k...@roeckx.be> said: > > kurt> The call for votes should probably also not go to the project list &g

Re: [openssl-project] Removal of NULL checks

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] Releases tomorrow

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] Forthcoming OpenSSL releases

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] Forthcoming OpenSSL releases

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] Releases tomorrow

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] Fractional seconds, etc.

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] Late thoughts on the 1.1.1 release - are we fooling ourselves?

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] Is this still relevant to OpenSSL?

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] OpenSSL version 1.1.1 pre release 9 published

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] Speaking of broken master, have a look at Travis

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] Release Criteria Update

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] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

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] VOTE report: Push the release of 1.1.1 beta1 (pre3) forward one week

On Sat, Mar 10, 2018 at 11:45:46AM +0100, Richard Levitte wrote: > Vote text: > > NOTE: THREE DAY VOTE > Why? Because beta1 is currently scheduled to be released in three > days. A longer voting period would hold the release hostage in > practice, and thereby force a push of the release date

Re: [openssl-project] DRBGs, threads and locking

On Wed, Mar 14, 2018 at 12:49:46PM +, Salz, Rich wrote: > So is having a high-quality, lockless (per-thread) CSPRNG good enough for > now? Phrased like that, I think so. We have enough other stuff to do. So > +1 to Kurt's per-thread approach. I think it's better than what we have in

[openssl-project] DRBGs, threads and locking

So Tim has voted -1 on PR #5547 and wants us to discuss it here and vote on it. I don't know if it's clear to everybody what this is about. If something is not clear, please ask. PR #5461 contains a lot of documentation updates that is related to it, and it might be useful to read it as

Re: [openssl-project] Entropy seeding the DRBG

On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote: > In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 18:00:32 > +0200, Kurt Roeckx <k...@roeckx.be> said: > > kurt> On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote: > k

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote: > In message <20180407154649.ga12...@roeckx.be> on Sat, 7 Apr 2018 17:46:50 > +0200, Kurt Roeckx <k...@roeckx.be> said: > > kurt> | For case 2 above, the timestamp must be trusted. A trusted >

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

On Sat, Apr 07, 2018 at 04:48:51PM +, Salz, Rich wrote: > >Like I said in the post I just made, I see zero problems with having > that requirement on systems that can support it. I don't see why we > must lower the bar for *everyone* just because we currently need to do > so

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote: > > Because > > - It is not clear we need to do so > > >That we need to do what? > > Do FIPS compliant random numbers in this release. We will never have that in any release by default, like I already stated a

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

On Sun, Apr 08, 2018 at 10:31:58AM +0200, Richard Levitte wrote: > In message <20180408080942.gb3...@roeckx.be> on Sun, 8 Apr 2018 10:09:42 > +0200, Kurt Roeckx <k...@roeckx.be> said: > > kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote: > kurt

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote: > In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 21:02:51 > +0200, Kurt Roeckx <k...@roeckx.be> said: > > kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote: > kurt

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote: > On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote: > > > Because > > > - It is not clear we need to do so > > > > >That we need to do what? > > > >

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

On Sun, Apr 08, 2018 at 08:29:18PM +, Dr. Matthias St. Pierre wrote: > Just for completeness sake: The entropy requirement is 256 and *not* 384 if a > derivation function is used. But one way of implementing the nonce when a DF is not used, is to also have 384 bit in that case, which is our

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

On Sun, Apr 08, 2018 at 07:15:16PM +0200, Richard Levitte wrote: > > > Kurt Roeckx <k...@roeckx.be> skrev: (8 april 2018 17:36:27 CEST) > >On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote: > >> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Ri

Re: [openssl-project] Entropy seeding the DRBG

On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote: > kurt> I wonder if it's useful to have a thread of VMS that collects > kurt> such bits all the time, like the kernel is doing. > > I was pondering something like that, and it does make sense. That, or > creating a generic device

Re: [openssl-project] Entropy seeding the DRBG

On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote: > > 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

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

On Sat, Apr 14, 2018 at 09:54:41PM +0200, Richard Levitte wrote: > Yes, I agree that the TLSProxy tests aren't the most important in this > regard. Also note that this part was a side note. Can you then find examples of what a normal user of the library might be expected to do that fails? I

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

On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote: > > a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests >that are meant to fail (i.e. if the individual tests fail, the >recipe is successful). When run against 1.1.1 libraries, the >recipe fails, i.e.

Re: [openssl-project] Constant time by default

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] Potentially bad news on TLS 1.3 compatibility (sans SNI)

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] The problem of (implicit) relinking and changed behaviour

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

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

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] When to enable TLS 1.3 (was: Google's SNI hurdle)

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] Entropy seeding the DRBG

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] Potentially bad news on TLS 1.3 compatibility (sans SNI)

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] Potentially bad news on TLS 1.3 compatibility (sans SNI)

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] When to enable TLS 1.3 (was: Google's SNI hurdle)

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] Entropy seeding the DRBG

On Tue, Apr 03, 2018 at 12:52:50PM +, Salz, Rich wrote: > I had not realized that we just increased the “entropy” requirements by 50%, > from 256 to 384. The original DRBG submission that I did only required 128 > bits. I think that is wrong, and I think the PR that did it (#5503) should >

Re: [openssl-project] Next release is beta1

On Fri, Mar 02, 2018 at 11:09:30AM +, Matt Caswell wrote: > Just a reminder, in case anyone missed it, that our next planned release > on 13th March is beta1. This means we will be calling a feature freeze > for 1.1.1 and we will create the new branch. If you've got any > outstanding feature

Re: [openssl-project] Next release is beta1

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 select things like supported ciphers.) An other important change is

Re: [openssl-project] dropping out

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] Current priorities

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] Random devices in chroot environments revisited

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

[openssl-project] Minimum C version

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] Minimum C version

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

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

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

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] Release strategy updates & other policies

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

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

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

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

[openssl-project] Current priorities

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] inline functions

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] Proposed vote text for the SSL_CB_HANDSHAKE_START change

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

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

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

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] Proposed vote text for the SSL_CB_HANDSHAKE_START change

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: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

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

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

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

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

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

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: Start up entropy gathering

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 >

Vote proposal: votes should get discussed first

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: Do we really want to have the legacy provider as opt-in only?

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: Thread sanitiser problems

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: Thread sanitiser problems

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: Do we really want to have the legacy provider as opt-in only?

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: Two Travis Jobs are failing on master

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

New audit before 3.0 release

Should we let someone do a new audit before the 3.0 release? Kurt

Re: Build failures on master?!

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

Re: Deprecations

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)

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

Deprecations

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

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

Re: Deprecations

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

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: crypt(3)

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: crypt(3)

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)

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

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: Improving X.509 certificate validation errors

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: Unexpected EOF handling

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

  1   2   >