You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using an instance of Veraison running on Linaro infrastructure, and available publicly at the base URL http://veraison.test.linaro.org:8080.
Commit level at date of reporting should be this one.
Does this issue reproduce with the latest release?
Yes
What OS and CPU architecture are you using (go env)?
I am not able to report this because I am not running my own instance of the service.
What did you do?
I used the Linaro-provided Veraison verification instance, which has been provisioned with endorsements and RVs for the CCA software models (which use a well-known token).
I submitted this token for verification and visually inspected the attestation result.
If you wish, for convenience, you can automate the repro by building and running this example Rust program, which you can run on the command-line without any arguments. It will submit the correct token to the Linaro-provided verifier and provide a summary of the returned AR.
What did you expect to see?
My initial expectation was for the AR to contain a single submodule for CCA_SSD_PLATFORM and a status tier of Affirming. This was previous behaviour.
What did you see instead?
The AR contained two submodules, one for CCA_SSD_PLATFORM with a status of Affirming as expected, but there was also another submodule for CCA_REALM with a status of Warning.
The presence of the second submodule for CCA_REALM is a feature, not a bug. This is due to recent work in the CCA plug-in to support the realm token.
However, the status of Warning does not appear to be the most appropriate. The Linaro verifier does not have any RVs for the realm token. This evaluation should have been skipped entirely with a consequent AR4SI tier value of None for this submodule.
The text was updated successfully, but these errors were encountered:
and I think you are right, since no realm reference values are provisioned, there is no good reason for the CCA_REALM appraisal to state a warning(33) in the executables bucket. It should just say "I can't tell", i.e., 0.
Do not return an overall warning status if no realm reference values have been
provisioned. Instead, return "no claims".
Fix#265
Signed-off-by: Thomas Fossati <[email protected]>
What version of the package are you using?
I am using an instance of Veraison running on Linaro infrastructure, and available publicly at the base URL
http://veraison.test.linaro.org:8080
.Commit level at date of reporting should be this one.
Does this issue reproduce with the latest release?
Yes
What OS and CPU architecture are you using (
go env
)?I am not able to report this because I am not running my own instance of the service.
What did you do?
I used the Linaro-provided Veraison verification instance, which has been provisioned with endorsements and RVs for the CCA software models (which use a well-known token).
I submitted this token for verification and visually inspected the attestation result.
If you wish, for convenience, you can automate the repro by building and running this example Rust program, which you can run on the command-line without any arguments. It will submit the correct token to the Linaro-provided verifier and provide a summary of the returned AR.
What did you expect to see?
My initial expectation was for the AR to contain a single submodule for
CCA_SSD_PLATFORM
and a status tier ofAffirming
. This was previous behaviour.What did you see instead?
The AR contained two submodules, one for
CCA_SSD_PLATFORM
with a status ofAffirming
as expected, but there was also another submodule forCCA_REALM
with a status ofWarning
.The presence of the second submodule for
CCA_REALM
is a feature, not a bug. This is due to recent work in the CCA plug-in to support the realm token.However, the status of
Warning
does not appear to be the most appropriate. The Linaro verifier does not have any RVs for the realm token. This evaluation should have been skipped entirely with a consequent AR4SI tier value ofNone
for this submodule.The text was updated successfully, but these errors were encountered: