Re: a new free smime service, but...
* Steffen Nurpmeso: > > * Steffen Nurpmeso: > > > I think it is common that S/MIME and SSL certificates are delivered > > > via PKCS12, including the private key. You then seem to extract the > > > individual things [...] > > > > Nope, that is the wrong way round. [...] > > Ok, but that is exactly what i have written a few lines later for the > CACert example that i posted, right. So not nope, Mr. What you describe in the "I think..." paragraph is *not* the common way to deliver certificates. Hence, nope. -Ralph ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: a new free smime service, but...
Hello, sorry for the late reply. Ralph Seichter wrote in <87pninuqns@wedjat.horus-it.com>: |* Steffen Nurpmeso: |> I think it is common that S/MIME and SSL certificates are delivered |> via PKCS12, including the private key. You then seem to extract the |> individual things [...] | |Nope, that is the wrong way round. The correct sequence to obtain an |S/MIME certificate is as follows: | |1. User X creates a private key *locally*. This private key must never |be handed to anybody else. | |2. User X creates a certificate signing request (CSR) and sends it to a |certificate authority (CA). | |3. The CA uses the CSR to create a signed certificate, and sends that |certificate back to user X. Ok, but that is exactly what i have written a few lines later for the CACert example that i posted, right. So not nope, Mr. Where "user X" meant "browser of user X" when i did so for a StartSSL certificate. I assume it did the right thing. But i do not know. |4. User X can then optionally combine private key and signed certificate |in a .p12 file to ease importing the data *locally* in his MUA (it is |usually more convenient to deal with a single file that combines both |private key and certificate). | |If the process is altered in any way in which a third party gets hold of |user X's private key, security is broken, no matter if the private key |is password protected or not. That is surely right. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: a new free smime service, but...
P.S.: Steffen Nurpmeso wrote in <20191023224323.kaodd%stef...@sdaoden.eu>: ... ||> I think it is common that S/MIME and SSL certificates are ||> delivered via PKCS12, including the private key. You then seem to ||> extract the individual things like || ||I think this is a severe security breach. The private key should never ||leave your computer. (Yes.) ||> $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes ||> $ # Alternatively ||> $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys ||> $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes || ||>|keys are generated on the subscriber's device and only the public key ||>|goes to the CA to be certified. | |With StartSSL it was like that, the browser generated the signing |request i hope. But i do not know. | |And, the above i inherited in the manual of the software |i maintain. I have not seen this in the wild on my own. This is actually only half true. The original manual only contains the first of the three. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: a new free smime service, but...
Hello, please excuse the late reply. Uwe Brauer via Gnupg-users wrote in <874kzz1var@mat.ucm.es>: |> MFPA via Gnupg-users wrote in <1171562612.20191022004056@my_localhost_AR\ |> >: |>|On Sunday 20 October 2019 at 3:20:41 PM, in |>|, Uwe Brauer via Gnupg-users wrote:- |>| |>|> I just found that |>|> https://extrassl.actalis.it/portal/uapub/doProcess |>| |>|> Provides a free smime certificate. |> ... |>|> does somebody know whether there is a security |>|> breach, the way this |>|> certificate was generated? |>| |>|I'm no expert but their Certificate Policy reads to me that the |>|private key is compromised right from the start. I think usually the | |> I think it is common that S/MIME and SSL certificates are |> delivered via PKCS12, including the private key. You then seem to |> extract the individual things like | |I think this is a severe security breach. The private key should never |leave your computer. | |> $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes |> $ # Alternatively |> $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys |> $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes | |>|keys are generated on the subscriber's device and only the public key |>|goes to the CA to be certified. With StartSSL it was like that, the browser generated the signing request i hope. But i do not know. And, the above i inherited in the manual of the software i maintain. I have not seen this in the wild on my own. |> This is possible via CACert.org, at least still (out of money). |> You create your local signing request, and the private key.pem never |> leaves your own box: | |> $ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem | |> (Ensure all email addresses of desire are included in the web |> form.) |> Unfortunate that besides Comodo there seems no other provider of |> free S/MIME certificates. You can only self-sign, and provide That i have done myself. |Comodo does not offer this any more. At the beginning of the year they |reduced the smime cerificates validity from 1 year to 1 month, now they |withdraw it all together. I did not know that. It was the only free service that i found when i searched for a free S/MIME certificate last, but i kept using CACert.org. (Until i support PGP, when i will switch.) |> a safe transport for a certificate to compare with. Which is why |> PGP is so nice. | |Well yes sort of, but I can tell you from my own experience PGP is more for |hackers while smime is not. I have convinced 6 of my friends to use |smime, but only one to pgp. | |Self signed smime certificates are basically useless, because then you |have to tell the other user either to install a root certificate or to |trust the certificate, in which case smime looses its convenience |(compared to pgp) Well, hm, yes. What should i say. It depends a bit, once you know a certificate is correct some software allow to just agree to the checksum of a certificate, for example, no need for a root certificate no more. To know it is correct you need the certificate which signed it in what you use as your local pool of certificate authorities, of course. I do have GPG keys in may keyring which were not signed by anyone (when i downloaded them), too, i saw the fingerprint in some announcement mail or on some website, searched SKS, and downloaded the one key which did match. (I think Postfix releases are still shipped with a gpg1 key sign that is revoked, last i looked, i always have to look how i can actually use a revoked key nonetheless.) Personally i like S/MIME more, because it comes from the same pool of standards etc. that TLS uses, and the same library can be used to deal with it, than what i use for TLS anyway. In theory file signing and all the other things would be possible via it, too, the primitives are there, it is just not used in that there are no omnipresent tools available, like GPG is. There is no other reason really, except that for mail different standards for MIME are used, and here i like the PGP one more ;) That is just how it is, and having said that, i do use PGP since many years, but only very rarely and mostly automatized (after having had immense loss due to lost passwords of encrypted backups). --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: a new free smime service, but...
* Steffen Nurpmeso: > I think it is common that S/MIME and SSL certificates are delivered > via PKCS12, including the private key. You then seem to extract the > individual things [...] Nope, that is the wrong way round. The correct sequence to obtain an S/MIME certificate is as follows: 1. User X creates a private key *locally*. This private key must never be handed to anybody else. 2. User X creates a certificate signing request (CSR) and sends it to a certificate authority (CA). 3. The CA uses the CSR to create a signed certificate, and sends that certificate back to user X. 4. User X can then optionally combine private key and signed certificate in a .p12 file to ease importing the data *locally* in his MUA (it is usually more convenient to deal with a single file that combines both private key and certificate). If the process is altered in any way in which a third party gets hold of user X's private key, security is broken, no matter if the private key is password protected or not. -Ralph ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Should gpg try to connect to TCP/993?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello! Mikhail Morfikov wrote: > Let's assume you are right, and it's because of the way the > linux works. > > When I clear the conntrack table, the following messages appear [...] > So it's an ACK packet (possibly one per already opened > connection, since src ports differ), and not SYN. So it's not a > new connection for sure. [...] > But in the case of gpg, > there's no entry that would match anything that was printed > above. So will this match to your idea? I think yes, it does. The assumption here is that gpg inherits the file descriptor after the connection is opened - so the SYN is already sent and recorded as having come from Thunderbird. The other assumption is that the firewalling systems are confused about which process owns the packets, because after the fork()/exec() there are actually two possibilities. Without keeping expensive historic state about which process *created* the connection, it's impossible for the kernel to know which is the owner and some connections will get misreported. All pretty plausible, no? > > Each active TCP/IP connection has an open file descriptor. So, if > > Enigmail's gpg launcher hasn't taken care to close unneeded file > > descriptors after fork() and before exec() [...] > Should the `Enigmail's gpg launcher` take care of that? Maybe > is a bug or something? IMO, yes, if this is what is going on it is almost certainly a bug. Whatever code is calling exec() should be closing file descriptors first. Not doing so can lead to all sorts of wasted resources and even deadlocks if processes depend on file descriptors getting properly closed in a timely fashion. > > Since gpg doesn't actually know anything about these connections, > > it likely won't close them, they'll stay open (potentially even > > after Thunderbird has closed them, although that doesn't match > > all the symptoms you've described). > So what doesn't match the symptoms I've described? Maybe I have > to pay attention to certain things, and than it will match. Since (I think) Enigmail's gpg processes are usually short-lived, you're unlikely to see this happen, and if it does it's likely to be harmless. If the gpg processes were long-lived, it could over time lead to resource exhaustion (running out of file descriptors or RAM). The symptoms that didn't match this, was that Thunderbird was unable to download mail. If this was *only* happening with connections that Thunderbird thought it had closed, then your firewall rules wouldn't have impacted TB's operations. Again, I'll stress that this is all educated guesswork. But the symptoms match. I've created bugs like this myself in the past. Of course, maybe GnuPG does like to connect to port 993. I haven't ruled that out, but if that were the case, you'd probably have seen SYN packets in your logs. :-D - Bjarni - -- PageKite.net lets your personal computer be part of the web -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2wq2QACgkQjgA3FgDP lJE3KAgAtVKIkBlAXRXhtvsuWvPUFoygc/LF7ice2PWKbBada8yIiY3U0F8YtbSJ bmtm+bqPhPijBuAH8O0RdGkFQsvyUFSYzvXKE92Tb6jZF5NEdOktVkIRbwurNOAS 0MreNosHaV9wPx5mm1DtY5UkDF9ccZzdQXdXRGvoMz5uKBdRgxtHaaBWS1+0pwey VsAqmjeSB8UOdJDpnqIXRxxyoZ7Ti/Aru4KweKoYVnIac39fFg2GRY3mRD0D0pIL nI+Znnm0nAi64wLQ6/hVEJ2175TN6g/XgRtCCPyjytmrFrIMnOwB6t+ZmSWADUH9 QzQpKFwoW1mC/+/7aDT0unQlUtDGDg== =j1yU -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Should gpg try to connect to TCP/993?
Let's assume you are right, and it's because of the way the linux works. When I clear the conntrack table, the following messages appear in the FW log (I don't block the gpg packets for now, just log and accept them in its rule): Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \ SRC=192.168.1.150 DST=64.233.165.108 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=63468 DF PROTO=TCP \ SPT=41414 DPT=993 SEQ=50635057 ACK=2111326021 WINDOW=501 RES=0x00 ACK PSH URGP=0 \ OPT (0101080A1268C9EA725E3175) UID=1000 GID=1000 Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \ SRC=192.168.1.150 DST=64.233.165.108 LEN=86 TOS=0x00 PREC=0x00 TTL=64 ID=29858 DF PROTO=TCP \ SPT=41416 DPT=993 SEQ=4217185545 ACK=3828226663 WINDOW=501 RES=0x00 ACK PSH URGP=0 \ OPT (0101080A1268CA10E67D9F27) UID=1000 GID=1000 Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \ SRC=192.168.1.150 DST=64.233.165.108 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=35167 DF PROTO=TCP \ SPT=41510 DPT=993 SEQ=2292653331 ACK=2720180704 WINDOW=501 RES=0x00 ACK PSH URGP=0 \ OPT (0101080A1268CAFEB48EC039) UID=1000 GID=1000 So it's an ACK packet (possibly one per already opened connection, since src ports differ), and not SYN. So it's not a new connection for sure. Also, someone once gave me the following audit rule: -a exit,always -F arch=b64 -S connect -k MYCONNECT to find what actually is trying to connect to the net. Each time I see some blocked OUTPUT packets in the FW logs, I usually run `audit` to find out what that might be. In all cases so far, in the audit log I was able to match the dst IP or dst port that I saw in the FW logs. But in the case of gpg, there's no entry that would match anything that was printed above. So will this match to your idea? > The way processes are spawned on Unix, fork()/exec() will by > default inherit open file descriptors. Thunderbird/Enigmail will > fork()/exec() to launch gpg. > > Each active TCP/IP connection has an open file descriptor. So, if > Enigmail's gpg launcher hasn't taken care to close unneeded file > descriptors after fork() and before exec(), gpg will inherit the > connections Thunderbird had open at the time of invocation. Should the `Enigmail's gpg launcher` take care of that? Maybe is a bug or something? > Since gpg doesn't actually know anything about these connections, > it likely won't close them, they'll stay open (potentially even > after Thunderbird has closed them, although that doesn't match > all the symptoms you've described). So what doesn't match the symptoms I've described? Maybe I have to pay attention to certain things, and than it will match. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Should gpg try to connect to TCP/993?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Mikhail, What follows is an educated guess, but only a guess... Mikhail Morfikov via Gnupg-users wrote: > gpg wants to connect to the network, but it looks like it wants > also TCP/993 (IMAPS). This happens when I use Thunderbird as a > mail clinet + Enigmail extension, which make some use of gpg. ... > doesn't show anything that points to gpg. When I prevent gpg > from connecting to this port, I can't access my mail account in > Thunderbird -- it just tries to refresh the inbox, but it just > stalls. When I restart Thunderbird at this point, then > everything backs to normal, and I don't see any drops in OUTPUT > traffic. Could anyone explain what's going on here? The way processes are spawned on Unix, fork()/exec() will by default inherit open file descriptors. Thunderbird/Enigmail will fork()/exec() to launch gpg. Each active TCP/IP connection has an open file descriptor. So, if Enigmail's gpg launcher hasn't taken care to close unneeded file descriptors after fork() and before exec(), gpg will inherit the connections Thunderbird had open at the time of invocation. Since gpg doesn't actually know anything about these connections, it likely won't close them, they'll stay open (potentially even after Thunderbird has closed them, although that doesn't match all the symptoms you've described). If your firewall then sends RST packets to close connections which gpg isn't supposed to be making, it will actually be shutting down the connections Thunderbird was using and you won't be able to access your mail. (This scenario matches what you have described, but I haven't reproduced your problem to verify it is indeed the case.) Hope this helps! - Bjarni - -- PageKite.net lets your personal computer be part of the web -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2wUdYACgkQjgA3FgDP lJH11ggAk3SujXyDYqzLdDkbDksZwkdZEE5fhMPfukMGrs6/N2L08yzUxKYTx9v4 QdTY5BmUVl2sG21eUY+y90Y0YK3lpHJNrfe9Rrw5QnHXjB4B1fuzQCuUfwVv3YGt kHtj95clWgHsWWqIh5AWnt4LDk4inZ6+SVhj0k49eyea3GIelL/iJxxQ9wFjbPVY sbxiUP83qtTgKDVW98rneVS8mgJ6/d0Qf+RQFRmR3E+6RYPDo0FoNhpKGodTN4BO Ph+GuwuHBu0o7cjxdsgNdFY8v1GgcpQOtJ9gbZs5ysBeG4nrejxwK1EFbiAh+YX/ cZTfoE7/g0PJ877299r5C1uPAUTXHg== =5yoS -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: a new free smime service, but...
> MFPA via Gnupg-users wrote in <1171562612.20191022004056@my_localhost_AR>: > |On Sunday 20 October 2019 at 3:20:41 PM, in > |, Uwe Brauer via Gnupg-users wrote:- > | > |> I just found that > |> https://extrassl.actalis.it/portal/uapub/doProcess > | > |> Provides a free smime certificate. > ... > |> does somebody know whether there is a security > |> breach, the way this > |> certificate was generated? > | > |I'm no expert but their Certificate Policy reads to me that the > |private key is compromised right from the start. I think usually the > I think it is common that S/MIME and SSL certificates are > delivered via PKCS12, including the private key. You then seem to > extract the individual things like I think this is a severe security breach. The private key should never leave your computer. > $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes > $ # Alternatively > $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys > $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes > |keys are generated on the subscriber's device and only the public key > |goes to the CA to be certified. > This is possible via CACert.org, at least still (out of money). > You create your local signing request, and the private key.pem never > leaves your own box: > $ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem > (Ensure all email addresses of desire are included in the web > form.) > Unfortunate that besides Comodo there seems no other provider of > free S/MIME certificates. You can only self-sign, and provide Comodo does not offer this any more. At the beginning of the year they reduced the smime cerificates validity from 1 year to 1 month, now they withdraw it all together. > a safe transport for a certificate to compare with. Which is why > PGP is so nice. Well yes sort of, but I can tell you from my own experience PGP is more for hackers while smime is not. I have convinced 6 of my friends to use smime, but only one to pgp. Self signed smime certificates are basically useless, because then you have to tell the other user either to install a root certificate or to trust the certificate, in which case smime looses its convenience (compared to pgp) smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: a new free smime service, but...
> Hi > On Sunday 20 October 2019 at 3:20:41 PM, in > , Uwe Brauer via Gnupg-users wrote:- > [...] > I'm no expert but their Certificate Policy reads to me that the > private key is compromised right from the start. I think usually the > keys are generated on the subscriber's device and only the public key > goes to the CA to be certified. > https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx > 3.2.2 Proving possession of private key > The private cryptographic key corresponding to the public key > within the certificate is generated by the CA (with a suitable > algorithm, size, etc.) and subsequently sent to the subscriberin > PKCS#12 for-mat[PFX], via email, thereby insuring that the > subscriber does possess the private key.The password needed to > import the PKCS#12 file isprovided to the subscriber out-of-band > (via web), therefore protecting it from unwanted disclosure to > third parties. The CA does not retain such pass-word, so that the > legitimate subscriber –assuming that he/she keeps such password > confidential –remains the only person able to import the PKCS#12. Oops this is really bad. I should have read this. Thanks for pointing it out. I am wondering why they do such a bizarre thing? Maybe it is easier to implement? smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: libgcrypt license
On 22.10.2019 20:50, Werner Koch via Gnupg-users wrote: > There is no real reason > for this and we could change the license if that really makes a > difference for you. It would help me as a downstream packager at least; to the extent that otherwise we'll have to update license acceptance information in the package. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Should gpg try to connect to TCP/993?
I'm filtering OUTPUT traffic on my Debian via nftables+cgroups(net_cls)+cgrulesengd, and all apps, which want to connect to the network, I have to assign some cgroups class and add a rule in the FW. The gpg binary wants TCP/443 to speak with keyservers (optionally TCP/80). I thought that's all what gpg wants to connect to the network, but it looks like it wants also TCP/993 (IMAPS). This happens when I use Thunderbird as a mail clinet + Enigmail extension, which make some use of gpg. Basically when I start Thunderbird, only it wants to connect to the TCP/993 port, but when I clear the conntrack table via `conntrack -F`, then also gpg wants to connect to that port. This is not always the case though -- it only happens when the clearing of the conntrack table is issued some time after Thunderbird has been stared (an hour or so). So it looks like the keepalive packets can play some role here. When I `lsof -i :993`, I can see some entries pointing to Thunderbird. Also nftables reports some NEW-notSYN packets destined to my machine (which is understood because the conntrack mechanism doesn't know about the established connections now,and everything that comes from the mail servers is in this NEW-notSYN state). I can see some blocked OUTPUT packets as well, and when compared src/dst ports/ips I can tell that the packets were sent by Thunderbird (they match to the `lsof` output). Also `lsof` doesn't show anything that points to gpg. When I prevent gpg from connecting to this port, I can't access my mail account in Thunderbird -- it just tries to refresh the inbox, but it just stalls. When I restart Thunderbird at this point, then everything backs to normal, and I don't see any drops in OUTPUT traffic. Could anyone explain what's going on here? signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Automatically changing/removing key passphrase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello GnuPG users! Background: I'm working a bit on Mailpile's Autocrypt support these days. Mailpile creates OpenPGP keys for its users, which are protected by a strong passphrase, but generally manages those passphrases on the user's behalf to guarantee a seamless user experience. I don't want my users to be locked in to Mailpile, and I wanted to implement the Autocrypt Setup Message (ASM) spec so users had a standardized, semi-automated way to migrate their keys from Mailpile to another mail agent. For better or worse, the ASM defines a password protection scheme for the key material which is different from a passphrase on the key itself. So when syncing the keys, I need to remove the passphrase. I cannot figure out an elegant way to do this using GnuPG or GPGME. The GPGME manual's "Changing Passphrases" section 7.5.10 states: "The backend engine will usually popup a window to ask for the old and the new passphrase. Thus this function is not useful in a server application (where passphrases are not required anyway)." I guess from the point of view of GnuPG and GPGME, Mailpile is behaving like a server application. But I would still rather not store the secret keys unprotected, so I need an automated way to manage the key's passphrase. How do I square this circle? Any hints on how to automatically remove the passphrase using gnupg without direct user interaction? A Google search showed that this is a question that comes up every now and then, but I have only seen manual procedures for resolving it. Is this perhaps a feature which should be added? Thanks in advance, - Bjarni - -- PageKite.net lets your personal computer be part of the web -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2wDukACgkQjgA3FgDP lJFCYAf/R+mKR92lZN5kaE5d81cP2oGqJ8AGuWzTulI42LubyRezoAg939OVijwo 2+sVcqL2Xk8uPBtu+gq+/ZvN31NuG1PfEE35s4+G4n4YqkLx+NC18HCffuMJ+515 unjHmrQ+ID08kbp/xQNE/jqXqFDTGUo25pGlSI4ecqZumtkK9SBEI9JSsW0jR11L N/SC9JXh2ksD2j9azYKsbj9fgDO+8Lg2vXpaWTjv+BFe1vKaDfQzGw7DSUVtzsD4 PT8HlFvWucUmhGv5A7SKUWEMG4VC7J33YjPK5KMe8TCBA+agmRw93JMiVPVUEzaw 8iFw9haK8zQawgYmC9Ja/qI9CuohyA== =Cpmt -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
