Permanently Destroying DataPhorge Administrator and User Documentation (Field Manuals)
How to permanently destroy data and manage leaked secrets.
Overview
Phorge intentionally makes it difficult to permanently destroy data, but provides a command-line tool for destroying objects if you're certain that you want to destroy something.
Disable vs Destroy: Most kinds of objects can be disabled, deactivated, closed, or archived. These operations place them in inactive states and preserve their transaction history.
Destroying Data
To permanently destroy an object, run this command from the command line:
phorge/ $ ./bin/remove destroy <object>The <object> may be an object monogram or PHID. For instance, you can use @alice to destroy a particular user, or T123 to destroy a particular task.
CLI Access Required
In almost all cases, Phorge requires operational access from the CLI to permanently destroy data. One major reason for this requirement is that it limits the reach of an attacker who compromises a privileged account.
The web UI is generally append-only and actions generally leave an audit trail, usually in the transaction log. Thus, an attacker who compromises an account but only gains access to the web UI usually can not do much permanent damage and usually can not hide their actions or cover their tracks.
Another reason that destroying data is hard is simply that it's permanent and can not be undone, so there's no way to recover from mistakes.
Leaked Secrets
Sometimes you may want to destroy an object because it has leaked a secret, like an API key or another credential. For example, an engineer might accidentally send a change for review which includes a sensitive private key.
No Phorge command can rewind time, and once data is written to Phorge the cat is often out of the bag: it has often been transmitted to external systems which Phorge can not interact with via email, webhooks, API calls, repository mirroring, CDN caching, and so on. You can try to clean up the mess, but you're generally already too late.
The bin/remove destroy command will make a reasonable attempt to completely destroy objects, but this is just an attempt. It can not unsend email or uncall the API, and no command can rewind time and undo a leak.
Revoking Credentials: If Phorge credentials were accidentally disclosed, you can revoke them so they no longer function. See Revoking Credentials for more information.
Preventing Leaks
Because time can not be rewound, it is best to prevent sensitive data from leaking in the first place. Phorge supports some technical measures that can make it more difficult to accidentally disclose secrets:
Differential Diff Herald Rules: You can write "Differential Diff" rules in Herald that reject diffs before they are written to disk by using the "Block diff with message" action.
These rules can reject diffs based on affected file names or file content. This is a coarse tool, but rejecting diffs which contain strings like BEGIN RSA PRIVATE KEY may make it more difficult to accidentally disclose certain secrets.
Commit Content Herald Rules: For hosted repositories, you can write "Commit Hook: Commit Content" rules in Herald which reject pushes that contain commit which match certain rules (like file name or file content rules).