Re: [OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix

2020-11-30 Thread Nicola Tuveri
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 re

OTC VOTE: Fixing missing failure exit status is a bug fix

2020-11-30 Thread Nicola Tuveri
urn 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

Re: [OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix

2020-11-24 Thread Nicola Tuveri
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

Re: [OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix

2020-11-24 Thread Nicola Tuveri
e 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 > &

[OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix

2020-11-24 Thread Nicola Tuveri
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

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Nicola Tuveri
gt; 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: > > > > The issue with that key

Re: Introducing Paul Nelson

2020-11-16 Thread Nicola Tuveri
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: > >

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Nicola Tuveri
here 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 Thu, 12 Nov 2020 11:33:13

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Nicola Tuveri
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 va

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-12 Thread Nicola Tuveri
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 >>

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-11 Thread Nicola Tuveri
t 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 mechanism for establis

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-11 Thread Nicola Tuveri
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

Re: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`

2020-11-11 Thread Nicola Tuveri
reaking 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 missin

Re: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`

2020-11-11 Thread Nicola Tuveri
ange 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

[OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`

2020-11-10 Thread Nicola Tuveri
## 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

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-13 Thread Nicola Tuveri
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

Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released

2020-10-11 Thread Nicola Tuveri
of the 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

Re: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch

2020-10-11 Thread Nicola Tuveri
+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]:

VOTE: Weekly OTC meetings until 3.0 beta1 is released

2020-10-09 Thread Nicola Tuveri
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, ab

Re: [VOTE PROPOSAL] Weekly OTC meeting until 3.0 beta1 is released

2020-10-09 Thread Nicola Tuveri
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

Re: VOTE: Technical Items still to be done

2020-10-08 Thread Nicola Tuveri
+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

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread Nicola Tuveri
+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,

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-08 Thread Nicola Tuveri
d 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:57 +0

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Nicola Tuveri
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

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Nicola Tuveri
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.

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Nicola Tuveri
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 possibility that it was a > precaut

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Nicola Tuveri
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

Re: Vote proposal: Technical items still to be done

2020-10-07 Thread Nicola Tuveri
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

[VOTE PROPOSAL] Weekly OTC meeting until 3.0 beta1 is released

2020-10-07 Thread Nicola Tuveri
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

Re: [OTC] Agenda proposal for OTC meeting on 2020-10-06

2020-10-02 Thread Nicola Tuveri
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.org/docs/OpenSSL

[OTC] Agenda proposal for OTC meeting on 2020-10-06

2020-10-02 Thread Nicola Tuveri
MS` 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 interfaces. ---

Re: VOTE: Accept the OTC voting policy as defined:

2020-09-28 Thread Nicola Tuveri
+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

Re: New GitHub label for release blockers

2020-09-13 Thread Nicola Tuveri
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

Re: New GitHub label for release blockers

2020-09-13 Thread Nicola Tuveri
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

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Nicola Tuveri
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*)

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Nicola Tuveri
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 >

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Nicola Tuveri
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

Re: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Nicola Tuveri
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

Re: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Nicola Tuveri
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

Re: The hold on PR 12089

2020-06-10 Thread Nicola Tuveri
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:

Re: addrev warning

2020-06-08 Thread Nicola Tuveri
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

Re: Some more extra tests

2020-05-07 Thread Nicola Tuveri
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

Re: Cherry-pick proposal

2020-04-29 Thread Nicola Tuveri
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

Re: Cherry-pick proposal

2020-04-29 Thread Nicola Tuveri
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

Re: Face to face

2020-03-04 Thread Nicola Tuveri
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

Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Nicola Tuveri
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

Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Nicola Tuveri
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

Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Nicola Tuveri
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