Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish stable checkpoint periodically to Redis #1461

Merged
merged 8 commits into from
May 14, 2023

Conversation

haydentherapper
Copy link
Contributor

Currently, a log witness countersigns the latest checkpoint Rekor publishes. Rekor updates its checkpoint on every entry upload, which is extremely frequent. This means that two witnesses are very unlikely to countersign the same checkpoint. While gossiping, it will not be possible to reach a consensus on the same checkpoint, and therefore we can't mitigate split-view attacks.

This change publishes a checkpoint, a "stable checkpoint", every 5 minutes (configurable) to Redis. This runs as a goroutine, with a Redis key derived from the current time rounded to the nearest 5 minutes. We use set-if-not-exist for Redis, meaning you can run replicated instances of Rekor, with all instances writing to the same Redis key.

For a client that wants to gossip, this means waiting 5 minutes before a checkpoint is published that witnesses will countersign (Note that this is an area of active development and research too). The stable checkpoint can be accessed with a query parameter.

Fixes #1067. There is still value in batching in terms of reliablity, but stable checkpoints solve the gossiping issue without a breaking change.

Summary

Release Note

Documentation

@haydentherapper haydentherapper requested a review from a team as a code owner May 2, 2023 19:59
@haydentherapper haydentherapper marked this pull request as draft May 2, 2023 19:59
@haydentherapper
Copy link
Contributor Author

@bobcallaway @asraa @jiggoha @mhutchinson @AlCutter Looking for early feedback on the implementation while I'm writing tests

pkg/api/tlog.go Outdated Show resolved Hide resolved
@codecov
Copy link

codecov bot commented May 2, 2023

Codecov Report

Merging #1461 (2112494) into main (35f0081) will decrease coverage by 19.31%.
The diff coverage is 63.19%.

@@             Coverage Diff             @@
##             main    #1461       +/-   ##
===========================================
- Coverage   64.33%   45.03%   -19.31%     
===========================================
  Files          80       72        -8     
  Lines        7789     7208      -581     
===========================================
- Hits         5011     3246     -1765     
- Misses       2129     3622     +1493     
+ Partials      649      340      -309     
Flag Coverage Δ
e2etests ?
unittests 45.03% <63.19%> (+0.37%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
pkg/api/api.go 0.00% <0.00%> (-68.24%) ⬇️
pkg/api/metrics.go 0.00% <ø> (-100.00%) ⬇️
pkg/api/tlog.go 0.00% <0.00%> (-39.03%) ⬇️
pkg/witness/publish_checkpoint.go 89.21% <89.21%> (ø)

... and 53 files with indirect coverage changes

@haydentherapper haydentherapper marked this pull request as ready for review May 2, 2023 22:44
Currently, a log witness countersigns the latest checkpoint Rekor
publishes. Rekor updates its checkpoint on every entry upload, which is
extremely frequent. This means that two witnesses are very unlikely to
countersign the same checkpoint. While gossiping, it will not be
possible to reach a consensus on the same checkpoint, and therefore we
can't mitigate split-view attacks.

This change publishes a checkpoint, a "stable checkpoint", every 5
minutes (configurable) to Redis. This runs as a goroutine, with a Redis
key derived from the current time rounded to the nearest 5 minutes.
We use set-if-not-exist for Redis, meaning you can run replicated instances of
Rekor, with all instances writing to the same Redis key.

For a client that wants to gossip, this means waiting 5 minutes before
a checkpoint is published that witnesses will countersign (Note that
this is an area of active development and research too).
The stable checkpoint can be accessed with a query parameter.

Fixes sigstore#1067. There is still
value in batching in terms of reliablity, but stable checkpoints
solve the gossiping issue without a breaking change.

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
@haydentherapper haydentherapper force-pushed the stable-checkpoint-etcd branch from 465a0e8 to 496d42f Compare May 9, 2023 21:50
pkg/api/tlog.go Outdated Show resolved Hide resolved
pkg/api/tlog.go Show resolved Hide resolved
pkg/witness/publish_checkpoint.go Outdated Show resolved Hide resolved
pkg/witness/publish_checkpoint.go Show resolved Hide resolved
haydentherapper and others added 3 commits May 10, 2023 14:28
Co-authored-by: Bob Callaway <bobcallaway@users.noreply.github.com>
Signed-off-by: Hayden B <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
@bobcallaway bobcallaway merged commit f69698a into sigstore:main May 14, 2023
@github-actions github-actions bot added this to the v1.1.0 milestone May 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Correctness issue: Change to batched entry upload to support witnessing
2 participants