Re: [META] The issue of the unwelcome CC (please email me if you receive a CC from me)
On Tue, Jan 31, 2012 at 11:35 AM, Jerry je...@seibercom.net wrote: On Tue, 31 Jan 2012 12:26:07 -0500 Christopher J. Walters articulated: It was my understanding that this bug had been fixed in Thunderbird, but I may be mistaken. I know that in a GNU/Linux user mailing list I have long been signed up for, I will occasionally receive CC's not for replies to my own messages, but for replies where the poster's To: line is to the person to whom they are replying and the message is CC'ed to the list. I have encounter two individuals, not on this list, who also think it is cute to mail a response directly to the OP and then CC the list. Honestly, some people are alive only because it seems cruel to kill a retard. Okay, the harshness of language here has baited me to reply: There's a simple reason people do this, and it's because it is a common choice for large lists, including the Linux family of mailing lists, the Postgres family of mailing lists, and the FreeBSD family of mailing lists, and the GCC mailing lists -- and these are the first four projects I thought of, all of which use the To: OP, CC: The List convention. The common (and entirely valid) use case being that one can filter for mail that is To: them, and not necessarily read *all* mailing list traffic. gnupg-users has a Reply-To convention that is an outlier in that crowd of mailing lists. Were I someone who was expected to respond to mail on this list frequently and the list was of higher volume, I'd find it very frustrating. Nevertheless, it's fine that gnupg-users has its own way of dealing with this, but as long as it is an outlier in this respect, you are going to get the occasional email addressed in this way, from people who otherwise think that somehow the 'reply' fields were actually filled in in error. Also, Message-Id. Getting two copies should be a non-problem. -- fdr ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A usability gap in fingerprint rendering and parsing
On Fri, Jan 6, 2012 at 2:17 AM, Werner Koch w...@gnupg.org wrote: On Fri, 6 Jan 2012 00:12, drfar...@acm.org said: Should that become the default? What's the use of nibbles that cannot No, --with-colons is not for humans. OTOH, humans are not able to properly read and compare 40 digits hex strings without the help of delimiters like spaces. Now, if you want to cut+paste things you need to convert them gpg -er $(echo PASTE-HERE |tr -d ' ') might be a solution. I also prefer to read the whitespace, but in that case --recipient can be taught to ignore whitespace when interpreting a stream of We could make this work but you would need to enclose it in quotes. What a bout a new option to display the fingerprint in a consensed format. For example --fpr instead of --with-fingerprint. By quotes, you mean so bash will pass it as one argv? This is actually the very first thing I tried: I think anyone familiar with the command line will immediately see the spaces and quote it, so one passes: gpg -er 'abcd ef12 ...' People are also used to quoting things like URLs, file names, patterns for grep or sed, and so on. So I think that's a totally acceptable thing...in fact, doing it any other way would seem weird. If that works, it'd be great to avoid any extra options. I also agree that the colon notation is pretty ugly. -- fdr ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A usability gap in fingerprint rendering and parsing
On Fri, Jan 6, 2012 at 5:18 AM, Jerome Baum jer...@jeromebaum.com wrote: Is this necessary for a technical reason? I'm just thinking about the scenario where transmits his human-readable fingerprint in a medium that collapses repeated spaces (think e.g. HTML). If there's no security implication (it's hard for me to imagine, but I'm not very imaginative) I think ignoring whitespace in the beginning and middle of the string makes a lot of sense. I could come up with a couple of more fanciful suggestions (for example: requiring at least a single space between nibbles to help users identify input that is truncated by a byte or two in case of a fudged copy-paste), but they're not nearly as large confusion-eliminators. But enough nit-picking, the complaint to code time was amazing! :) I, too, am amazed! -- fdr ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A usability gap in fingerprint rendering and parsing
On Mon, Jan 2, 2012 at 5:49 PM, Jerome Baum jer...@jeromebaum.com wrote: On 2012-01-03 02:43, Daniel Farina wrote: Thoughts? --with-colons Should that become the default? What's the use of nibbles that cannot be parsed by --recipient? I also prefer to read the whitespace, but in that case --recipient can be taught to ignore whitespace when interpreting a stream of hexadecimal. -- fdr ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
A usability gap in fingerprint rendering and parsing
Hello list, I was recently trying to encrypt a payload using fingerprints in my keyring to most unambiguously identify a key, when I encountered the following confusion. After giving up trying to find resolution via search engine I played with it a bit more I got it to work, but the head-scratching is, I think, unnecessary. Here's what I did: gpg --list-keys --fingerprint In the output is a line like: Key fingerprint = 560D 1AD1 81D9 81C2 D5D1 005F 10CA 1074 B50F 855E However, one cannot paste that string into gpg --encrypt --recipient, getting the no public key message, as one might expect. One can after removing the spaces, however. Two of the more obvious solution categories include: * Removing the otherwise helpful padding in the spaces between nibbles and decabytes * Expanding --recipient parsing code to accept this format Stepping back a bit, software and users that want to deal in fingerprints might be very different than software and users who want to deal in short ids and email addresses, and it might be nice to have a restricted --recipient option that only supports safe, unambiguous addressing of keys. I think I'm in the latter category. In any case, I think the output of the program should be, in this case, usable as input. Thoughts? -- fdr ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Encrypting using gpgsm and self-signed certificates
Hello list, I've been integrating GPG into a backup utility, and while OpenPGP works as expected, I'm having some trouble with trying to also enable self-signed x509 certs via gpgsm as a mechanism for encryption. Unfortunately all I get back from gpgsm is No Value. The output of a gpgsm invocation without an agent running (as so all output is in one set of output) is as follows: $ gpgsm -v --debug-level=guru -r 'A17951D33720CCE03E1065ABB7BBC16CC11CCBB9' -e /dev/urandom gpgsm: enabled debug flags: x509 mpi crypto memory cache memstat hashing assuan gpgsm: no key usage specified - assuming all usages gpgsm: DBG: BEGIN Certificate `target': gpgsm: DBG: serial: 00A5BAF1300BFAC1B8 gpgsm: DBG: notBefore: 2010-02-04 03:35:35 gpgsm: DBG:notAfter: 2020-02-02 03:35:35 gpgsm: DBG: issuer: CN=ubuntu gpgsm: DBG: subject: CN=ubuntu gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5 gpgsm: DBG: SHA1 Fingerprint: A1:79:51:D3:37:20:CC:E0:3E:10:65:AB:B7:BB:C1:6C:C1:1C:CB:B9 gpgsm: DBG: END Certificate gpgsm: can't connect to the agent - trying fall back gpgsm: no running gpg-agent - starting one gpgsm: DBG: connection to agent established gpgsm: validation model used: shell gpgsm: can't encrypt to `A17951D33720CCE03E1065ABB7BBC16CC11CCBB9': No value random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/16384 bytes in 0 blocks It looks like I'm not the only one who has been scratching his head when happening upon this error condition, although I think my situation appears slightly different: http://lists.gnupg.org/pipermail/gnupg-devel/2009-April/024937.html I also tried to make use of http://lists.gnupg.org/pipermail/gnupg-users/2004-September/023247.html, but somehow I feel there is a gap in documentation here for the really simple case of: I have a self signed certificate. I trust it. Encrypt with it, and doing the most obvious thing (--import-key, --encrypt --recipient $FINGERPRINT) fails. By contrast, it's more or less straightforward to generate an OpenPGP key, trust it, and then encrypt an archive with it, and that works as expected. Cheers, -- fdr ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
