Update to CCF 2.0.11 about scitt-ccf-ledger HOT 16 CLOSED

I'm experimenting with 3.x in #30

from scitt-ccf-ledger.

I think what Maik is referring to is typically during local development, I would configure SCITT with COMPILE_TARGET=sgx, build and run the integration tests on my local machine. Now if I also want to run unit tests I need to switch to COMPILE_TARGET=virtual and rebuild SCITT to be able to run them. I might have to switch back and forth between the two repeatedly. Of course I can solve this by having two build directories configured differently and switch between those two instead. Or I stick to virtual builds and let CI check the SGX build for me.

So not a dealbreaker, but inconvenient.

from scitt-ccf-ledger.

Would suggest https://github.com/microsoft/CCF/releases/tag/ccf-2.0.10

from scitt-ccf-ledger.

It's hard to keep up at this rate :) But yeah, 2.0.10 it is.

from scitt-ccf-ledger.

The releases start coming and they don't stop coming 🎶

from scitt-ccf-ledger.

@plietar @letmaik absolutely: https://github.com/microsoft/CCF/releases/tag/ccf-3.0.0

from scitt-ccf-ledger.

This one's going to be a bit more work than bumping a number up 😀

from scitt-ccf-ledger.

@plietar sure, yes, but you can now COSE Sign even more things than before!

from scitt-ccf-ledger.

But I can't run my unit tests anymore: microsoft/CCF#4428 (comment)

from scitt-ccf-ledger.

@plietar as discussed, these artefacts are still released, we've just split the packages. You will either need to loop over some defines in your virtual build, or install both on the SGX side if you wish to keep those tests there (despite them not needing or using SGX as such). If there are target conflicts, we will look at how they can be resolved with prefixes.

from scitt-ccf-ledger.

I'm trying to do the multiple find_package trick, but it's causing all sorts of problems due to cmake having a lot of global shared state. For starters, oe does not seem to support being included with both hostverify and enclave targets: https://github.com/openenclave/openenclave/blob/a8c70d309d7d06fc8685c63eb25f91ca37e8cae0/cmake/openenclave-config.cmake.in#L78-L81

I'm sure we can get it to work with something like cmake metabuilds or whatever, but just importing CCF twice is unlikely to ever work IMO.

from scitt-ccf-ledger.

For starters, oe does not seem to support being included with both hostverify and enclave targets: https://github.com/openenclave/openenclave/blob/a8c70d309d7d06fc8685c63eb25f91ca37e8cae0/cmake/openenclave-config.cmake.in#L78-L81

Yes, this is why we have to do this: https://github.com/microsoft/CCF/blob/main/cmake/cpack_settings.cmake#L32. I'm not sure what, if anything, we can do about that.

It is probably easier to build your unit tests with and without your SGX flags, but always against the virtual package.

from scitt-ccf-ledger.

It is probably easier to build your unit tests with and without your SGX flags, but always against the virtual package.

That's fine, but it means that when developing locally and building for SGX we wouldn't be able to run unit tests without a secondary CMake build. Is CCF doing the same or is there another trick?

from scitt-ccf-ledger.

@letmaik I'm not sure I understand the question, CCF never built nor ran unit tests in enclave.

building for SGX

This seems to be used with two different meanings, one is building binaries that can run in SGX enclaves. The other is building binaries similar to those that would run in SGX enclaves, and may contain certain features that you only wish to enable there, but cannot directly run in SGX enclaves.

If you're building the former, you can use the SGX package of CCF, if it's the latter, you can use the virtual package.

from scitt-ccf-ledger.

Or I stick to virtual builds and let CI check the SGX build for me.

That's how a lot of the work on CCF itself happens, and why we release the virtual build. Alternatively, if you want to use the SGX build primarily, you can make use of Open Enclave's simulation mode.

But I can't run my unit tests anymore
...
So not a dealbreaker, but inconvenient.

I'm glad that's cleared up. I think the benefits of splitting the packages per platform will become more apparent once you start to expand beyond SGX.

from scitt-ccf-ledger.

Closed in #30

from scitt-ccf-ledger.