You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
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.
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.
The text was updated successfully, but these errors were encountered: