Re: Project direction

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Project direction

Angus Robertson - Magenta Systems Ltd
> 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


 





Reply | Threaded
Open this post in threaded view
|

Re: Project direction

Michael Richardson

Angus Robertson - Magenta Systems Ltd <[hidden email]> 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   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [









signature.asc (497 bytes) Download Attachment