handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: https://github.com/openssl/technical-policies/issues/60
Public: yes
Opened: 2022-12-01
Closed: -MM-DD
Accepted: yes/no (for: X, against: Y, abstained: Z, not voted: W)
Dmitry [ ]
Matt [ ]
Pauli [ ]
Tim
default to UNCOMPRESSED) in our provider implementations, and
apply corresponding changes for handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: https://github.com/openssl/technical-policies/issues/59
Public: yes
Opened: 2022-11-15
Closed: 2022-11-27
Accepted: yes (for: 7, against
Branch: refs/heads/master
Home: https://github.com/openssl/technical-policies
Commit: 70312d1e8ccb605df19bcab76e9d95e8590b49be
https://github.com/openssl/technical-policies/commit/70312d1e8ccb605df19bcab76e9d95e8590b49be
Author: Nicola Tuveri
Date: 2022-11-27 (Sun, 27 Nov
Branch: refs/heads/master
Home: https://github.openssl.org/otc/technical-policies
Commit: 70312d1e8ccb605df19bcab76e9d95e8590b49be
https://github.openssl.org/otc/technical-policies/commit/70312d1e8ccb605df19bcab76e9d95e8590b49be
Author: Nicola Tuveri
Date: 2022-11-27 (Sun, 27
corresponding changes for handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: https://github.com/openssl/technical-policies/issues/59
Public: yes
Opened: 2022-11-15
Closed: -MM-DD
Accepted: yes/no (for: X, against: Y, abstained: Z, not voted: W)
Dmitry [ ]
Matt [ ]
Pauli
Branch: refs/heads/master
Home: https://github.com/openssl/technical-policies
Commit: 1fb420362b34b1481c7ab41f01bdba3d3139b10b
https://github.com/openssl/technical-policies/commit/1fb420362b34b1481c7ab41f01bdba3d3139b10b
Author: Nicola Tuveri
Date: 2022-11-15 (Tue, 15 Nov
-policies/commit/1fb420362b34b1481c7ab41f01bdba3d3139b10b
Author: Nicola Tuveri
Date: 2022-11-15 (Tue, 15 Nov 2022)
Changed paths:
M votes/vote-20221107-test-labels.txt
Log Message:
---
[VOTE][late update] test labelling policy
Compare:
https://github.openssl.org/otc
Branch: refs/heads/master
Home: https://github.com/openssl/technical-policies
Commit: 4908192cdab7c872ca018bfa3bbe7a11d8493876
https://github.com/openssl/technical-policies/commit/4908192cdab7c872ca018bfa3bbe7a11d8493876
Author: Nicola Tuveri
Date: 2022-08-01 (Mon, 01 Aug
Branch: refs/heads/master
Home: https://github.openssl.org/otc/technical-policies
Commit: 4908192cdab7c872ca018bfa3bbe7a11d8493876
https://github.openssl.org/otc/technical-policies/commit/4908192cdab7c872ca018bfa3bbe7a11d8493876
Author: Nicola Tuveri
Date: 2022-08-01 (Mon, 01
[+1]
Tim[ 0]
Richard[ 0]
Shane [-1]
Tomas [ 0]
Kurt [ ]
Matthias [-0]
Nicola [+1]
The vote was opened during the weekly OTC meeting, and is still open.
OTC members, please vote.
Nicola Tuveri
+1
On Tue, Nov 2, 2021 at 1:00 PM Tomas Mraz wrote:
>
> There are already enough votes to close this one, so I intend to close
> the vote tomorrow.
>
> Tomas
>
>
> On Mon, 2021-11-01 at 11:23 +0100, Tomas Mraz wrote:
> > topic: Accept openssl/technical-policies PR#1 - the policy change
> > proces
I believe Matt will find the time at some point to post the minutes
from today's meeting, but until then here is my recap.
The discussion mostly focused on why the changes in #16725 are a
bugfix and not a new feature, which would be a prerequisite to be
admissible to be merged in the 3.0 branch.
A
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 intent.
This might have security repercussions, as the user might end up sign
+1
On Thu, Jul 22, 2021, 16:56 Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:
> +1
>
> > -Original Message-
> > From: openssl-project On Behalf
> Of Tomas Mraz
> > Sent: Thursday, July 22, 2021 3:06 PM
> > To: openssl-project@openssl.org
> > Subject: Re: OTC VOTE: Accept
The vote is now closed: it passed, and PR#14759 is rejected.
topic: Reject PR#14759
Proposed by Nicola Tuveri
Public: yes
opened: 2021-04-20
closed: 2021-05-04
accepted: yes (for: 3, against: 2, abstained: 4, not voted: 2)
Matt [ 0]
Mark [ ]
Pauli [-0
-Metrics/issues)
is most welcome, and if you're interested in learning more or joining this
effort, please reach out to [Michael Scovetta](mailto://
michael.scove...@microsoft.com) or join us at our next [working group](
https://github.com/ossf/wg-identifying-security-threats) meeting.
Best regards,
Nicola Tuveri
officially today with a clean slate.
topic: Reject PR#14759
Proposed by Nicola Tuveri
Public: yes
opened: 2021-04-20
closed: 2021-mm-dd
accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T)
Matt [ ]
Mark [ ]
Pauli [ ]
Viktor [ ]
Tim
time
while we define a policy and then vote to accept or reject based on that.
Nicola
On Fri, Apr 9, 2021, 14:24 Nicola Tuveri wrote:
> I agree with what Tomàš said, and that is the reason why I convoluted them
> in a single vote: we need to merge or reject the PR based on a policy, but
&
Mraz wrote:
> On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote:
> >
> > On 08/04/2021 18:02, Nicola Tuveri wrote:
> > > Proposed vote text
> > > ==
> > >
> > > Do not merge PR#14759, prevent declaring properties similar to
ter thing than having nothing available - as with
> nothing available then no selection between alternatives is possible.
>
> Separately arguing about what the default set of properties should be
> (i.e. what mitigations should we configure as required by default) would
> make sens
Background
==
[PR#14759](https://github.com/openssl/openssl/pull/14759) (Set
blinding=yes property on some algorithm implementations) is a fix for
[Issue#14654](https://github.com/openssl/openssl/issues/14654) which
itself is a spin-off of
[Issue#14616](https://github.com/openssl/openssl/i
ch ultimately
delivers an SM2 key object over an arbitrary curve that can be used, for
example, for SM2DSA operations as demonstrated by
0001-drop-3.0.0-test-SM2DSA-and-SM2ENC-DEC-over-NIST-P-52.patch).
Nicola
On Tue, Mar 9, 2021 at 8:50 PM Kurt Roeckx wrote:
> On Tue, Mar 09, 2021 at 03:57
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 this text does not cover it, but another use case that we will
likely lose
nge the apps behavior triggering
>early exits (compared to previous versions of the apps), as bug
>fixes, they do not qualify as behavior changes that require an
>explicit OMC approval.
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2020-11-30
> closed: 202
project. These include things like
> users dependent on openssl library, number of project contributors and
> user activity in terms of issues filed, updated.
[Github issue]: https://github.com/ossf/criticality_score/issues/14
On Fri, Dec 11, 2020 at 11:54 AM Nicola Tuveri wrote:
>
> On
On Fri, Dec 11, 2020 at 11:23 AM Matt Caswell wrote:
>
>
> Actually according to the spreadsheet we are 5th (not 6th) - line 1 in
> the sheet is the title row. Linux takes 2 of the top spots, with git and
> php taking the other spots ahead of OpenSSL.
Good, it's good that the double review proce
Hi all,
just sharing an interesting factoid I came across today about the project.
Google, as part of the Open Source Security Foundation, yesterday released
a new project dubbed "Criticality Score", attempting (I am simplifying here
for brevity) to create a metric of "how critical" a software is
I just opened the vote using the latest version of the vote text
proposed in this thread.
Here is the link to the vote:
https://www.mail-archive.com/openssl-project@openssl.org/msg02286.html
Cheers,
Nicola
On Tue, Nov 24, 2020 at 10:29 PM Nicola Tuveri wrote:
>
> Off-list I rece
d return value.
Even when these bug fixes change the apps behavior triggering
early exits (compared to previous versions of the apps), as bug
fixes, they do not qualify as behavior changes that require an
explicit OMC approval.
Proposed by Nicola Tuveri
Public: yes
opened: 2020-11-30
fixes, they do not qualify as behavior changes that require an
explicit OMC approval.
Would this be preferable to the original proposal?
Cheers,
Nicola
On Tue, Nov 24, 2020 at 7:33 PM Nicola Tuveri wrote:
>
> Uhm, thanks Kurt! I think you have a point here, "unrecoverably&qu
u have
a better vote text proposal?
Nicola
On Tue, Nov 24, 2020, 19:18 Kurt Roeckx wrote:
>
> 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
&
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 attending
members that also sit in the OMC.
The suggestion was to improve the s
Cheers,
> Richard
>
> P.S. I'd like to pause the debate at this point... it looks like
> we're getting back into locked positions, and I'm not keen on
> continuing under those conditions.
>
> On Mon, 16 Nov 2020 19:06:51 +0100,
> Nicola Tuveri wrote:
> >
> &
That's great news!
Welcome Paul!
Nicola
On Mon, Nov 16, 2020 at 7:15 PM Matt Caswell wrote:
>
> You may recall that some while ago we posted a blog where we were
> looking for an Administrator and Manager to help run the project:
>
> https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.Proje
o possible that if there are conditions that may cause an
> infinite loop, that is a bug in itself that needs a fix.
>
> I believe this loop is due for a raised issue, unless there already is
> one.
> (if there isn't, I wonder why)
>
> Cheers,
> Richard
>
> On
this issue,
and the reason why I commented on the "lack of enforcement" argument.
Cheers,
Nicola
On Mon, Nov 16, 2020, 18:53 Richard Levitte wrote:
> On Wed, 11 Nov 2020 23:34:53 +0100,
> Nicola Tuveri wrote:
> >
> > By design the consistency checks and validati
On Thu, Nov 12, 2020 at 11:42 AM Dick Franks wrote:
>
> On Wed, 11 Nov 2020 at 14:14, Nicola Tuveri wrote:
>>
>>
>> In particular in 1.1.1, the key created as depicted in #12612 that
>> triggered this discussion (Matt posted a useful reproducer among the
>> f
d EVP_PKEY_check, but they may need a
> sub check such as
> EVP_PKEY_public_check, EVP_PKEY_param_check, EVP_PKEY_private_check or
> EVP_PKEY_pairwise_check (or some combination of those).
> Keys (and certs) that are received from another entity should be validated
> unless there is some other mecha
In light of recently working more closely to `EVP_PKEY_check()` I
would add to the discussion on this vote that it is not entirely true
that we were not enforcing the keypair assumption and that the current
strict behavior of the EC keymgmt in 3.0 is a breaking change w.r.t.
some uses that work in
s a breaking change an OMC vote is required? Or is an OTC vote
> sufficient?
>
> Matt
>
>
> On 10/11/2020 16:15, Nicola Tuveri wrote:
>
> ## Background
>
> As part of the discussion in [issue #8435], it was highlighted that both
> in 1.1.1 and master we are missi
e an OMC vote is required? Or is an OTC vote
> sufficient?
>
> Matt
>
>
> On 10/11/2020 16:15, Nicola Tuveri wrote:
> > ## Background
> >
> > As part of the discussion in [issue #8435], it was highlighted that both
> > in 1.1.1 and master we are missing tests
## Background
As part of the discussion in [issue #8435], it was highlighted that both
in 1.1.1 and master we are missing tests to validate decoded SM2 keys.
The `openssl pkey -check` (or `pkey -pubcheck` to validate only the
public key component) command allows to explicitly execute the
validatio
As defined by the [OTC Voting Procedures][0], I am declaring the
vote closed, as the number of uncast votes cannot affect the outcome of
the vote.
The vote is accepted.
topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as shown
in PR #13018 into the 3.0 release
Proposed by Mat
weekly "developer
meetings".
Proposed by Nicola Tuveri
Public: yes
opened: 2020-10-09
closed: 2020-10-11
accepted: yes (for: 9, against: 0, abstained: 0, not voted: 2)
Matt [+1]
Mark [+1]
Pauli [+1]
Viktor [ ]
Tim[+1]
Richard[ ]
Shan
+1
I am basing my vote on the feedback provided by @DDvO [0] and @t8m [1].
In particular I am convinced to vote in favor, as I can see this as a
bug fix, fixing an undocumented inconsistency, and that it is very
unlikely it would affect existing applications.
Nicola
[0]: https://github.com/ope
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".
Proposed by Nicola Tuveri
Public: yes
opened: 2020-10-09
closed: 2020-mm-dd
accepted: yes/no (for: X, against: Y, abstain
I received no feedback, so I am keeping the vote text as proposed and
opening the vote shortly.
Nicola
On Wed, 7 Oct 2020 at 16:53, Nicola Tuveri wrote:
>
> Background
> --
>
> Since the two virtual face-to-face OTC meetings of last week, and again
> in the two OTC
+1
On Thu, 8 Oct 2020 at 17:47, 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 that is
+1
On Thu, Oct 8, 2020, 17:27 Matt Caswell wrote:
> topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as
> shown in PR #13018 into the 3.0 release
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-10-08
> closed: 2020-mm-dd
> accepted: yes/no (for: X, against: Y, abst
uld emerge out of this change and the amount of work
required to reach exhaustive testing to be able to quantify these
risks and the work required to make all the existing codebase robust
to this change.
-- Nicola
On Thu, 8 Oct 2020 at 00:10, Richard Levitte wrote:
>
> On Wed, 07 Oct 2020 21:25:
On Wed, 7 Oct 2020 at 20:45, Richard Levitte wrote:
>
> I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY
> with a private key should have a public key. I was incorrect.
Sure, my example was not about pointing fingers!
It's just to give recent data points on how the document
On Wed, 7 Oct 2020 at 20:17, Richard Levitte wrote:
>
> There's no reason for the EVP layer to check for the presence or the
> absence or the public key, for one very simple reason: it doesn't have
> access to the backend key structure and therefore has no possibility
> to make any such checks. S
ement" at that level,
> it's more accidental than by design...
>
> I'm not sure what to make of the documentation from 2006. Considering
> the level of involvement there was from diverse people (2006 wasn't
> exactly the most eventful time), there's a possibil
I believe the current formulation is slightly concealing part of the problem.
The way I see it, the intention if the vote passes is to do more than stated:
1. change the long-documented assumption
2. fix "regressions" in 3.0 limited to things that worked in a certain
way in 1.1.1 (and maybe before
I support the edit proposed by Tomas.
First comment that I have is that I'd prefer the first-level items to
be actually numbered, as done in the drafts: we might put a disclaimer
that the numbers are not indicative of priority and just meant to be
used to address (equally important) tasks by index
Background
--
Since the two virtual face-to-face OTC meetings of last week, and again
in the two OTC meetings this week, we repeatedly discussed replacing the
weekly "developer meetings" with official OTC meetings.
The "developer meetings" have so far seen frequent participation from a
su
interfaces need to have their documentation pointing
to the replacement interfaces.
---
Best regards,
Nicola Tuveri
[Release Strategy]: https://www.openssl.org/policies/releasestrat.html
[OpenSSL Bylaws]: https://www.openssl.org/policies/omc-bylaws.html
[3.0 design document]: https://www.openssl.o
.
`OSSL_PARAMS` names.
6. We need to rewrite the apps to use only the non-deprecated interfaces
(except for the list, speed and engine apps and the engine parameter
in various places).
7. All the legacy interfaces need to have their documentation pointing
to the replacement int
+1, as expressed during the f2f meeting.
Nicola
On Mon, Sep 28, 2020, 15:02 Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:
> topic: Accept the OTC voting policy as defined:
>
>The proposer of a vote is ultimately responsible for updating the
> votes.txt
>file in t
s for the official documentation you
> mentioned, are you talking about this one?
> https://github.com/features/project-management
>
> Matthias
>
>
> From: Nicola Tuveri
> Sent: Sunday, September 13, 2020 4:17 PM
> To: Dr. Matthias St. Pierre
> Cc: openssl-project@openssl
Matthias overcredits me: I just wanted to know his opinion about when we
should use labels and when milestones (and that is why I wrote to him
off-list, as a very confused and shy pupil asking a sensei for wisdom
pearls).
All the alleged convincing was self-inflicted :P
And now that my ignorance
On Sat, Sep 5, 2020, 14:01 Tim Hudson wrote:
> On Sat, Sep 5, 2020 at 8:45 PM Nicola Tuveri wrote:
>
>> Or is your point that we are writing in C, all the arguments are
>> positional, none is ever really optional, there is no difference between
>> passing a `(void*)
On Sat, Sep 5, 2020, 12:13 Tim Hudson wrote:
> On Sat, Sep 5, 2020 at 6:38 PM Nicola Tuveri wrote:
>
>> In most (if not all) cases in our functions, both libctx and propquery
>> are optional arguments, as we have global defaults for them based on the
>> loaded
Thanks Tim for the writeup!
I tend to agree with Tim's conclusions in general, but I fear the analysis
here is missing an important premise that could influence the outcome of
our decision.
In most (if not all) cases in our functions, both libctx and propquery are
optional arguments, as we have
Sorry yes, I meant to refer to the open PR with the s390 support, I picked
the wrong number!
On Thu, Jun 25, 2020, 17:54 Matt Caswell wrote:
>
>
> On 25/06/2020 15:33, Nicola Tuveri wrote:
> > In light of how the discussion evolved I would say that not only there
> > is co
In light of how the discussion evolved I would say that not only there
is consensus on supporting the definition of a detailed policy on
backports and the definitions of what are the requirements for regular
releases vs LTS releases (other than the longer support timeframe),
but also highlights a n
I believe the OMC is called into action as some name changes might be seen
as breaking API or ABI compatibility and that has been considered so far as
part of the first item in the OMC prerogatives list.
The matter of OMC Vs OTC vote also depends on what kind of hold Tim is
applying with his - 1:
Yes, I also got that since I updated my git installation from the upstream
source tarball.
With recent versions of git this warning has been showing for months
already, but I don't know enough about it to propose a fix!
Nicola
On Mon, Jun 8, 2020, 12:16 Matt Caswell wrote:
> After upgrading U
I would be interested in seeing a PR to see what enabling these tests would
require!
I believe we do indeed need to test more thoroughly to ensure we are not
breaking the engine API!
Nicola
On Thu, May 7, 2020, 21:08 Dmitry Belyavsky wrote:
> Dear colleagues,
>
> Let me draw your attention to
I think we changed enough things in the test infrastructure that there is a
chance of creating subtle failures by merging cherry-picked commits from
master directly.
>From the burden perspective, from my point of view having a separate PR
that ran all the CI without failures is actually a benefit:
I can agree it is a good idea to always require backport as a separate PR,
with the following conditions:
- unless it's a 1.1.1 only issue, we MUST always wait to open the
backport-to-111 PR until after the master PR has been approved and merged
(to avoid splitting the discussions among different P
I would like to propose as a date for the OTC meeting somewhere close to
the projected release date for 3.0alpha1.
Ideally it would be nice if OMC and OTC could coordinate the dates to be
close enough to ease the discussion of agenda items that might require
coordination between OMC and OTC.
My r
On Fri, 14 Feb 2020 at 14:00, Matt Caswell wrote:
>
> To be clear the build that is timing out uses *msan* not *asan*.
>
As I understand it msan detects unitialised reads. whereas asan detects
> memory corruption, buffer overflows, use-after-free bugs, and memory leaks.
>
> The previous "home-m
If ASAN is too slow to run in the CI should we restore the previous
homemade checks for memory leaks as an alternative to be run in regular CI
runs and leave ASAN builds to run-checker on the master branch only?
Here is another idea that would be interesting if we restore the previous
checks:
I do
I have always implicitly assumed Matt view, but I am happy to conform to
what the consensus is.
I believe this discussion is very useful and could contribute a new entry
in the commiter guidelines.
Nicola
On Fri, May 24, 2019, 07:21 Matt Caswell wrote:
>
>
> On 24/05/2019 15:10, Richard Levitt
75 matches
Mail list logo
