Re: Project direction

2020-11-02 Thread Michael Richardson

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

2020-11-02 Thread Michael Richardson
--- 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

2020-11-02 Thread Michael Richardson

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: Reordering new API's that have a libctx, propq

2020-09-10 Thread Michael Richardson

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   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature


Re: Thoughts about library contexts

2019-02-18 Thread Michael Richardson

Paul Dale  wrote:
> Library contexts are going to allow us to separate different portions of 
the
> TLS/cryptographic activity within one application. No problems, here. This
> seems like a useful and worthwhile idea. It will e.g. be a way to separate
> FIPS and non-FIPS streams nicely.

> I’ve a reservation about the current definition. Why must they be opaque? 
I’m
> not suggesting that complete visible is a good idea, but partial 
visibility
> over some areas of the core would be useful. E.g. the core components 
ought
> to be able to access other core components without diving through an
> indirection scheme.

If by opaque, you mean that the C "struct" definition is not visible to the
application, then that's required so that we can maintain ABI across changes
to the structure.

> What level of isolation do we want between different contexts? We’re 
unlikely
> to be able to completely segregate them but should we make an effort to
> reduce information leakage between them? E.g. the current properties has a
> couple of global databases that will be shared across all contexts – would
> they make better sense being one per context? There would be a space 
cost, a
> reduction in the cache efficiency, … but it would add to segregation.
> Enclaves could also assist.

> Thoughts anyone?

> Pauli

> --

> Oracle

> Dr Paul Dale | Cryptographer | Network Security & Encryption

> Phone +61 7 3031 7217

> Oracle Australia



> 
> Alternatives:

> 


signature.asc
Description: PGP signature


Re: [openssl-project] OpenSSL 3.0 and FIPS Update

2019-02-14 Thread Michael Richardson

Matt Caswell  wrote:
> Please see my blog post for an OpenSSL 3.0 and FIPS Update:

> https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/

Thank you, it is very useful to have these plans made up front.
I think your posts should probably explain what happened to 2.x, and if this
represents a move towards semantic versioning. (I think it does...?)

In the various things linked, in particular:
   https://www.openssl.org/docs/OpenSSL300Design.html

I think that there is a missing box.  Specifically, the PERL API wrappers
that are used in the test bench.  I believe that the "applications" are
a serious problem as there are (in 1.1.1) still many things that are very
difficult (sometimes, it seems, impossible) to do programmatically, and which
the test cases actually simply shell out to the application to do.
An example of this is adding certain extensions to a certificate when
generating it, which is only really possible by loading pieces of
configuration file in.

So what I'd like to see is to remove many of the applications from the core
of OpenSSL, put them into a seperate package using better-documented API
calls.  Let them evolve according their own time-scale, probably taking
patches faster without disrupting the underlying libraries.

My observation is that the Perl testing system is used to drive the tests,
but the tests do not actually use the Perl API wrapper for OpenSSL, but
rather rely on the vast number of .c files in test/*.
In other (more purely agile) projects, the test cases often serve as
documentation as to how to use the API.  In OpenSSL, the test cases
rely too much on the openssl "applications", and the API is hidden.

This would involve adopting some or all of Net::SSLeay.
While there would be some initial duplication of effort, I think that over
time it would sort itself out.  Perl is no longer as cool as it used to be (I
still like it) and maybe someone would argue for Python3 or something, and
frankly I don't care which.

What I care about is that the test cases actually test the API, rather than
depend upon 20 years of twisty code in the "applications".
And that the applications are permitted to grow/change/adapt to people's
needs, rather than living in a hard spot between developer needs and end
user needs, pissing off both groups.

--
]   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
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project