HomePhorge
Diffusion Phorge (master) Code

phorge/src/docs/user/field/permanently_destroying_data.diviner
1fe631116771master

Last Change
Raw File

permanently_destroying_data.diviner
View Options

@title Permanently Destroying Data
@group fieldmanual
How to permanently destroy data and manage leaked secrets.
Overview
========
Phabricator 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.
(NOTE) Disabling (rather than destroying) objects is strongly recommended
unless you have a very good reason to want to permanently destroy an object.
Destroying Data
===============
To permanently destroy an object, run this command from the command line:
```
phabricator/ $ ./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.
(IMPORTANT) This operation is permanent and can not be undone.
CLI Access Required
===================
In almost all cases, Phabricator 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 Phabricator command can rewind time, and once data is written to Phabricator
the cat is often out of the bag: it has often been transmitted to external
systems which Phabricator 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 Phabricator credentials were accidentally
disclosed, you can revoke them so they no longer function. See
@{article: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. Phabricator 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).

Owner Packages

  • No Owners