recaptime.dev
@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
1@title Permanently Destroying Data
2@group fieldmanual
3
4How to permanently destroy data and manage leaked secrets.
5
6Overview
7========
8
9Phorge intentionally makes it difficult to permanently destroy data, but
10provides a command-line tool for destroying objects if you're certain that
11you want to destroy something.
12
13**Disable vs Destroy**: Most kinds of objects can be disabled, deactivated,
14closed, or archived. These operations place them in inactive states and
15preserve their transaction history.
16
17(NOTE) Disabling (rather than destroying) objects is strongly recommended
18unless you have a very good reason to want to permanently destroy an object.
19
20
21Destroying Data
22===============
23
24To permanently destroy an object, run this command from the command line:
25
26```
27phorge/ $ ./bin/remove destroy <object>
28```
29
30The `<object>` may be an object monogram or PHID. For instance, you can use
31`@alice` to destroy a particular user, or `T123` to destroy a particular task.
32
33(IMPORTANT) This operation is permanent and can not be undone.
34
35
36CLI Access Required
37===================
38
39In almost all cases, Phorge requires operational access from the CLI to
40permanently destroy data. One major reason for this requirement is that it
41limits the reach of an attacker who compromises a privileged account.
42
43The web UI is generally append-only and actions generally leave an audit
44trail, usually in the transaction log. Thus, an attacker who compromises an
45account but only gains access to the web UI usually can not do much permanent
46damage and usually can not hide their actions or cover their tracks.
47
48Another reason that destroying data is hard is simply that it's permanent and
49can not be undone, so there's no way to recover from mistakes.
50
51
52Leaked Secrets
53==============
54
55Sometimes you may want to destroy an object because it has leaked a secret,
56like an API key or another credential. For example, an engineer might
57accidentally send a change for review which includes a sensitive private key.
58
59No Phorge command can rewind time, and once data is written to Phorge
60the cat is often out of the bag: it has often been transmitted to external
61systems which Phorge can not interact with via email, webhooks, API calls,
62repository mirroring, CDN caching, and so on. You can try to clean up the mess,
63but you're generally already too late.
64
65The `bin/remove destroy` command will make a reasonable attempt to completely
66destroy objects, but this is just an attempt. It can not unsend email or uncall
67the API, and no command can rewind time and undo a leak.
68
69**Revoking Credentials**: If Phorge credentials were accidentally
70disclosed, you can revoke them so they no longer function. See
71@{article:Revoking Credentials} for more information.
72
73
74Preventing Leaks
75================
76
77Because time can not be rewound, it is best to prevent sensitive data from
78leaking in the first place. Phorge supports some technical measures that
79can make it more difficult to accidentally disclose secrets:
80
81**Differential Diff Herald Rules**: You can write "Differential Diff" rules
82in Herald that reject diffs before they are written to disk by using the
83"Block diff with message" action.
84
85These rules can reject diffs based on affected file names or file content.
86This is a coarse tool, but rejecting diffs which contain strings like
87`BEGIN RSA PRIVATE KEY` may make it more difficult to accidentally disclose
88certain secrets.
89
90**Commit Content Herald Rules**: For hosted repositories, you can write
91"Commit Hook: Commit Content" rules in Herald which reject pushes that contain
92commit which match certain rules (like file name or file content rules).