From tjh at openssl.org Tue Mar 5 09:11:06 2019 From: tjh at openssl.org (Tim Hudson) Date: Tue, 5 Mar 2019 19:11:06 +1000 Subject: function and typedef naming thoughts Message-ID: Looking at PR#8287 I think we need to get some naming schemes written down and documented and followed consistently. The naming used in this PR seems to be somewhat inconsistent. For me, I think the naming convention most often used is return_type SOMETHING_whatever(SOMETHING *,...) as a general rule for how we are naming things. There are lots of exceptions to this in the code base - but this is also pretty much consistent. And we use typedef names in all capitals for what we expect users to work with. We avoid the use of pure lowercase in naming functions or typedefs that are in the public API that we expect users to work with - all lowercase means this is "internal" only usage. And we reserve OSSL and OPENSSL as prefixes that we feel are safe to place all new names under. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Mar 5 10:41:09 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 05 Mar 2019 11:41:09 +0100 Subject: function and typedef naming thoughts In-Reply-To: References: Message-ID: <8736o161tm.wl-levitte@openssl.org> On Tue, 05 Mar 2019 10:11:06 +0100, Tim Hudson wrote: > Looking at PR#8287 I think we need to get some naming schemes written down and documented and > followed consistently. The naming used in this PR seems to be somewhat inconsistent. > > For me, I think the naming convention most often used is? > > return_type SOMETHING_whatever(SOMETHING *,...) Not always. > as a general rule for how we are naming things. There are lots of exceptions to this in the code > base - but this is also pretty much consistent. > > And we use typedef names in all capitals for what we expect users to work with. > We avoid the use of pure lowercase in naming functions or typedefs that are in the public API that > we expect users to work with - all lowercase means this is "internal" only usage. > > And we reserve OSSL and OPENSSL as prefixes that we feel are safe to place all new names under. I think we need to think about this not just in terms of copying the type of the first parameter into the function name, but also in terms of meaning. Even though C isn't an object oriented language, it's perfectly possible to implement a limited class concept. And we do this, all over the place. That's where function signatures such as what you give an example of comes in, at least when looking at coding patterns we've used for quite a while. So, when I see a function signature like this: return_type OSSL_SOMETHING_whatever(OSSL_SOMETHING *, ...) I view that as the "method" 'whatever' for the "class" OSSL_SOMETHING, and that first parameter is that method's |this| (which must be passed explicitely since this is C). However, this doesn't mean to me that every function that just happens to have OSSL_SOMETHING* as first parameters is necessarily a "method" for that "class", it might as well be a global function that just happens to use that "class" (and will typically call that "class"' "methods" to get the job done). I do understand the need for namespaces, I'm not trying to argue against that, but I see OSSL_ and OPENSSL_ as our namespaces for new functionality, and things like OSSL_SOMETHING_ as the prefix used to indicate the SOMETHING "class" in the OSSL namespace. While we're on the subject of namespaces, we are currently introducing a number of functions that are meant to be core functions (not class methods). Looking at include/openssl/crypto.h, it seems like the CRYPTO_ prefix was mainly used for core functionality (CRYPTO_malloc() is an example). However, I can't see myself adding to the CRYPTO_ set for core functionality, and therefore used the OSSL_ prefix instead. As for PR#8287, the pattern I followed is consistent with what I just wrote: - there is a "class", OSSL_PROVIDER. For the public, it's entirely opaque, i.e. its methods are internal only, all described in doc/internal/man3/ossl_provider_new.pod (and all with the prefix ossl_provider_, i.e. the provider "class" in the ossl namespace). In those methods, the first parameter is normally (not always) OSSL_PROVIDER*, and is the natural |this| for those methods. - there are some core functions, all described in doc/man3/OSSL_PROVIDER.pod. They also take an OSSL_PROVIDER* parameter, but it's not their |this|. They just pass that pointer along to the internal ossl_provider_ functions. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Wed Mar 6 10:33:34 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 6 Mar 2019 10:33:34 +0000 Subject: Monthly Status Report (February) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Worked with Richard to publish the Design and Strategy documents and wrote a blog post about them - Created a PR to rewrite SSL_dup - Made OPENSSL_malloc_init() a no-op - Significant review time looking at new PRs related to 3.0/FIPS - Attended regular FIPS sponsor call meetings - Fixed the issue relating to post-handshake message exchange signally using SSL_CB_HANDSHAKE_START in the info callback - Fixed an issue to allow more than 32 KeyUpdates per connection - Significant review time on the Kernel TLS receive side PR - Significant review time on the CMP PR - Significant review time on the "const" PR - Fixed an issue which allowed interleaving of handshake and other record types in TLSv1.3 - Co-ordinated updates to the release strategy to introduce the new stability policy - Investigated and fixed intermittent failures in ecdsatest - Fixed rel=canonical issue on the website - Fixed no-stdio - Fixed an EVP_KDF_CTX leak on error found by Coverity - Performed the release of 1.1.1b and 1.0.2r - Fixed the aes128_cbc_hmac_sha1 cipher in the dasync engine - Fixed issue in bn_cmp_words - Published details about the extended support option for 1.0.2 - Fixed no-ec, no-sm2 and no-sm3 Matt From openssl at openssl.org Wed Mar 6 15:28:20 2019 From: openssl at openssl.org (OpenSSL) Date: Wed, 6 Mar 2019 15:28:20 +0000 Subject: OpenSSL Security Advisory Message-ID: <20190306152820.GA15119@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [6 March 2019] ======================================== ChaCha20-Poly1305 with long nonces (CVE-2019-1543) ================================================== Severity: Low ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for every encryption operation. RFC 7539 specifies that the nonce value (IV) should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and front pads the nonce with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored. It is a requirement of using this cipher that nonce values are unique. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. If an application changes the default nonce length to be longer than 12 bytes and then makes a change to the leading bytes of the nonce expecting the new value to be a new unique nonce then such an application could inadvertently encrypt messages with a reused nonce. Additionally the ignored bytes in a long nonce are not covered by the integrity guarantee of this cipher. Any application that relies on the integrity of these ignored leading bytes of a long nonce may be further affected. Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because no such use sets such a long nonce value. However user applications that use this cipher directly and set a non-default nonce length to be longer than 12 bytes may be vulnerable. OpenSSL versions 1.1.1 and 1.1.0 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. The 1.1.1 mitigation for this issue can be found in commit f426625b6a. The 1.1.0 mitigation for this issue can be found in commit ee22257b14. This issue does not impact OpenSSL 1.0.2. This issue was discovered by Joran Dirk Greef of Ronomon. The fix was developed by Matt Caswell from the OpenSSL development team. It was reported to OpenSSL on 26th February 2019. Note ==== OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 will end on 11th September 2019. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20190306.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----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlx/5b4ACgkQ2cTSbQ5g RJEXSwgAgHQkb/CyWdubYozRAeUDBT9o6gt/kgsBwPYBxAV75lRo4qwBxzfkeQ6P 6EUFSzEPhabQOhpnTY4QaqphzG2FAl4BbtDalYN+zPOZxppmH7O8Kje+j+onInDI O4jbjXLgAlgmf5jw5IyhfxQKcaFbdLtcFGzh1t4rMEhT+ehx8ePnGnklPTjfh4ea bN+BlM1Fm6Au3i/IJB2I6e8ayxFnTx9mAegPvV/RRYma43Ee/Hpvb6eBaTfTZ9yp lOp0jG4iViB4r3EP3H/l5oVC9fWCAI0Am+vcLq9PsWl632fc39hDREhPrRMfnOds 40ayI4NwoUu4Z89Qdae1iWEUkgjRgA== =Aub4 -----END PGP SIGNATURE----- From matt at openssl.org Fri Mar 22 15:45:38 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 22 Mar 2019 15:45:38 +0000 Subject: Thoughts on OSSL_ALGORITHM Message-ID: <4d730ce9-928b-4e42-8681-0b16d632ad73@openssl.org> Currently we have the OSSL_ALGORITHM type defined as follows: struct ossl_algorithm_st { const char *algorithm_name; /* key */ const char *property_definition; /* key */ const OSSL_DISPATCH *implementation; }; I'm wondering whether we should add an additional member to this structure: a provider specific handle. i.e. struct ossl_algorithm_st { const char *algorithm_name; /* key */ const char *property_definition; /* key */ const OSSL_DISPATCH *implementation; void *handle; }; The reason to do this is because providers are likely to want to share the same implementation across multiple algorithms, e.g. the init/update/final functions for aes-128-cbc are likely to look identical to aes-256-cbc with the only difference being the key length. A provider could use the handle to point to some provider side structure which describes the details of the algorithm (key length, IV size etc). For example in the default provider we might have: typedef struct default_alg_handle_st { int nid; size_t keylen; size_t ivlen; } DEFAULT_ALG_HANDLE; DEFAULT_ALG_HANDLE aes256cbchandle = { NID_aes_256_cbc, 32, 16 }; DEFAULT_ALG_HANDLE aes128cbchandle = { NID_aes_128_cbc, 16, 16 }; static const OSSL_ALGORITHM deflt_ciphers[] = { { "AES-256-CBC", "default=yes", aes_cbc_functions, &aes256cbchandle }, { "AES-128-CBC", "default=yes", aes_cbc_functions, &aes128cbchandle }, { NULL, NULL, NULL } }; Then when the "init" function is called (or possibly at newctx), the core passes as an argument the provider specific handle associated with that algorithm. An alternative is for the provider to pass the algorithm name instead, but this potentially requires lots of strcmps to identify which algorithm we're dealing with which doesn't sound particularly attractive. A second alternative is for each algorithm to always have unique functions (which perhaps call some common functions underneath). This sounds like lots of unnecessary redundancy. Thoughts? Matt From matt at openssl.org Fri Mar 22 15:58:16 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 22 Mar 2019 15:58:16 +0000 Subject: Thoughts on OSSL_ALGORITHM In-Reply-To: <4d730ce9-928b-4e42-8681-0b16d632ad73@openssl.org> References: <4d730ce9-928b-4e42-8681-0b16d632ad73@openssl.org> Message-ID: <21d77dfd-239c-fbe3-3c80-074cd9872ec8@openssl.org> On 22/03/2019 15:45, Matt Caswell wrote: > An alternative is for the provider to pass the algorithm name instead, but this > potentially requires lots of strcmps to identify which algorithm we're dealing > with which doesn't sound particularly attractive. I meant "An alternative is for the core to pass the algorithm name instead..." Matt From paul.dale at oracle.com Fri Mar 22 23:11:23 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 23 Mar 2019 09:11:23 +1000 Subject: Thoughts on OSSL_ALGORITHM In-Reply-To: <4d730ce9-928b-4e42-8681-0b16d632ad73@openssl.org> References: <4d730ce9-928b-4e42-8681-0b16d632ad73@openssl.org> Message-ID: I?ve no issue having a provider data field there. It will be useful for more than just this (S390 AES e.g. holds data differently to other implementations). I also don?t think forcing separate functions is a big problem ? most providers will only implement one or two algorithm families which will help control the redundancy. I don?t think we should be doing a string lookup every time one of these is called. Of the three, the provider data feels clean and unique functions fast. I?d like to avoid mandating another level of indirection (it?s slow), which is a risk with provider data. My thought: add the provider data field. Use that when it can be done directly, use unique functions otherwise. The example with key and iv lengths would be a direct use. Code that dives through a function pointer or a switch statement would be an example of not. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 23 Mar 2019, at 1:45 am, Matt Caswell wrote: > > Currently we have the OSSL_ALGORITHM type defined as follows: > > struct ossl_algorithm_st { > const char *algorithm_name; /* key */ > const char *property_definition; /* key */ > const OSSL_DISPATCH *implementation; > }; > > I'm wondering whether we should add an additional member to this structure: a > provider specific handle. i.e. > > struct ossl_algorithm_st { > const char *algorithm_name; /* key */ > const char *property_definition; /* key */ > const OSSL_DISPATCH *implementation; > void *handle; > }; > > The reason to do this is because providers are likely to want to share the same > implementation across multiple algorithms, e.g. the init/update/final functions > for aes-128-cbc are likely to look identical to aes-256-cbc with the only > difference being the key length. A provider could use the handle to point to > some provider side structure which describes the details of the algorithm (key > length, IV size etc). For example in the default provider we might have: > > typedef struct default_alg_handle_st { > int nid; > size_t keylen; > size_t ivlen; > } DEFAULT_ALG_HANDLE; > > DEFAULT_ALG_HANDLE aes256cbchandle = { NID_aes_256_cbc, 32, 16 }; > DEFAULT_ALG_HANDLE aes128cbchandle = { NID_aes_128_cbc, 16, 16 }; > > static const OSSL_ALGORITHM deflt_ciphers[] = { > { "AES-256-CBC", "default=yes", aes_cbc_functions, &aes256cbchandle }, > { "AES-128-CBC", "default=yes", aes_cbc_functions, &aes128cbchandle }, > { NULL, NULL, NULL } > }; > > Then when the "init" function is called (or possibly at newctx), the core passes > as an argument the provider specific handle associated with that algorithm. > > An alternative is for the provider to pass the algorithm name instead, but this > potentially requires lots of strcmps to identify which algorithm we're dealing > with which doesn't sound particularly attractive. > > A second alternative is for each algorithm to always have unique functions > (which perhaps call some common functions underneath). This sounds like lots of > unnecessary redundancy. > > Thoughts? > > Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Fri Mar 22 23:28:02 2019 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 23 Mar 2019 09:28:02 +1000 Subject: Thoughts on OSSL_ALGORITHM In-Reply-To: References: <4d730ce9-928b-4e42-8681-0b16d632ad73@openssl.org> Message-ID: "handle" is the wrong name for this - if you want to have private const data then do that rather than something which might be abused for instance specific information. It could just be an int even or a short. It doesn't have to be a pointer. That would reduce the likely of it being used to hold non-const data. Tim. On Sat, 23 Mar. 2019, 9:11 am Dr Paul Dale I?ve no issue having a provider data field there. It will be useful for > more than just this (S390 AES e.g. holds data differently to other > implementations). > > I also don?t think forcing separate functions is a big problem ? most > providers will only implement one or two algorithm families which will help > control the redundancy. > > I don?t think we should be doing a string lookup every time one of these > is called. > > > Of the three, the provider data feels clean and unique functions fast. > > I?d like to avoid mandating another level of indirection (it?s slow), > which is a risk with provider data. > > > My thought: add the provider data field. Use that when it can be done > directly, use unique functions otherwise. > The example with key and iv lengths would be a direct use. Code that > dives through a function pointer or a switch statement would be an example > of not. > > > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > > > On 23 Mar 2019, at 1:45 am, Matt Caswell wrote: > > Currently we have the OSSL_ALGORITHM type defined as follows: > > struct ossl_algorithm_st { > const char *algorithm_name; /* key */ > const char *property_definition; /* key */ > const OSSL_DISPATCH *implementation; > }; > > I'm wondering whether we should add an additional member to this > structure: a > provider specific handle. i.e. > > struct ossl_algorithm_st { > const char *algorithm_name; /* key */ > const char *property_definition; /* key */ > const OSSL_DISPATCH *implementation; > void *handle; > }; > > The reason to do this is because providers are likely to want to share the > same > implementation across multiple algorithms, e.g. the init/update/final > functions > for aes-128-cbc are likely to look identical to aes-256-cbc with the only > difference being the key length. A provider could use the handle to point > to > some provider side structure which describes the details of the algorithm > (key > length, IV size etc). For example in the default provider we might have: > > typedef struct default_alg_handle_st { > int nid; > size_t keylen; > size_t ivlen; > } DEFAULT_ALG_HANDLE; > > DEFAULT_ALG_HANDLE aes256cbchandle = { NID_aes_256_cbc, 32, 16 }; > DEFAULT_ALG_HANDLE aes128cbchandle = { NID_aes_128_cbc, 16, 16 }; > > static const OSSL_ALGORITHM deflt_ciphers[] = { > { "AES-256-CBC", "default=yes", aes_cbc_functions, &aes256cbchandle }, > { "AES-128-CBC", "default=yes", aes_cbc_functions, &aes128cbchandle }, > { NULL, NULL, NULL } > }; > > Then when the "init" function is called (or possibly at newctx), the core > passes > as an argument the provider specific handle associated with that algorithm. > > An alternative is for the provider to pass the algorithm name instead, but > this > potentially requires lots of strcmps to identify which algorithm we're > dealing > with which doesn't sound particularly attractive. > > A second alternative is for each algorithm to always have unique functions > (which perhaps call some common functions underneath). This sounds like > lots of > unnecessary redundancy. > > Thoughts? > > Matt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduk at mit.edu Sat Mar 23 15:08:17 2019 From: kaduk at mit.edu (Benjamin Kaduk) Date: Sat, 23 Mar 2019 10:08:17 -0500 Subject: Thoughts on OSSL_ALGORITHM In-Reply-To: References: <4d730ce9-928b-4e42-8681-0b16d632ad73@openssl.org> Message-ID: <20190323150816.GB88959@kduck.mit.edu> I also like the provider data approach. -Ben On Sat, Mar 23, 2019 at 09:11:23AM +1000, Dr Paul Dale wrote: > I?ve no issue having a provider data field there. It will be useful for more than just this (S390 AES e.g. holds data differently to other implementations). > > I also don?t think forcing separate functions is a big problem ? most providers will only implement one or two algorithm families which will help control the redundancy. > > I don?t think we should be doing a string lookup every time one of these is called. > > > Of the three, the provider data feels clean and unique functions fast. > > I?d like to avoid mandating another level of indirection (it?s slow), which is a risk with provider data. > > > My thought: add the provider data field. Use that when it can be done directly, use unique functions otherwise. > The example with key and iv lengths would be a direct use. Code that dives through a function pointer or a switch statement would be an example of not. > > > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 23 Mar 2019, at 1:45 am, Matt Caswell wrote: > > > > Currently we have the OSSL_ALGORITHM type defined as follows: > > > > struct ossl_algorithm_st { > > const char *algorithm_name; /* key */ > > const char *property_definition; /* key */ > > const OSSL_DISPATCH *implementation; > > }; > > > > I'm wondering whether we should add an additional member to this structure: a > > provider specific handle. i.e. > > > > struct ossl_algorithm_st { > > const char *algorithm_name; /* key */ > > const char *property_definition; /* key */ > > const OSSL_DISPATCH *implementation; > > void *handle; > > }; > > > > The reason to do this is because providers are likely to want to share the same > > implementation across multiple algorithms, e.g. the init/update/final functions > > for aes-128-cbc are likely to look identical to aes-256-cbc with the only > > difference being the key length. A provider could use the handle to point to > > some provider side structure which describes the details of the algorithm (key > > length, IV size etc). For example in the default provider we might have: > > > > typedef struct default_alg_handle_st { > > int nid; > > size_t keylen; > > size_t ivlen; > > } DEFAULT_ALG_HANDLE; > > > > DEFAULT_ALG_HANDLE aes256cbchandle = { NID_aes_256_cbc, 32, 16 }; > > DEFAULT_ALG_HANDLE aes128cbchandle = { NID_aes_128_cbc, 16, 16 }; > > > > static const OSSL_ALGORITHM deflt_ciphers[] = { > > { "AES-256-CBC", "default=yes", aes_cbc_functions, &aes256cbchandle }, > > { "AES-128-CBC", "default=yes", aes_cbc_functions, &aes128cbchandle }, > > { NULL, NULL, NULL } > > }; > > > > Then when the "init" function is called (or possibly at newctx), the core passes > > as an argument the provider specific handle associated with that algorithm. > > > > An alternative is for the provider to pass the algorithm name instead, but this > > potentially requires lots of strcmps to identify which algorithm we're dealing > > with which doesn't sound particularly attractive. > > > > A second alternative is for each algorithm to always have unique functions > > (which perhaps call some common functions underneath). This sounds like lots of > > unnecessary redundancy. > > > > Thoughts? > > > > Matt > From mattlindn at gmail.com Mon Mar 25 20:10:42 2019 From: mattlindn at gmail.com (Matthew Lindner) Date: Mon, 25 Mar 2019 13:10:42 -0700 Subject: Issues and pull requests are largely getting ignored Message-ID: Hello OpenSSL Team, The issues and pull requests on github are largely getting ignored, I know the team is busy on the new release but please spend some time on these as well. Thank you, Matthew Lindner From Matthias.St.Pierre at ncp-e.com Tue Mar 26 09:38:42 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 26 Mar 2019 09:38:42 +0000 Subject: AW: Issues and pull requests are largely getting ignored In-Reply-To: References: Message-ID: <2edf8f260963486e859c0c7eaa56de0d@Ex13.ncp.local> Hi Matthew, please feel free to post the single word "ping" to the pull requests for which you would like to regain attention. These reminders are welcome (if they are not abused too much :-) ). Regards, Matthias > -----Urspr?ngliche Nachricht----- > Von: openssl-project Im Auftrag von Matthew Lindner > Gesendet: Montag, 25. M?rz 2019 21:11 > An: openssl-project at openssl.org > Betreff: Issues and pull requests are largely getting ignored > > Hello OpenSSL Team, > > The issues and pull requests on github are largely getting ignored, I > know the team is busy on the new release but please spend some time on > these as well. > > Thank you, > Matthew Lindner From Matthias.St.Pierre at ncp-e.com Tue Mar 26 09:43:09 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 26 Mar 2019 09:43:09 +0000 Subject: AW: Issues and pull requests are largely getting ignored In-Reply-To: <2edf8f260963486e859c0c7eaa56de0d@Ex13.ncp.local> References: <2edf8f260963486e859c0c7eaa56de0d@Ex13.ncp.local> Message-ID: <29f6d36f328744398d6a92750336bf2e@Ex13.ncp.local> > > Hello OpenSSL Team, > > > > The issues and pull requests on github are largely getting ignored, I > > know the team is busy on the new release but please spend some time on > > these as well. And I forgot to say: you are right, thanks for the polite reminder :-) From matt at openssl.org Tue Mar 26 09:53:22 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 26 Mar 2019 09:53:22 +0000 Subject: Issues and pull requests are largely getting ignored In-Reply-To: References: Message-ID: <8412ad5d-ea0f-d55d-92d8-8efa93d83159@openssl.org> On 25/03/2019 20:10, Matthew Lindner wrote: > Hello OpenSSL Team, > > The issues and pull requests on github are largely getting ignored, I > know the team is busy on the new release but please spend some time on > these as well. I don't think this is a fair characterisation. I see all posts to issues and PRs in github for openssl and I see *lots* of activity. If I use the github "insights" page I see that over the last month 67 new issues were raised and 46 were closed. However those numbers are skewed by issues in very recent days (its shortly after a weekend and neither Richard or myself were around yesterday). Over the last week 23 new issues were raised and 8 were closed. Subtracting one from the other I see that for the period 1 week ago to 1 month ago 44 new issues were raised and 38 were closed. So the real problem there is a mismatch between the opening rate and the closing rate, i.e. it is NOT that we are ignoring these issues. I see it more as a resource issue - we are seeing issues raised at a greater rate than we have resources to handle. The best answer to that IMO is to somehow encourage a greater participation from the community in helping us to keep on top of these things. Not sure how best to achieve that though. I can't do the same analysis for PRs because github doesn't detect properly when we merge PRs (because we don't use the github facility for doing that). I would expect to see somewhat similar numbers though. Matt From paul.dale at oracle.com Tue Mar 26 10:12:08 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 26 Mar 2019 20:12:08 +1000 Subject: Issues and pull requests are largely getting ignored In-Reply-To: <8412ad5d-ea0f-d55d-92d8-8efa93d83159@openssl.org> References: <8412ad5d-ea0f-d55d-92d8-8efa93d83159@openssl.org> Message-ID: <71A83EF7-C111-451F-9BDD-DC8899D0AA47@oracle.com> I agree with Matt. He and Richard are doing a great job but cannot quite keep up. They are doing a fantastic job given the time available to them. I?ve been a bit slack the last two weeks and will be so for the next four or so but I?ll attempt to catch up. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 26 Mar 2019, at 7:53 pm, Matt Caswell wrote: > > > > On 25/03/2019 20:10, Matthew Lindner wrote: >> Hello OpenSSL Team, >> >> The issues and pull requests on github are largely getting ignored, I >> know the team is busy on the new release but please spend some time on >> these as well. > > I don't think this is a fair characterisation. I see all posts to issues and PRs > in github for openssl and I see *lots* of activity. > > If I use the github "insights" page I see that over the last month 67 new issues > were raised and 46 were closed. However those numbers are skewed by issues in > very recent days (its shortly after a weekend and neither Richard or myself were > around yesterday). Over the last week 23 new issues were raised and 8 were > closed. Subtracting one from the other I see that for the period 1 week ago to 1 > month ago 44 new issues were raised and 38 were closed. > > So the real problem there is a mismatch between the opening rate and the closing > rate, i.e. it is NOT that we are ignoring these issues. I see it more as a > resource issue - we are seeing issues raised at a greater rate than we have > resources to handle. The best answer to that IMO is to somehow encourage a > greater participation from the community in helping us to keep on top of these > things. Not sure how best to achieve that though. > > I can't do the same analysis for PRs because github doesn't detect properly when > we merge PRs (because we don't use the github facility for doing that). I would > expect to see somewhat similar numbers though. > > > Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Tue Mar 26 13:20:28 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 26 Mar 2019 14:20:28 +0100 Subject: Issues and pull requests are largely getting ignored In-Reply-To: <8412ad5d-ea0f-d55d-92d8-8efa93d83159@openssl.org> References: <8412ad5d-ea0f-d55d-92d8-8efa93d83159@openssl.org> Message-ID: <20190326132028.GA27949@roeckx.be> On Tue, Mar 26, 2019 at 09:53:22AM +0000, Matt Caswell wrote: > > So the real problem there is a mismatch between the opening rate and the closing > rate, i.e. it is NOT that we are ignoring these issues. I see it more as a > resource issue - we are seeing issues raised at a greater rate than we have > resources to handle. Or that the resources we do have are spend on the wrong thing. > I can't do the same analysis for PRs because github doesn't detect properly when > we merge PRs (because we don't use the github facility for doing that). I would > expect to see somewhat similar numbers though. The amount of open pull requests has been around 200 for the last few months, so it seems we can just keep up with that currently, but it used to be around 100. So I think that in general we do not have enough resources to keep up with both the pull requests and issues. Kurt From kaduk at mit.edu Tue Mar 26 23:08:45 2019 From: kaduk at mit.edu (Benjamin Kaduk) Date: Tue, 26 Mar 2019 18:08:45 -0500 Subject: Issues and pull requests are largely getting ignored In-Reply-To: <20190326132028.GA27949@roeckx.be> References: <8412ad5d-ea0f-d55d-92d8-8efa93d83159@openssl.org> <20190326132028.GA27949@roeckx.be> Message-ID: <20190326230845.GA86501@kduck.mit.edu> On Tue, Mar 26, 2019 at 02:20:28PM +0100, Kurt Roeckx wrote: > On Tue, Mar 26, 2019 at 09:53:22AM +0000, Matt Caswell wrote: > > > > So the real problem there is a mismatch between the opening rate and the closing > > rate, i.e. it is NOT that we are ignoring these issues. I see it more as a > > resource issue - we are seeing issues raised at a greater rate than we have > > resources to handle. > > Or that the resources we do have are spend on the wrong thing. One might, perhaps, try to measure distribution of time between [pull-request/issue] submission and the first comment on it. Consider https://github.com/openssl/openssl/pull/8108 and https://github.com/openssl/openssl/pull/7943 (both submitted by users that are now project members), that have both been open for months and still have no comments! > > I can't do the same analysis for PRs because github doesn't detect properly when > > we merge PRs (because we don't use the github facility for doing that). I would > > expect to see somewhat similar numbers though. > > The amount of open pull requests has been around 200 for the last > few months, so it seems we can just keep up with that currently, > but it used to be around 100. > > So I think that in general we do not have enough resources to keep up > with both the pull requests and issues. Not if we want to keep up the pace of new development towards the goals for the next major release, I agree. (Not that I am doing much to contribute, myself, at this point -- my AD role in the IETF keeps me quite busy.) -Ben