freedomofpress
consider removing Redis key cache
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.
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.