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




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: 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: Github PR label automation

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

> -Original Message-
> From: openssl-project  On Behalf Of Mark 
> J Cox
> Sent: Saturday, February 8, 2020 8:52 PM
> To: Dmitry Belyavsky 
> Cc: openssl-project@openssl.org
> Subject: Re: Github PR label automation
> 
> Thanks Dmitry; I hope that the comment triggers notifications to the
> creator without mentioning them?  (let me know if you get something
> changed labels that doesn't)   Mark

In fact, it was my suggestion *not* to add personal mentions. Since anybody who 
has posted 
comments to the pull request (which includes the submitter and all reviewers) 
will be subscribed
to the pull request's thread, I think a general comment which addresses nobody 
specific (just like
our "ping" messages) is less intrusive.

Matthias




RE: Github PR label automation

2020-02-08 Thread Dr. Matthias St. Pierre
First of all, thank you Mark for implementing the notification daemon. You did 
a great job
and I think it's very useful. Here are some comments and thoughts about your 
last mail.

>  No doubt we'll use some tool user for this in the future.

Can't you just use an API-token generated for the openssl-machine account,
as the issue closing bot does?

A propos bot: I thought that GitHub provides official support for this kind of 
watch-bots
we are seeking and that they can be configured or programmed in an event driven 
fashion.
Executing specific actions (like setting labels or posting messages) in 
response to specific
GitHub events (approval added, change requested, timer expired, etc.) would 
have some
advantages compared to an external timer based approach. Did someone of you 
consider
this option and do some investigations in that direction? Please don't 
misinterpret my
question, I think that the current cron job solution is already a great 
improvement and
a big step forward.

> 2 If there were comments made after "approval: done" then I think we
> really ought to drop the "approval: done" label as the comments likely
> invalidated the approval. ...

I don't think that an *arbitrary comment* should automatically reset the 
approval state.
Anybody could just post a "nice job" comment or some side note. Resetting the 
approval
state could happen automatically if a *team member* posts a review with *change 
requests*.
But not in any other case (e.g. a change requests by a non-team member or an 
additional
approving review).

Also, I am strongly convinced that making the transition from the [approval: * 
review pending]
to the [approval:done] state should remain a *purely manual* state. I don't 
think it's a good idea
to leave this decision to an "artificial intelligence" whatsoever. And just 
counting whether the
number of approvals has reached the required minimum is too simplistic anyway.

Just imagine the pull request has reached the required number of reviews, but 
the
submitter or a reviewer is still waiting for another important outstanding 
review.
Do you really want the bot to interfere?

What about the existing approvals? They need to be dismissed if 'too much' has 
changed,
but not if the author pushed a trivial fixup addressing an approving review. Do 
you really
want to leave this decision to a bot?

This approach will just not work.

It is really almost no extra effort if we demand that the second reviewer sets 
the
[approval: done] label manually, unless he sees that there are still unresolved 
discussions
in progress. Only the grace period handling should be automated IMHO.

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



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



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




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




AW: Confirmed bug labels

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

Matthias

> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von 
> Matt Caswell
> Gesendet: Dienstag, 29. Oktober 2019 10:23
> An: openssl-project@openssl.org
> Betreff: Confirmed bug labels
> 
> Do we need a "confirmed bug" or similar label? I was looking at #10283
> which is labelled with "issue: bug report". But this only tells us that
> the reporter thought it was a bug. I wanted to add a label confirming
> that it really is a bug...but nothing suitable seems to be there.
> 
> Matt


Re: New GitHub labels for pull request and issues - 24 hour grace period

2019-10-26 Thread Dr. Matthias St. Pierre
Note: names might still undergo some fine tuning. For example, 

[issue: missing documentation]

was just changed to 

[issue: documentation]

to encompass both missing documentation and errors in documentation.

Matthias


> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von Dr. 
> Matthias St. Pierre
> Gesendet: Samstag, 26. Oktober 2019 15:40
> An: openssl-project@openssl.org
> Betreff: New GitHub labels for pull request and issues - 24 hour grace period
> 
> Hi all,
> 
> some of you contributors might have already noticed that the labels which
> are attached to the GitHub pull requests and issues have changed.
> During the face to face meeting it was decided to cleanup some of the
> unused labels and to organize the labelling more systematically to match
> our review and merging process.
> 
> The following gives you a brief outline of the changes. Wordings are mine
> and not authoritative. An official policy update by the OMC will follow.
> 
> It was decided by the OMC that starting from now on all committers need
> to wait for a grace period of (currently) 24 hours after the approval of
> a pull request has completed (which happens when it has the necessary
> number of approvals) before they are allowed to merge the pull request
> to the target branch(es). The two different states are indicated by labels
> ([approval: done] and [ready to merge]). The 24 hour policy will be endorsed
> by a server side git hook and a github bot which which controls the
> [ready to merge] label. There are limited exceptional cases in which a
> committer can manually set the [ready to merge] label to merge earlier.
> (e.g. during the release process).
> 
> Below is a brief overview over the most important new labels. For a full list
> and for explaining comments, see
> 
> https://github.com/openssl/openssl/labels
> 
> Matthias
> 
> 
> --
> 
> 
> *Branch labels*
> 
> [branch: master]
> [branch: x.y.z]
> 
> Branch labels serve as indication of all target branches to
> which the pull request is going to be merged. Approval of
> reviewers applies to all target branches, provided the commits
> can be cherry-picked cleanly. If that's not the case, a separate
> pull request needs to be made.
> 
> If there is no branch label, then the github target branch of the
> pull request is assumed. However, in the future we try to be explicit
> by allways adding the target branch (e.g., [branch: master]).
> 
> 
> * Review progress labels*
> 
>   [approval: review pending]
>   [approval: omc review pending]
>   [approval: done]
> 
>   ...24 hour grace period...
>   [ready to merge]
> 
> 
> * Hold labels*
> 
> Those labels act as blockers and prevent a pull request from
> being merged.
> 
>   [hold: cla required]  (set by the cla bot, replaces [need-cla], WIP)
>   [hold: license clash]
>   [hold: need omc decision]
> 
> 
> * Issue type labels*
> 
> The following labels are going to be set automatically by the issue templates
> (see pull request https://github.com/openssl/openssl/pull/10266)
> Templates for the starred labels are still to be done.
> 
>   [issue: bug report]
>   [issue: feature request]
>   [issue: missing documentation] *
>   [issue: question] *


Correction: New GitHub labels for pull request and issues - 24 hour grace period

2019-10-26 Thread Dr. Matthias St. Pierre
One small error happened w.r.t. branch labels: they are

*Branch labels*

[branch: master]
[branch: x.y.z]



New GitHub labels for pull request and issues - 24 hour grace period

2019-10-26 Thread Dr. Matthias St. Pierre
Hi all,

some of you contributors might have already noticed that the labels which
are attached to the GitHub pull requests and issues have changed.
During the face to face meeting it was decided to cleanup some of the
unused labels and to organize the labelling more systematically to match
our review and merging process.

The following gives you a brief outline of the changes. Wordings are mine
and not authoritative. An official policy update by the OMC will follow.

It was decided by the OMC that starting from now on all committers need
to wait for a grace period of (currently) 24 hours after the approval of
a pull request has completed (which happens when it has the necessary
number of approvals) before they are allowed to merge the pull request
to the target branch(es). The two different states are indicated by labels
([approval: done] and [ready to merge]). The 24 hour policy will be endorsed
by a server side git hook and a github bot which which controls the
[ready to merge] label. There are limited exceptional cases in which a
committer can manually set the [ready to merge] label to merge earlier.
(e.g. during the release process).

Below is a brief overview over the most important new labels. For a full list
and for explaining comments, see

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

Matthias


--


*Branch labels*

[branch.x.y.z]

Branch labels serve as indication of all target branches to
which the pull request is going to be merged. Approval of
reviewers applies to all target branches, provided the commits
can be cherry-picked cleanly. If that's not the case, a separate
pull request needs to be made.

If there is no branch label, then the github target branch of the
pull request is assumed. However, in the future we try to be explicit
by allways adding the target branch (e.g., [branch: master]).


* Review progress labels*

[approval: review pending]
[approval: omc review pending]
[approval: done]

...24 hour grace period...
[ready to merge]


* Hold labels*

Those labels act as blockers and prevent a pull request from
being merged.

[hold: cla required]  (set by the cla bot, replaces [need-cla], WIP)
[hold: license clash]
[hold: need omc decision]


* Issue type labels*

The following labels are going to be set automatically by the issue templates
(see pull request https://github.com/openssl/openssl/pull/10266)
Templates for the starred labels are still to be done.

[issue: bug report]
[issue: feature request]
[issue: missing documentation] * 
[issue: question] *


Commit access to openssl/tools and openssl/web

2019-10-04 Thread Dr. Matthias St. Pierre
Dear OMC,

while the process of merging and committing to openssl/openssl has been 
formalized,
no similar (official) rules for pull requests by non-OMC-member seem to apply 
to the
other two repositories openssl/tools and openssl/web. Probably it's because 
hardly
anybody outside the OMC else ever raises them? Or is it the other way around?

I would like to raise the question whether it wouldn't be beneficial for all of 
us,
if we would apply the same rules (commit access for all committers, plus the 
well
known approval rules) to all of our repos. After all, the openssl/openssl 
repository
is the most valuable of the three and I see no reason why the others would need
more protection. In the case of the openssl/web repository which targets the
official website, you might want to consider a 2OMC approval rule, but even 
there
I don't see why the usual OMC veto rule wouldn't be sufficient.

Regards,
Matthias



Build failures on master

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

since my last commit on master did not build successfully, I checked the CIs.
It turned out that a lot of tests are failing, and they have been for quite a 
while now.

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

Apart from the well known trio boringssl, krb5, and pyca, there are some new 
failing tests.
It would be nice if we could put some effort into fixing them in order to get 
back to having
stable successful builds on master again. The build failures on master also 
affect the
pull request CI builds and if the failure persists, people stop checking their 
red crosses.

Matthias


--

https://travis-ci.org/openssl/openssl/jobs/590874663

80-test_ssl_old.t(Wstat: 256 Tests: 6 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1


https://travis-ci.org/openssl/openssl/jobs/590874664

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_pyca.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1

https://travis-ci.org/openssl/openssl/jobs/590874669

Test Summary Report
---
30-test_evp.t(Wstat: 256 Tests: 19 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
30-test_evp_fetch_prov.t (Wstat: 5376 Tests: 34 Failed: 21)
  Failed tests:  1, 9-18, 25-34
  Non-zero exit status: 21

https://travis-ci.org/openssl/openssl/jobs/590874670

Test Summary Report
---
30-test_evp.t(Wstat: 256 Tests: 19 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
30-test_evp_fetch_prov.t (Wstat: 5376 Tests: 34 Failed: 21)
  Failed tests:  1, 9-18, 25-34
  Non-zero exit status: 21


AW: Reorganization of the header files (GitHub #9333)

2019-09-28 Thread Dr. Matthias St. Pierre
It's merged to master. If you encounter merge problems while rebasing,
please consult

https://github.com/openssl/openssl/pull/9333#issuecomment-536105158

Matthias



AW: Reorganization of the header files (GitHub #9333)

2019-09-28 Thread Dr. Matthias St. Pierre
> Go for it, the antipodean contingent aren’t busy this weekend.

Ok, since I have green light from three OMC members now, I think
there is no need to wait until tomorrow. I'll merge later this evening.

Matthias




AW: Reorganization of the header files (GitHub #9333)

2019-09-28 Thread Dr. Matthias St. Pierre
> Merge early is pretty much my default position ... and that applies to this 
> context in my view.

Thank you Tim for your quick and  clear consent.

Meanwhile, pull request #9333 and its counterpart #9681 for the 1.1.1 stable
branch have been approved by Richard. Unless I hear any protest until Sunday
afternoon (CEST), I would like to merge in the evening, just in time before the
Australian plumbers start their weekly shift again.

Matthias


Reorganization of the header files (GitHub #9333)

2019-09-27 Thread Dr. Matthias St. Pierre
Hi,

some of you might have loosely followed pull request #9333 (see [1]),
where I am reorganizing the header files in a more consistent manner.

Since I intend to do the reorganization both to master and the 1.1.1
stable branch (in order to facilitate conflict-free cherry-picking to 
the 1.1.1 LTS branch), I decided to automate the changes. This decision
turned out to be very convenient, because the heavy rearchitecturing on
master frequently conflicted with my changes. Instead of resolving
conflicts, I could just rerun the script after rebasing.

When this pull request finally gets merged, it might happen that you
in turn encounter more merge conflicts as usual, in particular if you
are one of the 'replumbers' involved in the FIPS rearchitecturing.
It might also happen if you are working on some long running pull
request like the CMP integration.

To check the impact of my changes on your work, I did some rebasing
experiments, and as a result I wrote down some guidance about possible
rebasing strategies in [2].

The reason I write this mail is because I'd like to hear your opinion
about how to proceed with this pull request. There are two possibilities:

Variant I):
Merge early in to get the reorganization integrated as soon
as possible and not wait until shortly before the next release.

Variant II):
Wait a little bit more until the heavy rearchitecturing
has settled down a little bit.

What is your opinion? What are your preferences?


Regards,

Matthias


[1] https://github.com/openssl/openssl/pull/9333
[2] https://github.com/openssl/openssl/pull/9333#issuecomment-536105158


AW: Being socially aware

2019-09-17 Thread Dr. Matthias St. Pierre
> I agree, this shouldn’t have been a “good first issue”.

You might be right, but in hindsight it’s always easier to judge. In advance it 
was not at all
obvious to me at all that this pull request would be discussed so 
controversially.

For me, the task had all properties which in my view make it a good first issue:

- There was an issue report about a missing feature
   https://github.com/openssl/openssl/issues/9880

- The task was straight forward and had the right size.
   Also, there was a precedence in the code.

So instead of rushing towards an own solution, I took the time to describe an 
outline
of a possible implementation, because I like the idea behind the [good first 
issue] tag,
which is to lower the bar for new contributors.

Personally, I don’t think that a lively discussion is discouraging per se. 
Discussing about
solutions and convincing others is an important aspect of open source 
development,
which one can start learning from the very first pull request.

Criticism is only harmful if it is carried out with a negative attitude. But 
recalling my
own experience as a beginner, I can say that this was never the case. I always
experienced the OpenSSL community as very positive and welcoming to newcomers,
and feedback was always constructive.

Matthias


AW: Being socially aware

2019-09-17 Thread Dr. Matthias St. Pierre
I appreciate your concerns Richard, but I believe they are unwarranted in this
case fortunately.

First, my impression is that the discussion between was objective all the time
and far from being heated up with emotions.

Second, looking at the profile of the contributor, one can assert that he might
be relatively new to our project, but he is certainly experienced in Open Source
development. So I wouldn't worry too much about his feelings 

Regards,
Matthias



AW: GitHub issue template for general questions

2019-09-01 Thread Dr. Matthias St. Pierre
Ok, I'll try to come up with an issue template which manages the balancing act
of facilitating questions on GitHub while still recommending the openssl-users
mailing list for normal user questions.

> -Ursprüngliche Nachricht-
> Von: Richard Levitte 
> Gesendet: Sonntag, 1. September 2019 16:52
> An: Dr. Matthias St. Pierre 
> Cc: openssl-project@openssl.org
> Betreff: Re: GitHub issue template for general questions
> 
> I don't remember why the generic template was made so small...  So I
> think I would welcome a PR that does what you describe.
> 
> Cheers,
> Richard



GitHub issue template for general questions

2019-09-01 Thread Dr. Matthias St. Pierre
Hi,

I noticed that a lot of issues on GitHub containing general questions get 
tagged as a [bug],
because the template list only gives the choice between two options, a *Bug 
Report* and
a *Feature request*. (There is a third choice in tiny letters, which usually 
gets overlooked.)
A recent example is https://github.com/openssl/openssl/issues/9743.

For that reason, I would like to suggest adding a third template, which creates 
issues tagged
as  [question]:

  *Bug report*
Report a defect in the software
  *Feature request*
Propose a feature you would like to see added in the software
  *Question*
Ask a general question about the software

I am aware that this third category was probably omitted on purpose, because we 
would rather
see those questions asked on the openssl-users mailing list, but the practice 
shows that user
interaction on the mailing lists is fading and more and more user questions are 
being asked on
GitHub. What do you think about the suggestion?

Matthias







AW: Cleaning up include file inconsistencies

2019-07-09 Thread Dr. Matthias St. Pierre
FYI, I opened pull request #9333 on GitHub today, which demonstrates some of 
the ideas which I discussed in this thread.

https://github.com/openssl/openssl/pull/9333

Looking forward to your feedback.

Matthias




 


Re: Cleaning up include file inconsistencies

2019-07-07 Thread Dr. Matthias St. Pierre
I am beginning to  wonder whether it is a good idea to make the fact
whether a private header file contains exported symbols as selection
criterion for where the header file needs to go in the source tree:

> >  - headers in `include/internal`
> 
> For internal things that we want to make available for both libcrypto
> and libssl (i.e. they are exported in libcrypto.so)
> 
> >  - headers in `crypto/include/internal`
> 
> For internal things that we only want available inside libcrypto
> (i.e. they are NOT exported in libcrypto.so)

If you take a look at commit d5e5e2ffafc7 (Move digests to providers)
then you will notice that the `sm3.h` header file was moved:

~/src/openssl$ git show --stat d5e5e2ffafc7 | grep sm3.h
{crypto/include => include}/internal/sm3.h |   7 +-

So it seems like whenever the first symbol of a libcrypto-only private header 
file
needs to be exported then we also have to move the entire header file?
This is tedious and also doesn't really make sense. Because now the files sm2.h
and sm3.h happen to be in two different directories:

crypto/include/internal/sm2.h
include/internal/sm3.h

To be precise: that's only in master, because in 1.1.1 they are still in the 
same directory.
(That's how I noticed it in the first place, because I compared source trees.)

My suggestion instead would be to store all internal header files which are 
shared by
more than one sub-system either in

include/internal/crypto  ( #include "crypto/filename.h")
include/internal/ssl ( #include "ssl/filename.h")

depending on where the code is *implemented*, not where it is *used*.
The directory `include/internal` itself should not contain any include files.

Whether an internal libcrypto function can be used in libssl should depend only
on libcrypto.num and nothing else.


Matthias





AW: Cleaning up include file inconsistencies

2019-07-06 Thread Dr. Matthias St. Pierre
 A good idea just occurred to me. I will rework #9274 and create two
new pull requests from it:

- PR 1:  restructure the internal headers and fix the internal include guards.
- PR 2:  fix the include guards for the public header files

PR 1 could be backported to 1.1.1 which would be advantageous for 
cherry-picking.
That's important IMHO because 1.1.1 is an LTS release.

PR 2 would only go to master.

What do you think about it?

Matthias




AW: Cleaning up include file inconsistencies

2019-07-06 Thread Dr. Matthias St. Pierre
> > > That, to me, is much clearer than the "_int" suffix.
> >
> > This sounds like an excellent idea to me.
> 
> "Someone" should create a PR...

I wouldn't mind doing it alongside the other changes in #9274,
but I'd prefer my alternative proposal, which I just posted before.
That is, if you agree of course.

If you insist on doing it as a separate PR, I don't mind. But it does
not make sense to start on it before #9274 has been accepted and
merged.

Matthias
 


AW: Cleaning up include file inconsistencies

2019-07-06 Thread Dr. Matthias St. Pierre
 
> > Me, I'm wondering if it wouldn't be clearer if we renamed
> > crypto/include/internal -> crypto/include/crypto, and thereby did
> > this:
> >
> > #include "crypto/evp.h"
> >
> > That, to me, is much clearer than the "_int" suffix.
> 
> This sounds like an excellent idea to me.

Wouldn't it even be better to move 

   `crypto/include/internal`  to  `include/internal/crypto`

and include it as

#include "internal/crypto/evp.h"

this would have the advantage that _all_ shared include files can
be found in the `include` folder, the public ones inside `include/openssl`
and the internal ones in `include/internal`. Also, it would be a very consistent
structure and easy to remember.

#include "internal/foo.h"  /* shared between libcrypto and 
libssl */
#include "internal/crypto/bar.h" /* shared by libcrypto modules only */
#include "internal/ssl/bar.h"/* shared by libssl modules only */

   ... and so on: ...
   #include "internal/engines/baz.h"   /* shared by engine modules */

Matthias





Re: Cleaning up include file inconsistencies

2019-07-06 Thread Dr. Matthias St. Pierre
> > ./crypto/include/internal/store.h
> > ./crypto/include/internal/store_int.h
> ...
> 
> I have *no* idea why there are two header files.  I must have
> forgotten about one of them when creating the other...
> 
> They should be merged into one.

Ok, I can take care of it.

Matthias



Re: Cleaning up include file inconsistencies

2019-07-06 Thread Dr. Matthias St. Pierre
> For things that are private to that sub-system (sorry, "package" doesn't 
> sound right)

Neither does it to me, apologies. I was looking for the right word, but nothing 
except
"package" came to my mind. And I was too lazy to search for it in the docs.

> Me, I'm wondering if it wouldn't be clearer if we renamed
> crypto/include/internal -> crypto/include/crypto, and thereby did
> this:
> 
> #include "crypto/evp.h"
> 
> That, to me, is much clearer than the "_int" suffix.

This sounds like an excellent idea to me.

Matthias



AW: Cleaning up include file inconsistencies

2019-07-06 Thread Dr. Matthias St. Pierre
> Having such a finegrained distinction is not the problem, but (at least to me)
> it is not entirely clear which include file goes into which directory.

Note: the high score seems to lie at four different header files for the same 
package,
not counting the generated error header file:

~/src/openssl$ find -name 'store*.h'

./crypto/store/store_locl.h
./crypto/include/internal/store.h
./crypto/include/internal/store_int.h
./include/openssl/store.h
./include/openssl/storeerr.h

Matthias 


Cleaning up include file inconsistencies

2019-07-06 Thread Dr. Matthias St. Pierre
Hi all,

pull request #9274 started out as a task to clean up inconsistencies in the 
naming
of the include guards. It turned out that there are also some inconsistencies 
in the
naming of the include files.

Please take a look at the general discussion starting at
https://github.com/openssl/openssl/pull/9274#issuecomment-508824668
between Bernd and me.

In particular, in
https://github.com/openssl/openssl/pull/9274#issuecomment-508826903 and
following the question was raised whether all local `*_lcl.h` files should be 
renamed
to `*_locl.h` for consistency reasons, and the pros and cons discussed. 
The latter choice was suggested by a source tree vote:

   ~/src/openssl$ find -name '*_lcl.h' | wc -l
   19
~/src/openssl$ find -name '*_locl.h' | wc -l
30

What's your opinion about renaming of those files?

Matthias



AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Dr. Matthias St. Pierre
> The reason I think nothing will change is that the problem is
> already solved, use getentropy()/getrandom(). 

I agree completely.

> The init system would
> need to create this kind of service, and then all software not using
> getentropy()/getrandom() would need to depend on that service. It

FWIW: systemd already has a service for saving and restoring a random seed.
If I understood Tomas correctly, the saved seed is added to the random pool,
but without crediting any entropy to it (which sounds reasonable to me).

https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html


Matthias




AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Dr. Matthias St. Pierre
> Introducing DEVRANDOM_WAIT didn't cause any change for us, because
> we use getentropy(), and a recent kernel. But even systems that
> use getentropy() with an older kernel can have a large delay after
> boot.

Yes, but that's the crucial difference IMHO: while getentropy() on blocks once
during the early boot phase until its initial seeding completes, the 
DEVRANDOM_WAIT
approach will block several times, depending on how much the other processes 
drain
the /dev/random device.

Matthias


> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von 
> Kurt Roeckx
> Gesendet: Freitag, 7. Juni 2019 19:52
> An: Tomas Mraz 
> Cc: openssl-project@openssl.org
> Betreff: Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
> 
> On Fri, Jun 07, 2019 at 10:18:32AM +0200, Tomas Mraz wrote:
> >
> > From the point of view of distribution maintainer of OpenSSL I would
> > say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had
> > no real problems for us.
> 
> Introducing DEVRANDOM_WAIT didn't cause any change for us, because
> we use getentropy(), and a recent kernel. But even systems that
> use getentropy() with an older kernel can have a large delay after
> boot.
> 
> 
> Kurt



AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Dr. Matthias St. Pierre
Matt and Richard, I think you are mixing up cherry-picking and nit-picking 
here. (Sorry for the pun ;-)

Matthias

> To be picky, may I assume that you meant a reviewed-by tag for you
> > should be *added*?  The commit itself (its contents) having been
> > reviewed by those already there, I cannot see a reason why they should
> > be removed.
> 
> You approved for master but did not approve for 1.1.1. This commit was merged 
> to
> 1.1.1 and so strictly speaking was not approved by you for that branch.
> Therefore you should have been removed, and I should have been added.
> 
> Matt



AW: proposed change to committers policy

2019-05-24 Thread Dr. Matthias St. Pierre


> > IMHO an important clarification needs to be made: The rule should not be 
> > about
> > _prohibiting_ double approvals. It should only be about _counting_ them.
> > I would not deprive people of the right to state their opinions.
> 
> Isn't that an implementation detail?

You're right, it should be. But current discussions and current practice show 
that Pauli
avoids to approve on GitHub when Shane is involved and vice versa. IMHO it 
should
be valid to approve (and also recorded in the commit message), even if the vote 
is not
counted. Because it documents that both have reviewed the code.

Matthias



AW: No two reviewers from same company

2019-05-23 Thread Dr. Matthias St. Pierre
> No such decision has been made as far as I know although it has been discussed
> at various times.
> 
> > Should this policy be extended to OpenSSL’s fellows?
> 
> IMO, no.

I agree with Matt: While this policy makes sense for employers of third party 
companies,
because these companies might have conflicting interests in theory, It's a 
different case
for OpenSSL fellows. In my opinion, such a rule would only block Matt's and 
Richard's
daily work unnecessarily. Also, I see no danger of misuse, because the OMC 
members
still have the possibility to block a merge with their veto.

Matthias



AW: Issues and pull requests are largely getting ignored

2019-03-26 Thread Dr. Matthias St. Pierre
> > Hello OpenSSL Team,
> >
> > The issues and pull requests on github are largely getting ignored, I
> > know the team is busy on the new release but please spend some time on
> > these as well.

And I forgot to say: you are right, thanks for the polite reminder :-)



AW: Issues and pull requests are largely getting ignored

2019-03-26 Thread Dr. Matthias St. Pierre
Hi Matthew,

please feel free to post the single word "ping" to the pull requests for which 
you would like to regain attention.
These reminders are welcome (if they are not abused too much :-) ). 

Regards,
Matthias


> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von 
> Matthew Lindner
> Gesendet: Montag, 25. März 2019 21:11
> An: openssl-project@openssl.org
> Betreff: Issues and pull requests are largely getting ignored
> 
> Hello OpenSSL Team,
> 
> The issues and pull requests on github are largely getting ignored, I
> know the team is busy on the new release but please spend some time on
> these as well.
> 
> Thank you,
> Matthew Lindner


Re: [openssl-project] Release scheduling

2018-11-14 Thread Dr. Matthias St. Pierre
+1, in particular for doing a triple release: the 1.0.2 branch has accumulated 
a lot of substantial bugfixes.

(Personally, I am waiting on behalf of my company for Nicola's fix for the 
crash in FIPS mode
https://github.com/openssl/openssl/commit/fff1da43be2236995cdf5ef2f3e2a51be232ba85)

Matthias



> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von 
> Richard Levitte
> Gesendet: Mittwoch, 14. November 2018 14:43
> An: openssl-project@openssl.org
> Betreff: Re: [openssl-project] Release scheduling
> 
> Only one thought: +1
> 
> Matt Caswell  skrev: (14 november 2018 14:27:17 CET)
> >There are now no open PRs/issues with the 1.1.1a milestone so I think
> >we should
> >go ahead and do a release. The question is when? I propose next Tuesday
> >(20th),
> >with releases of 1.1.0 and 1.0.2 on the same day. It's been a while
> >since they
> >last had releases so I think its worthwhile doing them at the same
> >time.
> >
> >Thoughts?
> >
> >Matt
> >___
> >openssl-project mailing list
> >openssl-project@openssl.org
> >https://mta.openssl.org/mailman/listinfo/openssl-project
> 
> --
> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] 1.1.1a milestone status

2018-11-08 Thread Dr. Matthias St. Pierre
I'll merge 7462 and 7437 later today.

Matthias

FYI: there is a direct link to the milestone
https://github.com/openssl/openssl/milestone/13

> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von 
> Matt Caswell
> Gesendet: Donnerstag, 8. November 2018 14:22
> An: openssl-project@openssl.org
> Betreff: [openssl-project] 1.1.1a milestone status
> 
> There are currently 5 PRs and 1 issue with the 1.1.1a milestone set
> against them.
> 
> Of the 5 PRs, 3 are in the ready state:
> 
> 7462: Test: link drbgtest statically against libcrypto
> 7437: rand_unix.c: open random devices on first use only
> 7391: Unbreak SECLEVEL 3 regression causing it to not accept any ciphers.
> 
> 2 PRs are still in review:
> 7442: Don't negotiate TLSv1.3 if our EC cert isn't TLSv1.3 capable
> 7503: Separate ca_names handling for client and server
> 
> The one 1.1.1a issue (7419) will be closed as soon as 7437 gets pushed.
> 
> It would be great if we could get the 3 PRs that are ready pushed, and
> the other 2 reviewed in the next day or two to enable us to do a release
> soon.
> 
> Matt
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Random devices in chroot environments revisited

2018-10-30 Thread Dr. Matthias St. Pierre


> > ... currently there are two alternative approaches for doing it:
> >
> > #7429 - Conditionally open random devices on initialization
> > #7437 - rand_unix.c: open random devices on first use only
> > ...
> > *  Pull request #7429 fixes the opt-out issue but remains along the lines of
> > the initial solution #7432. ...
> >
> > *  Pull request #7429 works without explicit opt-out, because it opens the
> > random devices on first use only ...
> 
> #7437 I guess

Yes, thanks for the correction. A typical copy error. 

Matthias

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] Random devices in chroot environments revisited

2018-10-30 Thread Dr. Matthias St. Pierre
Hi,

I'd like to recall that the following issue

#7419 - RAND_keep_random_devices_open not working

still needs to be fixed until 1.1.1a and that currently there are two
alternative approaches for doing it:

#7429 - Conditionally open random devices on initialization
#7437 - rand_unix.c: open random devices on first use only 

A short recall of the background story: In pull request

#6432 - Keep /dev/random open for seeding

a regression was fixed that affected applications in chroot environments.
It compensated the fact that the new OpenSSL CSPRNG now reseeds
periodically, which the previous one didn't.

The solution was to open all random devices early and keep them
open.  An API call (RAND_keep_random_devices_open()) was added
for the application to opt-out from this behaviour.

In issue #7419 it was reported that this opt-out did not work as expected.

*  Pull request #7429 fixes the opt-out issue but remains along the lines of
the initial solution #7432. This approach has the side effect that the
random devices are always opened, even if they are never used
(for example, because getrandom() is available). Even more, if the
application forks and execs, these handles will be left open and unused
in the child process.

An application which does not want this behavior, could explicitly opt-out,
but this would require a recompilation, which is somewhat contrary to
the assumptions of the initial chroot problem.

*  Pull request #7429 works without explicit opt-out, because it opens the
random devices on first use only (and then keeps them open, unless
the opt-out was called). The advantage of this approach: If getrandom()
is available and working, the opening will never happen.

The lazy opening does not add a regression for applications compiled
against 1.1.0, because the old SSLEAY CSPRNG used to be initialized 
on first use, too. So also with 1.1.0 it was necessary to initialize the
CSPRNG properly before chrooting (unless the random device was
mounted into the chroot jail).

Your thoughts?

Matthias

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] NEW: A proposal for an updated OpenSSL version scheme (v3.0-dev)

2018-09-24 Thread Dr. Matthias St. Pierre


> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von 
> Richard Levitte
> Gesendet: Montag, 24. September 2018 17:41
> An: openssl-project@openssl.org
> Betreff: [openssl-project] NEW: A proposal for an updated OpenSSL version 
> scheme (v3.0-dev)
> 
> Following the discussion that we had on the previous documents and on
> all the input I got, I created a new version (v3.0-dev) for this proposal:
> 
> https://docs.google.com/document/d/1p6l7VYn176JKzOtERdp9OG0HcyhnJZnVdRLD07L_1wE/
> 
> It's written from the point of view that the comment in opensslv.h and
> the documentation in OPENSSL_VERSION_NUMBER.pod are correct as to what
> the components in the version number are, and that we simply didn't do
> as the docs said since 1.0.0.  So the idea is to simply reset, and
> then synthesize the value of existing macros (especially
> OPENSSL_VERSION_NUMBER) to be safe to use as we have observed that
> users do.

I'm not sure about the implication of the new document v3 on the two proposals 
from document v2.
Does it mean you dropped your own proposal in favour of Tim's proposal? Or will 
there be two competing
proposals, each described in its own document?

Matthias

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


  1   2   >