The branch master has been updated
via 604491061a61f0e554cdd38354df341f57ee9fc1 (commit)
via 9a8296e24a0b4dc88cda33aacdab44676906f7c5 (commit)
from c2804b5a37217fccddacb44e5dc2791f962759ac (commit)
- Log -----------------------------------------------------------------
commit 604491061a61f0e554cdd38354df341f57ee9fc1
Author: Richard Levitte <levi...@openssl.org>
Date: Sat Feb 16 14:02:44 2019 +0100
3.0.0 design doc: /usr/share -> /usr/lib
/usr/share was a bad example for storing modules
Reviewed-by: Matt Caswell <m...@openssl.org>
(Merged from https://github.com/openssl/web/pull/119)
commit 9a8296e24a0b4dc88cda33aacdab44676906f7c5
Author: Richard Levitte <levi...@openssl.org>
Date: Sat Feb 16 14:02:04 2019 +0100
3.0.0 design doc: mark all code sections with a language where possible
Reviewed-by: Matt Caswell <m...@openssl.org>
(Merged from https://github.com/openssl/web/pull/119)
-----------------------------------------------------------------------
Summary of changes:
docs/OpenSSL300Design.md | 33 ++++++++++++++++-----------------
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/docs/OpenSSL300Design.md b/docs/OpenSSL300Design.md
index 30a02eb..d30e8fe 100644
--- a/docs/OpenSSL300Design.md
+++ b/docs/OpenSSL300Design.md
@@ -420,7 +420,7 @@ create and provide its own library context, an internal
default one
will be used.
-```
+``` C
OPENSSL_CTX *OPENSSL_CTX_new();
void OPENSSL_CTX_free(OPENSSL_CTX *ctx);
```
@@ -707,7 +707,7 @@ entry point.
A provider module _must_ have the following well known entry point:
-```
+``` C
int OSSL_provider_init(const OSSL_PROVIDER *provider,
const OSSL_DISPATCH *in,
const OSSL_DISPATCH **out);
@@ -735,7 +735,7 @@ function-pointer >` tuple mentioned in the introduction of
[Core and Provider Design](#core-and-provider-design):
-```
+``` C
typedef struct ossl_dispatch_st {
int function_id;
void *(*function)();
@@ -760,7 +760,7 @@ numbers. More function numbers can be added in later
releases as
required without breaking backwards compatibility.
-```
+``` C
/* Functions provided by the Core to the provider */
#define OSSL_FUNC_ERR_PUT_ERROR 1
#define OSSL_FUNC_GET_PARAMS 2
@@ -773,7 +773,7 @@ required without breaking backwards compatibility.
The Core will set up an array of the well known callback functions:
-```
+``` C
static OSSL_DISPATCH core_callbacks[] = {
{ OSSL_FUNC_ERR_PUT_ERROR, ERR_put_error },
/* int ossl_get_params(OSSL_PROVIDER *prov, OSSL_PARAM params[]); */
@@ -789,7 +789,7 @@ testing, instrumentation etc as the need comes up.
Once the module is loaded and the well known entry point located, the
init entry point can be invoked by the Core:
-```
+``` C
/*
* NOTE: this code is meant as a simple demonstration of what could happen
* in the core. This is an area where the OSSL_PROVIDER type is not opaque.
@@ -857,7 +857,7 @@ code.
Operations are identified by a unique number. For example:
-```
+``` C
#define OSSL_OP_DIGEST 1
#define OSSL_OP_SYM_ENCRYPT 2
#define OSSL_OP_SEAL 3
@@ -906,7 +906,7 @@ for init functions for other operations, those will have
their own
unique numbers. For example, for the digest operation, these functions
are required:
-```
+``` C
#define OSSL_OP_DIGEST_NEWCTX_FUNC 1
#define OSSL_OP_DIGEST_INIT_FUNC 2
#define OSSL_OP_DIGEST_UPDATE_FUNC 3
@@ -923,7 +923,7 @@ typedef void (*OSSL_OP_digest_freectx_fn)(void *ctx);
An all in one version is also advisable for devices that cannot handle
multi-part operations:
-```
+``` C
#define OSSL_OP_DIGEST_FUNC 6
typedef int (*OSSL_OP_digest)(const OSSL_PROVIDER *prov,
const void *data, size_t len,
@@ -938,7 +938,7 @@ for each operation. The algorithm descriptor was mentioned
higher up,
and would be publically defined like this:
-```
+``` C
typedef struct ossl_algorithm_st {
const char *name;
const char *properties;
@@ -952,7 +952,7 @@ querying function such as `fips_query_operation` below
returns) the
FIPS module may define arrays like this for the SHA1 algorithm:
-```
+``` C
static OSSL_DISPATCH fips_sha1_callbacks[] = {
{ OSSL_OP_DIGEST_NEWCTX_FUNC, fips_sha1_newctx },
{ OSSL_OP_DIGEST_INIT_FUNC, fips_sha1_init },
@@ -1105,8 +1105,7 @@ application to specify a non-default library context if
required
(`osslctx` in this example):
-```
-
+``` C
EVP_CIPHER_CTX *ctx;
EVP_CIPHER *ciph;
@@ -2344,7 +2343,7 @@ There is functionality to create diverse EVP method
structures in
OpenSSL 1.1.x, easily found like this:
-```
+``` shell
grep EVP_CIPHER_meth util/libcrypto.num
grep EVP_MD_meth util/libcrypto.num
grep EVP_PKEY_meth util/libcrypto.num
@@ -2663,7 +2662,7 @@ time.
We have macros to declare the type of content in `data_type`:
-```
+``` C
#define OSSL_PARAM_INTEGER 1
#define OSSL_PARAM_UNSIGNED_INTEGER 2
#define OSSL_PARAM_UTF8_STRING 3
@@ -2712,7 +2711,7 @@ bar = bar_section
[foo_section]
provider_id = myfoo
-module_path = /usr/share/openssl/providers/foo.so
+module_path = /usr/lib/openssl/providers/foo.so
selftests = foo_selftest_section
algorithms = RSA, DSA, DH
@@ -2725,7 +2724,7 @@ The Core side provider structure for the provider "foo"
could then
answer to these requested parameter keys:
* `"provider_id"` (value is `"myfoo"`)
-* `"module_path"` (value is `"/usr/share/openssl/providers/foo.so"`)
+* `"module_path"` (value is `"/usr/lib/openssl/providers/foo.so"`)
* `"selftests.doodah"` (value is `1`)
* `"selftests.cookie"` (value is `0`)
* `"algorithms"` (value is `"RSA, DSA, DH"`)
