-
-
Notifications
You must be signed in to change notification settings - Fork 933
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
RSTUF initial implementation #4167
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4167 +/- ##
==========================================
+ Coverage 97.13% 97.15% +0.02%
==========================================
Files 385 391 +6
Lines 8200 8259 +59
==========================================
+ Hits 7965 8024 +59
Misses 235 235 ☔ View full report in Codecov by Sentry. |
Could you please add (either here or in a doc somewhere) a short description of what RSTUF is, why we/our users should care about it, and how this PR fits into further work? It feels like I'm missing some context here on what the project/big idea is |
Good idea, I'll add also RSTUF.md with short info and also steps how to run with RubyGems.org locally. In short, this is replacement for #626, but instead of implementing whole TUF using RSTUF as self-hosted API based service. And what TUF in context of RubyGems.org is? TUF is additional layer of security to ensure that the gems you download are verified and haven't been tampered with, using cryptographic signatures even if the gem server is compromised. In super short - it is isolated crypto-safe repository of package signatures. It is also initial step for (hopefully following) sigstore implementation. More info at https://blog.sigstore.dev/sigstore-bring-your-own-stuf-with-tuf-40febfd2badd/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I wonder why we are checking the status if we don't store success or failure anywhere. We are either relying on our exception reporting as part of our application data or we are checking the status unnecessarily. If we want to know when it's broken, can we store that in our database somewhere in addition to error reporting.
app/jobs/rstuf/check_job.rb
Outdated
when "SUCCESS" | ||
# no-op, all good | ||
when "FAILURE" | ||
raise FailureException, "RSTUF job failed" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much do we care about this failing? Jobs fail often enough that these might be missed, right? Should we build a different way to record error percentage?
For example, should it make the request and ignore the result, then periodically check for consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure how much to "infect" RubyGems.org with RSTUF. Yes, it is possible to add rstuf_indexed
to Version
model and update in here.
Currently the main idea is to raise exception on problems. If RSTUF is not able to finish the task or task is failing, it would be great to get maintainers notified since it usually means something is wrong with RSTUF.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we maintain the server side? If so, could we just error on the server?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK with using persistent job failures as a signal for ONCALL to investigate, it's a pattern I've used before
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@martinemde plan is to maintain server side (deploy to RubyGems.org cluster). I'll see during deployment how simple that is to track errors in there. I'll definitelly work on improvements in there if needed. But I would like to keep RubyGems.org isolated and raise error if 3rd party app doesn't work. Maybe in the future RSTUF will be maintained by different maintainers.
app/jobs/rstuf/check_job.rb
Outdated
when "SUCCESS" | ||
# no-op, all good | ||
when "FAILURE" | ||
raise FailureException, "RSTUF job failed" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK with using persistent job failures as a signal for ONCALL to investigate, it's a pattern I've used before
This implements only server side of TUF, there is no client support yet. Fail on RSTUF means no problem for gem install for now. We will need to find out meanwhile how to safely operate this before rolling out default TUF check on gem/bundle install, but that is still relatively far away. Consider this PR as initial work for staging or even production testing without affecting gem/bundler clients. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @simi,
I comment about Tasks state
and status
result.
I still want to discuss how we can improve the RSTUF documentation about it.
ℹ️ This needs changes from repository-service-tuf/repository-service-tuf-api#518 applied. I'm on it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻 with some of the existing comments addressed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am happy to move forward with this and see how it is to run in production, as we (over time) expand towards signing more gem data, and reading and verifying the TUF data in the client. 👍🏻
@kairoaraujo would you mind to do last check for state handling? |
Yes, LGTM @simi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RSUF task state handling LGTM! 🎉
@martinemde @indirect @segiddins I have added short info in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's ready too. One minor quibble about the placement of teardown. Looking forward to seeing this!
The RSTUF idea is simple, call add endpoint when package is added to index and call remove endpoint when package is removed.
RSTUF API is async, by calling add/remove endpoints, background job is enqueued on the RSTUF side. That's the reason for CheckJob. It is used later to ensure remote job has finished successfully.
RSTUF is enabled only when
RSTUF_API_URL
ENV variable is set (=> disabled by default). Plan is to deploy RSTUF API just to be accessible by the RubyGems.org app, but not from the outside of K8s cluster. That's RSUF recommendation for now, it is considered internal API and is not meant to be exposed publicly into internet. Next step is to prepare deploy of RSTUF onto staging environment using helm chart.Open questions