Change Details

`gpg` lets the user use policy compliance options like `--rfc4880` or `--rfc2440` or `--openpgp` or `--compliance de-vs`. the documentation claims that "Only one of these options may be active at a time." but the tool itself lets the user specify multiple options, like so without complaint: ``` gpg --policy de-vs --policy gnupg --decrypt ``` In addition to setting cryptographic and wire format policies, these choices also adjust parameter decisions, like the default cipher used with s2k (which can also be set with `--s2k-digest`), whether to strip trailing whitespace when making a canonical text document signature without using the CSF (`--rfc2440-text`), or whether to require a cross-certification (`--require-cross-certification`). However, it's unpredictable which of these various policies and configuration choices take effect when two of them are in conflict, and `gpg` doesn't warn the user when a conflict arises. For example, when making canonical text signatures over data that has trailing whitespace, these commands will all strip the trailing whitespace: ``` gpg --text --armor --rfc2440-text --sign gpg --text --armor --rfc2440 --sign gpg --text --armor --rfc4880 --rfc2440 --sign gpg --text --armor --gnupg --rfc2440 --sign gpg --text --armor --rfc2440 --gnupg --sign ``` while these commands will *not* strip the trailing whitespace: ``` gpg --text --armor --sign gpg --text --armor --rfc4880 --sign gpg --text --armor --gnupg --sign gpg --text --armor --rfc2440 --rfc4880 --sign ``` That is, `--gnupg` does *not* override `--rfc2440` when it follows it, but `--rfc4880` *does* override `--rfc2440` when it follows it. Similarly, the default symmetric cipher and hash used for symmetric encryption interact strangely with the order of different options. One part of this appears to be that `--gnupg` (and its synonym `--compliance=gnupg`, as well as distinct options `--pgp7` and `--pgp8`) only set `opt.compliance` and don't update any of the more granular `opts` fields directly, in theory leaving the rest of `opt` set to the default values set at the top of `main()`. But if one of the other options that sets granular `opts` fields is invoked first, then `--compliance=gnupg` cannot restore those choices to their prior defaults. And, then again, there are some granular `opts` fields that are never touched by any of these "compliance" options. At the very least, it seems like `gpg` should warn the user when two incompatible `--compliance` options are in effect at the same time.

`gpg` lets the user use policy compliance options like `--rfc4880` or `--rfc2440` or `--openpgp` or `--compliance de-vs`. the documentation claims that "Only one of these options may be active at a time." but the tool itself lets the user specify multiple options, like so without complaint: ``` gpg --compliance de-vs --compliance gnupg --decrypt ``` In addition to setting cryptographic and wire format policies, these choices also adjust parameter decisions, like the default cipher used with s2k (which can also be set with `--s2k-digest`), whether to strip trailing whitespace when making a canonical text document signature without using the CSF (`--rfc2440-text`), or whether to require a cross-certification (`--require-cross-certification`). However, it's unpredictable which of these various policies and configuration choices take effect when two of them are in conflict, and `gpg` doesn't warn the user when a conflict arises. For example, when making canonical text signatures over data that has trailing whitespace, these commands will all strip the trailing whitespace: ``` gpg --text --armor --rfc2440-text --sign gpg --text --armor --rfc2440 --sign gpg --text --armor --rfc4880 --rfc2440 --sign gpg --text --armor --gnupg --rfc2440 --sign gpg --text --armor --rfc2440 --gnupg --sign ``` while these commands will *not* strip the trailing whitespace: ``` gpg --text --armor --sign gpg --text --armor --rfc4880 --sign gpg --text --armor --gnupg --sign gpg --text --armor --rfc2440 --rfc4880 --sign ``` That is, `--gnupg` does *not* override `--rfc2440` when it follows it, but `--rfc4880` *does* override `--rfc2440` when it follows it. Similarly, the default symmetric cipher and hash used for symmetric encryption interact strangely with the order of different options. One part of this appears to be that `--gnupg` (and its synonym `--compliance=gnupg`, as well as distinct options `--pgp7` and `--pgp8`) only set `opt.compliance` and don't update any of the more granular `opts` fields directly, in theory leaving the rest of `opt` set to the default values set at the top of `main()`. But if one of the other options that sets granular `opts` fields is invoked first, then `--compliance=gnupg` cannot restore those choices to their prior defaults. And, then again, there are some granular `opts` fields that are never touched by any of these "compliance" options. At the very least, it seems like `gpg` should warn the user when two incompatible `--compliance` options are in effect at the same time.

`gpg` lets the user use policy compliance options like `--rfc4880` or `--rfc2440` or `--openpgp` or `--compliance de-vs`. the documentation claims that "Only one of these options may be active at a time." but the tool itself lets the user specify multiple options, like so without complaint: ``` gpg --policycompliance de-vs --policycompliance gnupg --decrypt ``` In addition to setting cryptographic and wire format policies, these choices also adjust parameter decisions, like the default cipher used with s2k (which can also be set with `--s2k-digest`), whether to strip trailing whitespace when making a canonical text document signature without using the CSF (`--rfc2440-text`), or whether to require a cross-certification (`--require-cross-certification`). However, it's unpredictable which of these various policies and configuration choices take effect when two of them are in conflict, and `gpg` doesn't warn the user when a conflict arises. For example, when making canonical text signatures over data that has trailing whitespace, these commands will all strip the trailing whitespace: ``` gpg --text --armor --rfc2440-text --sign gpg --text --armor --rfc2440 --sign gpg --text --armor --rfc4880 --rfc2440 --sign gpg --text --armor --gnupg --rfc2440 --sign gpg --text --armor --rfc2440 --gnupg --sign ``` while these commands will *not* strip the trailing whitespace: ``` gpg --text --armor --sign gpg --text --armor --rfc4880 --sign gpg --text --armor --gnupg --sign gpg --text --armor --rfc2440 --rfc4880 --sign ``` That is, `--gnupg` does *not* override `--rfc2440` when it follows it, but `--rfc4880` *does* override `--rfc2440` when it follows it. Similarly, the default symmetric cipher and hash used for symmetric encryption interact strangely with the order of different options. One part of this appears to be that `--gnupg` (and its synonym `--compliance=gnupg`, as well as distinct options `--pgp7` and `--pgp8`) only set `opt.compliance` and don't update any of the more granular `opts` fields directly, in theory leaving the rest of `opt` set to the default values set at the top of `main()`. But if one of the other options that sets granular `opts` fields is invoked first, then `--compliance=gnupg` cannot restore those choices to their prior defaults. And, then again, there are some granular `opts` fields that are never touched by any of these "compliance" options. At the very least, it seems like `gpg` should warn the user when two incompatible `--compliance` options are in effect at the same time.