Split crates into library and applications

[ueno]

This is a start of refactoring the codebase into three sub-crates: keylime, keylime_agent, and keylime_ima_emulator. The keylime crate provides common facility used by the other crates as a library (currently only IMA parser).

Signed-off-by: Daiki Ueno dueno@redhat.com

[aplanas]

[Seems that the tests fail because of the shim.py move]

[ueno]

[Seems that the tests fail because of the shim.py move]

I've reverted that change (btw: I would put shim.py in dist/ instead of tests/ as it is installed), though the tests are still failing because they modify the source code.

[aplanas]

[Seems that the tests fail because of the shim.py move]

I've reverted that change (btw: I would put shim.py in dist/ instead of tests/ as it is installed), though the tests are still failing because they modify the source code.

Ah that is unfortunate ... I wonder what can be the correct approach here. One can be fork the keylime-tests to adapt the tests and add in the PR the address of the forked repo (I think that I saw this approach in other PR)

Another one is compile the agent as debug when testing, and adding a #[cfg(debug_assertions)] that will fetch the IMA measurement path from a env var if set.

[ueno]

I also tried to move tpm.rs into the library crate. The generated documentation is temporarily hosted here. My idea is to port low-level primitives first, then eventually provide a high-level (protocol) API over them. That way, we could gradually migrate the code out of the agent to the library.

@lkatalin @ansasaki any thoughts on that?

[ansasaki]

I also tried to move tpm.rs into the library crate. The generated documentation is temporarily hosted here. My idea is to port low-level primitives first, then eventually provide a high-level (protocol) API over them. That way, we could gradually migrate the code out of the agent to the library.

@lkatalin @ansasaki any thoughts on that?

Thanks for working on this! I think it makes sense to follow this incremental approach and progressively move the code out of the agent and into the library.

I've reverted that change (btw: I would put shim.py in dist/ instead of tests/ as it is installed), though the tests are still failing because they modify the source code.

About the failing test, maybe we could use a branch while we don't have a way to configure the measured boot log path. @kkaarreell Could TMT dynamic reference help us here?

[kkaarreell]

About the failing test, maybe we could use a branch while we don't have a way to configure the measured boot log path. @kkaarreell Could TMT dynamic reference help us here?

I think I have all the required changes in RedHat-SP-Security/keylime-tests#275
To use those updates please (temporarily) modify packit-ci.fmf file and in the environment section define variable RUST_KEYLIME_UPSTREAM_BRANCH: rust_pr_481

[ueno]

About the failing test, maybe we could use a branch while we don't have a way to configure the measured boot log path. @kkaarreell Could TMT dynamic reference help us here?

I think I have all the required changes in RedHat-SP-Security/keylime-tests#275 To use those updates please (temporarily) modify packit-ci.fmf file and in the environment section define variable RUST_KEYLIME_UPSTREAM_BRANCH: rust_pr_481

Thank you! I'm assuming that you meant ref: rust_pr_481 under discover, instead of RUST_KEYLIME_UPSTREAM_BRANCH. With that change, those packit tests are now passing.

[kkaarreell]

Right, of course, sorry for that.

[kkaarreell]

Thank you! I'm assuming that you meant ref: rust_pr_481 under discover, instead of RUST_KEYLIME_UPSTREAM_BRANCH. With that change, those packit tests are now passing.

I have merged the test update. You can restore original reference

[ueno]

Thank you! I'm assuming that you meant ref: rust_pr_481 under discover, instead of RUST_KEYLIME_UPSTREAM_BRANCH. With that change, those packit tests are now passing.

I have merged the test update. You can restore original reference

Thanks; done and merged.