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&utm_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 LTS

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 i

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 mig

AW: GitHub issue template for general questions

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

GitHub issue template for general questions

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 exampl

Two Travis Jobs are failing on master

It looks like currently two jobs of every travis build are failing on master, each with two different tests. Since this affect the builds of the pull requests, it would be nice if they could be fixed. Is anybody taking care of the problem already? Matthias Travis Job 11 https://travis-ci.org/

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 available

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

> > > That, to me, is much clearer than the "_int" suffix. > > > > This sounds like an excellent idea to me. > > "Someone" should create a PR... I wouldn't mind doing it alongside the other changes in #9274, but I'd prefer my alternative proposal, which I just posted before. That is, if you agree

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 i

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

Re: Cleaning up include file inconsistencies

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

AW: Cleaning up include file inconsistencies

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

AW: Cleaning up include file inconsistencies

There are more oddities in the organization of the internal header files. 1) It appears to me that there are three different levels of internal header files - headers in `include/internal` - headers in `crypto/include/internal` - headers in `crypto/` along with the source files Having such a

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 https://github.com/openssl/openss

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

AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

Matt and Richard, I think you are mixing up cherry-picking and nit-picking here. (Sorry for the pun ;-) Matthias > To be picky, may I assume that you meant a reviewed-by tag for you > > should be *added*? The commit itself (its contents) having been > > reviewed by those already there, I cannot

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 sho

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 hav

AW: Issues and pull requests are largely getting ignored

> > Hello OpenSSL Team, > > > > The issues and pull requests on github are largely getting ignored, I > > know the team is busy on the new release but please spend some time on > > these as well. And I forgot to say: you are right, thanks for the polite reminder :-)

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

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

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

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

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 discussi

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

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 a

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 htt

Re: [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves?

> I believe that we need to go through those issues and PRs and make an > actual assessment, i.e. label the appropriately, and for anything > that's a bug in current 1.1.1 code (*), they need to be fixed before > the release. If it's something which can be postponed until after the release, shou

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

[openssl-project] Creating the OpenSSL_1_1_1-stable branch

Hi, just a reminder: our release strategy still states that the OpenSSL_1_1_1-stable branch will be created together with the first beta release. 20th March 2018, beta release 1 (pre3) o OpenSSL_1_1_1-stable created (feature freeze) o master becomes basis for 1.1.2 or 1.2.0 (TBD) The bra

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 page

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 f

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 al

Re: [openssl-project] Current votes FYI

> VOTE: 1.1.1 beta release schedule changed so that the next two beta releases > are now 29th May, 19 June and we will re-review release readiness after that. > We will also ensure that there is at least one beta release post TLS-1.3 RFC > publication prior to the final release. Note: I just ha

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 22:43 An: openssl-project@openssl.org Bet

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

There is also the custom to add something like "(to be squashed)" or "(fixup)" in round or square brackets to the end oft he commit title. So maybe also add a regex for "squash" or "fixup" inside round or square brackets? -Ursprüngliche Nachricht- Von: openssl-project Im Auftrag von R

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

> 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 openssl-project@opens

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

My vision is a more versatile tool (say: ghtool) with separate subcommands as building blocks to simplify common subtasks: ghtool {checkout,rebase,squash,addrev,push} ... This tool could support the concept of a "current pull request" by using a naming convention for the local branches: 'g

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

> So do you guys use the ghmerge script or own procedures? I'm curious. At the beginnning, I tried to use ghmerge but it was not flexible enough for my needs. In particular, it only gives me the choice between squashing everything or leaving everything as it is. Most notably, it does not suppor

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 do

Re: [openssl-project] Fwd: New Defects reported by Coverity Scan for openssl/openssl

Matt, I wasn't aware that I can register for coverity reports (which I just did). If no one else has done it yet, I can look into the three drbg issues mentioned in your mail. Matthias BTW: isn't beta release 3 (pre5) due today? There was no announcement of a code freeze yet. Am 16.04.2018 um 1

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 Auftrag von > Salz, Rich > Gesendet:

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 see

Re: [openssl-project] Entropy seeding the DRBG

> -Ursprüngliche Nachricht- > Von: openssl-project Im Auftrag von > Salz, Rich > Gesendet: Mittwoch, 4. April 2018 02:59 > An: openssl-project@openssl.org > Betreff: Re: [openssl-project] Entropy seeding the DRBG > > If you say that AES256 needs CSPRNG seeding with 256 bits, then why doe

Re: [openssl-project] Entropy seeding the DRBG

commit 32bda2b2e4900308cb025020d8c8692e1d3c2ba9 > Author: Kurt Roeckx > 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 > GH: #5401 At first I was reluctant wh

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

t;Matt Caswell" 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 been >

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

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 been finalized yet. So instead of starting a vote for every pull request in question, you could also vote about an exceptional rule like the following: A pull re

Re: [openssl-project] Code Repo

Even more statistics: the completion rate of the milestone has _dropped_ from 30% to 26% since yesterday: https://github.com/openssl/openssl/milestone/9 Matthias Am 20.03.2018 um 16:06 schrieb Matt Caswell: > Without stating an opinion either way - some stats: > > PRs with 1.1.1 milestone: 57

[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

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 b

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 BETA

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

Re: [openssl-project] Next release is beta1

Am 04.03.2018 um 17:30 schrieb Kurt Roeckx: > There is also still work going on related to the DRBG API. Kurt convinced me that the DRBG backend (the reseeding) needs some adjustments in order to comply to NIST SP 800-90C. This applies in particular to the prediction_resistance feature. And there

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

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 leas

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

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 https://mta.open

Re: [openssl-project] Welcome Dr. Matthias St. Pierre

Thank you everybody! Feels great to be here! Matthias On 23.01.2018 17:49, Matt Caswell wrote: > I invited him to the committers team on github. > > Welcome Matthias! > > Matt > > > On 23/01/18 16:35, Salz, Rich wrote: >> Please welcome Matthias as our newest committer. >> >>   >> >> I have adde

<    1   2