Re: [openssl-project] build/test before merging

2018-05-24 Thread Dr. Matthias St. Pierre
Well, I use --fixup and --squash mostly nowadays, but I'm not sure everybody switched. It was not a feature request, only a remark. -Ursprüngliche Nachricht- Von: openssl-project Im Auftrag von Richard Levitte Gesendet: Donnerstag, 24. Mai 2018

Re: [openssl-project] build/test before merging

2018-05-23 Thread Dr. Matthias St. Pierre
> +1 for python! :) Well, if this is a "go for it"... ;-) Oh, and I forgot to mention 'ghtool cherry-pick {110,102}' ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] build/test before merging

2018-05-23 Thread Dr. Matthias St. Pierre
> But I am curious if we currently do and/or should have a commit hook on > git.openssl.org to reject commits that start with "!fixup". We probably don't, but it's a good idea to have it. Matthias ___ openssl-project mailing list

Re: [openssl-project] Creating the OpenSSL_1_1_1-stable branch

2018-06-23 Thread Dr. Matthias St. Pierre
> We the OMC figured that all work will go towards making as good a release as > possible, everything else will be left in feature branches anyway. This means > that effectively, OpenSSL_1_1_1-stable and master remain the same, i.e. won't > start diverging before the final release. > That makes

Re: [openssl-project] GitHub labels

2018-06-20 Thread Dr. Matthias St. Pierre
There are a lot of things that come to my mind when I see all those labels: IMHO there are too many of them and for some of them the precise meaning is not clear. So maybe we should reduce their number a bit and document the meaning and semantics of the other. I) NAMING CONVENTIONS First of

Re: [openssl-project] GitHub labels

2018-06-20 Thread Dr. Matthias St. Pierre
> Matthias.St.Pierre> A propos: it might be useful to split the 'pending > Matthias.St.Pierre> 2nd review' into two different labels (of the same color): > Matthias.St.Pierre> > Matthias.St.Pierre> 'pending 2nd review'  ->  'review-required'  > and > 'omc-review-required' > > I'm

Re: [openssl-project] GitHub labels

2018-06-20 Thread Dr. Matthias St. Pierre
> Matthias.St.Pierre> The github search index allows to search for > 'base:' which is a much Matthias.St.Pierre> more reliable way of > determining the target branch: > > I'm learning something new, I had no clue of the 'base:' feature. Me neither, until today ;-). I looked it up on a useful

Re: [openssl-project] Local kid does good

2018-01-30 Thread Dr. Matthias St. Pierre
Wow! Congratulations, Ben! Am 30.01.2018 um 17:13 schrieb Salz, Rich: > > One of our own, Ben Kaduk, was just picked to be the Security Area > co-Director in the IETF! > > > ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] New Committer

2018-02-01 Thread Dr. Matthias St. Pierre
Congratulations and welcome, David! Matthias P.S: Good choice, OMC! Am 01.02.2018 um 09:31 schrieb Matt Caswell: > Please welcome our newest committer David Benjamin! > > Matt > ___ > openssl-project mailing list > openssl-project@openssl.org >

Re: [openssl-project] Style guide update -- summary so far

