Moving attestation generation and verification code to `attest` repo.
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- cryptography, security
Research direction
Start by reading the attestation crate and the pccs crate in attested-tls, then inspect the not-yet-merged mock-tdx crate and the linked attest repository. Clarify whether the crates should move to attest or whether everything should move into attested-tls, including how generation and verification are organized. Done means the repository layout and ownership decision are agreed and the relevant crates have been moved consistently.
Written by the indexing model from the issue text.
Description
@alexhulbert has started https://github.com/flashbots/attest which can compute measurements from an OS image together with CVM configuration.
The idea is that CVM configuration data would be sent as part of the attestation evidence payload, and a verifier would use it to compute the expected measurements for that particular instance. Eg: for GCP we would probably include the machine type and region. This would save us needing to have pre-computed measurement values for every combination of accepted OS image version and CVM configuration.
Since this involves both generation and verification, the proposal is to move the contents of the attestation crate over to that repo.
If doing that, it would probably also make sense to move the pccs crate and not-yet-merged mock-tdx crate there as well, as i think they belong together with attestation rather than attested-tls.
The alternative would be to do it the other way around and move everything into this repo.
Tagging @0x416e746f6e as you were not around when we were talking about this last week.
- Dominant language
- Rust
- Stars
- 6
- Forks
- 3
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 3
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from flashbots/attested-tls
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
flashbots/attested-tls#97 ·
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
flashbots/attested-tls#92 · 4 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
flashbots/attested-tls#87 · 1 comment ·
-
Allow verification at an explicit timestamp, and report which collateral was usedMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 45/100
flashbots/attested-tls#84 · 7 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
flashbots/attested-tls#82 · 1 comment ·
All issues in flashbots/attested-tls
Similar issues
-
contribution
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
tree-sitter/tree-sitter#6005 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
agent:triaged bug bughunt pm:pipenv priority:p1
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
SocketDev/socket-patch#744 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
maplibre/maplibre-tile-spec#1844 ·
Maintainers usually reply within 1 day