From shane.lontis at oracle.com Sat Sep 5 03:48:08 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Sat, 5 Sep 2020 13:48:08 +1000 Subject: Reordering new API's that have a libctx, propq Message-ID: PR #12778 reorders all the API?s of the form: EVP_XX_fetch(libctx, algname, propq) So that the algorithm name appears first.. e.g: EVP_MD_fetch(digestname, libctx, propq); This now logically reads as 'search for this algorithm using these parameters?. The libctx, propq should always appear together as a pair of parameters. There are only a few places where only the libctx is needed, which means that if there is no propq it is likely to cause a bug in a fetch at some point. This keeps the API?s more consistent with other existing XXX_with_libctx API?s that put the libctx, propq at the end of the parameter list.. The exception to this rule is that callback(s) and their arguments occur after the libctx, propq.. e.g: typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn) (const OSSL_STORE_LOADER *loader, const char *uri, OPENSSL_CTX *libctx, const char *propq, const UI_METHOD *ui_method, void *ui_data); An otc_hold was put on this.. Do we need to have a formal vote? This really needs to be sorted out soon so the API?s can be locked down for beta. -------- Also discussed in a weekly meeting and numerous PR discussions was the removal of the long winded API?s ending with ?with_libctx? e.g CMS_data_create_with_libctx The proposed renaming for this was to continue with the _ex notation.. If there is an existing _ex name then it becomes _ex2, etc. There will most likely be additional parameters in the future for some API?s, so this notation would be more consistent with current API?s. Does this also need a vote? Regards, Shane -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Sat Sep 5 06:11:21 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 5 Sep 2020 06:11:21 +0000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: Both suggestions make sense to me and they were discussed several times in the weekly calls. So you have my support whether there will be the need for a formal vote or not. > An otc_hold was put on this.. Do we need to have a formal vote? Since Tim placed the hold, only he can remove it. If he doesn?t, an OTC vote is inevitable. https://github.com/openssl/openssl/pull/12778#issuecomment-686348526 In that case, let?s just have the vote and finish it quickly. Matthias From: openssl-project On Behalf Of SHANE LONTIS Sent: Saturday, September 5, 2020 5:48 AM To: openssl-project at openssl.org Subject: Reordering new API's that have a libctx, propq PR #12778 reorders all the API?s of the form: EVP_XX_fetch(libctx, algname, propq) So that the algorithm name appears first.. e.g: EVP_MD_fetch(digestname, libctx, propq); This now logically reads as 'search for this algorithm using these parameters?. The libctx, propq should always appear together as a pair of parameters. There are only a few places where only the libctx is needed, which means that if there is no propq it is likely to cause a bug in a fetch at some point. This keeps the API?s more consistent with other existing XXX_with_libctx API?s that put the libctx, propq at the end of the parameter list.. The exception to this rule is that callback(s) and their arguments occur after the libctx, propq.. e.g: typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn) (const OSSL_STORE_LOADER *loader, const char *uri, OPENSSL_CTX *libctx, const char *propq, const UI_METHOD *ui_method, void *ui_data); An otc_hold was put on this.. Do we need to have a formal vote? This really needs to be sorted out soon so the API?s can be locked down for beta. -------- Also discussed in a weekly meeting and numerous PR discussions was the removal of the long winded API?s ending with ?with_libctx? e.g CMS_data_create_with_libctx The proposed renaming for this was to continue with the _ex notation.. If there is an existing _ex name then it becomes _ex2, etc. There will most likely be additional parameters in the future for some API?s, so this notation would be more consistent with current API?s. Does this also need a vote? Regards, Shane -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Sat Sep 5 07:09:51 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 5 Sep 2020 17:09:51 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: I place the OTC hold because I don't believe we should be making parameter reordering decisions without actually having documented what approach we want to take so there is clear guidance. This was the position I expressed in the last face to face OTC meeting - that we need to write such things down - so that we avoid this precise situation - where we have new functions that are added that introduce the inconsistency that has been noted here that PR#12778 is attempting to address. However, this is a general issue and not a specific one to OPENSSL_CTX and it should be discussed in the broader context and not just be a last minute (before beta1) API argument reordering. That does not provide anyone with sufficient time to consider whether or not the renaming makes sense in the broader context. I also think that things like API argument reordering should have been discussed on openssl-project so that the broader OpenSSL community has an opportunity to express their views. Below is a quick write up on APIs in an attempt to make it easier to hold an email discussion about the alternatives and implications of the various alternatives over time. I've tried to outline the different options. In general, the OpenSSL API approach is of the following form: *rettype TYPE_get_something(TYPE *,[args])rettype TYPE_do_something(TYPE *,[args])TYPE *TYPE_new([args])* This isn't universally true, but it is the case for the majority of OpenSSL functions. In general, the majority of the APIs place the "important" parameters first, and the ancillary information afterwards. In general, for output parameters we tend to have those as the return value of the function or an output parameter that tends to be at the end of the argument list. This is less consistent in the OpenSSL APIs. We also have functions which operate on "global" information where the information used or updated or changed is not explicitly provided as an API parameter - e.g. all the byname functions. Adding the OPENSSL_CTX is basically providing where to get items from that used to be "global". When performing a lookup, the query string is a parameter to modify the lookup being performed. OPENSSL_CTX is a little different, as we are adding in effectively an explicit parameter where there was an implicit (global) usage in place. But the concept of adding parameters to functions over time is one that we should have a policy for IMHO. For many APIs we basically need the ability to add the OPENSSL_CTX that is used to the constructor so that it can be used for handling what used to be "global" information where such things need the ability to work with other-than-the-default OPENSSL_CTX (i.e. not the previous single "global" usage). That usage works without a query string - as it isn't a lookup as such - so there is no modifier present. For that form of API usage we have three choices as to where we place things: 1) place the context first *TYPE *TYPE_new(OPENSSL_CTX *,[args])* 2) place the context last *TYPE *TYPE_new([args],OPENSSL_CTX *)* 3) place the context neither first nor last *TYPE *TYPE_new([some-args],OPENSSL_CTX *,[more-args])* Option 3 really isn't a sensible choice to make IMHO. When we are performing effectively a lookup that needs a query string, we have a range of options. If we basically state that for a given type, you must use the OPENSSL_CTX you have been provided with on construction, (not an unreasonable position to take), then you don't need to modify the existing APIs. If we want to allow for a different OPENSSL_CTX for a specific existing function, then we have to add items. Again we have a range of choices: A) place the new arguments first *rettype TYPE_get_something(OPENSSL_CTX *,TYPE *,[args])rettype TYPE_do_something(OPENSSL_CTX *,TYPE *,[args])* B) place the new arguments first after the TPYE *rettype TYPE_get_something(TYPE *,OPENSSL_CTX *,[args])rettype TYPE_do_something(TYPE *,OPENSSL_CTX *,[args])* C) place the new arguments last *rettype TYPE_get_something(TYPE *,[args], OPENSSL_CTX *)rettype TYPE_do_something(TYPE *,[args], OPENSSL_CTX *)* D) place the new arguments neither first nor last *rettype TYPE_get_something(TYPE *,[some-args], OPENSSL_CTX *,[more-args])rettype TYPE_do_something(OPENSSL_CTX *,TYPE *,[some-args], OPENSSL_CTX *,[more-args])* Option D really isn't a sensible choice to make IMHO. My view is that the importance of arguments is what sets their order - and that is why for the TYPE functions the TYPE pointer comes first. We could have just as easily specified it as last or some other order, but we didn't. Now when we need to add a different location from which to retrieve other information we need to determine where this gets added. I'd argue that it is at constructor time that we should be adding any OPENSSL_CTX or query parameter for any existing TYPE usage in OpenSSL. If we feel the need to cross OPENSSL_CTX's (logically that is what is being done) inside the context of a single instance then we would have to make a choice as to where to place these arguments. A very simple thing to note is that we will add arguments over time and that any time we add arguments, applications have to change their code. We basically have again a similar set of choices as to where new arguments get added (first, middle, last). If we make a choice to decide our scheme is to add to the end of the list, then effectively we are choosing to place things in the middle as over time that is what the API pattern becomes when new arguments are added logically. This is of course ignoring that we create a new function when we are adding arguments - but they can conceptually be seen as the same function which we only added because we are coding in C and don't have polymorphic function support. I believe the right answer for how we should approach things is 1) and B) (with A as a fallback position). *TYPE *TYPE_new(OPENSSL_CTX *,[args])* *rettype TYPE_get_something(TYPE *,OPENSSL_CTX *,[args])rettype TYPE_do_something(TYPE *,OPENSSL_CTX *,[args]) * I think 2) and C) logically turn into 3) and D) over time and that 3) and D) are undesirable outcomes. I also think the pattern works equally well with the query string or any other parameter being included. *TYPE *TYPE_new(OPENSSL_CTX *,char *prop_query,[args])* *rettype TYPE_get_something(TYPE *,OPENSSL_CTX *,char *prop_query,[args])* *rettype TYPE_do_something(TYPE *,OPENSSL_CTX *,char *prop_query,[args]) * Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane.lontis at oracle.com Sat Sep 5 08:28:06 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Sat, 5 Sep 2020 18:28:06 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: <30AA7D4E-33BA-49EC-973B-39DC95AF5243@oracle.com> Thanks for the writeup.. > My view is that the importance of arguments is what sets their order - and that is why for the TYPE functions the TYPE pointer > comes first. We could have just as easily specified it as last or some other order, but we didn?t. Isn?t that the order that the fetch is in if it changes to what it is in the PR? I would argue that the algorithm is the most important parameter in the fetch. Deciding what argument is more ?important? is not always easy either. If we are doing an operation such as a get or load and it needs a whole lot of input params in order to return something, then aren?t they more important/ or just as important as the libctx,propq - (since the libctx,propq is just used normally to fetch something)? This then means the libctx ends up last, or maybe in the middle again. Also it is quite common for the new() methods (such as for X509) to need both the libctx and propq.. The X509 object gets passed to an d2i method that internally needs to do fetches (SHA1) and cache. Shane > On 5 Sep 2020, at 5:09 pm, Tim Hudson wrote: > > My view is that the importance of arguments is what sets their order - and that is why for the TYPE functions the TYPE pointer > comes first. We could have just as easily specified it as last or some other order, but we didn't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Sat Sep 5 08:38:33 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sat, 5 Sep 2020 11:38:33 +0300 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: Thanks Tim for the writeup! I tend to agree with Tim's conclusions in general, but I fear the analysis here is missing an important premise that could influence the outcome of our decision. In most (if not all) cases in our functions, both libctx and propquery are optional arguments, as we have global defaults for them based on the loaded config file. As such, explicitly passing non-NULL libctx and propquery, is likely to be an exceptional occurrence rather than the norm. For optional parameters most developers from C and a variety of languages, would expect them to come at the end of the list of parameters, and this also follows the rule of thumb of "importance" used by Tim to pick 1) and B/A). For this reason I would instead suggest to go with 2) and C) in this case (with the caveat of keeping callback and its args as the very last arguments, again this is a non-written convention not only for us but quite widespread). Nicola On Sat, Sep 5, 2020, 10:10 Tim Hudson wrote: > I place the OTC hold because I don't believe we should be making parameter > reordering decisions without actually having documented what approach we > want to take so there is clear guidance. > This was the position I expressed in the last face to face OTC meeting - > that we need to write such things down - so that we avoid this precise > situation - where we have new functions that are added that introduce the > inconsistency that has been noted here that PR#12778 is attempting to > address. > > However, this is a general issue and not a specific one to OPENSSL_CTX and > it should be discussed in the broader context and not just be a last minute > (before beta1) API argument reordering. > That does not provide anyone with sufficient time to consider whether or > not the renaming makes sense in the broader context. > I also think that things like API argument reordering should have been > discussed on openssl-project so that the broader OpenSSL community has an > opportunity to express their views. > > Below is a quick write up on APIs in an attempt to make it easier to hold > an email discussion about the alternatives and implications of the various > alternatives over time. > I've tried to outline the different options. > > In general, the OpenSSL API approach is of the following form: > > > > *rettype TYPE_get_something(TYPE *,[args])rettype TYPE_do_something(TYPE > *,[args])TYPE *TYPE_new([args])* > > This isn't universally true, but it is the case for the majority of > OpenSSL functions. > > In general, the majority of the APIs place the "important" parameters > first, and the ancillary information afterwards. > > In general, for output parameters we tend to have those as the return > value of the function or an output parameter that > tends to be at the end of the argument list. This is less consistent in > the OpenSSL APIs. > > We also have functions which operate on "global" information where the > information used or updated or changed > is not explicitly provided as an API parameter - e.g. all the byname > functions. > > Adding the OPENSSL_CTX is basically providing where to get items from that > used to be "global". > When performing a lookup, the query string is a parameter to modify the > lookup being performed. > > OPENSSL_CTX is a little different, as we are adding in effectively an > explicit parameter where there was an implicit (global) > usage in place. But the concept of adding parameters to functions over > time is one that we should have a policy for IMHO. > > For many APIs we basically need the ability to add the OPENSSL_CTX that is > used to the constructor so that > it can be used for handling what used to be "global" information where > such things need the ability to > work with other-than-the-default OPENSSL_CTX (i.e. not the previous single > "global" usage). > > That usage works without a query string - as it isn't a lookup as such - > so there is no modifier present. > For that form of API usage we have three choices as to where we place > things: > > 1) place the context first > > *TYPE *TYPE_new(OPENSSL_CTX *,[args])* > > 2) place the context last > > *TYPE *TYPE_new([args],OPENSSL_CTX *)* > > 3) place the context neither first nor last > > *TYPE *TYPE_new([some-args],OPENSSL_CTX *,[more-args])* > > Option 3 really isn't a sensible choice to make IMHO. > > When we are performing effectively a lookup that needs a query string, we > have a range of options. > If we basically state that for a given type, you must use the OPENSSL_CTX > you have been provided with on construction, > (not an unreasonable position to take), then you don't need to modify the > existing APIs. > > If we want to allow for a different OPENSSL_CTX for a specific existing > function, then we have to add items. > Again we have a range of choices: > > A) place the new arguments first > > > *rettype TYPE_get_something(OPENSSL_CTX *,TYPE *,[args])rettype > TYPE_do_something(OPENSSL_CTX *,TYPE *,[args])* > > B) place the new arguments first after the TPYE > > > > *rettype TYPE_get_something(TYPE *,OPENSSL_CTX *,[args])rettype > TYPE_do_something(TYPE *,OPENSSL_CTX *,[args])* > C) place the new arguments last > > > *rettype TYPE_get_something(TYPE *,[args], OPENSSL_CTX *)rettype > TYPE_do_something(TYPE *,[args], OPENSSL_CTX *)* > > D) place the new arguments neither first nor last > > > > *rettype TYPE_get_something(TYPE *,[some-args], OPENSSL_CTX > *,[more-args])rettype TYPE_do_something(OPENSSL_CTX *,TYPE *,[some-args], > OPENSSL_CTX *,[more-args])* > Option D really isn't a sensible choice to make IMHO. > > My view is that the importance of arguments is what sets their order - and > that is why for the TYPE functions the TYPE pointer > comes first. We could have just as easily specified it as last or some > other order, but we didn't. > > Now when we need to add a different location from which to retrieve other > information we need to determine where this gets added. > I'd argue that it is at constructor time that we should be adding any > OPENSSL_CTX or query parameter for any existing TYPE usage > in OpenSSL. If we feel the need to cross OPENSSL_CTX's (logically that is > what is being done) inside the context of a single instance > then we would have to make a choice as to where to place these arguments. > > A very simple thing to note is that we will add arguments over time and > that any time we add arguments, applications have to change > their code. We basically have again a similar set of choices as to where > new arguments get added (first, middle, last). If we make > a choice to decide our scheme is to add to the end of the list, then > effectively we are choosing to place things in the middle > as over time that is what the API pattern becomes when new arguments are > added logically. This is of course ignoring that we > create a new function when we are adding arguments - but they can > conceptually be seen as the same function which we only added > because we are coding in C and don't have polymorphic function support. > > I believe the right answer for how we should approach things is 1) and B) > (with A as a fallback position). > > *TYPE *TYPE_new(OPENSSL_CTX *,[args])* > > > *rettype TYPE_get_something(TYPE *,OPENSSL_CTX *,[args])rettype > TYPE_do_something(TYPE *,OPENSSL_CTX *,[args]) * > > I think 2) and C) logically turn into 3) and D) over time and that 3) and > D) are undesirable outcomes. > > I also think the pattern works equally well with the query string or any > other parameter being included. > > > *TYPE *TYPE_new(OPENSSL_CTX *,char *prop_query,[args])* > *rettype TYPE_get_something(TYPE *,OPENSSL_CTX *,char *prop_query,[args])* > *rettype TYPE_do_something(TYPE *,OPENSSL_CTX *,char *prop_query,[args]) * > > Tim. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Sat Sep 5 09:13:30 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 5 Sep 2020 19:13:30 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: On Sat, Sep 5, 2020 at 6:38 PM Nicola Tuveri wrote: > In most (if not all) cases in our functions, both libctx and propquery are > optional arguments, as we have global defaults for them based on the loaded > config file. > As such, explicitly passing non-NULL libctx and propquery, is likely to be > an exceptional occurrence rather than the norm. > And that is where we have a conceptual difference, the libctx is *always* used. If it is provided as a NULL parameter then it is a shortcut to make the call to get the default or to get the already set one. Conceptually it is always required for the function to operate. And the conceptual issue is actually important here - all of these functions require the libctx to do their work - if it is not available then they are unable to do their work. We just happen to have a default-if-NULL. If C offered the ability to default a parameter if not provided (and many languages offer that) I would expect we would be using it. But it doesn't - we are coding in C. So it is really where-is-what-this-function-needs-coming-from that actually is the important thing - the source of the information the function needs to make its choice. It isn't which algorithm is being selected - the critical thing is from which pool of algorithm implementations are we operating. The pool must be specified (this is C code), but we have a default value. And that is why I think the conceptual approach here is getting confused by the arguments appearing to be optional - conceptually they are not - we just have a defaulting mechanism and that isn't the same conceptually as the arguments actually being optional. Clearer? Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sat Sep 5 09:15:04 2020 From: matt at openssl.org (Matt Caswell) Date: Sat, 5 Sep 2020 10:15:04 +0100 Subject: OpenSSL is looking for a full time Administrator and Manager Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL Management Committee are looking to hire a full time Administrator and Manager. Details of the role can be found here: https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/ To apply please send your cover letter and resume to jobs at openssl.org by 20th September 2020. Regards, The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl9TVxgACgkQ2cTSbQ5g RJHKGggAn1YGhR7UwtgVXTMWUKiv4jYpXd5OaHonAaUwIFdkXUzBmmEq9PP1Thw/ A4rQ/anDZ6SfRlFaGxQB1Fyz5LRyNDhHA48lM0v/Yw55S6NfSrMaPcGRuU8Odikf 4Nd7zzD3RcOgfhphdHEXz7ykMi90ATVcLTVnaoQtkvw5LHeiXzqzBLT9+WEcENWU 4z2WLJRGTpwIBfYfm6/NQPTDzsy/VBoVW/nl1mx6jkvL2UxuOdp4rfTMz9lu3IPk CnkujXxDIVSn02xSiRccj3ujnFqOq4lwtSiOzOl/HowlCDY6DmRhIvsu1PnPzJ15 v5JbQhDpk4kHjalCsJq2QfdcP41pDQ== =h9gU -----END PGP SIGNATURE----- From nic.tuv at gmail.com Sat Sep 5 10:44:51 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sat, 5 Sep 2020 13:44:51 +0300 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: On Sat, Sep 5, 2020, 12:13 Tim Hudson wrote: > On Sat, Sep 5, 2020 at 6:38 PM Nicola Tuveri wrote: > >> In most (if not all) cases in our functions, both libctx and propquery >> are optional arguments, as we have global defaults for them based on the >> loaded config file. >> As such, explicitly passing non-NULL libctx and propquery, is likely to >> be an exceptional occurrence rather than the norm. >> > > And that is where we have a conceptual difference, the libctx is *always* used. > If it is provided as a NULL parameter then it is a shortcut to make the > call to get the default or to get the already set one. > Conceptually it is always required for the function to operate. > > And the conceptual issue is actually important here - all of these > functions require the libctx to do their work - if it is not available then > they are unable to do their work. > We just happen to have a default-if-NULL. > > If C offered the ability to default a parameter if not provided (and many > languages offer that) I would expect we would be using it. > But it doesn't - we are coding in C. > > So it is really where-is-what-this-function-needs-coming-from that > actually is the important thing - the source of the information the > function needs to make its choice. > It isn't which algorithm is being selected - the critical thing is from > which pool of algorithm implementations are we operating. The pool must be > specified (this is C code), but we have a default value. > > And that is why I think the conceptual approach here is getting confused > by the arguments appearing to be optional - conceptually they are not - we > just have a defaulting mechanism and that isn't the same conceptually as > the arguments actually being optional. > > Clearer? > It's not yet clear to me the distinction you are trying to make. I'll try to spell out what I extrapolated from your answer, and I apologize in advance if I am misunderstanding your argument, please be patient and correct me in that case so I can better understand your point! It seems to me you are making a conceptual difference between - a function that internally requires an instance of foo to work (and has a default if foo is given as NULL among the arguments); e.g libctx is necessary for a fetch, if a NULL libctx is given a mechanism is in place to retrieve the global default one - a function that internally uses an instance of foo only if a non-NULL one is passed as argument; e.g. bnctx, if the user provides it this is used by the callee and passed to its callee, if the user passes NULL the function creates a fresh one for itself and/or its callees But as a consumer of the API that difference is not visible and probably not even interesting, as we are programming in C and passing pointers, there are certain arguments that are required and must be passed as valid pointers, others that appear optional because as a consumer of that API I can pass NULL and let the function internally default to a reasonable behavior (and whatever this "reasonable behavior" is ? whether the first or the second case from above, or another one I did not list ?, it's part of the documentation of that API). IMHO, in the consumer POV, libctx and propq are optional arguments (even in C where optional or default arguments do not technically exist and the caller needs to always specify a value for each argument, which are always positional) in the sense that they can pass NULL as a value rather than a pointer to a fully instantiated object of the required type. Even more so given that, excluding a minority of cases, we can expect consumers of the APIs taking libctx and propq as arguments to pass NULL for both of them and rely on the openssl config mechanism. So while I agree with Tim that sometime it is valuable to make a difference among the consequences of passing NULL as arguments in the context of one kind of function and another, I believe the place for that is the documentation not its signature. The signature of the function should be designed for consumer usability, and the conventional pattern there seems to be - required args - optional args - callback+cb_args and inside each group the "importance" factor should be the secondary sorting criteria. "importance" is probably going to be affected by the difference you are making (or my understanding of it): e.g. if a function took both libctx and bnctx, the fact that a valid pre-existing libctx is required to work (and a global already existing one will be retrieved in case none is given), while a fresh short-lived bnctx is going to be created only for the lifetime of the called function in case none is given seems to indicate that libctx is of vital importance for the API functionality, while bnctx is of minor relevance. But... going this way as a generalized approach, would bring us to the "add in the middle" scenario that we'd like to avoid. I recognize that this is a point you already made in your original writeup, as the tendency of "add to the end" to naturally degrade into "add in the middle". So, my question is: if "degradable add to the end" (where "degradable" only happens rarely and for good reasons) seems the one that in the end produces signatures matching (IMHO) the conventional usability patterns expected by consumers of the API, is it such a dramatic conclusion that we want to exclude it? Or is your point that we are writing in C, all the arguments are positional, none is ever really optional, there is no difference between passing a `(void*) NULL` or a valid `(TYPE*) ptr` as the value of a `TYPE *` argument, so "importance" is the only remaining sorting criteria, hence (libctx, propq) are always the most important and should go to the beginning of the args list (with the exception of the `self/this` kind of argument that always goes first)? Nicola > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Sat Sep 5 11:01:33 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 5 Sep 2020 21:01:33 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: On Sat, Sep 5, 2020 at 8:45 PM Nicola Tuveri wrote: > Or is your point that we are writing in C, all the arguments are > positional, none is ever really optional, there is no difference between > passing a `(void*) NULL` or a valid `(TYPE*) ptr` as the value of a `TYPE > *` argument, so "importance" is the only remaining sorting criteria, hence > (libctx, propq) are always the most important and should go to the > beginning of the args list (with the exception of the `self/this` kind of > argument that always goes first)? > That's a reasonable way to express things. The actual underlying point I am making is that we should have a rule in place that is documented and that works within the programming language we are using and that over time doesn't turn into a mess. We do add parameters (in new function names) and we do like to keep the order of the old function - and ending up with a pile of things in the "middle" is in my view is one of the messes that we should be avoiding. I think the importance argument is the one that helps for setting order and on your "required args" coming first approach the importance argument also applies because it is actually a required argument simply with an implied default - which again puts it not at the end of the argument list. The library context is required - always - there is just a default - and that parameter must be present because we are working in C. Whatever it is that we end up decided to do, the rule should be captured and should also allow for the fact that we will evolve APIs and create _ex versions and those two will also evolve and a general rule should be one that doesn't result in an inconsistent treatment for argument order as we add _ex versions. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Sat Sep 5 15:43:56 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sat, 5 Sep 2020 18:43:56 +0300 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: On Sat, Sep 5, 2020, 14:01 Tim Hudson wrote: > On Sat, Sep 5, 2020 at 8:45 PM Nicola Tuveri wrote: > >> Or is your point that we are writing in C, all the arguments are >> positional, none is ever really optional, there is no difference between >> passing a `(void*) NULL` or a valid `(TYPE*) ptr` as the value of a `TYPE >> *` argument, so "importance" is the only remaining sorting criteria, hence >> (libctx, propq) are always the most important and should go to the >> beginning of the args list (with the exception of the `self/this` kind of >> argument that always goes first)? >> > > That's a reasonable way to express things. > > The actual underlying point I am making is that we should have a rule in > place that is documented and that works within the programming language we > are using and that over time doesn't turn into a mess. > We do add parameters (in new function names) and we do like to keep the > order of the old function - and ending up with a pile of things in the > "middle" is in my view is one of the messes that we should be avoiding. > We are already adding new functions, with the ex suffix, to allow users to keep using the old version, so given that the users passing to the "_ex" function are already altering their source, why are we limiting us from rationalizing the signature from the PoV of new users and old users alike that are in general quite critic of our API usability, even if it means that applying both "required-ness" and "importance" as sorting criteria sometime we end up adding in the middle? I don't think I am being dismissive of the needs of existing applications here: if a maintainer is altering their code from using "EVP_foo()" to "EVP_foo_ex()", they will likely also be looking at the documentation of the old and the new API versions and there shouldn't be really any additional significanf cost in adding a parameter a the edges or in the middle. I think the importance argument is the one that helps for setting order and > on your "required args" coming first approach the importance argument also > applies because it is actually a required argument simply with an implied > default - which again puts it not at the end of the argument list. The > library context is required - always - there is just a default - and that > parameter must be present because we are working in C. > I think I disagree with this, from the API CONSUMER PoV there is a clear difference between a function where they don't need to pass a valid libctx pointer and instead pass NULL (because there is a default associated with passing NULL) and a function like an hypothetical OSSL_LIBCTX_get_this(libctx) or OSSL_LIBCTX_set_that(libctx, value). In the first case the function operates despite the programmer not providing an explicit libctx (because a default one is used), in the latter the programmer is querying/altering directly the libctx and one must be provided. *? actually only now that I wrote out the greyed text above I think I am starting to understand what you meant all along!* Your point is that any API that uses a `libctx` (and `propq`) is always querying/altering a libctx, even if we use NULL as a shortcut to mean "the global one", so if we are fetching an algorithm, getting/setting something on a libctx scope, creating a new object, we are always doing so from a given libctx. In that sense, when an API consumer is passing NULL they are not passing "nothing" (on which my "optional arguments" approach is based), but they are passing NULL as a valid reference to a very specific libctx. I now see what you meant, and I can see how it is a relevant thing to make evident also in the function signature/usage. But I guess we can also agree that passing NULL as a very specific reference instead of as "nothing", can create a lot of confusion for external consumers of the API, if it took this long for one of us ? ?*ok, it's me, so probably everyone else understood your point immediately, but still?* ? to understand the difference you were pointing out, even knowing how these functions work internally and being somewhat familiar with dealing with libctx-s. If we want to convey this difference properly to our users, would it be better to use a new define? #define OSSL_DEFAULT ((void*)42) - OSSL_DFLT could be a shorter alternative, if we prefer brevity. - I am intentionally not specifying _LIBCTX as we might reuse a similar mechanism to avoid overloading NULL in other similar situations: e.g. for propq, where NULL is again a shortcut for the global ones, compared with passing "" as an empty properties query, seems like another good candidate for using a symbol to explicitly highlight that the default propq will be used - I would avoid making OSSL_DFLT an alias for NULL to prevent users from sidestepping the define completely and use NULL directly (because "it just works anyway"): that is why I am picking 42 as an example, but any magic number different from NULL/0 and that is most likely/always treated as an invalid userspace memory address would be ok. If we had such a define, from the API consumer PoV, libctx stops being an "optional argument" (in the sense I can give it "NULL/nothing" and the function still works) and it is clearly a required argument (passing "NULL/nothing" segfaults/errors) while still retaining the option of having a shortcut symbol to delegate the task of retrieving the default libctx to the called function. Whatever it is that we end up decided to do, the rule should be captured > and should also allow for the fact that we will evolve APIs and create _ex > versions and those two will also evolve and a general rule should be one > that doesn't result in an inconsistent treatment for argument order as we > add _ex versions. > If we were not using NULL as an alias for "the default one" rather than for "nothing", the difference between required and simil-optional arguments (those that you can avoid passing to the function by passing "NULL/nothing") would be evident to the users of the API. In that case we could agree on sorting arguments as: - required ones (you must pass a valid value, including the special OSSL_DFLT to let the callee retrieve a default value dynamically, or passing NULL/nothing as the output buffer to obtain a length for preallocation) - simil-optional ones (you can pass "NULL/nothing": the function will perform its operations skipping an optional part of it, or using whatever representation of "nothing" as the value of an optional thing, or creating a temporary thing to solve the task at hand in the stead of the one the caller did not pass, etc.) - callback+args and sorting by "importance" within each group: - among required args: * the equivalent of "self/this" for the functions that operate as object methods in a OOP fashion * libctx (for OOP-like functions, if an object is not libctx-agnostic, there should be very few occasions where both self and libctx appear as arguments, as the libctx should be embedded in the object at creation time if it depends from it, i.e. let's not repeat the EC_POINT/EC_GROUP mess!) * propquery (always right after libctx, see Note1 below about libctx+propquery) * functionality-specific required args, in their order of importance (we need to further formalize this, e.g. we have not always been consistent on the order of inputs and outputs, though most of the recommended API are quite consistent in having outputs first, then inputs) - among optional args: * functionality-specific optional args, in their order of importance * optional args for auxiliary objects (I would define these as openssl specific things that aid in solving a task, but are not required to solve a task, e.g. BN_CTX, see Note2 below)) *Note1*: I am listing propquery separately, although there should be very few cases where we deliberately have libctx as an argument of a function, and no propquery alongside it. If we are querying/altering a libctx, there is a very high chance that we require propquery to fetch something from it; the fact that, in our *current* implementation/plans, a function taking libctx as an argument does not use/support propquery for accomplishing its task, does not exclude that in the future part of that task might involve fetching another thing from the passed libctx. Given that once it's out in a release that function will stay with us for years to come, we should make extra sure we have a very solid argument covering the current and foreseeable future of that function, even at the cost of having a propquery argument ignored by the current implementation of that function, and marking it down as unused but reserved for future use in the documentation. Note that we currently have functions that take both libctx and propq, but they are not one after the other, eg. `EVP_PKEY_CTX_new_from_pkey(libctx, pkey, propq)`, if we agree that a libctx argument should always come with an attached porpq argument, there is no reason to separate them *Note2*: (expanding on BN_CTX as an optional auxiliary object) In the lifetime of a single high level RSA/DH/DSA/EC operation we have performance benefits from avoiding frequent heap (re)allocations, so we have this openssl specific object as a short-lived stack-like cache, interposing between malloc/realloc/free and the various BN_this() and BN_that() that compute the result of the high level operation. BN_CTX cannot be a global (or libctx-scoped) object, as we want to retain separation between unrelated high level operations and limit the surface for potential side-channel leakage. As a result most of the `BN_` functions that do not operate in-place have an optional `BN_CTX *` argument: the function will use the provided BN_CTX if it is passed, or create a temporary one if "nothing/NULL" is passed. Strictly speaking this BN_CTX object is not a functional requirement, as the implementation could easily replace all the `BN_CTX_get()` calls with conditional usage of either `BN_new()` or `BN_CTX_get()` and with corresponding conditional `BN_free()`, it is our choice to default to creating a fresh `BN_CTX` if the caller passes NULL, to improve code readability and maintainability. From the API consumer PoV, typing `BN_mul(r, a, b, NULL)` means "compute `r = a * b`, with no preexisting BN_CTX" and the implementation might (or might not) create a temporary BN_CTX to use internally or avoid the BN_CTX mechanism altogether. What do you (all) think about it? Nicola > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sat Sep 5 20:55:48 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 05 Sep 2020 22:55:48 +0200 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: <87a6y4t02z.wl-levitte@openssl.org> Hi, so... "importance" quite obviously carries different meaning to different people. What I see below is the meaning "having the longest life span" or possibly "being the biggest and most powerful resource". I've a different interpretation of "importance". Looking at EVP_XXX_fetch(), it's primary function is to get the caller an implementation of an algorithm, so a pretty important input for it to function is the name of that algorithm. Of course, it also needs to know where to go look and under what conditions (i.e. what properties need to apply), but in terms of importance for this function to work, I'd rank the algorithm name as the most important, it really can't do anything of value without it. With the in mind, the current (libctx, algoname, propq) argument order is... odd. I don't quite see if there was a suggestion to have (libctx, propq, algoname) as argument order; that's just plain weird in my mind. Those were late evening thoughts, I'll get back when I'm mulled over this a bit more. Cheers, Richard On Sat, 05 Sep 2020 12:44:51 +0200, Nicola Tuveri wrote: > > > On Sat, Sep 5, 2020, 12:13 Tim Hudson wrote: > > On Sat, Sep 5, 2020 at 6:38 PM Nicola Tuveri wrote: > > In most (if not all) cases in our functions, both libctx and propquery are optional > arguments, as we have global defaults for them based on the loaded config file. > As such, explicitly passing non-NULL libctx and propquery, is likely to be an exceptional > occurrence rather than the norm. > > And that is where we have a conceptual difference, the libctx is always?used. If it is > provided as a NULL parameter then it is a shortcut to make the call to get the default or to > get the already set one. > Conceptually it is always required for the function to operate. > > And the conceptual issue is actually important here - all of these functions?require the > libctx to do their work - if it is not available?then they are unable to do their work. > We just happen to have a default-if-NULL. > > If C offered the ability to default a parameter if not provided (and many languages offer > that) I would expect we would be using it.? > But it doesn't - we are coding in C. > > So it is really where-is-what-this-function-needs-coming-from that actually is the important > thing - the source of the information the function needs to make its choice. > It isn't which algorithm is being selected - the critical thing is from which pool of > algorithm implementations are we operating. The pool must be specified (this is C code), but > we have a default value. > > And that is why I think the conceptual approach here is getting confused by the arguments > appearing to be optional - conceptually they are not - we just have a defaulting mechanism and > that isn't the same conceptually as the arguments actually being optional. > > Clearer? > > It's not yet clear to me the distinction you are trying to make. > > I'll try to spell out what I extrapolated from your answer, and I apologize in advance if I am > misunderstanding your argument, please be patient and correct me in that case so I can better > understand your point!? > > It seems to me you are making a conceptual difference between > - a function that internally requires an instance of foo to work (and has a default if foo is > given as NULL among the arguments); e.g libctx is necessary for a fetch, if a NULL libctx is given > a mechanism is in place to retrieve the global default one > - a function that internally uses an instance of foo only if a non-NULL one is passed as argument; > e.g. bnctx, if the user provides it this is used by the callee and passed to its callee, if the > user passes NULL the function creates a fresh one for itself and/or its callees > > But as a consumer of the API that difference is not visible and probably not even interesting, as > we are programming in C and passing pointers, there are certain arguments that are required and > must be passed as valid pointers, others that appear optional because as a consumer of that API I > can pass NULL and let the function internally default to a reasonable behavior (and whatever this > "reasonable behavior" is ? whether the first or the second case from above, or another one I did > not list ?, it's part of the documentation of that API). > > IMHO, in the consumer POV, libctx and propq are optional arguments (even in C where optional or > default arguments do not technically exist and the caller needs to always specify a value for each > argument, which are always positional) in the sense that they can pass NULL as a value rather than > a pointer to a fully instantiated object of the required type. > Even more so given that, excluding a minority of cases, we can expect consumers of the APIs taking > libctx and propq as arguments to pass NULL for both of them and rely on the openssl config > mechanism. > > So while I agree with Tim that sometime it is valuable to make a difference among the consequences > of passing NULL as arguments in the context of one kind of function and another, I believe the > place for that is the documentation not its signature. > The signature of the function should be designed for consumer usability, and the conventional > pattern there seems to be > - required args > - optional args > - callback+cb_args > and inside each group the "importance" factor should be the secondary sorting criteria.? > > "importance" is probably going to be affected by the difference you are making (or my > understanding of it): e.g. if a function took both libctx and bnctx, the fact that a valid > pre-existing libctx is required to work (and a global already existing one will be retrieved in > case none is given), while a fresh short-lived bnctx is going to be created only for the lifetime > of the called function in case none is given seems to indicate that libctx is of vital importance > for the API functionality, while bnctx is of minor relevance.? > > But... going this way as a generalized approach, would bring us to the "add in the middle" > scenario that we'd like to avoid.? > I recognize that this is a point you already made in your original writeup, as the tendency of > "add to the end" to naturally degrade into "add in the middle". > > So, my question is: if "degradable add to the end" (where "degradable" only happens rarely and for > good reasons) seems the one that in the end produces signatures matching (IMHO) the conventional > usability patterns expected by consumers of the API, is it such a dramatic conclusion that we want > to exclude it? > > Or is your point that we are writing in C, all the arguments are positional, none is ever really > optional, there is no difference between passing a `(void*) NULL` or a valid `(TYPE*) ptr` as the > value of a `TYPE *` argument, so "importance" is the only remaining sorting criteria, hence > (libctx, propq) are always the most important and should go to the beginning of the args list > (with the exception of the `self/this` kind of argument that always goes first)?? > > Nicola > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tjh at cryptsoft.com Sat Sep 5 21:18:21 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Sun, 6 Sep 2020 07:18:21 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <87a6y4t02z.wl-levitte@openssl.org> References: <87a6y4t02z.wl-levitte@openssl.org> Message-ID: On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte wrote: > I'd rank the algorithm name as the most important, it really can't do > anything of value without it. > It also cannot do anything without knowing which libctx to use. Look at the implementation. Without the libctx there is no "from-where" to specify. This is again hitting the concept of where do things come from and what is a default. Once "global" disappears as such, logically everything comes from a libctx. Your argument is basically "what" is more important than "from" or "where". And the specific context here is where you see "from" or "where" can be defaulted to a value so it can be deduced so it isn't (as) important in the API. That would basically indicate you would (applying the same pattern/rule in a different context) change: *int EVP_PKEY_get_int_param(EVP_PKEY *pkey, const char *key_name, int *out);* To the following (putting what you want as the most important rather than from): *int EVP_PKEY_get_int_param(char *key_name, EVP_PKEY *pkey, int *out);* Or pushing it right to the end after the output parameter: *int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey);* The context of where things come from is actually the most critical item in any of the APIs we have. Even though what you want to get from where you want to get it is in the point of the API call you need to specify where from first as that context sets the frame of the call. Think of it around this way - we could have an implementation where we remember the last key that we have used and allow you to simply indicate you use the last key or if we didn't want the last key used to be able to specify it via a non-NULL pointer. This isn't that unusual an API but not something I'm suggesting we add - just trying to get the point across that you are still thinking of global and libctx as something super special with an exception in its handling rather than applying a general rule which is pretty much what we use everywhere else. And in which case where you generally don't provide a reference as there is some default meaning for it in general and can provide a reference for that sort of API would this make sense to you: *int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey);* If pkey is NULL then you use the last key that you referenced, if it is not then you use the specified pkey. For the application the specific key_name is the most important thing (using your argument that basically states the "what" is what counts). I would suggest that you really would still want to place the EVP_PKEY first - even if you had a defaulting mechanism of referring to the last key used. Conceptually you always have to have knowledge of from-where when you are performing a function. And that *context* is what is the most important. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sun Sep 6 06:02:50 2020 From: levitte at openssl.org (Richard Levitte) Date: Sun, 06 Sep 2020 08:02:50 +0200 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <87a6y4t02z.wl-levitte@openssl.org> Message-ID: <878sdntpbp.wl-levitte@openssl.org> There are many red herrings in here, and I would argue that trying to be too uniform in the way you think about all functions may be harmful, because not all functions are classified the same. We cannot deny that many of our interfaces have an OOP flair. We may be programming in C, but we very obviously have that kind of pattern, a "poor man's OOP" in C. So speaking about our interfaces in OOP terms is not far fetched, as long as we keep in mind that we can only take the argument so far. I would argue that EVP_XXX_get_whatever() / EVP_XXX_get_whatever() are classic accessors, and I assume that we have all been brought up with the description of "this" as the hidden first argument to any class method in C++, so it's not very far fetched to emulate that in C by making the instance you want details from or change details of as the (explicit) first argument. I would further argue that EVP_XXX_fetch() is a constructor (of an instance of EVP_XXX), and that with the assumption that there is no "this" in a constructor, the discussion about the arguments and their order must be different. What I hear, even though not in such terms, is an argument of the what the library context is and how that should affect the interface. In relation to EVP_XXX_fetch(), it seems to be more of a factory (or strictly speaking, the pool of resources, with hidden factory functions), and depending on the factory model you lean on, it might or might not be sensible to have it as first argument. My you, I'm trying quite hard to see it from a fresh user experience (as far as I can imagine it... after all, 20ish years with my fingers deep in OpenSSL entrails makes you not so fresh). I think, BTW, that this really comes down to how we view the library context. So far, I've seen all these interpretations (not all said explicitly, but clearly visible in code or how we argue about it): - framework - scope (I'm unsure if that differs much from framework) - factory / factory pool - bag of resources Personally, I have zero problems viewing it as all of these combined, but that requires us to be clear on how it's used in different places. Cheers, Richard On Sat, 05 Sep 2020 23:18:21 +0200, Tim Hudson wrote: > > > On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte wrote: > > I'd rank the algorithm name as the most important, it really can't do > anything of value without it. > > It also cannot do anything without knowing which libctx to use. Look at the implementation. > Without the libctx there is no "from-where" to specify.? > > This is again hitting the concept of where do things come from and what is a default. > Once "global" disappears as such, logically everything comes from a libctx. > > Your argument is basically "what" is more important than "from" or "where". > And the specific context here is where you see "from" or "where" can be defaulted to a value so it > can be deduced so it isn't (as) important in the API. > > That would basically indicate you would (applying the same pattern/rule in a different context) > change: > > int EVP_PKEY_get_int_param(EVP_PKEY *pkey, const char *key_name, int *out); > > To the following (putting what you want as the most important rather than from): > > int EVP_PKEY_get_int_param(char *key_name, EVP_PKEY *pkey, int *out); > > Or pushing it right to the end after the output parameter: > > int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey); > > The context of where things come from is actually the most critical item in any of the APIs we > have. > Even though what you want to get from where you want to get it is in the point of the API call you > need to specify where from first as that context sets the frame of the call. > > Think of it around this way - we could have an implementation where we remember the last key that > we have used and allow you to simply indicate you use the last key or if we didn't want the last > key used to be able to specify it via a non-NULL pointer. This isn't that unusual an API but not > something I'm suggesting we add - just trying to get the point across that you are still thinking > of global and libctx as something super special with an exception in its handling rather than > applying a general rule which is pretty much what we use everywhere else. > > And in which case where you generally don't provide a reference as there is some default meaning > for it in general and can provide a reference for that sort of API would this make sense to you: > > int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey); > > If pkey is NULL then you use the last key that you referenced, if it is not then you use the > specified pkey. For the application the specific key_name is the most important thing (using your > argument that basically states the "what" is what counts).? > > I would suggest that you really would still want to place the EVP_PKEY first - even if you had a > defaulting mechanism of referring to the last key used. Conceptually you always have to have > knowledge of from-where when you are performing a function. And that *context* is what is the most > important. > > Tim. > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From shane.lontis at oracle.com Sun Sep 6 21:40:53 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Mon, 7 Sep 2020 07:40:53 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <878sdntpbp.wl-levitte@openssl.org> References: <87a6y4t02z.wl-levitte@openssl.org> <878sdntpbp.wl-levitte@openssl.org> Message-ID: The example given was EVP_PKEY_get_() and from the API name it is fairly clear what the first param should be EVP_PKEY *pkey (the API tells you this). For the fetch case, I still think that the algorithm is the most important param. Libctx, propq are optional parameters as far as I am concerned. If it is decided that the libctx is more important then the API should really be something like this.. OSSL_LIBCTX_MD_fetch(), (and I dont know if that is a good idea.).. In some places where libctx is used it is a second class parameter whose only job is to perform a sub task of fetching during a bigger operation (such as in a load), And in these cases it should not be the first parameter.. Shane > On 6 Sep 2020, at 4:02 pm, Richard Levitte wrote: > > There are many red herrings in here, and I would argue that trying to > be too uniform in the way you think about all functions may be > harmful, because not all functions are classified the same. > > We cannot deny that many of our interfaces have an OOP flair. We may > be programming in C, but we very obviously have that kind of pattern, > a "poor man's OOP" in C. So speaking about our interfaces in OOP > terms is not far fetched, as long as we keep in mind that we can only > take the argument so far. > > I would argue that EVP_XXX_get_whatever() / EVP_XXX_get_whatever() are > classic accessors, and I assume that we have all been brought up with > the description of "this" as the hidden first argument to any class > method in C++, so it's not very far fetched to emulate that in C by > making the instance you want details from or change details of as the > (explicit) first argument. > > I would further argue that EVP_XXX_fetch() is a constructor (of an > instance of EVP_XXX), and that with the assumption that there is no > "this" in a constructor, the discussion about the arguments and their > order must be different. > > What I hear, even though not in such terms, is an argument of the > what the library context is and how that should affect the interface. > In relation to EVP_XXX_fetch(), it seems to be more of a factory (or > strictly speaking, the pool of resources, with hidden factory > functions), and depending on the factory model you lean on, it might > or might not be sensible to have it as first argument. My you, I'm > trying quite hard to see it from a fresh user experience (as far as I > can imagine it... after all, 20ish years with my fingers deep in > OpenSSL entrails makes you not so fresh). > > I think, BTW, that this really comes down to how we view the library > context. So far, I've seen all these interpretations (not all said > explicitly, but clearly visible in code or how we argue about it): > > - framework > - scope (I'm unsure if that differs much from framework) > - factory / factory pool > - bag of resources > > Personally, I have zero problems viewing it as all of these combined, > but that requires us to be clear on how it's used in different places. > > Cheers, > Richard > > On Sat, 05 Sep 2020 23:18:21 +0200, > Tim Hudson wrote: >> >> >> On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte wrote: >> >> I'd rank the algorithm name as the most important, it really can't do >> anything of value without it. >> >> It also cannot do anything without knowing which libctx to use. Look at the implementation. >> Without the libctx there is no "from-where" to specify. >> >> This is again hitting the concept of where do things come from and what is a default. >> Once "global" disappears as such, logically everything comes from a libctx. >> >> Your argument is basically "what" is more important than "from" or "where". >> And the specific context here is where you see "from" or "where" can be defaulted to a value so it >> can be deduced so it isn't (as) important in the API. >> >> That would basically indicate you would (applying the same pattern/rule in a different context) >> change: >> >> int EVP_PKEY_get_int_param(EVP_PKEY *pkey, const char *key_name, int *out); >> >> To the following (putting what you want as the most important rather than from): >> >> int EVP_PKEY_get_int_param(char *key_name, EVP_PKEY *pkey, int *out); >> >> Or pushing it right to the end after the output parameter: >> >> int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey); >> >> The context of where things come from is actually the most critical item in any of the APIs we >> have. >> Even though what you want to get from where you want to get it is in the point of the API call you >> need to specify where from first as that context sets the frame of the call. >> >> Think of it around this way - we could have an implementation where we remember the last key that >> we have used and allow you to simply indicate you use the last key or if we didn't want the last >> key used to be able to specify it via a non-NULL pointer. This isn't that unusual an API but not >> something I'm suggesting we add - just trying to get the point across that you are still thinking >> of global and libctx as something super special with an exception in its handling rather than >> applying a general rule which is pretty much what we use everywhere else. >> >> And in which case where you generally don't provide a reference as there is some default meaning >> for it in general and can provide a reference for that sort of API would this make sense to you: >> >> int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey); >> >> If pkey is NULL then you use the last key that you referenced, if it is not then you use the >> specified pkey. For the application the specific key_name is the most important thing (using your >> argument that basically states the "what" is what counts). >> >> I would suggest that you really would still want to place the EVP_PKEY first - even if you had a >> defaulting mechanism of referring to the last key used. Conceptually you always have to have >> knowledge of from-where when you are performing a function. And that *context* is what is the most >> important. >> >> Tim. >> >> > -- > Richard Levitte levitte at openssl.org > OpenSSL Project https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!LBMCWzrxlPIM4uha9erT3Uyg_OADMapJ5oKM9cxIb8jSiKZk6rXTcJIPq5PFwnOnwQ$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Mon Sep 7 10:15:10 2020 From: mark at openssl.org (Mark J Cox) Date: Mon, 7 Sep 2020 11:15:10 +0100 Subject: When "failed CI" isn't a blocker Message-ID: So when we have a PR in a state where any CI is marked as failing I lump them into a single "failed CI" state. The stale (over 30 day old untouched) ones are shown below. But most of them (if not all) are not actually CI failures. Aside from fixing the CI, one solution would be a label "Ignore CI failure" which can be manually set by a committer who reviews the fail and it's harmless, then I could have the bot ignore failed CI when that label is present. (And perhaps the bot also resets the label if the CI gets restarted due to changes). That would help have things in the right state bucket and can be acted on/reminded properly. Mark at Sep7: failed CI ( 19 issues, median 276 days) 11464 days:37 [* mjc: travis timeout on one combination, could ignore] 11327 reviewed:commented days:177 [* mjc: same] 11288 branch: master, reviewed:commented days:180 [* mjc: same] 11257 branch: 1.1.1, branch: master, reviewed:approved days:178 [* mjc: same, ......] 11151 days:189 10797 branch: master, reviewed:commented days:150 10556 days:276 10465 days:293 9926 days:355 9603 days:355 9155 reviewed:commented days:229 8955 branch: 1.1.1, branch: master, reviewed:dismissed days:304 8115 reviewed:commented days:177 7921 reviewed:commented days:548 7914 reviewed:approved days:607 7380 reviewed:commented days:695 7051 milestone:Assessed, reviewed:commented days:744 4992 milestone:Assessed, reviewed:commented days:317 4338 milestone:Assessed, days:153 From levitte at openssl.org Mon Sep 7 18:49:24 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 07 Sep 2020 20:49:24 +0200 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <87a6y4t02z.wl-levitte@openssl.org> <878sdntpbp.wl-levitte@openssl.org> Message-ID: <875z8ptoaz.wl-levitte@openssl.org> On Sun, 06 Sep 2020 23:40:53 +0200, SHANE LONTIS wrote: > > If it is decided that the libctx is more important then the API > should really be something like this.. > OSSL_LIBCTX_MD_fetch(), (and I dont know if that is a good idea.).. I would rather not see that. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Wed Sep 9 09:41:56 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 09 Sep 2020 11:41:56 +0200 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: <87pn6vs2vv.wl-levitte@openssl.org> A few of the more active developers currently have a videocall meeting every tuesday, in the morning for us in Europe. We talked about this issue yesterday, and realised quite a few things. One pretty important thing to realise is that while many new functions take a library context and a property query string that are located together, that doesn't mean that they are the coupled pair that we made them out to be, quite the contrary. The library context has been called many things... during the vidcall yesterday, it was compared to "a global state", which could be a term that we can agree with, since its primary function is to be a collection of stuff that were previously global. The property query string, on the other hand, is only interesting for fetching implementations, so if it's to be conceptually coupled with anything, it's with the name of the algorithm that's being fetched. This is most visible when we pass a cipher or digest name to some provider-side implementations; they also always take a property query string (if we've missed a spot, please raise an issue). Do note that there are places where we pass a property query string without passing an algorithm name. That happen when the algorithm name is inferred from another object that's passed in. For example: EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_pkey(OPENSSL_CTX *libctx, EVP_PKEY *pkey, const char *propquery); This function would classically be used when you have a |pkey| with just domain parameters, and you want to generate a key from it. In this case, the algorithm name is inferred from the |pkey|. With this, it makes sense to conceptually decouple the library context and the property query string, and to view the passing of them to diverse functions in form of a pair as accidental. We can thereby talk about them separately. -------- Regarding the library context, when viewed as a global state, it makes sense to have it as a first argument where it's being passed, if at all. The question is, where should we actually pass it? We have a few different suggestions, in wording or in code, on the table: 1. Pass it as first argument everywhere. This is problematic, as "everywhere" is a *lot*, and if we do this, we might as well re-design the whole libcrypto API [*], and that's definitely not what OpenSSL 3.0 is about, quite the contrary. This has been partially done, with all the _with_libctx functions. As far as I've understood, these have been added on need basis, i.e. somewhere down the code path, a library context or a property query string is needed. I can't say if this gives any sense of completeness or consistency, viewed as an cohesive API, or if we stand any chance of getting there without a complete API re-design. Something to be noted is that it doesn't make sense to pass the library context everywhere, because it's already part of other structures that are passed. For example, any method structure, such as EVP_CIPHER, EVP_MD, etc are tied to a provider, which is in turn tied to a library context. Passing another library context to anything that includes one of those method structures would only be confusing. 2. Pass it when constructing different structures, mostly other context structures. As an example, EVP_PKEY_CTX_new_from_pkey() that I displayed above. There may be cases where we need to pass it directly to functions that aren't constructors, but I expect those cases to be relatively few. This has been done for some other structures as well, on an as needed basis: X509 *X509_new_with_libctx(OPENSSL_CTX *libctx, const char *propq); X509_STORE_CTX *X509_STORE_CTX_new_with_libctx(OPENSSL_CTX *libctx, const char *propq); (the following are internal only) int x509_set0_libctx(X509 *x, OPENSSL_CTX *libctx, const char *propq); int x509_crl_set0_libctx(X509_CRL *x, OPENSSL_CTX *libctx, const char *propq); 3. Set a current library context, a pointer in a thread local variable. We already have support for that, which this function: OPENSSL_CTX *OPENSSL_CTX_set0_default(OPENSSL_CTX *libctx); The usage model is this: OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx); /* do stuff with |libctx| as implicit current global state */ OPENSSL_CTX_set0_default(prevctx) Looking at that list now, I realise that it goes from most intrusive to least intrusive, viewed as a public API. The third choice in particular would let any application or library just set their library context for the duration of the code that should be execute with that as a "global state", and restore it when done, leaving the rest of the OpenSSL calls untouched. Something to be noted is that model 2 and 3 is possible to combine, which could give us a smoother transition between the current API and whatever we design going forward. -------- Regarding the property query string, looking at it separate from the library context, the question remains where to put it, and a few proposals are on the table: 1. Put it last. 2. Put it next to the algorithm name or the object that an algorithm name is inferred from. 3. Set it "globally" with a thread local variable, a bit like what OPENSSL_CTX_set0_default() does for library contexts. For this model, it's been argued if it should simply be stored in the current library context, thereby avoiding to add another thread local variable (which, for all intents and purposes, is another actually global thing to deal with, even though on per-thread level). In my mind, model 2 would be more sensible than model 1, because of the implied tie between algorithm name and property query string. Also, even here, model 3 is possible to combine with model 2, and even with model 1. Regarding model 3, it must be said that there is potential for confusion on what it's supposed to do, replace the default property query string (settable with EVP_set_default_properties()), or merge with it. Remember that a property query string given through any XXX_fetch() function is temporarly merged with the default properties when looking for fitting algorithms. -------- Thoughts? Cheers, Richard [*] The OpenSSL API could do with a re-design, but that's for the farther future and requires a lot of thought and time. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tmraz at redhat.com Wed Sep 9 11:38:42 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 09 Sep 2020 13:38:42 +0200 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <87pn6vs2vv.wl-levitte@openssl.org> References: <87pn6vs2vv.wl-levitte@openssl.org> Message-ID: On Wed, 2020-09-09 at 11:41 +0200, Richard Levitte wrote: > > Regarding the library context, when viewed as a global state, it > makes > sense to have it as a first argument where it's being passed, if at > all. The question is, where should we actually pass it? We have a > few different suggestions, in wording or in code, on the table: > > 1. Pass it as first argument everywhere. This is problematic, as > "everywhere" is a *lot*, and if we do this, we might as well > re-design the whole libcrypto API [*], and that's definitely not > what OpenSSL 3.0 is about, quite the contrary. > > This has been partially done, with all the _with_libctx > functions. As far as I've understood, these have been added on > need basis, i.e. somewhere down the code path, a library context > or a property query string is needed. I can't say if this gives > any sense of completeness or consistency, viewed as an cohesive > API, or if we stand any chance of getting there without a > complete > API re-design. > > Something to be noted is that it doesn't make sense to pass the > library context everywhere, because it's already part of other > structures that are passed. For example, any method structure, > such as EVP_CIPHER, EVP_MD, etc are tied to a provider, which is > in turn tied to a library context. Passing another library > context to anything that includes one of those method structures > would only be confusing. > > 2. Pass it when constructing different structures, mostly other > context structures. As an example, EVP_PKEY_CTX_new_from_pkey() > that I displayed above. There may be cases where we need to pass > it directly to functions that aren't constructors, but I expect > those cases to be relatively few. > > This has been done for some other structures as well, on an as > needed basis: > > X509 *X509_new_with_libctx(OPENSSL_CTX *libctx, const char > *propq); > > X509_STORE_CTX *X509_STORE_CTX_new_with_libctx(OPENSSL_CTX > *libctx, > const char > *propq); > > (the following are internal only) > > int x509_set0_libctx(X509 *x, OPENSSL_CTX *libctx, const char > *propq); > int x509_crl_set0_libctx(X509_CRL *x, OPENSSL_CTX *libctx, > const char *propq); > > 3. Set a current library context, a pointer in a thread local > variable. We already have support for that, which this function: > > OPENSSL_CTX *OPENSSL_CTX_set0_default(OPENSSL_CTX *libctx); > > The usage model is this: > > OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx); > > /* do stuff with |libctx| as implicit current global state */ > > OPENSSL_CTX_set0_default(prevctx) > > Looking at that list now, I realise that it goes from most intrusive > to least intrusive, viewed as a public API. > > The third choice in particular would let any application or library > just set their library context for the duration of the code that > should be execute with that as a "global state", and restore it when > done, leaving the rest of the OpenSSL calls untouched. We could even provide a convenience thread local stack of lib contexts so the caller would not have to keep the old value but would just push the new libctx when entering and pop the old one when leaving. With that, I think the changes needed in the application code would be fairly simple and minimal. > Something to be noted is that model 2 and 3 is possible to combine, > which could give us a smoother transition between the current API and > whatever we design going forward. Although I have big sympathy with people that worked hard to add the various _with_libctx() calls I would say that keeping the new with_libctx variants would be too confusing. Especially for the reason we would not have a complete set of them anyway. The exception might be the low level EVP calls where we deal with the libctx directly and where the algorithm fetched is actually associated with the context. > -------- > > Regarding the property query string, looking at it separate from the > library context, the question remains where to put it, and a few > proposals are on the table: > > 1. Put it last. > > 2. Put it next to the algorithm name or the object that an algorithm > name is inferred from. > > 3. Set it "globally" with a thread local variable, a bit like what > OPENSSL_CTX_set0_default() does for library contexts. > > For this model, it's been argued if it should simply be stored in > the current library context, thereby avoiding to add another > thread local variable (which, for all intents and purposes, is > another actually global thing to deal with, even though on > per-thread level). > > In my mind, model 2 would be more sensible than model 1, because of > the implied tie between algorithm name and property query string. > Also, even here, model 3 is possible to combine with model 2, and > even > with model 1. I agree that the model 2 makes more sense than model 1. However it is also indicative of one thing - that the property query really does not make sense to be a parameter of things like X509_new(), because from the top level point of view of a caller you do not actually know for what purpose it will be later used. You might want a different property query to be used for the internal SHA1 digest of the certificate and a different property query when you want to verify a certificate signature. So again instead of trying to put property query as an additional member of higher level objects I'd say that using model 3 would make more sense to me here as well. Of course for the low level algorithm fetches the property query as parameter should stay. > Regarding model 3, it must be said that there is potential for > confusion > on what it's supposed to do, replace the default property query > string > (settable with EVP_set_default_properties()), or merge with it. > Remember that a property query string given through any XXX_fetch() > function is temporarly merged with the default properties when > looking > for fitting algorithms. Here I would actually argue, that there should be another property query in the libctx in addition to the default, that would have the exactly same semantics as the propq parameter has now and for the functions with the propq parameter it even would not be applied. How to name it so it won't be confused with the default property query, that's hard to say though. -- 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.] From kurt at roeckx.be Wed Sep 9 12:03:30 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 9 Sep 2020 14:03:30 +0200 Subject: Beta1 PR deadline In-Reply-To: References: Message-ID: <20200909120330.GA2514533@roeckx.be> On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: > Please can anyone with PRs that they wish to have included in OpenSSL > 3.0 beta1 ensure that they are merged to master by 8th September. So that date has passed now. Can someone give an overview of what we think is still needed to be done before the beta 1 release? Are there open PRs for everything? Do we a milestone on github to indicate which PRs need to go in before beta1? Kurt From paul.dale at oracle.com Wed Sep 9 12:29:46 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 9 Sep 2020 22:29:46 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <87pn6vs2vv.wl-levitte@openssl.org> Message-ID: <3313F349-F915-430F-BEAD-7817BB9F88D9@oracle.com> > On 9 Sep 2020, at 9:38 pm, Tomas Mraz wrote: > > We could even provide a convenience thread local stack of lib contexts > so the caller would not have to keep the old value but would just push > the new libctx when entering and pop the old one when leaving. With > that, I think the changes needed in the application code would be > fairly simple and minimal. Let?s not overcomplicate things. We went through this discussion back when this was introduced. Push is: OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx); Pop is: OPENSSL_CTX_set0_default(prevctx) I don?t see having an explicit stack of these is of any benefit to anything but unwarranted complexity. Pauli From openssl at openssl.org Wed Sep 9 12:39:50 2020 From: openssl at openssl.org (OpenSSL) Date: Wed, 9 Sep 2020 12:39:50 +0000 Subject: OpenSSL Security Advisory Message-ID: <20200909123950.GA20454@openssl.org> -----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----- From beldmit at gmail.com Wed Sep 9 12:44:53 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 9 Sep 2020 15:44:53 +0300 Subject: OpenSSL Security Advisory In-Reply-To: <20200909123950.GA20454@openssl.org> References: <20200909123950.GA20454@openssl.org> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Wed Sep 9 12:51:23 2020 From: mark at openssl.org (Mark J Cox) Date: Wed, 9 Sep 2020 13:51:23 +0100 Subject: OpenSSL Security Advisory In-Reply-To: References: <20200909123950.GA20454@openssl.org> Message-ID: 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: >> 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 From beldmit at gmail.com Wed Sep 9 13:07:48 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 9 Sep 2020 16:07:48 +0300 Subject: OpenSSL Security Advisory In-Reply-To: References: <20200909123950.GA20454@openssl.org> Message-ID: 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: > >> 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 > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Wed Sep 9 13:16:12 2020 From: mark at openssl.org (Mark J Cox) Date: Wed, 9 Sep 2020 14:16:12 +0100 Subject: OpenSSL Security Advisory In-Reply-To: References: <20200909123950.GA20454@openssl.org> Message-ID: 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 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 > > > > -- > SY, Dmitry Belyavsky From beldmit at gmail.com Wed Sep 9 13:23:36 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 9 Sep 2020 16:23:36 +0300 Subject: OpenSSL Security Advisory In-Reply-To: References: <20200909123950.GA20454@openssl.org> Message-ID: 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 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 > > > > > > > > -- > > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Sep 9 13:38:20 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 09 Sep 2020 15:38:20 +0200 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <87pn6vs2vv.wl-levitte@openssl.org> Message-ID: <87ft7rrrxv.wl-levitte@openssl.org> On Wed, 09 Sep 2020 13:38:42 +0200, Tomas Mraz wrote: > > Regarding model 3, it must be said that there is potential for > > confusion > > on what it's supposed to do, replace the default property query > > string > > (settable with EVP_set_default_properties()), or merge with it. > > Remember that a property query string given through any XXX_fetch() > > function is temporarly merged with the default properties when > > looking > > for fitting algorithms. > > Here I would actually argue, that there should be another property > query in the libctx in addition to the default, that would have the > exactly same semantics as the propq parameter has now and for the > functions with the propq parameter it even would not be applied. How to > name it so it won't be confused with the default property query, that's > hard to say though. "current" was mentioned several times during yesterday's videocall, that could actually be used for a name. I'm ok with putting such a property query string into the library context, As Long As there is the understanding that it's not *tied* to that library context, i.e. it can be used to pass a property query string on to a provider implementation, to be used with whatever library context the provider uses (the FIPS module has its own, for example). Side note: the function OPENSSL_CTX_set0_default() is a confusing name, as there's an internal default ("default default", "ultimate default"?) library context already, it's possible that we should rename that to OPENSSL_CTX_set0_current(). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tmraz at redhat.com Wed Sep 9 14:08:10 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 09 Sep 2020 16:08:10 +0200 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <3313F349-F915-430F-BEAD-7817BB9F88D9@oracle.com> References: <87pn6vs2vv.wl-levitte@openssl.org> <3313F349-F915-430F-BEAD-7817BB9F88D9@oracle.com> Message-ID: <5d416b0dc0b4aab55df1a94d67333abbf9a81240.camel@redhat.com> On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote: > > On 9 Sep 2020, at 9:38 pm, Tomas Mraz wrote: > > > > We could even provide a convenience thread local stack of lib > > contexts > > so the caller would not have to keep the old value but would just > > push > > the new libctx when entering and pop the old one when leaving. With > > that, I think the changes needed in the application code would be > > fairly simple and minimal. > > Let?s not overcomplicate things. > We went through this discussion back when this was introduced. > > > Push is: > OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx); > > Pop is: > OPENSSL_CTX_set0_default(prevctx) > > > I don?t see having an explicit stack of these is of any benefit to > anything but unwarranted complexity. There is one thing where it would be IMO helpful - let's say libcurl has a callback into a calling application. With the current API in libcurl API calls you would put the calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx ) at the beginning and end. But you would have to save the prevctx somewhere in the libcurl context structure because on callbacks you would have to temoprarily reset the context to the prevctx value. If we implemented real stack it would not be needed. But yeah, I am not sure this convenience is that much worth it. -- 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.] From levitte at openssl.org Wed Sep 9 14:23:12 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 09 Sep 2020 16:23:12 +0200 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <5d416b0dc0b4aab55df1a94d67333abbf9a81240.camel@redhat.com> References: <87pn6vs2vv.wl-levitte@openssl.org> <3313F349-F915-430F-BEAD-7817BB9F88D9@oracle.com> <5d416b0dc0b4aab55df1a94d67333abbf9a81240.camel@redhat.com> Message-ID: <87eenbrpv3.wl-levitte@openssl.org> On Wed, 09 Sep 2020 16:08:10 +0200, Tomas Mraz wrote: > > On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote: > > > On 9 Sep 2020, at 9:38 pm, Tomas Mraz wrote: > > > > > > We could even provide a convenience thread local stack of lib > > > contexts > > > so the caller would not have to keep the old value but would just > > > push > > > the new libctx when entering and pop the old one when leaving. With > > > that, I think the changes needed in the application code would be > > > fairly simple and minimal. > > > > Let?s not overcomplicate things. > > We went through this discussion back when this was introduced. > > > > > > Push is: > > OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx); > > > > Pop is: > > OPENSSL_CTX_set0_default(prevctx) > > > > > > I don?t see having an explicit stack of these is of any benefit to > > anything but unwarranted complexity. > > There is one thing where it would be IMO helpful - let's say libcurl > has a callback into a calling application. With the current API in > libcurl API calls you would put the > calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx > ) at the beginning and end. But you would have to save the prevctx > somewhere in the libcurl context structure because on callbacks you > would have to temoprarily reset the context to the prevctx value. If we > implemented real stack it would not be needed. But yeah, I am not sure > this convenience is that much worth it. A stack becomes potentially extra churn in memory allocation for every push, and wondering what to do with the stack if the stack functionality fails. So yeah, I'm thinking that it's not really worth it. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Wed Sep 9 20:27:26 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 10 Sep 2020 06:27:26 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <5d416b0dc0b4aab55df1a94d67333abbf9a81240.camel@redhat.com> References: <87pn6vs2vv.wl-levitte@openssl.org> <3313F349-F915-430F-BEAD-7817BB9F88D9@oracle.com> <5d416b0dc0b4aab55df1a94d67333abbf9a81240.camel@redhat.com> Message-ID: Still no need for the added complexity: Push: OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx); Pop is: OPENSSL_CTX_set0_default(prevctx); Push before callback: OPENSSL_CTX_set0_default(prevctx); Pop after callback: prevctx = OPENSSL_CTX_set0_default(libctx); or OPENSSL_CTX_set0_default(libctx); Depending if we want to support call backs changing the Libctx directly ? we should choose one and always recommend that. Also the auto allocation of storage for the second on stack cannot fail, so no error checking spaghetti. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 10 Sep 2020, at 12:08 am, Tomas Mraz wrote: > > On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote: >>> On 9 Sep 2020, at 9:38 pm, Tomas Mraz wrote: >>> >>> We could even provide a convenience thread local stack of lib >>> contexts >>> so the caller would not have to keep the old value but would just >>> push >>> the new libctx when entering and pop the old one when leaving. With >>> that, I think the changes needed in the application code would be >>> fairly simple and minimal. >> >> Let?s not overcomplicate things. >> We went through this discussion back when this was introduced. >> >> >> Push is: >> OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx); >> >> Pop is: >> OPENSSL_CTX_set0_default(prevctx) >> >> >> I don?t see having an explicit stack of these is of any benefit to >> anything but unwarranted complexity. > > There is one thing where it would be IMO helpful - let's say libcurl > has a callback into a calling application. With the current API in > libcurl API calls you would put the > calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx > ) at the beginning and end. But you would have to save the prevctx > somewhere in the libcurl context structure because on callbacks you > would have to temoprarily reset the context to the prevctx value. If we > implemented real stack it would not be needed. But yeah, I am not sure > this convenience is that much worth it. > > -- > 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.] -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu Sep 10 02:12:14 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 10 Sep 2020 12:12:14 +1000 Subject: More GitHub labels Message-ID: Just wondering if we should have two new labels: ?hold: tests needed? and ?hold: documentation needed? labels? There are a number of PRs that come through where one or both of these are missing (this post posed by @slontis?s comment in 12826 ). These would give a clear indication of what additional material is being expected as per CLA required and need rebase. A ?hold: code needed" seems less useful :) Thoughts or should we just add them? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Thu Sep 10 06:03:02 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 10 Sep 2020 06:03:02 +0000 Subject: More GitHub labels In-Reply-To: References: Message-ID: > Just wondering if we should have two new labels: ?hold: tests needed? and??hold: documentation needed? labels? > There are a number of PRs that come through where one or both of these are missing missing. The two use cases you mention are actually better handled by a change request (via GitHub review) instead of a label: A team member can formulate a change request to block the merging. Here he has more freedom to formulate what needs to be done. This includes your two use cases, as well as the use case for the label [hold: need rebase]. The problem with it is that currently we count only approvals and don?t consider unresolved change requests as a blocker. 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. Matthias From paul.dale at oracle.com Thu Sep 10 06:10:44 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 10 Sep 2020 16:10:44 +1000 Subject: More GitHub labels In-Reply-To: References: Message-ID: <2DD8E56D-40E9-4F87-B4BB-02853B138F52@oracle.com> Matthias, Your suggestion seems workable too. PRs are merged with outstanding change requests indicated ? a reviewer comments, the comments are addressed then a different reviewer approves without the original review being removed. The labels are a bit more in your face. A hybrid ?hold: required changes see review/comments? might be workable. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 10 Sep 2020, at 4:03 pm, Dr. Matthias St. Pierre wrote: > >> Just wondering if we should have two new labels: ?hold: tests needed? and ?hold: documentation needed? labels? >> There are a number of PRs that come through where one or both of these are missing missing. > > The two use cases you mention are actually better handled by a change request (via GitHub review) instead of a label: > A team member can formulate a change request to block the merging. Here he has more freedom to formulate what > needs to be done. This includes your two use cases, as well as the use case for the label [hold: need rebase]. > > The problem with it is that currently we count only approvals and don?t consider unresolved change requests > as a blocker. 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. > > Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Thu Sep 10 06:19:51 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 10 Sep 2020 06:19:51 +0000 Subject: More GitHub labels In-Reply-To: <2DD8E56D-40E9-4F87-B4BB-02853B138F52@oracle.com> References: <2DD8E56D-40E9-4F87-B4BB-02853B138F52@oracle.com> Message-ID: <3b7c951b5e524fb1948468d9dd003ad0@ncp-e.com> > Your suggestion seems workable too. ?PRs are merged with outstanding change requests indicated > ? a reviewer comments, the comments are addressed then a different reviewer approves without > the original review being removed. ?The labels are a bit more in your face. ?A hybrid ?hold: required changes see review/comments? might be workable. GitHub can be configured to require approval. It then gives a clear visual indication that the PR is not ready to be merged, and the Merge button is greyed out. This should be obvious enough, even more obvious than a label, which can also easily be ignored. Of course, our merge procedure circumvents the merge button, I'm only talking about the visual indicator. Alternatively, the pre-receive-hook on the git.openssl.org server could enforce the policy by checking the reviewer state via GitHub API queries. Matthias From Matthias.St.Pierre at ncp-e.com Thu Sep 10 06:20:07 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 10 Sep 2020 06:20:07 +0000 Subject: More GitHub labels In-Reply-To: References: Message-ID: <16e26f8738d84e0e8dfcb74dae20c3bb@ncp-e.com> > ... 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. Matthias From beldmit at gmail.com Thu Sep 10 06:26:52 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 10 Sep 2020 09:26:52 +0300 Subject: More GitHub labels In-Reply-To: <16e26f8738d84e0e8dfcb74dae20c3bb@ncp-e.com> References: <16e26f8738d84e0e8dfcb74dae20c3bb@ncp-e.com> Message-ID: On Thu, Sep 10, 2020 at 9:20 AM Dr. Matthias St. Pierre < Matthias.St.Pierre at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Sun Sep 6 22:28:50 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 06 Sep 2020 18:28:50 -0400 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <878sdntpbp.wl-levitte@openssl.org> References: <87a6y4t02z.wl-levitte@openssl.org> <878sdntpbp.wl-levitte@openssl.org> Message-ID: <16237.1599431330@localhost> Richard Levitte wrote: > There are many red herrings in here, and I would argue that trying to > be too uniform in the way you think about all functions may be > harmful, because not all functions are classified the same. > We cannot deny that many of our interfaces have an OOP flair. We may > be programming in C, but we very obviously have that kind of pattern, > a "poor man's OOP" in C. So speaking about our interfaces in OOP > terms is not far fetched, as long as we keep in mind that we can only > take the argument so far. It would be very nice if there was object-focused (rather than "oriented") documentation for OpenSSL. Tell me what all the structures/typedefs are, and then tell me what things operate on them. (I tried to start documentation like that for the CMS parts, but I got distracted.) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From David at von-Oheimb.de Tue Sep 8 11:31:17 2020 From: David at von-Oheimb.de (David von Oheimb) Date: Tue, 8 Sep 2020 13:31:17 +0200 Subject: Beta1 PR deadline In-Reply-To: References: Message-ID: <7c622327-ac2d-1bf3-ef03-75e4584a2795@von-Oheimb.de> Hi Matt et al., thanks to good collaboration with OTC members I've been able to get approved most of my open PRs that would be good be included before feature freeze, while a few such PRs appear 'nearly' approved. Given the 24-hours grace period, the PRs #12478 , #12741 , and #12769 won't make it today, or is there a chance to still get them into beta1 a little later? ??? David On 26.08.20 17:58, Matt Caswell wrote: > Hi all > > The OMC had a meeting today. > > Please can anyone with PRs that they wish to have included in OpenSSL > 3.0 beta1 ensure that they are merged to master by 8th September. > > Note in particular that there is no PR at the moment to incorporate SM2 > asymmetric encryption into OpenSSL 3.0. This feature currently exists in > 1.1.1, so if no PR emerges by the above date then this feature is liable > to be dropped in 3.0. (Note: PRs for SM2 signatures *do* exist and are > expected to be present). > > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.von.Oheimb at siemens.com Tue Sep 8 14:38:36 2020 From: David.von.Oheimb at siemens.com (David von Oheimb) Date: Tue, 8 Sep 2020 16:38:36 +0200 Subject: Beta1 PR deadline In-Reply-To: References: Message-ID: <0065b7b6-e953-6233-c65a-5b946f6204cc@siemens.com> Hi Matt et al., thanks to good collaboration with OTC members I've been able to get approved most of my open PRs that would be good be included before feature freeze, while a few such PRs appear 'nearly' approved. Given the 24-hours grace period, the PRs #12478 , #12741 , and #12769 won't make it today, or is there a chance to still get them into beta1 a little later? ??? David On 26.08.20 17:58, Matt Caswell wrote: > Hi all > > The OMC had a meeting today. > > Please can anyone with PRs that they wish to have included in OpenSSL > 3.0 beta1 ensure that they are merged to master by 8th September. > > Note in particular that there is no PR at the moment to incorporate SM2 > asymmetric encryption into OpenSSL 3.0. This feature currently exists in > 1.1.1, so if no PR emerges by the above date then this feature is liable > to be dropped in 3.0. (Note: PRs for SM2 signatures *do* exist and are > expected to be present). > > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nl0 at von-Oheimb.de Thu Sep 10 08:06:35 2020 From: nl0 at von-Oheimb.de (David von Oheimb) Date: Thu, 10 Sep 2020 10:06:35 +0200 Subject: Beta1 PR deadline In-Reply-To: <20200909120330.GA2514533@roeckx.be> References: <20200909120330.GA2514533@roeckx.be> Message-ID: On 09.09.20 14:03, Kurt Roeckx wrote: > On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: >> Please can anyone with PRs that they wish to have included in OpenSSL >> 3.0 beta1 ensure that they are merged to master by 8th September. > So that date has passed now. Can someone give an overview of what > we think is still needed to be done before the beta 1 release? > Are there open PRs for everything? Do we a milestone on github to > indicate which PRs need to go in before beta1? As far as my PRs are concerned (most of which have been related to some extent to the CMP contribution): Thanks to intensified exchange with OTC reviewers, everything that I see urgent for inclusion before feature freeze has either been merged already or meanwhile has been approved and is going to be merged by tomorrow. Just very few fixes/cleanups are not yet fully reviewed but I believe they can still be handled during the beta phase. ??? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu Sep 10 09:52:26 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 10 Sep 2020 12:52:26 +0300 Subject: Beta1 PR deadline In-Reply-To: <20200909120330.GA2514533@roeckx.be> References: <20200909120330.GA2514533@roeckx.be> Message-ID: Dear Kurt, I have 3 regression bugs, but I hope they can be dealt with after beta1. On Wed, Sep 9, 2020 at 3:03 PM Kurt Roeckx wrote: > On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: > > Please can anyone with PRs that they wish to have included in OpenSSL > > 3.0 beta1 ensure that they are merged to master by 8th September. > > So that date has passed now. Can someone give an overview of what > we think is still needed to be done before the beta 1 release? Are > there open PRs for everything? Do we a milestone on github to > indicate which PRs need to go in before beta1? > > > Kurt > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Sep 10 10:40:08 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Sep 2020 11:40:08 +0100 Subject: Beta1 PR deadline In-Reply-To: <20200909120330.GA2514533@roeckx.be> References: <20200909120330.GA2514533@roeckx.be> Message-ID: <2bc7adfe-29c9-f519-807a-04eddde1b633@openssl.org> On 09/09/2020 13:03, Kurt Roeckx wrote: > On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: >> Please can anyone with PRs that they wish to have included in OpenSSL >> 3.0 beta1 ensure that they are merged to master by 8th September. > > So that date has passed now. Can someone give an overview of what > we think is still needed to be done before the beta 1 release? Are > there open PRs for everything? Do we a milestone on github to > indicate which PRs need to go in before beta1? I believe the "blockers" to be: https://github.com/openssl/openssl/pull/12536 https://github.com/openssl/openssl/pull/12754 https://github.com/openssl/openssl/pull/12750 https://github.com/openssl/openssl/pull/12781 https://github.com/openssl/openssl/pull/12801 Aside from these there are potential PRs not yet opened but slated for beta1 regarding: - Refactor serialization? (owner: Richard) - lhash refactor? (owner: Me) - IG D.9 update? (owner: Shane) There's also this issue - but I'm not sure that it needs to be resolved for beta1: https://github.com/openssl/openssl/issues/12195 Matt From matt at openssl.org Thu Sep 10 11:24:18 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Sep 2020 12:24:18 +0100 Subject: Beta1 PR deadline In-Reply-To: <2bc7adfe-29c9-f519-807a-04eddde1b633@openssl.org> References: <20200909120330.GA2514533@roeckx.be> <2bc7adfe-29c9-f519-807a-04eddde1b633@openssl.org> Message-ID: <5c9515e2-52e4-74d3-3826-c8b87eccc7d1@openssl.org> On 10/09/2020 11:40, Matt Caswell wrote: > > > On 09/09/2020 13:03, Kurt Roeckx wrote: >> On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: >>> Please can anyone with PRs that they wish to have included in OpenSSL >>> 3.0 beta1 ensure that they are merged to master by 8th September. >> >> So that date has passed now. Can someone give an overview of what >> we think is still needed to be done before the beta 1 release? Are >> there open PRs for everything? Do we a milestone on github to >> indicate which PRs need to go in before beta1? > > > I believe the "blockers" to be: > > https://github.com/openssl/openssl/pull/12536 > https://github.com/openssl/openssl/pull/12754 > https://github.com/openssl/openssl/pull/12750 > https://github.com/openssl/openssl/pull/12781 > https://github.com/openssl/openssl/pull/12801 > > Aside from these there are potential PRs not yet opened but slated for > beta1 regarding: > - Refactor serialization? (owner: Richard) > - lhash refactor? (owner: Me) > - IG D.9 update? (owner: Shane) Oh, I think this last one might be: https://github.com/openssl/openssl/pull/12835 Matt > > There's also this issue - but I'm not sure that it needs to be resolved > for beta1: > https://github.com/openssl/openssl/issues/12195 > > Matt > From paul.dale at oracle.com Thu Sep 10 11:28:00 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 10 Sep 2020 21:28:00 +1000 Subject: Beta1 PR deadline In-Reply-To: <2bc7adfe-29c9-f519-807a-04eddde1b633@openssl.org> References: <20200909120330.GA2514533@roeckx.be> <2bc7adfe-29c9-f519-807a-04eddde1b633@openssl.org> Message-ID: Shane has done the IG D.9 work: it is in #12835 and is awaiting review. I think it should be in beta if possible. It?s mostly adding a second test case due to NIST changing guidance recently, so low risk and helpful for the lab. As Shane notes in 12801, there will be some conflicts generated over the FIPS error handling and self tests, hopefully they won?t slow progress. 12754 could be considered optional and something better should likely be done for 3.1 that what I?m planning there. With RAND_DRBG removed, there is nothing remotely comparable. Even RAND_DRBG is a bit of a stretch as a comparison. The API renaming discussion *must* reach a conclusion before beta. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 10 Sep 2020, at 8:40 pm, Matt Caswell wrote: > > > > On 09/09/2020 13:03, Kurt Roeckx wrote: >> On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: >>> Please can anyone with PRs that they wish to have included in OpenSSL >>> 3.0 beta1 ensure that they are merged to master by 8th September. >> >> So that date has passed now. Can someone give an overview of what >> we think is still needed to be done before the beta 1 release? Are >> there open PRs for everything? Do we a milestone on github to >> indicate which PRs need to go in before beta1? > > > I believe the "blockers" to be: > > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12536__;!!GqivPVa7Brio!O5gzpHuWIANvRtRYOHA9m7SK4SqMUb2uLzEGQbUrX9nFSRhT7-sA0F-JQc5z_l4$ > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12754__;!!GqivPVa7Brio!O5gzpHuWIANvRtRYOHA9m7SK4SqMUb2uLzEGQbUrX9nFSRhT7-sA0F-JseFWMvQ$ > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12750__;!!GqivPVa7Brio!O5gzpHuWIANvRtRYOHA9m7SK4SqMUb2uLzEGQbUrX9nFSRhT7-sA0F-J0OAUQ5s$ > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12781__;!!GqivPVa7Brio!O5gzpHuWIANvRtRYOHA9m7SK4SqMUb2uLzEGQbUrX9nFSRhT7-sA0F-JYPbPTZA$ > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12801__;!!GqivPVa7Brio!O5gzpHuWIANvRtRYOHA9m7SK4SqMUb2uLzEGQbUrX9nFSRhT7-sA0F-J_mL-S18$ > > Aside from these there are potential PRs not yet opened but slated for > beta1 regarding: > - Refactor serialization? (owner: Richard) > - lhash refactor? (owner: Me) > - IG D.9 update? (owner: Shane) > > There's also this issue - but I'm not sure that it needs to be resolved > for beta1: > https://urldefense.com/v3/__https://github.com/openssl/openssl/issues/12195__;!!GqivPVa7Brio!O5gzpHuWIANvRtRYOHA9m7SK4SqMUb2uLzEGQbUrX9nFSRhT7-sA0F-J1-VRwBk$ > > Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Fri Sep 11 11:07:48 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 11 Sep 2020 11:07:48 +0000 Subject: Beta1 PR deadline In-Reply-To: <5c9515e2-52e4-74d3-3826-c8b87eccc7d1@openssl.org> References: <20200909120330.GA2514533@roeckx.be> <2bc7adfe-29c9-f519-807a-04eddde1b633@openssl.org> <5c9515e2-52e4-74d3-3826-c8b87eccc7d1@openssl.org> Message-ID: For a more accurate and timely public overview over the current state of the blockers, it might be helpful to manage them via the 3.0.0 milestone https://github.com/openssl/openssl/milestone/15 Some of the tickets listed below were already associated to the milestone, the others were added by me now. Just a suggestion. Matthias > -----Original Message----- > From: openssl-project On Behalf Of Matt Caswell > Sent: Thursday, September 10, 2020 1:24 PM > To: openssl-project at openssl.org > Subject: Re: Beta1 PR deadline > > > > On 10/09/2020 11:40, Matt Caswell wrote: > > > > > > On 09/09/2020 13:03, Kurt Roeckx wrote: > >> On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: > >>> Please can anyone with PRs that they wish to have included in OpenSSL > >>> 3.0 beta1 ensure that they are merged to master by 8th September. > >> > >> So that date has passed now. Can someone give an overview of what > >> we think is still needed to be done before the beta 1 release? Are > >> there open PRs for everything? Do we a milestone on github to > >> indicate which PRs need to go in before beta1? > > > > > > I believe the "blockers" to be: > > > > https://github.com/openssl/openssl/pull/12536 > > https://github.com/openssl/openssl/pull/12754 > > https://github.com/openssl/openssl/pull/12750 > > https://github.com/openssl/openssl/pull/12781 > > https://github.com/openssl/openssl/pull/12801 > > > > Aside from these there are potential PRs not yet opened but slated for > > beta1 regarding: > > - Refactor serialization? (owner: Richard) > > - lhash refactor? (owner: Me) > > - IG D.9 update? (owner: Shane) > > Oh, I think this last one might be: > > https://github.com/openssl/openssl/pull/12835 > > Matt > > > > > There's also this issue - but I'm not sure that it needs to be resolved > > for beta1: > > https://github.com/openssl/openssl/issues/12195 > > > > Matt > > From matt at openssl.org Fri Sep 11 14:42:56 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 11 Sep 2020 15:42:56 +0100 Subject: Monthly Status Report (August) Message-ID: <2ff8877d-8ea2-7aa9-f774-2ee7053b239e@openssl.org> As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Raised PR to replace the legacy KDF bridge with a provider based KDF bridge - Continued work on and merged a fix to ensure that the default config file has been loaded before working with default properties - Performed the alpha 6 release - Implemented a provider based MAC bridge - Investigated and fixed an issue with stitched ciphersuites in TLSv1.0 - Drafted the job description for the new "Administrator and Manager" role - Implemented a provider side HMAC implementation that is TLS aware - Implemented checks in libssl to confirm if we have MD5-SHA1 or not - Attended the OMC virtual face-2-face - Wrote patches and security advisory in response to the Raccoon attack Matt From kurt at roeckx.be Fri Sep 11 16:51:34 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 11 Sep 2020 18:51:34 +0200 Subject: Beta1 PR deadline In-Reply-To: References: <20200909120330.GA2514533@roeckx.be> <2bc7adfe-29c9-f519-807a-04eddde1b633@openssl.org> <5c9515e2-52e4-74d3-3826-c8b87eccc7d1@openssl.org> Message-ID: <20200911165134.GA2605502@roeckx.be> On Fri, Sep 11, 2020 at 11:07:48AM +0000, Dr. Matthias St. Pierre wrote: > For a more accurate and timely public overview over the current state of the blockers, > it might be helpful to manage them via the 3.0.0 milestone > > https://github.com/openssl/openssl/milestone/15 > > Some of the tickets listed below were already associated to the milestone, the others > were added by me now. I think the 3.0.0 milestone is what we expect to be in the 3.0.0 release, not the beta release. That is bug fixes don't need to be in the beta release, but if it adds new functionallity it needs to be in the beta release. Kurt From Matthias.St.Pierre at ncp-e.com Fri Sep 11 18:08:47 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 11 Sep 2020 18:08:47 +0000 Subject: Beta1 PR deadline In-Reply-To: <20200911165134.GA2605502@roeckx.be> References: <20200909120330.GA2514533@roeckx.be> <2bc7adfe-29c9-f519-807a-04eddde1b633@openssl.org> <5c9515e2-52e4-74d3-3826-c8b87eccc7d1@openssl.org> <20200911165134.GA2605502@roeckx.be> Message-ID: > > For a more accurate and timely public overview over the current state of the blockers, > > it might be helpful to manage them via the 3.0.0 milestone > > > > https://github.com/openssl/openssl/milestone/15 > > > > Some of the tickets listed below were already associated to the milestone, the others > > were added by me now. > > I think the 3.0.0 milestone is what we expect to be in the > 3.0.0 release, not the beta release. That is bug fixes don't need > to be in the beta release, but if it adds new functionallity it > needs to be in the beta release. I was aware of this subtlety but I thought that we just could (ab-)use the milestone for the beta1 release and reuse it later for the final release, instead of creating a new milestone. Practically all of the relevant PRs are associated to the [3.0 New Core + FIPS] GitHub Project anyway, so it would be possible to remove the post-beta PRs from the milestone and restore them later. (In my mind, I see project managers running away screeming...) Matthias [3.0 New Core + FIPS]: https://github.com/openssl/openssl/projects/2 From Matthias.St.Pierre at ncp-e.com Sun Sep 13 13:17:05 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 13 Sep 2020 13:17:05 +0000 Subject: New GitHub label for release blockers Message-ID: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> Hi all, taking up again the discussion from openssl-project where I suggested to (ab)use the 3.0.0 milestone for release blockers, (see link and citation at the end of the mail), I propose to add a new label for this purpose instead. In fact, I already created the label [urgent: release blocker] (see link below) and will add the mentioned tickets within shortly. So you can take a look and tell me whether you like it or not. (If not, no problem. I'll just delete the label again.) Matthias BTW: It took me all my force of will to resist the temptation of making a pun by naming the label [urgent: beta blocker]. References: ========== [urgent: release blocker]: https://github.com/openssl/openssl/labels/urgent%3A%20release%20blocker [openssl-project message]: https://mta.openssl.org/pipermail/openssl-project/2020-September/002191.html > > > For a more accurate and timely public overview over the current state of the blockers, > > > it might be helpful to manage them via the 3.0.0 milestone > > > > > > https://github.com/openssl/openssl/milestone/15 > > > > > > Some of the tickets listed below were already associated to the milestone, the others > > > were added by me now. > > > > I think the 3.0.0 milestone is what we expect to be in the > > 3.0.0 release, not the beta release. That is bug fixes don't need > > to be in the beta release, but if it adds new functionallity it > > needs to be in the beta release. > > I was aware of this subtlety but I thought that we just could (ab-)use the milestone for > the beta1 release and reuse it later for the final release, instead of creating a new milestone. > > Practically all of the relevant PRs are associated to the [3.0 New Core + FIPS] GitHub Project > anyway, so it would be possible to remove the post-beta PRs from the milestone and restore > them later. (In my mind, I see project managers running away screeming...) > > Matthias > > > [3.0 New Core + FIPS]: https://github.com/openssl/openssl/projects/2 From Matthias.St.Pierre at ncp-e.com Sun Sep 13 13:27:25 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 13 Sep 2020 13:27:25 +0000 Subject: New GitHub label for release blockers In-Reply-To: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> Message-ID: <8227868113ab491090957507789681a9@ncp-e.com> I added some issues mentioned in the 'Beta1 PR deadline' thread to the new label. Feel free to extend and modify the list as necessary. From Matthias.St.Pierre at ncp-e.com Sun Sep 13 14:01:22 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 13 Sep 2020 14:01:22 +0000 Subject: New GitHub label for release blockers In-Reply-To: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> Message-ID: <469a1981315d44219b87db1bc32f1810@ncp-e.com> Nicola suggested and convinced me, that it would be better to have a dedicated milestone for the 3.0.0 beta1 release instead of adding a new label. So here it is, I already added all the tickets with the release blocker label and will remove the label again. https://github.com/openssl/openssl/milestone/17 Matthias > -----Original Message----- > From: Dr. Matthias St. Pierre > Sent: Sunday, September 13, 2020 3:17 PM > To: openssl-project at openssl.org > Subject: New GitHub label for release blockers > > Hi all, > > taking up again the discussion from openssl-project where I suggested to (ab)use > the 3.0.0 milestone for release blockers, (see link and citation at the end of the mail), > I propose to add a new label for this purpose instead. In fact, I already created the label > > [urgent: release blocker] (see link below) > > and will add the mentioned tickets within shortly. So you can take a look and tell > me whether you like it or not. (If not, no problem. I'll just delete the label again.) > > Matthias > > > BTW: It took me all my force of will to resist the temptation of making a pun > by naming the label [urgent: beta blocker]. > > > References: > ========== > > [urgent: release blocker]: > https://github.com/openssl/openssl/labels/urgent%3A%20release%20blocker > > [openssl-project message]: > https://mta.openssl.org/pipermail/openssl-project/2020-September/002191.html > > > > > > For a more accurate and timely public overview over the current state of the blockers, > > > > it might be helpful to manage them via the 3.0.0 milestone > > > > > > > > https://github.com/openssl/openssl/milestone/15 > > > > > > > > Some of the tickets listed below were already associated to the milestone, the others > > > > were added by me now. > > > > > > I think the 3.0.0 milestone is what we expect to be in the > > > 3.0.0 release, not the beta release. That is bug fixes don't need > > > to be in the beta release, but if it adds new functionallity it > > > needs to be in the beta release. > > > > I was aware of this subtlety but I thought that we just could (ab-)use the milestone for > > the beta1 release and reuse it later for the final release, instead of creating a new milestone. > > > > Practically all of the relevant PRs are associated to the [3.0 New Core + FIPS] GitHub Project > > anyway, so it would be possible to remove the post-beta PRs from the milestone and restore > > them later. (In my mind, I see project managers running away screeming...) > > > > Matthias > > > > > > [3.0 New Core + FIPS]: https://github.com/openssl/openssl/projects/2 From nic.tuv at gmail.com Sun Sep 13 14:16:44 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sun, 13 Sep 2020 17:16:44 +0300 Subject: New GitHub label for release blockers In-Reply-To: <469a1981315d44219b87db1bc32f1810@ncp-e.com> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> Message-ID: Matthias overcredits me: I just wanted to know his opinion about when we should use labels and when milestones (and that is why I wrote to him off-list, as a very confused and shy pupil asking a sensei for wisdom pearls). All the alleged convincing was self-inflicted :P And now that my ignorance is out of the closet... ... I still have very confused ideas regarding the "best" conventional usage of github features like labels, milestones and projects: I read the official documentation about them and I grasp the general ideas behind them, but too often the boundaries are too foggy for me to navigate and pick the right tool for the job in a consistent and organic manner. Nicola On Sun, Sep 13, 2020, 17:01 Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > Nicola suggested and convinced me, that it would be better to have a > dedicated > milestone for the 3.0.0 beta1 release instead of adding a new label. > > So here it is, I already added all the tickets with the release blocker > label and will > remove the label again. > > https://github.com/openssl/openssl/milestone/17 > > Matthias > > > > > -----Original Message----- > > From: Dr. Matthias St. Pierre > > Sent: Sunday, September 13, 2020 3:17 PM > > To: openssl-project at openssl.org > > Subject: New GitHub label for release blockers > > > > Hi all, > > > > taking up again the discussion from openssl-project where I suggested to > (ab)use > > the 3.0.0 milestone for release blockers, (see link and citation at the > end of the mail), > > I propose to add a new label for this purpose instead. In fact, I > already created the label > > > > [urgent: release blocker] (see link below) > > > > and will add the mentioned tickets within shortly. So you can take a > look and tell > > me whether you like it or not. (If not, no problem. I'll just delete the > label again.) > > > > Matthias > > > > > > BTW: It took me all my force of will to resist the temptation of making > a pun > > by naming the label [urgent: beta blocker]. > > > > > > References: > > ========== > > > > [urgent: release blocker]: > > > https://github.com/openssl/openssl/labels/urgent%3A%20release%20blocker > > > > [openssl-project message]: > > > https://mta.openssl.org/pipermail/openssl-project/2020-September/002191.html > > > > > > > > > For a more accurate and timely public overview over the current > state of the blockers, > > > > > it might be helpful to manage them via the 3.0.0 milestone > > > > > > > > > > https://github.com/openssl/openssl/milestone/15 > > > > > > > > > > Some of the tickets listed below were already associated to the > milestone, the others > > > > > were added by me now. > > > > > > > > I think the 3.0.0 milestone is what we expect to be in the > > > > 3.0.0 release, not the beta release. That is bug fixes don't need > > > > to be in the beta release, but if it adds new functionallity it > > > > needs to be in the beta release. > > > > > > I was aware of this subtlety but I thought that we just could (ab-)use > the milestone for > > > the beta1 release and reuse it later for the final release, instead of > creating a new milestone. > > > > > > Practically all of the relevant PRs are associated to the [3.0 New > Core + FIPS] GitHub Project > > > anyway, so it would be possible to remove the post-beta PRs from the > milestone and restore > > > them later. (In my mind, I see project managers running away > screeming...) > > > > > > Matthias > > > > > > > > > [3.0 New Core + FIPS]: https://github.com/openssl/openssl/projects/2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Sun Sep 13 14:26:51 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 13 Sep 2020 14:26:51 +0000 Subject: New GitHub label for release blockers In-Reply-To: References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> Message-ID: <509d8f7e305740439a97b37e8a7bcb85@ncp-e.com> Since we were able to collect some experiences working on the ?3.0 New Core + FIPS? project, I think that?s a perfect subject to be discussed on the face-to-face meeting. I will add it to the list of proposed topics. As for the official documentation you mentioned, are you talking about this one? https://github.com/features/project-management Matthias From: Nicola Tuveri Sent: Sunday, September 13, 2020 4:17 PM To: Dr. Matthias St. Pierre Cc: openssl-project at openssl.org Subject: Re: New GitHub label for release blockers Matthias overcredits me: I just wanted to know his opinion about when we should use labels and when milestones (and that is why I wrote to him off-list, as a very confused and shy pupil asking a sensei for wisdom pearls). All the alleged convincing was self-inflicted :P And now that my ignorance is out of the closet...? ... I still have very confused ideas regarding the "best" conventional usage of github features like labels, milestones and projects: I read the official documentation about them and I grasp the general ideas behind them, but too often the boundaries are too foggy for me to navigate and pick the right tool for the job in a consistent and organic manner.? Nicola From nic.tuv at gmail.com Sun Sep 13 14:36:53 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sun, 13 Sep 2020 17:36:53 +0300 Subject: New GitHub label for release blockers In-Reply-To: <509d8f7e305740439a97b37e8a7bcb85@ncp-e.com> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> <509d8f7e305740439a97b37e8a7bcb85@ncp-e.com> Message-ID: I was not referring to this page in particular, but in general to the various pages on github doc (and more in general among the first Google results) about github labels and milestones and how to use them. There seem to be, in the wild, different documented approaches, probably even influenced by the introduction over time of milestones and ways of using labels and milestones. I think having a common understanding of how we want to use these tools is a good idea, so I definitely welcome the proposition of talking about it during the vf2f! Nicola On Sun, Sep 13, 2020, 17:26 Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > Since we were able to collect some experiences working on the ?3.0 New > Core + FIPS? project, I think that?s a perfect subject > to be discussed on the face-to-face meeting. I will add it to the list of > proposed topics. As for the official documentation you > mentioned, are you talking about this one? > https://github.com/features/project-management > > Matthias > > > From: Nicola Tuveri > Sent: Sunday, September 13, 2020 4:17 PM > To: Dr. Matthias St. Pierre > Cc: openssl-project at openssl.org > Subject: Re: New GitHub label for release blockers > > Matthias overcredits me: I just wanted to know his opinion about when we > should use labels and when milestones (and that is why I wrote to him > off-list, as a very confused and shy pupil asking a sensei for wisdom > pearls). > > All the alleged convincing was self-inflicted :P > > > And now that my ignorance is out of the closet... > ... I still have very confused ideas regarding the "best" conventional > usage of github features like labels, milestones and projects: I read the > official documentation about them and I grasp the general ideas behind > them, but too often the boundaries are too foggy for me to navigate and > pick the right tool for the job in a consistent and organic manner. > > Nicola > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sun Sep 13 14:56:05 2020 From: matt at openssl.org (Matt Caswell) Date: Sun, 13 Sep 2020 15:56:05 +0100 Subject: New GitHub label for release blockers In-Reply-To: References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> Message-ID: On 13/09/2020 15:16, Nicola Tuveri wrote: > ... I still have very confused ideas regarding the "best" conventional > usage of github features like labels, milestones and projects: I read > the official documentation about them and I grasp the general ideas > behind them, but too often the boundaries are too foggy for me to > navigate and pick the right tool for the job in a consistent and organic > manner. In my head I think of them like this: - A label: describes a characteristic of a PR/issue - A milestone: a time based goal (such as a specific release) - A project: A collection of PRs/issues related by some common long term objective There is some confusion between labels and milestones, because you could think of "a time based goal" set for a pr/issue as a characteristic of it. So you could use either for the purpose. However since github has both, it seems more appropriate to use a milestone when talking about a time based goal since it is the more specific concept. Matt > > Nicola > > On Sun, Sep 13, 2020, 17:01 Dr. Matthias St. Pierre > > wrote: > > Nicola suggested and convinced me, that it would be better to have a > dedicated > milestone for the 3.0.0 beta1 release instead of adding a new label. > > So here it is, I already added all the tickets with the release > blocker label and will > remove the label again. > > https://github.com/openssl/openssl/milestone/17 > > Matthias > > > > > -----Original Message----- > > From: Dr. Matthias St. Pierre > > Sent: Sunday, September 13, 2020 3:17 PM > > To: openssl-project at openssl.org > > Subject: New GitHub label for release blockers > > > > Hi all, > > > > taking up again the discussion from openssl-project where I > suggested to (ab)use > > the 3.0.0 milestone for release blockers, (see link and citation > at the end of the mail), > > I propose to add a new label for this purpose instead. In fact, I > already created the label > > > >? ? ? ?[urgent: release blocker]? ?(see link below) > > > > and will add the mentioned tickets within shortly. So you can take > a look and tell > > me whether you like it or not. (If not, no problem. I'll just > delete the label again.) > > > > Matthias > > > > > > BTW: It took me all my force of will to resist the temptation of > making a pun > >? ? ? by naming the label [urgent: beta blocker]. > > > > > > References: > > ========== > > > > [urgent: release blocker]: > >? ? ? > ?https://github.com/openssl/openssl/labels/urgent%3A%20release%20blocker > > > > [openssl-project message]: > >? ? ? > ?https://mta.openssl.org/pipermail/openssl-project/2020-September/002191.html > > > > > > > > > For a more accurate and timely public overview over the > current state of the blockers, > > > > > it might be helpful to manage them via the 3.0.0? milestone > > > > > > > > > > https://github.com/openssl/openssl/milestone/15 > > > > > > > > > > Some of the tickets listed below were already associated to > the milestone, the others > > > > > were added by me now. > > > > > > > > I think the 3.0.0 milestone is what we expect to be in the > > > > 3.0.0 release, not the beta release. That is bug fixes don't need > > > > to be in the beta release, but if it adds new functionallity it > > > > needs to be in the beta release. > > > > > > I was aware of this subtlety but I thought that we just could > (ab-)use the milestone for > > > the beta1 release and reuse it later for the final release, > instead of creating a new milestone. > > > > > > Practically all of the relevant PRs are associated to the [3.0 > New Core + FIPS] GitHub Project > > > anyway, so it would be possible to remove the post-beta PRs from > the milestone and restore > > > them later.? (In my mind, I see project managers running away > screeming...) > > > > > > Matthias > > > > > > > > > [3.0 New Core + FIPS]:? > https://github.com/openssl/openssl/projects/2 > From Matthias.St.Pierre at ncp-e.com Sun Sep 13 15:15:25 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 13 Sep 2020 15:15:25 +0000 Subject: New GitHub label for release blockers In-Reply-To: References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> Message-ID: <81d466a27b164e178627ad3317162ef1@ncp-e.com> That's a very nice summary, Matt. when your time permits, could you please double-check whether all important tickets for beta1 were moved correctly from '3.0.0' to '3.0.0 beta1'? Thanks, Matthias From Matthias.St.Pierre at ncp-e.com Sun Sep 13 20:26:14 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 13 Sep 2020 20:26:14 +0000 Subject: New GitHub label for release blockers In-Reply-To: <81d466a27b164e178627ad3317162ef1@ncp-e.com> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> <81d466a27b164e178627ad3317162ef1@ncp-e.com> Message-ID: <4657ffc67c7648f685e43d7a29b8e62e@ncp-e.com> > when your time permits, could you please double-check whether all important tickets > for beta1 were moved correctly from '3.0.0' to '3.0.0 beta1'? The '3.0 New Core + FIPS' project currently lists 21 open pull requests, [is:open is:pr project:openssl/openssl/2]: https://github.com/openssl/openssl/pulls?q=is%3Aopen+is%3Apr+project%3Aopenssl%2Fopenssl%2F2+ ten of which are not associated with any milestone yet [is:open is:pr project:openssl/openssl/2 no:milestone]: https://github.com/openssl/openssl/pulls?q=is%3Aopen+is%3Apr+project%3Aopenssl%2Fopenssl%2F2+no%3Amilestone It would be helpful if someone of the core team could check and assigne them. Matthias From Matthias.St.Pierre at ncp-e.com Sun Sep 13 20:41:23 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 13 Sep 2020 20:41:23 +0000 Subject: New GitHub label for release blockers In-Reply-To: <4657ffc67c7648f685e43d7a29b8e62e@ncp-e.com> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> <81d466a27b164e178627ad3317162ef1@ncp-e.com> <4657ffc67c7648f685e43d7a29b8e62e@ncp-e.com> Message-ID: <8ba71241bbb84bdca2129e033c0529ca@ncp-e.com> Conversely, there were also pull requests associated with the '3.0.0' or '3.0.0 beta1' milestone, without being associated to the '3.0 New Core + FIPS' project. This has been fixed now. From paul.dale at oracle.com Sun Sep 13 22:13:08 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 14 Sep 2020 08:13:08 +1000 Subject: New GitHub label for release blockers In-Reply-To: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> Message-ID: > BTW: It took me all my force of will to resist the temptation of making a pun by naming the label [urgent: beta blocker]. Failed you have. Your training is not yet compete :) Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 14 08:18:25 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Sep 2020 09:18:25 +0100 Subject: SM2 asymmetric encryption Message-ID: Currently, 1.1.1 supports SM2 asymmetric encryption. Real world use of this is currently believed to be low (IIUC it is mainly useful for SM2 in TLS, which we don't current support). A discussion in PR #12536 is proposing to drop this feature from 3.0 (possibly to re-introduce it in some later release). This was mentioned on this list by me in this post: https://mta.openssl.org/pipermail/openssl-project/2020-August/002138.html No feedback has been received on that point. It was also discussed at the recent OMC f2f (although no vote was held on the issue). Since dropping this support is a breaking change it requires an OMC vote to approve it. I'm proposing this vote wording: "Support for SM2 asymmetric encryption should be dropped from OpenSSL 3.0" Please let me know any thoughts on the vote wording (or any other thoughts on the topic). Otherwise I plan to start this vote soon. Matt From matt at openssl.org Mon Sep 14 10:30:29 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Sep 2020 11:30:29 +0100 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: Message-ID: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> In order to try and move this discussion forward I have made a concrete proposal for how we should formulate the various ideas in this thread into an actual style. Please see here: https://github.com/openssl/web/pull/194 Since we're not yet fully in agreement some compromises will have to be made. I hope I've come up with something which isn't too abhorrent to anyone. Please take a look. Matt On 05/09/2020 04:48, SHANE LONTIS wrote: > > PR?#12778 reorders all the API?s of the form: > > > EVP_XX_fetch(libctx,?algname, propq)? > > > So that the algorithm name appears first..? > > > e.g: EVP_MD_fetch(digestname, libctx, propq); > > This now logically reads as 'search for this algorithm using these > parameters?. > > The libctx, propq should always appear together as a pair of parameters. > There are only a few places where only the libctx is needed, which means > that if there is no propq it is?likely to cause a bug in a fetch at some > point.? > > This keeps the API?s more consistent with other existing XXX_with_libctx > API?s that put the libctx, propq at the end of the parameter list.. > The exception to this rule is that callback(s) and their arguments occur > after the libctx, propq.. > > e.g: > typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn) > ? ? (const OSSL_STORE_LOADER *loader, > ? ? ?const char *uri, OPENSSL_CTX *libctx, const char *propq, > ? ? ?const UI_METHOD *ui_method, void *ui_data); > > An otc_hold was put on this.. Do we need to have a formal vote? > This really needs to be sorted out soon so the API?s can be locked down > for beta. > > -------- > Also discussed in a weekly meeting and numerous PR discussions was the > removal of the long winded API?s ending with ?with_libctx? > e.g CMS_data_create_with_libctx > The proposed renaming for this was to continue with the _ex notation.. > If there is an existing _ex name then it becomes _ex2, etc. > There will most likely be additional parameters in the future for some > API?s, so this notation would be more consistent with current API?s. > Does this also need a vote? > > Regards, > Shane > > From tjh at cryptsoft.com Mon Sep 14 10:52:15 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Mon, 14 Sep 2020 20:52:15 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> Message-ID: Any proposal needs to deal with the constructors consistently - whether they come from an OPENSSL_CTX or they come from an existing TYPE_CTX. That is absent in your PR. Basically this leads to the ability to provide inconsistent argument order in functions. TYPE *TYPE_make_from_ctx(TYPE_CTX *ctx, char *name) or TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx) It simply isn't consistent to basically allow both forms of this approach. Seeing the OPENSSL_CTX as something different to the other APIs in terms of its usage when it is providing the context from which something is constructed is the underlying issue here. Your PR basically makes rules for "context" arguments which lead to allowing both the above forms - and making the current usage of CTX values a different logical order than the OPENSSL_CTX. Separately, we should have consistency in the naming of the functions which take an OPENSSL_CTX - the _with_libctx makes no sense now that we settled on OPENSSL_CTX rather than OPENSSL_LIBCTX or OPENSSL_LIB_CTX as the naming. We also have a pile of _ex functions that were introduced just to add an OPENSSL_CTX - those should be consistently named. The PR should cover that context of how we name the variations of functions which add the OPENSSL_CTX reference. The suggested rules for extended functions is inconsistent in stating the order "should be retained" and then allowing for inserting "at any point". IHMO either the new function must preserve the existing order and just add to the end (to easy migration) or it should conform to the naming scheme and parameter argument order for new functions - one of those should be the driver rather than basically creating something that is neither - not easy to migrate to and also not following the documented order. We should be trying to achieve one of those two objectives. Tim. On Mon, Sep 14, 2020 at 8:30 PM Matt Caswell wrote: > In order to try and move this discussion forward I have made a concrete > proposal for how we should formulate the various ideas in this thread > into an actual style. Please see here: > > https://github.com/openssl/web/pull/194 > > Since we're not yet fully in agreement some compromises will have to be > made. I hope I've come up with something which isn't too abhorrent to > anyone. > > Please take a look. > > Matt > > > On 05/09/2020 04:48, SHANE LONTIS wrote: > > > > PR #12778 reorders all the API?s of the form: > > > > > > EVP_XX_fetch(libctx, algname, propq) > > > > > > So that the algorithm name appears first.. > > > > > > e.g: EVP_MD_fetch(digestname, libctx, propq); > > > > This now logically reads as 'search for this algorithm using these > > parameters?. > > > > The libctx, propq should always appear together as a pair of parameters. > > There are only a few places where only the libctx is needed, which means > > that if there is no propq it is likely to cause a bug in a fetch at some > > point. > > > > This keeps the API?s more consistent with other existing XXX_with_libctx > > API?s that put the libctx, propq at the end of the parameter list.. > > The exception to this rule is that callback(s) and their arguments occur > > after the libctx, propq.. > > > > e.g: > > typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn) > > (const OSSL_STORE_LOADER *loader, > > const char *uri, OPENSSL_CTX *libctx, const char *propq, > > const UI_METHOD *ui_method, void *ui_data); > > > > An otc_hold was put on this.. Do we need to have a formal vote? > > This really needs to be sorted out soon so the API?s can be locked down > > for beta. > > > > -------- > > Also discussed in a weekly meeting and numerous PR discussions was the > > removal of the long winded API?s ending with ?with_libctx? > > e.g CMS_data_create_with_libctx > > The proposed renaming for this was to continue with the _ex notation.. > > If there is an existing _ex name then it becomes _ex2, etc. > > There will most likely be additional parameters in the future for some > > API?s, so this notation would be more consistent with current API?s. > > Does this also need a vote? > > > > Regards, > > Shane > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 14 11:19:25 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Sep 2020 12:19:25 +0100 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> Message-ID: On 14/09/2020 11:52, Tim Hudson wrote: > Any?proposal needs to deal with the constructors?consistently - whether > they come from an OPENSSL_CTX or they come from an existing TYPE_CTX. > That is absent in your PR. > > Basically this leads to the ability to provide inconsistent argument > order in functions. > > TYPE *TYPE_make_from_ctx(TYPE_CTX *ctx, char *name) > or > TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx) > > It simply isn't consistent to basically allow both forms of this approach. > > Seeing the OPENSSL_CTX as something different to the other APIs in terms > of its usage when it is providing the context from which something is > constructed is the underlying issue here. > Your PR basically makes rules for "context" arguments which lead to > allowing both the above forms - and making the current usage of CTX > values a different logical order than the OPENSSL_CTX. I must be misunderstanding your point because I don't follow your logic at all. In your example above the proposal seems clear (to me): "Where present the TYPE argument should always be first. In constructors or object factory type functions (such as a "fetch" function), the key argument that identifies the thing be constructed should be placed first (if such an argument exists)." Your example is a "factory type" or constructor. Therefore the argument that identifies the thing being constructued should be first, i.e. the name. The section of the policy says: "The remaining argument list should be put into order of importance." Only then does it go on to list where the ctx sits in that order of importance. The phrase "the remaining argument list" indicates that that ordering is subordinate to the preceding paragraph. So this is the correct form according to my proposed policy: TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx) > > Separately, we should have consistency in the naming of the functions > which take an OPENSSL_CTX - the _with_libctx makes no sense now that we > settled on OPENSSL_CTX rather than OPENSSL_LIBCTX or OPENSSL_LIB_CTX as > the naming. We also have a pile of _ex functions that were introduced > just to add an OPENSSL_CTX - those should be consistently named. The policy is clear. We are adding extended forms of existing functions. Therefore "_with_libctx" is not consistent with the policy. "_ex" (or "_ex2" if necessary), is. > > The PR should cover that context of how we name the variations of > functions which add the OPENSSL_CTX reference. IMO, it does. They should be called "*_ex" as stated in chapter 6.2. I don't see why we need to special case OPENSSL_CTX in the policy. Its written in a generic way an can be applied to the OPENSSL_CTX case. > > The suggested rules for extended functions is inconsistent in stating > the order "should be retained" and then allowing for inserting "at any > point". This is not inconsistent. The *order* must be retained. Inserting additional arguments does *not* change the order. So according to the policy, if you have a function: FOO_do_something(bar, wibble, blah); Then this is ok: FOO_do_something(new, bar, wibble, blah); As is this: FOO_do_something(bar, new, wibble, blah); And this: FOO_do_something(bar, wibble, blah, new); But *not* this (because the order of existing arguments is different): FOO_do_something(blah, wibble, bar, new); > IHMO either the new function must preserve the existing order and just > add to the end (to easy migration) or it should conform to the naming > scheme and parameter argument order for new functions - one of those > should be the driver rather than basically creating something that is > neither - not easy to migrate to and also not following the documented > order. We should be trying to achieve one of those two objectives. I disagree that that should be an objective. IMO *the* most confusing thing would be to *change* an existing ordering (for example swap two existing parameters around). I see no problem with adding new ones anywhere that's appropriate. Matt From tjh at cryptsoft.com Mon Sep 14 11:46:01 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Mon, 14 Sep 2020 21:46:01 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> Message-ID: On Mon, Sep 14, 2020 at 9:19 PM Matt Caswell wrote: > I must be misunderstanding your point because I don't follow your logic > at all. > > So this is the correct form according to my proposed policy: > > TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx) > And that is the point - this is not how the existing CTX functions work (ignoring the OPENSSL_CTX stuff). > > The PR should cover that context of how we name the variations of > > functions which add the OPENSSL_CTX reference. > > IMO, it does. They should be called "*_ex" as stated in chapter 6.2. I > don't see why we need to special case OPENSSL_CTX in the policy. Its > written in a generic way an can be applied to the OPENSSL_CTX case. > And that means renaming all the with_libctx to _ex which frankly I don't think makes a lot of sense to do. Having a naming indicating OPENSSL_CTX added isn't a bad thing to do in my view. Collecting a whole pile of _ex functions and having to look at each one to figure out what the "extension" is does add additional burden for the user. There is a reason that _with_libctx was added rather than picking _ex as the function names - it clearly communicates then intent rather than be a generic extension-of-API naming. IMO *the* most confusing thing would be to *change* an existing ordering > (for example swap two existing parameters around). I see no problem with > adding new ones anywhere that's appropriate. > Clearly we disagree on that - if you are making an extended version of a function and you aren't keeping the same existing parameter order (which you are not if you add or remove parameters which is the point I was making - the order isn't the same as the existing function because you've removed items - what you have is the order of whatever parameters remain in the extended function are the same - and that's a pretty pointless distinction to make - if you aren't simply adding additional items on the end you make for a change over mess and this I think we should be trying to avoid). My context there is for the users of the existing API. It becomes especially problematic if you have type equivalence when the order is changed around so there are no compiler warnings if the user hasn't picked up on reordering of parameters. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 14 11:46:39 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Sep 2020 12:46:39 +0100 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> Message-ID: On 14/09/2020 11:30, Matt Caswell wrote: > In order to try and move this discussion forward I have made a concrete > proposal for how we should formulate the various ideas in this thread > into an actual style. Please see here: > > https://github.com/openssl/web/pull/194 > > Since we're not yet fully in agreement some compromises will have to be > made. I hope I've come up with something which isn't too abhorrent to > anyone. > > Please take a look. I'm planning to gather feedback on this PR today - so if you have any thoughts then please comment. I will post an updated version tomorrow incorporating any feedback. I plan to start a vote on this later this week (perhaps Wednesday). Possibly I might do two votes: one for the proposed chapter 6.1, and one for the proposed chapter 6.2. Given the disagreements on this, I don't believe unanimous agreement is going to be achievable. I hope to get it into a state where it is acceptable to as many people as possible. Matt > > Matt > > > On 05/09/2020 04:48, SHANE LONTIS wrote: >> >> PR?#12778 reorders all the API?s of the form: >> >> >> EVP_XX_fetch(libctx,?algname, propq)? >> >> >> So that the algorithm name appears first..? >> >> >> e.g: EVP_MD_fetch(digestname, libctx, propq); >> >> This now logically reads as 'search for this algorithm using these >> parameters?. >> >> The libctx, propq should always appear together as a pair of parameters. >> There are only a few places where only the libctx is needed, which means >> that if there is no propq it is?likely to cause a bug in a fetch at some >> point.? >> >> This keeps the API?s more consistent with other existing XXX_with_libctx >> API?s that put the libctx, propq at the end of the parameter list.. >> The exception to this rule is that callback(s) and their arguments occur >> after the libctx, propq.. >> >> e.g: >> typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn) >> ? ? (const OSSL_STORE_LOADER *loader, >> ? ? ?const char *uri, OPENSSL_CTX *libctx, const char *propq, >> ? ? ?const UI_METHOD *ui_method, void *ui_data); >> >> An otc_hold was put on this.. Do we need to have a formal vote? >> This really needs to be sorted out soon so the API?s can be locked down >> for beta. >> >> -------- >> Also discussed in a weekly meeting and numerous PR discussions was the >> removal of the long winded API?s ending with ?with_libctx? >> e.g CMS_data_create_with_libctx >> The proposed renaming for this was to continue with the _ex notation.. >> If there is an existing _ex name then it becomes _ex2, etc. >> There will most likely be additional parameters in the future for some >> API?s, so this notation would be more consistent with current API?s. >> Does this also need a vote? >> >> Regards, >> Shane >> >> > From matt at openssl.org Mon Sep 14 11:52:29 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Sep 2020 12:52:29 +0100 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> Message-ID: On 14/09/2020 12:46, Tim Hudson wrote: > On Mon, Sep 14, 2020 at 9:19 PM Matt Caswell > wrote: > > I must be misunderstanding your point because I don't follow your logic > at all. > > So this is the correct form according to my proposed policy: > > TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx) > > > And that is the point - this is not how the existing CTX functions work > (ignoring the OPENSSL_CTX stuff). Do you have some concrete examples of existing functions that don't work this way? > ? > > > The PR should cover that context of how we name the variations of > > functions which add the OPENSSL_CTX reference. > > IMO, it does. They should be called "*_ex" as stated in chapter 6.2. I > don't see why we need to special case OPENSSL_CTX in the policy. Its > written in a generic way an can be applied to the OPENSSL_CTX case. > > > And that means renaming all the with_libctx to _ex which frankly I don't > think makes a lot of sense to do. My understanding of the current consensus from previous discussions is that most people feel differently to you on this. Maybe I'm wrong. > Having a naming indicating OPENSSL_CTX added isn't a bad thing to do in > my view. > Collecting a whole pile of _ex functions and having to look at each one > to figure out what the "extension" is does add additional burden for the > user. > There is a reason that _with_libctx was added rather than picking _ex as > the function names - it clearly communicates then intent rather than be > a generic extension-of-API naming. > > > IMO *the* most confusing thing would be to *change* an existing ordering > > (for example swap two existing parameters around). I see no problem with > adding new ones anywhere that's appropriate. > > > Clearly we disagree on that - if you are making an extended version of a > function and you aren't keeping the same existing parameter order (which > you are not if you add or remove parameters which is the point I was > making - the order isn't the same as the existing function because > you've removed items - what you have is the order of whatever parameters > remain in the extended function are the same - and that's a pretty > pointless distinction to make - if you aren't simply adding additional > items on the end you make for a change over mess and this I think we > should be trying to avoid). My context there is for the users of the > existing API. > It becomes especially problematic if you have type equivalence when the > order is changed around so there are no compiler warnings if the user > hasn't picked up on reordering of parameters. IMO, we absolutely MUST have the ability to delete parameters (for example ENGINEs). If we can do that, then I don't see why we can't add parameters. Matt ? From tjh at cryptsoft.com Mon Sep 14 12:14:08 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Mon, 14 Sep 2020 22:14:08 +1000 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> Message-ID: On Mon, Sep 14, 2020 at 9:52 PM Matt Caswell wrote: > > And that is the point - this is not how the existing CTX functions work > > (ignoring the OPENSSL_CTX stuff). > > Do you have some concrete examples of existing functions that don't work > this way? > SSL_new() BIO_new_ssl() BIO_new_ssl_connect() BIO_new_bio_pair() etc And all the existing method using functions which are also factories. But I get the point - if there is only one argument is it logically coming first or last - obviously it can be seen both ways. IMO, we absolutely MUST have the ability to delete parameters (for > example ENGINEs). If we can do that, then I don't see why we can't add > parameters. > No - that doesn't follow. It is perfectly reasonable to have an ENGINE typedef that remains and is passed as NULL as usual - and in fact most of the top-level ENGINE stuff handles NULL as meaning no engine usage so that would remain consistent. There is no absolute requirement to delete a parameter for this or other purposes. If you want to reorder parameters I would argue it should be a new function name and not an _ex version. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 14 13:09:17 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Sep 2020 14:09:17 +0100 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> Message-ID: <607b4402-eac5-9c92-8584-dea4c6a785a8@openssl.org> On 14/09/2020 13:14, Tim Hudson wrote: > On Mon, Sep 14, 2020 at 9:52 PM Matt Caswell > wrote: > > > And that is the point - this is not how the existing CTX functions > work > > (ignoring the OPENSSL_CTX stuff). > > Do you have some concrete examples of existing functions that don't work > this way? > > > SSL_new() > BIO_new_ssl() > BIO_new_ssl_connect() All of these three are consistent with my proposed policy. The policy says: "the key argument that identifies the thing be constructed should be placed first (if such an argument exists)" The parenthetical comes into play here "if such an argument exists". It doesn't exist in any of these three cases and therefore this part doesn't apply. In all cases the arguments are a single argument and so trivially agree with the ordering rules. > BIO_new_bio_pair() This one is a slight oddity in that it doesn't create just one object but two. I'm not aware of anywhere else where we do this, but even if we do I don't think it is a common pattern, so I don't feel the need to base our future policy on this precedent. > etc > > And all the existing?method using functions which are also factories. > > But I get the point - if there is only one argument is it logically > coming first or last - obviously it can be seen both ways. > > IMO, we absolutely MUST have the ability to delete parameters (for > example ENGINEs). If we can do that, then I don't see why we can't add > parameters. > > > No - that doesn't follow. It is perfectly reasonable to have an ENGINE > typedef that remains and is passed as NULL as usual - and in fact most > of the top-level ENGINE stuff handles NULL as meaning no engine usage so > that would remain consistent. There is no absolute requirement to > delete?a parameter for this or other purposes. If you want to reorder > parameters I would argue it should be a new function name and not an _ex > version. I disagree with you on this. Matt From levitte at openssl.org Mon Sep 14 14:02:56 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 14 Sep 2020 16:02:56 +0200 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> Message-ID: <875z8gsbfz.wl-levitte@openssl.org> On Mon, 14 Sep 2020 13:46:01 +0200, Tim Hudson wrote: > > [1 ] > [2 ] > On Mon, Sep 14, 2020 at 9:19 PM Matt Caswell wrote: > > I must be misunderstanding your point because I don't follow your logic > at all. > > So this is the correct form according to my proposed policy: > > TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx) > > And that is the point - this is not how the existing CTX functions > work (ignoring the OPENSSL_CTX stuff). I'd say that the example here is flawed, at least for libcrypto. (libssl has some very different patterns that are quite confusing when relating them to what's been said here, so I'm choosing to ignore them for the moment, for the sake of clarity) The prime example I have for that sort of constructor constructor is this: EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_name(OPENSSL_CTX *libctx, const char *name, const char *propquery); Function name wise, it's obvious that the name is of primary interest. The library context is located as first argument, because "library global state" or factory pool, which is fine. However, other than SSL contra SSL_CTX, I can't recall that we have much functions that contruct a TYPE from a TYPE_CTX. ( mind you, our TYPE naming is all over the place and quite inconsistent. In many EVP APIs, we have a TYPE / TYPE_CTX pair where TYPE is the structure with method pointers and TYPE_CTX is the structure with instance data... except with EVP_PKEY, where we had (roughly and in legacy terms) the EVP_PKEY_ASN1_METHOD / EVP_PKEY pair and the EVP_PKEY_METHOD / EVP_PKEY_CTX pairs... and with non EVP APIs (such as BIO), we often have the TYPE_METHOD / TYPE pair I haven't even begun to analyse the SSL types in similar terms, if that's doable ) > > The PR should cover that context of how we name the variations of > > functions which add the OPENSSL_CTX reference. > > IMO, it does. They should be called "*_ex" as stated in chapter 6.2. I > don't see why we need to special case OPENSSL_CTX in the policy. Its > written in a generic way an can be applied to the OPENSSL_CTX case. > > And that means renaming all the with_libctx to _ex which frankly I > don't think makes a lot of sense to do. I don't see a lot of sense in _with_libctx (and I scold myself for starting that pattern). Imagine the next time we have something important that we want to add as argument to the same essential function, what then? TYPE_blah_with_libctx_with_whatever()? That doesn't set a sensible pattern... > Having a naming indicating OPENSSL_CTX added isn't a bad thing to do > in my view. Can you guarantee that this is the one and only time we add something like '_with_libctx' to a function name, or do we risk ending up feeling "inspired" some time in the future? > Collecting a whole pile of _ex functions and having to look at each > one to figure out what the "extension" is does add additional burden > for the user. A sensible thing to do is to deprecate the old and clunky. That'll tell the user which if variants A, B, and C they should use going forward. I'm with you insofar that I thoroughly dislike _ex, but I've made peace with it when someone pointed out that _ex{n} is possible. And quite frankly, I dislike more or less every scheme on giving new names to functions that are just extended but otherwise have the same essential functionality as the previous one. They're all ugly. So in my mind mind, it comes down to choosing a scheme that one can live with and that holds for a long time going forward. And just so we're clear, if you take a function and make a replacement that takes some slightly different arguments but that essentially (i.e. perhaps not exactly in the details, but in broader terms) gives the same result, then I'd say that the new function is an extension of the old, not an entirely new function. I'll also point out that when we make functions that are "concurrent" variants of the same, then it does make sense to have specific naming, like these: EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_name(OPENSSL_CTX *libctx, const char *name, const char *propquery); EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_pkey(OPENSSL_CTX *libctx, EVP_PKEY *pkey, const char *propquery); These are not replacements of each other, so it makes sense here to put the distinguishing feature of each as part of the function name. > There is a reason that _with_libctx was added rather than picking > _ex as the function names - it clearly communicates then intent > rather than be a generic extension-of-API naming. Considering I came up with that, I can easily declare that the intent wasn't originally as grand as you make it out to be. It was a name I came up with spur of the moment. Today, I wish I never had, at least in the public API (I'm less fussy about internal functions). It was a bad choice on my part. > IMO *the* most confusing thing would be to *change* an existing ordering > > (for example swap two existing parameters around). I see no problem with > adding new ones anywhere that's appropriate. > > Clearly we disagree on that - if you are making an extended version > of a function and you aren't keeping the same existing parameter > order (which you are not if you add or remove parameters which is > the point I was making - the order isn't the same as the existing > function because you've removed items - what you have is the order > of whatever parameters remain in the extended function are the same > - and that's a pretty pointless distinction to make - if you aren't > simply adding additional items on the end you make for a change over > mess and this I think we should be trying to avoid). I think we have some very fundamentaly different understanding of "order". I'm with Matt on this; if you have a list A, B, C, D and remove C, then A, B, D are still in the same order. As to where to add arguments, I would say that yes, it's good to have a general guideline, but that it will have to be decided more carefully on a per function basis. For example, I wouldn't necessarily add a property query string at the very end, if the algorithm name or the object the algorithm name can be derived from isn't there. So, I would not at all want to see something like this (this isn't what we have now, but with the idea that we always place OPENSSL_CTX as first argument and other added arguments last, this would be the result): OSSL_STORE_CTX * OSSL_STORE_open(OPENSSL_CTX *, const char *uri, const UI_METHOD *ui_method, void *ui_data, OSSL_STORE_post_process_info_fn post_process, void *post_process_data, const char *propq); Because the property query string is strongly associated with the implementation name (which is derived from the URI in this case), the more meaningful placement would be this: OSSL_STORE_CTX * OSSL_STORE_open(OPENSSL_CTX *, const char *uri, const char *propq, const UI_METHOD *ui_method, void *ui_data, OSSL_STORE_post_process_info_fn post_process, void *post_process_data, const char *propq); (that also follows the current _fetch function model) > My context there is for the users of the existing API. > It becomes especially problematic if you have type equivalence when > the order is changed around so there are no compiler warnings if the > user hasn't picked up on reordering of parameters. That is indeed a problem, but I fail to see how removed arguments or the location of added arguments matter much for this. Unless we get into +1 -1 situation and that a 'void *' just so happens to end up in a place that had a different type that gets silently passed anyway, I doubt that will be much of a problem. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Sep 14 15:44:03 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Sep 2020 16:44:03 +0100 Subject: OTC vote on PR11188 In-Reply-To: <930c7d61-38ed-39b0-230f-50ee6da5dd13@openssl.org> References: <930c7d61-38ed-39b0-230f-50ee6da5dd13@openssl.org> Message-ID: This vote is now closed (actually it closed last week but I forgot to report it). The vote was not accepted: for: 0, against: 8, abstained: 3, not voted: 0 On 27/08/2020 11:06, Matt Caswell wrote: > FYI, I have initiated the following vote on PR11188. Please see the > comments in that PR for the background. I will report back with the > result of the vote once known. > > topic: The performance improvements provided in PR11188 should be > considered a bug fix and therefore acceptable for backport to > 1.1.1 > Proposed by Matt Caswell > Public: yes > opened: 2020-08-27 > closed: 2020-mm-dd > > > Matt > From levitte at openssl.org Mon Sep 14 17:32:29 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 14 Sep 2020 19:32:29 +0200 Subject: New GitHub label for release blockers In-Reply-To: <8ba71241bbb84bdca2129e033c0529ca@ncp-e.com> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> <81d466a27b164e178627ad3317162ef1@ncp-e.com> <4657ffc67c7648f685e43d7a29b8e62e@ncp-e.com> <8ba71241bbb84bdca2129e033c0529ca@ncp-e.com> Message-ID: <874ko0s1qq.wl-levitte@openssl.org> On Sun, 13 Sep 2020 22:41:23 +0200, Dr. Matthias St. Pierre wrote: > > Conversely, there were also pull requests associated with the '3.0.0' or '3.0.0 beta1' milestone, > without being associated to the '3.0 New Core + FIPS' project. This has been fixed now. I fail to see why the milestones '3.0.0' / '3.0.0 beta1' must be 1:1 with the '3.0 New Core + FIPS' project. If we make them the same, what's the reason to have both? I just looked in the project, and these are issues and PRs the presence of which I think is questionable: #10612 #4930 #12860 #11311 Maybe there's a misunderstand of what "3.0 New Core" means. Please note the lack of comma. But if that doesn't help, how about the project description? I've seen a bit too much of wanting to pile *everything* into that project. That was never the intention. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Tue Sep 15 07:46:53 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 15 Sep 2020 07:46:53 +0000 Subject: New GitHub label for release blockers In-Reply-To: <874ko0s1qq.wl-levitte@openssl.org> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> <81d466a27b164e178627ad3317162ef1@ncp-e.com> <4657ffc67c7648f685e43d7a29b8e62e@ncp-e.com> <8ba71241bbb84bdca2129e033c0529ca@ncp-e.com> <874ko0s1qq.wl-levitte@openssl.org> Message-ID: <72c43fa6e94d400880e1c613c820281a@ncp-e.com> > I fail to see why the milestones '3.0.0' / '3.0.0 beta1' must be 1:1 > with the '3.0 New Core + FIPS' project. Sorry for the misunderstanding, Richard. I did not intend to mess around with your project organization. Since it was the only active GitHub project, I misinterpreted it as the "3.0.0" project and did not read the fine print. All I intended to do is to obtain an accurate overwiew of what remains to be done. Because listing them on the otc mailing list is not very maintainable, and the google spreadsheet is not viewable by the public. > If we make them the same, what's the reason to have both? I completely agree. According to my understanding, it would have made more sense if we had created an "OpenSSL 3.0" project for managing all what needs to go into this major release and three milestones '3.0.0 alpha', '3.0.0 beta', '3.0.0' associated with the major events. Regards, Matthias From nl0 at von-Oheimb.de Mon Sep 14 18:23:54 2020 From: nl0 at von-Oheimb.de (David von Oheimb) Date: Mon, 14 Sep 2020 20:23:54 +0200 Subject: New GitHub label for release blockers In-Reply-To: <874ko0s1qq.wl-levitte@openssl.org> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> <81d466a27b164e178627ad3317162ef1@ncp-e.com> <4657ffc67c7648f685e43d7a29b8e62e@ncp-e.com> <8ba71241bbb84bdca2129e033c0529ca@ncp-e.com> <874ko0s1qq.wl-levitte@openssl.org> Message-ID: Concerning PR #4930: Originally that PR was about extending support for PKCS#12 input in apps, which meanwhile has been superseded mostly by OSSL_STORE. I meanwhile carved out the most interesting remaining pieces of the PR? and contributed them separately. I've just rebased and cleaned up the various remaining commits. What is still left are fixes for several corner cases in PKCS#12 input and its error handling. There are also some rather unrelated fixes to several apps and their documentation, which I could separate if requested. I don't think any of this is critical before the beta release; in particular there are no feature or API changes any more. ??? David On 14.09.20 19:32, Richard Levitte wrote: > On Sun, 13 Sep 2020 22:41:23 +0200, > Dr. Matthias St. Pierre wrote: >> Conversely, there were also pull requests associated with the '3.0.0' or '3.0.0 beta1' milestone, >> without being associated to the '3.0 New Core + FIPS' project. This has been fixed now. > I fail to see why the milestones '3.0.0' / '3.0.0 beta1' must be 1:1 > with the '3.0 New Core + FIPS' project. If we make them the same, > what's the reason to have both? > > I just looked in the project, and these are issues and PRs the > presence of which I think is questionable: > > #10612 > #4930 > #12860 > #11311 > > Maybe there's a misunderstand of what "3.0 New Core" means. Please > note the lack of comma. But if that doesn't help, how about the > project description? > > I've seen a bit too much of wanting to pile *everything* into that > project. That was never the intention. > > Cheers, > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Sep 15 10:43:50 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 15 Sep 2020 12:43:50 +0200 Subject: New GitHub label for release blockers In-Reply-To: <72c43fa6e94d400880e1c613c820281a@ncp-e.com> References: <0c7cc8b8606e4adba978fddc4cc7a28c@ncp-e.com> <469a1981315d44219b87db1bc32f1810@ncp-e.com> <81d466a27b164e178627ad3317162ef1@ncp-e.com> <4657ffc67c7648f685e43d7a29b8e62e@ncp-e.com> <8ba71241bbb84bdca2129e033c0529ca@ncp-e.com> <874ko0s1qq.wl-levitte@openssl.org> <72c43fa6e94d400880e1c613c820281a@ncp-e.com> Message-ID: <87363js4k9.wl-levitte@openssl.org> On Tue, 15 Sep 2020 09:46:53 +0200, Dr. Matthias St. Pierre wrote: > > If we make them the same, what's the reason to have both? > > I completely agree. According to my understanding, it would have > made more sense if we had created an "OpenSSL 3.0" project for > managing all what needs to go into this major release and three > milestones '3.0.0 alpha', '3.0.0 beta', '3.0.0' associated with the > major events. And that, exactly that, would create a project that fulfill the exact same functionality as the 3.0.0 milestone. Why would that be necessary? Just use the milestones. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Sep 15 10:49:45 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 15 Sep 2020 11:49:45 +0100 Subject: SM2 asymmetric encryption In-Reply-To: References: Message-ID: <9037c198-c3a8-0eec-73f2-596e6630f796@openssl.org> I have started this vote and will report back when I have an answer. Matt On 14/09/2020 09:18, Matt Caswell wrote: > Currently, 1.1.1 supports SM2 asymmetric encryption. Real world use of > this is currently believed to be low (IIUC it is mainly useful for SM2 > in TLS, which we don't current support). A discussion in PR #12536 is > proposing to drop this feature from 3.0 (possibly to re-introduce it in > some later release). This was mentioned on this list by me in this post: > > https://mta.openssl.org/pipermail/openssl-project/2020-August/002138.html > > No feedback has been received on that point. It was also discussed at > the recent OMC f2f (although no vote was held on the issue). Since > dropping this support is a breaking change it requires an OMC vote to > approve it. I'm proposing this vote wording: > > "Support for SM2 asymmetric encryption should be dropped from OpenSSL 3.0" > > Please let me know any thoughts on the vote wording (or any other > thoughts on the topic). Otherwise I plan to start this vote soon. > > Matt > From matt at openssl.org Tue Sep 15 11:25:01 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 15 Sep 2020 12:25:01 +0100 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> Message-ID: <9a846dc2-2fac-7457-7f8a-19f3bf73cee8@openssl.org> On 14/09/2020 11:30, Matt Caswell wrote: > In order to try and move this discussion forward I have made a concrete > proposal for how we should formulate the various ideas in this thread > into an actual style. Please see here: > > https://github.com/openssl/web/pull/194 I've updated this PR with some of the feedback received so far. Please take another look. I plan to start two OTC votes on this tomorrow with the following wording: "Adopt the coding style policy on function arguments as shown in chapter 6.1 of web PR 194 (commit 7b45b46d71f)" "Adopt the coding style policy on extending existing functions as shown in chapter 6.2 of web PR 194 (commit 7b45b46d71f)" In the event that one vote passes but the other vote does not I will remove the section of text that did not pass from the PR and adjust chapter numbers accordingly. Matt > > Since we're not yet fully in agreement some compromises will have to be > made. I hope I've come up with something which isn't too abhorrent to > anyone. > > Please take a look. > > Matt > > > On 05/09/2020 04:48, SHANE LONTIS wrote: >> >> PR?#12778 reorders all the API?s of the form: >> >> >> EVP_XX_fetch(libctx,?algname, propq)? >> >> >> So that the algorithm name appears first..? >> >> >> e.g: EVP_MD_fetch(digestname, libctx, propq); >> >> This now logically reads as 'search for this algorithm using these >> parameters?. >> >> The libctx, propq should always appear together as a pair of parameters. >> There are only a few places where only the libctx is needed, which means >> that if there is no propq it is?likely to cause a bug in a fetch at some >> point.? >> >> This keeps the API?s more consistent with other existing XXX_with_libctx >> API?s that put the libctx, propq at the end of the parameter list.. >> The exception to this rule is that callback(s) and their arguments occur >> after the libctx, propq.. >> >> e.g: >> typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn) >> ? ? (const OSSL_STORE_LOADER *loader, >> ? ? ?const char *uri, OPENSSL_CTX *libctx, const char *propq, >> ? ? ?const UI_METHOD *ui_method, void *ui_data); >> >> An otc_hold was put on this.. Do we need to have a formal vote? >> This really needs to be sorted out soon so the API?s can be locked down >> for beta. >> >> -------- >> Also discussed in a weekly meeting and numerous PR discussions was the >> removal of the long winded API?s ending with ?with_libctx? >> e.g CMS_data_create_with_libctx >> The proposed renaming for this was to continue with the _ex notation.. >> If there is an existing _ex name then it becomes _ex2, etc. >> There will most likely be additional parameters in the future for some >> API?s, so this notation would be more consistent with current API?s. >> Does this also need a vote? >> >> Regards, >> Shane >> >> From matt at openssl.org Tue Sep 15 22:01:26 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 15 Sep 2020 23:01:26 +0100 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.1.1h. This release will be made available on Tuesday 22nd September 2020 between 1300-1700 UTC. OpenSSL 1.1.h is a bug-fix release. There are no CVEs addressed in this release. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl9hObYACgkQ2cTSbQ5g RJGmDAf+IPnGTpXB6XpHpuvlWWE6v0aTEOHntLgeYbqp9v3/5ay4i0qwFZk2M4Sn 9J5C/057OqqLVMq0UyXXAwhyS52KIR6VfcJKTCc/2NkgPHhee+/W5Q8SgGpXMnOP 60EIrHD5cfkestIO9fvrCHZ19RFFWlFQJnPmc64nLYyhQJ83a/AKGoug459oaxm7 lj90Rd+U4oQvEJyltsA5Urv/IAjQV24EYej1pCLb4zqerW4rLYnoATBrurclWVOa 5AXZgzuhNvtMV3/nVB7aFpfQIsg2FUaTnRW3ok+7e72oiXHndgxYW6TP0GxGOMdu RDB1ZlWWwt7LzYz8BlWTex+s23SNZA== =wNcz -----END PGP SIGNATURE----- From tjh at openssl.org Tue Sep 15 22:10:09 2020 From: tjh at openssl.org (Tim Hudson) Date: Wed, 16 Sep 2020 08:10:09 +1000 Subject: stable branch release cadence Message-ID: The OMC voted to: *Release stable branch on the second last Tuesday of the last month in each quarter as a regular cadence.* The vote passed. For: 6, against: 9, abstained 0, not voted: 1 Thanks, Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Sep 15 22:11:18 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 15 Sep 2020 23:11:18 +0100 Subject: stable branch release cadence In-Reply-To: References: Message-ID: <705d9667-fbf2-e17e-32a7-400175a11add@openssl.org> On 15/09/2020 23:10, Tim Hudson wrote: > The OMC voted to: > > /Release stable branch on the second last Tuesday of the last month in > each quarter as a regular cadence./ > > The vote passed. > For: 6, against: 9, abstained 0, not voted: 1 That should say against: 0 ;-) Matt > > Thanks, > Tim. > From tjh at openssl.org Tue Sep 15 22:12:35 2020 From: tjh at openssl.org (Tim Hudson) Date: Wed, 16 Sep 2020 08:12:35 +1000 Subject: stable branch release cadence In-Reply-To: <705d9667-fbf2-e17e-32a7-400175a11add@openssl.org> References: <705d9667-fbf2-e17e-32a7-400175a11add@openssl.org> Message-ID: Thanks Matt - cut-n-paste fumble on my part from the previous vote summary. The tally should always equal the number of OMC members. For: 6, against: 0, abstained 0, not voted: 1 Tim. On Wed, Sep 16, 2020 at 8:11 AM Matt Caswell wrote: > > > On 15/09/2020 23:10, Tim Hudson wrote: > > The OMC voted to: > > > > /Release stable branch on the second last Tuesday of the last month in > > each quarter as a regular cadence./ > > > > The vote passed. > > For: 6, against: 9, abstained 0, not voted: 1 > > That should say against: 0 > > ;-) > > Matt > > > > > Thanks, > > Tim. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 16 15:56:05 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 16 Sep 2020 16:56:05 +0100 Subject: Reordering new API's that have a libctx, propq In-Reply-To: <9a846dc2-2fac-7457-7f8a-19f3bf73cee8@openssl.org> References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> <9a846dc2-2fac-7457-7f8a-19f3bf73cee8@openssl.org> Message-ID: On 15/09/2020 12:25, Matt Caswell wrote: > I plan to start two OTC votes on this tomorrow with the following wording: These votes have now commenced. I'll report back with the results when they are known. Matt > > "Adopt the coding style policy on function arguments as shown in chapter > 6.1 of web PR 194 (commit 7b45b46d71f)" > > "Adopt the coding style policy on extending existing functions as shown > in chapter 6.2 of web PR 194 (commit 7b45b46d71f)" > > In the event that one vote passes but the other vote does not I will > remove the section of text that did not pass from the PR and adjust > chapter numbers accordingly. > > Matt > >> >> Since we're not yet fully in agreement some compromises will have to be >> made. I hope I've come up with something which isn't too abhorrent to >> anyone. >> >> Please take a look. >> >> Matt >> >> >> On 05/09/2020 04:48, SHANE LONTIS wrote: >>> >>> PR?#12778 reorders all the API?s of the form: >>> >>> >>> EVP_XX_fetch(libctx,?algname, propq)? >>> >>> >>> So that the algorithm name appears first..? >>> >>> >>> e.g: EVP_MD_fetch(digestname, libctx, propq); >>> >>> This now logically reads as 'search for this algorithm using these >>> parameters?. >>> >>> The libctx, propq should always appear together as a pair of parameters. >>> There are only a few places where only the libctx is needed, which means >>> that if there is no propq it is?likely to cause a bug in a fetch at some >>> point.? >>> >>> This keeps the API?s more consistent with other existing XXX_with_libctx >>> API?s that put the libctx, propq at the end of the parameter list.. >>> The exception to this rule is that callback(s) and their arguments occur >>> after the libctx, propq.. >>> >>> e.g: >>> typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn) >>> ? ? (const OSSL_STORE_LOADER *loader, >>> ? ? ?const char *uri, OPENSSL_CTX *libctx, const char *propq, >>> ? ? ?const UI_METHOD *ui_method, void *ui_data); >>> >>> An otc_hold was put on this.. Do we need to have a formal vote? >>> This really needs to be sorted out soon so the API?s can be locked down >>> for beta. >>> >>> -------- >>> Also discussed in a weekly meeting and numerous PR discussions was the >>> removal of the long winded API?s ending with ?with_libctx? >>> e.g CMS_data_create_with_libctx >>> The proposed renaming for this was to continue with the _ex notation.. >>> If there is an existing _ex name then it becomes _ex2, etc. >>> There will most likely be additional parameters in the future for some >>> API?s, so this notation would be more consistent with current API?s. >>> Does this also need a vote? >>> >>> Regards, >>> Shane >>> >>> From matt at openssl.org Thu Sep 17 12:48:18 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 17 Sep 2020 13:48:18 +0100 Subject: 3.0 beta 1 milestone Message-ID: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> 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 From tmraz at redhat.com Thu Sep 17 13:57:52 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 17 Sep 2020 15:57:52 +0200 Subject: 3.0 beta 1 milestone In-Reply-To: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> References: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> Message-ID: On Thu, 2020-09-17 at 13:48 +0100, 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. I do not think the milestone should include nice-to-have items. -- 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.] From kurt at roeckx.be Thu Sep 17 16:49:19 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 17 Sep 2020 18:49:19 +0200 Subject: 3.0 beta 1 milestone In-Reply-To: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> References: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> Message-ID: <20200917164919.GA1239813@roeckx.be> On Thu, Sep 17, 2020 at 01:48:18PM +0100, Matt Caswell wrote: > 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? We need to have a decision about those before beta 1, which can include: - It should be in beta 1 - It doesn't block beta 1, before the 3.0 release is fine too, which just means that you change the milestone to 3.0 - It doesn't go into 3.0. No idea what the best way to tag them is. Kurt From beldmit at gmail.com Thu Sep 17 17:21:50 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 17 Sep 2020 20:21:50 +0300 Subject: 3.0 beta 1 milestone In-Reply-To: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> References: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Sep 18 07:26:46 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 18 Sep 2020 09:26:46 +0200 Subject: 3.0 beta 1 milestone In-Reply-To: References: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> Message-ID: <87sgbfh7ex.wl-levitte@openssl.org> On Thu, 17 Sep 2020 15:57:52 +0200, Tomas Mraz wrote: > I do not think the milestone should include nice-to-have items. Another view is that beta 1 is feature freeze. If those nice to have items are characterized as new features, then it makes sense to have them included in the beta 1 milestone if we want them for 3.0.0. Otherwise, we will have to put them on the waiting list for after 3.0.0. If they are not characterized as new features, that is a different matter, of course. The conclusion is that we will have to take some time (I assume that'll be quick in most cases) thinking how we characterize certain PRs before beta 1 is released. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Sep 18 07:31:53 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 18 Sep 2020 09:31:53 +0200 Subject: 3.0 beta 1 milestone In-Reply-To: <20200917164919.GA1239813@roeckx.be> References: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> <20200917164919.GA1239813@roeckx.be> Message-ID: <87r1qzh76e.wl-levitte@openssl.org> On Thu, 17 Sep 2020 18:49:19 +0200, Kurt Roeckx wrote: > > On Thu, Sep 17, 2020 at 01:48:18PM +0100, Matt Caswell wrote: > > 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? > > We need to have a decision about those before beta 1, which can > include: > - It should be in beta 1 > - It doesn't block beta 1, before the 3.0 release is fine too, > which just means that you change the milestone to 3.0 > - It doesn't go into 3.0. No idea what the best way to tag them > is. Sorry, I realise I repeated what you said... Regarding things not going into 3.0.0, one way is not to assign a milestone to them. If we decide to do it that way, it probably means that we should set the 3.0.0 milestone on everything that we consider a bug fix rather than a new feature. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tmraz at redhat.com Fri Sep 18 07:32:59 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 18 Sep 2020 09:32:59 +0200 Subject: 3.0 beta 1 milestone In-Reply-To: <87sgbfh7ex.wl-levitte@openssl.org> References: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> <87sgbfh7ex.wl-levitte@openssl.org> Message-ID: <0960b921204bdeae932f5dadf8e60020fec32ef5.camel@redhat.com> On Fri, 2020-09-18 at 09:26 +0200, Richard Levitte wrote: > On Thu, 17 Sep 2020 15:57:52 +0200, > Tomas Mraz wrote: > > I do not think the milestone should include nice-to-have items. > > Another view is that beta 1 is feature freeze. If those nice to have > items are characterized as new features, then it makes sense to have > them included in the beta 1 milestone if we want them for 3.0.0. > Otherwise, we will have to put them on the waiting list for after > 3.0.0. Yes, but that effectively makes them either "must have in beta1" if we decide that we want them in 3.0.0 or "not at all in beta1" if we decide otherwise. As we are so close to beta1 now we should not have any "let's see if they can make it" features for 3.0.0 anymore. > If they are not characterized as new features, that is a different > matter, of course. The conclusion is that we will have to take some > time (I assume that'll be quick in most cases) thinking how we > characterize certain PRs before beta 1 is released. Yes! -- 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.] From matt at openssl.org Fri Sep 18 07:58:14 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Sep 2020 08:58:14 +0100 Subject: 3.0 beta 1 milestone In-Reply-To: <87sgbfh7ex.wl-levitte@openssl.org> References: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> <87sgbfh7ex.wl-levitte@openssl.org> Message-ID: On 18/09/2020 08:26, Richard Levitte wrote: > On Thu, 17 Sep 2020 15:57:52 +0200, > Tomas Mraz wrote: >> I do not think the milestone should include nice-to-have items. > > Another view is that beta 1 is feature freeze. If those nice to have > items are characterized as new features, then it makes sense to have > them included in the beta 1 milestone if we want them for 3.0.0. > Otherwise, we will have to put them on the waiting list for after > 3.0.0. Not every feature that someone dreams up and creates a PR for should mean we have to hold 3.0 beta 1 until it goes in. There are features that are required, and features that are nice-to-have. If nice-to-have features don't reach approval in time, then they should be dropped from 3.0, and wait for 3.1 instead. Matt > > If they are not characterized as new features, that is a different > matter, of course. The conclusion is that we will have to take some > time (I assume that'll be quick in most cases) thinking how we > characterize certain PRs before beta 1 is released. > > Cheers, > Richard > From levitte at openssl.org Fri Sep 18 09:00:12 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 18 Sep 2020 11:00:12 +0200 Subject: 3.0 beta 1 milestone In-Reply-To: References: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> Message-ID: <87mu1nh337.wl-levitte@openssl.org> I've found what's going wrong there, and I agree that it needs to be fixed ASAP, although I don't view it per se as a beta 1 blocker. Either way, a fix is coming up. Cheers, Richard On Thu, 17 Sep 2020 19:21:50 +0200, Dmitry Belyavsky wrote: > > > 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 > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Fri Sep 18 15:24:59 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Sep 2020 16:24:59 +0100 Subject: Status of the remaining beta1 PRs Message-ID: <03a4d393-d048-6a8d-ef9f-d8cd205d3513@openssl.org> As of right now we have 13 PRs with the beta1 milestone against them. Of these there are 4 which really need our focused attention. These are 2 PRs which are in a state of "written but still in review": WIP: Implement Provider side SM2 Asymmetric Cipher support https://github.com/openssl/openssl/pull/12913 Needed to complete the SM2 support (WIP because dependent on 12536, which is in "approval done" status but not yet merged) ENCODER: Refactor the OSSL_ENCODER API to be more like OSSL_DECODER https://github.com/openssl/openssl/pull/12873 Still in review 1 PR which is in a state of "we really need to do something about this": [WIP, Parked] EVP: Adapt EVP_PKEY_set_alias_type() for provider-native EVP_PKEYs https://github.com/openssl/openssl/pull/12675 Since this affects a public API we probably really do need to figure out what to do with the EVP_PKEY_set_alias_type() 1 PR which is in a state of "its unclear what we do with this": [WIP] Rename some XXX_ex() related methods to XXX_with_libctx() https://github.com/openssl/openssl/pull/12701 With no agreement on a naming convention its unclear if this should go ahead or not The remaining 9 PRs can be split into 2 groups: 6 are in the "approval done" state, so can be pushed soon (one of these we are actually deliberately holding back until nearer the beta release). 3 PRs are in a state of "probably can be dropped altogether": WIP: Fix the DRBG reseed propagation [master] https://github.com/openssl/openssl/pull/12871 This is a bug fix so may not be needed for beta1 at all. Matthias says: "I put the beta1 milestone against it because I wasn't sure whether I need to change some public API or not. Currently, I don't think it's necessary, but I need to check it once more. That will probably not happen before the weekend, but I'll remember to move the ticket from the beta1 milestone to the release milestone, if it's not urgent." Reorder algorithm parameter to be first in *_FETCH() operations. https://github.com/openssl/openssl/pull/12778 Disputed, and probably not needed. Probably can be dropped. RAND: allow the primary, public and private of DRBGs to be overriden and replaced. https://github.com/openssl/openssl/pull/12754 A feature that current discussion on the PR seems to suggest we may drop because it may not be needed for 3.0 after all. Matt From tmraz at redhat.com Fri Sep 18 15:59:10 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 18 Sep 2020 17:59:10 +0200 Subject: Status of the remaining beta1 PRs In-Reply-To: <03a4d393-d048-6a8d-ef9f-d8cd205d3513@openssl.org> References: <03a4d393-d048-6a8d-ef9f-d8cd205d3513@openssl.org> Message-ID: On Fri, 2020-09-18 at 16:24 +0100, Matt Caswell wrote: > > 1 PR which is in a state of "its unclear what we do with this": > [WIP] Rename some XXX_ex() related methods to XXX_with_libctx() > https://github.com/openssl/openssl/pull/12701 > With no agreement on a naming convention its unclear if this should > go > ahead or not We should do something consistent - either rename the _ex functions that just add libctx (and property query) or rename the existing with_libctx functions to _ex functions. The current state is a mess having some functions with _ex and some with _with_libctx. -- 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.] From matt at openssl.org Fri Sep 18 16:09:12 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Sep 2020 17:09:12 +0100 Subject: Status of the remaining beta1 PRs In-Reply-To: References: <03a4d393-d048-6a8d-ef9f-d8cd205d3513@openssl.org> Message-ID: On 18/09/2020 16:59, Tomas Mraz wrote: > On Fri, 2020-09-18 at 16:24 +0100, Matt Caswell wrote: >> >> 1 PR which is in a state of "its unclear what we do with this": >> [WIP] Rename some XXX_ex() related methods to XXX_with_libctx() >> https://github.com/openssl/openssl/pull/12701 >> With no agreement on a naming convention its unclear if this should >> go >> ahead or not > > We should do something consistent - either rename the _ex functions > that just add libctx (and property query) or rename the existing > with_libctx functions to _ex functions. > > The current state is a mess having some functions with _ex and some > with _with_libctx. > The current vote on the policy is still ongoing (the subject of this PR is the one covered by chapter 6.2 in the proposed coding style). Unfortunately there is currently no clear outcome on that vote and there are still a significant number of outstanding votes. Without a clear decision one way or another on that vote we cannot decide a way forward. If the vote passes, then it is clear what we have to do. If the vote fails then we will probably have to make a one off vote about what to do about existing _with_libctx vs _ex discrepancies without making a policy out of it. Please can I encourage OTC members to vote one way or the other so that we can move forward. Matt From levitte at openssl.org Sun Sep 20 06:42:17 2020 From: levitte at openssl.org (Richard Levitte) Date: Sun, 20 Sep 2020 08:42:17 +0200 Subject: Status of the remaining beta1 PRs In-Reply-To: <03a4d393-d048-6a8d-ef9f-d8cd205d3513@openssl.org> References: <03a4d393-d048-6a8d-ef9f-d8cd205d3513@openssl.org> Message-ID: <875z89gd9y.wl-levitte@openssl.org> On Fri, 18 Sep 2020 17:24:59 +0200, Matt Caswell wrote: > > 1 PR which is in a state of "we really need to do something about this": > [WIP, Parked] EVP: Adapt EVP_PKEY_set_alias_type() for provider-native > EVP_PKEYs > https://github.com/openssl/openssl/pull/12675 > Since this affects a public API we probably really do need to figure out > what to do with the EVP_PKEY_set_alias_type() There's a counter PR now: #12920 -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Sep 21 09:59:57 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 21 Sep 2020 10:59:57 +0100 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> <9a846dc2-2fac-7457-7f8a-19f3bf73cee8@openssl.org> Message-ID: On 16/09/2020 16:56, Matt Caswell wrote: >> "Adopt the coding style policy on function arguments as shown in chapter >> 6.1 of web PR 194 (commit 7b45b46d71f)" This vote failed: accepted: no (for: 2, against: 5, abstained: 2, not voted: 2) >> >> "Adopt the coding style policy on extending existing functions as shown >> in chapter 6.2 of web PR 194 (commit 7b45b46d71f)" This vote is still in progress. Matt >> >> In the event that one vote passes but the other vote does not I will >> remove the section of text that did not pass from the PR and adjust >> chapter numbers accordingly. >> >> Matt >> >>> >>> Since we're not yet fully in agreement some compromises will have to be >>> made. I hope I've come up with something which isn't too abhorrent to >>> anyone. >>> >>> Please take a look. >>> >>> Matt >>> >>> >>> On 05/09/2020 04:48, SHANE LONTIS wrote: >>>> >>>> PR?#12778 reorders all the API?s of the form: >>>> >>>> >>>> EVP_XX_fetch(libctx,?algname, propq)? >>>> >>>> >>>> So that the algorithm name appears first..? >>>> >>>> >>>> e.g: EVP_MD_fetch(digestname, libctx, propq); >>>> >>>> This now logically reads as 'search for this algorithm using these >>>> parameters?. >>>> >>>> The libctx, propq should always appear together as a pair of parameters. >>>> There are only a few places where only the libctx is needed, which means >>>> that if there is no propq it is?likely to cause a bug in a fetch at some >>>> point.? >>>> >>>> This keeps the API?s more consistent with other existing XXX_with_libctx >>>> API?s that put the libctx, propq at the end of the parameter list.. >>>> The exception to this rule is that callback(s) and their arguments occur >>>> after the libctx, propq.. >>>> >>>> e.g: >>>> typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn) >>>> ? ? (const OSSL_STORE_LOADER *loader, >>>> ? ? ?const char *uri, OPENSSL_CTX *libctx, const char *propq, >>>> ? ? ?const UI_METHOD *ui_method, void *ui_data); >>>> >>>> An otc_hold was put on this.. Do we need to have a formal vote? >>>> This really needs to be sorted out soon so the API?s can be locked down >>>> for beta. >>>> >>>> -------- >>>> Also discussed in a weekly meeting and numerous PR discussions was the >>>> removal of the long winded API?s ending with ?with_libctx? >>>> e.g CMS_data_create_with_libctx >>>> The proposed renaming for this was to continue with the _ex notation.. >>>> If there is an existing _ex name then it becomes _ex2, etc. >>>> There will most likely be additional parameters in the future for some >>>> API?s, so this notation would be more consistent with current API?s. >>>> Does this also need a vote? >>>> >>>> Regards, >>>> Shane >>>> >>>> From mark at openssl.org Mon Sep 21 11:54:26 2020 From: mark at openssl.org (Mark J Cox) Date: Mon, 21 Sep 2020 12:54:26 +0100 Subject: When "failed CI" isn't a blocker In-Reply-To: References: Message-ID: Didn't see any response one way or the other so I'll create a 'ignore ci failure' label, change the bot logic to deal with it, and go through the stale things in the failed CI state. Mark On Mon, Sep 7, 2020 at 11:15 AM Mark J Cox wrote: > > So when we have a PR in a state where any CI is marked as failing I > lump them into a single "failed CI" state. The stale (over 30 day old > untouched) ones are shown below. But most of them (if not all) are > not actually CI failures. Aside from fixing the CI, one solution > would be a label "Ignore CI failure" which can be manually set by a > committer who reviews the fail and it's harmless, then I could have > the bot ignore failed CI when that label is present. (And perhaps the > bot also resets the label if the CI gets restarted due to changes). > That would help have things in the right state bucket and can be acted > on/reminded properly. > > Mark > > at Sep7: failed CI ( 19 issues, median 276 days) > 11464 days:37 [* mjc: travis timeout on one combination, could ignore] > 11327 reviewed:commented days:177 [* mjc: same] > 11288 branch: master, reviewed:commented days:180 [* mjc: same] > 11257 branch: 1.1.1, branch: master, reviewed:approved days:178 [* > mjc: same, ......] > 11151 days:189 > 10797 branch: master, reviewed:commented days:150 > 10556 days:276 > 10465 days:293 > 9926 days:355 > 9603 days:355 > 9155 reviewed:commented days:229 > 8955 branch: 1.1.1, branch: master, reviewed:dismissed days:304 > 8115 reviewed:commented days:177 > 7921 reviewed:commented days:548 > 7914 reviewed:approved days:607 > 7380 reviewed:commented days:695 > 7051 milestone:Assessed, reviewed:commented days:744 > 4992 milestone:Assessed, reviewed:commented days:317 > 4338 milestone:Assessed, days:153 From matt at openssl.org Mon Sep 21 12:43:52 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 21 Sep 2020 13:43:52 +0100 Subject: Reordering new API's that have a libctx, propq In-Reply-To: References: <05e9cc9f-7fa1-e597-cd96-9ffdca99e973@openssl.org> <9a846dc2-2fac-7457-7f8a-19f3bf73cee8@openssl.org> Message-ID: On 21/09/2020 10:59, Matt Caswell wrote: > > > On 16/09/2020 16:56, Matt Caswell wrote: >>> "Adopt the coding style policy on function arguments as shown in chapter >>> 6.1 of web PR 194 (commit 7b45b46d71f)" > > This vote failed: > > accepted: no (for: 2, against: 5, abstained: 2, not voted: 2) > >>> >>> "Adopt the coding style policy on extending existing functions as shown >>> in chapter 6.2 of web PR 194 (commit 7b45b46d71f)" > > > This vote is still in progress. This vote has now also closed. It was passed: accepted: yes (for: 5, against: 3, abstained: 2, not voted: 1) > > Matt > > >>> >>> In the event that one vote passes but the other vote does not I will >>> remove the section of text that did not pass from the PR and adjust >>> chapter numbers accordingly. >>> >>> Matt >>> >>>> >>>> Since we're not yet fully in agreement some compromises will have to be >>>> made. I hope I've come up with something which isn't too abhorrent to >>>> anyone. >>>> >>>> Please take a look. >>>> >>>> Matt >>>> >>>> >>>> On 05/09/2020 04:48, SHANE LONTIS wrote: >>>>> >>>>> PR?#12778 reorders all the API?s of the form: >>>>> >>>>> >>>>> EVP_XX_fetch(libctx,?algname, propq)? >>>>> >>>>> >>>>> So that the algorithm name appears first..? >>>>> >>>>> >>>>> e.g: EVP_MD_fetch(digestname, libctx, propq); >>>>> >>>>> This now logically reads as 'search for this algorithm using these >>>>> parameters?. >>>>> >>>>> The libctx, propq should always appear together as a pair of parameters. >>>>> There are only a few places where only the libctx is needed, which means >>>>> that if there is no propq it is?likely to cause a bug in a fetch at some >>>>> point.? >>>>> >>>>> This keeps the API?s more consistent with other existing XXX_with_libctx >>>>> API?s that put the libctx, propq at the end of the parameter list.. >>>>> The exception to this rule is that callback(s) and their arguments occur >>>>> after the libctx, propq.. >>>>> >>>>> e.g: >>>>> typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn) >>>>> ? ? (const OSSL_STORE_LOADER *loader, >>>>> ? ? ?const char *uri, OPENSSL_CTX *libctx, const char *propq, >>>>> ? ? ?const UI_METHOD *ui_method, void *ui_data); >>>>> >>>>> An otc_hold was put on this.. Do we need to have a formal vote? >>>>> This really needs to be sorted out soon so the API?s can be locked down >>>>> for beta. >>>>> >>>>> -------- >>>>> Also discussed in a weekly meeting and numerous PR discussions was the >>>>> removal of the long winded API?s ending with ?with_libctx? >>>>> e.g CMS_data_create_with_libctx >>>>> The proposed renaming for this was to continue with the _ex notation.. >>>>> If there is an existing _ex name then it becomes _ex2, etc. >>>>> There will most likely be additional parameters in the future for some >>>>> API?s, so this notation would be more consistent with current API?s. >>>>> Does this also need a vote? >>>>> >>>>> Regards, >>>>> Shane >>>>> >>>>> From openssl at openssl.org Tue Sep 22 13:26:18 2020 From: openssl at openssl.org (OpenSSL) Date: Tue, 22 Sep 2020 13:26:18 +0000 Subject: OpenSSL version 1.1.1h published Message-ID: <20200922132618.GA23664@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1h 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.1.1h 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.1.1-notes.html OpenSSL 1.1.1h 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.1.1h.tar.gz Size: 9810045 SHA1 checksum: 8d0d099e8973ec851368c8c775e05e1eadca1794 SHA256 checksum: 5c9ca8774bd7b03e5784f26ae9e9e6d749c9da2438545077e6b3d755a06595d9 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1h.tar.gz openssl sha256 openssl-1.1.1h.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl9p9DIACgkQ2cTSbQ5g RJG6pAf/Y6B3I9pwD6MG7lm3ywEqp2dAwYym84l39K6LrBFPOg76GmHLby92Se5/ N2S5uHPCcXrBdtHLZZTi1Tn3rwMN6EAJmedZJvMwoxeKJxNjZ2f8K8SjgUkuimSa dKbXtv92uDNRpD4X3Fv+uRatmbvygdjduwJWqgJ88ahz/IM7x1lv8E8GNnkPNBfA 9M9rDP5ThiQAetbefHBq9vb6wywwbi0FGTnXkeaYpyKDXmob0VWUdI0olMFLIUAG ZAQAD8XEPnJBVh4qCOlVy0n/5+jzcOiqcwJyORQc/U0wkV71I9XigW9H7wgg6skD iVQQe2QEODbEbtx9iMPsN4Ssmfk+VA== =OYam -----END PGP SIGNATURE----- From kurt at roeckx.be Tue Sep 22 14:12:48 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 22 Sep 2020 16:12:48 +0200 Subject: 3.0 beta 1 milestone In-Reply-To: <20200917164919.GA1239813@roeckx.be> References: <13999305-0605-2ef8-553e-55537250b5dd@openssl.org> <20200917164919.GA1239813@roeckx.be> Message-ID: <20200922141248.GA1487967@roeckx.be> On Thu, Sep 17, 2020 at 06:49:19PM +0200, Kurt Roeckx wrote: > - It doesn't go into 3.0. No idea what the best way to tag them > is. So I've created a "Post 3.0.0" milestone for that. Kurt From kurt at roeckx.be Wed Sep 23 18:51:28 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 23 Sep 2020 20:51:28 +0200 Subject: Tracking important issues Message-ID: <20200923185128.GA1669330@roeckx.be> Hi, I would like to have a system so that we can tag issues as important. But I think they fall in a few categories: - Features for the next minor/major release (so 3.1 or 4.0) that we find important. I've created a new milestone for that: https://github.com/openssl/openssl/milestone/18 (Post 3.0.0) We've also had a Post 1.1.1 milestone, but that seems to be just things that didn't block the 1.1.1 release, maybe some more things can be moved over. I suggest we do not add all feature requests to the new milestone, so that we can have some kind of overview. - Features we want in before beta 1: The 3.0.0 beta1 milestone - Bugs that need to get fixed before the 3.0.0 release: currently using the 3.0.0 milestone - Important bugs that affect the stable releases. I've started tagging bugs that have "triaged: bug" also with the branches that are affected. But that doesn't say how important it is. I have 2 proposals for that: - Create a milestone for them, like 1.1.1-stable. In cases we have multiple supported branches, we can add for instance a 3.0-stable and use the oldest branches that's a affected as the target. This would at least match what we do now with the "3.0.0" milestone. - Create a label for the severity. I'm not sure we need things like "severity: minor", but it might be useful too. Kurt From paul.dale at oracle.com Thu Sep 24 02:33:56 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 24 Sep 2020 12:33:56 +1000 Subject: Freeze? Message-ID: <776DCF89-EABB-451F-9D4A-44B2E70BE162@oracle.com> 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? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduk at mit.edu Fri Sep 25 23:17:42 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 25 Sep 2020 16:17:42 -0700 Subject: Freeze? In-Reply-To: <776DCF89-EABB-451F-9D4A-44B2E70BE162@oracle.com> References: <776DCF89-EABB-451F-9D4A-44B2E70BE162@oracle.com> Message-ID: <20200925231742.GU89563@kduck.mit.edu> 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). -Ben From shane.lontis at oracle.com Fri Sep 25 23:46:26 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Sat, 26 Sep 2020 09:46:26 +1000 Subject: Freeze? In-Reply-To: <20200925231742.GU89563@kduck.mit.edu> References: <776DCF89-EABB-451F-9D4A-44B2E70BE162@oracle.com> <20200925231742.GU89563@kduck.mit.edu> Message-ID: <1CA4512D-7065-4CEF-BBBB-6E36DB2A3C70@oracle.com> I think this best describes the issue: https://www.youtube.com/watch?v=zsKOYQ7z9CE > On 26 Sep 2020, at 9: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). > > -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Sat Sep 26 07:21:39 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sat, 26 Sep 2020 10:21:39 +0300 Subject: Freeze? In-Reply-To: <20200925231742.GU89563@kduck.mit.edu> References: <776DCF89-EABB-451F-9D4A-44B2E70BE162@oracle.com> <20200925231742.GU89563@kduck.mit.edu> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Sep 26 15:36:42 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 26 Sep 2020 15:36:42 +0000 Subject: Freeze? In-Reply-To: References: <776DCF89-EABB-451F-9D4A-44B2E70BE162@oracle.com> <20200925231742.GU89563@kduck.mit.edu> Message-ID: <5D61C6B9-6D8A-4291-A8B1-2A4D60080B43@akamai.com> As a sponsor of this release, we are concerned about further slippages in the schedule. I understand open source and ?scratch your itch? and all that, but the project made a commitment and several companies have contributed money and/or engineering time. Some of those groups are making plans based on discussed schedules and yes, I am sure that those people are not na?ve about it. I?d like the project to make a statement saying that, unless it?s a regression or breakage, the only PR?s that will be merged for the near future are those directly related to the agreed-upon FIPS work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Sat Sep 26 22:39:51 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 27 Sep 2020 00:39:51 +0200 Subject: Freeze? In-Reply-To: <776DCF89-EABB-451F-9D4A-44B2E70BE162@oracle.com> References: <776DCF89-EABB-451F-9D4A-44B2E70BE162@oracle.com> Message-ID: <20200926223951.GA1870749@roeckx.be> 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. I think we should stop accepting any new changes that are not clearly related to fixing issues that have been introduced during the development of 3.0. Of course, bugs can always be fixed. We've previously announced the deadline for beta 1 to be the 8th of September. Clearly not everything needed is ready. But at some point we will have to make the beta 1 release. Kurt From Matthias.St.Pierre at ncp-e.com Mon Sep 28 12:02:07 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 28 Sep 2020 12:02:07 +0000 Subject: VOTE: Accept the OTC voting policy as defined: Message-ID: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> topic: Accept the OTC voting policy as defined: The proposer of a vote is ultimately responsible for updating the votes.txt file in the repository. Outside of a face to face meeting, voters MUST reply to the vote email indicating their preference and optionally their reasoning. Voters MAY update the votes.txt file in addition. The proposed vote text SHOULD be raised for discussion before calling the vote. Public votes MUST be called on the project list, not the OTC list and the subject MUST begin with "VOTE:". Private votes MUST be called on the OTC list with "PRIVATE VOTE:" beginning subject. Proposed by Matthias St. Pierre (on behalf of the OTC) Public: yes opened: 2020-09-28 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [ ] Mark [ ] Pauli [ ] Viktor [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [+1] Nicola [ ] From nic.tuv at gmail.com Mon Sep 28 12:05:08 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 28 Sep 2020 15:05:08 +0300 Subject: VOTE: Accept the OTC voting policy as defined: In-Reply-To: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> References: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> Message-ID: +1, as expressed during the f2f meeting. Nicola On Mon, Sep 28, 2020, 15:02 Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > topic: Accept the OTC voting policy as defined: > > The proposer of a vote is ultimately responsible for updating the > votes.txt > file in the repository. Outside of a face to face meeting, voters > MUST reply > to the vote email indicating their preference and optionally their > reasoning. > Voters MAY update the votes.txt file in addition. > > The proposed vote text SHOULD be raised for discussion before > calling the vote. > > Public votes MUST be called on the project list, not the OTC list > and the > subject MUST begin with "VOTE:". Private votes MUST be called on > the > OTC list with "PRIVATE VOTE:" beginning subject. > > Proposed by Matthias St. Pierre (on behalf of the OTC) > Public: yes > opened: 2020-09-28 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [+1] > Nicola [ ] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Mon Sep 28 12:10:03 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 28 Sep 2020 22:10:03 +1000 Subject: VOTE: Accept the OTC voting policy as defined: In-Reply-To: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> References: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> Message-ID: <06C0FD06-E75A-4835-8104-95F5C63A1B18@oracle.com> +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 28 Sep 2020, at 10:02 pm, Dr. Matthias St. Pierre wrote: > > topic: Accept the OTC voting policy as defined: > > The proposer of a vote is ultimately responsible for updating the votes.txt > file in the repository. Outside of a face to face meeting, voters MUST reply > to the vote email indicating their preference and optionally their reasoning. > Voters MAY update the votes.txt file in addition. > > The proposed vote text SHOULD be raised for discussion before calling the vote. > > Public votes MUST be called on the project list, not the OTC list and the > subject MUST begin with "VOTE:". Private votes MUST be called on the > OTC list with "PRIVATE VOTE:" beginning subject. > > Proposed by Matthias St. Pierre (on behalf of the OTC) > Public: yes > opened: 2020-09-28 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [+1] > Nicola [ ] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Sep 28 12:17:24 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 28 Sep 2020 12:17:24 +0000 Subject: VOTE: Accept the OTC voting policy as defined: In-Reply-To: <06C0FD06-E75A-4835-8104-95F5C63A1B18@oracle.com> References: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> <06C0FD06-E75A-4835-8104-95F5C63A1B18@oracle.com> Message-ID: <8f299b5bac08431fbab2891d3c6a9a09@ncp-e.com> Oh, sorry, you are right! The participants of the face to face already voted, but I forgot to fill in the votes. Apologies, I'll make up for it in a minute! Matthias From: openssl-project On Behalf Of Dr Paul Dale Sent: Monday, September 28, 2020 2:10 PM To: openssl-project at openssl.org Subject: Re: VOTE: Accept the OTC voting policy as defined: +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia On 28 Sep 2020, at 10:02 pm, Dr. Matthias St. Pierre > wrote: topic: Accept the OTC voting policy as defined: The proposer of a vote is ultimately responsible for updating the votes.txt file in the repository. Outside of a face to face meeting, voters MUST reply to the vote email indicating their preference and optionally their reasoning. Voters MAY update the votes.txt file in addition. The proposed vote text SHOULD be raised for discussion before calling the vote. Public votes MUST be called on the project list, not the OTC list and the subject MUST begin with "VOTE:". Private votes MUST be called on the OTC list with "PRIVATE VOTE:" beginning subject. Proposed by Matthias St. Pierre (on behalf of the OTC) Public: yes opened: 2020-09-28 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [ ] Mark [ ] Pauli [ ] Viktor [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [+1] Nicola [ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Sep 28 12:22:18 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 28 Sep 2020 12:22:18 +0000 Subject: VOTE: Accept the OTC voting policy as defined: In-Reply-To: <8f299b5bac08431fbab2891d3c6a9a09@ncp-e.com> References: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> <06C0FD06-E75A-4835-8104-95F5C63A1B18@oracle.com> <8f299b5bac08431fbab2891d3c6a9a09@ncp-e.com> Message-ID: <4acc0646de1d45cebf813660385d9eac@ncp-e.com> Now with the votes already cast filled in :-) topic: Accept the OTC voting policy as defined: The proposer of a vote is ultimately responsible for updating the votes.txt file in the repository. Outside of a face to face meeting, voters MUST reply to the vote email indicating their preference and optionally their reasoning. Voters MAY update the votes.txt file in addition. The proposed vote text SHOULD be raised for discussion before calling the vote. Public votes MUST be called on the project list, not the OTC list and the subject MUST begin with "VOTE:". Private votes MUST be called on the OTC list with "PRIVATE VOTE:" beginning subject. Proposed by Matthias St. Pierre (on behalf of the OTC) Public: yes opened: 2020-09-28 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [+1] Mark [+1] Pauli [+1] Viktor [ ] Tim [+1] Richard [+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] Nicola [+1] From: openssl-project On Behalf Of Dr. Matthias St. Pierre Sent: Monday, September 28, 2020 2:17 PM To: Dr Paul Dale ; Nicola Tuveri (nic.tuv at gmail.com) ; openssl-project at openssl.org Subject: RE: VOTE: Accept the OTC voting policy as defined: Oh, sorry, you are right! The participants of the face to face already voted, but I forgot to fill in the votes. Apologies, I'll make up for it in a minute! Matthias From: openssl-project > On Behalf Of Dr Paul Dale Sent: Monday, September 28, 2020 2:10 PM To: openssl-project at openssl.org Subject: Re: VOTE: Accept the OTC voting policy as defined: +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia On 28 Sep 2020, at 10:02 pm, Dr. Matthias St. Pierre > wrote: topic: Accept the OTC voting policy as defined: The proposer of a vote is ultimately responsible for updating the votes.txt file in the repository. Outside of a face to face meeting, voters MUST reply to the vote email indicating their preference and optionally their reasoning. Voters MAY update the votes.txt file in addition. The proposed vote text SHOULD be raised for discussion before calling the vote. Public votes MUST be called on the project list, not the OTC list and the subject MUST begin with "VOTE:". Private votes MUST be called on the OTC list with "PRIVATE VOTE:" beginning subject. Proposed by Matthias St. Pierre (on behalf of the OTC) Public: yes opened: 2020-09-28 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [ ] Mark [ ] Pauli [ ] Viktor [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [+1] Nicola [ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Sep 28 15:53:50 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 28 Sep 2020 15:53:50 +0000 Subject: Add 'OpenSSL Technical Policies' page to openssl.org? Message-ID: <58ead33ca6424a93a73c43b57d7b6437@ncp-e.com> Hi, Pauli added the following action item for me to the OTC vF2F spreadsheet: > Matthias: create web PR for OTC voting policy. I wouldn't mind to add the content, but currently there seems to be no appropriate place yet to put it. The voting process is currently described only in the OMC bylaws, OpenSSL Bylaws openssl/web:policies/omc-bylaws.html and there is no specific document for implementary regulations, or more generally, technical policies decided by the OTC. The web page needs a name and an URL, something like OpenSSL Technical Policies openssl/web:policies/otc-policies.html and it needs to be referenced by the Policies page . If you agree with the name and URL, I can add that part to the web PR as well. Matthias From matt at openssl.org Mon Sep 28 16:11:43 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 28 Sep 2020 17:11:43 +0100 Subject: Add 'OpenSSL Technical Policies' page to openssl.org? In-Reply-To: <58ead33ca6424a93a73c43b57d7b6437@ncp-e.com> References: <58ead33ca6424a93a73c43b57d7b6437@ncp-e.com> Message-ID: <06ee29a2-a7be-1917-01de-d55b7ec8e995@openssl.org> Works for me. Matt On 28/09/2020 16:53, Dr. Matthias St. Pierre wrote: > Hi, > > Pauli added the following action item for me to the OTC vF2F spreadsheet: > >> Matthias: create web PR for OTC voting policy. > > I wouldn't mind to add the content, but currently there seems to be no > appropriate place yet to put it. The voting process is currently described > only in the OMC bylaws, > > OpenSSL Bylaws > openssl/web:policies/omc-bylaws.html > > and there is no specific document for implementary regulations, or more generally, > technical policies decided by the OTC. The web page needs a name and an URL, > something like > > OpenSSL Technical Policies > openssl/web:policies/otc-policies.html > > and it needs to be referenced by the Policies page . > If you agree with the name and URL, I can add that part to the web PR as well. > > Matthias > > From levitte at openssl.org Mon Sep 28 16:50:22 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 28 Sep 2020 18:50:22 +0200 Subject: Proposal for a libcrypto module style guide / policy Message-ID: <87sgb1etgx.wl-levitte@openssl.org> The code style proposal that we had before didn't fare well and was deemed incomplete or contradictory. Still, we need something for a more overall view on how we should design an new API as well as how we should treat existing APIs. Here's a proposal for something that I/we hope have grasped all the diverse feedback that's come our way and can become a good enough guide. I currently have it as a separate file, and not committed anywhere, because I wasn't sure where it should end up, and need ideas. Something to be noted is the current coding style policy doesn't have a natural space for higher level items such as whole APIs (as opposed to individual functions) or modules. My proposal would be to have a separate document for API / module design (the name of the attached text is a possible name). Ideas, thoughts, constructive criticism, acclamations, etc welcome. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- OpenSSL modules =============== A module in the sense described here is a part of OpenSSL functionality, in particular in libcrypto, not a dynamically loadable module. A module is recognised by its upper case beginning of public function names. For example, "RAND_bytes" is a function in the RAND module. In the rest of this text, '{NAME}' is used to represent the module name. For working with entire modules, we have three cases to consider: 1. Existing modules 2. New modules 3. Function arguments in new modules [ note: there are core "modules" as well, which aren't quite the same. CRYPTO and OSSL_PROVIDER come to mind. ] Existing modules ================ >From time to time it is necessary to extend an existing module with new functions. To make such functions consistent with the API of that module, look at similar or related functions in the same module, otherwise follow the general rules for adding functions in a new module as described below. New modules =========== OpenSSL modules may have different levels of complexity: 1. Simple 2. Class 3. Class, dynamic Simple ------ The absolutely simplest don't have an associated type, and simply have functions of this form: rettype {NAME}_do_something([args]) Otherwise, still fairly simple are those with an associated type that has the same name as the module, but nothing more: {NAME} *{NAME}_new([args]) rettype {NAME}_get_something({NAME} *,[args]) rettype {NAME}_set_something({NAME} *,[args]) rettype {NAME}_do_something({NAME} *,[args]) void {NAME}_free({NAME} *) Class ----- Somewhat more complex modules have multiple backend implementations, much like C++ classes have virtual methods. For those, there are two types, {NAME} and {NAME}_METHOD, where {NAME} holds execution data, while {NAME}_METHOD holds function pointers to a backend implementation. Such modules should use the following pattern: {NAME} *{NAME}_new({NAME}_METHOD *, [args]) rettype {NAME}_get_something({NAME} *,[args]) rettype {NAME}_set_something({NAME} *,[args]) rettype {NAME}_do_something({NAME} *,[args]) void {NAME}_free({NAME} *) Class, dynamic -------------- Some more complex modules are also dynamic, in that they get their implementation from diverse places, and referring to those implementations isn't as simple as using a method structure pointer directly. It's often more suitable that the constructor finds the method structure implicitly, from a given implementation name or an object that can be used to derive a suitable name from. The constructor for such a module typically relies on a factory pool, such as OPENSSL_CTX (OPENSSL_CTX is a bag of diverse core library things, and is generally seen as the libcrypto library state. With constructors, it is used in the role of a factory pool). The constructor pattern should look like this: {NAME} *{NAME}_new(OPENSSL_CTX *libctx, const char *name, [args]) {NAME} *{NAME}_new(OPENSSL_CTX *libctx, OBJTYPE *object, [args]) The first variant is a straightforward construct by name, the second would rather derive the name from another related type. The rest of such a module's API should like as in "Class" above. Function arguments in new modules ================================= For all of the above patterns, the remaining argument list (seen as '[args]' above) should be put into order of importance. Deciding the relative importance of arguments is necessarily somewhat subjective, but the following guideline ordering of the arguments should be considered: 1) additional context arguments If multiple contexts are necessary then they should be in order of most general to most specific. In some cases (typically with an OPENSSL_CTX), a context may be NULL to indicate a default context should be used. [ This should be *very* rare ] 2) Data transfer parameters (these are parameters used to convert or copy some sort of input data to some kind of output data). a) output / destination data parameters b) input / source data parameters 3) Required arguments 4) Optional arguments Here optional are arguments that are meant to be used in certain circumstances only and therefore may be "NULL" or empty. 5) Function pointers to callback functions and associated callback data pointer, in pairs. In function prototypes, include parameter names with their data types. Although this is not required by the C language, it is preferred in OpenSSL because it is a simple way to add valuable information for the reader. The name in the prototype declaration should match the name in the function definition. From engr.abhiarora at gmail.com Wed Sep 9 15:40:03 2020 From: engr.abhiarora at gmail.com (Abhi Arora) Date: Wed, 09 Sep 2020 15:40:03 -0000 Subject: Memory leak in openssl 1.1.1d Message-ID: I am using openssl 1.1.1d. I found out around 228 bytes are being directly lost (as per valgrind) report. I have one application which uses curl (7.64) and I wrote the same application using POCO HTTPS and I got the same result. I thought it could be related to the cipher suit. I can see the leak is dependent on the URL being used (all were https). For one of the urls, it was leaking 228 (directly) per connection and disconnection. For one of the urls, the same code doesn't leak atall (no matter how many times you run that code in a for loop). For the urls which were leaking, the following cipher suites were being used: 1. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 2. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 Here is the valgrind summary: ==8620== HEAP SUMMARY: ==8620== in use at exit: 121,777 bytes in 1,097 blocks ==8620== total heap usage: 129,382 allocs, 128,285 frees, 10,635,842 bytes allocated ==8620== ==8620== 8 bytes in 1 blocks are possibly lost in loss record 16 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E75523: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 8 bytes in 1 blocks are definitely lost in loss record 17 of 372 ==8620== at 0x483F310: operator new(unsigned int) (vg_replace_malloc.c:336) ==8620== by 0x36D15: main (sample_pki.cpp:27) ==8620== ==8620== 8 bytes in 1 blocks are definitely lost in loss record 18 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) ==8620== by 0x4C76E07: ECDSA_SIG_new (ec_asn1.c:1214) ==8620== by 0x537064B: pkcs11_try_pkey_ec_sign (p11_pkey.c:546) ==8620== by 0x537064B: pkcs11_pkey_ec_sign (p11_pkey.c:634) ==8620== by 0x4CB70CD: EVP_DigestSignFinal (m_sigver.c:148) ==8620== by 0x4BA9FF3: tls_construct_cert_verify (statem_lib.c:307) ==8620== by 0x4BA42C7: write_state_machine (statem.c:843) ==8620== by 0x4BA42C7: state_machine (statem.c:443) ==8620== by 0x4B8BABB: ssl3_read_bytes (rec_layer_s3.c:1278) ==8620== by 0x4B900E1: ssl3_read_internal (s3_lib.c:4473) ==8620== by 0x4B9013F: ssl3_read (s3_lib.c:4497) ==8620== by 0x4B96A6D: ssl_read_internal (ssl_lib.c:1761) ==8620== by 0x4B96B09: SSL_read (ssl_lib.c:1775) ==8620== ==8620== 16 bytes in 2 blocks are possibly lost in loss record 55 of 372 ==8620== at 0x483EA30: malloc (vg_replace_malloc.c:306) ==8620== by 0x48419FF: realloc (vg_replace_malloc.c:834) ==8620== by 0x4E73B5D: amqpvalue_set_map_value (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 40 bytes in 10 blocks are possibly lost in loss record 182 of 372 ==8620== at 0x483EA30: malloc (vg_replace_malloc.c:306) ==8620== by 0x48419FF: realloc (vg_replace_malloc.c:834) ==8620== by 0x4E738BB: amqpvalue_set_list_item (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 48 bytes in 1 blocks are possibly lost in loss record 210 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E7582D: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 48 bytes in 2 blocks are possibly lost in loss record 211 of 372 ==8620== at 0x48419B0: realloc (vg_replace_malloc.c:834) ==8620== by 0x4E73B5D: amqpvalue_set_map_value (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 56 bytes in 1 blocks are possibly lost in loss record 215 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E74FF9: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 64 bytes in 2 blocks are possibly lost in loss record 228 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E74477: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 64 bytes in 1 blocks are definitely lost in loss record 229 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4A8D411: __libc_alloc_buffer_allocate (alloc_buffer_allocate.c:26) ==8620== by 0x4AE2B51: alloc_buffer_allocate (alloc_buffer.h:143) ==8620== by 0x4AE2B51: __resolv_conf_allocate (resolv_conf.c:411) ==8620== by 0x4AE147D: __resolv_conf_load (res_init.c:592) ==8620== by 0x4AE292B: __resolv_conf_get_current (resolv_conf.c:163) ==8620== by 0x4AE19D7: __res_vinit (res_init.c:614) ==8620== by 0x4AE24B1: maybe_init (resolv_context.c:122) ==8620== by 0x4AE24B1: context_get.part.1 (resolv_context.c:184) ==8620== by 0x4ABBAE7: gaih_inet.constprop.6 (getaddrinfo.c:751) ==8620== by 0x4ABC90B: getaddrinfo (getaddrinfo.c:2265) ==8620== by 0x4B4AA17: Curl_getaddrinfo_ex (in /usr/lib/libcurl.so.4.5.0) ==8620== ==8620== 80 bytes in 3 blocks are possibly lost in loss record 246 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E7547D: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 92 bytes in 3 blocks are possibly lost in loss record 256 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E74E3D: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 128 bytes in 4 blocks are possibly lost in loss record 278 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E74ABF: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 128 bytes in 4 blocks are possibly lost in loss record 279 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E74DF1: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 128 bytes in 4 blocks are possibly lost in loss record 280 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E70EC5: amqpvalue_create_map (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 152 bytes in 1 blocks are possibly lost in loss record 291 of 372 ==8620== at 0x4841748: calloc (vg_replace_malloc.c:760) ==8620== by 0x400C871: allocate_dtv (dl-tls.c:286) ==8620== by 0x400CEB3: _dl_allocate_tls (dl-tls.c:530) ==8620== by 0x4A18585: allocate_stack (allocatestack.c:621) ==8620== by 0x4A18585: pthread_create@@GLIBC_2.4 (pthread_create.c:669) ==8620== by 0x4B4B507: Curl_thread_create (in /usr/lib/libcurl.so.4.5.0) ==8620== ==8620== 192 bytes in 6 blocks are possibly lost in loss record 303 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E75329: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 242 bytes in 8 blocks are possibly lost in loss record 310 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E70C33: amqpvalue_create_symbol (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 256 bytes in 8 blocks are possibly lost in loss record 322 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E70C1B: amqpvalue_create_symbol (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 320 bytes in 10 blocks are possibly lost in loss record 326 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E7611B: amqpvalue_create_composite_with_ulong_descriptor (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 320 bytes in 10 blocks are possibly lost in loss record 327 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E6FD95: amqpvalue_create_ulong (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 320 bytes in 10 blocks are possibly lost in loss record 328 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E70DBD: amqpvalue_create_list (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 360 bytes in 6 blocks are possibly lost in loss record 331 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E7467F: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 576 bytes in 18 blocks are possibly lost in loss record 337 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E70A6B: amqpvalue_create_string (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 1,024 bytes in 4 blocks are indirectly lost in loss record 351 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) ==8620== by 0x4C498EB: bn_expand_internal (bn_lib.c:268) ==8620== by 0x4C498EB: bn_expand2 (bn_lib.c:292) ==8620== by 0x4C499B3: BN_copy (bn_lib.c:329) ==8620== by 0x4C4A5D7: BN_MONT_CTX_set (bn_mont.c:275) ==8620== by 0x4C4A7F7: BN_MONT_CTX_set_locked (bn_mont.c:450) ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) ==8620== by 0x4BA824D: tls_process_key_exchange (statem_clnt.c:2401) ==8620== ==8620== 1,039 bytes in 18 blocks are possibly lost in loss record 352 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E70A83: amqpvalue_create_string (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 1,088 bytes in 34 blocks are possibly lost in loss record 353 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4E754A9: ??? (in /usr/lib/libuamqp.so.1.2.12) ==8620== ==8620== 2,064 bytes in 4 blocks are indirectly lost in loss record 359 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) ==8620== by 0x4C498EB: bn_expand_internal (bn_lib.c:268) ==8620== by 0x4C498EB: bn_expand2 (bn_lib.c:292) ==8620== by 0x4C49A4B: BN_set_bit (bn_lib.c:659) ==8620== by 0x4C4A6FB: BN_MONT_CTX_set (bn_mont.c:395) ==8620== by 0x4C4A7F7: BN_MONT_CTX_set_locked (bn_mont.c:450) ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) ==8620== by 0x4BA824D: tls_process_key_exchange (statem_clnt.c:2401) ==8620== ==8620== 2,304 bytes in 7 blocks are indirectly lost in loss record 362 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) ==8620== by 0x4C498EB: bn_expand_internal (bn_lib.c:268) ==8620== by 0x4C498EB: bn_expand2 (bn_lib.c:292) ==8620== by 0x4C499B3: BN_copy (bn_lib.c:329) ==8620== by 0x4C4A5D7: BN_MONT_CTX_set (bn_mont.c:275) ==8620== by 0x4C4A7F7: BN_MONT_CTX_set_locked (bn_mont.c:450) ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) ==8620== by 0x4C27D59: ASN1_item_verify (a_verify.c:167) ==8620== ==8620== 3,392 (304 direct, 3,088 indirect) bytes in 4 blocks are definitely lost in loss record 365 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4C4A531: BN_MONT_CTX_new (bn_mont.c:232) ==8620== by 0x4C4A7E9: BN_MONT_CTX_set_locked (bn_mont.c:447) ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) ==8620== by 0x4BA824D: tls_process_key_exchange (statem_clnt.c:2401) ==8620== by 0x4BA8725: ossl_statem_client_process_message (statem_clnt.c:1048) ==8620== by 0x4BA4653: read_state_machine (statem.c:636) ==8620== by 0x4BA4653: state_machine (statem.c:434) ==8620== by 0x4B980B1: SSL_do_handshake (ssl_lib.c:3607) ==8620== ==8620== 4,636 bytes in 7 blocks are indirectly lost in loss record 367 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) ==8620== by 0x4C498EB: bn_expand_internal (bn_lib.c:268) ==8620== by 0x4C498EB: bn_expand2 (bn_lib.c:292) ==8620== by 0x4C49A4B: BN_set_bit (bn_lib.c:659) ==8620== by 0x4C4A6FB: BN_MONT_CTX_set (bn_mont.c:395) ==8620== by 0x4C4A7F7: BN_MONT_CTX_set_locked (bn_mont.c:450) ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) ==8620== by 0x4C27D59: ASN1_item_verify (a_verify.c:167) ==8620== ==8620== 7,472 (532 direct, 6,940 indirect) bytes in 7 blocks are definitely lost in loss record 369 of 372 ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) ==8620== by 0x4C4A531: BN_MONT_CTX_new (bn_mont.c:232) ==8620== by 0x4C4A7E9: BN_MONT_CTX_set_locked (bn_mont.c:447) ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) ==8620== by 0x4C27D59: ASN1_item_verify (a_verify.c:167) ==8620== by 0x4CFFF4B: X509_verify (x_all.c:26) ==8620== by 0x4CFCE63: internal_verify (x509_vfy.c:1750) ==8620== by 0x4CFDF03: verify_chain (x509_vfy.c:232) ==8620== ==8620== LEAK SUMMARY: ==8620== definitely lost: 916 bytes in 14 blocks ==8620== indirectly lost: 10,028 bytes in 22 blocks ==8620== possibly lost: 5,701 bytes in 166 blocks ==8620== still reachable: 105,132 bytes in 895 blocks ==8620== suppressed: 0 bytes in 0 blocks ==8620== Reachable blocks (those to which a pointer was found) are not shown. ==8620== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==8620== ==8620== For lists of detected and suppressed errors, rerun with: -s ==8620== ERROR SUMMARY: 28 errors from 28 contexts (suppressed: 0 from 0) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kapil.awate at FireEye.com Tue Sep 22 13:55:06 2020 From: kapil.awate at FireEye.com (Kapil Awate) Date: Tue, 22 Sep 2020 13:55:06 +0000 Subject: Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? Message-ID: <0A7DCA77-E3C5-4CBA-85CF-41B90448B7AF@fireeye.com> Hi, Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? Can anyone help me with this ? Is there any impact on existing functionality after upgrading it to 1.1.1g ? Thanks! This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kapil.awate at FireEye.com Tue Sep 22 14:08:43 2020 From: kapil.awate at FireEye.com (Kapil Awate) Date: Tue, 22 Sep 2020 14:08:43 +0000 Subject: Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? Message-ID: <9EE453BD-4197-4367-A8A2-DD7EB45FC9AB@fireeye.com> Hi, Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? Can anyone help me with this ? Is there any impact on existing functionality after upgrading it to 1.1.1g ? Thanks! This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Tue Sep 29 21:07:17 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 29 Sep 2020 21:07:17 +0000 Subject: VOTE: Accept the OTC voting policy as defined: In-Reply-To: <4acc0646de1d45cebf813660385d9eac@ncp-e.com> References: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> <06C0FD06-E75A-4835-8104-95F5C63A1B18@oracle.com> <8f299b5bac08431fbab2891d3c6a9a09@ncp-e.com> <4acc0646de1d45cebf813660385d9eac@ncp-e.com> Message-ID: The vote has been closed, the verdict is accepted: yes (for: 9, against: 0, abstained: 0, not voted: 2) topic: Accept the OTC voting policy as defined: The proposer of a vote is ultimately responsible for updating the votes.txt file in the repository. Outside of a face to face meeting, voters MUST reply to the vote email indicating their preference and optionally their reasoning. Voters MAY update the votes.txt file in addition. The proposed vote text SHOULD be raised for discussion before calling the vote. Public votes MUST be called on the project list, not the OTC list and the subject MUST begin with "VOTE:". Private votes MUST be called on the OTC list with "PRIVATE VOTE:" beginning subject. Proposed by Matthias St. Pierre (on behalf of the OTC) Public: yes opened: 2020-09-28 closed: 2020-09-29 accepted: yes/no (for: 9, against: 0, abstained: 0, not voted: 2) Matt [+1] Mark [+1] Pauli [+1] Viktor [ ] Tim [+1] Richard [+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] Nicola [+1] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Tue Sep 29 21:31:05 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 29 Sep 2020 21:31:05 +0000 Subject: VOTE: Accept the OTC voting policy as defined: In-Reply-To: References: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> <06C0FD06-E75A-4835-8104-95F5C63A1B18@oracle.com> <8f299b5bac08431fbab2891d3c6a9a09@ncp-e.com> <4acc0646de1d45cebf813660385d9eac@ncp-e.com> Message-ID: See pull request #198 - Add 'OpenSSL Technical Policies' page with a 'Voting Policy' section https://github.com/openssl/web/pull/198 Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Wed Sep 30 07:05:04 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 30 Sep 2020 17:05:04 +1000 Subject: Integration of new algorithms In-Reply-To: References: Message-ID: Instead of using an engine, you should write a provider (assuming you?re using the soon to be released OpenSSL 3.0). It doesn?t need a NID. If you are using OpenSSL 1.1.1, try the OBJ_new_nid() function. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 26 Aug 2020, at 6:48 pm, Kris Kwiatkowski wrote: > > > Hey, > > I'm working on development of OpenSSL ENGINE that integrates > post-quantum algorithms (new NIDs). During integration I > need to modify OpenSSL code to add custom function, but would > prefer not to need add anything to OpenSSL code (so engine > can be dynmicaly loaded by any modern OpenSSL). > > So, In three cases, namely when the code is in callbacks for keygen, > encryption and ctrl (called by EVP_PKEY_CTX_ctrl, EVP_PKEY_encrypt > and EVP_PKEY_keygen) I need to get NID of the scheme. The problem > is that, those functions are called with EVP_PKEY_CTX object > provided as an argument. The NID is stored in the > EVP_PKEY_CTX->pmeth->pkey_id. I think (AFAIK) there is no API > which would return that value. > > I've added a simple function that returns pkey_id from the ctx, but > that means that I need to change OpenSSL code. Is there any way > to get NID without changing OpenSSL? > > Kind regards, > Kris > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Wed Sep 30 07:08:18 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 30 Sep 2020 17:08:18 +1000 Subject: Memory leak in openssl 1.1.1d In-Reply-To: References: Message-ID: This isn?t enough information to diagnose the issue. Which of the leak summary records is the problem? Are you sure that your application is cleaning up properly (hint: it isn?t, e.g. OpenSSL never calls operator new() from the second record). Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 10 Sep 2020, at 1:39 am, Abhi Arora wrote: > > I am using openssl 1.1.1d. I found out around 228 bytes are being directly lost (as per valgrind) report. I have one application which uses curl (7.64) and I wrote the same application using POCO HTTPS and I got the same result. > > I thought it could be related to the cipher suit. I can see the leak is dependent on the URL being used (all were https). For one of the urls, it was leaking 228 (directly) per connection and disconnection. For one of the urls, the same code doesn't leak atall (no matter how many times you run that code in a for loop). > > For the urls which were leaking, the following cipher suites were being used: > 1. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 > 2. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 > > Here is the valgrind summary: > ==8620== HEAP SUMMARY: > ==8620== in use at exit: 121,777 bytes in 1,097 blocks > ==8620== total heap usage: 129,382 allocs, 128,285 frees, 10,635,842 bytes allocated > ==8620== > ==8620== 8 bytes in 1 blocks are possibly lost in loss record 16 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E75523: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 8 bytes in 1 blocks are definitely lost in loss record 17 of 372 > ==8620== at 0x483F310: operator new(unsigned int) (vg_replace_malloc.c:336) > ==8620== by 0x36D15: main (sample_pki.cpp:27) > ==8620== > ==8620== 8 bytes in 1 blocks are definitely lost in loss record 18 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) > ==8620== by 0x4C76E07: ECDSA_SIG_new (ec_asn1.c:1214) > ==8620== by 0x537064B: pkcs11_try_pkey_ec_sign (p11_pkey.c:546) > ==8620== by 0x537064B: pkcs11_pkey_ec_sign (p11_pkey.c:634) > ==8620== by 0x4CB70CD: EVP_DigestSignFinal (m_sigver.c:148) > ==8620== by 0x4BA9FF3: tls_construct_cert_verify (statem_lib.c:307) > ==8620== by 0x4BA42C7: write_state_machine (statem.c:843) > ==8620== by 0x4BA42C7: state_machine (statem.c:443) > ==8620== by 0x4B8BABB: ssl3_read_bytes (rec_layer_s3.c:1278) > ==8620== by 0x4B900E1: ssl3_read_internal (s3_lib.c:4473) > ==8620== by 0x4B9013F: ssl3_read (s3_lib.c:4497) > ==8620== by 0x4B96A6D: ssl_read_internal (ssl_lib.c:1761) > ==8620== by 0x4B96B09: SSL_read (ssl_lib.c:1775) > ==8620== > ==8620== 16 bytes in 2 blocks are possibly lost in loss record 55 of 372 > ==8620== at 0x483EA30: malloc (vg_replace_malloc.c:306) > ==8620== by 0x48419FF: realloc (vg_replace_malloc.c:834) > ==8620== by 0x4E73B5D: amqpvalue_set_map_value (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 40 bytes in 10 blocks are possibly lost in loss record 182 of 372 > ==8620== at 0x483EA30: malloc (vg_replace_malloc.c:306) > ==8620== by 0x48419FF: realloc (vg_replace_malloc.c:834) > ==8620== by 0x4E738BB: amqpvalue_set_list_item (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 48 bytes in 1 blocks are possibly lost in loss record 210 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E7582D: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 48 bytes in 2 blocks are possibly lost in loss record 211 of 372 > ==8620== at 0x48419B0: realloc (vg_replace_malloc.c:834) > ==8620== by 0x4E73B5D: amqpvalue_set_map_value (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 56 bytes in 1 blocks are possibly lost in loss record 215 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E74FF9: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 64 bytes in 2 blocks are possibly lost in loss record 228 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E74477: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 64 bytes in 1 blocks are definitely lost in loss record 229 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4A8D411: __libc_alloc_buffer_allocate (alloc_buffer_allocate.c:26) > ==8620== by 0x4AE2B51: alloc_buffer_allocate (alloc_buffer.h:143) > ==8620== by 0x4AE2B51: __resolv_conf_allocate (resolv_conf.c:411) > ==8620== by 0x4AE147D: __resolv_conf_load (res_init.c:592) > ==8620== by 0x4AE292B: __resolv_conf_get_current (resolv_conf.c:163) > ==8620== by 0x4AE19D7: __res_vinit (res_init.c:614) > ==8620== by 0x4AE24B1: maybe_init (resolv_context.c:122) > ==8620== by 0x4AE24B1: context_get.part.1 (resolv_context.c:184) > ==8620== by 0x4ABBAE7: gaih_inet.constprop.6 (getaddrinfo.c:751) > ==8620== by 0x4ABC90B: getaddrinfo (getaddrinfo.c:2265) > ==8620== by 0x4B4AA17: Curl_getaddrinfo_ex (in /usr/lib/libcurl.so.4.5.0) > ==8620== > ==8620== 80 bytes in 3 blocks are possibly lost in loss record 246 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E7547D: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 92 bytes in 3 blocks are possibly lost in loss record 256 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E74E3D: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 128 bytes in 4 blocks are possibly lost in loss record 278 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E74ABF: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 128 bytes in 4 blocks are possibly lost in loss record 279 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E74DF1: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 128 bytes in 4 blocks are possibly lost in loss record 280 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E70EC5: amqpvalue_create_map (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 152 bytes in 1 blocks are possibly lost in loss record 291 of 372 > ==8620== at 0x4841748: calloc (vg_replace_malloc.c:760) > ==8620== by 0x400C871: allocate_dtv (dl-tls.c:286) > ==8620== by 0x400CEB3: _dl_allocate_tls (dl-tls.c:530) > ==8620== by 0x4A18585: allocate_stack (allocatestack.c:621) > ==8620== by 0x4A18585: pthread_create@@GLIBC_2.4 (pthread_create.c:669) > ==8620== by 0x4B4B507: Curl_thread_create (in /usr/lib/libcurl.so.4.5.0) > ==8620== > ==8620== 192 bytes in 6 blocks are possibly lost in loss record 303 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E75329: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 242 bytes in 8 blocks are possibly lost in loss record 310 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E70C33: amqpvalue_create_symbol (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 256 bytes in 8 blocks are possibly lost in loss record 322 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E70C1B: amqpvalue_create_symbol (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 320 bytes in 10 blocks are possibly lost in loss record 326 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E7611B: amqpvalue_create_composite_with_ulong_descriptor (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 320 bytes in 10 blocks are possibly lost in loss record 327 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E6FD95: amqpvalue_create_ulong (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 320 bytes in 10 blocks are possibly lost in loss record 328 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E70DBD: amqpvalue_create_list (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 360 bytes in 6 blocks are possibly lost in loss record 331 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E7467F: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 576 bytes in 18 blocks are possibly lost in loss record 337 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E70A6B: amqpvalue_create_string (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 1,024 bytes in 4 blocks are indirectly lost in loss record 351 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) > ==8620== by 0x4C498EB: bn_expand_internal (bn_lib.c:268) > ==8620== by 0x4C498EB: bn_expand2 (bn_lib.c:292) > ==8620== by 0x4C499B3: BN_copy (bn_lib.c:329) > ==8620== by 0x4C4A5D7: BN_MONT_CTX_set (bn_mont.c:275) > ==8620== by 0x4C4A7F7: BN_MONT_CTX_set_locked (bn_mont.c:450) > ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) > ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) > ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) > ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) > ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) > ==8620== by 0x4BA824D: tls_process_key_exchange (statem_clnt.c:2401) > ==8620== > ==8620== 1,039 bytes in 18 blocks are possibly lost in loss record 352 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E70A83: amqpvalue_create_string (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 1,088 bytes in 34 blocks are possibly lost in loss record 353 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4E754A9: ??? (in /usr/lib/libuamqp.so.1.2.12) > ==8620== > ==8620== 2,064 bytes in 4 blocks are indirectly lost in loss record 359 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) > ==8620== by 0x4C498EB: bn_expand_internal (bn_lib.c:268) > ==8620== by 0x4C498EB: bn_expand2 (bn_lib.c:292) > ==8620== by 0x4C49A4B: BN_set_bit (bn_lib.c:659) > ==8620== by 0x4C4A6FB: BN_MONT_CTX_set (bn_mont.c:395) > ==8620== by 0x4C4A7F7: BN_MONT_CTX_set_locked (bn_mont.c:450) > ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) > ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) > ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) > ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) > ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) > ==8620== by 0x4BA824D: tls_process_key_exchange (statem_clnt.c:2401) > ==8620== > ==8620== 2,304 bytes in 7 blocks are indirectly lost in loss record 362 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) > ==8620== by 0x4C498EB: bn_expand_internal (bn_lib.c:268) > ==8620== by 0x4C498EB: bn_expand2 (bn_lib.c:292) > ==8620== by 0x4C499B3: BN_copy (bn_lib.c:329) > ==8620== by 0x4C4A5D7: BN_MONT_CTX_set (bn_mont.c:275) > ==8620== by 0x4C4A7F7: BN_MONT_CTX_set_locked (bn_mont.c:450) > ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) > ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) > ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) > ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) > ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) > ==8620== by 0x4C27D59: ASN1_item_verify (a_verify.c:167) > ==8620== > ==8620== 3,392 (304 direct, 3,088 indirect) bytes in 4 blocks are definitely lost in loss record 365 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4C4A531: BN_MONT_CTX_new (bn_mont.c:232) > ==8620== by 0x4C4A7E9: BN_MONT_CTX_set_locked (bn_mont.c:447) > ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) > ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) > ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) > ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) > ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) > ==8620== by 0x4BA824D: tls_process_key_exchange (statem_clnt.c:2401) > ==8620== by 0x4BA8725: ossl_statem_client_process_message (statem_clnt.c:1048) > ==8620== by 0x4BA4653: read_state_machine (statem.c:636) > ==8620== by 0x4BA4653: state_machine (statem.c:434) > ==8620== by 0x4B980B1: SSL_do_handshake (ssl_lib.c:3607) > ==8620== > ==8620== 4,636 bytes in 7 blocks are indirectly lost in loss record 367 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4CBF14B: CRYPTO_zalloc (mem.c:230) > ==8620== by 0x4C498EB: bn_expand_internal (bn_lib.c:268) > ==8620== by 0x4C498EB: bn_expand2 (bn_lib.c:292) > ==8620== by 0x4C49A4B: BN_set_bit (bn_lib.c:659) > ==8620== by 0x4C4A6FB: BN_MONT_CTX_set (bn_mont.c:395) > ==8620== by 0x4C4A7F7: BN_MONT_CTX_set_locked (bn_mont.c:450) > ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) > ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) > ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) > ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) > ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) > ==8620== by 0x4C27D59: ASN1_item_verify (a_verify.c:167) > ==8620== > ==8620== 7,472 (532 direct, 6,940 indirect) bytes in 7 blocks are definitely lost in loss record 369 of 372 > ==8620== at 0x483EB28: malloc (vg_replace_malloc.c:307) > ==8620== by 0x4C4A531: BN_MONT_CTX_new (bn_mont.c:232) > ==8620== by 0x4C4A7E9: BN_MONT_CTX_set_locked (bn_mont.c:447) > ==8620== by 0x4CDC003: rsa_ossl_public_decrypt (rsa_ossl.c:559) > ==8620== by 0x4CDE4AF: int_rsa_verify (rsa_sign.c:143) > ==8620== by 0x4CDE703: RSA_verify (rsa_sign.c:247) > ==8620== by 0x4CDD8F5: pkey_rsa_verify (rsa_pmeth.c:251) > ==8620== by 0x4CB722D: EVP_DigestVerifyFinal (m_sigver.c:207) > ==8620== by 0x4C27D59: ASN1_item_verify (a_verify.c:167) > ==8620== by 0x4CFFF4B: X509_verify (x_all.c:26) > ==8620== by 0x4CFCE63: internal_verify (x509_vfy.c:1750) > ==8620== by 0x4CFDF03: verify_chain (x509_vfy.c:232) > ==8620== > ==8620== LEAK SUMMARY: > ==8620== definitely lost: 916 bytes in 14 blocks > ==8620== indirectly lost: 10,028 bytes in 22 blocks > ==8620== possibly lost: 5,701 bytes in 166 blocks > ==8620== still reachable: 105,132 bytes in 895 blocks > ==8620== suppressed: 0 bytes in 0 blocks > ==8620== Reachable blocks (those to which a pointer was found) are not shown. > ==8620== To see them, rerun with: --leak-check=full --show-leak-kinds=all > ==8620== > ==8620== For lists of detected and suppressed errors, rerun with: -s > ==8620== ERROR SUMMARY: 28 errors from 28 contexts (suppressed: 0 from 0) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Wed Sep 30 07:32:16 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 30 Sep 2020 09:32:16 +0200 Subject: VOTE: Accept the OTC voting policy as defined: In-Reply-To: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> References: <8789f6d768004e86a62e1cdc2f9ecbad@ncp-e.com> Message-ID: <20200930073216.GA2014447@roeckx.be> On Mon, Sep 28, 2020 at 12:02:07PM +0000, Dr. Matthias St. Pierre wrote: > topic: Accept the OTC voting policy as defined: > > The proposer of a vote is ultimately responsible for updating the votes.txt > file in the repository. Outside of a face to face meeting, voters MUST reply > to the vote email indicating their preference and optionally their reasoning. > Voters MAY update the votes.txt file in addition. > > The proposed vote text SHOULD be raised for discussion before calling the vote. > > Public votes MUST be called on the project list, not the OTC list and the > subject MUST begin with "VOTE:". Private votes MUST be called on the > OTC list with "PRIVATE VOTE:" beginning subject. +1 Kurt From tmraz at redhat.com Wed Sep 30 07:33:43 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 30 Sep 2020 09:33:43 +0200 Subject: Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? In-Reply-To: <9EE453BD-4197-4367-A8A2-DD7EB45FC9AB@fireeye.com> References: <9EE453BD-4197-4367-A8A2-DD7EB45FC9AB@fireeye.com> Message-ID: <0b821bd7a34485430397976e94dc9a5b7391d47c.camel@redhat.com> Hello, unfortunately no, 1.1.1g is neither API nor ABI compatible with 1.0.2f. You cannot directly replace 1.0.2f with 1.1.1g. The applications have to support 1.1.1 release and be recompiled against it to work with it. Regards, Tomas Mraz On Tue, 2020-09-22 at 14:08 +0000, Kapil Awate wrote: > Hi, > > Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? Can anyone help > me with this ? Is there any impact on existing functionality after > upgrading it to 1.1.1g ? > > Thanks! > > This email and any attachments thereto may contain private, > confidential, and/or privileged material for the sole use of the > intended recipient. Any review, copying, or distribution of this > email (or any attachments thereto) by others is strictly prohibited. > If you are not the intended recipient, please contact the sender > immediately and permanently delete the original and any copies of > this email and any attachments thereto. -- 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.] From Matthias.St.Pierre at ncp-e.com Wed Sep 30 13:57:34 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 30 Sep 2020 13:57:34 +0000 Subject: VOTE: OTC meeting will be called for next Tuesday Message-ID: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> The following vote has been proposed and voted on at the vF2F today: topic: OTC meeting will be called for next Tuesday It has been closed immediately by Tim, the verdict is accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) (Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 Planning meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate invitation to the OTC list.) Matthias ---------------- topic: OTC meeting will be called for next Tuesday (2020-10-06) Proposed by Matthias St. Pierre Public: yes opened: 2020-09-30 closed: 2020-09-30 accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) Matt [+1] Mark [ ] Pauli [+1] Viktor [ ] Tim [+1] Richard [+1] Shane [+1] Tomas [ ] Kurt [ ] Matthias [+1] Nicola [+1] From mark at openssl.org Wed Sep 30 14:01:59 2020 From: mark at openssl.org (Mark J Cox) Date: Wed, 30 Sep 2020 15:01:59 +0100 Subject: VOTE: OTC meeting will be called for next Tuesday In-Reply-To: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> References: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> Message-ID: +1 On Wed, Sep 30, 2020 at 2:57 PM Dr. Matthias St. Pierre wrote: > > The following vote has been proposed and voted on at the vF2F today: > > topic: OTC meeting will be called for next Tuesday > > It has been closed immediately by Tim, the verdict is > > accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) > > (Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 Planning > meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate > invitation to the OTC list.) > > Matthias > > ---------------- > topic: OTC meeting will be called for next Tuesday (2020-10-06) > Proposed by Matthias St. Pierre > Public: yes > opened: 2020-09-30 > closed: 2020-09-30 > accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim [+1] > Richard [+1] > Shane [+1] > Tomas [ ] > Kurt [ ] > Matthias [+1] > Nicola [+1] > > From tmraz at redhat.com Wed Sep 30 14:23:37 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 30 Sep 2020 16:23:37 +0200 Subject: VOTE: OTC meeting will be called for next Tuesday In-Reply-To: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> References: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> Message-ID: +1 On Wed, 2020-09-30 at 13:57 +0000, Dr. Matthias St. Pierre wrote: > The following vote has been proposed and voted on at the vF2F today: > > topic: OTC meeting will be called for next Tuesday > > It has been closed immediately by Tim, the verdict is > > accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) > > (Note: the OTC meeting will be held in place of the weekly OpenSSL > 3.0 Planning > meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a > separate > invitation to the OTC list.) > > Matthias > > ---------------- > topic: OTC meeting will be called for next Tuesday (2020-10-06) > Proposed by Matthias St. Pierre > Public: yes > opened: 2020-09-30 > closed: 2020-09-30 > accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim [+1] > Richard [+1] > Shane [+1] > Tomas [ ] > Kurt [ ] > Matthias [+1] > Nicola [+1] > > -- 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.] From kris at amongbytes.com Wed Sep 30 15:11:06 2020 From: kris at amongbytes.com (Kris Kwiatkowski) Date: Wed, 30 Sep 2020 16:11:06 +0100 Subject: Integration of new algorithms In-Reply-To: References: Message-ID: Hello, In regards to OBJ_new_nid - yes, that's more or less what I already do. I actually use OBJ_sn2nid() which, indeed calls a OBJ_new_nid(). But the problem that I've is different. In keygen (callback set by EVP_PKEY_meth_set_keygen), there is no way to access NID. It seems to be stored in the EVP_PKEY_CTX->pmeth->pkey_id, but there is no way to read it (or at least I couldn't find any). But, anyway - I've some sub-optimal solution, which uses EVP_PKEY_meth_set_ctrl() to set scheme specific callback. Not perfectly clean, but works perfectly well. In regards to 3.0 - I've started to work on provider for PQ schemes some time ago. Not finished yet, but indeed, it looks easier/better. Nevertheless ENGINE for 1.1.1 is actually something that is needed now for practical reasons (like integration with existing software). Kind regards, Kris On 9/30/20 8:05 AM, Dr Paul Dale wrote: > Instead of using an engine, you should write a provider (assuming you?re > using the soon to be released OpenSSL 3.0). ?It doesn?t need a NID. > > If you are using OpenSSL 1.1.1, try the?OBJ_new_nid() function. > > > Pauli > --? > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations? > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 26 Aug 2020, at 6:48 pm, Kris Kwiatkowski > > wrote: >> >> >> Hey, >> >> I'm working on development of OpenSSL ENGINE that integrates >> post-quantum algorithms (new NIDs). During integration I >> need to modify OpenSSL code to add custom function, but would >> prefer not to need add anything to OpenSSL code (so engine >> can be dynmicaly loaded by any modern OpenSSL). >> >> So, In three cases, namely when the code is in callbacks for keygen, >> encryption and ctrl (called by EVP_PKEY_CTX_ctrl, EVP_PKEY_encrypt >> and EVP_PKEY_keygen) I need to get NID of the scheme. The problem >> is that, those functions are called with EVP_PKEY_CTX object >> provided as an argument. The NID is stored in the >> EVP_PKEY_CTX->pmeth->pkey_id. I think (AFAIK) there is no API >> which would return that value. >> >> I've added a simple function that returns pkey_id from the ctx, but >> that means that I need to change OpenSSL code. Is there any way >> to get NID without changing OpenSSL? >> >> Kind regards, >> Kris >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Wed Sep 30 16:07:20 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 30 Sep 2020 18:07:20 +0200 Subject: VOTE: OTC meeting will be called for next Tuesday In-Reply-To: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> References: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> Message-ID: <20200930160720.GA2030691@roeckx.be> On Wed, Sep 30, 2020 at 01:57:34PM +0000, Dr. Matthias St. Pierre wrote: > topic: OTC meeting will be called for next Tuesday +1, but wondering why this needs a vote. Kurt From levitte at openssl.org Wed Sep 30 16:14:43 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 30 Sep 2020 18:14:43 +0200 Subject: VOTE: OTC meeting will be called for next Tuesday In-Reply-To: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> References: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> Message-ID: <87r1qj2qdo.wl-levitte@openssl.org> +1 On Wed, 30 Sep 2020 15:57:34 +0200, Dr. Matthias St. Pierre wrote: > > The following vote has been proposed and voted on at the vF2F today: > > topic: OTC meeting will be called for next Tuesday > > It has been closed immediately by Tim, the verdict is > > accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) > > (Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 Planning > meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate > invitation to the OTC list.) > > Matthias > > ---------------- > topic: OTC meeting will be called for next Tuesday (2020-10-06) > Proposed by Matthias St. Pierre > Public: yes > opened: 2020-09-30 > closed: 2020-09-30 > accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim [+1] > Richard [+1] > Shane [+1] > Tomas [ ] > Kurt [ ] > Matthias [+1] > Nicola [+1] > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Wed Sep 30 17:23:58 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 30 Sep 2020 17:23:58 +0000 Subject: VOTE: OTC meeting will be called for next Tuesday In-Reply-To: <20200930160720.GA2030691@roeckx.be> References: <24048b224bc64c0fa919d8c131bdb444@ncp-e.com> <20200930160720.GA2030691@roeckx.be> Message-ID: <0849ad0a16f04be7988b01d5b4543093@ncp-e.com> > +1, but wondering why this needs a vote. Because we decided to follow our own bylaws more closely. In particular the following two items: > All OTC decisions are taken on the basis of a vote https://www.openssl.org/policies/omc-bylaws.html#OTC > ### OTC Transparency > The majority of the activity of the OTC will take place in public. https://www.openssl.org/policies/omc-bylaws.html#transparency Matthias > -----Original Message----- > From: Kurt Roeckx > Sent: Wednesday, September 30, 2020 6:07 PM > To: Dr. Matthias St. Pierre > Cc: openssl-project at openssl.org > Subject: Re: VOTE: OTC meeting will be called for next Tuesday > > On Wed, Sep 30, 2020 at 01:57:34PM +0000, Dr. Matthias St. Pierre wrote: > > topic: OTC meeting will be called for next Tuesday > > > > Kurt >