RE: Hacktoberfest

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

Assigning OpenSSL 3.0.0 beta1 issues

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

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

2020-10-10 Thread Dr. Matthias St. Pierre
+1 > -Original Message- > From: openssl-project On Behalf Of Mark > J Cox > Sent: Saturday, October 10, 2020 9:34 AM > To: openssl-project@openssl.org > Subject: Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released > > +1 > > On Fri, Oct 9, 2020 at 1:03 PM Tomas Mraz wrote: > >

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

2020-10-10 Thread Dr. Matthias St. Pierre
0 > -Original Message- > From: openssl-project On Behalf Of > Tomas Mraz > Sent: Friday, October 9, 2020 2:02 PM > To: openssl-project@openssl.org > Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for > 1.1.1

RE: VOTE: Technical Items still to be done

2020-10-08 Thread Dr. Matthias St. Pierre
+1 > -Original Message- > From: openssl-project On Behalf Of > Tomas Mraz > Sent: Thursday, October 8, 2020 6:21 PM > To: Matt Caswell ; openssl-project@openssl.org > Subject: Re: VOTE: Technical Items still to be done > > +1 > > On Thu, 2020-10-08 at 15:47 +0100, Matt Caswell wrote:

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

2020-10-08 Thread Dr. Matthias St. Pierre
+1 > -Original Message- > From: openssl-project On Behalf Of Matt > Caswell > Sent: Thursday, October 8, 2020 4:27 PM > To: openssl-project@openssl.org > Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality > > topic: We should accept the Fully Pluggable TLSv1.3 KEM

RE: Would this be interesting to the project?

2020-10-02 Thread Dr. Matthias St. Pierre
> Do you have ideas on how to properly set it up? Congratulations, Dmitry! You just won the price of being assigned the job to figure it out. ;-) Matthias From: openssl-project On Behalf Of Dmitry Belyavsky Sent: Friday, October 2, 2020 2:51 PM To: Dr Paul Dale Cc:

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

2020-09-30 Thread Dr. Matthias St. Pierre
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@open

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

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

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

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

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

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

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

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

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

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

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

RE: New GitHub label for release blockers

2020-09-13 Thread Dr. Matthias St. Pierre
/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 openss

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:

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,

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

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 >

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:

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

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

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

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

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

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

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

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

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

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.

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

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

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

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 >

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

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

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

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

RE: Release done

2020-03-17 Thread Dr. Matthias St. Pierre
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/N

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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*

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

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

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

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

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

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

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

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

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

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

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

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

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

AW: GitHub issue template for general questions

2019-09-01 Thread Dr. Matthias St. Pierre
mber 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

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

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

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

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

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

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:

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

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

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

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

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

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

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 >

  1   2   >