Hello. On this website
(http://www.gnupg.org/faq/GnuPG-FAQ.html#how-can-i-get-list-of-key-ids-used-
to-encrypt-a-message) I found this FAQ and answer:
Question: How can I get list of key IDs used to encrypt a message?
$ gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | \
awk '/^\[
Am Dienstag, 1. November 2011, 00:04:19 schrieb Veet Vivarto:
> Someone may encrypt the message to me and to 10 other recipients, I would
> like to know who they are.
>
> Is there a command line option for displaying all recipients to whom
> the message was encrypted.
--list-packets
In case the
Someone may encrypt the message to me and to 10 other recipients, I would
like to know who they are.
Is there a command line option for displaying all recipients to whom
the message was encrypted.
Thank you in advance for your help.
Vivarto
___
Gnupg-use
On Mon, 31 Oct 2011 16:40, melvincarva...@gmail.com said:
> http://www.w3.org/TR/xmldsig-core/
Let me quote Peter Gutmann's take on this:
This writeup was motivated by the following exchange on a mailing list:
>>I have some questions related to XML-Dsig:
>
>Argghh!! Run away!
Thanks for the explanation, Werner.
-Jimmy
On Mon, Oct 31, 2011 at 6:22 AM, Werner Koch wrote:
> On Sun, 30 Oct 2011 20:51, cha...@gmail.com said:
> > Despite setting ignore-cache-for-signing on gpg-agent, the
> > key/passphrase appears to be cached when I use gpg to sign files.
>
> Gpg does no
Am Sonntag, 30. Oktober 2011, 05:21:56 schrieb Eric Abrahamsen:
> Is there a general sense that this is viable (at least as viable as
> scanning and emailing contracts that have been signed with a pen)?
I think there are two points:
1) What exactly does a digital signature mean?
2) Can you prov
On 30 October 2011 05:21, Eric Abrahamsen wrote:
> I own a small business that works with contractors all over the world,
> and I'm currently scratching my head over the issue of signing
> contracts. I know that gpg can/has been used to this purpose, but I
> wanted to ask the list's advice. There
I have no experience in this matter, but it's an interesting problem,
so here are my thoughts, whatever they are worth:
When contracting on paper, the signature is a personal characteristic
of the signer, so samples can be compared by an expert witness.
Unless there's some sort of biometric compon
On 31/10/11 11:36, Werner Koch wrote:
> Rfc822 addresses are merely properties of the MAPI message and used if the
> message needs to be send via SMTP; this is done by a transport provider which
> constructs a proper MIME message out of the MAPI message.
Now it all makes sense. Thanks for this ins
Hi,
On Mon, 31 Oct 2011, Werner Koch wrote:
Obviously there are some kludges in the system to allow sending of
signed messages by taking great care not to modify the content.
A remark on these kludges: an S/MIME email from a colleague elsewhere
using Outlook and their Exchange server was stil
Hi,
On Fri, 28 Oct 2011, Jerry wrote:
On Fri, 28 Oct 2011 14:07:53 +0100 (BST) Phil Brooke articulated:
Nothing relating to encrypted data, but I've seen an MS Exchange
system rewrite signed emails (both PGP/MIME and S/MIME) with the
obvious effect of causing failed verifications.
Could you p
On Sat, 29 Oct 2011 14:47, pe...@digitalbrains.com said:
> So I guess I should rephrase my comment as a request: when this behaviour is
> fixed, please fix it for mangling in general and not just this specific
> PGP/MIME
> and S/MIME case :).
You need to know that Exchange is not an RFC822 appli
On Sun, 30 Oct 2011 20:51, cha...@gmail.com said:
> Despite setting ignore-cache-for-signing on gpg-agent, the
> key/passphrase appears to be cached when I use gpg to sign files.
Gpg does not use gpg-agent for private key operations; it only uses
gpg-agent for passphrase caching. It would be pos
On 30/10/11 22:03, Daniel Kahn Gillmor wrote:
> Assuming that standards-based arguments carry any weight at all, you'll
> have a stronger argument if you *do* limit your scope to the
> multipart/signed mime parts:
Would a lawyer perhaps say it as this?
I would like to see no mangling at all. If
14 matches
Mail list logo