feat(dcap): make DCAP RA default #150
Conversation
…s-default-RA-type
…nformalsystems/cycles-quartz into dusterbloom/70-DCAP-as-default-RA-type
hu55a1n1
changed the title
|
The CosmWasm unittests are failing because the testdata is not updated for DCAP and still has hardcoded EPID attestations in tests. |
SummarySee #70 (comment) for more details. This PR allows a user to explicitly specify the What's in this PR
Next steps
|
| /// FMSPC (Family-Model-Stepping-Platform-Custom SKU); required if `MOCK_SGX` is not set | ||
| #[arg(long)] | ||
| #[serde(skip_serializing_if = "Option::is_none")] | ||
| pub fmspc: Option<Fmspc>, | ||
|
|
||
| /// Address of the TcbInfo contract | ||
| #[arg(long)] | ||
| #[serde(skip_serializing_if = "Option::is_none")] | ||
| pub tcbinfo_contract: Option<AccountId>, | ||
|
|
||
| /// Address of the DCAP verifier contract | ||
| #[arg(long)] | ||
| #[serde(skip_serializing_if = "Option::is_none")] | ||
| pub dcap_verifier_contract: Option<AccountId>, | ||
|
|
There was a problem hiding this comment.
not in this PR but we should move these into a separate struct that we flatten into whatever command needs them
| "FMSPC is required if MOCK_SGX isn't set".to_string(), | ||
| )); | ||
| }; | ||
|
|
There was a problem hiding this comment.
Can this validation be moved into requests/enclave_start.rs?
There was a problem hiding this comment.
Clap groupings could be useful here also:
https://users.rust-lang.org/t/clap-derive-required-flags-or-options-that-are-exclusive-to-each-other/75998/2
There was a problem hiding this comment.
I thought about putting this into impl TryFrom<EnclaveCommand> for Request, but the problem is that the validation depends on config.mock_sgx which isn't available in the TryFrom. Did you have something else in mind?
|
|
||
| use crate::error::Error; | ||
|
|
||
| #[derive(Debug)] | ||
| pub enum RelayMessage { | ||
| Instantiate, | ||
| Instantiate { init_msg: JsonValue }, |
There was a problem hiding this comment.
Just curious behind the motivation for having a struct vs attaching data to the enum?
There was a problem hiding this comment.
I think I prefer attaching data like this when the enum variant is not used elsewhere in code (as a separate type or if there isn't more validation for the inner type/fields, etc.). Not sure what's the best practice here. :)
| @@ -22,6 +22,9 @@ loader.env.QUARTZ_PORT = { passthrough = true } | |||
|
|
|||
| loader.argv = ["enclave", | |||
| "--chain-id", "testing", | |||
| "--fmspc", "{{ fmspc }}", | |||
| "--tcbinfo-contract", "{{ tcbinfo_contract }}", | |||
|
Will merge this now to unblock development and follow-up with Andrew regarding questions on handling security advisories, etc. |
|
bye bye 102 commit pr.. you will not be missed! |
Closes: #70