Support raw sends of encrypted datasets

[aarononeal]

An additional 'on|off' parameter can now be set on a destination to indicate that a 'raw' send should be used to transmit an encrypted dataset. This is useful for remote backup scenarios to an untrusted destination since data is not decrypted before transmitting. Unlike unencrypted datasets, the destination dataset must not exist prior to the initial send, so this commit also disables such checks when raw send is enabled.

[coveralls]

Coverage decreased (-0.2%) to 86.969% when pulling ac7995cc75162a8e8aca12064465710c744f22a1 on aarononeal:feature/raw into 1d266cf24eee397f9a792b8ccd7fbd1ee8ed79e5 on oetiker:master.

[coveralls]

Coverage decreased (-0.2%) to 86.969% when pulling 54358b803943d64fd380615f4f80b9af9158540a on aarononeal:feature/raw into 1d266cf24eee397f9a792b8ccd7fbd1ee8ed79e5 on oetiker:master.

[coveralls]

Coverage decreased (-0.2%) to 86.969% when pulling 54358b803943d64fd380615f4f80b9af9158540a on aarononeal:feature/raw into 1d266cf24eee397f9a792b8ccd7fbd1ee8ed79e5 on oetiker:master.

[oetiker]

could you add a bit more documentation about the purpose of the raw switch ?

[oetiker]

reading your PR I get the impression that [raw] is not really optional ... and would break existing syntax

[aarononeal]

I can revise the PR if you can suggest a preferred way to make the syntax optional. Easiest fix may be to move it after post-command.

[aarononeal]

I just pushed an update that moves raw to the end and adds a doc entry.

[oetiker]

I think we have API design issue here ... positional arguments in this structure are not really sustainable if more of them come. I would suggest the following:

only mandatory arguments are positional (plus the two optional ones added earlier for backward compatibility).

all optional argument follow the classic cli design principle where optional argument are written as --key[=value] so the syntax would look like this:

[ DST[:key] plan [[user@]host:]dataset [--pre-send-command=cmd] [--post-send-command=cmd] [--raw]

the optional arguments can appear in any order AFTER the DST: argument.

@hadfl what do you think?

[aarononeal]

I prefer that approach but am not familiar with how to modify that option parsing code.

On a related note, I think recvu might also have made a good option as it seems something destination specific.

[tgerczei]

Could this one be revived? I'd have use for this feature.

[oetiker]

I think we got this now