[ale] More Key Signing Followup

[Jeremy T. Bouse]

Scott,

	I would assume 3.2.1 would have the agent functionality in it since I
use 2.32.0 on Ubuntu and it provides it. The only config change I ever
made was adding "use-agent" to my ~/.gnupg/gpg.conf and then logging
into the X desktop.

On 12/15/2011 10:09 PM, Scott Castaline wrote:
> Due to some of you commenting on using a GUI Frontend for GnuPG called
> Seahorse I went ahead and installed it. I found that the online manual
> is way dated and seems to not correspond with the version I have. For
> one, the first tab (left most tab) is Passwords. I have seen elsewhere
> mention of Password-Agent, any possibility that Seahorse 3.2.1 includes
> this Password-Agent now? It sort of looks like a password manager
> similar to KeePassX which is what I currently use. Is that a correct
> assumption?
> 
> I'd like to find some explanation or a howto that is more current for
> version 3.2.1 and have not been able to find it. Can anyone help me on this?
> 
> On 12/15/2011 08:51 PM, Michael B. Trausch wrote:
>> On 12/15/2011 06:21 PM, Aaron Ruscetta wrote:
>>> I have decided not to bother creating a replacement key at this
>>> time, but thanks for the offers to sign it if I provided proof of
>>> origination by signing the fingerprint with my working key.
>> If you change your mind at some point, the offer will be just as valid
>> then as it is now.  :-)
>>
>>> Thoughts on the process of managing PGP keys:
>>>
>>> This my third time around with this gpg key stuff and I continue
>>> to find everything about this process cryptic (no pun intended),
>>> confusing, frustrating and a massive time vacuum.
>> To get started using any sort of thing like OpenPGP (which GnuPG is an
>> implementation of, more or less) can be a bit overwhelming, particularly
>> if you aren't using tool wrappers around the command line program
>> itself.  My daily use of it is mostly "behind the scenes" to me; the
>> agent handles passphrase caching pretty transparently, as does the mail
>> client.  In my case, I am (currently) using Thunderbird, but Evolution
>> works just as well with OpenPGP messages.
>>
>> Because most of my use for the key is in fact email, I don't actually
>> directly interact with the gpg command line program often.  So, every
>> time I need to do something with it, I have to look up the man page
>> until I find what it is I am looking for---because I have inevitably
>> forgotten it.  Don't get me wrong; I'm not complaining about the command
>> line!  Just one of those "use it or lose it" things, and I'd rather lose
>> one really complex command's options from my memory than all the
>> standard stuff from the toolbox.  :)
>>
>> What system are you running on?  You should be able to pick a decent
>> mail client (regardless of your processor architecture) that has
>> built-in or extension-based support for GnuPG.  Claws, Mozilla
>> Thunderbird and Evolution all support it pretty straightforwardly (I
>> have used all three at various points in time).  There is also a list of
>> plugins and user interfaces here:
>>
>>   http://www.gnupg.org/related_software/frontends.html
>>
>> Like many other things, if you use it all the time it just kind of fades
>> into the background.  When I go to sign tarballs, I can never remember
>> anything other than "gpg --armor"... :-)
>>
>>> Most of the additional issues come from what I found to be
>>> huge inconsistencies in the use of KEY ID / UID terminology
>>> in the gpg argument strings, man pages and other
>>> documentation.   In some cases, Key ID was used to refer to
>>> the user ID (e.g. "Michael H. Warfield").  For signing, where
>>> the man page indicates a "Key ID" argument, only the
>>> UID would work for me and the program balked at using
>>> any actual 8 character Key ID's.  Other places, like uploading
>>> the keys to a key server, the Key ID of the man page was
>>> referring to (and ONLY referring to) the actual 8 character
>>> hex ID string (which I learned could be optionally set
>>> to be 16 characters by another command argument) .
>> Sadly, this kind of thing can be found everywhere, and it really is
>> discouraging.  Personally, I try to use the terms "uid" and "key ID"
>> consistently (and meaning the user name/email address and the tail of
>> the key's fingerprint, respectively).  Then again, (in)consistency in
>> naming has often been a pet peeve of mine.
>>
>>> The process of Exporting-keys to upload to the Keyring site
>>> (biglumber) and Sending-keys to the key servers was made
>>> additionally annoying and time consuming by the apparent
>>> lack of [easy to include] tools or command arguments that
>>> would simply produce a list of JUST the Key ID's or JUST
>>> the UID's from a person's keyring DB.  The best I could do
>>> for getting a "batch" list of the Key or User ID's was to dump
>>> the whole key listing to text file and then manually edit out
>>> the irrelevant cruft (which you get to do twice, since one
>>> operation wanted UID's and the other wanted Key ID's).
>> The way that I did this was with a one-off pipeline...
>>
>> ... I use far too many one-off pipelines.  :-)
>>
>> The command I used to get the list of key IDs was (sorry, these span
>> multiple lines...):
>>
>> $ gpg --list-keys | grep pub | awk '{ print $2 }' | cut -f2 -d/ | sort |
>> tail -n+2
>>
>> To export the keys from the list, then:
>>
>> $ gpg --armor --export $(gpg --list-keys | grep pub | awk '{ print $2 }'
>> | cut -f2 -d/ | sort | tail -n+2)
>>
>> I suppose I should try to remember to capture all of these pipelines I
>> create as one-offs and put them in some sort of a small collection of
>> shell scripts.
>>
>>> Using the keys after you get them also remains less than
>>> simple, as only a couple of specific mail client versions
>>> are supported on my slightly older platform.  Tools for using
>>> gpg keys within the web mail clients like gmail seem to be
>>> available for newer web browser versions, but not for
>>> anything that still runs on PPC.
>> One thing that comes to mind, if you don't mind terminal applications:
>> mutt handles OpenPGP messages pretty well after a bit of configuration.
>>
>> Also, Claws might be something you want to look into, as well.
>>
>>> I definitely got a lot further toward a clear understanding
>>> the gpg key mechanisms and usage and management
>>> with this foray, even more than I did when I helped prepare
>>> the documentation for the last ALE key signing event in
>>> 2009. The disappointment is that a lot of my new found
>>> understanding is the knowing that the gpg key processes
>>> are cryptic (no pun intended), confusing, frustrating and
>>> a massive time vacuum.
>>>
>>> Even for a fairly competent shell mechanic like myself, the
>>> whole key management process seems a major PITA that
>>> could due to be greatly simplified (or at least much better
>>> explained) so that the benefits of public key encryption can
>>> be enjoyed and employed by a much broader audience.
>> I agree that there could be better (more intuitive, and more robust)
>> front-ends, at least compared to the ones that I have seen and used.  I
>> haven't used them all, of course, but the ones that I have found have
>> had issues here and there.  Thing is, I'm not entirely certain how to
>> make it more convenient without getting rid of some of its benefits;
>> lowering the bar, so to speak, would very likely have the potential to
>> also lower the quality of the Web of Trust and so forth.
>>
>> 	--- Mike
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20111215/e65b32f6/attachment.bin