mirrors/hockeypuck
1
0
Fork 0
mirror of https://github.com/hockeypuck/hockeypuck.git synced 2025-12-17 08:55:43 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
Page: HIP 011: Merge ptree into pghkp
Pages
HIP 000: Hockeypuck Improvement Proposals HIP 001: [REVERTED] Regaining control over public key identity with authenticated key management HIP 002: SKS v2 protocol HIP 003: Timestamp aware merge strategy HIP 004: Third party revocation sig distribution HIP 005: Reliable personal data deletion using self signatures HIP 006: WKD support HIP 007: Recursive resolver HIP 008: Out of Band Email Ownership Proof HIP 009: Management Interface HIP 010: Internal rate limiting support HIP 011: Merge ptree into pghkp HIP 012: Define and use JSON‐LD schemas HIP 013: In‐Band Metadata Sync Using Trust Packets Home Migrating from SKS‐keyserver to Hockeypuck Semantic Versioning Policy Upgrading docker‐compose standalone deployment from 2.1 to 2.2
HIP 011: Merge ptree into pghkp
Andrew Gallagher edited this page 2025-03-28 15:47:01 +00:00
Table of Contents

See also https://github.com/hockeypuck/hockeypuck/issues/381

Motivation

There are ongoing issues with index consistency due to the dual-database structure of the SKS protocol. While these should be mitigated at runtime, in particular using writebacks, it would be more robust to unify the databases so that updates could be guaranteed transaction safe. It would also make it possible to run multiple hockeypuck front ends against a common database.

Design

The ptree could be stored in a postgres table, and updates to the ptree table would be performed as part of the same transaction as the (sub)key tables. Since this involves updates in-place, many potential issues could arise:

  • Transactions might fail because of simultaneous updates to rows in the ptree table
  • Bulk updates would need to be handled gracefully
  • Performance may be adversely impacted

Due to the tight inner loops and updates in-place required, it would be preferable to implement the ptree at the lowest level possible. This may involve stored procedures or even a native postgres plugin.

Out of scope

Security considerations

There are no known direct security implications, however transaction consistency will automatically improve the security properties of the software.

Compatibility

Postgres schema migrations may be required (https://github.com/hockeypuck/hockeypuck/issues/252)

Plan