Re: Will gpg 1.x remain supported for the foreseeable future?
On Sat, Jan 20, 2018 at 4:08 PM, Todd Zullinger wrote: > I think that's https://dev.gnupg.org/T2290 Thanks. Say, anyone know how to get bug tracker problems resolved? Somehow my email address there lacks a dot before .com, so I can't get confirmation emails. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
Dan Kegel wrote: > - might save time and anguish if apt-key (and thus gpg[v]?) accepted > armored keyrings even if filename ends in .gpg I think that's https://dev.gnupg.org/T2290, in case you want to follow it or submit a patch to implement it. Werner did provide some details about how it would ideally be done. If I was more capable with C, I'd give it a try since I'd like to see gpgv work with armored keyrings too. -- Todd ~~ Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something. -- Robert Heinlein signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Thu, Jan 18, 2018 at 7:58 PM, Dan Kegel wrote: >> The keys referred to via signed-by are the only acceptable keys for the >> associated apt repo. >> >> does that make sense? > > That'd be great if it worked. Since it's hard to explain what's broken > without a simple script showing exactly what I'm doing, let's just > hold that thought until I post one. I spent a little while cleaning up my script and found the problem, whew! Here's part of the log: + gpg2 -q --pinentry-mode loopback --passphrase --personal-digest-preferences SHA256 --gen-key gpg.in.tmp + gpg2 --armor --export temp-r...@example.com ... + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get update ... Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring /tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg verify --status-fd 3 /tmp/apt.sig.nD3tum /tmp/apt.data.OVJLiX Read: [GNUPG:] ERRSIG 505A301EE37484C6 1 8 01 1516484740 9 Got ERRSIG Read: [GNUPG:] NO_PUBKEY 505A301EE37484C6 Even with apt debug logging on, that wasn't enough to make the problem obvious. I had to add exec 2> /tmp/apt-key.log.$$ set -x to the top of /usr/bin/apt-key. Grepping for that key in /tmp/apt-key*, I found + gpgv --homedir /tmp/tmp.oM7RZ707db --keyring /tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg --ignore-time-conflict --status-fd 3 /tmp/apt.sig.nD3tum /tmp/apt.data.OVJLiX gpgv: Signature made Sat Jan 20 13:45:40 2018 PST using RSA key ID E37484C6 gpgv: [don't know]: invalid packet (ctb=2d) gpgv: keydb_search failed: invalid packet gpgv: Can't check signature: public key not found Well, well. That 'invalid packet' appears to be a telltale sign of using --armor where one shouldn't, and looking at my first log, you can see a --armor. Removing it made everything happy. So this was a case of a) dumb user and b) poor diagnostics from apt. Also, now that I've ripped out all gpg1 support from my script, I realize that gpg-agent is nearly well behaved. Only possible rough spots I ran into were: - having to enable pinentry (ubuntu 16.04's gpg is old) - not knowing a clean way to tidy up an old gnupghome and its agent without hanging if the agent is missing - the gpg man page says --dearmor isn't very useful. I beg to differ :-) - might save time and anguish if apt-key (and thus gpg[v]?) accepted armored keyrings even if filename ends in .gpg Thanks for the encouragement. All's well that ends well. I'm sure I'll trip over my shoelaces again soon enough! - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Thu, Jan 18, 2018 at 7:52 PM, Daniel Kahn Gillmor wrote: > if this is the only thing happening, apt will indeed fail, because it > has never heard of the "new key" that was just created -- why should it > accept signatures from that new key? > > how are you configuring the target system to point to the repo? how are > you telling it where to find the key? By installing my package, which drops the key into /usr/share/keyrings and creates the lists.d entries with signed-by. That ought to suffice, I gather, but I'm tripping over shoelaces somewhere. > this looks strange to me -- you seem to be using a --keyring that is > *inside* the GNUPGHOME that you've set > (/tmp/obs_localbuild_gnupghome_dank.tmp/). > > that GnuPG homedir is really not part of the GnuPG API contract -- and > anything you put in that homedir could potentially be overwritten by > GnuPG itself. How is > /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg being > generated? It's just a regression test script. I'm cleaning it up and will post it once it's legible and avoids sins like that. > The keys referred to via signed-by are the only acceptable keys for the > associated apt repo. > > does that make sense? That'd be great if it worked. Since it's hard to explain what's broken without a simple script showing exactly what I'm doing, let's just hold that thought until I post one. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Wed 2018-01-17 20:58:21 -0800, Dan Kegel wrote: > Does one even need --import and --export while building foobar-archive; > aren't the thing being imported and the thing being exported > the same format? i don't know -- what are you importing? if the thing you're importing is already a clean Transferable Public Key, then you are right: you can deploy it with /bin/cp or /bin/cat or /usr/bin/install :) > (I saw a note about stripping off trust packets, since they're less > portable. Wonder if that's related.) trust packets aren't part of a Transferable Public Key -- if you're seeing trust packets, then the thing you're working with was never a Transferable Public Key in the first place :/ > What I am missing is how dropping a key into /usr/share/keyrings, > and then pointing to it with signed-by=, actually establishes > trust. hm, that pesky "trust" word again ;) -- let's be clear what we mean about it. The actions you describe above mean that the user is willing to rely on this key to certify the archive listing from your APT repository. this is a narrowly-scoped "trust", because it also means that the user will *not* accept signatures from the key in question on any *other* repository. This is good -- in the security sense of "trusted", we want to *reduce* trust, not expand it, right? things that you trust can violate that trust and you're helpless. > I mean, it makes sense and all, but when I write a > regression test script that : > - sets GNUPGHOME to an empty directory > - generates a key > - creates a repo using reprepro signed by that key > - creates a dummy package > - adds it to the repo > - tries to access the repo with 'apt-get update' if this is the only thing happening, apt will indeed fail, because it has never heard of the "new key" that was just created -- why should it accept signatures from that new key? how are you configuring the target system to point to the repo? how are you telling it where to find the key? I'd expect somewhere in there to be a "gpg --export" of the newly-created key, into a simple file that can be picked up later. > + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp > APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q update > inside VerifyGetSigners > Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring > /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify > --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj > Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9 > Got ERRSIG > Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4 > Got NO_PUBKEY this looks strange to me -- you seem to be using a --keyring that is *inside* the GNUPGHOME that you've set (/tmp/obs_localbuild_gnupghome_dank.tmp/). that GnuPG homedir is really not part of the GnuPG API contract -- and anything you put in that homedir could potentially be overwritten by GnuPG itself. How is /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg being generated? This seems like the sticking point to me. > or forgetting to mark the key I just generated as trusted there's no need to mark any keys as "trusted" with GnuPG for apt's sake. Apt represents its "trust" (willingness to rely on a key to generate acceptable signatures over an archive) in one of two ways: a) placement in /etc/apt/trusted.gpg or /etc/apt/trusted.gpg.d/*.gpg b) placement elsewhere in the filesystem, pointed to by a signed-by option in a line in /etc/apt/sources.list or /etc/apt/sources.list.d/*.list; or pointed to by a Signed-By: header in a stanza in /etc/apt/sources.list.d/*.source (see sources.list(5) for more details about the way that signed-by can be presented). the keys placed in the filesystem at the locations described in (a) are acceptable for making signatures over *every* apt repository configured on the system, except those with an explicit signed-by directive, which are more constrained. The keys referred to via signed-by are the only acceptable keys for the associated apt repo. does that make sense? --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Wed, Jan 17, 2018 at 8:58 PM, Dan Kegel wrote: > Here's the bit where it explodes, > > + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp > APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q > update > inside VerifyGetSigners > Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring > /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify > --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj > Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9 > Got ERRSIG > Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4 > Got NO_PUBKEY One little clue: apt evidently runs apt-key as user _apt, and /tmp/obs_localbuild_gpghome_dank.tmp/ is owned by me, with permissions 700. So apt-key can't read it. Whee! And if I try creating it with permissions 755, gpg complains about unsafe permissions. I'm still stuck in a twisty maze of little passages, all different. I probably should boil down my test to a simple linear script so I can ask for help properly... - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Wed, Jan 17, 2018 at 5:20 PM, Daniel Kahn Gillmor wrote: > > - The package depends on debian-archive-keyring (to leverage > > the web of trust as suggested in 'man secure-apt') > > (itym 'man apt-secure', right?) right. > if you're expecting ubuntu (or any other non-debian) users to install > this, then you're actually increasing their attack surface Correct. Glad to hear it's a crazy idea, happy to drop it, just need to understand how trust is established, and how to use the tools. > what i'm not hearing is an explicit example of how you are using gpg -- > as the archive maintainer, surely you manage the archive itself on a > system of your choice. for me, that would be a debian stable system, > with reprepro or something like that, which should already know how to > call out to gpg. > > as the developer of the foobar-archive package, you shouldn't need to > invoke gpg at all in your package build scripts other than just --import > and --export, which should be pretty standard across all versions of > gpg. Does one even need --import and --export while building foobar-archive; aren't the thing being imported and the thing being exported the same format? Just ferry active-keys/foobar-archive.gpg straight into /usr/share/keyrings/foobar-archive.gpg? (I saw a note about stripping off trust packets, since they're less portable. Wonder if that's related.) > You may also be interested in https://bugs.debian.org/861695, fwiw. Yes, I read that earlier with interest. Happy to be chatting with a grandmaster, as it were. What I am missing is how dropping a key into /usr/share/keyrings, and then pointing to it with signed-by=, actually establishes trust. I mean, it makes sense and all, but when I write a regression test script that : - sets GNUPGHOME to an empty directory - generates a key - creates a repo using reprepro signed by that key - creates a dummy package - adds it to the repo - tries to access the repo with 'apt-get update' it says the repo key is bad. Such a script is long enough than a secure apt beginner like me is unlikely to be able to get it right quickly. Here's the bit where it explodes, with debugging prints enabled: + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q update inside VerifyGetSigners Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9 Got ERRSIG Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4 Got NO_PUBKEY So I'm forgetting something important, like avoiding breaking things when I set up an isolated GNUPGHOME or apt config, or forgetting to mark the key I just generated as trusted, or not understanding how apt-key works, or just plain being dumb. My next move is probably reading apt-key and trying to understand it. Alternately, I could try ripping out all the gpg1 support in my scripts. That probably won't help, but would be satisfying :-) - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Wed 2018-01-17 15:09:45 -0800, Dan Kegel wrote: > Yes to all four questions. Here's the user story. cool, your user story all makes sense to me except this bit: > - The package depends on debian-archive-keyring (to leverage > the web of trust as suggested in 'man secure-apt') (itym 'man apt-secure', right?) if you're expecting ubuntu (or any other non-debian) users to install this, then you're actually increasing their attack surface, because this package will place debian archive keys as "trusted" keys automatically (meaning "any archive that is signed by them is considered legitimate), when they weren't present on the system before. I don't see the part of apt-secure(8) that says anything about needing this, and i don't see how it "leverages the web of trust" -- can you explain this more? Without a clear justification, i think you should remove this dependency. > I also have to support a range of versions of gpg, can't insist > on the latest. Happily, in preparation for supporting Ubuntu 17.10, > I verified that I can drop support for versions of gpg and apt > older than the ones in Ubuntu 16.04. what i'm not hearing is an explicit example of how you are using gpg -- as the archive maintainer, surely you manage the archive itself on a system of your choice. for me, that would be a debian stable system, with reprepro or something like that, which should already know how to call out to gpg. as the developer of the foobar-archive package, you shouldn't need to invoke gpg at all in your package build scripts other than just --import and --export, which should be pretty standard across all versions of gpg. your end users don't actually need full-blown gpg at all -- modern versions of apt depend explicitly (and minimally) on gpgv, since all they do is verify signatures based on a set of acceptable keys. > While my foobar-archive.deb may seem superficially similar to > debian-archive-keyring.deb, the latter does things > in its postinstall step that establish trust at the system > level in a way that doesn't seem like a good example for > third party apt repositories to use as an example. yep, agreed. (which is why i'm surprised to see your dependency on debian-archive-keyring) You may also be interested in https://bugs.debian.org/861695, fwiw. All the best, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Tue, Jan 16, 2018 at 8:31 PM, Daniel Kahn Gillmor wrote: > On Tue 2018-01-16 20:10:38 -0800, Dan Kegel wrote: > > When I try to use gpg to manipulate secure apt repositories in the > > real world, my head explodes. > > hi there! what kind of manipulation are you doing of secure apt > repositories with gpg? > > are you talking about signing the repo as an author? or about > configuring for a client? or distributing public keys for the repo? or > about verifying signatures as a client? Yes to all four questions. Here's the user story. - I maintain a secure apt repository at pkgs.foobar.com following best practices in https://wiki.debian.org/DebianRepository/UseThirdParty - the key that signs my repository is trusted by debian developers in the pgp web of trust - To my users, I send via a trusted offline mechanism a copy of a package foobar-archive.deb - When they install that package, it installs the files /usr/share/keyrings/foobar-archive.gpg, and /etc/apt/sources.list.d/foobar-archive.list - The latter file's entries say signed-by=/usr/share/keyrings/foobar-archive.gpg - The package depends on debian-archive-keyring (to leverage the web of trust as suggested in 'man secure-apt') - My users are happy that simply installing one package establishes trust and lets them apt-get from my repo with no pesky errors from ubuntu 17.10 about my server having an invalid or untrusted signature - Updates to foobar-archive are delivered via secure apt. So much magic. It took me a while to figure that path out, and I'm still not quite sure I've got it right, still working on getting my regression tests to pass. There don't seem to be a wealth of accurate examples that are both kosher and up to date. Most of my angst comes from having to come up two learning curves simultaneously with tools that are used by fairly small communities and thus have some rough edges still (debian packaging and gpg commandline tools), and have lots of stale stories out on the web about how to work around problems that no longer exist. I also have to support a range of versions of gpg, can't insist on the latest. Happily, in preparation for supporting Ubuntu 17.10, I verified that I can drop support for versions of gpg and apt older than the ones in Ubuntu 16.04. While my foobar-archive.deb may seem superficially similar to debian-archive-keyring.deb, the latter does things in its postinstall step that establish trust at the system level in a way that doesn't seem like a good example for third party apt repositories to use as an example. That package is not to be confused with the similarly named debian-keyring package, which is completely kosher and just installs key(ring)s into /usr/share/keyrings, but does not of itself establish trust. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Tue 2018-01-16 20:10:38 -0800, Dan Kegel wrote: > When I try to use gpg to manipulate secure apt repositories in the > real world, my head explodes. hi there! what kind of manipulation are you doing of secure apt repositories with gpg? are you talking about signing the repo as an author? or about configuring for a client? or distributing public keys for the repo? or about verifying signatures as a client? each use case is slightly different, but there should be reasonable, non-head-explode-y tooling available for all of them. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Tue 2018-01-16 16:26:49 -0800, Dan Kegel wrote: > I worked hard to jump through hoops to use version 2 in such > an environment, but then I ran into the fact that even the latest apt > from debian does not support version 2's keybox format, so I had > to drop back to gpg version 1 anyway. apt always uses the "transferable public key" form for its OpenPGP dependencies, which is specified in RFC 4880. a simple linear concatenation of these transferable public keys is a "keyring", which apt knows how to ingest. The "keybox" format is not used by any tool outside of the GnuPG suite, and it doesn't have nearly as much documentation or history as the transferable public key format. i tend to treat *.kbx the same way i treat private-keys-v1.d -- as part of GnuPG internals, not as part of its public interface. If you want to generate a clean "keyring" it should be straightforward to do so with any version of GnuPG just by using --export. You can import a keyring into any version of GnuPG with --import. if you're in the habit of using GnuPG in order to create some file within its internal "home directory" and then extract that for some other use (like sending handing some internal file from there to apt) -- please don't do that. The internals of the GnuPG homedir have never explicitly been part of the publicly-exposed API. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Wed, 17 Jan 2018 01:26, d...@kegel.com said: > I'm starting to suspect that using version 2.x of gnupg is simply not > a good idea when writing shell scripts that have to run unattended > and not touch system keychains or agents. Actually 2.2 is much easier to script than 2.1. Watch out for all these new --quick-foo commands. There are also very useful new --export-options and --import-options. Regarding the passphrase to protect private keys: Please rethink your design if you need a passphrase for unattended systems. If that does not work for you: --pinentry-mode=loopback works reasonable well. > from debian does not support version 2's keybox format, so I had > to drop back to gpg version 1 anyway. I am stating this for nearly 20 years: The format of pubring.gpg or pubring.kbx is intern to the gpg implementation and does not constitute any specified API. The same goes for most files in GnuPG's home directory. To work with public or private keys the --import and --export commands are to be used. Just in case: Always use --batch, --status-fd, and --with-colon in scripts. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp3sksq3GWpV.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Wed, 17 Jan 2018 03:52, r...@sixdemonbag.org said: > The game plan has always been to retire 1.4 as soon as practical. Do > not rely on it existing in the future. Kind of: 1.4 will be kept alive for use with PGP 2 encrypted and signated data and maybe for old platforms. However, modern algorithms won't be added to 1.4. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpQocJeZHCXo.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Tue, Jan 16, 2018 at 7:37 PM, Robert J. Hansen wrote: > * it's not going away in the near future > * we know people like to use it for servers > * it's a lot of work to keep two codebases going > * new crypto, like ECC, will not be backported to 1.4 > * new features will probably not be backported > * if you need 1.4 support, contact g10 Code GmbH Thanks. When I try to use gpg to manipulate secure apt repositories in the real world, my head explodes. I'm sure it will all seem reasonable after I figure things out. I've only been at it off and on for a couple years. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
> that's a shame. I should also say some more things about it, like -- * it's not going away in the near future * we know people like to use it for servers * it's a lot of work to keep two codebases going * new crypto, like ECC, will not be backported to 1.4 * new features will probably not be backported * if you need 1.4 support, contact g10 Code GmbH :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
Robert J. Hansen wrote: > > Is version 1 going to remain available, I hope? Version 2 simply > > seems a poor fit for scripting. > > The game plan has always been to retire 1.4 as soon as practical. Do > not rely on it existing in the future. that's a shame. i hope someone creates a non-gui, non-curses pinentry program before that happens (that can work inside a gvim window). cheers, raf ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
> Is version 1 going to remain available, I hope? Version 2 simply > seems a poor fit for scripting. The game plan has always been to retire 1.4 as soon as practical. Do not rely on it existing in the future. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Will gpg 1.x remain supported for the foreseeable future?
Hey all, I'm starting to suspect that using version 2.x of gnupg is simply not a good idea when writing shell scripts that have to run unattended and not touch system keychains or agents. I worked hard to jump through hoops to use version 2 in such an environment, but then I ran into the fact that even the latest apt from debian does not support version 2's keybox format, so I had to drop back to gpg version 1 anyway. Is version 1 going to remain available, I hope? Version 2 simply seems a poor fit for scripting. Thanks, Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users