Fix a typo, preventing emails from setting internal encryption header

X-RT-Incoming-Encryption, along with a number of other headers, is
removed from all parts of incoming emails because they are used to
annotate GPG-related properties of the message.  Fix a typo, which
allowed the properly-spelled header to pass through under specific
circumstances.
Remove internal signing and encryption hints from incoming mail

RT uses the existance of the X-RT-Sign and X-RT-Encrypt headers to
decide if the outgoing mails it sends as a result of the transaction
should be signed and/or encrypted.  It standardly inserts these headers
based on checkboxes visable in the web UI; however, it fails to remove
them from incoming mails, allowing external users to create nearly
arbitrary messages signed by the queue's key.
Restrict users to only signing with queue or their own personal keys

While the UI only presents two options for signing, the underlying form
accepted any key ID or email address, and dutifully signed the mail with
the appropriate secret key.  Restrict the accepted values of SignUsing
to the two values that we displayed.
(cherry picked from commit aeaeb9cf58240603bb8a7d6d951518d32e8512a6)

Conflicts:

	share/html/Elements/Crypt/SignEncryptWidget
Don't propose any secret keys to users with no email address

GetKeysForSigning, when called with 'force', returns all keys if no
email address is provided.  This caused users with no email address to
have all secret keys offered to them.  Remove the 'force' to ensure that
empty email address are shown an empty list.
(cherry picked from commit 10e4a18a61b07b505bae8e9ffff65708a97fc659)

Conflicts:

	share/html/Admin/Users/GnuPG.html
Explicitly restrict private keys to ones offered
(cherry picked from commit b32d9f5ffe7b60816942c91a6b7cb62992910369)
Avoid spurious update and warning messages on key update

This avoids an ominous-looking warning about failure to remove the key,
when no key was previously set but no key was newly selected.
(cherry picked from commit cd0235bda39972fabecd837d982dd9f1619296c4)
Require AdminUser to set PGP private key IDs, not merely ModifySelf

Be explicit that modification of the PrivateKey pseudo-column requires
admin rights -- namely, AdminUser, not just ModifySelf.  While the page
that controlls that property is in /Admin/Users/GnuPG.html, accessing
that page requires only the ShowConfigTab right, and modifying the
property on yourself required only ModifySelf.  Combined with the
ability (also granted by ModifySelf) for users to change their own email
addresses, this opened the possibility for users to claim arbitrary
private keys as their own, for use in signing.
(cherry picked from commit 8ce033b38ced865622a2823aa266ae9bbc251811)
Ensure that no --arguments can be snuck to GPG commands as arguments

GnuPG::Interface 0.46 adds code to prefix command_args with a "--" if it
doesn't have one already.  Rather than bump the dependency, explicitly
add the "--" in the two places that we pass in command_args.
(cherry picked from commit 1f213d6989e646e0163c901b0567ba1c94a311a8)

Conflicts:

	lib/RT/Crypt/GnuPG.pm
Refactor shared code controlling if a message will be encrypted or signed
(cherry picked from commit 8f242072bb196e155ec9a5fbbf06bc8a2d3c2813)

Conflicts:

	lib/RT/Interface/Email.pm
Refactor RT::Action::SendEmail->Commit to consolidate RecordOutgoingEmail path

Instead of interweaving the logic around the case where
RecordOutgoingEmail is disabled, resolve that simple case first.
(cherry picked from commit 08555f51ff8a4105aaaf34725d6b8df356203a86)
When creating tickets via the UI, always set signing/encryption headers
(cherry picked from commit e50f6496cfd15a3b9e1e24b67c9b1b721107d6a5)
Escape all arguments passed to /l

Escaping arguments prevents one of the easiest ways to accidentally
write XSS vectors.  For /l calls which pass HTML in their arguments,
/l_unsafe is provided which preserves the previous behaviour.  Note that
the text to be localized itself is not escaped, only the placeholder
values.  Hopefully seeing "unsafe" in the name will also make folks
pause and consider what they're doing.

Partially resolves CVE-2011-2083.
(cherry picked from commit a2a50999aa214fa01bb824d2b6fcec197ec2a8e9)
Differentiate "always sign" from "default to signing when composing"

Signing incorporates two related but distinct concepts: first,
verification that the message was transmitted without corruption
(integrity), and second, proof that the message was indeed sent by the
sender (authentication).

When the "Sign by default" queue option is disabled, the only messages
which are signed are those triggered by an action where the sender has
explicitly checked the "Sign" option.  Consequently, messages which are
not generated via the web UI, such as auto-replies, or requestors'
messages which are forwarded to owners, are not signed.  In this
configuration, the signing conveys authenticity, but does not provide
integrity for all messages..

When the "Sign by default" queue option is enabled, all messages default
to being signed, even ones generated automatically.  Thus, emails from
the requestor (which may have arbitrary content!) will be signed by the
queue's key when redistributed to owners and AdminCcs.  In this
configuration, the signing ensures integrity, but (because signing
happens automatically) means that no authenticity should be attached to
messages thus signed.

Because the simple configuration option fundamentally changed the
meaning of the signature, exchanging integrity for authenticity, with no
warning, alter it to instead provide an additional option ("Sign
auto-generated messages") which takes the burden of this change in
meaning.  Degrade the "Sign by default" option to describing the default
state of the checkbox on the ticket create or reply page.
(cherry picked from commit e3c2880e6526f9c78079df2097483fea30ba910e)
The "Always Sign, even redistributed email" option is now called SignAuto
Stop looking for things in the GnuPG configuration

This restores the behavior that if mail comes in which is "invalid" in
some way that we want to reject, we'll stop gpg/smime processing the
mail after notifying external users of the failure (basically skip the
parts that update X-RT-Incoming-(Signature|Encryption) to record
success).  I'm not sure if that's actually the optimal behavior, but
it's the back-compat behavior.
Let MIME::Head modify the crypt status headers to handle continuations

X-RT-GnuPG-Status and X-RT-SMIME-Status are set to a many-line string
and previously continuations weren't handled properly.

Temporarily letting the inserted headers be modified fixes the known
problem.  If instead we marked the entire entity as modifiable early
after parsing and left it that way, the possibility of unforeseen
breakage would be too high for a stable release series.  It would also
lead to even further deviation of RT's stored message from the original
source message.

Forward ported from commit e6c6ae922252e36b510264472820ea8df72e4b7e.
Merge branch 'security/4.2/signing' into 4.2/smime-v2