Re: Project direction
On Nov 2, 2020, at 2:16 PM, Michael Richardson wrote: > Angus Robertson - Magenta Systems Ltd wrote: > > OpenSSL is really aimed at two markets, developers using the API and > > admins using the applications, it would be easier for both groups if > > the help was separate. > I think that the "admins using the application" has never been a target. > While people build CAs using the shell scripts, my impression is that this > has been a discouraged activity. > This is one reason I'd like the tools split off into it's own git repo, > so that it could evolve separately. Even if it was actually the case that "admins using the application" have never been the target, that is the primary use case as indicated by questions on *overflow (eg stack overflow) sites. You can find very few popular posts on said sites. This is also the case when searching on google. Try googling "how do I X in Openssl" and you'll get many articles discussing how to achieve various tasks using the command line tools. The majority of users of openssl are actually users of the openssl applications.
Re: Project direction
Angus Robertson - Magenta Systems Ltd wrote: > OpenSSL is really aimed at two markets, developers using the API and > admins using the applications, it would be easier for both groups if > the help was separate. I think that the "admins using the application" has never been a target. While people build CAs using the shell scripts, my impression is that this has been a discouraged activity. This is one reason I'd like the tools split off into it's own git repo, so that it could evolve separately. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: Project direction (fwd) Michael Richardson: Re: Project direction
--- Begin Message --- Angus Robertson - Magenta Systems Ltd wrote: > Also, there is an assumption OpenSSL is only used by other C developers, > by the use of public macros that are not usable in any other language. > BoringSSL replaced macros with exports and OpenSSL should consider > doing the same. This. > There needs to be more task oriented documentation, for instance > collecting the APIs needed to create a CSR or certificate, using APIs > rather than command line tools which is where much of the documentation > currently resides. For instance there is no documentation about > building a stack of extensions to add SANs to requests and certificates > so a lot of research is needed to adds SANs to a certificate. My claim is that much of the "applications" should be removed from the core system, and should be re-implemented in a cleaner way using the APIs. I.e. into a separate git repo with it's own release schedule. They should serve as exemplars for using the APIs, which they are often are not. In particular, the way that many things are only doable via "configuration file" is a serious problem. Yes, the applications are used as part of the tests, but I'm not saying that they shouldn't be pulled in as a github. Could Perl wrapper be used for more? Could it be used exclusively? (No calls out to "openssl ca" to generate a certificate...) The tests do not serve as particularly good examplars, because of the mix of C and perl, sometimes the perl is just running some .c code that was compiled... sometimes not. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature --- End Message ---
Re: Project direction
> My claim is that much of the "applications" should be removed > from the core system, and should be re-implemented in a cleaner > way using the APIs. > I.e. into a separate git repo with it's own release schedule. > > They should serve as exemplars for using the APIs, which they are > often are not. > > In particular, the way that many things are only doable via > "configuration file" is a serious problem. Agree, to create X509 SANs you need to understand the application, but that gets very confusing since half of it is getting command line and config file input, even harder when you don't understand C. You end up using obscure APIs like GENERAL_NAME_set0_value for which there is no documentation, because there seems nothing better to use to create the stack of extensions. But it was satisfying when it all worked and I had a CA component. OpenSSL is really aimed at two markets, developers using the API and admins using the applications, it would be easier for both groups if the help was separate. Angus
Fwd: Project direction
Forwarding this to openssl-project from openssl-users. Please keep the discussion on the openssl-project list! Note: Although openssl-project is a moderated list, I am one of the moderators and will let through posts that are clearly relevant. Matt Forwarded Message Subject: Re: Project direction Date: Mon, 2 Nov 2020 16:51 + (GMT Standard Time) From: Angus Robertson - Magenta Systems Ltd Reply-To: an...@magsys.co.uk To: openssl-us...@openssl.org > The idea being that supporting existing users means not changing > the existing API, whereas catering to new users means working > towards a new fresh consistent API. OpenSSL has been in use for getting on for 20 years (I think) and may still be in use in another 20 years, so can not stay still to make life easy for old projects, it has to evolve for new projects, as it does. But any changes should be clearly documented and should not require the use of third party sites like ABI to discover new APIs and changes to old ones. Major changes are usually in the changelog, but can be hard to find when updating from a much earlier release. There should really be detailed articles about upgrading from any long term release to the latest release, with simple lists of all exports or macros removed or added, or whose use has changed. Also, there is an assumption OpenSSL is only used by other C developers, by the use of public macros that are not usable in any other language. BoringSSL replaced macros with exports and OpenSSL should consider doing the same. Currently changing a macro to an export is rarely documented, so it's hard for those that have rewritten macros in other languages to know something will be broken. There needs to be more task oriented documentation, for instance collecting the APIs needed to create a CSR or certificate, using APIs rather than command line tools which is where much of the documentation currently resides. For instance there is no documentation about building a stack of extensions to add SANs to requests and certificates so a lot of research is needed to adds SANs to a certificate. Angus
Re: Project direction
Benjamin Kaduk wrote:
>> On Mon, 2 Nov 2020 at 10:47, Christian Heinrich <
>>
>>
>> > Maybe we should define the problems that new end users experience
>> > during onboarding instead and address those first?
>> >
>>
>> Better documentation would help enormously.
> Would that take the form of ensuring that each public API has a man page,
> or a general "here's how to get started with "
with
> examples, or something else?
Most of the APIs have a man page, but the man pages are often not that
useful. They might explain how to use the call, but not always:
* why I should use this call?
* how to get the various inputs for the call.
There are many manpages which explain the {A,B,C,D}_get_{X,Y,Z}() calls.
And while this is a nice convenience, as they are rather similar, the result
lacks much of the context needed above.
I would like a man page for each *object* that OpenSSL has.
Tell me how to make the object, how to free it, how to manipulate it, what
the expected lifetime (to use the Rust term) for the object is.
Please also tell me what it's a pre-requisite for.
The sectional and version organization of the web site is a bit wonky.
We need links from the 0.9.8 version of the man pages to the "most recent",
as the older pages get better Google SEO.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
Re: Project direction
On Mon, Nov 02, 2020 at 03:51:58PM +, Dick Franks wrote: > On Mon, 2 Nov 2020 at 10:47, Christian Heinrich < > > > > Maybe we should define the problems that new end users experience > > during onboarding instead and address those first? > > > > Better documentation would help enormously. Would that take the form of ensuring that each public API has a man page, or a general "here's how to get started with " with examples, or something else? Thanks, Ben
Re: Project direction
On Mon, 2 Nov 2020 at 10:47, Christian Heinrich < christian.heinr...@cmlh.id.au> wrote: > > On Fri, 30 Oct 2020 at 10:45, Dr Paul Dale wrote: > > The question was should we design our APIs to ease the pain existing > > users of OpenSSL or should we be trying to attract new users. > > The idea being that supporting existing users means not changing the > > existing API, whereas catering to new users means working towards > > a new fresh consistent API. > > As far as I am aware the competition isn't much better than us ¯\_(ツ)_/¯ > As a user mainly interested in the libcrypto library component, OpenSSL is far better than the competition. However, there are 1189 reasons to think is not perfect. LibreSSL not only lacks performance but also behind on the functionality front (no Ed25529, Ed448, SHA3). Whatever aspirations it may have had at the start have long since evaporated and it is now a poor relation of OpenSSL 1.1.0 BoringSSL has declared itself not to be a competitor. > Maybe we should define the problems that new end users experience > during onboarding instead and address those first? > Better documentation would help enormously. --RWF
Monthly Status Report (October)
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Fixed DHX parameter encoding (they were incorrectly being encoded using PKCS3 Parameters). Also extended the encode/decode tests as part of this. - Active participant in the interviewing and recruitment process for the "Administrator and Manager" position - Ongoing participation in the regular OTC meetings - Ongoing participation in regular FIPS sponsor meetings - Removed CMS specific code out of the algorithm implementations and removed key downgrades - Deprecated EVP_PKEY_set1_tls_encodedpoint() as well as the get version. Implemented replacements with more generic names. - Concentrated all deprecated API usage in libssl in one file - Fixed an issue with the SSL_SECOP_TMP_DH security operation which was defined to take an EVP_PKEY, but was actually sending a DH object in one instance. - Performed the alpha 7 release - Created WIP to do the DH deprecation - Fixed an issue that was causing a test failure in a no-dh build - Fixed the deprecation macros to allow "empty" deprecation macros to be passed as macro arguments - Created PR to change the default key generation type for DH and DSA - Fixed an issue where we weren't calling SSLfatal on an error path in libssl - Created PR to convert dhparam so that it no longer needs to use low level APIs - Created PR to remove all instances of low-level DH use in libssl - Fixed some missed usage of DEFINE_LHASH_OF() that meant there were compile failures on some platforms Matt
Re: Project direction
Dr Dale, On Fri, 30 Oct 2020 at 10:45, Dr Paul Dale wrote: > The question was should we design our APIs to ease the pain existing > users of OpenSSL or should we be trying to attract new users. > The idea being that supporting existing users means not changing the > existing API, whereas catering to new users means working towards > a new fresh consistent API. As far as I am aware the competition isn't much better than us ¯\_(ツ)_/¯ "LibreSSL was great as alternative when Heartbleed first emerged, but LibreSSL development has lagged way behind OpenSSL to the point that OpenSSL 1.1.1 is miles ahead of LibreSSL in performance" to quote https://community.centminmod.com/threads/openssl-or-libressl-in-mid-2020.19810/ "There are no guarantees of API or ABI stability with this code: we are not aiming to replace OpenSSL as an open-source project." to quote https://www.chromium.org/Home/chromium-security/boringssl Maybe we should define the problems that new end users experience during onboarding instead and address those first? -- Regards, Christian Heinrich http://cmlh.id.au/contact
