Export OPENSSL_str[n]casecmp as public API functions in 3.0
Topic: We export OPENSSL_str[n]casecmp as public API functions in 3.0 Proposed by: Dmitry Issue link: https://github.com/openssl/openssl/issues/18039, https://github.com/openssl/openssl/issues/18069, https://github.com/openssl/openssl/issues/18103 Public: yes Opened: 2022-04-19 Closed: Accepted: yes/no (for: ?, against: ?, abstained: ?, not voted: ?) Vote link: https://github.com/openssl/technical-policies/issues/44 Dmitry [+1] Matt [ ] Pauli [ ] Tim[ ] Richard[ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [ ] Nicola [+1] -- SY, Dmitry Belyavsky
Re: OTC VOTE: Accept Policy change process proposal
+1 On Mon, Nov 1, 2021 at 11:23 AM Tomas Mraz wrote: > topic: Accept openssl/technical-policies PR#1 - the policy change > process proposal as of commit 3bccdf6. This will become an official OTC > policy. > > comment: This will implement the formal policy change process so we can > introduce and amend further policies as set by OTC via a public > process. > > Proposed by Tomáš Mráz > Public: yes > opened: 2021-11-01 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > >Dmitry [ ] >Matt [ ] >Pauli [ ] >Tim[ ] >Richard[ ] >Shane [ ] >Tomas [+1] >Kurt [ ] >Matthias [ ] >Nicola [ ] > > > > -- SY, Dmitry Belyavsky
Re: Agenda for the next OTC meeting
I'd like to add 2 more items to the agenda: 1. Do we want to restart the GH items review in this or that form? 2. Can we do anything with file load performance regression On Tue, Oct 12, 2021 at 2:23 PM Matt Caswell wrote: > My proposed agenda for the next OTC meeting (2021-10-19): > > 1) Nominate a minute taker and confirm agenda > 2) Review policy process strawman > 3) PR #16725 > 4) Agree agenda for next meeting > 5) AOB > > > Matt > > -- SY, Dmitry Belyavsky
Re: Blog post about FIPS submission
Hello Matt, The link https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-processmodules-in-process-list (You can see the official listing for the submission *here*) seems to be not working On Thu, Sep 23, 2021 at 9:31 PM Matt Caswell wrote: > FYI, please see my blog post about the OpenSSL 3 FIPS submission here: > > https://www.openssl.org/blog/blog/2021/09/22/OpenSSL3-fips-submission/ > > Matt > > -- SY, Dmitry Belyavsky
Re: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process
On Sun, Aug 29, 2021 at 1:36 PM Kurt Roeckx wrote: > On Tue, Aug 17, 2021 at 02:19:08PM +0100, Matt Caswell wrote: > > topic: Accept PR#16286 into 3.0 subject to the normal review process > > -1 > > Do we need some general policy for such changes after the 3.0 > release? > > I think we need some sort of definition of missing features. Some features (e.g. SRP) were deliberately excluded from 3.0, but I tend to treat all the other features available in 1.1.1 and missing in 3.0 as bugs. -- SY, Dmitry Belyavsky
Re: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process
+1 On Tue, Aug 17, 2021 at 3:19 PM Matt Caswell wrote: > topic: Accept PR#16286 into 3.0 subject to the normal review process > Proposed by Shane Lontis > Public: yes > opened: 2021-08-17 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > >Dmitry [ ] >Matt [-1] >Pauli [+1] >Tim[ 0] >Richard[+1] >Shane [+1] >Tomas [ ] >Kurt [ ] >Matthias [ ] >Nicola [+1] > -- SY, Dmitry Belyavsky
Re: New OTC Member
Dear Matt, dear colleagues, It's a great honor to become an OpenSSL Technical Committee member! I'll do my best to make the project better. On Fri, Jul 30, 2021 at 12:12 PM Matt Caswell wrote: > I am very pleased to be able to announce that Dmitry Belyavsky has > become the OpenSSL Technical Committee's latest member. > > Welcome Dmitry! > > Matt > -- SY, Dmitry Belyavsky
Re: Repository
Congratulations! On Thu, Jun 17, 2021 at 3:41 PM Matt Caswell wrote: > The repo is now thawed. > > OpenSSL 3.0 beta1 release is done! > > Matt > > > On 16/06/2021 15:48, Matt Caswell wrote: > > I've now merged all PRs that I'm aware of for the beta release. If you > > have an approved PR that you were expecting would be included and it > > hasn't been, then please point me at it. > > > > Thanks > > > > Matt > > > > > > On 16/06/2021 10:21, Dr Paul Dale wrote: > >> The repository is frozen in anticipation of the 3.0 beta release. > >> > >> Pauli > >> > -- SY, Dmitry Belyavsky
Re: Change of scenery
Congratulations! On Sun, Jan 31, 2021 at 10:27 PM Dr Paul Dale wrote: > Letting people know that I'm starting as an OpenSSL fellow today. > > I'm looking forward to working as part of the team and I'll be able to > fully devote my efforts to the benefit of the project. > > > Dr Paul Dale > > > > -- SY, Dmitry Belyavsky
Re: OSSL_PARAM behaviour for unknown keys
Dear Kurt, On Mon, Dec 14, 2020 at 10:10 PM Kurt Roeckx wrote: > On Mon, Dec 14, 2020 at 08:20:29PM +0100, Dmitry Belyavsky wrote: > > Dear Kurt, > > > > > > On Mon, Dec 14, 2020 at 3:59 PM Kurt Roeckx wrote: > > > > > Hi, > > > > > > doc/man3/OSSL_PARAM.pod current says: > > > Keys that a I or I doesn't recognise should > > > simply be ignored. That in itself isn't an error. > > > > > > The intention of that seems to be that you just pass all the data > > > you have, and that it takes data it needs. So you can pass it data > > > that it doesn't need because it's only used in case some other > parameter > > > has some specific value. For example, depending on the DRBG mode > > > (HMAC, CTR, HASH) you have different parameters, and you can just > > > pass all the parameters for all the modes. > > > > > > I think for behaviour for a setter is not something that we want, > > > it makes it complicated for applications to check that it will > > > behave properly. I think that in general, if the applications > > > wants to set something and you don't understand it, you should > > > return an error. This is about future proofing the API. For > > > instance, a new version supports a new mode to work in and that > > > needs a new parameter. If it's build against a version that knows > > > about it, but then runs against a version that doesn't know about > > > it, everything will appear to work, but be broken. If we return > > > an error, it will be clear that it's not supported. > > > > > > An alternative method of working is that the application first > > > needs to query that it's supported. And only if it's supported > > > it should call the function. But we don't have an API to query for > > > that. You might be able to ask for which keys you can set, but it > > > doesn't cover which values you can set. I hope we at least return > > > an error for a known key with an unknown value. But it's my > > > understanding that we currently don't always return all supported > > > keys, and that the supported keys can depend on one of the set > > > parameters. > > > > > > I suggest that we change the return value to indicate that all > > > parameters have been used or not. For instance return 1 in case > > > all used, return 2 in case not all used. > > > > > > > > From my GOST implementor's experience, the provider can get a lot of > > parameters. > > Some of them are supported, some of them are not. > > > > The particular provider is the only subsystem that knows which parameters > > are supported and which are necessary for the operations. > > > > So the caller can provide some unsupported parameters, some supported and > > some totally wrong for the provider. > > These are the cases that must be distinguishable on the caller side. > > If I understand you correctly, what you're saying is that it's > sometimes ok to ignore some parameters. For instance, if you try > to create an RSA object, and you pass it CRT parameters, and the > implementation doesn't do anything with them, it can ignore them > if it wants to. > > I would say that the provider should know what those parameters > mean, so that it's not an "unknown key", it just ignores them, > at which points it can say that it understands all the parameters. > > Some might argue that they don't want to use something that > doesn't make use of the CRT parameters, but then they probably > shouldn't be using that provider to begin with. > > > After that the provided EVP object should be either in a consistent state > > or not, assuming the upcoming operation. > > The object should always be in a consistent state. I would prefer > that in case of failure the object is not created (or modified). > Which brings us to some other open points about the API we have. We > should not introduce new APIs where you can modify the state of the > object, so it can not be in a non-consistent state. It's much more > simple to get things correct in that case. But as long as we have > to support old APIs where it can be modified, the prefered > consistent state is to not mofify the object on error. Some APIs make > this very hard, so the other acceptable state is that you can free > the object. With an API that doesn't allow modification, either > you get a complete object, or you get no object. > > I hope I've got a specific point of our disagreement. There are 2 variants of using OpenSSL. 1. Algorithm-agnostic. We can deal with mo
Re: OSSL_PARAM behaviour for unknown keys
Dear Kurt, On Mon, Dec 14, 2020 at 3:59 PM Kurt Roeckx wrote: > Hi, > > doc/man3/OSSL_PARAM.pod current says: > Keys that a I or I doesn't recognise should > simply be ignored. That in itself isn't an error. > > The intention of that seems to be that you just pass all the data > you have, and that it takes data it needs. So you can pass it data > that it doesn't need because it's only used in case some other parameter > has some specific value. For example, depending on the DRBG mode > (HMAC, CTR, HASH) you have different parameters, and you can just > pass all the parameters for all the modes. > > I think for behaviour for a setter is not something that we want, > it makes it complicated for applications to check that it will > behave properly. I think that in general, if the applications > wants to set something and you don't understand it, you should > return an error. This is about future proofing the API. For > instance, a new version supports a new mode to work in and that > needs a new parameter. If it's build against a version that knows > about it, but then runs against a version that doesn't know about > it, everything will appear to work, but be broken. If we return > an error, it will be clear that it's not supported. > > An alternative method of working is that the application first > needs to query that it's supported. And only if it's supported > it should call the function. But we don't have an API to query for > that. You might be able to ask for which keys you can set, but it > doesn't cover which values you can set. I hope we at least return > an error for a known key with an unknown value. But it's my > understanding that we currently don't always return all supported > keys, and that the supported keys can depend on one of the set > parameters. > > I suggest that we change the return value to indicate that all > parameters have been used or not. For instance return 1 in case > all used, return 2 in case not all used. > > >From my GOST implementor's experience, the provider can get a lot of parameters. Some of them are supported, some of them are not. The particular provider is the only subsystem that knows which parameters are supported and which are necessary for the operations. So the caller can provide some unsupported parameters, some supported and some totally wrong for the provider. These are the cases that must be distinguishable on the caller side. After that the provided EVP object should be either in a consistent state or not, assuming the upcoming operation. And the possibility to find out whether the state is consistent and suitable for the upcoming operation or not is a must and should be provided by an API. -- SY, Dmitry Belyavsky
Job Change
Dear colleagues, If everything is OK, I join the RedHat team on December 1. As it's planned now, I join the department where Tomas Mraz works. I strongly suppose that being an OpenSSL committer was a significant argument for the RedHat to send me an offer, and hope I'll be able to continue my activity as a committer. -- SY, Dmitry Belyavsky
Re: Meaning of no-xxx option
Dear Kurt, The situation in 1.1.1 was a bit fuzzier than you say. E.g., openssl built with no-gost in fact permits loading an engine for use in X.509/CMS, but GOST TLS support becomes unavailable. On Sun, Oct 18, 2020 at 10:33 AM Kurt Roeckx wrote: > Hi, > > It seems that we might start to interprete the no-xxx options > differently. In 1.1.1 it would completly disable the feature in > libcrypto, the apps and libssl. It seems that now the > interpretation changed to just disable the support for it in the > provider. You might load a different provider that does support > it, and so the apps and libssl can use it then. > > My interpretation was always that we want to completly disable the > feature, for instance because we don't want to use it at all or we > want to reduce the size of the binries. > > > Kurt > > -- SY, Dmitry Belyavsky
Re: Would this be interesting to the project?
Hello, I was able to setup CodeQL for the GOST engine. As it fetches OpenSSL alpha 6, I got able to see the results. == openssl/test/cmp_hdr_test.c#L181 Call to gmtime is potentially dangerous openssl/test/cmp_hdr_test.c#L171 Call to gmtime is potentially dangerous  openssl/test/asn1_time_test.c#L398 Call to localtime is potentially dangerous  openssl/crypto/ec/curve448/curve448.c#L583 Multiplication result may overflow 'int' before it is converted to 'unsigned long'.  openssl/crypto/asn1/a_time.c#L250 Multiplication result may overflow 'int' before it is converted to 'long'. == I can submit a PR providing the CodeQL scan for the master branch if the Team thinks it is useful. But I strongly suppose that someone will have to configure the OpenSSL github project to enable it. On Fri, Oct 2, 2020 at 6:30 PM Dmitry Belyavsky wrote: > As setting up openssl master is required to build gost-engine, I'll have > to. > > On Fri, Oct 2, 2020 at 4:29 PM Dr. Matthias St. Pierre < > matthias.st.pie...@ncp-e.com> wrote: > >> > Do you have ideas on how to properly set it up? >> >> >> >> Congratulations, Dmitry! You just won the price of being assigned the job >> to figure it out. ;-) >> >> >> >> Matthias >> >> >> >> >> >> *[image: NCP engingeering GmbH]* *Dr. Matthias St. Pierre* >> >> Senior Software Engineer >> matthias.st.pie...@ncp-e.com >> Phone: +49 911 9968-0 >> www.ncp-e.com >> >> >> * Follow us on:* Facebook <https://www.facebook.com/NCPengineering> | >> Twitter <https://twitter.com/NCP_engineering> | Xing >> <https://www.xing.com/companies/ncpengineeringgmbh> | YouTube >> <https://www.youtube.com/user/NCPengineeringGmbH> | LinkedIn >> <http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0> >> >> *Headquarters Germany: *NCP engineering GmbH • Dombuehler Str. 2 • 90449 >> • Nuremberg >> *North American HQ:* NCP engineering Inc. • 601 Cleveland Str., Suite >> 501-25 • Clearwater, FL 33755 >> >> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate >> Dietrich >> Registry Court: Lower District Court of Nuremberg >> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE >> 133557619 >> >> This e-mail message including any attachments is for the sole use of the >> intended recipient(s) and may contain privileged or confidential >> information. Any unauthorized review, use, disclosure or distribution is >> prohibited. If you are not the intended recipient, please immediately >> contact the sender by reply e-mail and delete the original message and >> destroy all copies thereof. >> >> <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen> >> <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen> >> >> *From**:* openssl-project *On >> Behalf Of *Dmitry Belyavsky >> *Sent:* Friday, October 2, 2020 2:51 PM >> *To:* Dr Paul Dale >> *Cc:* openssl-project@openssl.org >> *Subject:* Re: Would this be interesting to the project? >> >> >> >> Do you have ideas on how to properly set it up? >> >> >> >> On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale >> wrote: >> >> https://github.blog/2020-09-30-code-scanning-is-now-available/ >> >> >> >> Pauli >> >> -- >> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations >> Phone +61 7 3031 7217 >> Oracle Australia >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> SY, Dmitry Belyavsky >> > > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky
Re: Would this be interesting to the project?
As setting up openssl master is required to build gost-engine, I'll have to. On Fri, Oct 2, 2020 at 4:29 PM Dr. Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > > Do you have ideas on how to properly set it up? > > > > Congratulations, Dmitry! You just won the price of being assigned the job > to figure it out. ;-) > > > > Matthias > > > > > > *[image: NCP engingeering GmbH]* *Dr. Matthias St. Pierre* > > Senior Software Engineer > matthias.st.pie...@ncp-e.com > Phone: +49 911 9968-0 > www.ncp-e.com > > > * Follow us on:* Facebook <https://www.facebook.com/NCPengineering> | > Twitter <https://twitter.com/NCP_engineering> | Xing > <https://www.xing.com/companies/ncpengineeringgmbh> | YouTube > <https://www.youtube.com/user/NCPengineeringGmbH> | LinkedIn > <http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0> > > *Headquarters Germany: *NCP engineering GmbH • Dombuehler Str. 2 • 90449 > • Nuremberg > *North American HQ:* NCP engineering Inc. • 601 Cleveland Str., Suite > 501-25 • Clearwater, FL 33755 > > Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate > Dietrich > Registry Court: Lower District Court of Nuremberg > Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE > 133557619 > > This e-mail message including any attachments is for the sole use of the > intended recipient(s) and may contain privileged or confidential > information. Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, please immediately > contact the sender by reply e-mail and delete the original message and > destroy all copies thereof. > > <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen> > <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen> > > *From**:* openssl-project *On > Behalf Of *Dmitry Belyavsky > *Sent:* Friday, October 2, 2020 2:51 PM > *To:* Dr Paul Dale > *Cc:* openssl-project@openssl.org > *Subject:* Re: Would this be interesting to the project? > > > > Do you have ideas on how to properly set it up? > > > > On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale wrote: > > https://github.blog/2020-09-30-code-scanning-is-now-available/ > > > > Pauli > > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > > > > > > > > > -- > > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky
Re: Would this be interesting to the project?
Do you have ideas on how to properly set it up? On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale wrote: > https://github.blog/2020-09-30-code-scanning-is-now-available/ > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > -- SY, Dmitry Belyavsky
Re: Freeze?
On Sat, Sep 26, 2020 at 2:17 AM Benjamin Kaduk wrote: > On Thu, Sep 24, 2020 at 12:33:56PM +1000, Dr Paul Dale wrote: > > I’m seeing quite a bit of activity going on which isn’t related to the > 3.0beta1 milestone. > > We’re well past the cutoff date announced for new features in the code. > > > > Should we be limiting the “new” stuff going in? > > > > I’m fine with bug fixes, they make sense. I’m fine with the list of > beta1 pull requests continuing. > > It’s the rest that is more concerning. > > > > Does anyone else have a similar view? > > I think we should probably avoid putting in large or potentially > destabilizing changes, but don't see much reason to put a total freeze in > place (even with your listed exceptions). > I agree with Ben. -- SY, Dmitry Belyavsky
Re: 3.0 beta 1 milestone
Dear Matt, I think #12891 is a significant problem. I'd suggest fixing it before beta1 or at least discuss it. Many thanks! On Thu, Sep 17, 2020 at 3:48 PM Matt Caswell wrote: > There's been quite a number of PRs added to the 3.0 beta 1 milestone. > > Within the PRs there are a couple of bug fixes: > > https://github.com/openssl/openssl/pull/12884 > https://github.com/openssl/openssl/pull/12874 > > IMO these would be really nice to get into beta 1, but they should not > be considered blockers for it (i.e. if they didn't go in, it shouldn't > stop us from releasing beta 1). > > There are also some nice-to-have items: > > https://github.com/openssl/openssl/pull/12777 > https://github.com/openssl/openssl/pull/12771 > https://github.com/openssl/openssl/pull/12726 > https://github.com/openssl/openssl/pull/12669 > https://github.com/openssl/openssl/pull/12072 > > Again - these are nice-to-have, and if they happen to get merged in time > for beta 1 then great. Otherwise, they should wait for 3.1 (possibly > things which are just cleanup/minor refactoring could still be done > within the beta period). So, IMO, these should not be considered > blockers either. > > So - this leads me to the question - what is the milestone for? Does it > means these things *must* go in before we can release beta 1? Or does it > mean we would *like* to get these things in for beta 1? > > I actually don't mind either way - but if its the latter, then I need a > way of identifying the "must haves". These are the top priority items, > and at the moment I can't easily track their progress. > > Matt > > > -- SY, Dmitry Belyavsky
Re: More GitHub labels
On Thu, Sep 10, 2020 at 9:20 AM Dr. Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > > ... I think we should change that. This does not mean that a reviewer > who made a change request > > two months ago and lost interest is forced to re-review, only that such > stale reviews must be dismissed > > explicitly, if the reviewer does not respond to a re-review request > within a certain time period. > > I would refine this procedure as follows: the team member who intends to > do the merge (the "merger"), > needs to issue re-review requests for all unresolved change requests > (there is a spinning button next the > name of the reviewer to do this). The person who receives the re-review > request can either dismiss its > review or indicate that it intends to review within x hours. Otherwise, > the merger can dismiss the stale review. > > Sorry, it seems a bit overengineering for me. I'd prefer a procedure with explicit hold and explanation in the comments. -- SY, Dmitry Belyavsky
Re: OpenSSL Security Advisory
Many thanks! On Wed, Sep 9, 2020 at 4:16 PM Mark J Cox wrote: > I just spotted it via twitter, https://raccoon-attack.com/ > > Mark > > On Wed, Sep 9, 2020 at 2:08 PM Dmitry Belyavsky wrote: > > > > Could you please let me know when it is available? > > > > On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox wrote: > >> > >> They should be releasing their paper very soon (today). > >> > >> Regards, Mark > >> > >> On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky > wrote: > >> > > >> > Is the description of the attack publicly available? > >> > > >> > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL wrote: > >> >> > >> >> -BEGIN PGP SIGNED MESSAGE- > >> >> Hash: SHA512 > >> >> > >> >> OpenSSL Security Advisory [09 September 2020] > >> >> = > >> >> > >> >> Raccoon Attack (CVE-2020-1968) > >> >> == > >> >> > >> >> Severity: Low > >> >> > >> >> The Raccoon attack exploits a flaw in the TLS specification which > can lead to > >> >> an attacker being able to compute the pre-master secret in > connections which > >> >> have used a Diffie-Hellman (DH) based ciphersuite. In such a case > this would > >> >> result in the attacker being able to eavesdrop on all encrypted > communications > >> >> sent over that TLS connection. The attack can only be exploited if an > >> >> implementation re-uses a DH secret across multiple TLS connections. > Note that > >> >> this issue only impacts DH ciphersuites and not ECDH ciphersuites. > >> >> > >> >> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH > secret and > >> >> does not implement any "static" DH ciphersuites. > >> >> > >> >> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH > >> >> ciphersuite is used. These static "DH" ciphersuites are ones that > start with the > >> >> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA > names for these > >> >> ciphersuites all start with "TLS_DH_" but excludes those that start > with > >> >> "TLS_DH_anon_". > >> >> > >> >> OpenSSL 1.0.2e and below would reuse the DH secret across multiple > TLS > >> >> connections in server processes unless the SSL_OP_SINGLE_DH_USE > option was > >> >> explicitly configured. Therefore all ciphersuites that use DH in > servers > >> >> (including ephemeral DH) are vulnerable in these versions. In > OpenSSL 1.0.2f > >> >> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned > off as a > >> >> response to CVE-2016-0701. > >> >> > >> >> Since the vulnerability lies in the TLS specification, fixing the > affected > >> >> ciphersuites is not viable. For this reason 1.0.2w moves the affected > >> >> ciphersuites into the "weak-ssl-ciphers" list. Support for the > >> >> "weak-ssl-ciphers" is not compiled in by default. This is unlikely > to cause > >> >> interoperability problems in most cases since use of these > ciphersuites is rare. > >> >> Support for the "weak-ssl-ciphers" can be added back by configuring > OpenSSL at > >> >> compile time with the "enable-weak-ssl-ciphers" option. This is not > recommended. > >> >> > >> >> OpenSSL 1.0.2 is out of support and no longer receiving public > updates. > >> >> > >> >> Premium support customers of OpenSSL 1.0.2 should upgrade to > 1.0.2w. If > >> >> upgrading is not viable then users of OpenSSL 1.0.2v or below should > ensure > >> >> that affected ciphersuites are disabled through runtime > configuration. Also > >> >> note that the affected ciphersuites are only available on the server > side if a > >> >> DH certificate has been configured. These certificates are very > rarely used and > >> >> for this reason this issue has been classified as LOW severity. > >> >> > >> >> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod > Aviram and Juraj > >> >> Somorovsky and report
Re: OpenSSL Security Advisory
Could you please let me know when it is available? On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox wrote: > They should be releasing their paper very soon (today). > > Regards, Mark > > On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky wrote: > > > > Is the description of the attack publicly available? > > > > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL wrote: > >> > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA512 > >> > >> OpenSSL Security Advisory [09 September 2020] > >> = > >> > >> Raccoon Attack (CVE-2020-1968) > >> == > >> > >> Severity: Low > >> > >> The Raccoon attack exploits a flaw in the TLS specification which can > lead to > >> an attacker being able to compute the pre-master secret in connections > which > >> have used a Diffie-Hellman (DH) based ciphersuite. In such a case this > would > >> result in the attacker being able to eavesdrop on all encrypted > communications > >> sent over that TLS connection. The attack can only be exploited if an > >> implementation re-uses a DH secret across multiple TLS connections. > Note that > >> this issue only impacts DH ciphersuites and not ECDH ciphersuites. > >> > >> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH > secret and > >> does not implement any "static" DH ciphersuites. > >> > >> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH > >> ciphersuite is used. These static "DH" ciphersuites are ones that start > with the > >> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names > for these > >> ciphersuites all start with "TLS_DH_" but excludes those that start with > >> "TLS_DH_anon_". > >> > >> OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS > >> connections in server processes unless the SSL_OP_SINGLE_DH_USE option > was > >> explicitly configured. Therefore all ciphersuites that use DH in servers > >> (including ephemeral DH) are vulnerable in these versions. In OpenSSL > 1.0.2f > >> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned > off as a > >> response to CVE-2016-0701. > >> > >> Since the vulnerability lies in the TLS specification, fixing the > affected > >> ciphersuites is not viable. For this reason 1.0.2w moves the affected > >> ciphersuites into the "weak-ssl-ciphers" list. Support for the > >> "weak-ssl-ciphers" is not compiled in by default. This is unlikely to > cause > >> interoperability problems in most cases since use of these ciphersuites > is rare. > >> Support for the "weak-ssl-ciphers" can be added back by configuring > OpenSSL at > >> compile time with the "enable-weak-ssl-ciphers" option. This is not > recommended. > >> > >> OpenSSL 1.0.2 is out of support and no longer receiving public updates. > >> > >> Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w. If > >> upgrading is not viable then users of OpenSSL 1.0.2v or below should > ensure > >> that affected ciphersuites are disabled through runtime configuration. > Also > >> note that the affected ciphersuites are only available on the server > side if a > >> DH certificate has been configured. These certificates are very rarely > used and > >> for this reason this issue has been classified as LOW severity. > >> > >> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram > and Juraj > >> Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in > order to > >> allow co-ordinated disclosure with other implementations. > >> > >> Note > >> > >> > >> OpenSSL 1.0.2 is out of support and no longer receiving public updates. > 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 of any > kind. > >> The impact of this issue on OpenSSL 1.1.0 has not been analysed. > >> > >> Users of these versions should upgrade to OpenSSL 1.1.1. > >> > >> References > >> == > >> > >> URL for this Security Advisory: > &
Re: OpenSSL Security Advisory
Is the description of the attack publicly available? On Wed, Sep 9, 2020 at 3:39 PM OpenSSL wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > OpenSSL Security Advisory [09 September 2020] > = > > Raccoon Attack (CVE-2020-1968) > == > > Severity: Low > > The Raccoon attack exploits a flaw in the TLS specification which can lead > to > an attacker being able to compute the pre-master secret in connections > which > have used a Diffie-Hellman (DH) based ciphersuite. In such a case this > would > result in the attacker being able to eavesdrop on all encrypted > communications > sent over that TLS connection. The attack can only be exploited if an > implementation re-uses a DH secret across multiple TLS connections. Note > that > this issue only impacts DH ciphersuites and not ECDH ciphersuites. > > OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret > and > does not implement any "static" DH ciphersuites. > > OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH > ciphersuite is used. These static "DH" ciphersuites are ones that start > with the > text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for > these > ciphersuites all start with "TLS_DH_" but excludes those that start with > "TLS_DH_anon_". > > OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS > connections in server processes unless the SSL_OP_SINGLE_DH_USE option was > explicitly configured. Therefore all ciphersuites that use DH in servers > (including ephemeral DH) are vulnerable in these versions. In OpenSSL > 1.0.2f > SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off > as a > response to CVE-2016-0701. > > Since the vulnerability lies in the TLS specification, fixing the affected > ciphersuites is not viable. For this reason 1.0.2w moves the affected > ciphersuites into the "weak-ssl-ciphers" list. Support for the > "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause > interoperability problems in most cases since use of these ciphersuites is > rare. > Support for the "weak-ssl-ciphers" can be added back by configuring > OpenSSL at > compile time with the "enable-weak-ssl-ciphers" option. This is not > recommended. > > OpenSSL 1.0.2 is out of support and no longer receiving public updates. > > Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w. If > upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure > that affected ciphersuites are disabled through runtime configuration. Also > note that the affected ciphersuites are only available on the server side > if a > DH certificate has been configured. These certificates are very rarely > used and > for this reason this issue has been classified as LOW severity. > > This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and > Juraj > Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order > to > allow co-ordinated disclosure with other implementations. > > Note > > > OpenSSL 1.0.2 is out of support and no longer receiving public updates. > 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 of any > kind. > The impact of this issue on OpenSSL 1.1.0 has not been analysed. > > Users of these versions should upgrade to OpenSSL 1.1.1. > > References > == > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20200909.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- > > iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl9YzBsACgkQ1enkP335 > 7oyIxg/9FWuca3/s/lY6g6a5VTPIekZMOLRUnDyzS3YePQu/sEd1w81mKoTqU+6F > KQmliGqdRDk+KN8HDVd14kcLBukto8UKmkp9FpB5J4d2KK1I/Fg/DofJs6xUQYKb > 5rHRLB3DDoyHEBzEEIjcqYTTThXW9ZSByVK9SKpC78IRM/B2dfd0+j4hIB/kDC/E > G+wieFzexHQVdleVYT/VaJ6qS8AwvohBbt8h7yK0P6v/4vEm0spDbUmjWJBVUlUu > QZyELjj8XZR3YFxt3axSuJg3JSGYlaMzkt2+DVq4qEzeJLIydLK9J8p6RNwPhsJk > Rx0ez8P4N+5O7XmA0nHv3HyompdMgHlvykj8Ks4lNHVS02KKLi1jDtmOxl3Fm/hb > ZNOmjn7lulV1342pw4rWL3Nge3x0s0Q5zgBCm1mqLzzu/V1ksx8FJwGA1w2cH280 > dU9VedkC2wvFQije8pFrWH9l6N9Bh41DIEOnlBl0AL7IrbPdO6yMcD6vpR7hWjr3 > fx4hNJSAGzJ3i/NXlSj4eR/47zkjfJyEc8Drc2QgewyqXFrK20X/LOj8MqJlc+ry > pXZseh+XC8WaYDMV1ltrKvE2Ld9/0f3Ydc04AcDeu5SXPJG79ogzVnchZok7+XCj > RT+a3/ES45+CTfL5v27t5QJxJcxg4siLVsILfi0rIUv0IYgH2fU= > =U7OO > -END PGP SIGNATURE- > -- SY, Dmitry Belyavsky
My vacation
Hello, I go on my vacation from July 24 to August 5. On vacation, my internet access is very limited. If you have smth urgent, please let me know via direct email. Many thanks! -- SY, Dmitry Belyavsky
Re: Unexpected EOF handling
Dear Tomas, On Mon, May 11, 2020 at 2:07 PM Tomas Mraz wrote: > On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote: > > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > > > So I think we need at least to agree on: > > > > > - Do we want an option that makes the unexpected EOF either a > > > > > fatal > > > > > error or a non-fatal error? > > > > > - Which error should we return? > > > > > > > > This is an excellent summary of the current situation. > > > > > > > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno > > > > as a > > > > long term solution. It's a very confusing API for new > > > > applications to > > > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - > > > > except > > > > when its not. SSL_ERROR_SYSCALL should mean fatal error. > > > > > > > > That said I also recognise that it is apparently commonplace to > > > > shut > > > > down a TLS connection without sending close_notify - despite what > > > > the > > > > standards may say about it (and TBH we can hardly claim the moral > > > > high > > > > ground here since s_server does exactly this - or at least it > > > > does in > > > > 1.1.1 and did until very recently in master). > > > > > > > > But we do have to consider usages beyond HTTPS. I have no idea if > > > > this > > > > occurs in other settings or not. > > > > > > > > Perhaps what we need is an option for "strict shutdown". With > > > > strict > > > > shutdown "off" we could treat EOF as if we had received a > > > > close_notify > > > > gracefully (and don't invalidate the session). Presumably > > > > existing > > > > code > > > > would be able to cope with that??? > > > > > > Yes, existing code would be able to cope with that with one > > > important > > > exception that I am going to talk about below. > > > > > > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in > > > > master). > > > > > > > > I'm not sure though what the default should be. > > > > > > In case we go with this solution, which would be acceptable I > > > think, we > > > MUST NOT EVER make it the default because existing applications > > > that > > > depend on the existing way how the unclean EOF condition is > > > returned > > > might actually depend on it to detect the truncation attack. > > > > I agree that we should not return SSL_ERROR_ZERO_RETURN by default > > on an unexpected EOF. > > > > If the default behaviour should be to make it a non-fatal error, > > like the old behaviour is, I would really prefer a different > > error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL. > > > > So I think the suggestion is to have this: > > - By default, SSL_ERROR_SSL is returned with > > SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be > > marked invalid. > > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session > > will stay valid. > > +1 > > And my suggestion for the SSL_OP name is SSL_OP_IGNORE_UNEXPECTED_EOF. > > Dmitry, I think this solution should be working well for nginx and > similar http related applications. They just need to use the > SSL_OP_IGNORE_UNEXPECTED_EOF and the peers that do not properly > terminate the TLS session will just appear as if they properly > terminated it. > I'm not sure this is the best possible solution because it makes the application developers doing extra compile-time checks. But anyway, is it a final decision and the patch can be amended or we are waiting for objections some more time? -- SY, Dmitry Belyavsky
Re: Some more extra tests
Dear Nicola, Please see https://github.com/openssl/openssl/pull/11792 It currently does not enable TCL and Perl tests, but the C tests also helped me to find regression in the master branch. On Thu, May 7, 2020 at 10:55 PM Dmitry Belyavsky wrote: > Dear Nicola, > > I feel a significant lack of knowledge of preparing such a PR. > If I was able to submit it, I would. > > On Thu, May 7, 2020 at 10:38 PM Nicola Tuveri wrote: > >> I would be interested in seeing a PR to see what enabling these tests >> would require! >> >> I believe we do indeed need to test more thoroughly to ensure we are not >> breaking the engine API! >> >> >> Nicola >> >> On Thu, May 7, 2020, 21:08 Dmitry Belyavsky wrote: >> >>> Dear colleagues, >>> >>> Let me draw your attention to a potentially reasonable set of extended >>> tests for the openssl engines. >>> >>> The gost-engine project (https://github.com/gost-engine/engine) has >>> some test scenarios robust enough for testing engine-provided algorithms >>> and some basic RSA regression tests. It contains a rather eclectic set of >>> C, Perl, and TCL(!) tests that are used by me on a regular basis. >>> >>> If these tests are included in the project extended test suite, they >>> could reduce some regression that sometimes occurs (see >>> https://github.com/gost-engine/engine/issues/232 as a current list of >>> known problems). >>> >>> I will be happy to assist in enabling these tests as a part of openssl >>> test suites. >>> Many thanks! >>> >>> -- >>> SY, Dmitry Belyavsky >>> >> > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky
Re: Alpha2
Dear Matt, The workaround for the 11763 is implemented, 11764 seems to be fixed now, so no objections from my side. Happy weekend! On Fri, May 8, 2020 at 11:58 AM Dmitry Belyavsky wrote: > Dear Matt, > > I kindly ask not to make release until issues raised in #11763 and #11764 > are fixed. > > On Fri, May 8, 2020 at 11:55 AM Matt Caswell wrote: > >> Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss >> current progress. It was proposed that we should do the Alpha 2 release >> next week (on Thursday 14th May). Unless I hear objections otherwise, I >> plan to go with that. >> >> Matt >> > > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky
Re: Unexpected EOF handling
Dear Kurt On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx wrote: > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > > So I think we need at least to agree on: > > > > - Do we want an option that makes the unexpected EOF either a fatal > > > > error or a non-fatal error? > > > > - Which error should we return? > > > > > > This is an excellent summary of the current situation. > > > > > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a > > > long term solution. It's a very confusing API for new applications to > > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except > > > when its not. SSL_ERROR_SYSCALL should mean fatal error. > > > > > > That said I also recognise that it is apparently commonplace to shut > > > down a TLS connection without sending close_notify - despite what the > > > standards may say about it (and TBH we can hardly claim the moral > > > high > > > ground here since s_server does exactly this - or at least it does in > > > 1.1.1 and did until very recently in master). > > > > > > But we do have to consider usages beyond HTTPS. I have no idea if > > > this > > > occurs in other settings or not. > > > > > > Perhaps what we need is an option for "strict shutdown". With strict > > > shutdown "off" we could treat EOF as if we had received a > > > close_notify > > > gracefully (and don't invalidate the session). Presumably existing > > > code > > > would be able to cope with that??? > > > > Yes, existing code would be able to cope with that with one important > > exception that I am going to talk about below. > > > > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in > > > master). > > > > > > I'm not sure though what the default should be. > > > > In case we go with this solution, which would be acceptable I think, we > > MUST NOT EVER make it the default because existing applications that > > depend on the existing way how the unclean EOF condition is returned > > might actually depend on it to detect the truncation attack. > > I agree that we should not return SSL_ERROR_ZERO_RETURN by default > on an unexpected EOF. > > If the default behaviour should be to make it a non-fatal error, > like the old behaviour is, I would really prefer a different > error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL. > > So I think the suggestion is to have this: > - By default, SSL_ERROR_SSL is returned with > SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be > marked invalid. > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session > will stay valid. > If I remember correctly, session resumption is a way to significantly reduce a server's workload. So I think that by default (and maybe the only option) we should prefer the old behaviour. -- SY, Dmitry Belyavsky
Re: Alpha2
Dear Matt, I kindly ask not to make release until issues raised in #11763 and #11764 are fixed. On Fri, May 8, 2020 at 11:55 AM Matt Caswell wrote: > Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss > current progress. It was proposed that we should do the Alpha 2 release > next week (on Thursday 14th May). Unless I hear objections otherwise, I > plan to go with that. > > Matt > -- SY, Dmitry Belyavsky
Re: Some more extra tests
Dear Nicola, I feel a significant lack of knowledge of preparing such a PR. If I was able to submit it, I would. On Thu, May 7, 2020 at 10:38 PM Nicola Tuveri wrote: > I would be interested in seeing a PR to see what enabling these tests > would require! > > I believe we do indeed need to test more thoroughly to ensure we are not > breaking the engine API! > > > Nicola > > On Thu, May 7, 2020, 21:08 Dmitry Belyavsky wrote: > >> Dear colleagues, >> >> Let me draw your attention to a potentially reasonable set of extended >> tests for the openssl engines. >> >> The gost-engine project (https://github.com/gost-engine/engine) has some >> test scenarios robust enough for testing engine-provided algorithms and >> some basic RSA regression tests. It contains a rather eclectic set of C, >> Perl, and TCL(!) tests that are used by me on a regular basis. >> >> If these tests are included in the project extended test suite, they >> could reduce some regression that sometimes occurs (see >> https://github.com/gost-engine/engine/issues/232 as a current list of >> known problems). >> >> I will be happy to assist in enabling these tests as a part of openssl >> test suites. >> Many thanks! >> >> -- >> SY, Dmitry Belyavsky >> > -- SY, Dmitry Belyavsky
Re: Unexpected EOF handling
ted EOF either a fatal > > error or a non-fatal error? > > - Which error should we return? > > From application developer side of view for protocols that do not > depend on SSL detecting the truncation I think inventing a different > behavior for this condition than the existing one as of 1.1.1f would be > clearly wrong. Switching on a SSL_OP if that newly provided OP is a > trivial change to an application that needs to accommodate various > versions of OpenSSL (and I am not talking about forks), however > switching on a SSL_OP and also add another special error case is much > more complicated change and has potential for bringing regressions in > the applications that need to do it. > > It is also an API break, however we would do it anyway unless we make > the legacy behavior the default one, so that is not really relevant > here. > > Is there really another situation where SSL_ERROR_SYSCALL with errno 0 > could be returned apart from the unclean EOF condition? > > I can't really think of any. > > So I would be just for properly documenting the condition and keeping > it as is if the SSL_OP to ignore unclean EOF is in effect. > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > > -- SY, Dmitry Belyavsky
Some more extra tests
Dear colleagues, Let me draw your attention to a potentially reasonable set of extended tests for the openssl engines. The gost-engine project (https://github.com/gost-engine/engine) has some test scenarios robust enough for testing engine-provided algorithms and some basic RSA regression tests. It contains a rather eclectic set of C, Perl, and TCL(!) tests that are used by me on a regular basis. If these tests are included in the project extended test suite, they could reduce some regression that sometimes occurs (see https://github.com/gost-engine/engine/issues/232 as a current list of known problems). I will be happy to assist in enabling these tests as a part of openssl test suites. Many thanks! -- SY, Dmitry Belyavsky
Re: Stale PR stats @May01
On Fri, May 1, 2020 at 6:19 PM Mark J Cox wrote: > On Fri, May 1, 2020 at 3:30 PM Dmitry Belyavsky wrote: > .. > > And I also got an idea that ping comment leaves PRs out of this > statistics :) > > Thanks! The script is designed to ignore the automated pings that it > creates itself so they themselves don't reset the dates and > artificially stop things being stale. Instead they will hopefully > nudge folks into taking some action that will actually stop the PRs > being stale :)) > Well, I see some Catch-22 elements here... -- SY, Dmitry Belyavsky
Re: Stale PR stats @May01
862 days:330 > 8835 days:370 > 8743 branch: master, days:381 > 8668 days:392 > 8455 days:394 > 8420 days:395 > 8333 days:430 > 8309 branch: master, reviewed:commented days:316 > 8024 reviewed:commented days:81 > 7688 days:516 > 7615 days:520 > 7454 reviewed:commented days:471 > 7274 reviewed:approved days:322 > 7225 reviewed:commented days:587 > 6725 milestone:Assessed, reviewed:approved days:330 > 6518 milestone:Assessed, reviewed:approved days:681 > 6516 branch: 1.1.1, branch: master, milestone:Assessed, days:681 > 6448 milestone:Assessed, days:188 > 6219 milestone:Assessed, reviewed:approved days:719 > 5427 branch: master, milestone:Assessed, reviewed:commented days:481 > 4487 milestone:Assessed, days:658 > -- SY, Dmitry Belyavsky
Re: 1.1.1f
On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell wrote: > The EOF issue (https://github.com/openssl/openssl/issues/11378) has > resulted in us reverting the original EOF change in the 1.1.1 branch > (https://github.com/openssl/openssl/pull/11400). > > Given that this seems to have broken quite a bit of stuff, I propose > that we do a 1.1.1f soon (possibly next Tuesday - 31st March). > > Thoughts? > I strongly support this idea. -- SY, Dmitry Belyavsky
Deprecating misleading GOST names
Hello, I came across wrong naming for some GOST-related stuff in object.txt. As all this stuff was introduced by me, it's a separate problem. First, I've erroneously translated the name of the Russian "Кузнечик" algorithm as "grasshopper" instead of transliterating it as 'kuznyechik". The transliteration has appeared as an official after the changes were accepted into openssl. Second, some other algorithm and parameter names were introduced with their official names instead of reasonable short names. When they are used in the command line applications, it's very inconvenient. I'd like to fix these issues in the upcoming 3.0 release, so any ideas about how to deal with it are welcome. Some of this stuff can be fixed on the engine level, but it's better to avoid misleading naming. -- SY, Dmitry Belyavsky
Re: New GitHub Project Landing Page
Looks great! Many thanks for your efforts! On Wed, Feb 26, 2020 at 11:13 PM Dr. Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > The OpenSSL Project GitHub has a new landing page: > > https://github.com/openssl/openssl > > Scroll down. Enjoy. > > > Matthias > > > -- SY, Dmitry Belyavsky
Re: Deprecation
Dear Richard, On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte wrote: > On Fri, 14 Feb 2020 10:41:05 +0100, > Dmitry Belyavsky wrote: > > > > > > Hello, > > > > On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale > wrote: > > > > There is some pushback against the deprecations going on in various > PRs. > > > > The plan has always been to deprecate engines in 3.0 and removing > support for them 5+ years later. > > Originally, the path was to have included an engine provider that > could load engines and make them appear > > to be a provider. After a fair amount of investigation, this was > deemed to be too difficult in the 3.0 > > time frame. > > > > Do we still want to deprecate engines in 3.0? > > Should we defer until 4.0 instead? > > > > I think we should delay the deprecation of engine stuff to 4.0. > Personally I don't have sense of stability of > > provider API. > > It should be pointed out that the engine stuff isn't as stable as you > might think, because it shares internal structures with libcrypto. > Even if we handle those structures via function calls, all it takes is > loading an engine linked against - say - 1.1.0 in 1.1.1 to run a real > risk of a spectacular KABOOM if any of the structure that are touched > changed between those OpenSSL versions. > Does ABI compatibility cover a significant share of these cases? > This is a consequence of making structures opaque and feeling much > more liberty in changing them, and we didn't quite pay attention. > > The whole model around providers is intentionally designed to allow > providers to run flexibly with any OpenSSL version, even if they are > linked with some (possibly different) libcrypto version. > > So the question of stability depends on what you look at. > Agreed. It's true that some parts of the provider API is fluctuating a bit, as > early designs need modifications to better meet demands. We're still > in development. Come beta1 (schedule for June), I expect that it will > have stabilized. Come the release, it must have. > Sure. > The main benefits seem to boil down to continuing to support existing > engines vs removing the legacy code > > paths and switching to the provider model. > > > > For me, both as open-source and commercial engine developer seems > > reasonable to delay conversion from engines to providers at least > > until 3.0.0 feature freeze happens. > > According to our policy, a deprecation starts at the release that has > those deprecations, and removal of deprecated stuff can only happen 5 > years later at the earliest. Seeing deprecations in the source now > doesn't change that, the clock will start ticking when we release > 3.0, so consider what you see happening on github as a pre-deprecation > warning. > Yes. > > But some features I'm interested in imply engine model (and it will > > be great if somebody else could look at PR 10904 to avoid it when > > possible). > > Apart from a few details, that PR looks rather innocuous. I frankly > haven't had time to look at it too deeply (I just discovered that I > was prompted), as I haven't dived in the CMS code yet... > Well, the problem is introducing some new control values. I don't feel policy here very well. I also plan to submit at least one TLS-related PR significantly more innocent... -- SY, Dmitry Belyavsky
Re: Deprecation
Dear Matt, On Fri, Feb 14, 2020 at 12:48 PM Matt Caswell wrote: > > > On 14/02/2020 09:41, Dmitry Belyavsky wrote: > > Hello, > > > > On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale > <mailto:paul.d...@oracle.com>> wrote: > > > > There is some pushback against the deprecations going on in various > PRs. > > > > The plan has always been to deprecate engines in 3.0 and removing > > support for them 5+ years later. Originally, the path was to have > > included an engine provider that could load engines and make them > > appear to be a provider. After a fair amount of investigation, this > > was deemed to be too difficult in the 3.0 time frame. > > > > Do we still want to deprecate engines in 3.0? > > Should we defer until 4.0 instead? > > > > > > I think we should delay the deprecation of engine stuff to 4.0. > > Personally I don't have sense of stability of provider API. > > Well - it isn't stable *right now*. Its in development. But moving > forward the provider model *is* the way we intend to go. By the time of > the 3.0 release the provider stuff had better be stable, otherwise we've > gone wrong. > Totally agree. Though the conversion between engines and providers is not as straightforward as I want, so I prefer to wait for some time. > > As has been pointed out many times. Deprecation does not mean removal > (yet). Its just a signal that at some later time we will remove it. > Sure. > > And the 3.0 is the right time to signal that. We don't want to hold on > the "legacy" codepaths for any longer than we have to. They were only > ever originally intended to be temporary, and to be removed before 3.0 > got released. However it now looks like they will live beyond the 3.0 > release. They should not live for any longer than absolutely necessary. > Hmmm. Not sure here. I remember the introduction of EVP_PKEY_ameth/pmeth currently moving to providers. > The main benefits seem to boil down to continuing to support > > existing engines vs removing the legacy code paths and switching to > > the provider model. > It's worth explaining the benefits to engine authors :) I understand the benefits of OpenSSL as a product and still now don't have a firm understanding of benefits for the surrounding ecosystem. Though I did not dive into the providers deeply. I still have a suspicion that we will not have function signatures for callbacks in providers. Do we? If don't, we'll have a set of errors implementing it. > For me, both as open-source and commercial engine developer seems > > reasonable to delay conversion from engines to providers at least until > > 3.0.0 feature freeze happens. > > That's a perfectly reasonable strategy. But this decision is independent > of whether we deprecate the ENGINE APIs in 3.0 or not. It would be > perfectly ok for people to continue to *use* engines in 3.0 even though > they are deprecated. > Sure. > > But some features I'm interested in imply engine model (and it will be > > great if somebody else could look at PR 10904 to avoid it when possible). > > If there are gaps then we need to plug them. The provider model should > be able to do everything that you can do now in ENGINEs. > Totally agree. -- SY, Dmitry Belyavsky
Re: Deprecation
Hello, On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale wrote: > There is some pushback against the deprecations going on in various PRs. > > The plan has always been to deprecate engines in 3.0 and removing support > for them 5+ years later. Originally, the path was to have included an > engine provider that could load engines and make them appear to be a > provider. After a fair amount of investigation, this was deemed to be too > difficult in the 3.0 time frame. > > Do we still want to deprecate engines in 3.0? > Should we defer until 4.0 instead? > I think we should delay the deprecation of engine stuff to 4.0. Personally I don't have sense of stability of provider API. The main benefits seem to boil down to continuing to support existing > engines vs removing the legacy code paths and switching to the provider > model. > For me, both as open-source and commercial engine developer seems reasonable to delay conversion from engines to providers at least until 3.0.0 feature freeze happens. But some features I'm interested in imply engine model (and it will be great if somebody else could look at PR 10904 to avoid it when possible). -- SY, Dmitry Belyavsky
Re: Deprecation
Hello, I think OPENSSL_NO_DEPRECATED_1_0_2 should be added to this list too. On Fri, Feb 14, 2020 at 12:31 PM Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > > > On 14.02.20 10:21, Matthias St. Pierre wrote: > > > > Because deprecation without removal is futile, it increases complexity > of the code > > instead of reducing it. > > > > Matthias > > > > To underlinie my last statement, I added the initial release dates: > > OPENSSL_NO_DEPRECATED_0_9_8 # 05 Jul 2005 > OPENSSL_NO_DEPRECATED_1_0_0 # 29 Mar 2010 > OPENSSL_NO_DEPRECATED_1_0_1 # 14 Mar 2012 > -- SY, Dmitry Belyavsky
Re: Github PR label automation
Dear Mark, Thank you for a nice job! As the reviewers are expected to commit the PRs, could you also add the reviewers' names as a part of the notification? On Sat, Feb 8, 2020 at 6:56 PM Mark J Cox wrote: > I've currently got a cron job running every hour that looks at open PR > requests against github openssl repo and does various actions. So if > you were wondering why I was altering labels and making comments at > 4am, now you know. No doubt we'll use some tool user for this in the > future. > > So right now here's what it does: > > Every hour it looks at open PRs that are labelled "approval: done". > If 24 hours has elapsed since that label was assigned and if there > have been no comments made to the PR since the label was assigned then > it is automatically moved to "approval: ready to merge" with a comment > added to trigger notifications. So if you want to stop something > going to "ready to merge" just add any comment to the PR. > > I'm thinking of using this script also to 1) collect interesting stats > and 2) do some other actions. So if there's some automation you'd > like to see just add an enhancement issue against the openssl/tools > repo. > > 1 Matt already asked for committer notification trigger for anything > labelled Urgent. > > 2 If there were comments made after "approval: done" then I think we > really ought to drop the "approval: done" label as the comments likely > invalidated the approval. So I'll likely add that next week (if > "approval: done" label and has comments since that label then remove > the label and add a comment 'please review if this is really approval: > done'. If the approval: done label gets set again then after 24 hours > the existing automation will trigger. #10786 is a good example of > this. > > Mark > -- SY, Dmitry Belyavsky
Re: New Committer
Great news! On Fri, Jan 31, 2020 at 5:48 PM Matt Caswell wrote: > I'd like to announce that David von Oheimb has joined our team of > committers! David has been particularly active recently with the CMP > contribution - but also has numerous other PRs and commits to his name. > > Welcome David! > > Matt > -- SY, Dmitry Belyavsky
Re: crypt(3)
Dear Paul, The KDF variant seems the best one. On Fri, Jan 17, 2020 at 9:33 AM Dr Paul Dale wrote: > In the deprecation efforts for 3.0, I’ve hit something in the DES code > that I’d appreciate input on. > > There are two functions (DES_crypt and DES_fcrypt) which implement the old > crypt(3) password algorithm. Once these are deprecated, they will no > longer be reachable via EVP. The confounding point is that they aren’t > quite DES — close but not identical. I would be surprised if they aren’t > still in use for /etc/passwd files on old and/or embedded systems. > > I’ve got several choices: > >1. Leave them public and unchanged — that is, don’t deprecate these >two functions yet. >2. Deprecate them and add KDFs to replace them. >3. Deprecate them, leave them alone and hope they go away painlessly >at some point. > > > The apps/password.c applet calls these which is how I stumbled over the > complication. I’m fine refactoring this based on the solution chosen. I’d > also be okay with factoring out all the password derivation functions into > KDFs if necessary. > > > Thoughts? Other alternatives? > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > -- SY, Dmitry Belyavsky
Re: 3.0 release timeline proposal
Sorry. My fault :( On Tue, 7 Jan 2020, 16:35 Matt Caswell, wrote: > > > On 07/01/2020 13:26, Dmitry Belyavsky wrote: > > Many thanks! > > > > Got it, and I think this should be directly written. > > It was!! > > beta1, 2020-06-02: Code complete (API stable, feature freeze) > > > Matt > > > > > > On Tue, 7 Jan 2020, 16:05 Matt Caswell, > <mailto:m...@openssl.org>> wrote: > > > > > > > > On 07/01/2020 13:00, Dmitry Belyavsky wrote: > > > When does the feature freeze happen? > > > I'm interested in publishing as much GOST support as possible. > > > > According to my proposal feature freeze would happen on release of > > beta1, i.e. 2020-06-02. > > > > Matt > > > > > > > > > > On Tue, 7 Jan 2020, 14:13 Matt Caswell, > <mailto:m...@openssl.org> > > > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> wrote: > > > > > > Hi all > > > > > > Myself, Paul, Shane, Richard and Nicola had a conf call today > > to discuss > > > the outstanding tasks and effort required to get us to a final > > release. > > > > > > We've previously said this about that timeline: > > > > > > "We are now not expecting code completion to occur until the > > end of Q2 > > > 2020 with a final release in early Q4 2020." > > > (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/) > > > > > > > > > With that in mind we came up with the following proposal for a > > release > > > timetable which we think is a challenging but achievable > timeline: > > > > > > alpha1, 2020-03-31: Basic functionality plus basic FIPS module > > > alpha2, 2020-04-21: Complete external provider support > > (serialization, > > > support for new algs, support for providers which only include > > > operations in a class) > > > alpha3, 2020-05-21: Almost there (aiming to test the API > > completeness > > > before beta1 freezes it) > > > beta1, 2020-06-02: Code complete (API stable, feature freeze) > > > betaN: Other beta TBD > > > Final: 2020 early Q4 > > > > > > The idea here is to set some intermediate deadlines to focus > > attention > > > on the final remaining tasks, with a series of 3 alphas prior > > to the > > > first beta release where each alpha release comes > > approximately every 3 > > > weeks. We can have some flexibility to adjust this timetable > > if we think > > > it is necessary (such as by including an additional alpha > > release if > > > required). > > > > > > Please let me know your thoughts. This would probably need to > > go to an > > > OMC vote to get approved. > > > > > > Matt > > > > > >
Re: 3.0 release timeline proposal
Many thanks! Got it, and I think this should be directly written. On Tue, 7 Jan 2020, 16:05 Matt Caswell, wrote: > > > On 07/01/2020 13:00, Dmitry Belyavsky wrote: > > When does the feature freeze happen? > > I'm interested in publishing as much GOST support as possible. > > According to my proposal feature freeze would happen on release of > beta1, i.e. 2020-06-02. > > Matt > > > > > > On Tue, 7 Jan 2020, 14:13 Matt Caswell, > <mailto:m...@openssl.org>> wrote: > > > > Hi all > > > > Myself, Paul, Shane, Richard and Nicola had a conf call today to > discuss > > the outstanding tasks and effort required to get us to a final > release. > > > > We've previously said this about that timeline: > > > > "We are now not expecting code completion to occur until the end of > Q2 > > 2020 with a final release in early Q4 2020." > > (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/) > > > > > > With that in mind we came up with the following proposal for a > release > > timetable which we think is a challenging but achievable timeline: > > > > alpha1, 2020-03-31: Basic functionality plus basic FIPS module > > alpha2, 2020-04-21: Complete external provider support > (serialization, > > support for new algs, support for providers which only include > > operations in a class) > > alpha3, 2020-05-21: Almost there (aiming to test the API completeness > > before beta1 freezes it) > > beta1, 2020-06-02: Code complete (API stable, feature freeze) > > betaN: Other beta TBD > > Final: 2020 early Q4 > > > > The idea here is to set some intermediate deadlines to focus > attention > > on the final remaining tasks, with a series of 3 alphas prior to the > > first beta release where each alpha release comes approximately > every 3 > > weeks. We can have some flexibility to adjust this timetable if we > think > > it is necessary (such as by including an additional alpha release if > > required). > > > > Please let me know your thoughts. This would probably need to go to > an > > OMC vote to get approved. > > > > Matt > > >
Re: 3.0 release timeline proposal
When does the feature freeze happen? I'm interested in publishing as much GOST support as possible. On Tue, 7 Jan 2020, 14:13 Matt Caswell, wrote: > Hi all > > Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss > the outstanding tasks and effort required to get us to a final release. > > We've previously said this about that timeline: > > "We are now not expecting code completion to occur until the end of Q2 > 2020 with a final release in early Q4 2020." > (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/) > > > With that in mind we came up with the following proposal for a release > timetable which we think is a challenging but achievable timeline: > > alpha1, 2020-03-31: Basic functionality plus basic FIPS module > alpha2, 2020-04-21: Complete external provider support (serialization, > support for new algs, support for providers which only include > operations in a class) > alpha3, 2020-05-21: Almost there (aiming to test the API completeness > before beta1 freezes it) > beta1, 2020-06-02: Code complete (API stable, feature freeze) > betaN: Other beta TBD > Final: 2020 early Q4 > > The idea here is to set some intermediate deadlines to focus attention > on the final remaining tasks, with a series of 3 alphas prior to the > first beta release where each alpha release comes approximately every 3 > weeks. We can have some flexibility to adjust this timetable if we think > it is necessary (such as by including an additional alpha release if > required). > > Please let me know your thoughts. This would probably need to go to an > OMC vote to get approved. > > Matt >
Re: Flaw in our process for dealing with trivial changes
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 +, 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 > > > >
Re: Flaw in our process for dealing with trivial changes
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 >> <mailto:beld...@gmail.com>> 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 >> <mailto:m...@openssl.org>> 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
Re: Flaw in our process for dealing with trivial changes
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
Re: Malloc failures check
Unfortunately, it is not a compile-time check...
I mean smth like
https://github.com/openssl/openssl/blob/ab5c77b4766e0992751d86560193ca42b49cf316/include/openssl/e_os2.h#L198-L202
but not sure it is applicable to external functions...
On Thu, Nov 21, 2019 at 1:42 PM Salz, Rich wrote:
>
>- It would be possible to implement a malloc failure feature in the
>test suite that systematically runs a test many times, failing successive
>malloc calls.
>
>
>
> It’s there; look crypto/mem.c, shouldfail() and FAILTEST.
>
>
>
> More detail, from off-list discusson:
>
>
>
> i=0
>
> while : ; do
>
>((i++))
>
>export MALLOC_FAILURE_CHECKS=${i}@100 openssl foo etc…
>
>test -f core && echo crashed && exit 1
>
> done
>
>
>
>
>
--
SY, Dmitry Belyavsky
Malloc failures check
Hello, Observing a series of similar bugs related to a lack of checks of the malloc return values, I wonder if we could automate the search of these errors on the compile level (e.g. similar to the __owur macro)? -- SY, Dmitry Belyavsky
Re: punycode licensing
Dear Tim, Sorry for the delay with the response. On Thu, Jul 11, 2019 at 2:44 AM Tim Hudson wrote: > On Thu, Jul 11, 2019 at 12:37 AM Dmitry Belyavsky > wrote: > >> Dear Tim, >> >> Formally I am a contributor with a signed CLA. >> I took a code definitely permitting any usage without any feedback, >> slightly modified it (at least by openssl-format-source and splitting >> between header and source), and submitted it as my feedback to OpenSSL. >> >> I still think that it will be a good idea if Adam signs the CLA, but if >> he declines, we still have a correct interpretation. >> > > In your ICLA it contains the instructions you have to follow (reproduced > here to save you time): > > 7. Should You wish to submit work that is not Your original creation, You > may submit it to the Foundation separately from any Contribution, > identifying the complete details of its source and of any license or other > restriction (including, but not limited to, related patents, trademarks, > and license agreements) of which you are personally aware, and > conspicuously marking the work as "Submitted on behalf of a third-party: > [named here]". > > > Your current PR at https://github.com/openssl/openssl/pull/9199 does not > actually do this - basically you have to have punycode.c, punycode.h in a > separate submission not intermixed with anything else. > > The reason for not intermixing the code should be pretty clear - as we > need to know which parts belong to someone else and aren't covered by your > ICLA and which parts are - with no possibility of confusion. > > You would also need to include the *license* that those files are under > which you have not done so - which according to the RFC is: > > Regarding this entire document or any portion of it (including > the pseudocode and C code), the author makes no guarantees and > is not responsible for any damage resulting from its use. The > author grants irrevocable permission to anyone to use, modify, > and distribute it in any way that does not diminish the rights > of anyone else to use, modify, and distribute it, provided that > redistributed derivative works do not contain misleading author or > version information. Derivative works need not be licensed under > similar terms. > > Separately, Rich Salz indicated he had email from the author with respect to > being willing to license under the Apache License 2.0 which you would need to > get directly from the author (or Rich would need to be the submitter). Only > the author (actually copyright owner) can change the license terms of code > they create. This isn't about the license. > > You really should reach out to the author to ask if he is willing to sign an > ICLA - that is the normal steps involved. > There is nothing particularly onerous in the ICLAs - they are basically there > to provide certainty and a legal background for the project to be able to > provide the code that it does. > > You should also note that the license noted in the RFC misses many of the > provisions within the ICLA and within the Apache License 2.0 itself and is > incompatible with the Apache License 2.0 because it contains restrictions and > conditions beyond those stated in this license. > > After all the work that the project did to be able to move to its current > license (and a lot of that work was Rich Salz's efforts) it is important that > we maintain the foundation of the clear license terms for the entire code > base. > > Unfortunately, the author of the code did not respond to my letter in which I asked him whether he agrees to sign the ICLA and close the discussion. Do I correctly understand that for now, the best solution is just reimplementing the punycode encoding/decoding myself to avoid all the conflicts? It's a solution I do not like, but if OMC insists, I will do it. Thank you! -- SY, Dmitry Belyavsky
Re: punycode licensing
Dear Tim, Formally I am a contributor with a signed CLA. I took a code definitely permitting any usage without any feedback, slightly modified it (at least by openssl-format-source and splitting between header and source), and submitted it as my feedback to OpenSSL. I still think that it will be a good idea if Adam signs the CLA, but if he declines, we still have a correct interpretation. On Wed, Jul 10, 2019 at 1:43 PM Tim Hudson wrote: > Previous assertions that if the license was compatible that we don't need > a CLA in order to accept a contribution were incorrect. > You are now questioning the entire purpose of contributor agreements and > effectively arguing they are superfluous and that our policy should be > different. > > You are (of course) entitled to your opinion on the topic - however the > project view and policy on this is both clear and consistent even if it is > different from what you would like to see. > > If someone else wants to create a derivative of the software and combine > in packages under other licenses (Apache License or otherwise) without > having CLAs in place then that is their choice to do so as long as they > adhere to the license agreement. > Again, all of this is use under the license. What our policies cover is > for contributions that the project itself will distribute - and entirely > separate context for what others can do with the resulting package. > > The CLAs are not the same as code being contributed under an Apache > License 2.0. > There are many sound reasons for CLAs existing, and discussion of those > reasons isn't an appropriate topic IMHO for openssl-project. > > Tim. > > > > On Wed, Jul 10, 2019 at 8:08 PM Salz, Rich wrote: > >> Thank you for the reply. >> >> >> >> *>*The license under which the OpenSSL software is provided does not >> require "permission" to be sought for use of the software. >> >> See https://www.openssl.org/source/apache-license-2.0.txt >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_source_apache-2Dlicense-2D2.0.txt=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=xXRygChGgiK1BqBdOliLUVY3TL3voFi6oS6EUcMdAaU=g7Itj8LyezH-cDY2PLhFY6RkrbcX4b3xX5A7_f9MQvE=> >> >> >> >> Use, as defined by the license, doesn’t just mean end-users, and it is >> not limited to compiling, linking, and running executables. A recipient >> can make derivative items, redistribute, and so on. All of those things are >> what OpenSSL would do if it “took in” code into the source base. >> >> >> >> So why does the project require permission from other Apache-licensed >> licensed software? In other words, why will the project not accept and use >> the rights, covered by copyright and license, that it grants to others? >> >> >> > -- SY, Dmitry Belyavsky
Re: Cleaning up include file inconsistencies
Hello, I'd like either _lcl.h or _local.h. _locl.h seems weird to me :) On Sat, Jul 6, 2019 at 10:32 AM Dr. Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > 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/openssl/pull/9274#issuecomment-508824668 > between Bernd and me. > > In particular, in > https://github.com/openssl/openssl/pull/9274#issuecomment-508826903 and > following the question was raised whether all local `*_lcl.h` files should > be renamed > to `*_locl.h` for consistency reasons, and the pros and cons discussed. > The latter choice was suggested by a source tree vote: > >~/src/openssl$ find -name '*_lcl.h' | wc -l >19 > ~/src/openssl$ find -name '*_locl.h' | wc -l > 30 > > What's your opinion about renaming of those files? > > Matthias > > -- SY, Dmitry Belyavsky
Re: Welcoming our new committers
Many thanks for a great honor to become an OpenSSL committer! I hope to be useful after I understand the procedures. On Tue, May 21, 2019 at 12:58 AM Paul Dale wrote: > Welcome to the team. > > > Pauli > -- > Oracle > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > > -Original Message- > From: Matt Caswell [mailto:m...@openssl.org] > Sent: Monday, 20 May 2019 8:31 PM > To: openssl-project@openssl.org > Subject: Welcoming our new committers > > Please welcome our four new committers as announced here: > > https://www.openssl.org/blog/blog/2019/05/20/committers/ > > The new committers are: > > Dmitry Belyavsky, Shane Lontis, Tomáš Mráz and Patrick Steuer. > > Welcome all! > > Matt > -- SY, Dmitry Belyavsky
