We are using Rust heavily inside our company. However, some security certifications need separation of concerns. So if we want to get certified, we need to make sure that some crate is visible only for those working on that crate. However, of course, some crates use another crates from our company.
Since Rust has a non-stable ABI, we cannot compile a crate as a binary that can be used by other people. Also, compiling as a C binary with a C interface is extremely unsafe. The only solution I can see is that everyone uses the same exact rustc version on the company and we share rlibs.
For libraries that need trade secret protection, your best option is to compile to a cdylib and present a stable ABI using the crates that help you with that task.
That's not what separation of concerns means. Separation of concerns is an API design principle. It has nothing to do with who can see what code.
You achieve good, secure, usable APIs by following good design practice, by documenting code extensively, and by regularly maintaining it. You do not achieve good and secure APIs by artificially hiding source code from co-workers.
I would even go as far to argue that hiding code would lead to even worse security. Since, the proof of the pudding lies in the eating, the best way to increase security is actually peer-auditing code and actively trying to break it.
On the other hand, it seems to me that @adriana_777 needs the code to be hidden because of some external requirements. So, what are the requirements? Why do you need to hide the code from co-workers?
Some security certifications require to apply the "need to know" rule, where everything is kept secret from everyone except for the people who really need to know about it.
I'm not sure what we're achieving here by telling OP that their unsupported use case is Actually Bad.
OP, unfortunately this use case is not well supported by rust at the moment. Some attempted to do plugin systems in Rust, maybe that could help you? This is the state of the art to my knowledge: A Plugin System in Rust | NullDeref
Note: as far as I know, "everyone using the same toolchain/compiler version" is not actually supported, and could conceivably break in funny ways in the future?
Sometimes it’s hiding your code from yourself, depending what machine you’re using… While I agree with your point, companies dealing with issues of national security for multiple nations (for example) often have their hands tied by such technically dubious regulations. You may be allowed to reuse an existing component for another contract, but only as a black box, forbidding the dependency’s source code ever being on the same network as the new contract’s code.
Even if there's no officially supported way to have binary compatibility (even by fixing the compiler version), I'd like to see if we can still at least come up with some solutions that are better than doing a bunch of FFI by hand.
I am wondering, if you were writing in C, would your requirements allow you to use public header files from the other projects, or would you have to use extern declarations? Just trying to gauge how much flexibility there is here.
"Crates that help you with that task?" Do you have anything in particular in mind?