Allow supplying Sa/Key/Mc interfaces that have not been compiled with CryptoLib

[Niautanor]

Currently, the process for supplying a mission specific custom interface is to include CryptoLib as a git submodule, provide an e.g. sa/sa_custom/sa_custom.c next to the submodule and let CryptoLib compile it and initialize it in Crypto_Init(). This approach has some drawbacks:

• Since the interface is compiled as a part of CryptoLib, project specific code is compiled with the CryptoLib compiler flags and warnings rather than the project compiler flags and warnings
• It enforces a specific project structure on library consumers
• Installing CryptoLib as a generic shared library becomes impossible
• Interfaces have to be mostly self contained and can't use functions defined in project headers (unless you explicitly include project headers via relative paths, I guess, but this goes back to the project structure point)
• There is no easy way to pass configuration data to the interface

With the proposed change, projects will be able to do e.g. sa_if = &project_sa_if; before calling Crypto_Init() while the behaviour will be unchanged for library consumers that do not modify the interface pointers themselves.

[Niautanor]

(I'll send the signed CLA shortly)

[jlucas9]

Can confirm receipt of CLA!

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 60.00000% with 10 lines in your changes missing coverage. Please review.

Project coverage is 82.69%. Comparing base (3c2a3d4) to head (8c0c72c).

Files	Patch %	Lines
src/core/crypto_config.c	60.00%	6 Missing and 4 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #257   +/-   ##
=======================================
  Coverage   82.68%   82.69%           
=======================================
  Files          40       40           
  Lines       10026    10029    +3     
  Branches      814      817    +3     
=======================================
+ Hits         8290     8293    +3     
  Misses       1437     1437           
  Partials      299      299           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jlucas9]

Looks good to me! Hadn't tested outside the project yet, thanks for the PR!

[rjbrown2]

@williamposey: Would you mind looking over this quickly? Wanted to make sure you saw this upcoming change before we merged it in.

[williamposey]

@williamposey: Would you mind looking over this quickly? Wanted to make sure you saw this upcoming change before we merged it in.

Hey @rjbrown2 I just got back from vacation today, I will try and look things over by EOD!

[williamposey]

I like the approach of decoupling the library from the various interfaces. I have a few questions/concerns:

• should there be CMake changes to coincide with setting the interface at run time? Maybe a default configuration to stubbed interface definitions?
• should there be a standard API call to set the various interfaces? I'm thinking that it would be self-documenting to provide a function call like Set_Security_Association_Interface(SaInterface *sa)

[jlucas9]

I like the approach of decoupling the library from the various interfaces. I have a few questions/concerns:

• should there be CMake changes to coincide with setting the interface at run time? Maybe a default configuration to stubbed interface definitions?

I think the code exists now to check that something has been initialized or one of the default configurations used. It'll error out otherwise if you built it assuming a custom interface then don't perform that init step for it as you make your calls.

• should there be a standard API call to set the various interfaces? I'm thinking that it would be self-documenting to provide a function call like Set_Security_Association_Interface(SaInterface *sa)

As it's not really determined at runtime now sure this is needed.

[williamposey]

I like the approach of decoupling the library from the various interfaces. I have a few questions/concerns:

• should there be CMake changes to coincide with setting the interface at run time? Maybe a default configuration to stubbed interface definitions?

I think the code exists now to check that something has been initialized or one of the default configurations used. It'll error out otherwise if you built it assuming a custom interface then don't perform that init step for it as you make your calls.

• should there be a standard API call to set the various interfaces? I'm thinking that it would be self-documenting to provide a function call like Set_Security_Association_Interface(SaInterface *sa)

As it's not really determined at runtime now sure this is needed.

I think it makes sense to move this PR ahead and a follow up issue can address additional changes. I'll approve now