You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The PSA Crypto API has some implementation-defined parts. For example, output size macros and various types need to be defined by the implementor.
The consequence of that are:
the header file of the PSA Crypto implementation needs to be given as an input of this crate to generate the bindings
bindings can not be pre-generated
dynamic loading is impossible
A solution to investigate would be for us to define a subset PSA Crypto API where:
all functions are defined but return PSA_ERROR_NOT_SUPPORTED if not implementend
the key types and algorithms are limited to only the ones defined within the API (no extension)
the output macro are implemented (they can be with the constraint above)
the types are implemented, probably with void * pointer
We could implement all this in a header file, in this repo that we produce bindings from.
On the PSA Crypto implementors side, there will be a need to write a wrapper implementing our subset with the available functions.
In an ideal world, we could imagine a compilation option on the implementor project to produce a .a or .so which implements the subset instead of the original API. Then people will need to use that with Parsec.
The text was updated successfully, but these errors were encountered:
The PSA Crypto API has some implementation-defined parts. For example, output size macros and various types need to be defined by the implementor.
The consequence of that are:
A solution to investigate would be for us to define a subset PSA Crypto API where:
PSA_ERROR_NOT_SUPPORTED
if not implementendvoid *
pointerWe could implement all this in a header file, in this repo that we produce bindings from.
On the PSA Crypto implementors side, there will be a need to write a wrapper implementing our subset with the available functions.
In an ideal world, we could imagine a compilation option on the implementor project to produce a
.a
or.so
which implements the subset instead of the original API. Then people will need to use that with Parsec.The text was updated successfully, but these errors were encountered: