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

RSTUF initial implementation #4167

Merged
merged 9 commits into from
Feb 18, 2024
Merged

RSTUF initial implementation #4167

merged 9 commits into from
Feb 18, 2024

Conversation

simi
Copy link
Member

@simi simi commented Oct 31, 2023

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

  • How to set retry mechanism for waiting unless remote job finishes?
  • How to handle failed remote jobs?

@codecov
Copy link

codecov bot commented Oct 31, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (150005e) 97.13% compared to head (135b9e9) 97.15%.

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.
📢 Have feedback on the report? Share it here.

@simi simi requested review from segiddins, martinemde and indirect and removed request for segiddins and martinemde October 31, 2023 10:54
app/jobs/rstuf/check_job.rb Outdated Show resolved Hide resolved
app/jobs/rstuf/check_job.rb Outdated Show resolved Hide resolved
@segiddins
Copy link
Member

The RSTUF idea is simple, call add endpoint when package is added to index and call remove endpoint when package is removed.

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

@simi
Copy link
Member Author

simi commented Oct 31, 2023

The RSTUF idea is simple, call add endpoint when package is added to index and call remove endpoint when package is removed.

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/.

Copy link
Member

@martinemde martinemde left a 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/application_job.rb Show resolved Hide resolved
when "SUCCESS"
# no-op, all good
when "FAILURE"
raise FailureException, "RSTUF job failed"
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member

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

Copy link
Member Author

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/models/deletion.rb Outdated Show resolved Hide resolved
app/models/deletion.rb Outdated Show resolved Hide resolved
lib/rstuf.rb Show resolved Hide resolved
lib/rstuf.rb Show resolved Hide resolved
lib/rstuf/client.rb Show resolved Hide resolved
app/jobs/rstuf/add_job.rb Show resolved Hide resolved
app/jobs/rstuf/check_job.rb Show resolved Hide resolved
test/models/deletion_test.rb Outdated Show resolved Hide resolved
test/models/pusher_test.rb Outdated Show resolved Hide resolved
when "SUCCESS"
# no-op, all good
when "FAILURE"
raise FailureException, "RSTUF job failed"
Copy link
Member

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

config/initializers/rstuf.rb Outdated Show resolved Hide resolved
@simi
Copy link
Member Author

simi commented Nov 13, 2023

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.

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.

Copy link
Contributor

@kairoaraujo kairoaraujo left a 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.

lib/rstuf/client.rb Outdated Show resolved Hide resolved
app/jobs/rstuf/check_job.rb Outdated Show resolved Hide resolved
app/jobs/rstuf/check_job.rb Show resolved Hide resolved
@simi
Copy link
Member Author

simi commented Jan 31, 2024

ℹ️ This needs changes from repository-service-tuf/repository-service-tuf-api#518 applied. I'm on it.

Copy link
Member

@segiddins segiddins left a 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

lib/rstuf/client.rb Outdated Show resolved Hide resolved
Copy link
Member

@indirect indirect left a 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. 👍🏻

@simi
Copy link
Member Author

simi commented Jan 31, 2024

@kairoaraujo would you mind to do last check for state handling?
@segiddins logger updated.
@indirect indeed this is just beginning, we will explore over time what and how to store in RSTUF.

@simi simi requested review from kairoaraujo and segiddins January 31, 2024 21:06
@kairoaraujo
Copy link
Contributor

kairoaraujo commented Feb 1, 2024

@kairoaraujo would you mind to do last check for state handling?

Yes, LGTM @simi

Copy link
Contributor

@kairoaraujo kairoaraujo left a 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! 🎉

@simi
Copy link
Member Author

simi commented Feb 18, 2024

@martinemde @indirect @segiddins I have added short info in CONTRIBUTING.md. From my side this is ready for merge.

Copy link
Member

@martinemde martinemde left a 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!

test/unit/rstuf/client_test.rb Outdated Show resolved Hide resolved
@simi simi merged commit b2b787c into master Feb 18, 2024
17 checks passed
@simi simi deleted the rstuf-init branch February 18, 2024 22:34
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.

7 participants