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

consider removing Redis key cache #7027

Open
cfm opened this issue Oct 26, 2023 · 1 comment
Open

consider removing Redis key cache #7027

cfm opened this issue Oct 26, 2023 · 1 comment

Comments

@cfm
Copy link
Member

cfm commented Oct 26, 2023

Description

After #6399, looking up a key is no longer an operation against GnuPG's keyring; it's just another SQLite query. Do we still need to cache key lookups at all?

How will this impact SecureDrop users?

It should not result in a performance hit of the sort that #5184 was implemented to eliminate. We should investigate what happens with instances in various degrees of migration from GnuPG to Sequoia backing.

How would this affect SecureDrop's threat model?

Less code, fewer bugs. Fewer services and dependencies, fewer vulnerabilities.

User Stories

As a contrarian, I want to violate the fundamental theorem of software engineering whenever possible.

@cfm
Copy link
Member Author

cfm commented Nov 1, 2023

Mental-model update from #7055: In the course of consolidating two key-related datastores (GPG keyring + SQLite database) into one (database), #6399 actually gives us three (GPG keyring + Redis cache + SQLite database), with more possible interactions and states to reason about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants