[ale] More Key Signing Followup

Thu Dec 15 22:30:53 EST 2011

Thanks Jeremy, I had a feeling that's what they did. So I could probably
just go by the manuals that are available for both Seahorse and
Password-Agent, should be fairly close.

On 12/15/2011 10:18 PM, Jeremy T. Bouse wrote:
> 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
>>>
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: skotchman.vcf
Type: text/x-vcard
Size: 172 bytes
Desc: not available
Url : http://mail.ale.org/pipermail/ale/attachments/20111215/6567290d/attachment.vcf 