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

2020-11-30 Thread Dr. Matthias St. Pierre
+1

> -Original Message-
> From: openssl-project  On Behalf Of 
> Nicola Tuveri
> Sent: Monday, November 30, 2020 1:03 PM
> To: OpenSSL Project 
> Subject: OTC VOTE: Fixing missing failure exit status is a bug fix
> 
> Vote 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 separation of the OTC and OMC domains
> here, by having a more generic OTC vote to qualify as bug fixes the
> changes to let any OpenSSL app return an (early) failure exit status
> when a called function fails.
> 
> The idea is that, if we agree on this technical definition, then no OMC
> vote to allow a behavior change in the apps would be required in
> general, unless, on a case-by-case basis, the "OMC hold" process is
> invoked for whatever reason on the specific bug fix, triggering the
> usual OMC decision process.
> 
> [previous proposal]:
> 
> [PR#13359]: 
> 
> 
> 
> 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.
>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



smime.p7s
Description: S/MIME cryptographic signature


RE: OpenSSL Cookbook is being updated soon

2020-11-16 Thread Dr. Matthias St. Pierre
typo: “your user base” -> “our user base”

From: openssl-project  On Behalf Of Dr. 
Matthias St. Pierre
Sent: Monday, November 16, 2020 9:08 PM
To: Ivan Ristic ; openssl-project@openssl.org
Subject: RE: OpenSSL Cookbook is being updated soon

Ivan,

thank you very much for giving us the opportunity to preview your next 
publication of the OpenSSL cookbook. Even if your mail was unanswered (until 
know), I’m sure your announcement did not go unnoticed.

I would like to take the opportunity to thank you for your continuous efforts 
during the past years to provide the OpenSSL community with an excellent 
introduction to the OpenSSL command line tool. It has always been available as 
a free download and is a valuable source of information for your user base. And 
it’s excellent news that there is an update coming. Enough reasons IMHO to 
propose you as an “OpenSSL Team member h.c.” if such a role would already exist 
in our bylaws (maybe we should add it ).

Regards,

Matthias

@openssl/committers: please take the time to take a look at the preprint and 
provide your feedback.


From: openssl-project 
mailto:openssl-project-boun...@openssl.org>>
 On Behalf Of Ivan Ristic
Sent: Friday, November 6, 2020 11:29 AM
To: openssl-project@openssl.org<mailto:openssl-project@openssl.org>
Subject: OpenSSL Cookbook is being updated soon

Apologies for starting a new thread, but I had no previous message to reply to. 
Matt alerted me to the mention of OpenSSL Cookbook here and I was previously 
not on this list.

I am committed to maintaining OpenSSL Cookbook. In fact, we've just completed 
the 3rd edition. This time I had Matt help me as a technical reviewer and that 
led to many improvements. We're currently updating our web site and will 
release the new edition as soon as that's done.

The 3rd edition required many changes because of TLS 1.3. Now that it's done, 
going forward I will aim for continuous updates as needed.

Additionally, we wish to make the content more useful by splitting it into 
smaller chunks. At the moment, it's presented as one page per chapter, which is 
not ideal. We will look into this at some point after the release.

If you'd like to see the 3rd edition before it's officially out, you can 
actually get it immediately by registering for an account here 
https://www.feistyduck.com/account/register If you already have an account, it 
should be offered to you at the bottom of the library page 
https://www.feistyduck.com/library/ I would certainly welcome any thoughts 
about the content and the possible improvements. The scope is generally 
command-line usage.

--
Ivan


smime.p7s
Description: S/MIME cryptographic signature


RE: OpenSSL Cookbook is being updated soon

2020-11-16 Thread Dr. Matthias St. Pierre
Ivan,

thank you very much for giving us the opportunity to preview your next 
publication of the OpenSSL cookbook. Even if your mail was unanswered (until 
know), I’m sure your announcement did not go unnoticed.

I would like to take the opportunity to thank you for your continuous efforts 
during the past years to provide the OpenSSL community with an excellent 
introduction to the OpenSSL command line tool. It has always been available as 
a free download and is a valuable source of information for your user base. And 
it’s excellent news that there is an update coming. Enough reasons IMHO to 
propose you as an “OpenSSL Team member h.c.” if such a role would already exist 
in our bylaws (maybe we should add it ).

Regards,

Matthias

@openssl/committers: please take the time to take a look at the preprint and 
provide your feedback.


From: openssl-project  On Behalf Of Ivan 
Ristic
Sent: Friday, November 6, 2020 11:29 AM
To: openssl-project@openssl.org
Subject: OpenSSL Cookbook is being updated soon

Apologies for starting a new thread, but I had no previous message to reply to. 
Matt alerted me to the mention of OpenSSL Cookbook here and I was previously 
not on this list.

I am committed to maintaining OpenSSL Cookbook. In fact, we've just completed 
the 3rd edition. This time I had Matt help me as a technical reviewer and that 
led to many improvements. We're currently updating our web site and will 
release the new edition as soon as that's done.

The 3rd edition required many changes because of TLS 1.3. Now that it's done, 
going forward I will aim for continuous updates as needed.

Additionally, we wish to make the content more useful by splitting it into 
smaller chunks. At the moment, it's presented as one page per chapter, which is 
not ideal. We will look into this at some point after the release.

If you'd like to see the 3rd edition before it's officially out, you can 
actually get it immediately by registering for an account here 
https://www.feistyduck.com/account/register If you already have an account, it 
should be offered to you at the bottom of the library page 
https://www.feistyduck.com/library/ I would certainly welcome any thoughts 
about the content and the possible improvements. The scope is generally 
command-line usage.

--
Ivan


smime.p7s
Description: S/MIME cryptographic signature


RE: OTC VOTE: EVP_PKEY private/public key components

2020-11-09 Thread Dr. Matthias St. Pierre
0

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Tuesday, November 3, 2020 1:11 PM
> To: openssl-project@openssl.org
> Subject: OTC VOTE: EVP_PKEY private/public key components
> 
> Background to the vote:
> 
> The OTC meeting today discussed the problems raised by issue #12612. In
> summary the problem is that there has been a long standing, widespread
> and documented assumption that an EVP_PKEY with a private key will
> always also have the public key component.
> 
> In spite of this it turns out that in the EC implementation in 1.1.1 it
> was perfectly possible to create an EVP_PKEY with only a private key and
> no public key - and it was also possible to use such an EVP_PKEY in a
> signing operation.
> 
> The current 3.0 code in master introduced an explicit check (in line
> with the long held assumption) that the public key was present and
> rejected keys where this was not the case. This caused a backwards
> compatibility break for some users (as discussed at length in #12612).
> 
> The OTC discussed a proposal that we should relax our conceptual model
> in this regards and conceptually allow EVP_PKEYs to exist that only have
> the private component without the public component - although individual
> algorithm implementations may still require both.
> 
> It is possible to automatically generate the public component from the
> private for many algorithms, although this may come at a performance and
> (potentially) a security cost.
> 
> 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 behaviour between 1.1.1 and 3.0.
> 
> The vote text is as follows:
> 
> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without public
>   components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not
>   contain public keys and
> * our decoders unconditionally generate the public key (where possible).
> 
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-11-03
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[  ]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [+1]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [-1]



smime.p7s
Description: S/MIME cryptographic signature


RE: Hacktoberfest

2020-10-20 Thread Dr. Matthias St. Pierre
Given the fact that only one person asked for it and that only ten days are 
left in October,
I think the label solution might be the simpler one for the moment. (Assuming 
that adding
Topics to the project requires a vote?) The label has already been created and 
is ready
to be applied, to make the person happy which asked for it. In November, the 
label can
be removed again.

[cid:image003.png@01D6A77C.74236BB0]

In general, I agree that GitHub Topics are a better solution. If we decide to 
participate
officially next year, we should take the time to inform ourselves in advance 
and announce
our participation in form of a blog post (I volunteer). Also, GitHub Topics 
should be discussed
in more generality, i.e.,  what's our benefit of using GitHub Topics, and which 
topics we
should add to the project. Up to yesterday, I didn't give GitHub Topics much 
thought.

Matthias


From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Wednesday, October 21, 2020 5:31 AM
To: openssl-project@openssl.org
Subject: Hacktoberfest

There has been a request in 
#13172 to tag the PR for 
Hacktoberfest.
There are two ways 
to do this: add a tag to the PR or a topic to the project.

Is either something the project is interested in doing?

Rather than polluting our already busy tags menu, the topic seems the easier 
path to me.


Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia





Assigning OpenSSL 3.0.0 beta1 issues

2020-10-13 Thread Dr. Matthias St. Pierre
A lot of GitHub issues were created by Nicola (@romen) today to keep track of 
the
[Technical Items still to be done][tbd] list. On the same occasion, we assigned
some of the tasks internally. For more transparency, I converted the assignments
on the internal spreadsheet into GitHub assignments of the corresponding [beta1 
issues].

Note that there remain a lot of [unassigned beta1 issues].

Matthias


[tbd]:
https://www.mail-archive.com/openssl-project@openssl.org/msg02141.html
[beta1 issues]:

https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.0.0+beta1%22
[unassigned beta1 issues]:

https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.0.0+beta1%22+no%3Aassignee



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

2020-10-10 Thread Dr. Matthias St. Pierre
+1

> -Original Message-
> From: openssl-project  On Behalf Of Mark 
> J Cox
> Sent: Saturday, October 10, 2020 9:34 AM
> To: openssl-project@openssl.org
> Subject: Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released
> 
> +1
> 
> On Fri, Oct 9, 2020 at 1:03 PM Tomas Mraz  wrote:
> >
> > +1
> >
> > On Fri, 2020-10-09 at 15:00 +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".
> > > Proposed by Nicola Tuveri
> > > Public: yes
> > > opened: 2020-10-09
> > > closed: 2020-mm-dd
> > > accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> > >
> > >   Matt   [  ]
> > >   Mark   [  ]
> > >   Pauli  [  ]
> > >   Viktor [  ]
> > >   Tim[  ]
> > >   Richard[  ]
> > >   Shane  [  ]
> > >   Tomas  [  ]
> > >   Kurt   [  ]
> > >   Matthias   [  ]
> > >   Nicola [+1]
> > --
> > Tomáš Mráz
> > No matter how far down the wrong road you've gone, turn back.
> >   Turkish proverb
> > [You'll know whether the road is wrong if you carefully listen to your
> > conscience.]
> >
> >



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-10 Thread Dr. Matthias St. Pierre
0

> -Original Message-
> From: openssl-project  On Behalf Of 
> Tomas Mraz
> Sent: Friday, October 9, 2020 2:02 PM
> To: openssl-project@openssl.org
> Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on 
> UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for
> 1.1.1 branch
> 
> 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 for 1.1.1 branch.
> Proposed by Tomas Mraz
> Public: yes
> opened: 2020-10-09
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>   Matt   [  ]
>   Mark   [  ]
>   Pauli  [  ]
>   Viktor [  ]
>   Tim[  ]
>   Richard[  ]
>   Shane  [  ]
>   Tomas  [+1]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [  ]
> 
> --
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]



RE: VOTE: Technical Items still to be done

2020-10-08 Thread Dr. Matthias St. Pierre
+1

> -Original Message-
> From: openssl-project  On Behalf Of 
> Tomas Mraz
> Sent: Thursday, October 8, 2020 6:21 PM
> To: Matt Caswell ; openssl-project@openssl.org
> Subject: Re: VOTE: Technical Items still to be done
> 
> +1
> 
> On Thu, 2020-10-08 at 15:47 +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 that isn’t available must be put to an OTC vote to
> > exclude.
> >- The apps are the minimum bar for this, subject to exceptions
> > noted
> > below.
> >  2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_,
> > RSA_,
> > RAND_METHOD_.
> >- Does not include macros defining useful constants (e.g.
> >  SHA512_DIGEST_LENGTH).
> >- Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`.
> >- There might be some others.
> >- Review for exceptions.
> >- The apps are the minimum bar to measure feature completeness for
> > the EVP
> >  interface: rewrite them so they do not use internal nor
> > deprecated
> >  functions (except speed, engine, list, passwd -crypt and the
> > code
> > to handle
> >  the -engine CLI option).  That is, remove the suppression of
> > deprecated
> >  define.
> >  - Proposal: drop passwd -crypt (OMC vote required)
> >- Compile and link 1.1.1 command line app against the master
> > headers and
> >  library.  Run 1.1.1 app test cases against the chimera.  Treat
> > this
> > as an
> >  external test using a special 1.1.1 branch. Deprecated functions
> > used by
> >  libssl should be moved to independent file(s), to limit the
> > suppression of
> >  deprecated defines to the absolute minimum scope.
> >  3) Draft documentation (contents but not pretty)
> >- Need a list of things we know are not present - including things
> > we
> > have
> >  removed.
> >- We need to have mapping tables for various d2i/i2d functions.
> >- We need to have a mapping table from “old names” for things into
> > the
> >  OSSL_PARAMS names.
> >  - Documentation addition to old APIs to refer to new ones
> > (man7).
> >  - Documentation needs to reference name mapping.
> >  - All the legacy interfaces need to have their documentation
> > pointing to
> >the replacement interfaces.
> >  4) Review (and maybe clean up) legacy bridge code.
> >  5) Review TODO(3.0) items #12224.
> >  6) Source checksum script.
> >  7) Review of functions previously named _with_libctx.
> >  8) Encoder fixes (PKCS#8, PKCS#1, etc).
> >  9) Encoder DER to PEM refactor.
> > 10) Builds and passes tests on all primary, secondary and FIPS
> > platforms.
> > 11) Query provider parameters (name, version, ...) from the command
> > line.
> > 12) Setup buildbot infrastructure and associated instructions.
> > 13) Complete make fipsinstall.
> > 14) More specific decoding selection (e.g. params or keys).
> > 15) Example code covering replacements for deprecated APIs.
> > 16) Drop C code output options from the apps (OMC approval required).
> > 17) Address issues and PRs in the 3.0beta1 milestone.
> > Proposed by .
> > Public: yes
> > opened: 2020-10-08
> > closed: 2020-mm-dd
> > accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> >
> >   Matt   [+1]
> >   Mark   [  ]
> >   Pauli  [  ]
> >   Viktor [  ]
> >   Tim[  ]
> >   Richard[  ]
> >   Shane  [  ]
> >   Tomas  [  ]
> >   Kurt   [  ]
> >   Matthias   [  ]
> >   Nicola [  ]
> --
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]



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

2020-10-08 Thread Dr. Matthias St. Pierre
+1

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Thursday, October 8, 2020 4:27 PM
> To: openssl-project@openssl.org
> Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality
> 
> 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, abstained: Z, not voted: T)
> 
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [  ]
>   Viktor [  ]
>   Tim[  ]
>   Richard[  ]
>   Shane  [  ]
>   Tomas  [  ]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [  ]



RE: Would this be interesting to the project?

2020-10-02 Thread Dr. Matthias St. Pierre
> Do you have ideas on how to properly set it up?

Congratulations, Dmitry! You just won the price of being assigned the job to 
figure it out.  ;-)

Matthias

From: openssl-project  On Behalf Of Dmitry 
Belyavsky
Sent: Friday, October 2, 2020 2:51 PM
To: Dr Paul Dale 
Cc: openssl-project@openssl.org
Subject: Re: Would this be interesting to the project?

Do you have ideas on how to properly set it up?

On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale 
mailto:paul.d...@oracle.com>> wrote:
https://github.blog/2020-09-30-code-scanning-is-now-available/

Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia






--
SY, Dmitry Belyavsky


RE: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Dr. Matthias St. Pierre
> +1, but wondering why this needs a vote.

Because we decided to follow our own bylaws more closely. In particular the 
following two items:

> All OTC decisions are taken on the basis of a vote
https://www.openssl.org/policies/omc-bylaws.html#OTC

> ### OTC Transparency
> The majority of the activity of the OTC will take place in public.
https://www.openssl.org/policies/omc-bylaws.html#transparency


Matthias



> -Original Message-
> From: Kurt Roeckx 
> Sent: Wednesday, September 30, 2020 6:07 PM
> To: Dr. Matthias St. Pierre 
> Cc: openssl-project@openssl.org
> Subject: Re: VOTE: OTC meeting will be called for next Tuesday
> 
> On Wed, Sep 30, 2020 at 01:57:34PM +, Dr. Matthias St. Pierre wrote:
> > topic: OTC meeting will be called for next Tuesday
> 
> 
> 
> Kurt
> 




VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Dr. Matthias St. Pierre
The following vote has been proposed and voted on at the vF2F today:

topic: OTC meeting will be called for next Tuesday

It has been closed immediately by Tim, the verdict is

accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)

(Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 Planning
meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate
invitation to the OTC list.)

Matthias


topic: OTC meeting will be called for next Tuesday (2020-10-06)
Proposed by Matthias St. Pierre
Public: yes
opened: 2020-09-30
closed: 2020-09-30
accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)

  Matt   [+1]
  Mark   [  ]
  Pauli  [+1]
  Viktor [  ]
  Tim[+1]
  Richard[+1]
  Shane  [+1]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]




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

2020-09-30 Thread Dr. Matthias St. Pierre
The vote has been closed, the verdict is

accepted:  yes  (for: 9, against: 0, abstained: 0, not voted: 2)


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 
reply
   to the vote email indicating their preference and optionally their 
reasoning.
   Voters MAY update the votes.txt file in addition.

   The proposed vote text SHOULD be raised for discussion before calling 
the vote.

   Public votes MUST be called on the project list, not the OTC list and the
   subject MUST begin with "VOTE:".  Private votes MUST be called on the
   OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-09-29
accepted:  yes/no  (for: 9, against: 0, abstained: 0, not voted: 2)

  Matt   [+1]
  Mark   [+1]
  Pauli  [+1]
  Viktor [  ]
  Tim[+1]
  Richard[+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]




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

2020-09-30 Thread Dr. Matthias St. Pierre
See pull request

#198 - Add 'OpenSSL Technical Policies' page with a 'Voting Policy' section
https://github.com/openssl/web/pull/198

Matthias



Add 'OpenSSL Technical Policies' page to openssl.org?

2020-09-28 Thread Dr. Matthias St. Pierre
Hi,

Pauli added the following action item for me to the OTC vF2F spreadsheet:

> Matthias: create web PR for OTC voting policy.

I wouldn't mind to add the content, but currently there seems to be no
appropriate place yet to put it. The voting process is currently described
only in the OMC bylaws,

   OpenSSL Bylaws
   openssl/web:policies/omc-bylaws.html

and there is no specific document for implementary regulations, or more 
generally,
technical policies decided by the OTC.  The web page needs a name and an URL,
something like

OpenSSL Technical Policies
openssl/web:policies/otc-policies.html

and it needs to be referenced by the Policies page 
.
If you agree with the name and URL, I can add that part to the web PR as well.

Matthias




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

2020-09-28 Thread Dr. Matthias St. Pierre
Now with the votes already cast filled in :-)

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 
reply
   to the vote email indicating their preference and optionally their 
reasoning.
   Voters MAY update the votes.txt file in addition.

   The proposed vote text SHOULD be raised for discussion before calling 
the vote.

   Public votes MUST be called on the project list, not the OTC list and the
   subject MUST begin with "VOTE:".  Private votes MUST be called on the
   OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Matt   [+1]
  Mark   [+1]
  Pauli  [+1]
  Viktor [  ]
  Tim[+1]
  Richard[+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]

From: openssl-project  On Behalf Of Dr. 
Matthias St. Pierre
Sent: Monday, September 28, 2020 2:17 PM
To: Dr Paul Dale ; Nicola Tuveri (nic@gmail.com) 
; openssl-project@openssl.org
Subject: RE: VOTE: Accept the OTC voting policy as defined:

Oh, sorry, you are right! The participants of the face to face already voted, 
but I forgot to fill in the votes. Apologies, I'll make up for it in a minute!

Matthias


From: openssl-project 
mailto:openssl-project-boun...@openssl.org>>
 On Behalf Of Dr Paul Dale
Sent: Monday, September 28, 2020 2:10 PM
To: openssl-project@openssl.org<mailto:openssl-project@openssl.org>
Subject: Re: VOTE: Accept the OTC voting policy as defined:

+1

Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia





On 28 Sep 2020, at 10:02 pm, Dr. Matthias St. Pierre 
mailto: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 the repository.  Outside of a face to face meeting, voters MUST 
reply
  to the vote email indicating their preference and optionally their 
reasoning.
  Voters MAY update the votes.txt file in addition.

  The proposed vote text SHOULD be raised for discussion before calling the 
vote.

  Public votes MUST be called on the project list, not the OTC list and the
  subject MUST begin with "VOTE:".  Private votes MUST be called on the
  OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

 Matt   [  ]
 Mark   [  ]
 Pauli  [  ]
 Viktor [  ]
 Tim[  ]
 Richard[  ]
 Shane  [  ]
 Tomas  [  ]
 Kurt   [  ]
 Matthias   [+1]
 Nicola [  ]



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

2020-09-28 Thread Dr. Matthias St. Pierre
Oh, sorry, you are right! The participants of the face to face already voted, 
but I forgot to fill in the votes. Apologies, I'll make up for it in a minute!

Matthias


From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Monday, September 28, 2020 2:10 PM
To: openssl-project@openssl.org
Subject: Re: VOTE: Accept the OTC voting policy as defined:

+1

Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia





On 28 Sep 2020, at 10:02 pm, Dr. Matthias St. Pierre 
mailto: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 the repository.  Outside of a face to face meeting, voters MUST 
reply
  to the vote email indicating their preference and optionally their 
reasoning.
  Voters MAY update the votes.txt file in addition.

  The proposed vote text SHOULD be raised for discussion before calling the 
vote.

  Public votes MUST be called on the project list, not the OTC list and the
  subject MUST begin with "VOTE:".  Private votes MUST be called on the
  OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

 Matt   [  ]
 Mark   [  ]
 Pauli  [  ]
 Viktor [  ]
 Tim[  ]
 Richard[  ]
 Shane  [  ]
 Tomas  [  ]
 Kurt   [  ]
 Matthias   [+1]
 Nicola [  ]



VOTE: Accept the OTC voting policy as defined:

2020-09-28 Thread Dr. Matthias St. Pierre
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 
reply
   to the vote email indicating their preference and optionally their 
reasoning.
   Voters MAY update the votes.txt file in addition.

   The proposed vote text SHOULD be raised for discussion before calling 
the vote.

   Public votes MUST be called on the project list, not the OTC list and the
   subject MUST begin with "VOTE:".  Private votes MUST be called on the
   OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Matt   [  ]
  Mark   [  ]
  Pauli  [  ]
  Viktor [  ]
  Tim[  ]
  Richard[  ]
  Shane  [  ]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [  ]



RE: New GitHub label for release blockers

2020-09-15 Thread Dr. Matthias St. Pierre
> I fail to see why the milestones '3.0.0' / '3.0.0 beta1' must be 1:1
> with the '3.0 New Core + FIPS' project.  

Sorry for the misunderstanding, Richard. I did not intend to mess around with 
your project organization.
Since it was the only active GitHub project, I misinterpreted it as the "3.0.0" 
project and did not read
the fine print.

All I intended to do is to obtain an accurate overwiew of what remains to be 
done.
Because listing them on the otc mailing list is not very maintainable, and the 
google spreadsheet is not viewable by the public.

> If we make them the same, what's the reason to have both?

I completely agree. According to my understanding,  it would have made more 
sense if we had created
an "OpenSSL 3.0" project for managing all what needs to go into this major 
release and three milestones
'3.0.0 alpha',  '3.0.0 beta', '3.0.0' associated with the major events.

Regards,
Matthias



RE: New GitHub label for release blockers

2020-09-13 Thread Dr. Matthias St. Pierre
Conversely, there were also pull requests associated with the '3.0.0' or '3.0.0 
beta1' milestone,
without  being associated to the  '3.0 New Core + FIPS' project. This has been 
fixed now.



RE: New GitHub label for release blockers

2020-09-13 Thread Dr. Matthias St. Pierre
> when your time permits, could you please double-check whether all important 
> tickets
> for beta1 were moved correctly from '3.0.0' to '3.0.0 beta1'?

The '3.0 New Core + FIPS' project currently lists 21 open pull requests,

[is:open is:pr project:openssl/openssl/2]:

https://github.com/openssl/openssl/pulls?q=is%3Aopen+is%3Apr+project%3Aopenssl%2Fopenssl%2F2+

ten of which are not associated with any milestone yet

[is:open is:pr project:openssl/openssl/2 no:milestone]:

https://github.com/openssl/openssl/pulls?q=is%3Aopen+is%3Apr+project%3Aopenssl%2Fopenssl%2F2+no%3Amilestone

It would be helpful if someone of the core team could check and assigne them.

Matthias




RE: New GitHub label for release blockers

2020-09-13 Thread Dr. Matthias St. Pierre
That's a very nice summary,  Matt.

when your time permits, could you please double-check whether all important 
tickets
for beta1 were moved correctly from '3.0.0' to '3.0.0 beta1'?

Thanks,

Matthias





RE: New GitHub label for release blockers

2020-09-13 Thread Dr. Matthias St. Pierre
Since we were able to collect some experiences working on the ‘3.0 New Core + 
FIPS’ project, I think that’s a perfect subject
to be discussed on the face-to-face meeting. I will add it to the list of 
proposed topics. As 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.org
Subject: Re: New GitHub label for release blockers

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 is out of the closet... 
... I still have very confused ideas regarding the "best" conventional usage of 
github features like labels, milestones and projects: I read the official 
documentation about them and I grasp the general ideas behind them, but too 
often the boundaries are too foggy for me to navigate and pick the right tool 
for the job in a consistent and organic manner. 

Nicola


RE: New GitHub label for release blockers

2020-09-13 Thread Dr. Matthias St. Pierre
Nicola suggested and convinced me, that it would be better to have a dedicated
milestone for the 3.0.0 beta1 release instead of adding a new label.

So here it is, I already added all the tickets with the release blocker label 
and will
remove the label again.

https://github.com/openssl/openssl/milestone/17

Matthias



> -Original Message-
> From: Dr. Matthias St. Pierre
> Sent: Sunday, September 13, 2020 3:17 PM
> To: openssl-project@openssl.org
> Subject: New GitHub label for release blockers
> 
> Hi all,
> 
> taking up again the discussion from openssl-project where I suggested to 
> (ab)use
> the 3.0.0 milestone for release blockers, (see link and citation at the end 
> of the mail),
> I propose to add a new label for this purpose instead. In fact, I already 
> created the label
> 
>   [urgent: release blocker]   (see link below)
> 
> and will add the mentioned tickets within shortly. So you can take a look and 
> tell
> me whether you like it or not. (If not, no problem. I'll just delete the 
> label again.)
> 
> Matthias
> 
> 
> BTW: It took me all my force of will to resist the temptation of making a pun
>  by naming the label [urgent: beta blocker].
> 
> 
> References:
> ==
> 
> [urgent: release blocker]:
>   https://github.com/openssl/openssl/labels/urgent%3A%20release%20blocker
> 
> [openssl-project message]:
>   
> https://mta.openssl.org/pipermail/openssl-project/2020-September/002191.html
> 
> 
> > > > 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 tickets listed below were already associated to the 
> > > > milestone, the others
> > > > were added by me now.
> > >
> > > I think the 3.0.0 milestone is what we expect to be in the
> > > 3.0.0 release, not the beta release. That is bug fixes don't need
> > > to be in the beta release, but if it adds new functionallity it
> > > needs to be in the beta release.
> >
> > I was aware of this subtlety but I thought that we just could (ab-)use the 
> > milestone for
> > the beta1 release and reuse it later for the final release, instead of 
> > creating a new milestone.
> >
> > Practically all of the relevant PRs are associated to the [3.0 New Core + 
> > FIPS] GitHub Project
> > anyway, so it would be possible to remove the post-beta PRs from the 
> > milestone and restore
> > them later.  (In my mind, I see project managers running away screeming...)
> >
> > Matthias
> >
> >
> > [3.0 New Core + FIPS]:  https://github.com/openssl/openssl/projects/2



RE: New GitHub label for release blockers

2020-09-13 Thread Dr. Matthias St. Pierre
I added some issues mentioned in the  'Beta1 PR deadline' thread to the new 
label.
Feel free to extend and modify the list as necessary.



New GitHub label for release blockers

2020-09-13 Thread Dr. Matthias St. Pierre
Hi all,

taking up again the discussion from openssl-project where I suggested to (ab)use
the 3.0.0 milestone for release blockers, (see link and citation at the end of 
the mail),
I propose to add a new label for this purpose instead. In fact, I already 
created the label

[urgent: release blocker]   (see link below)

and will add the mentioned tickets within shortly. So you can take a look and 
tell
me whether you like it or not. (If not, no problem. I'll just delete the label 
again.)

Matthias


BTW: It took me all my force of will to resist the temptation of making a pun
 by naming the label [urgent: beta blocker].


References:
==

[urgent: release blocker]:
https://github.com/openssl/openssl/labels/urgent%3A%20release%20blocker

[openssl-project message]:

https://mta.openssl.org/pipermail/openssl-project/2020-September/002191.html


> > > 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 tickets listed below were already associated to the 
> > > milestone, the others
> > > were added by me now.
> > 
> > I think the 3.0.0 milestone is what we expect to be in the
> > 3.0.0 release, not the beta release. That is bug fixes don't need
> > to be in the beta release, but if it adds new functionallity it
> > needs to be in the beta release.
> 
> I was aware of this subtlety but I thought that we just could (ab-)use the 
> milestone for
> the beta1 release and reuse it later for the final release, instead of 
> creating a new milestone.
> 
> Practically all of the relevant PRs are associated to the [3.0 New Core + 
> FIPS] GitHub Project
> anyway, so it would be possible to remove the post-beta PRs from the 
> milestone and restore
> them later.  (In my mind, I see project managers running away screeming...)
> 
> Matthias
> 
> 
> [3.0 New Core + FIPS]:  https://github.com/openssl/openssl/projects/2



RE: Beta1 PR deadline

2020-09-11 Thread Dr. Matthias St. Pierre
> > 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 tickets listed below were already associated to the milestone, 
> > the others
> > were added by me now.
> 
> I think the 3.0.0 milestone is what we expect to be in the
> 3.0.0 release, not the beta release. That is bug fixes don't need
> to be in the beta release, but if it adds new functionallity it
> needs to be in the beta release.

I was aware of this subtlety but I thought that we just could (ab-)use the 
milestone for
the beta1 release and reuse it later for the final release, instead of creating 
a new milestone.

Practically all of the relevant PRs are associated to the [3.0 New Core + FIPS] 
GitHub Project
anyway, so it would be possible to remove the post-beta PRs from the milestone 
and restore
them later.  (In my mind, I see project managers running away screeming...)

Matthias


[3.0 New Core + FIPS]:  https://github.com/openssl/openssl/projects/2




RE: Beta1 PR deadline

2020-09-11 Thread Dr. Matthias St. Pierre
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 tickets listed below were already associated to the milestone, the 
others
were added by me now.

Just a suggestion.

Matthias



> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Thursday, September 10, 2020 1:24 PM
> To: openssl-project@openssl.org
> Subject: Re: Beta1 PR deadline
> 
> 
> 
> On 10/09/2020 11:40, Matt Caswell wrote:
> >
> >
> > On 09/09/2020 13:03, Kurt Roeckx wrote:
> >> 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 done before the beta 1 release? Are
> >> there open PRs for everything? Do we a milestone on github to
> >> indicate which PRs need to go in before beta1?
> >
> >
> > I believe the "blockers" to be:
> >
> > https://github.com/openssl/openssl/pull/12536
> > https://github.com/openssl/openssl/pull/12754
> > https://github.com/openssl/openssl/pull/12750
> > https://github.com/openssl/openssl/pull/12781
> > https://github.com/openssl/openssl/pull/12801
> >
> > Aside from these there are potential PRs not yet opened but slated for
> > beta1 regarding:
> > - Refactor serialization? (owner: Richard)
> > - lhash refactor? (owner: Me)
> > - IG D.9 update? (owner: Shane)
> 
> Oh, I think this last one might be:
> 
> https://github.com/openssl/openssl/pull/12835
> 
> Matt
> 
> >
> > There's also this issue - but I'm not sure that it needs to be resolved
> > for beta1:
> > https://github.com/openssl/openssl/issues/12195
> >
> > Matt
> >



RE: More GitHub labels

2020-09-10 Thread Dr. Matthias St. Pierre
> ... I think we should change that. This does not mean that a reviewer who 
> made a change request
> two months ago and lost interest is forced to re-review, only that such stale 
> reviews must be dismissed
> explicitly, if the reviewer does not respond to a re-review request within a 
> certain time period.

I would refine this procedure as follows: the team member who intends to do the 
merge (the "merger"),
needs to issue re-review requests for all unresolved change requests (there is 
a spinning button next the
name of the reviewer to do this). The person who receives the re-review request 
can either dismiss its
review or indicate that it intends to review within x hours. Otherwise, the 
merger can dismiss the stale review.
 
Matthias



RE: More GitHub labels

2020-09-10 Thread Dr. Matthias St. Pierre

> Your suggestion seems workable too.  PRs are merged with outstanding change 
> requests indicated
> — a reviewer comments, the comments are addressed then a different reviewer 
> approves without
> the original review being removed.  The labels are a bit more in your face.  
> A hybrid “hold: required changes see review/comments” might be workable.

GitHub can be configured to require approval. It then gives a clear visual 
indication that the PR is
not ready to be merged, and the Merge button is greyed out. This should be 
obvious enough,
even more obvious than a label, which can also easily be ignored.

Of course, our merge procedure circumvents the merge button, I'm only talking 
about the visual
indicator. Alternatively, the pre-receive-hook on the git.openssl.org server 
could enforce the policy
by checking the  reviewer state via GitHub API queries.

Matthias



RE: More GitHub labels

2020-09-10 Thread Dr. Matthias St. Pierre
> Just wondering if we should have two new labels: “hold: tests needed” and 
> “hold: documentation needed” labels?
> There are a number of PRs that come through where one or both of these are 
> missing missing.

The two use cases you mention are actually better handled by a change request 
(via GitHub review) instead of a label:
A team member can formulate a change request to block the merging. Here he has 
more freedom to formulate what
needs to be done. This includes your two use cases, as well as the use case for 
the label [hold: need rebase].

The problem with it is that currently we count only approvals and don’t 
consider unresolved change requests
as a blocker. I think we should change that. This does not mean that a reviewer 
who made a change request
two months ago and lost interest is forced to re-review, only that such stale 
reviews must be dismissed
explicitly, if the reviewer does not respond to a re-review request within a 
certain time period.

Matthias



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

2020-09-05 Thread Dr. Matthias St. Pierre
Both suggestions make sense to me and they were discussed several times in the 
weekly calls.
So you have my support whether there will be the need for a formal vote or not.

> An otc_hold was put on this.. Do we need to have a formal vote?

Since Tim placed the hold, only he can remove it. If he doesn’t, an OTC vote is 
inevitable.

https://github.com/openssl/openssl/pull/12778#issuecomment-686348526

In that case, let’s just have the vote and finish it quickly.

Matthias


From: openssl-project  On Behalf Of SHANE 
LONTIS
Sent: Saturday, September 5, 2020 5:48 AM
To: openssl-project@openssl.org
Subject: Reordering new API's that have a libctx, propq

PR #12778 reorders all the API’s of the form:
EVP_XX_fetch(libctx, algname, propq)
So that the algorithm name appears first..
e.g: EVP_MD_fetch(digestname, libctx, propq);
This now logically reads as 'search for this algorithm using these parameters’.

The libctx, propq should always appear together as a pair of parameters.
There are only a few places where only the libctx is needed, which means that 
if there is no propq it is likely to cause a bug in a fetch at some point.
This keeps the API’s more consistent with other existing XXX_with_libctx API’s 
that put the libctx, propq at the end of the parameter list..
The exception to this rule is that callback(s) and their arguments occur after 
the libctx, propq..

e.g:
typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)
(const OSSL_STORE_LOADER *loader,
 const char *uri, OPENSSL_CTX *libctx, const char *propq,
 const UI_METHOD *ui_method, void *ui_data);

An otc_hold was put on this.. Do we need to have a formal vote?
This really needs to be sorted out soon so the API’s can be locked down for 
beta.


Also discussed in a weekly meeting and numerous PR discussions was the removal 
of the long winded API’s ending with ‘with_libctx’
e.g CMS_data_create_with_libctx
The proposed renaming for this was to continue with the _ex notation.. If there 
is an existing _ex name then it becomes _ex2, etc.
There will most likely be additional parameters in the future for some API’s, 
so this notation would be more consistent with current API’s.
Does this also need a vote?

Regards,
Shane




RE: OTC vote on PR11188

2020-08-27 Thread Dr. Matthias St. Pierre
-0

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Thursday, August 27, 2020 12:06 PM
> To: openssl-project@openssl.org
> Subject: OTC vote on PR11188
> 
> FYI, I have initiated the following vote on PR11188. Please see the
> comments in that PR for the background. I will report back with the
> result of the vote once known.
> 
> topic: The performance improvements provided in PR11188 should be
>considered a bug fix and therefore acceptable for backport to
>1.1.1
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-08-27
> closed: 2020-mm-dd
> 
> 
> Matt
> 



Re: VOTE: Rename OPENSSL_CTX to OSSL_LIB_CTX (as proposed by pull request #12621)

2020-08-20 Thread Dr. Matthias St. Pierre

The vote has been closed, the verdict is:

    accepted:  yes  (for: 5, against: 0, abstained: 4, not voted: 2)


On 18.08.20 13:12, Dr. Matthias St. Pierre wrote:

The main rationale behind this change is consistency, because many of the new
OpenSSL 3.0 types have an OSSL_ prefix, and OPENSSL_CTX is a notable exception.
More details can be found in the description and thread of pull request #12621.

There was a discussion on openssl-committers and an initial poll on doodle 
about the
favourite replacements for OPENSSL_CTX 
(https://doodle.com/poll/drku9ziwvkp6tw25).

Matthias





VOTE: Rename OPENSSL_CTX to OSSL_LIB_CTX (as proposed by pull request #12621)

2020-08-18 Thread Dr. Matthias St. Pierre

The main rationale behind this change is consistency, because many of the new
OpenSSL 3.0 types have an OSSL_ prefix, and OPENSSL_CTX is a notable exception.
More details can be found in the description and thread of pull request #12621.

There was a discussion on openssl-committers and an initial poll on doodle 
about the
favourite replacements for OPENSSL_CTX 
(https://doodle.com/poll/drku9ziwvkp6tw25).

Matthias



RE: TLS 1.3 illustrated

2020-08-16 Thread Dr. Matthias St. Pierre
Nice, thank you for the link. FWIW, there is also a TLS 1.2 illustrated page:

https://tls12.ulfheim.net

Matthias


From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Sunday, August 16, 2020 8:19 AM
To: openssl-project@openssl.org
Subject: TLS 1.3 illustrated

This might be interesting to some:

https://tls13.ulfheim.net

Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia






RE: RAND_DRBG

2020-07-27 Thread Dr. Matthias St. Pierre
> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
> with the move to provider based infrastructure.

Actually, it is not the RAND_DRBG API itself (as it is in 1.1.1) which is 
messy. It’s the fact that part of its interface is very low level
and that the EVP_RAND interface tries to move away from that. In particular, in 
the future seed sources will be pluggable by chaining
the primary DRBG to an entropy source which is provided as a fetchable EVP_RAND 
interface, not by replacing some internal callbacks.
(Note however, that fetchable entropy sources,  in particular sources of low 
quality, are not implemented yet and won’t be implemented
in time for version 3.0. But as far as I’m concerned, I can wait for 3.1, since 
my company is still transitioning from 1.0.2 to 1.1.1. )

Moving to the new approach while at the same time having to retain 
compatibility to the old approach, that’s what is creating the mess
under the hood. Most notably, it’s the two functions RAND_DRBG_set_callbacks() 
and RAND_DRBG_set() which are creating the problems.
Pull Request #12509 attempts to untangle the two RNG interfaces by providing 
two unrelated triples of RNGs (option 2 in Pauli’s proposal),
an EVP_RAND triple and a RAND_DRBG triple. This does not work out well, as 
pointed out by me in [1]. There might be a variant of option (2)
however to fix the problem described in [1], which could provide better 
compatibility:

4. Offer legacy RAND_METHOD (e.g. RAND_drbg_method(), RAND_OpenSSL_legacy(), …) 
as an alternative to RAND_OpenSSL()

Anybody who currently uses the RAND_DRBG callback mechanism, could activate 
this legacy RAND_METHOD to switch from the new
EVP_RAND triple to the legacy RAND_DRBG triple of random generators, and their 
callbacks would continue to work as expected.

I still favour option (1), but (4) might be a reasonable compromise. It comes 
at a price, because both RAND_METHODs need to be fully
supported  and tested thoroughly.

Matthias


[1] https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828

From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Monday, July 27, 2020 3:08 AM
To: openssl-project@openssl.org
Subject: RAND_DRBG

The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
with the move to provider based infrastructure.
They are definitely being deprecated in master but without more, the extra 
layer of indirection and additional complexity generating random numbers will 
remain.

The option I see are:

1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking change.
2. Bypass RAND_DRBG and live with a breaking change (refer: 
https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828)
3. Leave things as they currently are in master.

The first two are breaking changes and will require an OMC vote.


Some pertinent points:

1. RAND_bytes will continue to work as is — this API is perfect for almost 
everyone.
2. The RAND_METHOD functionality remains — this allows wholesale replacement of 
OpenSSL’s RNGs if desired.
3. The name EVP_RAND is the working name and might change — this is not 
relevant to this discussion.
4. The RAND_DRBG APIs are unlikely to be widely used — they were introduced in 
1.1.1.  The two users I know of (Akamai and NCP) are both fine with them being 
removed.


Thoughts anyone?


Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia



RE: API renaming

2020-07-24 Thread Dr. Matthias St. Pierre
> They also correspond directly to EVP_MAC and EVP_KDF types. Would the types 
> change as well?

Yes, if we would decide to change the EVP_MAC and EVP_KDF prefix, then this 
would not only
apply to the functions, but to the types as well.

Matthias



RE: API renaming

2020-07-24 Thread Dr. Matthias St. Pierre
> I was thinking OSSL_LIBCTX?

That's a good choice and consistent with how we name the variable in most (but 
not all) places:

OPENSSL_CTX *libctx;

I volunteer to raise a pull request which does a scripted bulk rename, as soon 
as we have made
a decision. Ideally, the bulk renaming should go in shortly before the next 
alpha. Having it
automated by a script would ease rebasing of other still unmerged pull requests 
over the change.

Matthias

> -Original Message-
> From: SHANE LONTIS 
> Sent: Friday, July 24, 2020 9:43 AM
> To: Dr. Matthias St. Pierre 
> Cc: Richard Levitte ; openssl-project@openssl.org
> Subject: Re: API renaming
> 
> I was thinking OSSL_LIBCTX?
> 



RE: API renaming

2020-07-24 Thread Dr. Matthias St. Pierre
> I think the KDF and MAC got back ported also...

In this case it would be no question that we should keep the names EVP_KDF and 
EVP_MAC.



RE: API renaming

2020-07-24 Thread Dr. Matthias St. Pierre
I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree with 
Shane
that we should go for a single prefix and not have two alternatives. Existing 
prefixes
for things like feature macros should remain as they are, but if the OSSL_ 
prefix is
our choice for the future, we should start using it consistently for _all_ new 
APIs in 3.0.
And not make it a random choice (pun intended) depending on whether the API went
into master early or late. So my favorite choice is a consistent renaming, i.e.

OSSL_MAC, OSSL_KDF, OSSL_RAND, OSSL_CTX, ...

OTOH, it would be ok for me if we would make an exception for EVP_MAC and 
EVP_KDF,
because they have a long EVP history, as Matt pointed out. But using the EVP_ 
prefix
for the new RAND interface never made sense to me.

What bothers me about OPENSSL_CTX in particular is the fact that it is a 
mixture of
a non-abbreviated and an abbreviated word. IMHO it should be either OSSL_CTX or
OPENSSL_CONTEXT, and the former is obviously preferrable for its length.

Matthias


> -Original Message-
> From: openssl-project  On Behalf Of 
> Richard Levitte
> Sent: Friday, July 24, 2020 8:34 AM
> To: openssl-project@openssl.org
> Subject: Re: API renaming
> 
> I'm fine with that, really.
> 
> I have a preference for OSSL_, but if we look through the source,
> there's reason for either.  So far, we've majorly used OPENSSL_ for
> things like feature macros (disabling macros, really), environment
> variables, that sort of thing, while OSSL_ has become the primary
> choice for new APIs ("less klunky", I think the judgement was in that
> past discussion I keep referring to).
> 
> And yeah, I hear you from all the way around the planet, there are
> some recent name choice that were made that give pause and are
> arguably a mistake in this regard.  EVP_MAC and EVP_KDF could have
> been OSSL_MAC and OSSL_KDF.  OPENSSL_CTX could have been OSSL_CTX.
> I have no problem recognising that.  But, they are there, even though
> only in master (*).  This is question of what we do going forward (a
> yet unmerged PR with a new API is as good a target as any).
> 
> Cheers,
> Richard
> 
> (*) I'm not sure I see master as something untouchable in this regard,
> as the development is still not frozen (alpha), so I for one could
> easily see a rename fest happening, should we decide for it.  That
> must happen before we enter the beta phase, though...
>


RE: Cherry-pick proposal

2020-07-11 Thread Dr. Matthias St. Pierre
Independently of the outcome of the vote I think we should adopt the habit to 
wait with the
merging of a backport PR until the original PR has been approved and merged. As 
an indicator
and reminder, I added a new label (hold: wait for master), which I applied to 
#12417.

https://github.com/openssl/openssl/labels/hold%3A%20wait%20for%20master

Matthias


> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Thursday, July 9, 2020 11:13 AM
> To: openssl-project@openssl.org
> Subject: Re: Cherry-pick proposal
> 
> 
> 
> On 02/06/2020 15:29, Matt Caswell wrote:
> >
> > There's been no further discussion on this for quite a while, so I will
> > start an OTC vote based on the vote text proposed by Matthias and report
> > back the results here.
> 
> Sorry, I forgot to report back. The final result was:
> 
> +1: 4
> -1: 4
>  0: 3
> 
> So the result was tied. According to our bylaws this means that the vote
> does not pass.
> 
> Matt



RE: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Dr. Matthias St. Pierre
Since already a few backporting requests to 1.1.1 have accumulated which are 
controversial
or not allowed for an LTS release, would it make sense to consider creating a 
new 1.1.2 STS
branch which could then receive such changes?

Matthias



RE: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote?

2020-05-27 Thread Dr. Matthias St. Pierre
> I mean I am definitely not against having a vote if someone feels it
> should be done but if nobody requires it, I do not think it would be a
> violation of anything if this is merged without a vote.

Tomáš I dont't mind following your viewpoint at all, and if the OMC thinks
the same, that's fine. Also, I agree that an OTC/OMC discussion does not
automatically have to be resolved by an OTC/OMC vote.

Maybe my original post was a bit misleading. The main motivation behind it
was my impression that we tend to start many technical discussions with a
general discussion about whether it should be discussed/decided by the
OMC or the OTC.

Matthias




RE: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote?

2020-05-27 Thread Dr. Matthias St. Pierre

> IMO it seems appropriate to have an OMC vote on this topic (or should it
> be OTC?). Possible wording:

Personally, I would prefer if technical questions would by default be discussed 
(and voted on)
by the OTC, unless an OMC member explicitly puts in his veto and claims that 
higher level
strategical interests of the OpenSSL project are affected.

But according to the current wording of the bylaws, I would say it is a 
'feature requirement' and
requires an OMC vote:

> The OMC:
>
> * makes all decisions regarding management and strategic direction of the 
> project; including:
> - business requirements;
> - feature requirements;
> - platform requirements;
> - roadmap requirements and priority;
> - end-of-life decisions;
> - release timing and requirement decisions;

Matthias



RE: Cherry-pick proposal

2020-04-29 Thread Dr. Matthias St. Pierre
I completely agree with Nicolas reasoning. But we should try to keep things 
simple and not
add too many regulations. What do you think of the following formulation?

>
For change requests which target both the master and the OpenSSL_1_1_1-stable 
branch,
the following procedure should be followed:

- First, a pull request needs to be opened against the master branch for 
discussion.
  Only after that pull request has received the necessary amount of approvals,
  a separate pull request can be opened  against the OpenSSL_1_1_1-stable 
branch.

- A separate pull request against the OpenSSL_1_1_1-stable branch is required.
  This holds - contrary to common practice - even if the change can be 
cherry-picked
  without conflicts from the master branch. The only exception from this rule 
are
  changes which are considered 'CLA: trivial', like e.g. typographical fixes.
>

Matthias


From: openssl-project  On Behalf Of Nicola 
Tuveri
Sent: Wednesday, April 29, 2020 3:05 PM
To: openssl-project@openssl.org
Subject: Re: Cherry-pick proposal

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 PRs, which make review and 
revisiting our history very hard)
- trivial documentation changes, such as fixing typos, can be exempted

It must be clear that although things have changed a lot in the inner 
plumbings, we have so far managed to keep crypto implementations very much in 
sync between 1.1.1 and master, by applying the policy of "first merge to 
master, then possibly backport".

What I am afraid of in Bernd's proposal, and recent discussions, is that 
committers might be tempted to open PRs changing implementations against 1.1.1 
first (to avoid frequent rebases due to unrelated changes) and let the `master` 
PR stagnate indefinitely because it feels like too much hassle to keep up with 
the development pace of master if your PR collaterally changes certain files.

An example of what can go wrong if we open a 1.1.1 PR concurrently with a PR 
for master can be seen here:
- `master` PR: https://github.com/openssl/openssl/pull/10828
- `1.1.1` PR: https://github.com/openssl/openssl/pull/11411

I highlight the following problems related to the above example:
- as you can see the `1.1.1` has been merged, even though the `master` one has 
stalled while discussing which implementation we should pick. (this was my 
fault, I should have applied the `hold` label after stating that my approval 
for 1.1.1 was conditional to approving the `master` counterpart)
- discussion that is integral part of the decision process was split among the 
2 PRs, with over 40 comments each
- there is no clear link between the `master` PR and the `1.1.1` PR for the 
same feature (this makes it very difficult to review what is the state of the 
"main" PR, and if we or someone else in some months or years needs to go check 
why we did things the way we did, will have a hard time connecting the dots)

I also think that the proposal as written is a bit misleading: I would very 
like to keep seeing in 1.1.1 a majority of commits cherry-picked from commits 
merged to master, with explicit tags in the 1.1.1 commit messages (this helps 
keeping the git history self-contained without a too strong dependency on 
GitHub).
I would rephrase the proposal as follows:

Merge to 1.1.1 should only happen after approval of a dedicated PR 
targeting the OpenSSL_1_1_1-stable branch.

Potential amendments that I'd like the OTC to consider are:
a) before the end of the sentence add ", with the optional exclusion of trivial 
documentation-only changes"
b) after the end of the sentence add "In composing backport pull requests, 
explicit cherry-picking (`git cherry-pick -x`) of relevant commits merged to 
`master` or another stable branch is recommended and encouraged whenever 
possible."
c) adopt a more general statement:

Merge to any stable branch should only happen after approval of a dedicated 
PR targeting specifically that branch.




So, in summary, I would agree with the proposal, as I definitely think Bernd 
has a good point about running the 1.1.1 CI for things we think should be 
backported, but requires careful consideration of additional requirements to 
avoid duplicating review efforts, splitting discussions that should be kept 
together, or disrupting our processes making 1.1.1 and master diverge more than 
necessary.


Cheers,


Nicola

On Wed, 29 Apr 2020 at 14:08, Matt Caswell 
mailto:m...@openssl.org>> wrote:

The OTC have received this proposal and a request that we vote on it:

I would like to request that we do not allow cherry-picks between master
and 1.1.1-stable because these two versions are now very different, if a

RE: Revisiting tradition: branches and tags

2020-04-14 Thread Dr. Matthias St. Pierre
> > We change the GitHub setup such that pull requests to stable
> > branches need to be based onto the new-style branches, but keep the
> > old-style stable branches in sync with the new-style branches for a
> > little while.
> 
> Er...  how do you change that Github setup?  I thought it simply
> showed a list of all available branches regardless.  So if we got a
> duplicate set, it's going to show both, isn't it?  Considering that
> the github repo is a --mirror of the git.openssl.org repo, I'm not
> sure how the old branch refs would be filtered out...

You are right, I thought it was possible using protected branches, but that
doesn't seem to be the case.

> 
> It seems to me like this discussion is splitting into two:
> 
> 1)  Start with new names for 3.0 and on (I can only see positive
> responses so far, even with Matt's hesitance)
> 2)  Rename of the old names.
>
> As far as I can see, those two don't have to be in absolute sync, even
> though that would be desirable.  In other words, we can figure out the
> details of 2 even after we've started 1.

Agreed.

The best thing would be to publicly announce the branch renaming in a blog post
with a sufficient notice time  (3-6 months) and with detailed instructions
how to rename the local branches and how to reset the upstream branches
(using `git branch --set-upstream-to=...`). Just as we did for the grand code 
reformatting. We might even provide a smart helper script for users to do the
local conversion.


Matthias



RE: Revisiting tradition: branches and tags

2020-04-14 Thread Dr. Matthias St. Pierre
> > Is it possible to set up alias names for the historical branches?
> 
> It's possible yes.  The hard part is 1.1.1.  There *is* something
> called 'git symbolic-ref', but they can only be added in repos we have
> physical access to, so while can add those on our git server, and they
> will work, we cannot add them in github.
> 
> Ref git help symbolic-ref

Symbolic references are *not* the right solution to the problem IMO. They are 
not equivalent to branches.
Checking out a symbolic reference leaves you in the 'detached HEAD' state:

msp@msppc:~/src/openssl$ git symbolic-ref ossl111 
refs/heads/OpenSSL_1_1_1-stable
msp@msppc:~/src/openssl$ cd ../openssl-1.1.1
msp@msppc:~/src/openssl-1.1.1$ git checkout ossl111
Note: switching to 'ossl111'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

The proper way to do it IMO is to create new branch and tag references for all 
the stable branches
resp. release tags. We change the GitHub setup such that pull requests to 
stable branches need to
be based onto the new-style branches, but keep the old-style stable branches in 
sync with the new-style
branches for a little while. Currently, the only old-style branch which needs 
to be synchronized is
` OpenSSL_1_1_1-stable`. This could easily be done by the git post-receive hook 
on git.openssl.org.
In fact, all old-style branch and tag references for all eol-branches could be 
removed immediately.

Matthias



RE: Revisiting tradition: branches and tags

2020-04-13 Thread Dr. Matthias St. Pierre
> Is it possible to set up alias names for the historical branches?

... and tags, of course. All one needs to do is to write a little script which 
creates the
additional references and pushes them.


Matthias



RE: Revisiting tradition: branches and tags

2020-04-11 Thread Dr. Matthias St. Pierre
I love the new naming scheme, in particular the fact that it's all-lowercase 
and does not
mix dashes and underscores anymore. I don't recall how often I cursed about the 
current
scheme which is so typer unfriendly.

I'd like to see *all* stable branch names and release tags converted to 
new-style uniformly
(keeping the old names for compatibility), so we have an overall consistent 
scheme and people
don't need to switch back and forth between naming conventions in the future 
when doing
historical investigations. The old names could be deprecated for later removal.

Matthias



> -Original Message-
> From: openssl-project  On Behalf Of 
> Richard Levitte
> Sent: Friday, April 10, 2020 8:28 PM
> To: openssl-project@openssl.org
> Subject: Revisiting tradition: branches and tags
> 
> Once upon a time, there was CVS (*).
> 
> The story could stop there, but since CVS was what was available,
> OpenSSL was versioned with CVS.
> 
> Among limitations that came with CVS was the allowed syntax in tag and
> branch names; letters, digits, dashes and underscores.  At the time,
> eveyone that wanted to encode a version number in a tag had to convert
> periods to some other character.  We chose underscores, ending up with
> tags like this:
> 
> OpenSSL_0_9_7-beta2
> OpenSSL_0_9_7a
> 
> Furthermore, the culture that we have with git, where branches are
> being pulled between repositories...  where you can actually have a
> multitude of repositories and pull data between them, was very hard if
> not practically impossible with CVS.  So, we occasionally had feature
> branches for longer term work.  To distinguish our so called stable
> branches, we had branch names with '-stable' added at the end:
> 
> OpenSSL_0_9_7-stable
> 
> We *could* have had something shorter, like 'OpenSSL_0_9_7xx', but
> I guess that was too easy to mix up with our letter releases.
> 
> With git, however, there's no technical reason why we must maintain
> what was originally a technical limitation.  I therefore propose that
> we start using tags like this starting with OpenSSL 3.0:
> 
> openssl-3.0.0-alpha1
> openssl-3.0.0-beta2
> openssl-3.0.0
> openssl-3.0.1
> openssl-3.1.0
> 
> This is a little more than just avoiding to change the periods with
> underscores.  However, if you look at the tar files we've released for
> a long time, that's the naming format they use, and I can see benefits
> in having the tags for a release match the tar file of the same
> release:
> 
> openssl-0.9.7a.tar.gz
> openssl-0.9.7a.tar.gz.asc
> openssl-0.9.7a.tar.gz.md5
> 
> Future tar files would be numbered with the new version scheme, of
> course:
> 
> openssl-3.0.0-alpha1.tar.gz
> openssl-3.0.0-beta2.tar.gz
> openssl-3.0.0.tar.gz
> openssl-3.0.1.tar.gz
> openssl-3.1.0.tar.gz
> 
> So what about release branches?  We could actually follow a very
> similar new pattern, just replace the last digit with, say, an 'x', to
> signify that this branch will contain a series of patch releases:
> 
> openssl-3.0.x
> 
> In this branch, one would expect to see the tags 'openssl-3.0.0',
> 'openssl-3.0.1', 'openssl-3.0.2', ...
> 
> Earlier today, I submitted a new release script that codifies exactly
> this:  https://github.com/openssl/openssl/pull/11516
> 
> Thoughts?
> 
> Cheers,
> Richard
> 
> (*) Well, not quite, there was RCS, there was SCCS, and a few other
> versioning systems that would make your skin crawl by today's
> standards, even more so than CVS.
> 
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/


RE: 1.1.1f

2020-03-26 Thread Dr. Matthias St. Pierre
> Please also consider reverting the change for the 3.0 alpha release as well, 
> see Daniel Stenbergs comment
> https://github.com/openssl/openssl/issues/11378#issuecomment-603730581

Never mind my last comment. I noticed a lot of discussion has been going on in 
issue #11378 and I was not
quite up-to-date.

Matthias



RE: 1.1.1f

2020-03-26 Thread Dr. Matthias St. Pierre
I agree, go ahead.

Please also consider reverting the change for the 3.0 alpha release as well, 
see Daniel Stenbergs comment
https://github.com/openssl/openssl/issues/11378#issuecomment-603730581

Matthias


From: openssl-project  On Behalf Of Dmitry 
Belyavsky
Sent: Thursday, March 26, 2020 3:48 PM
To: Matt Caswell 
Cc: openssl-project@openssl.org
Subject: Re: 1.1.1f


On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell 
mailto:m...@openssl.org>> wrote:
The EOF issue (https://github.com/openssl/openssl/issues/11378) has
resulted in us reverting the original EOF change in the 1.1.1 branch
(https://github.com/openssl/openssl/pull/11400).

Given that this seems to have broken quite a bit of stuff, I propose
that we do a 1.1.1f soon (possibly next Tuesday - 31st March).

Thoughts?

I strongly support this idea.

--
SY, Dmitry Belyavsky


RE: Release done

2020-03-17 Thread Dr. Matthias St. Pierre
Unfortunately, the server side hooks are not published anywhere. So I was not 
able to figure out
that there might be a problem. I should have given you a heads-up nevertheless, 
sorry for the omission.

Matthias


> -Original Message-
> From: Matt Caswell 
> Sent: Tuesday, March 17, 2020 8:29 PM
> To: Dr. Matthias St. Pierre ; 
> openssl-project@openssl.org
> Subject: Re: Release done
> 
> 
> 
> On 17/03/2020 18:53, Dr. Matthias St. Pierre wrote:
> >> Problems were due to:
> >> ...
> >> - Rename of CHANGES/NEWS to CHANGES.md/NEWS.md
> >
> > Strange  what exactly was your problem?
> 
> The website is supposed to update itself automatically when we push
> stuff, so things like release notes etc get automatically generated.
> From tools/release/README.md:
> 
> Verify that the release notes, which are built from the CHANGES file
> in the release, have been updated. This is done automatically by the
> commit-hook, but if you see a problem, try the following steps:
> 
> cd /var/www/openssl
> sudo -u openssl -H make relupd
> sudo -u openssl ./bin/purge-one-hour
> 
> This didn't happen unfortunately. When I ran "make relupd" manually I got:
> 
> make: *** No rule to make target
> '/var/cache/openssl/checkouts/openssl/CHANGES', needed by
> 'news/changelog.txt'.  Stop.
> 
> That particular make target is related to the *master* CHANGES file
> (there are similar targets I think for other branches).
> 
> Matt


RE: Release done

2020-03-17 Thread Dr. Matthias St. Pierre
> Problems were due to:
> ...
> - Rename of CHANGES/NEWS to CHANGES.md/NEWS.md

Strange  what exactly was your problem?

I anticipated this problem on the weekend and checked the release scripts.
After some investigation, I came to the conclusion that it wouldn't be a problem
for the OpenSSL_1_1_1-stable branch yet, because the markdown revamping
happened only on master. What did I miss?

Matthias


P.S.: As a byproduct of my investigations I created 
https://github.com/openssl/tools/pull/64



RE: My next step in handling stale PRs

2020-03-03 Thread Dr. Matthias St. Pierre
Hi Mark,

your proposal sounds reasonable, and I let me take the opportunity to pay a 
compliment to your bot,
he is doing a great job :-).

I have just a tiny little nit: since the sender is clearly identified as 
"openssl-machine", it is not necessary
to add a special prefix to the text of the message to indicate the message was 
automated. In fact, the
"ready-to-merge" reminder, which started it all, doesn't have a prefix.  But 
recently you started to
add various prefixes like "Automated Ping:" and now "openssl-machine:". I'd 
prefer if the messages
were consistently without a prefix, because they only distract from the gist of 
the message IMHO,
in particular consistency junkies like me.

Matthias




RE: OpenSSL Logo (was: New GitHub Project Landing Page)

2020-02-28 Thread Dr. Matthias St. Pierre
> 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

FYI: there is another discussion about the OpenSSL logo going on in pr #11200.
In particular this post contains a link to text+css of the OpenSSL logo:

https://github.com/openssl/openssl/pull/11200#issuecomment-592673575

Matthias




RE: OpenSSL Logo

2020-02-27 Thread Dr. Matthias St. Pierre

> According to that site, it used to be at
> 
> http://openssl.com/images/openssl-logo.png
>

Thanks to the Wayback Machine, nothing gets lost: Here is the historical 
OpenSSL Logo:

https://web.archive.org/web/20141231112717/http://openssl.com/images/openssl-logo.png

Matthias




Re: OpenSSL Logo

2020-02-27 Thread Matthias St. Pierre


Well then, if Tomáš manages to convert it to SVG and if there is no problem
with the font, you may raise a pull request. (BTW: what is the font's name?)

Please note that you might have to enlarge the bounding box to increase
the border around the text. Because GitHub will automatically scale the
image to full width on https://github.com/openssl/openssl and there is no
way to downsize the image if we restrict ourselves to plain markdown
(i.e. without adding inline HTML).  See [1] for an example.


Matthias


[1] https://github.com/openssl/openssl/blob/master/doc/images/openssl.svg



On 27.02.20 14:08, Paul Yang wrote:

Right, there is no 3D.

Regards,

Paul Yang


On Feb 27, 2020, at 6:54 PM, Tomas Mraz mailto:tm...@redhat.com>> wrote:

On Thu, 2020-02-27 at 11:28 +0100, Matthias St. Pierre wrote:

Thank you for the clarification, Mark.

So this means we have some artistic freedom in choosing the logo?

Personally, I'm not sure whether we really should aim at restoring
the historic logo. IMHO this ornate font with 3D appearance reminds
me of the nineties and has slightly gone out of style. Just take a
look
how the Google logo changed over time [1], for example.

I think it's time for a more modern layout. Let's have a competition.


I like the logo as sent by Paul. There is no "3D appearance" in it.

--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
 Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]







Re: OpenSSL Logo

2020-02-27 Thread Matthias St. Pierre

Sorry for linking a german page (although the video is english).

This seems to be the corresponding english version.

https://googleblog.blogspot.com/2015/09/google-update.html



On 27.02.20 11:28, Matthias St. Pierre wrote:

Thank you for the clarification, Mark.

So this means we have some artistic freedom in choosing the logo?

Personally, I'm not sure whether we really should aim at restoring
the historic logo. IMHO this ornate font with 3D appearance reminds
me of the nineties and has slightly gone out of style. Just take a look
how the Google logo changed over time [1], for example.

I think it's time for a more modern layout. Let's have a competition.

Matthias



[1] https://germany.googleblog.com/2015/09/google-update.html






Re: OpenSSL Logo

2020-02-27 Thread Matthias St. Pierre

Thank you for the clarification, Mark.

So this means we have some artistic freedom in choosing the logo?

Personally, I'm not sure whether we really should aim at restoring
the historic logo. IMHO this ornate font with 3D appearance reminds
me of the nineties and has slightly gone out of style. Just take a look
how the Google logo changed over time [1], for example.

I think it's time for a more modern layout. Let's have a competition.

Matthias



[1] https://germany.googleblog.com/2015/09/google-update.html



On 27.02.20 11:16, Mark J Cox wrote:

On Thu, Feb 27, 2020 at 9:31 AM Matthias St. Pierre
 wrote:

Because after all, the shape of the logo is an
essential part of the OpenSSL 'trade mark'.

Although the current website logo as of January 2020 was used as the
specimen to show our use of the trademark at renewal time, our
official trademark registration is a standard character mark:  i.e.
"The mark consists of standard characters without claim to any
particular font style, size, or color.".

Regards, Mark




Re: OpenSSL Logo

2020-02-27 Thread Matthias St. Pierre



The logo on this site

https://unixblogger.com/how-to-convert-split-p12-certificates-into-single-files/

seems to be very similar to the one on your stickers, Paul.

According to that site, it used to be at

http://openssl.com/images/openssl-logo.png

It even has a (TM) marker. Can the OMC please clarify whether this is the
current official OpenSSL logo? And if it is, point us to a location where the
original file can be found?

Matthias




On 27.02.20 10:31, Matthias St. Pierre wrote:


The openssl.svg was chosen to match the current logo at

https://www.openssl.org/

as close as possible. According to the style sheet, the font of the logo
is HelveticaNeue-Light.

https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158

While I'm not opposed to brush up the OpenSSL logo, I think this can't
be done simply be replacing it on the fly. I think this requires a general
discussion among the team members and finally an OMC decision,
and shouldn't be rushed. Because after all, the shape of the logo is an
essential part of the OpenSSL 'trade mark'.

If we we want to brush up the Logo, we should give everybody time to come up
with proposals and then have an open contest, ideally among all committers,
not only OMC or OTC.  (And you can be sure, I will come up with a proposal ;-) )

Finally, the OMC can run a vote, for example whether to pick the winner of the
contest or to leave the logo as it is.

Regards,

Matthias



On 27.02.20 09:58, Paul Yang wrote:

Sent

Regards,

Paul Yang


On Feb 27, 2020, at 3:15 PM, Tomas Mraz mailto:tm...@redhat.com>> wrote:

Could you, please, send me the .ai file? I'll try converting it. Is the
font freely available?

Tomas

On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote:

The logo could be changed to the 'correct-font' version -as the one
printed on the stickers I brought to Nuremberg

I have an '.ai’ image file at hand an I think someone needs to figure
how to extract the image then include it in the markdown file...

Regards,

Paul Yang






Re: OpenSSL Logo (was: New GitHub Project Landing Page)

2020-02-27 Thread Matthias St. Pierre


The openssl.svg was chosen to match the current logo at

https://www.openssl.org/

as close as possible. According to the style sheet, the font of the logo
is HelveticaNeue-Light.

https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158

While I'm not opposed to brush up the OpenSSL logo, I think this can't
be done simply be replacing it on the fly. I think this requires a general
discussion among the team members and finally an OMC decision,
and shouldn't be rushed. Because after all, the shape of the logo is an
essential part of the OpenSSL 'trade mark'.

If we we want to brush up the Logo, we should give everybody time to come up
with proposals and then have an open contest, ideally among all committers,
not only OMC or OTC.  (And you can be sure, I will come up with a proposal ;-) )

Finally, the OMC can run a vote, for example whether to pick the winner of the
contest or to leave the logo as it is.

Regards,

Matthias



On 27.02.20 09:58, Paul Yang wrote:

Sent

Regards,

Paul Yang


On Feb 27, 2020, at 3:15 PM, Tomas Mraz mailto:tm...@redhat.com>> wrote:

Could you, please, send me the .ai file? I'll try converting it. Is the
font freely available?

Tomas

On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote:

The logo could be changed to the 'correct-font' version -as the one
printed on the stickers I brought to Nuremberg

I have an '.ai’ image file at hand an I think someone needs to figure
how to extract the image then include it in the markdown file...

Regards,

Paul Yang




New GitHub Project Landing Page

2020-02-26 Thread Dr. Matthias St. Pierre
The OpenSSL Project GitHub has a new landing page:

https://github.com/openssl/openssl

Scroll down. Enjoy.


Matthias




Re: Deprecation

2020-02-14 Thread Matthias St. Pierre




On 14.02.20 10:21, Matthias St. Pierre wrote:


Because deprecation without removal is futile, it increases complexity of the 
code
instead of reducing it.

Matthias



To underlinie my last statement, I added the initial release dates:

    OPENSSL_NO_DEPRECATED_0_9_8  # 05 Jul 2005
    OPENSSL_NO_DEPRECATED_1_0_0  # 29 Mar 2010
    OPENSSL_NO_DEPRECATED_1_0_1  # 14 Mar 2012


Re: Deprecation

2020-02-14 Thread Matthias St. Pierre




On 14.02.20 08:24, Tomas Mraz wrote:


I do not understand the pushback too much - Perhaps it could be
resolved by proper explanation that deprecation does not mean a
removal?

Also even if some stuff deprecated in 3.0 is removed in 4.0, it does
not necessarily mean that engines must be removed in the same release.
They can continue to be supported (just deprecated) until 5.0 for
example.

I think that doing the deprecation as early as possible is better - it
properly gives the signal that the engine interface is legacy and it
will disappear at some point. It provides more time for 3rd party
engines to transform into providers.



I agree with Tomas. In addition, I think it is high time to publish a definite 
timescale
for actually *removing* the older deprecated APIs, at least for the first three 
entries
in the list below:

    OPENSSL_NO_DEPRECATED_0_9_8  #
    OPENSSL_NO_DEPRECATED_1_0_0  #
    OPENSSL_NO_DEPRECATED_1_0_1  #

    OPENSSL_NO_DEPRECATED_1_0_2
    OPENSSL_NO_DEPRECATED_1_1_0
    OPENSSL_NO_DEPRECATED_1_1_1
    OPENSSL_NO_DEPRECATED_3_0

Because deprecation without removal is futile, it increases complexity of the 
code
instead of reducing it.

Matthias



RE: Github PR label automation

2020-02-12 Thread Dr. Matthias St. Pierre
> check.  It will not move to 'ready to merge' state automatically
> unless (or until) all CI passes.  (I'll do a PR for the tool with that
> change shortly).

If the does not automatically remove the "ready to merge" label, but only
refrains from setting it automatically, that's a good compromise I can live 
with.

Matthias



RE: Github PR label automation

2020-02-12 Thread Dr. Matthias St. Pierre
> > Does it also check that the CI says that everything is OK?
>
> Do we want it to?  I assumed that Approval: done was not being applied
> unless tests past (but looking that's not always the case). Can we
> assume that something in "approval: ready to merge" but that failed CI
> won't get merged?  Otherwise I could add a CI check on the move to
> "ready to merge".

It does not check and I don't think it should attempt to do it. The only task of
this script should be to automatically promote the [approval: done] state to 
[approval: ready to merge] after the grace period has expired, because humans
tend to forget that. Anything beyond that, in particular an attempt to judge
whether the approval is valid or not, and whether a CI failure can be ignored or
not, should be left to humans.

Matthias



Re: Travis in solid red mode again

2020-02-03 Thread Matthias St. Pierre

Mission accomplished, Travis just turned green again on master  :-)

https://travis-ci.org/openssl/openssl/builds/645563965?utm_source=github_status_medium=notification

Thanks to Matt, Richard and everybody else who participated in fixing it.


Matthias





RE: Travis in solid red mode again

2020-02-01 Thread Dr. Matthias St. Pierre


> -Original Message-
> From: Matt Caswell 
> Sent: Sunday, February 2, 2020 12:58 AM
> To: Dr Paul Dale ; Dr. Matthias St. Pierre 
> 
> Cc: Salz, Rich ; openssl-project@openssl.org
> Subject: Re: Travis in solid red mode again
> 
> 
> 
> On 01/02/2020 10:39, Dr Paul Dale wrote:
> > I thought I was subscribed but don’t seem to see the failures.
> > I do get the (very many) PR activity emails….
> 
> Oh, actually, maybe I'm wrong. Is it just Appveyor that posts failures
> and not Travis?

I see both CI's posting in January:

https://mta.openssl.org/pipermail/openssl-commits/2020-January/thread.html

Broken: openssl/openssl#30961 (master - 2de5a5f)   Travis CI
Broken: openssl/openssl#30962 (OpenSSL_1_1_1-stable - 10e166a)   Travis CI
Build failed: openssl master.30389   AppVeyor
Build completed: openssl OpenSSL_1_1_1-stable.30390   AppVeyor
Fixed: openssl/openssl#30966 (master - e7b834b)   Travis CI
Fixed: openssl/openssl#30967 (OpenSSL_1_1_1-stable - 2c52a36)   Travis CI
Build failed: openssl master.30394   AppVeyor
Build completed: openssl OpenSSL_1_1_1-stable.30395   AppVeyor
Build failed: openssl master.30405   AppVeyor
Build completed: openssl master.30406   AppVeyor
Build failed: openssl master.30411   AppVeyor
Build failed: openssl master.30412   AppVeyor



RE: Travis in solid red mode again

2020-02-01 Thread Dr. Matthias St. Pierre
> I thought I was subscribed but don’t seem to see the failures.
> I do get the (very many) PR activity emails….

You are right, those “[openssl]  update” mails generate a lot
of noise. Do we really need them? If not, we could just deactivate them.
Alternatively, we could move the CI failures to a separate openssl-ci list.

Matthias



RE: Travis in solid red mode again

2020-02-01 Thread Dr. Matthias St. Pierre
> -Original Message-
> On 01/02/2020 00:34, Salz, Rich wrote:
> >
> >   >  Could we add a CI check for PRs that confirms that the target branch is
> > green in travis?
> >
> > Looking at 
> > https://docs.travis-ci.com/user/notifications/#conditional-notifications 
> > and https://config.travis-
> ci.com/ref/notifications/email it seems like it should be fairly easy 
> configure builds to do "send email to openssl-commits when builds on
> master fail"
> 
> We already have that.

Maybe we should make it a requirement that at least all OTC members subscribe 
to openssl-commits?

Matthias



Travis in solid red mode again

2020-01-31 Thread Matthias St. Pierre



After a much to short green period, Travis has turned to solid red mode again:

https://travis-ci.org/openssl/openssl/builds?utm_medium=notification_source=github_status

This fact causes a lot of pain for reviewers, because every failing job needs 
to be checked manually.
I would be happy to fix some of the failures if I could, but in most cases I 
have no clue what the problem is,
because I can't reproduce the issue locally. Could we try to fix them in a 
joint effort?  For your convenience,
I added a summary of all failing jobs of Build #31837 below.

Since this is not the first time that this happens, I think it is overdue that 
the OTC discusses those constant
build failures and proposes some measures to raise the priority for fixing CI 
errors. One drastic possibility
would be to allow only CI fixing pull requests to be merged as long as master 
and the stable branches are red.
But I am sure there is a golden middle way between such an extreme sanction and 
our current indifference.


Regards,

Matthias






Last Successful Build: #31583 (10 days ago!)
https://travis-ci.org/openssl/openssl/builds/639939072?utm_medium=notification_source=github_status

Recent Build: #31837
https://travis-ci.org/openssl/openssl/builds/644238908?utm_medium=notification_source=github_status


SSL TESTS
=

* 
https://travis-ci.org/openssl/openssl/jobs/644238919?utm_medium=notification_source=github_status
* 
https://travis-ci.org/openssl/openssl/jobs/644238926?utm_medium=notification_source=github_status
* 
https://travis-ci.org/openssl/openssl/jobs/644238929?utm_medium=notification_source=github_status

>  Test Summary Report
> ---
>  80-test_ssl_new.t    (Wstat: 256 Tests: 30 Failed: 1)
>    Failed test:  4
>    Non-zero exit status: 1
>  80-test_ssl_old.t    (Wstat: 256 Tests: 6 Failed: 1)
>    Failed test:  2
>    Non-zero exit status: 1



BORINGSSL AND KRB5
==

* 
https://travis-ci.org/openssl/openssl/jobs/644238927?utm_medium=notification_source=github_status

> Test Summary Report
> ---

> 95-test_external_boringssl.t (Wstat: 256 Tests: 1 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> 95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1



95-test_external_boringssl.t:
---

    grep 'go.*FAILED' t
    go test: FAILED (SSL3-Client-ClientAuth-RSA)
    go test: FAILED (SSL3-Server-ClientAuth-RSA)
    go test: FAILED (ClientAuth-Sign-RSA-SSL3)
    go test: FAILED (ClientAuth-InvalidSignature-RSA-SSL3)
    go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Sync)
    go test: FAILED 
(CertificateVerificationSucceed-Server-SSL3-Sync-SplitHandshakeRecords)
    go test: FAILED 
(CertificateVerificationSucceed-Server-SSL3-Sync-PackHandshakeFlight)
    go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Async)
    go test: FAILED 
(CertificateVerificationSucceed-Server-SSL3-Async-SplitHandshakeRecords)
    go test: FAILED 
(CertificateVerificationSucceed-Server-SSL3-Async-PackHandshakeFlight)



95-test_external_krb5.t:
---

    LD_LIBRARY_PATH=`echo -L../../../lib | sed -e "s/-L//g" -e "s/ /:/g"` 
KRB5_CONFIG=../../../config-files/krb5.conf LC_ALL=C ./t_nfold
    N-fold
    Input:    "basch"
    192-Fold: 1aab6b42 964b98b2 1f8cde2d 2448ba34 55d7862c 9731643f
    Input:    "eichin"
    192-Fold: 65696368 696e4b73 2b4b1b43 da1a5b99 5a58d2c6 d0d2dcca
    Input:    "sommerfeld"
    192-Fold: 2f7a9855 7c6ee4ab adf4e711 92dd442b d4ff5325 a5def75c
    Input:    "MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
    192-Fold: db3b0d8f 0b061e60 3282b308 a5084122 9ad798fa b9540c1b
    RFC tests:

    ...

    Generating random keyblock: . . . OK
    Creating opaque key from keyblock: . . . OK
    Encrypting (c): . . . Failed: Cannot allocate memory <===ALLOC FAILURE==
    Aborted (core dumped) 
<===CORE DUMPED==
    Makefile:684: recipe for target 'check-unix' failed
    make[5]: *** [check-unix] Error 134
    make[5]: Leaving directory 
'/home/travis/build/openssl/openssl/krb5/src/lib/crypto/crypto_tests'
    Makefile:1107: recipe for target 'check-recurse' failed
    make[4]: *** [check-recurse] Error 1
    make[4]: Leaving directory 
'/home/travis/build/openssl/openssl/krb5/src/lib/crypto'
    Makefile:992: recipe for target 'check-recurse' failed
    make[3]: *** [check-recurse] Error 1
    make[3]: Leaving directory '/home/travis/build/openssl/openssl/krb5/src/lib'
    Makefile:1533: recipe for target 'check-recurse' failed
    make[2]: *** [check-recurse] Error 1
    make[2]: Leaving directory '/home/travis/build/openssl/openssl/krb5/src'
    ../../util/shlib_wrap.sh ../recipes/95-test_external_krb5_data/krb5.sh => 2
    not ok 1 - running krb5 tests






Re: New Committer

2020-01-31 Thread Matthias St. Pierre

Congratulations, David! And welcome to the team!

Matthias


On 31.01.20 15:48, Matt Caswell wrote:

I'd like to announce that David von Oheimb has joined our team of
committers! David has been particularly active recently with the CMP
contribution - but also has numerous other PRs and commits to his name.

Welcome David!

Matt




RE: fips mode and key management

2020-01-21 Thread Dr. Matthias St. Pierre

> >distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
> more fitting than FIPS_MODE?
> 
> 
> Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use 
> OPENSSL_BUILDING_OPENSSL ...

OPENSSL_BUILDING_OPENSSL is really a remarkably long name.  I hope this does 
not blow up any commandline
length limits . How about using OSSL_LIBRARY library instead? This would fit 
nicely to OSSL_FIPS_PROVIDER:

#ifdef OSSL_LIBRARY
...
#endif

#ifdef OSSL_FIPS_PROVIDER
...
#endif

> There's no reason to use OSSL for internal macros.

But it avoids unnecessary name clashes with system headers. Just today, I saw 
this collision with Windows headers:

include/openssl/types.h:74:#  undef OCSP_REQUEST
include/openssl/types.h:75:#  undef OCSP_RESPONSE

(Yes I know, Window headers are really polluting the global namespace).




Re: fips mode and key management

2020-01-21 Thread Matthias St. Pierre



BTW: the following build time constant with the remarkably long name seems to 
be intended for
a related purpose,  but it is currently completely unused?

    Configurations/00-base-templates.conf:  lib_defines => [ 
'OPENSSL_BUILDING_OPENSSL' ],




Re: fips mode and key management

2020-01-21 Thread Matthias St. Pierre

On 21.01.20 10:36, Richard Levitte wrote:

I think that the misunderstanding lies in when FIPS_MODE is defined.


Reading this sentence it occurred to me that the misunderstanding comes from
the fact that the define is indeed misnamed. The term "FIPS mode" is a relict
from FIPS 2.0, where the OpenSSL 1.0.x library had an API to enable FIPS mode
*at runtime*.

(Note that the *compile time* option to include the FOM was called OPENSSL_FIPS,
not FIPS_MODE. So the misleading name must have crept in only recently.)


It's defined when the FIPS provider module is being built, never otherwise.


Exactly, in OpenSSL 3.0 the DEFAULT and the FIPS provider are partially built 
from
the same source files, which is the reason why we need a build time constant to
distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
more fitting than FIPS_MODE?


    #ifdef OSSL_FIPS_PROVIDER
    ...
    #endif


Matthias


P.S: Even though it is an internal define, it should have an OSSL_ prefix IMHO.
P.P.S: Optionally, one could also #define an OSSL_DEFAULT_PROVIDER, 
OSSL_LEGACY_PROVIDER, ...



RE: Build failures on master?!

2019-12-22 Thread Dr. Matthias St. Pierre
> With apologies for being a week behind on mail, but I didn't see any
> commits in the past week that look like they were targetted to fix external
> tests, and I see (E.g.)
> https://travis-ci.org/openssl/openssl/jobs/628003784?utm_medium=notification_source=github_status
> succeeding (as well as my local build with the krb5 tests).  Are the
> external tests still failing?

I don't really understand what's going on, but it looks like job 19 fails 
intermittently: Job #30814.19 (the one you 
pointet out) succeeded, but #30827.19 failed. And afterwards #30846.19 
succeeded again.

- #30814.19 (two days ago): SUCCEEDED
  
https://travis-ci.org/openssl/openssl/jobs/628003784?utm_medium=notification_source=github_status


- #30827.19 (23 hours ago): FAILED
  
https://travis-ci.org/openssl/openssl/jobs/628205488?utm_medium=notification_source=github_status

Test Summary Report
---
95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=3, Tests=3, 225 wallclock secs ( 0.67 usr  0.05 sys + 112.06 cusr 
29.38 csys = 142.16 CPU)
Result: FAIL
Makefile:2893: recipe for target '_tests' failed
make[1]: *** [_tests] Error 1
make[1]: Leaving directory '/home/travis/build/openssl/openssl'
Makefile:2891: recipe for target 'tests' failed
make: *** [tests] Error 2
** FAILED -- MAKE TEST

- #30846.19 (2 hours ago) SUCCEEDED
  
https://travis-ci.org/openssl/openssl/jobs/628466771?utm_medium=notification_source=github_status

There are other tests failing, too. If you look at the build history, you will 
hardly see any successful builds on
master and 1.1.1.

https://travis-ci.org/openssl/openssl/builds?utm_medium=notification_source=github_status


Matthias





AW: Build failures on master?!

2019-12-15 Thread Dr. Matthias St. Pierre
Gentle reminder: it's almost a month since a started this thread, but the 
external pyca and krb5 
tests are still failing. Apart from complicating the review process, it also 
happens that people
are noticing the failures and are hesitating to update to the current tip of 
master [1].

IMHO chronically failing tests should be deactivated and an issue created for 
fixing them.

Matthias

[1] https://github.com/openssl/openssl/issues/9866#issuecomment-565714221



AW: Flaw in our process for dealing with trivial changes

2019-12-12 Thread Dr. Matthias St. Pierre


> On Thu, 12 Dec 2019 22:31:10 +0100,
> Dr Paul Dale wrote:
> >
> > A red blocker along the lines of: "Triviality Unconfirmed". One of
> > the reviewers needs to remove this before the PR can be merged.
> >
> > It's in our face, it prevent accidental merges and its low overhead.
> 
> I still think simply adding the label should be sufficient.  I dunno
> about you, but I look at labels all the time, for all sorts of
> reasons, and one saying [cla: trivial] would certainly attract my
> attention.
> 
> Let's make it bright red-orange, that'll catch anyone's eye (even mine)
> 
> Also, removing that label will rapidly be annoying as soon as someone
> closes and re-opens a PR...  or whatever other action that triggers
> the "pull_request" event (and there's a lot that does that...  our
> script is being kept busy!).
> 
> Cheers,
> Richard


This seems to be implied already by my last proposal, with just one color 
changed:   ;-)

> Add three mutually exclusive [cla: *] labels:

>   [cla: ok] (green)
>   [cla: trivial]   (orange)
>   [cla: missing](red)
>
> The CLA bot  *always* sets the [cla: ok] label if it finds a  CLA on file. 
> Otherwise, it sets the
> [cla: missing] label, unless the [cla: trivial] label is already set.
>
> The [cla: trivial] label can only be set manually by a committer, and only 
> after the consent
> between contributor and both reviewers has been reached.



Re: Flaw in our process for dealing with trivial changes

2019-12-12 Thread Dr. Matthias St. Pierre
> > The server-side commit hook ensures that
> >
> > - the "CLA: trivial" annotation is present in *all* commits of the PR if 
> > and only if the [cla: trivial]
> >   label is set.
> > - the [cla: ok] label is set if and only if the CLA is on file
> > - the pull request is accepted only if the [cla: ok] or [cla: trivial] 
> > label is set
> 
> 
> One issue with this bit is that it requires the git hooks to connect to
> github to check the labels. AFAIK we don't do that at present. Does it
> add too much complexity to the hooks?

Actually, the consistency checks could be done entirely by the addrev script, 
which already uses the GitHub API.

addrev:
=

Ensure that

- the [cla: ok] label is set if and only if the CLA is on file
- the [cla: trivial] label is set if and only if the "CLA: trivial" annotation 
is present in *all* commits of the PR

git commit hook
=

Accept pull request if and only if the CLA is on file or *all* commits have the 
"CLA: trivial" annotation.


(The git commit hook would need only a minimal change, if it does not check 
*all* commits yet.)




AW: Flaw in our process for dealing with trivial changes

2019-12-12 Thread Dr. Matthias St. Pierre

> On 12/12/2019 09:43, Paul Yang wrote:
> > Would it be better if 'CLA: trivial’ is in the commit message but no CLA
> > on file, then a new label like ’warn: no CLA but trivial’ is added? This
> > can inform the committer who will merge the PR for the CLA condition of
> > the commits.
> >
> 
> Yes, I think that would be a really good idea. At least then its very
> visible what is happening.

Reusing Tim's words I'd like to argue that we should avoid rushing for a 
premature optimization.

- Just adding new labels does not solve anything, at least as long as those 
labels
  are not enforced automatically. (via GitHub bot & git hook)

- This is the first time in quite a while that a pull request with a 
questionable
  trivial CLA has slipped in and it is no problem to revert a commit if 
necessary.
  So I wouldn't consider it a significant problem. The best countermeasure IMHO
  is to adopt the habit of skimming over the last GitHub messages of the PR and
  to reread the final commit messages (after the "Reviewed-by:" annotations have
  been added) before pushing the final commit.


As for a possible semi-automated solution:

The problem is more fundamental: currently both the GitHub bot and the git 
commit hook
only watch out for the 'CLA: trivial' marker. But this marker is intended to be 
added
by the *contributor* himself, so it expresses only his opinion, not ours. Only 
if all three,
the contributor and the two reviewers agree, then the pull request can be 
considered
trivial.

One possible solution to this problem could be the following procedure: 

Add three mutually exclusive [cla: *] labels:

  [cla: ok] (green)
  [cla: trivial]   (green)
  [cla: missing](red)

The CLA bot  *always* sets the [cla: ok] label if it finds a  CLA on file. 
Otherwise, it sets the
[cla: missing] label, unless the [cla: trivial] label is already set.

The [cla: trivial] label can only be set manually by a committer, and only 
after the consent
between contributor and both reviewers has been reached.

The server-side commit hook ensures that

- the "CLA: trivial" annotation is present in *all* commits of the PR if and 
only if the [cla: trivial]
  label is set.
- the [cla: ok] label is set if and only if the CLA is on file
- the pull request is accepted only if the [cla: ok] or [cla: trivial] label is 
set


Matthias



Re: Check NULL pointers or not...

2019-11-29 Thread Matthias St. Pierre




On 29.11.19 11:29, Matthias St. Pierre wrote:



On 29.11.19 10:22, Matt Caswell wrote:


 if (!ossl_assert(ptr != NULL)) {
 ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
 return 0;
 }



I still dislike the odd way in which the assertion needs to be formulated,
with the double negation. With the `ossl_is_null()` macro, which I proposed
in #7218, the same condition would read

    if (ossl_is_null(ptr)) {
    ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
    return 0;
    }


Isn't that much better readable and easier to understand?


For more examples like that, see the change set

https://github.com/openssl/openssl/pull/7218/files


Matthias





Moreover, in the debug build you get the error message  "Invalid NULL pointer:" instead 
of a generic "Assertion Failed:"

https://github.com/openssl/openssl/pull/7218/files#diff-6e9d962dc8c30948fdf827ad471ec11dR41-R44





Re: Check NULL pointers or not...

2019-11-29 Thread Matthias St. Pierre




On 29.11.19 10:22, Matt Caswell wrote:


 if (!ossl_assert(ptr != NULL)) {
 ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
 return 0;
 }



I still dislike the odd way in which the assertion needs to be formulated,
with the double negation. With the `ossl_is_null()` macro, which I proposed
in #7218, the same condition would read

if (ossl_is_null(ptr)) {
ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}


Isn't that much better readable and easier to understand?


For more examples like that, see the change set

https://github.com/openssl/openssl/pull/7218/files


Matthias




AW: Build failures on master?!

2019-11-18 Thread Dr. Matthias St. Pierre
> > The last 19 commits on https://github.com/openssl/openssl/commits/master,
> > starting from Nov 14 have a red cross from the CIs. What's going on again?
> > My personal impression is that builds on master are failing 50% of the time.
> 
> The builds on master have been failing for *much* longer than that. They
> should be succeeded on the PRs, but its the extended tests that fail.

Yes I know. I was just counting the last consecutive failures. What actually 
wonders
me is the fact that the tests do not fail throughout. In between there are 
always short
periods where the tests succced. Why is this?

The reason why I issued this cry for help is because after watching it for a 
long time I
got the impression that due to the ongoing failures everybody has become dull 
and
indifferent agains the red crosses.

Matthias



Build failures on master?!

2019-11-18 Thread Dr. Matthias St. Pierre
The last 19 commits on https://github.com/openssl/openssl/commits/master,
starting from Nov 14 have a red cross from the CIs. What's going on again?
My personal impression is that builds on master are failing 50% of the time.

It is really tedious to check pull requests for build errors just to find that 
those errors
are well known failures from master. In particular, the krb5 an pyca tests are 
notoriously
failing. Are there any plans to fix them or disable them?

  95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1)
  95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1)

Clean builds on master should have highest priority. Because if there are too 
many red
crosses, nobody cares about them anymore.

Matthias




Re: #10388

2019-11-15 Thread Matthias St. Pierre




On 14.11.19 20:40, Viktor Dukhovni wrote:

On Nov 14, 2019, at 9:15 AM, Matt Caswell  wrote:

"No existing public interface can be removed until its replacement has
been in place in an LTS stable release. The original interface must also
have been documented as deprecated for at least 5 years. A public
interface is any function, structure or macro declared in a public
header file."

So the functions we're talking about don't yet have a replacement -
there will be one in 3.0. So presumably they will be documented as
deprecated in 3.0. So we have to support them for at least 5 years from
the release of 3.0.

I think that when we're deprecating an entire family of *related* accessors
(for the same structure) that have been in place for some time, the addition
of a missing member of that family is reasonably interpreted as not resetting
the support clock on the entire family.  We can still remove them all as though
the missing members of the family had been in place all along.

That is, we should (and if that requires a policy update and vote so be it) be
able to interpret the rules based on the "spirit" (intent) without getting
unduly burdened by the "letter", where common sense would suggest that we're
getting the intended outcome.


I don't think we need a reinterpretation, or even a change, of the existing 
policy for
this specific case,  since already now the *entire* engine api can only be 
deprecated
in version 3.0 and removed afterwards according to the policy cited by Matt.

We can simply add the missing accessor as bugfix to 1.1.1 and 3.0, and 
immediately
deprecate it on the latter. The only difference will be that we end up with n+1 
deprecated
functions instead of n  (for some natural number n) for version 3.0.

Even after 3.0 is released and as long as 1.1.1 LTS is still supported, we can 
proceed
in the same way without violating existing policies.


Matthias



Re: Re-requesting reviews on GitHub

2019-10-30 Thread Matthias St. Pierre




On 30.10.19 10:14, Richard Levitte wrote:

This is a good idea, and also a detectable event for a bot to listen to.


Sounds like an excellent idea: If approvals and dismissals of approvals
(resp. re-review requests) are all bot events, then the bot should be able
to handle most state changes automatically, including the determination
whether a normal or an omc review is required.  This would be a great
ease for the reviewer's workflow.

Matthias



AW: Re-requesting reviews on GitHub

2019-10-30 Thread Dr. Matthias St. Pierre
> Independently of the new 'approval: *' state labelling I was wondering 
> whether it wouldn't
> be a good idea to adopt the habit of explicitly requesting a re-review from 
> the other reviewers
> after significant changes, using the mechanism provided by GitHub (i.e. the 
> button with the two

To be more precise: not all reviews need to be invalidated by requesting a 
re-review, only the approvals.



Re-requesting reviews on GitHub

2019-10-30 Thread Dr. Matthias St. Pierre
Independently of the new 'approval: *' state labelling I was wondering whether 
it wouldn't
be a good idea to adopt the habit of explicitly requesting a re-review from the 
other reviewers
after significant changes, using the mechanism provided by GitHub (i.e. the 
button with the two
circling arrows next to the reviewer entry). In that way, outdated reviews 
would become more
visible, and outdated reviews wouldn't be addrev'ed to the commit message when 
merging,
unless they are renewed before the 24h grace period expires.  For nit changes, 
the current informal
way of re-approval could be kept of course.

What's your opinion?

Matthias




Triage of issues using the new labels

2019-10-29 Thread Matthias St. Pierre

Hi,

after some discussion with Matt, some new 'triaged:*' GitHub labels have been
added in addition to the 'issue: *' labels.

The idea is that the 'issue: *' labels are going to be added by the reporter
by choosing the corresponding GitHub issue template (there will be one
template for every issue type when #10051 is merged).

When we committers first look at the issue, we can decide of what type the issue
and add an appropriate 'triaged: *' label. This type can be different from what
the reporter chose, if we disagree with his opinion. When we add the 'triaged: 
*'
label, the 'issue: *' label should be removed (IMHO). In this way, we can 
distinguish
between untriaged and triaged tickets.

It would be great, if you all could look through the labelled issues in the next
days/weeks and help with the triage. Ideally, only new untriaged tickets should
carry one of the 'issue: *' labels.

    issue: bug report
https://github.com/openssl/openssl/labels/issue%3A%20bug%20report 


    issue: documentation
https://github.com/openssl/openssl/labels/issue%3A%20documentation 


    issue: feature request
https://github.com/openssl/openssl/labels/issue%3A%20feature%20request

    issue: question
https://github.com/openssl/openssl/labels/issue%3A%20question 



Regards,
Matthias



GitHub Milestones

2019-10-29 Thread Matthias St. Pierre

Since the reorganization of the labels is mostly complete (except for
automation), the next step could now be to clean up the old milestones.
But that's more a task for Matt and Richard.

https://github.com/openssl/openssl/milestones


Matthias




Re: AW: Confirmed bug labels

2019-10-29 Thread Matthias St. Pierre

I decided to change the 'issue: *' colors to a more 'yelling' cyan color
making the untriaged issues more prominent, and use the more
relaxed blue color for the 'triaged: *' labels instead.

Also added an 'unresolved' label.

Matthias


On 29.10.19 13:38, Matt Caswell wrote:


On 29/10/2019 12:37, Matthias St. Pierre wrote:

The 'unresolved: *' labels could carry the same grey color as the
'resolved: *' labels.
For the 'triaged: *' labels we need a new color. I can make a suggestion...

Please do!

Matt




Re: AW: Confirmed bug labels

2019-10-29 Thread Matthias St. Pierre




On 29.10.19 13:34, Matt Caswell wrote:



     ...

For the unresolved issues, an 'unresolved: *' label makes sense:

     "unresolved: "

Possible reasons for marking something as unresolved:

- The question is stale - no activity for a prolonged period
- Off topic - the question is about something not directly related to
OpenSSL
- Unable to help - despite our best efforts we weren't able to figure
out an answer
- Lack of information - we requested information and it wasn't forthcoming

Not sure if we would want a label for all of those or not.

Matt



Then I'll just add a simple 'unresolved' label without a reason and we can
extend labels if needed.



Re: AW: Confirmed bug labels

2019-10-29 Thread Matthias St. Pierre

The 'unresolved: *' labels could carry the same grey color as the 'resolved: *' 
labels.
For the 'triaged: *' labels we need a new color. I can make a suggestion...

Matthias



Re: AW: Confirmed bug labels

2019-10-29 Thread Matthias St. Pierre




On 29.10.19 13:14, Matt Caswell wrote:

Do we just need "triaged: bug" and "triaged: feature"? Or should we also
have "triaged: documentation" and "triaged: question" (so that there is
one for every corresponding "issue" label)?


Yes, that makes sense. Then it is assured that the 'issue: *' labels are
set only for issues which have not been triaged yet.

Note also that the 'triaged: bug', 'triaged: feature', and 'triaged: 
documentation'
labels also make sense for pull request, in particular w.r.t. the question 
whether
a pull request can be backported or not.



Bugs, features and documentation issues are resolved by
fixing/implementing them, or marking them with a resolved label. Should
we also have a "resolved: answered" label where we believe we have
answered a question? Possibly also one where there has been no answer,
but we're closing it because the question is stale?


It might be useful to add more reasons for why the issue is resolved.
OTOH we should watch out that we don't create too many labels.

    "resolved: fixed"
    "resolved: answered"
    ...

For the unresolved issues, an 'unresolved: *' label makes sense:

    "unresolved: "



I updated the "closed: *" labels to say "resolved: *" instead.

Ok, I already saw it :-)


Re: Confirmed bug labels

2019-10-29 Thread Matthias St. Pierre

We try to group the labels into categories using prefixes, see

https://github.com/openssl/openssl/labels 


and my initial post

https://mta.openssl.org/pipermail/openssl-project/2019-October/001593.html

Note that the 'issue: *' labels are automatically added by the GitHub issue 
templates,
because normal users don't have the permissions to add those labels.

Alternative proposals are welcome, but they need to fit into the new naming 
scheme.

Matthias


On 29.10.19 13:04, Salz, Rich wrote:

What about "proposed bug" "proposed feature" etc.  And a single "accepted" 
label?
  





Re: AW: Confirmed bug labels

2019-10-29 Thread Matthias St. Pierre

Our replies overlapped. 'resolved: *' is even better than 'triaged: *'.


On 29.10.19 12:57, Matthias St. Pierre wrote:

Another idea just occurred to me: we could join the 'closed: *' labels with the 
'triaged: *' labels:

    triaged: duplicate
    triaged: not a bug
    triaged: wont fix




Re: AW: Confirmed bug labels

2019-10-29 Thread Matthias St. Pierre

Another idea just occurred to me: we could join the 'closed: *' labels with the 
'triaged: *' labels:

    triaged: duplicate
    triaged: not a bug
    triaged: wont fix


On 29.10.19 12:53, Matthias St. Pierre wrote:



On 29.10.19 12:41, Matt Caswell wrote:


On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote:

A similar problem applies to 'issue: feature request'.  Just having a 
'confirmed' label for bugs
wouldn't help in that case.

So what do you think about adding a new 'triaged: *' family of labels, in 
addition to 'issue: *'?

'triaged: bug'
'triaged: feature'
etc.

If this seems too verbose, then we could just omit the triaged prefix:

'bug'
'feature'
etc.

Yes, this makes sense to me (and I prefer the more verbose versions).
Should we remove the reporter label once its been triaged? It would be
quite confusing if you had both the labels "issue: bug report" *and*
"triaged: feature" (in the cases where someone reports something as a
bug, but we see it as a feature request).


I agree with you that it should be removed.


BTW: That's a similar question than your recent question whether
'approval: done' should be removed when the 'ready to merge'
label is added. After sleeping a night over it, I would prefer if
the former were removed. If we would add the 'approval: ' prefix,
then it would be obvious why it makes sense:

    'approval: review pending'
    'approval: omc review pending'
    'approval: done'

    ... 24h grace period ...

    'approval: ready to merge'

The transition diagram would be much easier to remember, in particular
for the case when an approval needs to be revoked because some change
was added (or even force-pushed) after approval.




Another issue I encountered was with the "closed: *" labels. "closed"
doesn't quite seem right to me. Whether something is closed or open is
somewhat independent of the states that those labels convey. For example
we might want to label something as "not a bug" but leave it open for a
little while to allow the reporter to respond or argue why it really
should be treated as a bug. Similarly with "wont fix" and maybe even
"duplicate".


Actually the 'rejected: *' prefix would be the most appropriate. I just 
hesitated
because it sounded so unfriendly. If you have a more friendly proposal, I'd be
happy to hear about it. Otherwise I would just suggest to use it instead of
'closed: *'.


Matthias





Re: AW: Confirmed bug labels

2019-10-29 Thread Matthias St. Pierre




On 29.10.19 12:41, Matt Caswell wrote:


On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote:

A similar problem applies to 'issue: feature request'.  Just having a 
'confirmed' label for bugs
wouldn't help in that case.

So what do you think about adding a new 'triaged: *' family of labels, in 
addition to 'issue: *'?

'triaged: bug'
'triaged: feature'
etc.

If this seems too verbose, then we could just omit the triaged prefix:

'bug'
'feature'
etc.

Yes, this makes sense to me (and I prefer the more verbose versions).
Should we remove the reporter label once its been triaged? It would be
quite confusing if you had both the labels "issue: bug report" *and*
"triaged: feature" (in the cases where someone reports something as a
bug, but we see it as a feature request).


I agree with you that it should be removed.


BTW: That's a similar question than your recent question whether
'approval: done' should be removed when the 'ready to merge'
label is added. After sleeping a night over it, I would prefer if
the former were removed. If we would add the 'approval: ' prefix,
then it would be obvious why it makes sense:

    'approval: review pending'
    'approval: omc review pending'
    'approval: done'

    ... 24h grace period ...

    'approval: ready to merge'

The transition diagram would be much easier to remember, in particular
for the case when an approval needs to be revoked because some change
was added (or even force-pushed) after approval.




Another issue I encountered was with the "closed: *" labels. "closed"
doesn't quite seem right to me. Whether something is closed or open is
somewhat independent of the states that those labels convey. For example
we might want to label something as "not a bug" but leave it open for a
little while to allow the reporter to respond or argue why it really
should be treated as a bug. Similarly with "wont fix" and maybe even
"duplicate".


Actually the 'rejected: *' prefix would be the most appropriate. I just 
hesitated
because it sounded so unfriendly. If you have a more friendly proposal, I'd be
happy to hear about it. Otherwise I would just suggest to use it instead of
'closed: *'.


Matthias



  1   2   >