Triage of issues using the new labels

Hi, after some discussion with Matt, some new 'triaged:*' GitHub labels have been added in addition to the 'issue: *' labels. The idea is that the 'issue: *' labels are going to be added by the reporter by choosing the corresponding GitHub issue template (there will be one template for every

GitHub Milestones

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

Re: AW: Confirmed bug labels

, Matthias St. Pierre wrote: The 'unresolved: *' labels could carry the same grey color as the 'resolved: *' labels. For the 'triaged: *' labels we need a new color. I can make a suggestion... Please do! Matt

Re: AW: Confirmed bug labels

On 29.10.19 13:34, Matt Caswell wrote:     ... For the unresolved issues, an 'unresolved: *' label makes sense:     "unresolved: " Possible reasons for marking something as unresolved: - The question is stale - no activity for a prolonged period - Off topic - the question is about

Re: AW: Confirmed bug labels

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

Re: Confirmed bug labels

We try to group the labels into categories using prefixes, see https://github.com/openssl/openssl/labels and my initial post https://mta.openssl.org/pipermail/openssl-project/2019-October/001593.html Note that the 'issue: *' labels are

Re: AW: Confirmed bug labels

Another idea just occurred to me: we could join the 'closed: *' labels with the 'triaged: *' labels:     triaged: duplicate     triaged: not a bug     triaged: wont fix On 29.10.19 12:53, Matthias St. Pierre wrote: On 29.10.19 12:41, Matt Caswell wrote: On 29/10/2019 11:34, Dr. Matthias

Re: AW: Confirmed bug labels

On 29.10.19 12:41, Matt Caswell wrote: On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: A similar problem applies to 'issue: feature request'. Just having a 'confirmed' label for bugs wouldn't help in that case. So what do you think about adding a new 'triaged: *' family of labels

AW: Confirmed bug labels

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

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

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

Commit access to openssl/tools and openssl/web

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

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)

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)

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

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

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

Re: RAND, FIPS and providers

On 24.09.19 10:58, Matthias St. Pierre wrote: It would also make sense to make the entropy sources themselves fetchable and configurable.  This would enable us to - separate FIPS and non-FIPS entropy sources (using the 'fips' attribute) This concept would also enable us to ensure that FIPS

Re: RAND, FIPS and providers

As for what to fetch: the DRBG instances and the seed material source would be ideal, although we don’t need the seed source for FIPS (so long as the DRBGs seed from inside their own provider). I had always assumed we would fetch DRBG instances. Matt It would also make sense to make the

AW: Being socially aware

> 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

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

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

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

Re: Thread sanitiser problems

Sorry, my reply was misleading, since Pauli is talking mainly about #9454. Please take a look at the issue description https://github.com/openssl/openssl/issues/9454 instead. Matthias On 30.07.19 12:47, Matthias St. Pierre wrote: On 30.07.19 12:43, Kurt Roeckx wrote: I currently fail

Re: Thread sanitiser problems

On 30.07.19 12:43, Kurt Roeckx wrote: I currently fail to see how that's a problem, unless that EVP_CIPHER_CTX tries to use a DRBG. This is what I mean when I say that things have gotten more complicated under the hood due to the replumbing. To understand the problem, please take at a

Re: Thread sanitiser problems

On 30.07.19 04:42, Dr Paul Dale wrote: > Bringing the discussions over to the project list. That's a very good idea Pauli to bring this subject to a wider audience for discussion. I would like to take the opportunity to re-post  a general remark which I made in

AW: Cleaning up include file inconsistencies

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

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

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

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

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

Cleaning up include file inconsistencies

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

> 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

Re: AW: [openssl] OpenSSL_1_1_1-stable update

I forgot one word: On 24.05.19 17:45, Matthias St. Pierre wrote: (Otherwise, the missing approvers need to be from the Reviewed-by list and additional approvals would be needed). need to be _removed_ from the Reviewed-by list

Re: AW: [openssl] OpenSSL_1_1_1-stable update

On 24.05.19 16:54, Richard Levitte wrote: On Fri, 24 May 2019 16:39:51 +0200, Matt Caswell wrote: On 24/05/2019 15:30, Richard Levitte wrote: Not in practice. We *do* ask on the PR in question if it should be cherry-picked to 1.1.1 and seek approval for that action, but then it hasn't at

AW: [openssl] OpenSSL_1_1_1-stable update

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

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

> 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

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 >

C source file naming conventions

Hi, there has been some discussion going on between Richard and me about the new naming style he introduced in pull request #8287. It would be nice to get some independent opinions from the team. Regards, Matthias See https://github.com/openssl/openssl/pull/8287#pullrequestreview-206706986

[openssl-project] Update release strategy to document new versioning scheme

Hi, I just happened to notice that the Release Strategy [1] on our homepage is outdated w.r.t. the versioning scheme: It still calls the 1.x.y versioning scheme the 'improved' one, and does not mention the new 3.0.0+ scheme at all. As of release 1.0.0 the OpenSSL versioning scheme was

Re: [openssl-project] Release scheduling

+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] 1.1.1a milestone status

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] Random devices in chroot environments revisited

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

[openssl-project] Random devices in chroot environments revisited

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] NEW: A proposal for an updated OpenSSL version scheme (v3.0-dev)

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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On 21.09.2018 17:27, Tim Hudson wrote: > > We cannot remove the current major version number - as that concept exists > and we have used it all along.  > We don't just get to tell our users for the last 20+ years what we called the > major version (which was 0 for the first half and 1 for the

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

I like Richard's approach (with the '8' or another number) and  I don't think it is contradicting semantic versioning. Maybe a good compromise between  your two opposing views would be to make the encoding irrelevant to our users by introducing version check macros like       

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

> > *** 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] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

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)

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] Is this still relevant to OpenSSL?

> 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] Fractional seconds, etc.

Note: There was a reason why Emilias pull request #2668 was backported to 1.0.2, see github #6182: It was done to fix issue #4915. So if possible we should not revert it entirely but just try to relax the fractional seconds part.     https://github.com/openssl/openssl/pull/6182    

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

> 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

> 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] GitHub labels

> 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

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] build/test before merging

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

> +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] Problems with waiting for specific person to merge

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] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

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

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)

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

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] Entropy seeding the DRBG

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.

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

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] GitHub milestone for 1.1.1

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

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

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] DRBGs, threads and locking

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

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

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

> 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] Style guide update -- summary so far

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] New Committer

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] Local kid does good

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

<    1   2