Expose the Runner API to allow 3rd party Procedures.

[tensor-programming]

Description of change

Duplicate of #499
The main change here is just to expose the Runner API and also update the libsodium-sys library to the libsodium-sys-stable version which is being properly maintained (the older version was achieved months ago). Exposing the Runner API makes it easier for anyone to create their own procedures without having to make a PR to the stronghold repository. This doesn't change the security of the library as anyone is able to create their own stronghold client even without these changes. All this change does, is make it possible for a 3rd party to write their own extension procedures in a way that works with the existing APIs. The security of these procedures is up to the author rather than the IF.

Here is libsodium-sys-stable: https://github.com/jedisct1/libsodium-sys-stable and here is the original repo: https://github.com/sodiumoxide/sodiumoxide

Jedisct1 is the maintainer of the popular webview library, and his code is more or less the same as the original with minor updates to keep it inline with the sodium c library.

Links to any relevant issues

Be sure to reference any related issues by adding fixes issue #.

Type of change

Choose a type of change, and delete any options that are not relevant.

• Bug fix (a non-breaking change which fixes an issue)
• Enhancement (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Fix

How the change has been tested

Change is very simple, nothing to really test apart from the original tests in the system. Even without exposing the runner, anyone can build their own stronghold client with the current API.

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

• I have followed the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[JelleMillenaar]

I would like to provide some additional context to this PR from the perspective of Impierce Technologies. We are building Self-Sovereign Identity solutions on top of the IOTA Identity framework and utilize Stronghold for key management. While the on-chain interactions have to follow ED25519, which is supported in Stronghold, SSI also contains a significant amount of off-chain cryptographic operations such as signing Verifiable Credentials or OpenID4VC requests/responses.

These off-chain signing operations need to be aligned with other ecosystems such as the DIIP interoperability profile and EBSI to create interoperability with other applications and wallets which will lead to a much wider ecosystem and adoption potential. Both EBSI and the wider SSI world currently favors the use of ES256, but other ecosystems might also require other signature schemes.

We tasked Tensor to implement ES256 in Stronghold and hoped to contribute it to Stronghold instead of requiring us to fork. He came up with this very elegant yet simple solution to only expose the Runner API, which allows third parties to add additional signature schemes to their Stronghold without compromising on security.

While we know Stronghold is in maintenance mode, we hope that this PR could be merged as it will also be beneficial for the IOTA Identity framework (Which allows EBSI ES256 compatibility and potentially ZKP), EBSI PCP and likely other IF projects like TLIP as well.

[tensor-programming]

Can anyone take a look at this? I don't mind fixing the linting errors and bringing the dependencies up to date if thats whats requried.

[semenov-vladyslav]

@tensor-programming , could you please add .changes file? I forgot to mention it in my review.

Also, you should consider switching to 2.0 branch. I has some security improvements over dev.

Would you fancy bringing these changes to 2.0 branch too?

[tensor-programming]

Sure, I can do both of those things. If you don't mind me asking, is 2.0 just something that is going to eventually be merged with dev or is it the new primary branch for now?

[tensor-programming]

I've rebased 2.0 into this branch but it seems like its applying the 3 commits that dev has which aren't on 2.0 I can remove these if thats not something you guys want. That would be the changing of the bee stuff from specs and the deletion of the documentation folder in favor of the wiki.

[tensor-programming]

I am just going to close this PR and make a new one. Should make things easier since for whatever reason its throwing in merge conflicts and the like.