On Wed, Dec 08, 2021 at 09:17:05AM +0100, Tomas Mraz wrote:
> On Tue, 2021-12-07 at 19:18 +0100, Kurt Roeckx wrote:
> > On Tue, Dec 07, 2021 at 10:35:02AM +, Matt Caswell wrote:
> > > topic: Accept PR #16705 into 3.0 subject to the normal review
> > > process
>
On Tue, Dec 07, 2021 at 10:35:02AM +, Matt Caswell wrote:
> topic: Accept PR #16705 into 3.0 subject to the normal review process
-1
>From what I understand, this breaks our provider API. Providers
that work with 3.0.0 will not work when that PR is applied, and
providers that do the same impl
Hi,
The following vote passed with 6 in favour, 0 against, 0 abstain:
topic: All committers to the main source repository must enable 2 factor
authentication
on GitHub Enterprise when it is moved there
We plan to move all repositories from git.openssl.org to
github.openssl.org which uses Github
On Mon, Nov 01, 2021 at 11:23:15AM +0100, Tomas Mraz wrote:
> topic: Accept openssl/technical-policies PR#1 - the policy change
> process proposal as of commit 3bccdf6. This will become an official OTC
> policy.
>
> comment: This will implement the formal policy change process so we can
> introduc
On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote:
> topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the
> normal review process
+1
Kurt
On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote:
> topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the
> normal review process
So we have various people voting -1. Does someone want to explain
why they vote -1?
Kurt
> I would like to also discuss code coverage, and in particular adding tests
> for any new code that is added.
It was always my understanding that our policy was that tests need
to be added. We have a checkbox in the pull request to indicate
that it's been done. But maybe it's not written down in
On Thu, Sep 23, 2021 at 09:42:01PM +0200, Dmitry Belyavsky wrote:
> Hello Matt,
>
> The link
> https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-processmodules-in-process-list
> (You can see the official listing for the submission *here*) seems to be
> not working
On Tue, Sep 21, 2021 at 06:37:42PM +0200, Tomas Mraz wrote:
> On Tue, 2021-09-21 at 18:32 +0200, Kurt Roeckx wrote:
> > On Tue, Sep 21, 2021 at 07:14:51PM +1000, Dr Paul Dale wrote:
> > > Accept PR#16594 into master subject to the normal review process
> > >
> >
On Tue, Sep 21, 2021 at 11:08:40AM +0100, Matt Caswell wrote:
> topic: Increase the default security level from 1 to 2 in master
+1
Kurt
On Tue, Sep 21, 2021 at 07:14:51PM +1000, Dr Paul Dale wrote:
> Accept PR#16594 into master subject to the normal review process
>
>
>
> This doesn't meet the "is a standard" requirement but it is in use and we
> have the implementation. It just isn't exposed.
Can you describe where it is in u
On Tue, Sep 14, 2021 at 11:13:13AM +0100, Matt Caswell wrote:
> topic: Allow the restart of merging of non-breaking small features to the
> master
>branch
+1
Kurt
time as
> we can compare the approaches in concrete form and then we can make a
> decision - but that would be accepting one PR over another PR. We have had
> "competing" PRs regularly - and we then vote on the alternatives - where it
> is clear what the alternatives are. A sin
On Tue, Aug 17, 2021 at 02:19:08PM +0100, Matt Caswell wrote:
> topic: Accept PR#16286 into 3.0 subject to the normal review process
-1
Do we need some general policy for such changes after the 3.0
release?
Kurt
On Wed, Aug 11, 2021 at 09:53:14PM +0300, Nicola Tuveri wrote:
> On the other hand, 1.1.1 is not in its last year of support so it is not
> limited to security fixes only.
>
> The commits which this vote proposes to revert fixed a bug that produced
> invalid output from functions with a clear inte
On Tue, Aug 10, 2021 at 11:53:23AM +0100, Matt Caswell wrote:
> topic: Revert the commits merged from PR #16027 in 1.1.1
+1
Kurt
On Tue, Aug 10, 2021 at 11:54:19AM +0100, Matt Caswell wrote:
> topic: RSA public exponent validation in 3.0 for the default provider should
> be
> consistent with 1.1.1
I think this is one of those conflicts between providing a general
crypto library, and providing something that is secure by def
On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote:
>
> This isn't about the OTC meeting itself - this is about the details of the
> topic actually being captured within the PR.
> You need to actually look at the PR to form a view. And we do add to the
> PRs during the discussion if things
On Tue, Jul 27, 2021 at 10:11:53AM +0100, Matt Caswell wrote:
> topic: OTC approve the release of 3.0 beta2 on Thursday 29th July
+1
Kurt
On Tue, Jul 27, 2021 at 10:10:27AM +0100, Matt Caswell wrote:
> topic: Accept PR 16050 in 3.0 subject to our normal review process
> Proposed by Tim Hudson
> Public: yes
> opened: 2021-07-20
> closed: 2021-07-27
> accepted: no (for: 1, against: 3, abstained: 4, not voted: 1)
I don't find a call
On Thu, Jul 22, 2021 at 01:51:27PM +0100, Matt Caswell wrote:
> topic: Accept PR 16128 in 3.0 subject to our normal review process
+1
Kurt
On Tue, Jul 20, 2021 at 11:18:27AM +0100, Matt Caswell wrote:
> topic: We should accept PR #16118 into 3.0 when completed and subject to the
>normal review process
This already seems to be merged, so I'll vote 0.
Kurt
> topic: We should fix the issue described in #16088 for 3.0
After reading #16088, I have no idea what this vote means, so I
will vote -1.
Please stop referring to a github issue or pull request as vote
text and actually describe what we're voting on.
Since this describes a regression against 1.
On Tue, Jul 13, 2021 at 11:24:55AM +0100, Matt Caswell wrote:
> topic: Allow the addition of EVP_PKEY_get0_provider() and
>EVP_PKEY_CTX_get0_provider() calls in 3.0
-1
Kurt
On Tue, Jul 06, 2021 at 10:26:13AM +0100, Matt Caswell wrote:
> topic: Remove ERR_GET_FUNC in 3.0
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2021-07-06
> closed: 2021-07-06
> accepted: yes (for: 6, against: 1, abstained: 0, not voted: 2)
There seem to be no good solutions here, so I'm v
On Tue, Jun 29, 2021 at 10:48:25AM +0100, Matt Caswell wrote:
> topic: We will allow enabling of __owur specifiers for functions for 3.0 as
> a
>safe API-change exception.
If this was proposed before the beta, I would be happy with such a
change. But at some point we need to stop changing
On Tue, Jun 29, 2021 at 10:49:36AM +0100, Matt Caswell wrote:
> topic: Accept the API additions from pull request #15790 subject to the
> normal
>review process
It seems this is even already merged, so I'll vote 0.
Kurt
On Tue, Jun 29, 2021 at 10:50:36AM +0100, Matt Caswell wrote:
> topic: Accept PR #15763 for 1.1.1 subject to the normal review process
+1
Kurt
On Tue, Jun 15, 2021 at 10:53:03AM +0100, Matt Caswell wrote:
> topic: OTC approve the release of 3.0 beta1 on Thursday 17th June on the
> basis
>that: 1) all current approved PRs with the beta1 milestone are merged
>2) issues #15755 and #15756 are resolved 3) We accept that VMS doe
On Tue, Apr 20, 2021 at 01:23:56PM +0300, Nicola Tuveri wrote:
> Following up on
> https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html we
> had a discussion on this during last week OTC meeting, and opened a vote
> limited exclusively to the matter of rejecting PR#14759.
>
> We
On Tue, Apr 20, 2021 at 12:17:17PM +0200, Tomas Mraz wrote:
> topic: Set PR 13817 milestone to Post 3.0
0
Kurt
On Tue, Apr 20, 2021 at 12:15:19PM +0200, Tomas Mraz wrote:
> topic: Set issue 11164 milestone to Post 3.0
> Proposed by Tim Hudson
> Public: yes
> opened: 2021-04-20
> closed: 2021-04-20
> accepted: yes (for: 6, against: 1, abstained: 0, not voted: 4)
-1
Kurt
Hi,
I just found this in votes.txt, it looks like it was not mailed to
the list as required.
topic: EVP_PKEY types are immutable once set. Types cannot be changed once
set. To move from one type to another compatible type will require
export/import.
Comment: This will result in brea
On Tue, Mar 23, 2021 at 09:12:40AM +, Matt Caswell wrote:
> This vote has now closed:
>
> accepted: yes (for: 5, against: 1, abstained: 1, not voted: 4)
It seems unclear to me that you can close the vote at this time.
The result is not clear, the 4 people who didn't vote can vote -1
in whic
On Tue, Mar 09, 2021 at 10:24:32AM +, Matt Caswell wrote:
> topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This
>should be documented.
+1
Kurt
On Wed, Mar 10, 2021 at 05:44:22AM +0200, Nicola Tuveri wrote:
> Yes, in 1.1.1j the following is possible:
>
> - SM2 cryptosystem operations over the "SM2 curve"
> - SM2 cryptosystem operations over arbitrary curve (including NIST ones)
> - ECDSA/ECDH cryptosystem operations over the "SM2 curve"
On Tue, Mar 09, 2021 at 03:57:32PM +0200, Nicola Tuveri wrote:
> It is tangent to the vote in itself, but I'd like to highlight that in part
> this vote is motivated by getting rid of cases where there is a need to
> convert between compatible key types (e.g. SM2 & EC, DH & DHX).
>
> The vote of t
On Tue, Mar 09, 2021 at 10:25:50AM +, Matt Caswell wrote:
> topic: EVP init functions take an OSSL_PARAM array to set parameters and
> this
>should be reflected in the equivalent provider interface.
+1
Kurt
On Tue, Mar 09, 2021 at 10:25:50AM +, Matt Caswell wrote:
> topic: EVP init functions take an OSSL_PARAM array to set parameters and
> this
>should be reflected in the equivalent provider interface.
I need more information than the vote text to be able to vote on
this.
Kurt
On Tue, Mar 02, 2021 at 10:20:30AM +, Matt Caswell wrote:
> topic: EVP_PKEY_get0 functions will return a cached copy of the legacy key,
> and
> will be changed to return const. EVP_PKEY_get1 functions work as per
> EVP_PKEY_get0 but are not const returns and up the reference count
> Comment: Se
On Tue, Feb 23, 2021 at 11:21:41AM +0100, Tomas Mraz wrote:
> topic: The RSA_SSLV23_PADDING and related functions should be
> completely removed from OpenSSL 3.0 code.
+1
Kurt
On Tue, Dec 15, 2020 at 08:45:45AM +0100, Richard Levitte wrote:
> Whatever we decide on this, I would rather not burden provider authors
> with having to check for all sorts of things they aren't interested in.
I think you write the provider just a little bit different than
what you might be doin
On Tue, Dec 15, 2020 at 08:40:03AM +0100, Dmitry Belyavsky wrote:
>
> There are 2 variants of using OpenSSL.
> 1. Algorithm-agnostic. We can deal with most of the algorithms in a more or
> less similar way.
> That was the way we dealt with various algorithms in libcrypto since 1.0
> version.
>
>
On Mon, Dec 14, 2020 at 08:20:29PM +0100, Dmitry Belyavsky wrote:
> Dear Kurt,
>
>
> On Mon, Dec 14, 2020 at 3:59 PM Kurt Roeckx wrote:
>
> > Hi,
> >
> > doc/man3/OSSL_PARAM.pod current says:
> > Keys that a I or I doesn't recognise should
> >
Hi,
doc/man3/OSSL_PARAM.pod current says:
Keys that a I or I doesn't recognise should
simply be ignored. That in itself isn't an error.
The intention of that seems to be that you just pass all the data
you have, and that it takes data it needs. So you can pass it data
that it doesn't need because
On Fri, Dec 04, 2020 at 01:45:07PM +0100, Tomas Mraz wrote:
> topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable
>with 1.1.1 EVP_PKEY API or low level APIs without public component must
>stay usable.
>
>This overrules the
> * all implementa
On Mon, Nov 30, 2020 at 02:03:15PM +0200, Nicola Tuveri wrote:
> Vote text
> -
>
> topic: In the context of the OpenSSL apps, the OTC qualifies as bug
>fixes the changes to return a failure exit status when a called
>function fails with an unhandled return value.
>E
On Fri, Nov 27, 2020 at 12:42:44PM +0100, Felix Bünemann wrote:
> Hi Kurt,
>
> > Am 26.11.2020 um 18:57 schrieb Kurt Roeckx :
> >
> > On Wed, Nov 25, 2020 at 09:17:13PM +0100, Felix Bünemann wrote:
> >>
> >> It is also unique cause it requires no co
On Wed, Nov 25, 2020 at 09:17:13PM +0100, Felix Bünemann wrote:
>
> It is also unique cause it requires no code changes to support a new platform.
In a previous discussion we have talked about when a platform can
be added in an LTS release. I think that in general if it's only
configuration chang
On Tue, Nov 24, 2020 at 01:51:44PM +0200, Nicola Tuveri wrote:
> Background
> --
>
> This follows up on a [previous proposal] that was abandoned in favor of
> an OMC vote on the behavior change introduced in [PR#13359].
> Within today's OTC meeting this was further discussed with the atten
On Tue, Nov 03, 2020 at 12:11:27PM +, Matt Caswell wrote:
>
> The proposal discussed was that while relaxing the conceptual model,
> most of the existing implementations would still require both. The EC
> implementation would be relaxed however. This essentially gives largely
> compatible beha
Hi,
It seems that we might start to interprete the no-xxx options
differently. In 1.1.1 it would completly disable the feature in
libcrypto, the apps and libssl. It seems that now the
interpretation changed to just disable the support for it in the
provider. You might load a different provider tha
On Fri, Oct 09, 2020 at 02:02:29PM +0200, Tomas Mraz wrote:
> topic: The PR #11359 (Allow to continue with further checks on
> UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
> As the change is borderline on bug fix/behaviour change OTC needs
> to decide whether it is acceptable fo
On Thu, Oct 08, 2020 at 03:47:18PM +0100, Matt Caswell wrote:
> topic: The following items are required prerequisites for the first beta
> release:
> 1) EVP is the recommended API, it must be feature-complete compared with
> the functionality available using lower-level APIs.
>- Anything t
On Fri, Oct 09, 2020 at 03:00:00PM +0300, Nicola Tuveri wrote:
> topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13
>and until 3.0 beta1 is released, in lieu of the weekly "developer
>meetings".
+1
Kurt
On Thu, Oct 08, 2020 at 03:27:18PM +0100, Matt Caswell wrote:
> topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as
> shown in PR #13018 into the 3.0 release
+1
Kurt
On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote:
> The following items are required prerequisites for the first beta release:
[...]
> * Address 3.0beta1 milestones.
So we now have a list here, with the last item pointing to a
different list. I suggest that we only have 1 list, and tha
On Wed, Oct 07, 2020 at 12:29:10PM +0100, Matt Caswell wrote:
> Issue #12612 exposes a problem with how we handle keys that contain
> private components but not public components.
>
> There is a widespread assumption in the code that keys with private
> components must have public components. Ther
On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote:
> Hi,
>
> I would like to have a system so that we can tag issues as
> important. But I think they fall in a few categories:
> - Features for the next minor/major release (so 3.1 or 4.0)
> that we find important.
On Wed, Sep 30, 2020 at 01:57:34PM +, Dr. Matthias St. Pierre wrote:
> topic: OTC meeting will be called for next Tuesday
+1, but wondering why this needs a vote.
Kurt
On Mon, Sep 28, 2020 at 12:02:07PM +, Dr. Matthias St. Pierre wrote:
> topic: Accept the OTC voting policy as defined:
>
>The proposer of a vote is ultimately responsible for updating the
> votes.txt
>file in the repository. Outside of a face to face meeting, voters
> MUST r
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,
I would like to have a system so that we can tag issues as
important. But I think they fall in a few categories:
- Features for the next minor/major release (so 3.1 or 4.0)
that we find important. I've created a new milestone for that:
https://github.com/openssl/openssl/milestone/18 (Post
On Thu, Sep 17, 2020 at 06:49:19PM +0200, Kurt Roeckx wrote:
> - It doesn't go into 3.0. No idea what the best way to tag them
> is.
So I've created a "Post 3.0.0" milestone for that.
Kurt
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 ab
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 t
On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote:
> Please can anyone with PRs that they wish to have included in OpenSSL
> 3.0 beta1 ensure that they are merged to master by 8th September.
So that date has passed now. Can someone give an overview of what
we think is still needed to be
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
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
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 asse
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 woul
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 b
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 i
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
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
On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote:
>
> Actually the coincidence is that the errno is set to 0 on EOF. So yes,
> we should explicitly clear the errno on EOF so any leftover value from
> previous calls does not affect this.
On EOF, errno is normally not modified. It's value
On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote:
> From application developer side of view for protocols that do not
> depend on SSL detecting the truncation I think inventing a different
> behavior for this condition than the existing one as of 1.1.1f would be
> clearly wrong. Switching
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
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 co
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 ca
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
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
On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
>
> dhparam itself has been deprecated. For that reason we are not
> attempting to rewrite it to use non-deprecated APIs. The informed
> decision we have made about DH_check use in dhparam is to not build the
> whole application in a no
On Fri, Feb 21, 2020 at 09:50:10AM +, Matt Caswell wrote:
>
>
> On 21/02/2020 08:06, Kurt Roeckx wrote:
> > In the apps, a lot of the files define
> > OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do
> > it. We should stop using the deprecated func
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
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 as
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 lo
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 i
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
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 so
On Tue, Jan 07, 2020 at 09:57:55AM +1000, Dr Paul Dale wrote:
> The refactoring/FIPS work needs the question resolved about loading the
> legacy provider or not by default. We’ve been through this before on the
> project list [1] and in at least one PR [2].
>
> I expect that its resolution will
On Thu, Dec 12, 2019 at 12:10:35PM +, Matt Caswell wrote:
>
> But in principle I agree that addrev could be used to do this. It's not
> quite as robust as doing it in the commit hook - because you don't
> *have* to use addrev. But, AFAIK, everyone does - so that's probably
> good enough.
I ha
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 th
Should we let someone do a new audit before the 3.0 release?
Kurt
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
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 y
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 taki
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 specifi
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). Ins
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
> i
1 - 100 of 209 matches
Mail list logo
