Stronghold Enhancement Proposal: Better Support for Language Bindings

[felsweg-iota]

SEP: Better Support for Language Bindings

Outline

Bindings to other languages enables Strongholds functionality to be used on a broader spectrum. The usage of security software should not rely on the ability to code in one specific language, but shall expose a flexible, yet secure API to be accessed by many popular programming languages.

Motivation

In a polyglot world with many programming languages, each in their own domain and with their own degree of popularity, Stronghold shall be revisited in terms of language bindings. With the restriction to compiled, and/or managed languages capable of supporting system process and memory protections, Stronghold shall offer an easier and standardized way to support a multitude of programming languages.

So far, Stronghold exposes a client interface to access all of it's core functionality. Language bindings required some intermediate interface to

• expose the desired functionality directly
• export functional symbols as part of a C-ABI

As C (and the respective ABIs ) is used as lingua franca among compiled and native languages, hence it would only be sensible to standardize an exportable interface ready to be included with languages supporting calls to external functionality via a foreign function interface (FFI).

Alternatively RPC solutions like gRPC or cap'n proto shall be explored to widen the integration and adoption of Stronghold as secure data service provider.

Reference-Level Explanation

In order to provide a more flexible binding, we have to answer following questions:

• What languages do we want to support?
  • For the most part bindings shall be offered to Go, C/C++,
• Can we offer a configurable interface for export to other languages?

Comparing RPC vs Native Bindings

	RPC	Native Bindings
advantages	Can be used for distributed services RPC Frameworks are well supported among languages	Almost no calling overhead Integration doesn't require serialization middle ware
disadvantages	incurs latency1 (if not tricked out like cpnp) Reliance on serialization / RPC framework	Restricted support of languages ( Mainly compiled languages ) Would require more work in source library concerning the export of symbols Would require another wrapper for accessing native calls

¹ This blog suggest the usage of gRPC for inter process communication, while having a performance reduction by 10 when compare with unix domain sockets. Benchmarks on other OS are not available, but may have similar figures.

Exposing Functionality through Feature Gates

We define two feature gates, that expose the functionality from Stronghold.

• p2p is already present and adds secure networking functionality to Stronghold
• persist would enable Stronghold to store runtime state present in Clients to be persisted on disk.

If both feature flags are not set during build, only the core functionality would remain.

Drawbacks

Language bindings to Stronghold must be carefully crafted and system capabilities must be considered, when evaluating for specific languages. Exporting functionality that is intended to run in a web-browser would render security mechanism obsolete, or even would not enable bindings at all.

Rationale and Alternatives

Prior art

prose

Unresolved Questions

Native

• could be provide a configurable wrapper interface, that would be generated automatically? similar to additive features like p2p? core features would expose the runtime features of Stronghold only, while a posssible persist feature would enable Snapshot file persistence.
• ...

Future Possibilities

prose

Resources

• Mozilla Uni-FFI
• Rust-Diplomat

[felsweg-iota]

SWIG could be used? https://blog.jonharrington.org/rust-and-swig/