From openssl at openssl.org Fri Dec 6 16:46:08 2019 From: openssl at openssl.org (OpenSSL) Date: Fri, 6 Dec 2019 16:46:08 +0000 Subject: OpenSSL Security Advisory Message-ID: <20191206164608.GA6057@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [6 December 2019] =========================================== rsaz_512_sqr overflow bug on x86_64 (CVE-2019-1551) =================================================== Severity: Low There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. Also applications directly using the low level API BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. OpenSSL versions 1.1.1 and 1.0.2 are affected by this issue. However due to the low severity of this issue we are not creating new releases at this time. The 1.1.1 mitigation for this issue can be found in commit 419102400. The 1.0.2 mitigation for this issue can be found in commit f1c5eea8a. This issue was found by OSS-Fuzz and Guido Vranken and reported to OpenSSL on 12th September 2019. The fix was developed by Andy Polyakov with additional analysis by Bernd Edlinger. Note ===== OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates. It is unknown whether issues in this advisory affect it. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20191206.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl3qhRUACgkQ2cTSbQ5g RJHQvwgAhVefbdppxDZbGhiIjc/MLTeZmYC5U57rGMvGQ7WL8+xbkGVYmFPu69kp dN+kGPVJAZySmbhJZVmbrdxgl/zCvwE1WXPh5ILQCvA8cF0z762TCJpxbDJksy/9 igmavYVMxWLePMz7+HsVo6VCcvmBNGykg8zpJm33v2/wc9dBE+c/sJoep/pcXYNI fLrcLUnsnJoWhg23VNUXEkW8Ru4jkaXTtg4v4sdxHzPbp0qBbekdhj6GAekyFRjn Zpv4buJDxohcJw91rBK36tXU/PZARW4tO6TR6CdVuB16T7XMye0wKp3kRNd0QPE9 O/LGrT1Jq8cFTxYHfFYeOrkVJKpgog== =6Z6t -----END PGP SIGNATURE----- From matt at openssl.org Mon Dec 9 14:46:28 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 9 Dec 2019 14:46:28 +0000 Subject: Monthly Status Report (November) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Updated EVP_get_digestbyname() and EVP_get_cipherbyname() to know about the new namemap and use it where appropriate - Wrote and published bog with updates for 3.0 - Significant effort has been spent in conjunction with Richard Levitte reviewing old issues and triaging them. This is expected to be ongoing for some time. - Continued work from the previous month to get the asymmetric cipher support approved and pushed - Fixed no-dsa - Significant ongoing review work on the CMP contribution - Created PR to move the constant time RSA padding checks out of libssl and into the providers. - Fixed no-engine - Fixed no-cmac and no-camellia - Fixed no-blake2 - Fixed an uninitialised read in conf_def.c - Fixed a memory leak in confdump, and added confdump to .gitignore - Fixed a use-after-free after copying a cipher ctx - Finished off and pushed PR to fix various algorithm naming inconsistencies - Fixed EVP_CIPHER_CTX_set_keylen to ensure it does not succeed if a bad keylen is passed - Added some missing NULL pointer return checks - Fix for handling NULL with length 0 in EVP_Encrypt* functions - Updated and pushed PR to ensure the FIPS self tests are only run once - Created PR to deprecate the AES_ige_* functions - Further work on the PR to fix SSL_get_servername() Matt From matt at openssl.org Thu Dec 12 09:20:47 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Dec 2019 09:20:47 +0000 Subject: Flaw in our process for dealing with trivial changes Message-ID: I notice that PR 10594 (Add support for otherName:NAIRealm in output) got merged yesterday: https://github.com/openssl/openssl/pull/10594 The commit description contained "CLA: trivial" and so the "hold: cla required" label was not automatically applied to the PR. But the discussion in the PR suggested a CLA should be submitted. But it got merged anyway! Fortunately the CLA had already been processed - just not noted in the PR. So, in this case, it makes no difference. I think this points to a possible flaw in our workflow for dealing with trivial changes. Because the "CLA: trivial" header suppresses the "hold: cla required" label and the git hooks don't complain when commits get pushed with the "CLA: trivial" header and no CLA on file, it seems possible to me that we could push commit all the way through the process without the reviewers even realising that the author is claiming triviality on the commit. Not sure what the solution to that is. Matt From beldmit at gmail.com Thu Dec 12 09:29:28 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 12 Dec 2019 12:29:28 +0300 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: References: Message-ID: Dear Matt, As - the contributor agreed to sign the CLA and - there was a mark that CLA is signed and - all the necessary approves were present I decided that there is no problem to merge. BTW, I am not sure the PR was trivial enough. Anyway, the responsibility was mine, not the git one :) On Thu, Dec 12, 2019 at 12:20 PM Matt Caswell wrote: > I notice that PR 10594 (Add support for otherName:NAIRealm in output) > got merged yesterday: > https://github.com/openssl/openssl/pull/10594 > > The commit description contained "CLA: trivial" and so the "hold: cla > required" label was not automatically applied to the PR. But the > discussion in the PR suggested a CLA should be submitted. But it got > merged anyway! Fortunately the CLA had already been processed - just not > noted in the PR. So, in this case, it makes no difference. > > I think this points to a possible flaw in our workflow for dealing with > trivial changes. Because the "CLA: trivial" header suppresses the "hold: > cla required" label and the git hooks don't complain when commits get > pushed with the "CLA: trivial" header and no CLA on file, it seems > possible to me that we could push commit all the way through the process > without the reviewers even realising that the author is claiming > triviality on the commit. > > Not sure what the solution to that is. > > Matt > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu Dec 12 09:36:32 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 12 Dec 2019 19:36:32 +1000 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: References: Message-ID: I agree that there is a possible flaw in the workflow. What?s saved us so far is that new contributors don?t generally include the "CLA: trivial" line or put it in the GitHub text. Could we have a ?trivial? tag that is added whenever the "CLA: trivial" line is present? Better would be to add it only if the submitter doesn?t have a CLA on file but either works. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 12 Dec 2019, at 7:20 pm, Matt Caswell wrote: > > I notice that PR 10594 (Add support for otherName:NAIRealm in output) > got merged yesterday: > https://github.com/openssl/openssl/pull/10594 > > The commit description contained "CLA: trivial" and so the "hold: cla > required" label was not automatically applied to the PR. But the > discussion in the PR suggested a CLA should be submitted. But it got > merged anyway! Fortunately the CLA had already been processed - just not > noted in the PR. So, in this case, it makes no difference. > > I think this points to a possible flaw in our workflow for dealing with > trivial changes. Because the "CLA: trivial" header suppresses the "hold: > cla required" label and the git hooks don't complain when commits get > pushed with the "CLA: trivial" header and no CLA on file, it seems > possible to me that we could push commit all the way through the process > without the reviewers even realising that the author is claiming > triviality on the commit. > > Not sure what the solution to that is. > > Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaishen.yy at alipay.com Thu Dec 12 09:43:43 2019 From: kaishen.yy at alipay.com (Paul Yang) Date: Thu, 12 Dec 2019 17:43:43 +0800 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: References: Message-ID: 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. Regards, Paul Yang > On Dec 12, 2019, at 5:29 PM, Dmitry Belyavsky wrote: > > Dear Matt, > > As > - the contributor agreed to sign the CLA and > - there was a mark that CLA is signed and > - all the necessary approves were present > I decided that there is no problem to merge. > > BTW, I am not sure the PR was trivial enough. > > Anyway, the responsibility was mine, not the git one :) > > > On Thu, Dec 12, 2019 at 12:20 PM Matt Caswell > wrote: > I notice that PR 10594 (Add support for otherName:NAIRealm in output) > got merged yesterday: > https://github.com/openssl/openssl/pull/10594 > > The commit description contained "CLA: trivial" and so the "hold: cla > required" label was not automatically applied to the PR. But the > discussion in the PR suggested a CLA should be submitted. But it got > merged anyway! Fortunately the CLA had already been processed - just not > noted in the PR. So, in this case, it makes no difference. > > I think this points to a possible flaw in our workflow for dealing with > trivial changes. Because the "CLA: trivial" header suppresses the "hold: > cla required" label and the git hooks don't complain when commits get > pushed with the "CLA: trivial" header and no CLA on file, it seems > possible to me that we could push commit all the way through the process > without the reviewers even realising that the author is claiming > triviality on the commit. > > Not sure what the solution to that is. > > Matt > > > -- > SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From kaishen.yy at alipay.com Thu Dec 12 09:45:03 2019 From: kaishen.yy at alipay.com (Paul Yang) Date: Thu, 12 Dec 2019 17:45:03 +0800 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: References: Message-ID: <3A66053E-E6EB-4D74-BCD5-5A66C29170C0@alipay.com> It seems we have the same thoughts... Regards, Paul Yang > On Dec 12, 2019, at 5:36 PM, Dr Paul Dale wrote: > > I agree that there is a possible flaw in the workflow. What?s saved us so far is that new contributors don?t generally include the "CLA: trivial" line or put it in the GitHub text. > > Could we have a ?trivial? tag that is added whenever the "CLA: trivial" line is present? Better would be to add it only if the submitter doesn?t have a CLA on file but either works. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 12 Dec 2019, at 7:20 pm, Matt Caswell > wrote: >> >> I notice that PR 10594 (Add support for otherName:NAIRealm in output) >> got merged yesterday: >> https://github.com/openssl/openssl/pull/10594 >> >> The commit description contained "CLA: trivial" and so the "hold: cla >> required" label was not automatically applied to the PR. But the >> discussion in the PR suggested a CLA should be submitted. But it got >> merged anyway! Fortunately the CLA had already been processed - just not >> noted in the PR. So, in this case, it makes no difference. >> >> I think this points to a possible flaw in our workflow for dealing with >> trivial changes. Because the "CLA: trivial" header suppresses the "hold: >> cla required" label and the git hooks don't complain when commits get >> pushed with the "CLA: trivial" header and no CLA on file, it seems >> possible to me that we could push commit all the way through the process >> without the reviewers even realising that the author is claiming >> triviality on the commit. >> >> Not sure what the solution to that is. >> >> Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From matt at openssl.org Thu Dec 12 10:25:30 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Dec 2019 10:25:30 +0000 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: References: Message-ID: On 12/12/2019 09:43, Paul Yang wrote: > Would it be better if 'CLA: trivial? is in the commit message but no CLA > on file, then a new label like ?warn: no CLA but trivial? is added? This > can inform the committer who will merge the PR for the CLA condition of > the commits. > Yes, I think that would be a really good idea. At least then its very visible what is happening. On 12/12/2019 09:29, Dmitry Belyavsky wrote: > - the contributor agreed to sign the CLA and > - there was a mark that CLA is signed and > - all the necessary approves were present > I decided that there is no problem to merge. The only thing I could see in that PR was a message from the author saying that they would submit a CLA. There doesn't seem to be a message saying that the CLA had actually been processed. It's not sufficient for the author to *say* they have submitted a CLA. It must actually have been submitted, and accepted and be on file. Sometimes there are problems with submitted CLAs (e.g. missing fields, or a user sends an ICLA when they really also need a CCLA, etc). Normally the git hooks would not allow you to push a commit where the author does not have a CLA. However those checks are suppressed where "CLA: trivial" appears in the commit description. So we need to be extra careful in that case, i.e. perhaps we should insist that commits containing "CLA: trivial" have the line removed if we don't think the commit really is trivial. This ensures that the git hooks do their job and we can be absolutely sure that the author has a registered CLA. Matt > > Regards, > > Paul Yang > >> On Dec 12, 2019, at 5:29 PM, Dmitry Belyavsky > > wrote: >> >> Dear Matt, >> >> As? >> - the contributor agreed to sign the CLA and? >> - there was a mark that CLA is signed and >> - all the necessary approves were present >> I decided that there is no problem to merge. >> >> BTW, I am not sure the PR was trivial enough. >> >> Anyway, the responsibility was mine, not the git one :) >> >> >> On Thu, Dec 12, 2019 at 12:20 PM Matt Caswell > > wrote: >> >> I notice that PR 10594 (Add support for otherName:NAIRealm in output) >> got merged yesterday: >> https://github.com/openssl/openssl/pull/10594 >> >> The commit description contained "CLA: trivial" and so the "hold: cla >> required" label was not automatically applied to the PR. But the >> discussion in the PR suggested a CLA should be submitted. But it got >> merged anyway! Fortunately the CLA had already been processed - >> just not >> noted in the PR. So, in this case, it makes no difference. >> >> I think this points to a possible flaw in our workflow for dealing >> with >> trivial changes. Because the "CLA: trivial" header suppresses the >> "hold: >> cla required" label and the git hooks don't complain when commits get >> pushed with the "CLA: trivial" header and no CLA on file, it seems >> possible to me that we could push commit all the way through the >> process >> without the reviewers even realising that the author is claiming >> triviality on the commit. >> >> Not sure what the solution to that is. >> >> Matt >> >> >> >> -- >> SY, Dmitry Belyavsky > From Matthias.St.Pierre at ncp-e.com Thu Dec 12 11:15:30 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 12 Dec 2019 11:15:30 +0000 Subject: AW: Flaw in our process for dealing with trivial changes In-Reply-To: References: Message-ID: <3f4fb278315743b1bcc8a2186e07016c@Ex13.ncp.local> > On 12/12/2019 09:43, Paul Yang wrote: > > Would it be better if 'CLA: trivial? is in the commit message but no CLA > > on file, then a new label like ?warn: no CLA but trivial? is added? This > > can inform the committer who will merge the PR for the CLA condition of > > the commits. > > > > Yes, I think that would be a really good idea. At least then its very > visible what is happening. Reusing Tim's words I'd like to argue that we should avoid rushing for a premature optimization. - Just adding new labels does not solve anything, at least as long as those labels are not enforced automatically. (via GitHub bot & git hook) - This is the first time in quite a while that a pull request with a questionable trivial CLA has slipped in and it is no problem to revert a commit if necessary. So I wouldn't consider it a significant problem. The best countermeasure IMHO is to adopt the habit of skimming over the last GitHub messages of the PR and to reread the final commit messages (after the "Reviewed-by:" annotations have been added) before pushing the final commit. As for a possible semi-automated solution: The problem is more fundamental: currently both the GitHub bot and the git commit hook only watch out for the 'CLA: trivial' marker. But this marker is intended to be added by the *contributor* himself, so it expresses only his opinion, not ours. Only if all three, the contributor and the two reviewers agree, then the pull request can be considered trivial. One possible solution to this problem could be the following procedure: Add three mutually exclusive [cla: *] labels: [cla: ok] (green) [cla: trivial] (green) [cla: missing] (red) The CLA bot *always* sets the [cla: ok] label if it finds a CLA on file. Otherwise, it sets the [cla: missing] label, unless the [cla: trivial] label is already set. The [cla: trivial] label can only be set manually by a committer, and only after the consent between contributor and both reviewers has been reached. The server-side commit hook ensures that - the "CLA: trivial" annotation is present in *all* commits of the PR if and only if the [cla: trivial] label is set. - the [cla: ok] label is set if and only if the CLA is on file - the pull request is accepted only if the [cla: ok] or [cla: trivial] label is set Matthias From matt at openssl.org Thu Dec 12 11:32:09 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Dec 2019 11:32:09 +0000 Subject: AW: Flaw in our process for dealing with trivial changes In-Reply-To: <3f4fb278315743b1bcc8a2186e07016c@Ex13.ncp.local> References: <3f4fb278315743b1bcc8a2186e07016c@Ex13.ncp.local> Message-ID: <6ae5489b-09d2-ba88-6ef0-fc1fac876631@openssl.org> On 12/12/2019 11:15, Dr. Matthias St. Pierre wrote: > >> On 12/12/2019 09:43, Paul Yang wrote: >>> Would it be better if 'CLA: trivial? is in the commit message but no CLA >>> on file, then a new label like ?warn: no CLA but trivial? is added? This >>> can inform the committer who will merge the PR for the CLA condition of >>> the commits. >>> >> >> Yes, I think that would be a really good idea. At least then its very >> visible what is happening. > > Reusing Tim's words I'd like to argue that we should avoid rushing for a > premature optimization. > > - Just adding new labels does not solve anything, at least as long as those labels > are not enforced automatically. (via GitHub bot & git hook) I think part of the problem with "CLA: trivial" handling at the moment is that it is not *visible*. A PR with a "CLA: trivial" header in the commit, and with no CLA on file, looks the same as a PR where the author does have a CLA on file. It's easy to miss that "CLA: trivial" is there at all. I agree that having an automatically enforced solution is the way to go. > > - This is the first time in quite a while that a pull request with a questionable > trivial CLA has slipped in As far as we know! > and it is no problem to revert a commit if necessary. > So I wouldn't consider it a significant problem. The best countermeasure IMHO > is to adopt the habit of skimming over the last GitHub messages of the PR and > to reread the final commit messages (after the "Reviewed-by:" annotations have > been added) before pushing the final commit. > > > As for a possible semi-automated solution: > > The problem is more fundamental: currently both the GitHub bot and the git commit hook > only watch out for the 'CLA: trivial' marker. But this marker is intended to be added > by the *contributor* himself, so it expresses only his opinion, not ours. Only if all three, > the contributor and the two reviewers agree, then the pull request can be considered > trivial. > > One possible solution to this problem could be the following procedure: > > Add three mutually exclusive [cla: *] labels: > > [cla: ok] (green) > [cla: trivial] (green) > [cla: missing] (red) > > The CLA bot *always* sets the [cla: ok] label if it finds a CLA on file. Otherwise, it sets the > [cla: missing] label, unless the [cla: trivial] label is already set. > > The [cla: trivial] label can only be set manually by a committer, and only after the consent > between contributor and both reviewers has been reached. This solution could work. > > The server-side commit hook ensures that > > - the "CLA: trivial" annotation is present in *all* commits of the PR if and only if the [cla: trivial] > label is set. > - the [cla: ok] label is set if and only if the CLA is on file > - the pull request is accepted only if the [cla: ok] or [cla: trivial] label is set One issue with this bit is that it requires the git hooks to connect to github to check the labels. AFAIK we don't do that at present. Does it add too much complexity to the hooks? Matt From Matthias.St.Pierre at ncp-e.com Thu Dec 12 12:06:33 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 12 Dec 2019 12:06:33 +0000 Subject: Flaw in our process for dealing with trivial changes Message-ID: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> > > The server-side commit hook ensures that > > > > - the "CLA: trivial" annotation is present in *all* commits of the PR if and only if the [cla: trivial] > > label is set. > > - the [cla: ok] label is set if and only if the CLA is on file > > - the pull request is accepted only if the [cla: ok] or [cla: trivial] label is set > > > One issue with this bit is that it requires the git hooks to connect to > github to check the labels. AFAIK we don't do that at present. Does it > add too much complexity to the hooks? Actually, the consistency checks could be done entirely by the addrev script, which already uses the GitHub API. addrev: ===== Ensure that - the [cla: ok] label is set if and only if the CLA is on file - the [cla: trivial] label is set if and only if the "CLA: trivial" annotation is present in *all* commits of the PR git commit hook ============= Accept pull request if and only if the CLA is on file or *all* commits have the "CLA: trivial" annotation. (The git commit hook would need only a minimal change, if it does not check *all* commits yet.) From matt at openssl.org Thu Dec 12 12:10:35 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Dec 2019 12:10:35 +0000 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> Message-ID: On 12/12/2019 12:06, Dr. Matthias St. Pierre wrote: >>> The server-side commit hook ensures that >>> >>> - the "CLA: trivial" annotation is present in *all* commits of the PR if and only if the [cla: trivial] >>> label is set. >>> - the [cla: ok] label is set if and only if the CLA is on file >>> - the pull request is accepted only if the [cla: ok] or [cla: trivial] label is set >> >> >> One issue with this bit is that it requires the git hooks to connect to >> github to check the labels. AFAIK we don't do that at present. Does it >> add too much complexity to the hooks? > > Actually, the consistency checks could be done entirely by the addrev script, which already uses the GitHub API. > > addrev: > ===== > > Ensure that > > - the [cla: ok] label is set if and only if the CLA is on file > - the [cla: trivial] label is set if and only if the "CLA: trivial" annotation is present in *all* commits of the PR It's conceivable (although I don't know how likely) that a PR has mixed commits from different authors. E.g. a complex PR from one author with a CLA on file, but with one commit from a different author that is trivial. But in principle I agree that addrev could be used to do this. It's not quite as robust as doing it in the commit hook - because you don't *have* to use addrev. But, AFAIK, everyone does - so that's probably good enough. Matt > > git commit hook > ============= > > Accept pull request if and only if the CLA is on file or *all* commits have the "CLA: trivial" annotation. > > > (The git commit hook would need only a minimal change, if it does not check *all* commits yet.) > > From beldmit at gmail.com Thu Dec 12 13:08:39 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 12 Dec 2019 16:08:39 +0300 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: References: Message-ID: Dear Matt, On Thu, Dec 12, 2019 at 1:25 PM Matt Caswell wrote: > > On 12/12/2019 09:29, Dmitry Belyavsky wrote: > > - the contributor agreed to sign the CLA and > > - there was a mark that CLA is signed and > > - all the necessary approves were present > > I decided that there is no problem to merge. > > The only thing I could see in that PR was a message from the author > saying that they would submit a CLA. There doesn't seem to be a message > saying that the CLA had actually been processed. > Well, then it's my misinterpretation. I saw a author's words and green checkbox related to CLA. My fault, sorry. > It's not sufficient for the author to *say* they have submitted a CLA. > It must actually have been submitted, and accepted and be on file. > Sometimes there are problems with submitted CLAs (e.g. missing fields, > or a user sends an ICLA when they really also need a CCLA, etc). > Normally the git hooks would not allow you to push a commit where the > author does not have a CLA. However those checks are suppressed where > "CLA: trivial" appears in the commit description. So we need to be extra > careful in that case, i.e. perhaps we should insist that commits > containing "CLA: trivial" have the line removed if we don't think the > commit really is trivial. This ensures that the git hooks do their job > and we can be absolutely sure that the author has a registered CLA. > > Matt > > > > > Regards, > > > > Paul Yang > > > >> On Dec 12, 2019, at 5:29 PM, Dmitry Belyavsky >> > wrote: > >> > >> Dear Matt, > >> > >> As > >> - the contributor agreed to sign the CLA and > >> - there was a mark that CLA is signed and > >> - all the necessary approves were present > >> I decided that there is no problem to merge. > >> > >> BTW, I am not sure the PR was trivial enough. > >> > >> Anyway, the responsibility was mine, not the git one :) > >> > >> > >> On Thu, Dec 12, 2019 at 12:20 PM Matt Caswell >> > wrote: > >> > >> I notice that PR 10594 (Add support for otherName:NAIRealm in > output) > >> got merged yesterday: > >> https://github.com/openssl/openssl/pull/10594 > >> > >> The commit description contained "CLA: trivial" and so the "hold: > cla > >> required" label was not automatically applied to the PR. But the > >> discussion in the PR suggested a CLA should be submitted. But it got > >> merged anyway! Fortunately the CLA had already been processed - > >> just not > >> noted in the PR. So, in this case, it makes no difference. > >> > >> I think this points to a possible flaw in our workflow for dealing > >> with > >> trivial changes. Because the "CLA: trivial" header suppresses the > >> "hold: > >> cla required" label and the git hooks don't complain when commits > get > >> pushed with the "CLA: trivial" header and no CLA on file, it seems > >> possible to me that we could push commit all the way through the > >> process > >> without the reviewers even realising that the author is claiming > >> triviality on the commit. > >> > >> Not sure what the solution to that is. > >> > >> Matt > >> > >> > >> > >> -- > >> SY, Dmitry Belyavsky > > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Thu Dec 12 17:24:33 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 12 Dec 2019 18:24:33 +0100 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> Message-ID: <20191212172433.GA770418@roeckx.be> On Thu, Dec 12, 2019 at 12:10:35PM +0000, Matt Caswell wrote: > > But in principle I agree that addrev could be used to do this. It's not > quite as robust as doing it in the commit hook - because you don't > *have* to use addrev. But, AFAIK, everyone does - so that's probably > good enough. I have never used addrev. Kurt From paul.dale at oracle.com Thu Dec 12 21:06:52 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 13 Dec 2019 07:06:52 +1000 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <20191212172433.GA770418@roeckx.be> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> Message-ID: <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> Before we start over engineering a solution, how about we try just having an automatic visual indicator for trivial PRs. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 13 Dec 2019, at 3:24 am, Kurt Roeckx wrote: > > On Thu, Dec 12, 2019 at 12:10:35PM +0000, Matt Caswell wrote: >> >> But in principle I agree that addrev could be used to do this. It's not >> quite as robust as doing it in the commit hook - because you don't >> *have* to use addrev. But, AFAIK, everyone does - so that's probably >> good enough. > > I have never used addrev. > > > Kurt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu Dec 12 21:31:10 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 13 Dec 2019 07:31:10 +1000 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> Message-ID: <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> 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. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 13 Dec 2019, at 7:06 am, Dr Paul Dale wrote: > > Before we start over engineering a solution, how about we try just having an automatic visual indicator for trivial PRs. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 13 Dec 2019, at 3:24 am, Kurt Roeckx > wrote: >> >> On Thu, Dec 12, 2019 at 12:10:35PM +0000, Matt Caswell wrote: >>> >>> But in principle I agree that addrev could be used to do this. It's not >>> quite as robust as doing it in the commit hook - because you don't >>> *have* to use addrev. But, AFAIK, everyone does - so that's probably >>> good enough. >> >> I have never used addrev. >> >> >> Kurt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu Dec 12 21:48:03 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 13 Dec 2019 00:48:03 +0300 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> Message-ID: Great idea. ??, 13 ???. 2019 ?., 0:31 Dr Paul Dale : > 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. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 13 Dec 2019, at 7:06 am, Dr Paul Dale wrote: > > Before we start over engineering a solution, how about we try just having > an automatic visual indicator for trivial PRs. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 13 Dec 2019, at 3:24 am, Kurt Roeckx wrote: > > On Thu, Dec 12, 2019 at 12:10:35PM +0000, Matt Caswell wrote: > > > But in principle I agree that addrev could be used to do this. It's not > quite as robust as doing it in the commit hook - because you don't > *have* to use addrev. But, AFAIK, everyone does - so that's probably > good enough. > > > I have never used addrev. > > > Kurt > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Dec 12 23:55:56 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Dec 2019 23:55:56 +0000 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> Message-ID: On 12/12/2019 21:31, 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. Sounds workable. Matt > > > Pauli > --? > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations? > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 13 Dec 2019, at 7:06 am, Dr Paul Dale > > wrote: >> >> Before we start over engineering a solution, how about we try just >> having an automatic visual indicator for trivial PRs. >> >> >> Pauli >> --? >> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations? >> Phone +61 7 3031 7217 >> Oracle Australia >> >> >> >> >>> On 13 Dec 2019, at 3:24 am, Kurt Roeckx >> > wrote: >>> >>> On Thu, Dec 12, 2019 at 12:10:35PM +0000, Matt Caswell wrote: >>>> >>>> But in principle I agree that addrev could be used to do this. It's not >>>> quite as robust as doing it in the commit hook - because you don't >>>> *have* to use addrev. But, AFAIK, everyone does - so that's probably >>>> good enough. >>> >>> I have never used addrev. >>> >>> >>> Kurt >>> >> > From levitte at openssl.org Fri Dec 13 00:10:06 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 13 Dec 2019 01:10:06 +0100 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> Message-ID: <87zhfx13xd.wl-levitte@openssl.org> On Thu, 12 Dec 2019 13:06:33 +0100, Dr. Matthias St. Pierre wrote: > > > > The server-side commit hook ensures that > > > > > > - the "CLA: trivial" annotation is present in *all* commits of the PR if and only if the [cla: trivial] > > > label is set. > > > - the [cla: ok] label is set if and only if the CLA is on file > > > - the pull request is accepted only if the [cla: ok] or [cla: trivial] label is set > > > > > > One issue with this bit is that it requires the git hooks to connect to > > github to check the labels. AFAIK we don't do that at present. Does it > > add too much complexity to the hooks? > > Actually, the consistency checks could be done entirely by the > addrev script, which already uses the GitHub API. Incidently, I'm looking at a rewrite of addrev to make it a self-contained script that doesn't need the assistance of gitaddrev, and that also computes everything in the preparation sweep, so the filter part just needs to do the editing (i.e. should work *much* faster). > git commit hook > ============= > > Accept pull request if and only if the CLA is on file or *all* > commits have the "CLA: trivial" annotation. > > (The git commit hook would need only a minimal change, if it does > not check *all* commits yet.) git education: It's the post-receive or update hooks, not the commit hook. There are commit hooks, and they are all client side, so talking about a commit hook in this context is *really* confusing, especially for those who aren't qutie aware. Ref: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks That being said, the update hook does what you say, on a per commit basis. In other words, for each commit, it will do the appropriate checks. This is the leading comment of that script: # For any revision between oldrev and newrev, print VREF/UNREVIEWED/{sha} # if it hasn't been reviewed enough. # # The rules for being reviewed enough are: # # - UNLESS there's a 'CLA: Trivial' line: # - at least one of the author and the reviewers MUST have a CLA and MUST # be member of the 'omc' group. # - at least two of the author and the reviewers MUST have a CLA and MUST # be member of the 'commit' group. # - IF there's a 'CLA: Trivial' line: # - at least one of the reviewers MUST have a CLA and MUST be member of the # 'omc' group. # - at least two of the reviewers MUST have a CLA and MUST be member of the # 'commit' group. (gitolite works by having a denial on any output VREF/UNREVIEWED/ line) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Dec 13 00:39:49 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 13 Dec 2019 01:39:49 +0100 Subject: AW: Flaw in our process for dealing with trivial changes In-Reply-To: <3f4fb278315743b1bcc8a2186e07016c@Ex13.ncp.local> References: <3f4fb278315743b1bcc8a2186e07016c@Ex13.ncp.local> Message-ID: <87y2vh12ju.wl-levitte@openssl.org> On Thu, 12 Dec 2019 12:15:30 +0100, Dr. Matthias St. Pierre wrote: > > As for a possible semi-automated solution: > > The problem is more fundamental: currently both the GitHub bot and > the git commit hook only watch out for the 'CLA: trivial' marker. Correct re the clacheck hook (that's the Github hook we're talking about), but re the update hook on our git server, it does a little more than that, as already shown. > One possible solution to this problem could be the following procedure: > > Add three mutually exclusive [cla: *] labels: > > [cla: ok] (green) > [cla: trivial] (green) > [cla: missing] (red) > > The CLA bot *always* sets the [cla: ok] label if it finds a CLA on > file. Otherwise, it sets the [cla: missing] label, unless the [cla: > trivial] label is already set. I'm not sure why the [cla: ok] or [cla: missing] labels are needed. We already have a [hold: cla required] label that comes up when there's a lack of CLA and of "CLA: trivial" marker, so [cla: ok] and [cla: missing] seem redundant. However, contrary to you, I would have the [cla: trivial] label added automatically!... whenever clacheck finds a "CLA: trivial" line in any of the commits. > The [cla: trivial] label can only be set manually by a committer, > and only after the consent between contributor and both reviewers > has been reached. Sounds superfluous, considering there's already a need for two approvals, as well as the [approved: done] label set. Yet another manual label will make zero difference, as long as all reviewers can clearly see that there's a "CLA: trivial" commit (i.e. that the [cla: trivial] label has been set by clacheck). After all, the problem we have hit is that "CLA: trivial" can go undetected, so let's make sure it doesn't, without adding a lot of other redundant mechanisms that only make our lives harder, yeah? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Dec 13 01:02:58 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 13 Dec 2019 02:02:58 +0100 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> Message-ID: <87wob111h9.wl-levitte@openssl.org> On Thu, 12 Dec 2019 22:31:10 +0100, Dr Paul Dale wrote: > > A red blocker along the lines of: ?Triviality Unconfirmed?. One of > the reviewers needs to remove this before the PR can be merged. > > It?s in our face, it prevent accidental merges and its low overhead. I still think simply adding the label should be sufficient. I dunno about you, but I look at labels all the time, for all sorts of reasons, and one saying [cla: trivial] would certainly attract my attention. Let's make it bright red-orange, that'll catch anyone's eye (even mine) Also, removing that label will rapidly be annoying as soon as someone closes and re-opens a PR... or whatever other action that triggers the "pull_request" event (and there's a lot that does that... our script is being kept busy!). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Fri Dec 13 03:48:38 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 13 Dec 2019 13:48:38 +1000 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <87wob111h9.wl-levitte@openssl.org> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> <87wob111h9.wl-levitte@openssl.org> Message-ID: <39800FA9-D909-409B-8462-C2F3C977EACD@oracle.com> A better example of this problem: #10607. Both Paul and I approved it yesterday and I merged it today without noticing until too late that it was tagged ?CLA: trivial? :( I?ve not reverted it at this point but will if necessary. Let?s get the label in. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 13 Dec 2019, at 11:02 am, Richard Levitte wrote: > > On Thu, 12 Dec 2019 22:31:10 +0100, > Dr Paul Dale wrote: >> >> A red blocker along the lines of: ?Triviality Unconfirmed?. One of >> the reviewers needs to remove this before the PR can be merged. >> >> It?s in our face, it prevent accidental merges and its low overhead. > > I still think simply adding the label should be sufficient. I dunno > about you, but I look at labels all the time, for all sorts of > reasons, and one saying [cla: trivial] would certainly attract my > attention. > > Let's make it bright red-orange, that'll catch anyone's eye (even mine) > > Also, removing that label will rapidly be annoying as soon as someone > closes and re-opens a PR... or whatever other action that triggers > the "pull_request" event (and there's a lot that does that... our > script is being kept busy!). > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Fri Dec 13 07:58:27 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 13 Dec 2019 07:58:27 +0000 Subject: AW: Flaw in our process for dealing with trivial changes In-Reply-To: <87wob111h9.wl-levitte@openssl.org> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> <87wob111h9.wl-levitte@openssl.org> Message-ID: <689ec900e65d4f128eefee9733d3c73a@Ex13.ncp.local> > On Thu, 12 Dec 2019 22:31:10 +0100, > Dr Paul Dale wrote: > > > > A red blocker along the lines of: "Triviality Unconfirmed". One of > > the reviewers needs to remove this before the PR can be merged. > > > > It's in our face, it prevent accidental merges and its low overhead. > > I still think simply adding the label should be sufficient. I dunno > about you, but I look at labels all the time, for all sorts of > reasons, and one saying [cla: trivial] would certainly attract my > attention. > > Let's make it bright red-orange, that'll catch anyone's eye (even mine) > > Also, removing that label will rapidly be annoying as soon as someone > closes and re-opens a PR... or whatever other action that triggers > the "pull_request" event (and there's a lot that does that... our > script is being kept busy!). > > Cheers, > Richard This seems to be implied already by my last proposal, with just one color changed: ;-) > Add three mutually exclusive [cla: *] labels: > [cla: ok] (green) > [cla: trivial] (orange) > [cla: missing] (red) > > The CLA bot *always* sets the [cla: ok] label if it finds a CLA on file. Otherwise, it sets the > [cla: missing] label, unless the [cla: trivial] label is already set. > > The [cla: trivial] label can only be set manually by a committer, and only after the consent > between contributor and both reviewers has been reached. From levitte at openssl.org Fri Dec 13 11:07:48 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 13 Dec 2019 12:07:48 +0100 Subject: AW: Flaw in our process for dealing with trivial changes In-Reply-To: <689ec900e65d4f128eefee9733d3c73a@Ex13.ncp.local> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> <87wob111h9.wl-levitte@openssl.org> <689ec900e65d4f128eefee9733d3c73a@Ex13.ncp.local> Message-ID: <87tv641o1n.wl-levitte@openssl.org> On Fri, 13 Dec 2019 08:58:27 +0100, Dr. Matthias St. Pierre wrote: > > > > On Thu, 12 Dec 2019 22:31:10 +0100, > > Dr Paul Dale wrote: > > > > > > A red blocker along the lines of: "Triviality Unconfirmed". One of > > > the reviewers needs to remove this before the PR can be merged. > > > > > > It's in our face, it prevent accidental merges and its low overhead. > > > > I still think simply adding the label should be sufficient. I dunno > > about you, but I look at labels all the time, for all sorts of > > reasons, and one saying [cla: trivial] would certainly attract my > > attention. > > > > Let's make it bright red-orange, that'll catch anyone's eye (even mine) > > > > Also, removing that label will rapidly be annoying as soon as someone > > closes and re-opens a PR... or whatever other action that triggers > > the "pull_request" event (and there's a lot that does that... our > > script is being kept busy!). > > > > Cheers, > > Richard > > > This seems to be implied already by my last proposal, with just one color changed: ;-) Yes and no... you talked about addrev, which should not be affected by this. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Dec 13 11:08:42 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 13 Dec 2019 12:08:42 +0100 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <39800FA9-D909-409B-8462-C2F3C977EACD@oracle.com> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> <87wob111h9.wl-levitte@openssl.org> <39800FA9-D909-409B-8462-C2F3C977EACD@oracle.com> Message-ID: <87sglo1o05.wl-levitte@openssl.org> clacheck modification coming up! Cheers, Richard On Fri, 13 Dec 2019 04:48:38 +0100, Dr Paul Dale wrote: > > > A better example of this problem: #10607. Both Paul and I approved it yesterday and I merged it > today without noticing until too late that it was tagged ?CLA: trivial? :( > I?ve not reverted it at this point but will if necessary. > > Let?s get the label in. > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > On 13 Dec 2019, at 11:02 am, Richard Levitte wrote: > > On Thu, 12 Dec 2019 22:31:10 +0100, > Dr Paul Dale wrote: > > A red blocker along the lines of: ?Triviality Unconfirmed?. One of > the reviewers needs to remove this before the PR can be merged. > > It?s in our face, it prevent accidental merges and its low overhead. > > I still think simply adding the label should be sufficient. I dunno > about you, but I look at labels all the time, for all sorts of > reasons, and one saying [cla: trivial] would certainly attract my > attention. > > Let's make it bright red-orange, that'll catch anyone's eye (even mine) > > Also, removing that label will rapidly be annoying as soon as someone > closes and re-opens a PR... or whatever other action that triggers > the "pull_request" event (and there's a lot that does that... our > script is being kept busy!). > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Dec 13 12:43:56 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 13 Dec 2019 13:43:56 +0100 Subject: Flaw in our process for dealing with trivial changes In-Reply-To: <87sglo1o05.wl-levitte@openssl.org> References: <3c626a7559604f88a54dcd75880aef67@Ex13.ncp.local> <20191212172433.GA770418@roeckx.be> <41DB919B-4DD2-451F-9269-620DF30C5B5C@oracle.com> <70686EC9-7182-471C-ACA8-B2F6222484CB@oracle.com> <87wob111h9.wl-levitte@openssl.org> <39800FA9-D909-409B-8462-C2F3C977EACD@oracle.com> <87sglo1o05.wl-levitte@openssl.org> Message-ID: <87r2181jlf.wl-levitte@openssl.org> https://github.com/openssl/tools/pull/49 Quite an exercise, I think my python-fu has increased significantly. I have *no* idea how to debug CGI stuff in a sensible way, suggestions welcome! Cheers, Richard On Fri, 13 Dec 2019 12:08:42 +0100, Richard Levitte wrote: > > clacheck modification coming up! > > Cheers, > Richard > > On Fri, 13 Dec 2019 04:48:38 +0100, > Dr Paul Dale wrote: > > > > > > A better example of this problem: #10607. Both Paul and I approved it yesterday and I merged it > > today without noticing until too late that it was tagged ?CLA: trivial? :( > > I?ve not reverted it at this point but will if necessary. > > > > Let?s get the label in. > > > > Pauli > > -- > > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > > Phone +61 7 3031 7217 > > Oracle Australia > > > > On 13 Dec 2019, at 11:02 am, Richard Levitte wrote: > > > > On Thu, 12 Dec 2019 22:31:10 +0100, > > Dr Paul Dale wrote: > > > > A red blocker along the lines of: ?Triviality Unconfirmed?. One of > > the reviewers needs to remove this before the PR can be merged. > > > > It?s in our face, it prevent accidental merges and its low overhead. > > > > I still think simply adding the label should be sufficient. I dunno > > about you, but I look at labels all the time, for all sorts of > > reasons, and one saying [cla: trivial] would certainly attract my > > attention. > > > > Let's make it bright red-orange, that'll catch anyone's eye (even mine) > > > > Also, removing that label will rapidly be annoying as soon as someone > > closes and re-opens a PR... or whatever other action that triggers > > the "pull_request" event (and there's a lot that does that... our > > script is being kept busy!). > > > > Cheers, > > Richard > > > > -- > > Richard Levitte levitte at openssl.org > > OpenSSL Project http://www.openssl.org/~levitte/ > > > > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Sun Dec 15 20:25:02 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 15 Dec 2019 20:25:02 +0000 Subject: AW: Build failures on master?! In-Reply-To: <20191122034340.GX32847@mit.edu> References: <74ffec7814564f6cb54afd69005fac2c@Ex13.ncp.local> <4e5c6cef-9328-e2b3-d5f6-bf1afa4ce3bb@openssl.org> <20191122034340.GX32847@mit.edu> Message-ID: <20c749d21b8b422bbda02cd9161efc12@Ex13.ncp.local> Gentle reminder: it's almost a month since a started this thread, but the external pyca and krb5 tests are still failing. Apart from complicating the review process, it also happens that people are noticing the failures and are hesitating to update to the current tip of master [1]. IMHO chronically failing tests should be deactivated and an issue created for fixing them. Matthias [1] https://github.com/openssl/openssl/issues/9866#issuecomment-565714221 From matt at openssl.org Mon Dec 16 11:23:39 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Dec 2019 11:23:39 +0000 Subject: OTC Message-ID: <9080522c-f306-e804-57e7-892d0088eb0f@openssl.org> The changes to the project bylaws to introduce the OTC concept have now been approved, and the relevant updates pushed to the website. A few of our other policies need a bit of adjustment to reflect the new by-laws. Please take a look at: https://github.com/openssl/web/pull/146 We'll need a new vote to make these changes, so please provide any feedback asap so we can press ahead with that. Matt From matt at openssl.org Tue Dec 17 14:54:51 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Dec 2019 14:54:51 +0000 Subject: OTC In-Reply-To: <9080522c-f306-e804-57e7-892d0088eb0f@openssl.org> References: <9080522c-f306-e804-57e7-892d0088eb0f@openssl.org> Message-ID: <62d5f30c-c7cf-f0a5-d88d-f63eeee32b84@openssl.org> On 16/12/2019 11:23, Matt Caswell wrote: > The changes to the project bylaws to introduce the OTC concept have now > been approved, and the relevant updates pushed to the website. A few of > our other policies need a bit of adjustment to reflect the new by-laws. > Please take a look at: > > https://github.com/openssl/web/pull/146 > > We'll need a new vote to make these changes, so please provide any > feedback asap so we can press ahead with that. Before I start the vote the proposed wording will be: topic: Update our project policies to incorporate the OTC as per the text in https://github.com/openssl/web/pull/146 (as of commit f43235924ab) Matt From matt at openssl.org Tue Dec 17 23:45:45 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Dec 2019 23:45:45 +0000 Subject: Forthcoming OpenSSL release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.0.2u This release will be made available on Friday 20th December 2019 between 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551 previously announced here: https://www.openssl.org/news/secadv/20191206.txt Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html This is expected to be the last 1.0.2 release before its End Of Life date on 31st December 2019. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl35aKkACgkQ2cTSbQ5g RJFTrQgAs5QMVDvkcEaSqKCKxYqTRaFlBCevtyEV/GaMdhWBEwGDsRfn+8jDSD20 i+UbtL6ymCf7xWrIFHbZaY4E/vyT1UhxkBYXj9DCS02eMRqwy7ileWxqs3xZ2Tiq vqCd+PR13hUdfnOZ62P8Uly9MaR7mTnf+bdJ1vvfOMI6DaUy1HqGghI9YHVwuwqE p6TR/jSCp64BpdsWSNKFTIwvd5u/LkpApO2ngLa5pB8BfUFPwu00ekYNtyb5qrya Gu3dIqJrirPl5ePaci/SC2lkjT2LjKcxIbXn1/rXN1WtsCItV9ztBdrjJvt/rbGM r8O+JOLIa0jEDAgC6fwgmeB7ryNY1w== =PqVo -----END PGP SIGNATURE----- From openssl at openssl.org Fri Dec 20 13:38:24 2019 From: openssl at openssl.org (OpenSSL) Date: Fri, 20 Dec 2019 13:38:24 +0000 Subject: OpenSSL version 1.0.2u published Message-ID: <20191220133824.GA10996@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.0.2u released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2u of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2u is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2u.tar.gz Size: 5355412 SHA1 checksum: 740916d79ab0d209d2775277b1c6c3ec2f6502b2 SHA256 checksum: ecd0c6ffb493dd06707d38b14bb4d8c2288bb7033735606569d8f90f89669d16 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2u.tar.gz openssl sha256 openssl-1.0.2u.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl38yAQACgkQ2cTSbQ5g RJHhkggAgL/QJ1zRY8yppCnf9zT1h3DW6t6nHC+n01GV5Fu6L4lvJqmJEtR+Vr5l u/z+kNDWdeTdic73MAdD9RO/k+sraZ13kAaj5VaQ7Sn16LIok0cQl09Q0yVYaXlC aEVcQ3RUcOneqI+sMLlpIWE26tMCn9MvNmuFNmyOHvYDotJbHQc379Qt6qoYmqHd Hn9vJrIAgjtuwtb2InA5Y29788dwQPXS9qPOWWN/xMOq2t4dSM43vvwrC2jgyTtR tT/l/FZQuu8Y1oVKwuHB43tDM8Gnvpot9DwSxXSxBPcSKxNpKVqvyNUrYohYaruB a6I9lBE7rbRojDiAvg9nUF3PTG0O/w== =IOW8 -----END PGP SIGNATURE----- From kaduk at mit.edu Sat Dec 21 18:38:57 2019 From: kaduk at mit.edu (Benjamin Kaduk) Date: Sat, 21 Dec 2019 10:38:57 -0800 Subject: Build failures on master?! In-Reply-To: <20c749d21b8b422bbda02cd9161efc12@Ex13.ncp.local> References: <74ffec7814564f6cb54afd69005fac2c@Ex13.ncp.local> <4e5c6cef-9328-e2b3-d5f6-bf1afa4ce3bb@openssl.org> <20191122034340.GX32847@mit.edu> <20c749d21b8b422bbda02cd9161efc12@Ex13.ncp.local> Message-ID: <20191221183857.GS35479@kduck.mit.edu> On Sun, Dec 15, 2019 at 08:25:02PM +0000, Dr. Matthias St. Pierre wrote: > 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 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&utm_source=github_status succeeding (as well as my local build with the krb5 tests). Are the external tests still failing? Thanks, Ben From Matthias.St.Pierre at ncp-e.com Sun Dec 22 22:26:34 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 22 Dec 2019 22:26:34 +0000 Subject: Build failures on master?! In-Reply-To: <20191221183857.GS35479@kduck.mit.edu> References: <74ffec7814564f6cb54afd69005fac2c@Ex13.ncp.local> <4e5c6cef-9328-e2b3-d5f6-bf1afa4ce3bb@openssl.org> <20191122034340.GX32847@mit.edu> <20c749d21b8b422bbda02cd9161efc12@Ex13.ncp.local> <20191221183857.GS35479@kduck.mit.edu> Message-ID: <684508fc48554c6f9d151ccc7cbf0135@Ex13.ncp.local> > 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&utm_source=github_status > succeeding (as well as my local build with the krb5 tests). Are the > external tests still failing? I don't really understand what's going on, but it looks like job 19 fails intermittently: Job #30814.19 (the one you pointet out) succeeded, but #30827.19 failed. And afterwards #30846.19 succeeded again. - #30814.19 (two days ago): SUCCEEDED https://travis-ci.org/openssl/openssl/jobs/628003784?utm_medium=notification&utm_source=github_status - #30827.19 (23 hours ago): FAILED https://travis-ci.org/openssl/openssl/jobs/628205488?utm_medium=notification&utm_source=github_status Test Summary Report ------------------- 95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=3, Tests=3, 225 wallclock secs ( 0.67 usr 0.05 sys + 112.06 cusr 29.38 csys = 142.16 CPU) Result: FAIL Makefile:2893: recipe for target '_tests' failed make[1]: *** [_tests] Error 1 make[1]: Leaving directory '/home/travis/build/openssl/openssl' Makefile:2891: recipe for target 'tests' failed make: *** [tests] Error 2 ** FAILED -- MAKE TEST - #30846.19 (2 hours ago) SUCCEEDED https://travis-ci.org/openssl/openssl/jobs/628466771?utm_medium=notification&utm_source=github_status There are other tests failing, too. If you look at the build history, you will hardly see any successful builds on master and 1.1.1. https://travis-ci.org/openssl/openssl/builds?utm_medium=notification&utm_source=github_status Matthias From matt at openssl.org Mon Dec 23 12:48:13 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 23 Dec 2019 12:48:13 +0000 Subject: Build failures on master?! In-Reply-To: <684508fc48554c6f9d151ccc7cbf0135@Ex13.ncp.local> References: <74ffec7814564f6cb54afd69005fac2c@Ex13.ncp.local> <4e5c6cef-9328-e2b3-d5f6-bf1afa4ce3bb@openssl.org> <20191122034340.GX32847@mit.edu> <20c749d21b8b422bbda02cd9161efc12@Ex13.ncp.local> <20191221183857.GS35479@kduck.mit.edu> <684508fc48554c6f9d151ccc7cbf0135@Ex13.ncp.local> Message-ID: <94e34dba-82c7-b8ee-3a39-08e56e88675e@openssl.org> On 22/12/2019 22:26, Dr. Matthias St. Pierre wrote: >> 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&utm_source=github_status >> succeeding (as well as my local build with the krb5 tests). Are the >> external tests still failing? > > I don't really understand what's going on, but it looks like job 19 fails intermittently: Job #30814.19 (the one you > pointet out) succeeded, but #30827.19 failed. And afterwards #30846.19 succeeded again. > > - #30814.19 (two days ago): SUCCEEDED > https://travis-ci.org/openssl/openssl/jobs/628003784?utm_medium=notification&utm_source=github_status > > > - #30827.19 (23 hours ago): FAILED > https://travis-ci.org/openssl/openssl/jobs/628205488?utm_medium=notification&utm_source=github_status > > Test Summary Report > ------------------- > 95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 AFAICT the krb5 test failure on master seems to be environmental. We get this failure: make[5]: Entering directory '/home/travis/build/openssl/openssl/krb5/src/lib/rpc/unit-test' rm -f krb5cc_rpc_test_* ../../../kadmin/testing/scripts/env-setup.sh ../../../kadmin/testing/scripts/start_servers RPC_TEST_SRVTAB=/tmp/rpc_test_v5srvtab.$$ ; export RPC_TEST_SRVTAB ; \ trap "echo Failed, cleaning up... ; rm -f $RPC_TEST_SRVTAB ; ../../../kadmin/testing/scripts/env-setup.sh ../../../kadmin/testing/scripts/stop_servers ; trap '' 0 ; exit 1" 0 1 2 3 14 15 ; \ if ../../../kadmin/testing/scripts/env-setup.sh \ runtest --debug --srcdir . --host x86_64-pc-linux-gnu SERVER=./server CLIENT=./client \ KINIT=../../../clients/kinit/kinit \ KDESTROY=../../../clients/kdestroy/kdestroy \ PRIOCNTL_HACK=0 VALGRIND="" \ PASS="tcp" --tool rpc_test ; \ then \ echo Cleaning up... ; \ rm -f $RPC_TEST_SRVTAB krb5cc_rpc_test_* ; \ ../../../kadmin/testing/scripts/env-setup.sh ../../../kadmin/testing/scripts/stop_servers ; \ trap 0 ; exit 0 ; \ else exit 1 ; fi WARNING: Couldn't find tool init file Test Run By travis on Thu Dec 19 08:07:45 2019 Native configuration is x86_64-pc-linux-gnu === rpc_test tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using ./config/unix.exp as tool-and-target-specific interface file. TOP=/home/travis/build/openssl/openssl/krb5/src/kadmin Running pass `tcp' ... Running ./rpc_test.0/expire.exp ... FAIL: tcp: expire: client 1: unexpected return status 2, should be 0. FAIL: tcp: expire: client 2: unexpected return status 2, should be 0. FAIL: tcp: expire: client 3: unexpected return status 2, should be 0. Running ./rpc_test.0/fullrun.exp ... FAIL: tcp: full run: client fullrun: unexpected return status 2, should be 0. FAIL: tcp: fullrun: echo test: expected 11 dots, got 1 FAIL: tcp: fullrun: expected four bad verifiers, got 0 Running ./rpc_test.0/gsserr.exp ... FAIL: tcp: gss err: timeout waiting for server output === rpc_test Summary === # of expected passes 2 # of unexpected failures 7 ./client version ./server version Failed, cleaning up... Makefile:678: recipe for target 'unit-test-body' failed However, if I run the same test locally with the same config options the krb5 tests pass. This is the equivalent section of the log: make[5]: Entering directory '/home/matt/dev/openssl-write/krb5/src/lib/rpc/unit-test' rm -f krb5cc_rpc_test_* ../../../kadmin/testing/scripts/env-setup.sh ../../../kadmin/testing/scripts/start_servers RPC_TEST_SRVTAB=/tmp/rpc_test_v5srvtab.$$ ; export RPC_TEST_SRVTAB ; \ trap "echo Failed, cleaning up... ; rm -f $RPC_TEST_SRVTAB ; ../../../kadmin/testing/scripts/env-setup.sh ../../../kadmin/testing/scripts/stop_servers ; trap '' 0 ; exit 1" 0 1 2 3 14 15 ; \ if ../../../kadmin/testing/scripts/env-setup.sh \ runtest --debug --srcdir . --host x86_64-pc-linux-gnu SERVER=./server CLIENT=./client \ KINIT=../../../clients/kinit/kinit \ KDESTROY=../../../clients/kdestroy/kdestroy \ PRIOCNTL_HACK=0 VALGRIND="" \ PASS="tcp" --tool rpc_test ; \ then \ echo Cleaning up... ; \ rm -f $RPC_TEST_SRVTAB krb5cc_rpc_test_* ; \ ../../../kadmin/testing/scripts/env-setup.sh ../../../kadmin/testing/scripts/stop_servers ; \ trap 0 ; exit 0 ; \ else exit 1 ; fi WARNING: Couldn't find tool init file Test run by matt on Mon Dec 23 12:26:44 2019 Native configuration is x86_64-pc-linux-gnu === rpc_test tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using ./config/unix.exp as tool-and-target-specific interface file. TOP=/home/matt/dev/openssl-write/krb5/src/kadmin Running pass `tcp' ... Running ./rpc_test.0/expire.exp ... Running ./rpc_test.0/fullrun.exp ... Running ./rpc_test.0/gsserr.exp ... === rpc_test Summary === # of expected passes 8 ./client version ./server version Cleaning up... make[5]: Leaving directory '/home/matt/dev/openssl-write/krb5/src/lib/rpc/unit-test' > Non-zero exit status: 1 > 95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > Files=3, Tests=3, 225 wallclock secs ( 0.67 usr 0.05 sys + 112.06 cusr 29.38 csys = 142.16 CPU) > Result: FAIL > Makefile:2893: recipe for target '_tests' failed > make[1]: *** [_tests] Error 1 > make[1]: Leaving directory '/home/travis/build/openssl/openssl' > Makefile:2891: recipe for target 'tests' failed > make: *** [tests] Error 2 > ** FAILED -- MAKE TEST > > - #30846.19 (2 hours ago) SUCCEEDED > https://travis-ci.org/openssl/openssl/jobs/628466771?utm_medium=notification&utm_source=github_status > > There are other tests failing, too. If you look at the build history, you will hardly see any successful builds on > master and 1.1.1. > > https://travis-ci.org/openssl/openssl/builds?utm_medium=notification&utm_source=github_status > > > Matthias > > > From levitte at openssl.org Sat Dec 28 11:04:17 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 28 Dec 2019 12:04:17 +0100 Subject: Late Monthly Status Report (August 2019) Message-ID: <87k16glnim.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development - Configurations/unix-Makefile.tmpl: Don't clean away dotted files (PR openssl/openssl#9573) - Add text to OSSL_PARAM constructors (PR openssl/openssl#9303) - Rework EVP_MD support, enhance existing functions (PR openssl/openssl#9391) - Enhance param handling with param type descriptors (PR openssl/openssl#9576) - Rename provider and core get_param_types functions (PR openssl/openssl#9591) - Move all MACs to the providers (PR openssl/openssl#8877) - Rename ctx_{get,set}_params to {get,set}_ctx_params (PR openssl/openssl#9612) - Windows UWP builds: determine automatically if asm should be disabled (PR openssl/openssl#9440) - Untangle / retangle opensslv.h, openssslconf.h and macros.h (PR openssl/openssl#9626) - Use macros internally for algorithm names (PR openssl/openssl#9635) - Modify ossl_method_store_add() to accept an OSSL_PROVIDER and check for it (PR openssl/openssl#9650) - Configure: Allow 'DEFINE[]=def' crypto/bn/build.info: define OPENSL_IA32_SSE2 globally when needed (PR openssl/openssl#9679) - Clean up MAC implementations (PR openssl/openssl#9667) - testing: set OPENSSL_MODULES to the providers directory by default (PR openssl/openssl#9618) - OPENSSL_info(): add the item OPENSSL_INFO_SEED_SOURCE and use it (PR openssl/openssl#9689) - openssl provider: New sub-command, for provider discovery (PR openssl/openssl#9697) - [not yet merged] When building of modules is disabled, build the legacy provider into libcrypto (PR openssl/openssl#9637) * System administration - Installed and set up internal github EE instance - Fixed letsencrypt issues with our gitlab instance - Modernized our apache config template usage -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Dec 28 11:05:41 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 28 Dec 2019 12:05:41 +0100 Subject: Late Monthly Status Report (September 2019) Message-ID: <87imm0lnga.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development - Rework the documentation of our individual MAC implementations (PR openssl/openssl#9713) - Refactor how KEYMGMT methods get associated with other methods (PR openssl/openssl#9678) - test/errtest.c: more conditions for checking __FILE__ and __LINE__ (PR openssl/openssl#9755) - New functions EVP_MD_free() and EVP_CIPHER_free() (PR openssl/openssl#9758) - Move libapps.a source to apps/lib (PR openssl/openssl#9723) - Move KDFs and PRFs into providers (PR openssl/openssl#9662) - Rework the perl fallback functionality (PR openssl/openssl#9826) - test/evp_test.c: try fetching algorithms (PR openssl/openssl#9121) - doc/man3/OSSL_PARAM.pod: add details about multiple elements with same key (PR openssl/openssl#9741) - util/perl/OpenSSL/Test.pm: Disable stdout/stderr redirection on non-verbosity (PR openssl/openssl#9862) - Rework test/run_tests.pl to support selective verbosity and TAP copy (PR openssl/openssl#9862) - ERR fixups and additions (PR openssl/openssl#9765) - Refactor configdata.pm to be generated by template (PR openssl/openssl#9693) - Deprecate the public definition of ERR_STATE (PR openssl/openssl#9462) - Unify assembler scripts (PR openssl/openssl#9884) - crypto/bn/build.info: Correct use of SSE2 definition (PR openssl/openssl#9879) - Refactor TLS1-PRF to create the MAC contexts early (PR openssl/openssl#9930) - Use name identity instead of name in diverse methods (PR openssl/openssl#9897) - Refactor TLS-PRF's kdf_tls1_prf_mkmacctx() to a provider utility (PR openssl/openssl#9946) - Refactor SSKDF to create the MAC contexts early (PR openssl/openssl#9946) - include/openssl/macros.h: Rework OPENSSL_FUNC for div C standards (PR openssl/openssl#9913) - include/openssl/macros.h: better OPENSSL_FUNC fallback (PR openssl/openssl#9976) - Rework cipher / digest fetching for legacy nids with multiple name support (PR openssl/openssl#9969) - Configure, build.info: make it possible to use variables in indexes (PR openssl/openssl#9637) - When building of modules is disabled, build the legacy provider into libcrypto (PR openssl/openssl#9637) - OSSL_PARAM.pod: document the mechanism to figure out buffer sizes (PR openssl/openssl#10025) - Make doc/man7/ and doc/internal/man3/ conform with man-pages(7) (PR openssl/openssl#10034) - Make relevant tests more sensitive to 'no-fips' (PR openssl/openssl#10047) - Make ASYNC manuals conform with man-pages(7) (PR openssl/openssl#10043) - [not yet merged] Adapt EVP_CIPHER_{param_to_asn1,asn1_to_param} for use with provider. (PR openssl/openssl#10008) - [not yet merged] Replumbing: pre-populate the EVP namemap with commonly known names (PR openssl/openssl#8984) - [not yet merged] Display multiple names (PR openssl/openssl#9979) - [unpublished] Continued work on flexible installation commands for Makefiles - [not yet merged] X509_LOOKUP_store: new X509_LOOKUP_METHOD that works by OSSL_STORE URI (PR openssl/openssl#8442) * System administration - Installed and set up internal github EE instance - Fixed letsencrypt issues with our gitlab instance - Modernized our apache config template usage -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Dec 28 11:06:31 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 28 Dec 2019 12:06:31 +0100 Subject: Late Monthly Status Report (October 2019) Message-ID: <87h81klnew.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Meetings, workshops, etc - Attended the OMC f2f, and committers f2f meetings in Nuremburg * Development - Make ASN1 manuals conform with man-pages(7) (PR openssl/openssl#10042) - Make manuals with TYPE conform with man-pages(7) (PR openssl/openssl#10041) - Adapt EVP_CIPHER_{param_to_asn1,asn1_to_param} for use with provider. (PR openssl/openssl#10008) - util/find-doc-nits: more precise option and function name checker (PR openssl/openssl#10073) - Replumbing: make it possible for providers to specify multiple names (PR openssl/openssl#8985) - Move all SHA digests completely to the default provider (PR openssl/openssl#10059) - Move MD5-SHA1 digest completely to the default provider (PR openssl/openssl#9076) - EVP_{CIPHER,MD}_CTX_ctrl(): make sure to return 0 or 1 (PR openssl/openssl#10108) - Add documentation for PEM_{read,write}_bio_Parameters() (PR openssl/openssl#10113) - More doc/man1 fixes (PR openssl/openssl#10065) - Document build.info syntax internally (PR openssl/openssl#10121, openssl/openssl#10148) - Reorganize providers, which also involved: Configure: rework build.info grammar and attributes Configure: Implement attributes for DEPEND[xxx] Configurations/common.tmpl: Rework dependency resolution Build files: Make it possible to source libraries into other libraries - POD: stop abusing comment (PR openssl/openssl#10048) - Fix EVP_Cipher() for provided cipher implementations (PR openssl/openssl#10137) - KDF: clean away old EVP_KDF declarations (PR openssl/openssl#10170) - Restore MD5-SHA1 in legacy method database (PR openssl/openssl#10176) - Building: Add modules with DEPENDs to GENERATEd files (PR openssl/openssl#10162) - Move MD2, MD4 and MD5 digests completely to the providers (PR openssl/openssl#10164) - Add EVP_PKEY_CTX_new_provided() (PR openssl/openssl#10184) - EVP_{CIPHER,MD}_CTX_ctrl(): make extra sure to return 0 or 1 (PR openssl/openssl#10163) - Display multiple names (PR openssl/openssl#9979) - Configure: break long lines in build files (PR openssl/openssl#8990) - KEYMGMT: export/import domain parameters (PR openssl/openssl#10169) - Export / import RSA to / from provider (PR openssl/openssl#10190) - Move BLAKE2 digests completely to the default provider (PR openssl/openssl#9075) - Centralize version data (PR openssl/openssl#10205) - Doc for the added internal RSA functions (PR openssl/openssl#10206) - windows-makefile.tmpl: Convert all /I and /D to -I and -D (PR openssl/openssl#10222) - crypto/s390xcap.c: Add guards around the GETAUXVAL checks (PR openssl/openssl#9892) - crypto/evp/evp_fetch.c: Make it more prominent that these functions are EVP (PR openssl/openssl#10257) - evp_pkey_ctx_free_old_ops(): Make sure to assign NULL to freed pointers (PR openssl/openssl#10292) - [not yet merged] Replumbing: pre-populate the EVP namemap with commonly known names (PR openssl/openssl#8984) - [1.1.1 only] Define AESNI_ASM if AESNI assembler is included, and use it (PR openssl/openssl#10080) - [not yet merged] Implement domparam and key generation (PR openssl/openssl#10289) - [not yet merged] Template fipsprov (PR openssl/openssl#10124) - [not yet merged] Add EVP functionality to create domain params and keys by user data (PR openssl/openssl#10187) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Dec 28 11:14:33 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 28 Dec 2019 12:14:33 +0100 Subject: Late Monthly Status Report (September 2019) Message-ID: <87eewoln1i.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development - Rework the documentation of our individual MAC implementations (PR openssl/openssl#9713) - Refactor how KEYMGMT methods get associated with other methods (PR openssl/openssl#9678) - test/errtest.c: more conditions for checking __FILE__ and __LINE__ (PR openssl/openssl#9755) - New functions EVP_MD_free() and EVP_CIPHER_free() (PR openssl/openssl#9758) - Move libapps.a source to apps/lib (PR openssl/openssl#9723) - Move KDFs and PRFs into providers (PR openssl/openssl#9662) - Rework the perl fallback functionality (PR openssl/openssl#9826) - test/evp_test.c: try fetching algorithms (PR openssl/openssl#9121) - doc/man3/OSSL_PARAM.pod: add details about multiple elements with same key (PR openssl/openssl#9741) - util/perl/OpenSSL/Test.pm: Disable stdout/stderr redirection on non-verbosity (PR openssl/openssl#9862) - Rework test/run_tests.pl to support selective verbosity and TAP copy (PR openssl/openssl#9862) - ERR fixups and additions (PR openssl/openssl#9765) - Refactor configdata.pm to be generated by template (PR openssl/openssl#9693) - Deprecate the public definition of ERR_STATE (PR openssl/openssl#9462) - Unify assembler scripts (PR openssl/openssl#9884) - crypto/bn/build.info: Correct use of SSE2 definition (PR openssl/openssl#9879) - Refactor TLS1-PRF to create the MAC contexts early (PR openssl/openssl#9930) - Use name identity instead of name in diverse methods (PR openssl/openssl#9897) - Refactor TLS-PRF's kdf_tls1_prf_mkmacctx() to a provider utility (PR openssl/openssl#9946) - Refactor SSKDF to create the MAC contexts early (PR openssl/openssl#9946) - include/openssl/macros.h: Rework OPENSSL_FUNC for div C standards (PR openssl/openssl#9913) - include/openssl/macros.h: better OPENSSL_FUNC fallback (PR openssl/openssl#9976) - Rework cipher / digest fetching for legacy nids with multiple name support (PR openssl/openssl#9969) - Configure, build.info: make it possible to use variables in indexes (PR openssl/openssl#9637) - When building of modules is disabled, build the legacy provider into libcrypto (PR openssl/openssl#9637) - OSSL_PARAM.pod: document the mechanism to figure out buffer sizes (PR openssl/openssl#10025) - Make doc/man7/ and doc/internal/man3/ conform with man-pages(7) (PR openssl/openssl#10034) - Make relevant tests more sensitive to 'no-fips' (PR openssl/openssl#10047) - Make ASYNC manuals conform with man-pages(7) (PR openssl/openssl#10043) - [not yet merged] Adapt EVP_CIPHER_{param_to_asn1,asn1_to_param} for use with provider. (PR openssl/openssl#10008) - [not yet merged] Replumbing: pre-populate the EVP namemap with commonly known names (PR openssl/openssl#8984) - [not yet merged] Display multiple names (PR openssl/openssl#9979) - [unpublished] Continued work on flexible installation commands for Makefiles - [not yet merged] X509_LOOKUP_store: new X509_LOOKUP_METHOD that works by OSSL_STORE URI (PR openssl/openssl#8442) * System administration - Installed and set up internal github EE instance - Fixed letsencrypt issues with our gitlab instance - Modernized our apache config template usage -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Dec 28 11:07:25 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 28 Dec 2019 12:07:25 +0100 Subject: Late Monthly Status Report (November 2019) Message-ID: <87fth4lnde.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Meetings, workshops, etc - Worked through a significant amount of older issues together with Matt Caswell, primarly to triage them, but in some cases to also review them. We will continued with the seriously aged issues in 2020. * Development - BIO_s_connect: add an error state and use it (PR openssl/openssl#7630) - Configure: Make --strict-warnings meaningful with MSVC cl (PR openssl/openssl#10287) - VMS: Added new method to gather entropy on VMS, based on SYS$GET_ENTROPY. (PR openssl/openssl#8926) - Fix OSSL_PARAM_set_BN() to fill the given buffer correctly. (PR openssl/openssl#10326) - Make EVP_PKEY_CTX initialization more precise (PR openssl/openssl#10308) - OSSL_STORE: constify the criterion parameter a bit more (PR openssl/openssl#8442) - X509_LOOKUP_store: new X509_LOOKUP_METHOD that works by OSSL_STORE URI (PR openssl/openssl#8442) - EVP: Make the KEYEXCH implementation leaner (PR openssl/openssl#10305) - EVP: Make the SIGNATURE implementation leaner (PR openssl/openssl#10303) - Rework ordinals (PR openssl/openssl#10348) - Change the logic and behaviour surrounding '--api' and 'no-deprecated' (PR openssl/openssl#10364) - Add EVP functionality to create domain params and keys by user data (PR openssl/openssl#10187) - Refactor PEM_read_bio_{PrivateKey,Parameters,DHparams} (PR openssl/openssl#2746) - Cleanup include/openssl/opensslv.h.in (PR openssl/openssl#10218) - Configuration: make Solaris builds with gcc recognise GNU ld (PR openssl/openssl#8548) - Final cleanup after move to leaner EVP_PKEY methods (PR openssl/openssl#10309) - Reinstate the KDF error macros (PR openssl/openssl#10368) - Add a .pragma directive for configuration files (PR openssl/openssl#8882) - [master] SSL: Document SSL_add_{file,dir,store}_cert_subjects_to_stack() (PR openssl/openssl#10402) - [1.1.1] SSL: Document SSL_add_{file,dir}_cert_subjects_to_stack() (PR openssl/openssl#10403) - CORE: Add a generic callback function type (PR openssl/openssl#10412) - CORE & PROV: make export of key data leaner through callback (PR openssl/openssl#10414) - PEM: constify PEM_write_ routines (PR openssl/openssl#10452) - Replumbing: pre-populate the EVP namemap with commonly known names (PR openssl/openssl#8984) - UI_UTIL_wrap_read_pem_callback(): when |cb| is NULL, use PEM_def_callback (PR openssl/openssl#10447) - doc/man7/proxy-certificates.pod: New guide for proxy certificates (PR openssl/openssl#10507) - configdata.pm.in, util/dofile.pl: load 'platform' unconditionally (PR openssl/openssl#10514) - Generate docs at build time instead of install time (PR openssl/openssl#6236) - SERIALIZER: New API for serialization of objects through providers (PR openssl/openssl#10394) - [1.1.1 only] i2b_PVK(): Use Encrypt, not Decrypt (PR openssl/openssl#10521) - [not yet merged] Implement domparam and key generation (PR openssl/openssl#10289) - [not yet merged] apps: Switch to using OSSL_STORE for loading keys, certs, ... (PR openssl/openssl#7390) - [unpublished] Support serializers in 'openssl provider' and 'openssl list' -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Dec 28 11:55:07 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 28 Dec 2019 12:55:07 +0100 Subject: monthly Status Report (December 2019) Message-ID: <877e2gll5w.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Meetings, workshops, etc - Continued work through older issues together with Matt Caswell, primarly to triage them, but in some cases to also review them. We will continued with the seriously aged issues in 2020. * Development - util/mkerr.pl: don't stop reading conserved symbols from the state file (PR openssl/openssl#10549) - Use leak sanitizer instead of internal mdebug to check for memory leaks (PR openssl/openssl#9294) - Disable devcryptoeng on newer OpenBSD versions (PR openssl/openssl#10566) - Move providers/common/{ciphers,digests}/* to providers/implementations (PR openssl/openssl#10564) - PROV: Move AES_CCM and AES_GCM specialisation away from common cipher header (PR openssl/openssl#10606) - Add better support for using deprecated symbols internally (PR openssl/openssl#10608) - EVP: make it possible to init EVP_PKEY_CTX with provided EVP_PKEY (PR openssl/openssl#10618) - BIO: Add BIO_f_prefix(), a text line prefixing filter (PR openssl/openssl#10531) - CRYPTO: split cipher_platform.h into algorithm specific headers (PR openssl/openssl#10662) - util/find-doc-nits: Better checking of missing documentation (PR openssl/openssl#10621) - util/find-doc-nits: when loading "missing" files, check if documented (PR openssl/openssl#10683) - Configurations/windows-makefile.tmpl: HTMLDOCS are files, not directories (PR openssl/openssl#10555) - [1.1.1] Disable devcryptoeng on newer OpenBSD versions (PR openssl/openssl#10565) - [not yet merged] Implement domparam and key generation (PR openssl/openssl#10289) - [not yet merged] apps: Switch to using OSSL_STORE for loading keys, certs, ... (PR openssl/openssl#7390) - [not yet merged] PROV: add RSA signature implementation (PR openssl/openssl#10557) - [not yet merged] CORE & EVP: Adapt KEYEXCH, SIGNATURE and ASYM_CIPHER to handle key types better (PR openssl/openssl#10647) - [unpublished] Support serializers in 'openssl provider' and 'openssl list' - [unpublished] Experiments with builbbot-travis * Administration - Set up initial OTC memberships - Form gitolite @otc group - Create the public OTC repo - Block pushes to branches on the main repo that are now EOL (1.1.0 and 1.0.2) - Added xymon entry for internal github instance - Set up infrastructure for premium customers -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Sun Dec 29 17:28:35 2019 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 29 Dec 2019 17:28:35 +0000 Subject: OTC membership? Message-ID: <4E1F07CC-1597-4319-BB59-253226D99C3F@akamai.com> The list of committers is at https://www.openssl.org/community/committers.html The list of OMC members is at https://www.openssl.org/community/omc.html Will there be a list of OTC members also in the community tab soon? Or a mark in the committers table? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sun Dec 29 22:30:12 2019 From: matt at openssl.org (Matt Caswell) Date: Sun, 29 Dec 2019 22:30:12 +0000 Subject: OTC membership? In-Reply-To: <4E1F07CC-1597-4319-BB59-253226D99C3F@akamai.com> References: <4E1F07CC-1597-4319-BB59-253226D99C3F@akamai.com> Message-ID: Yes there will be a list. But I don't expect it to happen until Richard is back from vacation. Matt On 29/12/2019 17:28, Salz, Rich wrote: > The list of committers is at > https://www.openssl.org/community/committers.html > > The list of OMC members is at https://www.openssl.org/community/omc.html > > Will there be a list of OTC members also in the community tab soon?? Or > a mark in the committers table? > > ? > > ? >