Re: Re-arrange the library structure - Re: CMP is a subproject?
David von Oheimb wrote: > To avoid any misunderstandings on what I wrote before: > My proposal (possibly in difference to Dmitry's) was and still is *not* to > move any functionality out of the OpenSSL main repository, > but to re-arrange the library structure (likely by splitting libcrypto into > two or more libraries) to better reflect the code layering. What I observe is that the "openssl" *app* is not the best example code out there. There are a number of things, particularly those involving certificate creation, where the only obivous[%] way to get some things done is to use an openssl.conf fragment. [%]- sometimes there are non-obvious ways, but the only example code is the apps/*.c, so people wind up emulating it. There are also some things (no, I don't have a list handy) that are done by the apps code, which ought to be a library function. People wind up copy and pasting, then of course, it becomes non-obvious how to update their code. > Expected benefits: > * reduce binary code footprint in case just the crypto core or just > TLS (including crypto) is needed This last part is probably a red herring. If you link against the .a files, then you get only what you need. If you link against the .so, then in theory you pay only once for all users. > * some so far internal crypto interfaces that are used by the more > application-level code need to be exported We need to make a list of these. I think that they are more on the "poorly documented" rather than internal. > plus an actual library (say, libapps) that is more application-level and > includes everything that requires both TLS any crypto features, such as > HTTPS and part of (or even all of) apps/lib/. > This likely would provide a better pros/cons ratio than actually splitting up > libcrypto. I agree with you. I also also agree that restructuring should occur first, and I think that introducing a libapps could in the 3.x stream, but that many other things would be a 4.0 > In particular, as Tomas wrote, the openssl app will continue to provide > everything that it did before. I have advocated in the past splitting the "openssl" app into a new repo which could evolve at a different rate, and with a different level of scrutiny to the core library. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature
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
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
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
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
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