2018-02-05 Thread Dr. Matthias St. Pierre
Am 05.02.2018 um 19:13 schrieb Salz, Rich: > > > Do not put a size after sizeof; do use parens. > nit: Do not put a /space /after sizeof. > > > Treat a single-statement with comment as if it were multi-line and use > curly braces > > > > if (test()) { > >

Re: [openssl-project] Alpha release coverage on The Register

2018-02-14 Thread Dr. Matthias St. Pierre
Am 14.02.2018 um 23:28 schrieb Tim Hudson: > http://www.theregister.co.uk/2018/02/14/openssl_1_1_1_alpha_adds_tls_1_3_support/ > > > Note that the headline "Shambling corpse of ancient, shoddy, buggy, > crypto shoved towards the grave" is referring to TLS protocol versions > not to OpenSSL (at

Re: [openssl-project] Is this still relevant to OpenSSL?

2018-08-22 Thread Dr. Matthias St. Pierre
> https://eprint.iacr.org/2018/749 Side note: I like the reference to Jane Austen in the paper's title: > Prime and Prejudice: Primality Testing Under Adversarial Conditions Matthias ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

2018-09-09 Thread Dr. Matthias St. Pierre
I am currently occupied with other things, so I won't be able to look at it before later this evening or tomorrow. I also had a quick look at CID 1423323 (see below) but I was unable to see why 'pkey' would be a NULL pointer when passed to 'EVP_PKEY_up_ref'. So I'm not sure yet whether this is

Re: [openssl-project] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

2018-09-09 Thread Dr. Matthias St. Pierre
preliminary status report: *** CID 1439138: Integer handling issues (NEGATIVE_RETURNS) see https://github.com/openssl/openssl/pull/7156 *** CID 1439137: Integer handling issues (NEGATIVE_RETURNS) work in progress... *** CID 1439136: Resource leaks

Re: [openssl-project] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

2018-09-09 Thread Dr. Matthias St. Pierre
> > *** CID 1439137: Integer handling issues (NEGATIVE_RETURNS) > > work in progress... > > I think this one may be a false positive -- it's worried that EVP_MD_size() > will return -1, but we've essentially already validated that the md is > valid by the time we get there. I didn't do a

Re: [openssl-project] External contributors and the next release

2018-03-08 Thread Dr. Matthias St. Pierre
> If you are blocked on review please drop a note (like the one you just > did) to the group.  > Some of us review the specifically blocked things when such notes are > sent. > I will try hard to complete the documentation for the RAND_DRBG api until saturday. And I would be happy if #5461 and

Re: [openssl-project] DRBGs, threads and locking

2018-03-14 Thread Dr. Matthias St. Pierre
It is good that Tim hit the break and requested a discussion. That was overdue and it is unfortunate that we did not start it much earlier. I think Tim brought up to important points: 1. We need to to pause for a discussion to determine the direction to go. Otherwise the DRBG implementation will

Re: [openssl-project] External contributors and the next release

2018-03-10 Thread Dr. Matthias St. Pierre
Am 07.03.2018 um 02:20 schrieb Salz, Rich: > > I think we should make sure to set aside time to review as many of the > non-project pull requests as possible. I think it is important to > show a commitment to the larger community. > > > > One way to do this is to say that we will extend the

[openssl-project] Merge conflicts caused by pull request #5462 - Publish the RAND_DRBG API

2018-03-15 Thread Dr. Matthias St. Pierre
Hi, in a few hours I will merge pull request   #5462 - Publish the RAND_DRBG API This pull request removes 14 public symbols (symbols RAND_POOL_*,  numbers 4351 - 4364) and closes the gap by renumbering all following symbols. Anyone of you who as added new symbols to libcrypto.num in his pull

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-08 Thread Dr. Matthias St. Pierre
Just for completeness sake: The entropy requirement is 256 and *not* 384 if a derivation function is used. Please reread https://mta.openssl.org/pipermail/openssl-project/2018-April/000506.html > -Ursprüngliche Nachricht- > Von: openssl-project Im

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-08 Thread Dr. Matthias St. Pierre
> This also puts into question the no_df tests in test/drbgtest.c, how > can we possibly, under the diverse conditions we're facing, assume to > know if those tests will succeed or fail? The no_df tests are o.k. as they are. In fact, OpenSSL supports using the DRBG with or without the derivation

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-08 Thread Dr. Matthias St. Pierre
> > Wait what? This sounds nuts... Can you refer to something that backs your > > claim? > > The 384 comes straight out of SP800-90A, see the table 10.2.1. > It's also in the code where we do: > drbg->seedlen = keylen + 16; > [...] > if ((drbg->flags & RAND_DRBG_FLAG_CTR_NO_DF) == 0) { >

Re: [openssl-project] Entropy seeding the DRBG

2018-04-04 Thread Dr. Matthias St. Pierre
The internal state of the CTR-DRBG consists of a key K and a counter V (see figure 11 on page 48, which is the page before table 3). This is the reason why it requires bits_of(K) + bits_of(V) = keysize + blocksize = 256 + 128 = 384 bits to initialize the internal state of the DRBG. But the

Re: [openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Dr. Matthias St. Pierre
Speaking as one of the committer with $PAYROLL != "OpenSSL", I would like to add two remarks. I think the reluctance to merge other committer's pull requests comes from the thought that it might appear impolite or that one does not want to interfere with the other's business. Personally, I

Re: [openssl-project] Entropy seeding the DRBG

2018-04-03 Thread Dr. Matthias St. Pierre
commit 32bda2b2e4900308cb025020d8c8692e1d3c2ba9 > Author: Kurt Roeckx <k...@roeckx.be> > Date: Sun Feb 18 19:16:13 2018 +0100 > > Switch the DRBGs from AES-128-CTR to AES-256-CTR > > Reviewed-by: Dr. Matthias St. Pierre <matthias.st.pie...@ncp-e.

[openssl-project] GitHub milestone for 1.1.1

2018-03-19 Thread Dr. Matthias St. Pierre
Hi, in view of the upcoming beta release and the release strategy (see below) it is a little bit disturbing that our GitHub milestone for 1.1.1 shows only 30% completion. How are we going to deal with this? Shouldn't the PR's and issues be examined

Re: [openssl-project] Accept PR 5702 after the feature-freeze?

2018-03-21 Thread Dr. Matthias St. Pierre
tt Caswell" <m...@openssl.org> wrote: > > > > On 21/03/18 20:23, Dr. Matthias St. Pierre wrote: > > Not that it's my business, but IMHO it might be sensible to loosen the > > freeze for TLS 1.3 related changes in general, since that hasn't b

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

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

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:

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)

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

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

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

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

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

2020-02-27 Thread Dr. Matthias St. Pierre
> According to that site, it used to be at > > http://openssl.com/images/openssl-logo.png > Thanks to the Wayback Machine, nothing gets lost: Here is the historical OpenSSL Logo: https://web.archive.org/web/20141231112717/http://openssl.com/images/openssl-logo.png Matthias

RE: 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
> -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: 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: 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: 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: 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-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: 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: 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: 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-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: 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: 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: 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: 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: 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: 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
> ... 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
> 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: 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
? 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
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.

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

  1   2   >