On Sat, Sep 29, 2018 at 11:42:40AM -0400, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * David Hedberg (david.hedberg@gmail.com) wrote:
> >> The idea is to add a --pipe option to pg_dump / pg_restore where
> >> you can specify a custom shell command that is used to write /
> >> read each .dat-file. Usage examples include encryption with pgp
> >> and/or custom compression pipelines. %p in the command is
> >> expanded to the path to write to / read from. The pipe command is
> >> not applied to the toc.
>
> > I would certainly think that we'd want to have support for custom
> > format dumps too..
>
> This seems like rather a kluge :-(. In the context of encrypted
> dumps in particular, I see no really safe way to pass an encryption
> key down to the custom command --- either you put it in the command
> line to be exec'd, or you put it in the process environment, and
> neither of those are secure on all platforms.
As I understand it, those are the options for providing secrets in
general. At least in the case of encryption, one good solution would
be to use an asymmetric encryption scheme, i.e. one where encrypting
doesn't expose a secret in any way.
As to decryption, that's generally done with more caution in
environments where things are being routinely encrypted in the first
place.
> The assumption that the TOC doesn't need encryption seems pretty
> shaky as well.
That it does.
> So I think we'd be better off proceeding as Stephen envisions.
> Maybe there are use-cases for the sort of thing David is proposing,
> but I don't think encrypted dumps present a good argument for it.
Dumping over a network seems like a reasonable use case for this. I
know that we have remote ways to do this, but in some
environments--think FedRAMP, or similar compliance regime--setting up
a remote access to do the dump can cause extra headaches. Being able
to encrypt them in the process would be helpful in situations I've
seen in the past week.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate