From wk at gnupg.org Mon Jan 2 09:12:38 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Jan 2 09:17:23 2006 Subject: gpgol cross compilation error In-Reply-To: <20051227120545.EBE4A7B524@ws5-10.us4.outblaze.com> (Srinivasan S.'s message of "Tue, 27 Dec 2005 20:05:45 +0800") References: <20051227120545.EBE4A7B524@ws5-10.us4.outblaze.com> Message-ID: <877j9jvyix.fsf@wheatstone.g10code.de> On Tue, 27 Dec 2005 20:05:45 +0800, Srinivasan S said: > util.h:47:25: w32-gettext.h: No such file or directory Sorry. Forgot to commit w32-gettext.[ch]. Fixed (rev. 135). Shalom-Salam, Werner From kfitzner at excelcia.org Thu Jan 5 05:22:25 2006 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Thu Jan 5 05:23:59 2006 Subject: Confusing results Message-ID: <43BC9F01.2000907@excelcia.org> I recently ran into an error while importing a key into my keyring. The results reported by GnuPG seem a little confusing: gpg: requesting key 500B8987 from hkp server wwwkeys.pgp.net gpg: renaming `e:/apps/gnupg\pubring.gpg' to `e:/apps/gnupg\pubring.bak' failed: Permission denied gpg: error writing keyring `e:/apps/gnupg\pubring.gpg': file rename error gpg: key 500B8987: public key "[User ID not found]" imported gpg: error reading `[stream]': file rename error gpg: Total number processed: 0 gpg: imported: 1 One part of GnuPG seems to think the import succeeded (which, in a way, it did), while another is giving an error message. The end result was that the import failed, but it's hard to tell from the message that it did, since it claims the key was imported. This error was caused by another instance of GnuPG operating while this one was. Would it be possible for GnuPG to check for a lock on the keyring before it tries to manipulate it? That would probably avoid something like the above occuring. Kurt. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 372 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060104/275b809b/signature.pgp From kfitzner at excelcia.org Mon Jan 9 15:06:51 2006 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Mon Jan 9 15:06:33 2006 Subject: Better smartcard support in GnuPG Message-ID: <43C26DFB.5090101@excelcia.org> While implementing smartcard support in GPGee, I noticed that there are what I think are a few weak areas in GnuPG's smartcard support: 1) Missing --status-fd messages I took my well-used key and made a subkey on my smartcard. I then deleted my primary secret key so that I only have the subkey's smartcard stubs on my secret keyring. I keep my full secret keys offline in a safe place. Without that full secret key, I cannot sign other keys. The error reported by GnuPG is: gpg: secret key parts are not available gpg: signing failed: general error The problem is, GnuPG has no --status-fd message for the above error. This means that GPGME doesn't pick up on this error. A GPGME client application will think that a signing operation was a success. 2) Confusing --status-fd messages When a smartcard PIN is wrong, the only --status-fd message returned is: [GNUPG:] SC_OP_FAILURE This means that a GPGME client appication can't tell the user that the PIN was wrong - all it can say is the operation failed. I would suggest that a BAD_PASSPHRASE status message be issued with the serial number of the card: [GNUPG:] BAD_PASSPHRASE D27600012401010100010000052C0000 3) Request PIN even when card is missing/wrong card I would suggest that if there is no smartcard in the reader, then GnuPG should still go ahead and request the PIN. This will give applications the opportunity to prompt the user for the correct card in their passphrase dialogs: "Insert card #blahblah and then enter the PIN" This will eliminate the need for card detection and simplify front end support greatly. The current status messages for missing (CARDCTL 5) or wrong (CARDCTL 3+1) could still be retained so that missing/wrong cards can be detected. If the "GET_LINE cardctrl.change_card.okay" command-fd line is eliminated with this change, it shouldn't break any existing applications. In fact, this might actually make some existing applications more card friendly. Kurt. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 372 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060109/54e86b11/signature.pgp From jvender at owensboro.net Tue Jan 10 12:38:26 2006 From: jvender at owensboro.net (Joe Vender) Date: Tue Jan 10 13:48:32 2006 Subject: GnuPG 1.4.3-cvs make warning under mingw Message-ID: <200601100538260940.007DD770@216.135.2.37> This is a reminder that the make warning is still showing up in the latest cvs code of GnuPG 1.4.3 when building under MinGW/MSYS for windows: iobuf.c: In function `iobuf_get_fd': iobuf.c:1930: warning: return makes integer from pointer without a cast Joe From jvender at owensboro.net Tue Jan 10 12:23:11 2006 From: jvender at owensboro.net (Joe Vender) Date: Tue Jan 10 13:48:57 2006 Subject: Bug in GnuPG Message-ID: <000501c615d8$43b82a60$971387d8@net> This appears to be a bug in the latest GnuPG 1.4.3-cvs (tested on rev.3985). I've also verified it in the official GnuPG 1.4.2 windows binary distributed by GnuPG.org. I started with an empty gpg.conf. Then, using the command line, I encrypt a text file in the working directory as per the following: gpg -o test2.txt --encrypt-to [my_key_id] -R [hidden_recipient_1] -R [hidden_recipient_2] -eat test.txt and then decrypt the encrypted file as per the following: gpg test2.txt the output looks like the following: C:\GnuPG>gpg test2.txt gpg: anonymous recipient; trying secret key 25A8679F ... gpg: anonymous recipient; trying secret key 25A8679F ... You need a passphrase to unlock the secret key for user: "Joe Vender " 4096-bit ELG-E key, ID 25A8679F, created 2005-12-14 (main key ID 23F3119B) gpg: encrypted with ELG-E key, ID 00000000 gpg: encrypted with ELG-E key, ID 00000000 gpg: encrypted with 4096-bit ELG-E key, ID 25A8679F, created 2005-12-14 "Joe Vender " gpg: test2.txt: unknown suffix Enter new filename [test.txt]: test3.txt Notice that it first states that it's trying my secret key and gives an anonymous prompt. But, even after I've entered my passphrase correctly after the first anonymous prompt, it asks for it again with the non-anonymous prompt. When encrypting to any number of anonymous recipients while also encrypting non-anonymously to a key (or multiple keys) that I own, why does it do the anonymous stuff before first checking to see if any given KeyIDs (keyIDs sent with the encrypted block) belong to keys that I own and have the secret key to on my ring? It looks like it should first check to see if any given KeyIDs belong to a keypair on my ring, and if so, start with the non-anonymous prompt for the passphrase of the first key I own of which the message was encrypted to, skipping the anonymous prompt. In any case, why didn't it accept my passphrase after the very first anonymous prompt in which it stated it was trying my secret key? *** *** *** Also, another possible bug in GnuPG: If the command line I send for decryption of the encrypted text file listed above is: gpg --status-fd 1 test2.txt The output looks like: C:\GnuPG>gpg --status-fd 1 test2.txt [GNUPG:] ENC_TO 0000000000000000 16 0 gpg: anonymous recipient; trying secret key 25A8679F ... [GNUPG:] USERID_HINT 60867A9925A8679F Joe Vender [GNUPG:] NEED_PASSPHRASE 60867A9925A8679F 60867A9925A8679F 16 0 [GNUPG:] GOOD_PASSPHRASE [GNUPG:] ENC_TO 0000000000000000 16 0 gpg: anonymous recipient; trying secret key 25A8679F ... [GNUPG:] USERID_HINT 60867A9925A8679F Joe Vender [GNUPG:] NEED_PASSPHRASE 60867A9925A8679F 60867A9925A8679F 16 0 [GNUPG:] GOOD_PASSPHRASE [GNUPG:] ENC_TO 60867A9925A8679F 16 0 [GNUPG:] USERID_HINT 60867A9925A8679F Joe Vender [GNUPG:] NEED_PASSPHRASE 60867A9925A8679F 70BD436E23F3119B 16 0 You need a passphrase to unlock the secret key for user: "Joe Vender " 4096-bit ELG-E key, ID 25A8679F, created 2005-12-14 (main key ID 23F3119B) Enter passphrase: Notice that it starts with an anonymous prompt in which it states that its trying my secret key, and, after I enter the correct passphrase for my key, it reports the passphrase was good and again asks for the passphrase for my secret key with an anonymous prompt! After I enter my passphrase correctly for the second prompt, it again asks for my passphrase but with a non-anonymous prompt! [Note: I'm not caching my passphrase] Apparently, when status-fd 1 is sent during decryption as above, it will give multiple anonymous prompts even if your passphrase is entered correctly, the number of prompts equal to the number of anonymous recipients, followed by on final non-anonymous prompt listing your key details if you happened to encrypt to yourself non-anonymously. One last thing to note. If I have "throw-keyids" in my gpg.conf, then even if I have my own KeyID after an "--encrypt-to" on the command line, the first decryption attempt either succeeds or fails after entering the passphrase in the first anonymous prompt depending upon whether it was entered correctly or not. That is, UNLESS THE DECRYPTION COMMAND LINE INCLUDES --status-fd in which case it gives a prompt for each recipient encrypted to. BUG From wk at gnupg.org Tue Jan 10 15:50:31 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 10 15:57:33 2006 Subject: Bug in GnuPG In-Reply-To: <000501c615d8$43b82a60$971387d8@net> (Joe Vender's message of "Tue, 10 Jan 2006 05:23:11 -0600") References: <000501c615d8$43b82a60$971387d8@net> Message-ID: <878xto2l3c.fsf@wheatstone.g10code.de> On Tue, 10 Jan 2006 05:23:11 -0600, Joe Vender said: > When encrypting to any number of anonymous recipients while also encrypting > non-anonymously to a key (or multiple keys) that I own, why does it do the > anonymous stuff before first checking to see if any given KeyIDs (keyIDs > sent with the encrypted block) belong to keys that I own and have the secret > key to on my ring? It looks like it should first check to see if any given The reason is simple: gpg does not build up a list of possible keys but processes the keys as they come. This allows to stop checking for key as soon as a valid one has been found. Yes, this could be changed but it would be a larger change. > C:\GnuPG>gpg --status-fd 1 test2.txt > [GNUPG:] ENC_TO 0000000000000000 16 0 > gpg: anonymous recipient; trying secret key 25A8679F ... > [GNUPG:] USERID_HINT 60867A9925A8679F Joe Vender > [GNUPG:] NEED_PASSPHRASE 60867A9925A8679F 60867A9925A8679F 16 0 > [GNUPG:] GOOD_PASSPHRASE This means that the passphrase for the key 60867A9925A8679F was good but does not say anything on whether this secret key was able to decrypt the message. > [GNUPG:] ENC_TO 0000000000000000 16 0 > gpg: anonymous recipient; trying secret key 25A8679F ... Well, the message has not been encrypted to your key. Now gpg continues with the second hidden recipient > [GNUPG:] USERID_HINT 60867A9925A8679F Joe Vender > [GNUPG:] NEED_PASSPHRASE 60867A9925A8679F 60867A9925A8679F 16 0 > [GNUPG:] GOOD_PASSPHRASE > [GNUPG:] ENC_TO 60867A9925A8679F 16 0 Same result as above. > [GNUPG:] USERID_HINT 60867A9925A8679F Joe Vender > [GNUPG:] NEED_PASSPHRASE 60867A9925A8679F 70BD436E23F3119B 16 0 > You need a passphrase to unlock the secret key for > user: "Joe Vender " > 4096-bit ELG-E key, ID 25A8679F, created 2005-12-14 (main key ID 23F3119B) The third (non-hidden) recipient matches your key. > Apparently, when status-fd 1 is sent during decryption as above, it will > give multiple anonymous prompts even if your passphrase is entered > correctly, the number of prompts equal to the number of anonymous Right, there is no passphrase caching. > entered correctly or not. That is, UNLESS THE DECRYPTION COMMAND LINE > INCLUDES --status-fd in which case it gives a prompt for each recipient > encrypted to. That is so that frontends are able to show more information about the messages. Shalom-Salam, Werner From wk at gnupg.org Tue Jan 10 15:53:23 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 10 15:57:39 2006 Subject: GnuPG 1.4.3-cvs make warning under mingw In-Reply-To: <200601100538260940.007DD770@216.135.2.37> (Joe Vender's message of "Tue, 10 Jan 2006 05:38:26 -0600") References: <200601100538260940.007DD770@216.135.2.37> Message-ID: <874q4c2kyk.fsf@wheatstone.g10code.de> On Tue, 10 Jan 2006 05:38:26 -0600, Joe Vender said: > iobuf.c: In function `iobuf_get_fd': > iobuf.c:1930: warning: return makes integer from pointer without a cast Doesn't harm on 32 bit Windows. Salam-Shalom, Werner From jvender at owensboro.net Tue Jan 10 19:48:34 2006 From: jvender at owensboro.net (Joe Vender) Date: Tue Jan 10 19:49:34 2006 Subject: Bug in GnuPG In-Reply-To: <878xto2l3c.fsf@wheatstone.g10code.de> References: <000501c615d8$43b82a60$971387d8@net> <878xto2l3c.fsf@wheatstone.g10code.de> Message-ID: <200601101248340340.00194EBF@216.135.2.37> On 1/10/06 at 3:50 PM Werner Koch wrote: >> C:\GnuPG>gpg --status-fd 1 test2.txt >> [GNUPG:] ENC_TO 0000000000000000 16 0 >> gpg: anonymous recipient; trying secret key 25A8679F ... >> [GNUPG:] USERID_HINT 60867A9925A8679F Joe Vender > >> [GNUPG:] NEED_PASSPHRASE 60867A9925A8679F 60867A9925A8679F 16 0 >> [GNUPG:] GOOD_PASSPHRASE > >This means that the passphrase for the key 60867A9925A8679F was good >but does not say anything on whether this secret key was able to >decrypt the message. My point is that the secret key that its asking the passphrase for should be able to decrypt the message, since it's the same secret key as the one for the last, non-anonymous prompt. The message WAS encrypted to this secret key. Its the only secret key on my ring for this test. So, why doesn't it decrypt the message after the first anonymous prompt? > >> [GNUPG:] ENC_TO 0000000000000000 16 0 >> gpg: anonymous recipient; trying secret key 25A8679F ... > >Well, the message has not been encrypted to your key. Now gpg >continues with the second hidden recipient > Yes, the message was encrypted to my key. If it's not going to actually use my passphrase to try to decrypt the message, why ask for it? >> [GNUPG:] USERID_HINT 60867A9925A8679F Joe Vender > >> [GNUPG:] NEED_PASSPHRASE 60867A9925A8679F 60867A9925A8679F 16 0 >> [GNUPG:] GOOD_PASSPHRASE >> [GNUPG:] ENC_TO 60867A9925A8679F 16 0 > >Same result as above. Same question as above. > >> [GNUPG:] USERID_HINT 60867A9925A8679F Joe Vender > >> [GNUPG:] NEED_PASSPHRASE 60867A9925A8679F 70BD436E23F3119B 16 0 > >> You need a passphrase to unlock the secret key for >> user: "Joe Vender " >> 4096-bit ELG-E key, ID 25A8679F, created 2005-12-14 (main key ID >23F3119B) > >The third (non-hidden) recipient matches your key. Then why, if instead of encrypting to myself non-anonymously, I encrypt to myself anonymously along with the other anonymous recipients, I only get the anonymous passphrase prompt once, and upon successful passphrase entry it goes through the "anonymous recipient: trying secret key [my_secret_keyid]" as many times as there are recipients without asking for it again, and decrypts the message? > >> Apparently, when status-fd 1 is sent during decryption as above, it will >> give multiple anonymous prompts even if your passphrase is entered >> correctly, the number of prompts equal to the number of anonymous > >Right, there is no passphrase caching. > >> entered correctly or not. That is, UNLESS THE DECRYPTION COMMAND LINE >> INCLUDES --status-fd in which case it gives a prompt for each recipient >> encrypted to. > >That is so that frontends are able to show more information about the >messages. > > I don't understand. If the message was encrypted to my key, and the anonymous prompt states that its checking my key, then why doesn't it decrypt the message after I enter the passphrase correctly? From wk at gnupg.org Tue Jan 10 21:38:51 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 10 22:09:10 2006 Subject: Bug in GnuPG In-Reply-To: <200601101248340340.00194EBF@216.135.2.37> (Joe Vender's message of "Tue, 10 Jan 2006 12:48:34 -0600") References: <000501c615d8$43b82a60$971387d8@net> <878xto2l3c.fsf@wheatstone.g10code.de> <200601101248340340.00194EBF@216.135.2.37> Message-ID: <87wth7yg10.fsf@wheatstone.g10code.de> On Tue, 10 Jan 2006 12:48:34 -0600, Joe Vender said: > the one for the last, non-anonymous prompt. The message WAS encrypted > to this secret key. Its the only secret key on my ring for this test. So, > why doesn't it decrypt the message after the first anonymous prompt? Because it has not yet seen a session key encrypted to you. I agree that it would be better to try the known keys first. > Yes, the message was encrypted to my key. If it's not going to actually > use my passphrase to try to decrypt the message, why ask for it? It tried. For hidden recipients we need to do tria decryptions and thus we need the passpharse of all secret keys available. > Then why, if instead of encrypting to myself non-anonymously, I encrypt to myself > anonymously along with the other anonymous recipients, I only get the anonymous > passphrase prompt once, and upon successful passphrase entry it goes through the > "anonymous recipient: trying secret key [my_secret_keyid]" as many times as there That message is a diagnostic to tell that there is a hidden recipient. > I don't understand. If the message was encrypted to my key, and the anonymous prompt states that its checking my key, then why doesn't it decrypt the message after I enter the passphrase correctly? Look at such a message PK_hidden_recipient_1(session_key) PK_hidden_recipient_2(session_key) PK_joe_vender(session_key) ENC_session_key(message) gpg sees tehse packages one after the other. So first we have a public key encrypted session key encrypted to the hidden_recipient_1. Obviously we don't known ahead which secret key to use for a hidden recipient. Thus we do trial decryptions for a in secring.gpg do PKDECRYPT_a (PK_hidden_recipient_1(session_key)) done if this succeeded with one of the secret keys, we are done and stop. However it didn't worked and we can conclude that the hidden_recipients is not one of the keys in secring.gpg. Now we go on and do the same, this time: for a in secring.gpg do PKDECRYPT_a (PK_hidden_recipient_2(session_key)) done Same result as above. Now we are at the third packet and gpg instantly knows that it can do a = secring.gpg(joe_vender) PKDECRYPT_a (PK_joe_vender(session_key)) You are asked for the passphrase several times because each PKDECRYPT operation requires a passphrase to prepare the key for the actual decryption. Salam-Shalom, Werner From jvender at owensboro.net Wed Jan 11 06:09:16 2006 From: jvender at owensboro.net (Joe Vender) Date: Wed Jan 11 06:10:35 2006 Subject: Bug in GnuPG In-Reply-To: <87wth7yg10.fsf@wheatstone.g10code.de> References: <000501c615d8$43b82a60$971387d8@net> <878xto2l3c.fsf@wheatstone.g10code.de> <200601101248340340.00194EBF@216.135.2.37> <87wth7yg10.fsf@wheatstone.g10code.de> Message-ID: <200601102309160240.003EDEAB@216.135.2.37> >On 1/10/06 at 9:38 PM Werner Koch wrote: >On Tue, 10 Jan 2006 12:48:34 -0600, Joe Vender said: > >> Then why, if instead of encrypting to myself non-anonymously, I encrypt to >> myself anonymously along with the other anonymous recipients, I only get the >> anonymous passphrase prompt once, and upon successful passphrase entry it goes >> through the "anonymous recipient: trying secret key [my_secret_keyid]" as many >> times as there > >That message is a diagnostic to tell that there is a hidden recipient. Yes, I understand that the message is telling me that it's trying my secret key on the session key that its checking, but why am I only asked once in this situation, but once for each recipient when I'm included non-anonymously? >You are asked for the passphrase several times because each PKDECRYPT >operation requires a passphrase to prepare the key for the actual >decryption. Then this must mean that when I am encrypting to multiple anonymous recipients including myself anonymously, GnuPG always puts my session_key at the top. Otherwise, by this reasoning, I would keep getting anonymous prompts until it encountered my session_key. And it also appears that GnuPG puts the known recipients at the end. This is backwards. >On 1/10/06 at 9:38 PM Werner Koch wrote: Also, as an example, lets say I encrypt to 100 anonymous recipients and include myself non-anonymously. Then, I would get 100 anonymous prompts in a row,even if I entered my passphrase correctly each time. This isn't reasonable. GnuPG needs to either put my session keys at the very top of the list regardless of whether I'm including myself anonymously or non-anonymously, or have the ability to cache the passphrase (possibly via a switch "--cache-passphrase") to be supplied automatically for each anonymous prompt until the decryption process either fails due to lack of decryption key, or passes, at which point the passphrase is automatically cleared from cache. Joe From kfitzner at excelcia.org Wed Jan 11 14:35:58 2006 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Wed Jan 11 14:35:43 2006 Subject: Bug in GnuPG In-Reply-To: <200601102309160240.003EDEAB@216.135.2.37> References: <000501c615d8$43b82a60$971387d8@net> <878xto2l3c.fsf@wheatstone.g10code.de> <200601101248340340.00194EBF@216.135.2.37> <87wth7yg10.fsf@wheatstone.g10code.de> <200601102309160240.003EDEAB@216.135.2.37> Message-ID: <43C509BE.7070303@excelcia.org> It seems to me that the loop nesting just needs to be reversed. It seems like the way GnuPG works is that it has a list of session keys, and a list of private keys. It then iterates through the list of session keys and tries to see if any private key matches. This makes it so that if the session key is anonymous, it has to ask for each private key passphrase in turn, and do this for each and every session key. If the logic were reversed, this would be avoided. Iterate through the private keys first, then test each private key to see if it will decrypt a session key. The passphrase is asked for once for each private key instead of for each session key times the number of private keys. ie: right now, it works this way for (int s = 0; s < NumSessionKeys; s++) { for (int k = 0; k < NumPrivateKeys; k++) { char *PassPhrase = GetPassphrase(PrivateKeyList[k]); if (DecryptSessionKey(SessionKeyList[s], PassPhrase)) /* decrypt message here */ } } Perhaps it would be better like this: for (int k = 0; k < NumPrivateKeys; k++) { char *PassPhrase = GetPassphrase(PrivateKeyList[k]); for (int s = 0; s < NumSessionKeys; s++) { if (DecryptSessionKey(SessionKeyList[s], PassPhrase)) /* decrypt message here */ } } That's a terrible simplification, but it seems to me like the logic works better this way. Kurt. p.s. Would it be possible to get the reply-to for the GnuPG mailing lists set to the list address? :p -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 305 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060111/e8dadc62/signature.pgp From jvender at owensboro.net Wed Jan 11 15:37:41 2006 From: jvender at owensboro.net (Joe Vender) Date: Wed Jan 11 15:38:33 2006 Subject: Bug in GnuPG Message-ID: <200601110837410460.005A0E77@216.135.2.37> When someone else encrypts to multiple anonymous recipients including myself, my own hidden_recipient(session_key) could potentially be anywhere from the beginning to the end of the list. So, unless the way GnuPG recurses through the lists (see suggestion by Kurt Fitzner) is changed if possible, or my passphrase is cached after the first entry and automatically resubmitted until the decryption process either succeeds or fails, I will still get multiple, possible very many, anonymous passphrase prompts until my hidden_recipient(session_key) is encountered. Also, many users will not be willing, or at least prefer not, to cache the passphrase due to security concerns. There must be a better way of handling this. It seems to me that changing the recursion scheme is the best approach. If Kurt's approach is possible, it would also eliminate the need to make sure my hidden recipient(session_key) is at the top of the list on messages which I encrypt anonymously to others while including myself, since it would first ask for my passphrase and then move through the hidden_recipient(session_key) list until it encountered the one that matched the right key to decrypt the message. Joe From wk at gnupg.org Wed Jan 11 16:40:09 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Jan 11 16:47:04 2006 Subject: Bug in GnuPG In-Reply-To: <200601110837410460.005A0E77@216.135.2.37> (Joe Vender's message of "Wed, 11 Jan 2006 08:37:41 -0600") References: <200601110837410460.005A0E77@216.135.2.37> Message-ID: <871wzeojs6.fsf@wheatstone.g10code.de> On Wed, 11 Jan 2006 08:37:41 -0600, Joe Vender said: > prompts until my hidden_recipient(session_key) is encountered. Also, many > users will not be willing, or at least prefer not, to cache the passphrase > due to security concerns. There must be a better way of handling this. It Caching the passphrase for a few minutes is just fine. The passphrase itself is mainly a protection against stolen disks or alike. Any key logger will be able to log the passphrase and by entering it many times over a day it will be even easier to figure out the passphrase. I consider gpg-agent/pinentry-gtk on a local X-sever more secure than the passphrase prompt of gpg. > would first ask for my passphrase and then move through the > hidden_recipient(session_key) list until it encountered the one that > matched the right key to decrypt the message. As already mentioned, there is no immediate list of public key encrypted packages - they are processed one after the other without any look-ahead. I just checked the code and a possible way to implement it is be queuing up the hidden publick key encrypted packets and process them only after all other packets failed. However this is still a too intrusive change for now. It won't help the passphrase caching problem. The memory used for for storing the unprotected secret keys (after the passphrase has been presented) is a scare resource and thus we can't keep them them unprotected for a logn time. It is even a design goal to keep secret stuff as short as possible unprotected. gpg-agent/pinentry solves this problem. Salam-Shalom, Werner From wk at gnupg.org Wed Jan 11 16:41:30 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Jan 11 16:47:14 2006 Subject: Bug in GnuPG In-Reply-To: <43C509BE.7070303@excelcia.org> (Kurt Fitzner's message of "Wed, 11 Jan 2006 06:35:58 -0700") References: <000501c615d8$43b82a60$971387d8@net> <878xto2l3c.fsf@wheatstone.g10code.de> <200601101248340340.00194EBF@216.135.2.37> <87wth7yg10.fsf@wheatstone.g10code.de> <200601102309160240.003EDEAB@216.135.2.37> <43C509BE.7070303@excelcia.org> Message-ID: <87wth6n55h.fsf@wheatstone.g10code.de> On Wed, 11 Jan 2006 06:35:58 -0700, Kurt Fitzner said: > p.s. Would it be possible to get the reply-to for the GnuPG mailing > lists set to the list address? :p No way. Reply-to considered harmful. You need to use the command for answering list mails (or Group reply). Shalom-Salam, Werner From kfitzner at excelcia.org Fri Jan 13 18:35:13 2006 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Fri Jan 13 21:51:22 2006 Subject: [Announce] GPGee version 1.3.0 Released Message-ID: <43C7E4D1.4070400@excelcia.org> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From kfitzner at excelcia.org Mon Jan 16 08:33:48 2006 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Mon Jan 16 08:33:26 2006 Subject: Please filter out duplicate keyrings Message-ID: <43CB4C5C.4090905@excelcia.org> I have requested this before, and was turned down. However, this is becoming more and more of an issue, so I would like to ask please that GnuPG be modified to filter out duplicate keyrings. I do not believe it would be a technical challenge for GnuPG to add filtering. It only requires filtering by the canonical filename of the keyring, not by key. At the very least, perhaps an explicit keyring can be ignored if it matches the default keyring. This should catch 99.9% of all keyring duplications. As it stands, all it takes to get duplicate keys from GnuPG is to explicitely add a keyring entry to gpg.conf that is also the default keyring. This is not an unreasonable thing for a person to do. I have helped users complaining of duplicate keys more than once in several front ends. The last was just a week ago: http://tinyurl.com/d5d2a It is a real challenge for me with GPGee to deal with duplicate keys. The obvious answer is just to filter them out, which I do. But I have found that the library I use assumes that when a single key is asked for from GnuPG that a single key will be given. It is not trivial to fix this assumption. Because of the read buffering, GPGee can handle this if the keys are small (in this case small means few user ids and signatures). If the key is complex with many signatures (PGP global directory trash), then GPGee hangs. While duplicate keys is not a bug per se, asking for a single key by fingerprint and getting it twice violates at least the spirit of what you are asking gpg to do. If nothing more than as a personal favor to me and perhaps other front-end authors, can GnuPG please be patched to filter out duplicates. Kurt. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 305 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060116/0ef779ee/signature.pgp From ossi at kde.org Sat Jan 14 14:14:05 2006 From: ossi at kde.org (Oswald Buddenhagen) Date: Mon Jan 16 09:52:25 2006 Subject: SSO, *-agent & PAM Message-ID: <20060114131405.GA7257@ugly.local> moin *, sorry for the cross-post; follow-ups should go to xdg@ (the only one of those lists i'm subscribed to). i'm pondering with the idea to implement SingleSignOn based on an authentication agent like the ones employed by ssh and gnupg. the system would consist of the two main components: - fdo-keyagent, certainly a d-bus service - pam_keyagent. a PAM module that would authenticate users by unlocking their key(s) (which one(s), has to be preconfigured somehow - ~/.config/keyagent maybe?) and adding them to the agent's cache. - it might make sense to create libkeyagent that would provide functions for key retrieval, etc. i'm not sure whether it would be better to embed ssh-add's equivalent into the agent or into such a library. the key agent would send notifications when keys exceed their lifetime. in fact, this is a major missing component of PAM. in this context it might even make sense to create meta-entries for kerberos tokens and even unix passwords (with close relation to pam_time/pam_group). end-user/desktop applications (password managers, ssh, gpg, etc.) would use the keys stored in the agent - obviously. a buzz word that comes to mind is x.509 compliance, but i really have no idea what that would include. as far as security goes, i really need some input. possible concerns: - having a central agent for all users might be frowned upon. one could make the agent fork a sub-agent for each user, but this would require some elaborate IPC. plan b is to make fdo-keyagent a meta-agent that would spawn ssh-agents, gpg-agents, etc. on demand, ref-count them and do other housekeeping. even more "interesting" IPC. - apps using PAM traditionally have been bad at using mlock, and i wouldn't know how to fix this. what do the security experts think about this issue? - having the d-bus daemon in between doesn't exactly help, either. maybe it would make sense to use d-bus for the protocol only and setup dedicated connections for passphrase and key transfers. i'm interested in any kind of useful comments, including pointers to prior art in that area and papers worth reading. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From martin.konold at erfrakon.de Mon Jan 16 15:07:26 2006 From: martin.konold at erfrakon.de (Martin Konold) Date: Mon Jan 16 16:49:48 2006 Subject: SSO, *-agent & PAM In-Reply-To: <20060114131405.GA7257@ugly.local> References: <20060114131405.GA7257@ugly.local> Message-ID: <200601161507.28921.martin.konold@erfrakon.de> Am Samstag, 14. Januar 2006 14:14 schrieb Oswald Buddenhagen: Hi, > i'm interested in any kind of useful comments, including pointers to > prior art in that area and papers worth reading. You may check kwallet and GPG pinentry. Sofar I was unable to convince the GPG developers to use a single SSO keyring application. Regards, -- martin -- http://www.erfrakon.com/ Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker From nelg at linuxsolutions.co.nz Tue Jan 17 02:48:23 2006 From: nelg at linuxsolutions.co.nz (Glen Ogilvie) Date: Tue Jan 17 04:48:21 2006 Subject: gpg-agent in windows Message-ID: Hi, Does anyone have a compiled binary of gpg and gpg-agent that works on MS windows? I've written an application in perl, which uses GPG to decrypt various config files. In linux, this works well, as it can use gpg-agent so the user is not prompted all the time for their passphrase. However, under windows, when I try gpg --use-agent, in gpg 1.4.2, it tells me it's unsupported, and I don't have a gpg-agent.exe binary. Does the development version, 1.9.20 have gpg-agent and gpg that will compile on windows. Thanks Glen Ogilvie From JPClizbe at comcast.net Tue Jan 17 06:56:06 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Tue Jan 17 07:51:59 2006 Subject: gpg-agent in windows In-Reply-To: References: Message-ID: <43CC86F6.5050101@comcast.net> Glen Ogilvie wrote: > Hi, > > Does anyone have a compiled binary of gpg and gpg-agent that works on > MS windows? > > I've written an application in perl, which uses GPG to decrypt various > config files. In linux, this works well, as it can use gpg-agent so > the user is not prompted all the time for their passphrase. > > However, under windows, when I try gpg --use-agent, in gpg 1.4.2, it tells > me it's unsupported, and I don't have a gpg-agent.exe binary. Does the > development version, 1.9.20 have gpg-agent and gpg that will compile on > windows. I'm in the process of building the dependency libraries for GnuPG 1.9 at the moment (which includes gpg-agent) on Windows. So far, it's not too promising. I may punt and try a Cygwin build first. There's a windows binary in ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.9.14.zip You may wish to try a mirror. I haven't been able to access the server via FTP. http://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.9.14.zip seems to work. -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 669 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060116/dfb40b56/signature.pgp From wk at gnupg.org Tue Jan 17 08:34:44 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 17 08:36:50 2006 Subject: gpg-agent in windows In-Reply-To: (Glen Ogilvie's message of "Tue, 17 Jan 2006 14:48:23 +1300 (NZDT)") References: Message-ID: <87zmlvl33f.fsf@wheatstone.g10code.de> On Tue, 17 Jan 2006 14:48:23 +1300 (NZDT), Glen Ogilvie said: > However, under windows, when I try gpg --use-agent, in gpg 1.4.2, it tells > me it's unsupported, and I don't have a gpg-agent.exe binary. Does the > development version, 1.9.20 have gpg-agent and gpg that will compile on In theory that will work, there is even a very experimental pinentry for W32 in the pinentry SVN. Whether 1.9.20 can be build for W32 is not clear; I have not done such a build for more than a year and the version then was only useful for server applications. Shalom-Salam, Werner From anthony.metcalf at anferny.ath.cx Tue Jan 17 10:00:11 2006 From: anthony.metcalf at anferny.ath.cx (Anthony Metcalf) Date: Tue Jan 17 11:48:14 2006 Subject: gpg-agent in windows In-Reply-To: References: Message-ID: <20060117090011.55cd6854@gentoo> On Tue, 17 Jan 2006 14:48:23 +1300 (NZDT) Glen Ogilvie wrote: > I've written an application in perl, which uses GPG to decrypt > various config files. In linux, this works well, as it can use > gpg-agent so the user is not prompted all the time for their > passphrase. Would it not be possible to have the script use pagent, the agent from putty, when in windows? Possibly by renaming the pagent binary in windows? I use svn in windows and have it working using pagent so I don't have to re-key my pass phrase. Kind Regards Anthony -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060117/d91bce05/signature.pgp From wk at gnupg.org Tue Jan 17 18:21:10 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 17 18:26:57 2006 Subject: gpg-agent in windows In-Reply-To: <20060117090011.55cd6854@gentoo> (Anthony Metcalf's message of "Tue, 17 Jan 2006 09:00:11 +0000") References: <20060117090011.55cd6854@gentoo> Message-ID: <87hd823h4p.fsf@wheatstone.g10code.de> On Tue, 17 Jan 2006 09:00:11 +0000, Anthony Metcalf said: > Would it not be possible to have the script use pagent, the agent from > putty, when in windows? Unlikely, I doubt that this tool speaks the same protocol. To the contrary, gpg-agent speaks ssh's protocol in addition to its native protocol. Salam-Shalom, Werner From nelg at linuxsolutions.co.nz Tue Jan 17 20:51:02 2006 From: nelg at linuxsolutions.co.nz (Glen Ogilvie) Date: Tue Jan 17 20:50:55 2006 Subject: gpg-agent in windows In-Reply-To: <43CC86F6.5050101@comcast.net> References: <43CC86F6.5050101@comcast.net> Message-ID: <200601180851.02991.nelg@linuxsolutions.co.nz> On Tuesday 17 January 2006 18:56, John Clizbe wrote: > > I'm in the process of building the dependency libraries for GnuPG 1.9 at > the moment (which includes gpg-agent) on Windows. So far, it's not too > promising. I may punt and try a Cygwin build first. > Sounds good. Do you have an estimate of when you expect to have a build complete? > There's a windows binary in > ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.9.14.zip Yes, I've had a look at that. It has a gpg-agent.exe, but does not have a gpg.exe, so I am unsure as to how I should use it. If I run the gpg-agent, it gives me a GPG_AGENT_INFO variable, but the packages does not seem to have any client that can use this, except for maybe gpgsm, which does not seem to be able to do much, I think, because 1.9.14 is still very much alpha and quite old. Regards Glen Ogilvie New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060118/c98351f1/attachment.pgp From wk at gnupg.org Wed Jan 18 11:06:31 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Jan 18 11:11:52 2006 Subject: gpg-agent in windows In-Reply-To: <200601180851.02991.nelg@linuxsolutions.co.nz> (Glen Ogilvie's message of "Wed, 18 Jan 2006 08:51:02 +1300") References: <43CC86F6.5050101@comcast.net> <200601180851.02991.nelg@linuxsolutions.co.nz> Message-ID: <87psmp26l4.fsf@wheatstone.g10code.de> On Wed, 18 Jan 2006 08:51:02 +1300, Glen Ogilvie said: > packages does not seem to have any client that can use this, except for maybe > gpgsm, which does not seem to be able to do much, I think, because 1.9.14 is Yes, gpgsm is the reasons why I did the port at all. The stuff is currently used in a server environment to encrypt/decrypt large S/MIME messages. It works, but it is hard to setup. Quite possible that gpg has not been converted. You may take the gpg-agent from that package and modify a gpg 1.4 for Windows. The main thing to do is to add the socket emulation (gnupg-1.9/util/w32_afunix.[ch]). Of course it would be better to trun the gpg-agent into a system service. Salam-Shalom, Werner From alan.watt at per-se.com Thu Jan 19 16:11:23 2006 From: alan.watt at per-se.com (Alan Watt) Date: Thu Jan 19 20:48:33 2006 Subject: Decrypt error: "gpg: block_filter: 1st length byte missing" Message-ID: <43CFAC1B.7090100@per-se.com> I get this error several times a week, out of a decryption volume of about 10,500 files per week. The verbose output is: =========================================== gpg: public key is 268C2A61 [GNUPG:] ENC_TO 60019F71268C2A61 16 0 gpg: using secondary key 268C2A61 instead of primary key B0B2EBAF [GNUPG:] USERID_HINT 60019F71268C2A61 [GNUPG:] NEED_PASSPHRASE 60019F71268C2A61 694D94E7B0B2EBAF 16 0 [GNUPG:] GOOD_PASSPHRASE gpg: using secondary key 268C2A61 instead of primary key B0B2EBAF gpg: encrypted with 2048-bit ELG-E key, ID 268C2A61, created 1999-11-04 "" [GNUPG:] BEGIN_DECRYPTION gpg: CAST5 encrypted data gpg: original file name='ED_32509.hpf' [GNUPG:] PLAINTEXT 62 0 ED_32509.hpf gpg: block_filter: 1st length byte missing [GNUPG:] DECRYPTION_OKAY gpg: WARNING: message was not integrity protected [GNUPG:] END_DECRYPTION =========================================== I have an old (version 5) copy of PGP we use as a backup if GPG fails. This decrypts the same files without complaint. Usually the GPG output is identical to the PGP output, and in the cases where the file has some kind of text structure I can examine, it appears intact. That is, it appears this is a false alarm. The production system is still using GPG 1.0.6, but I have confirmed the same results on a test system with GPG 1.2.6. This happens with files from a number of different sending partners, and using several different public keys (in other words, it does not appear to be limited to one particular encryption implementation or key). In the past I have run into this error when the encrypted file contained extra NUL characters at the end, due to incorrect FTP record size parameters when passing through a mainframe system, but these files do not appear to have that problem. I did not see any mention of this problem being identified and fixed in the bug notes. Does anyone have any insight on this? I want to toss the old PGP software completely, but I can't as long as I keep getting these errors. From dshaw at jabberwocky.com Thu Jan 19 21:10:58 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Jan 19 21:58:43 2006 Subject: Decrypt error: "gpg: block_filter: 1st length byte missing" In-Reply-To: <43CFAC1B.7090100@per-se.com> References: <43CFAC1B.7090100@per-se.com> Message-ID: <20060119201058.GA31770@jabberwocky.com> On Thu, Jan 19, 2006 at 10:11:23AM -0500, Alan Watt wrote: > In the past I have run into this error when the encrypted file > contained extra NUL characters at the end, due to incorrect FTP > record size parameters when passing through a mainframe system, but > these files do not appear to have that problem. Another way FTP can mangle things is the files being sent in ASCII rather than binary mode. FTP will try and do line ending conversion and break things. Alternately, you might try asking your sending partners to send ASCII-armored (--armor) messages which are mostly immune to this sort of transport mangling. David From list-gnupg at legroom.net Fri Jan 20 20:25:45 2006 From: list-gnupg at legroom.net (Jared) Date: Sat Jan 21 00:18:12 2006 Subject: New GnuPG Installer Message-ID: <43D13939.2030803@legroom.net> Hello. I've written a new installer for the Windows GnuPG binaries that I'd like to share with the group. Before I get into any details, I'd like to briefly explain why I did it. I know that an official installer already exists as of 1.4.1, and that (from searching the list archives) the general feeling about installer changes is to modify/improve the current installer rather than create a new one. However, I felt that there were a few weaknesses with the official installer that made it unsuitable for my needs. Specifically, this includes: 1. Inability to perform a proper silent install/deployment - While I can specify /S file silent and /D to set the output directory, that's all NSIS supports. I cannot enable/disable specific components, I cannot choose to install not start menu icons, and I cannot specify the language or any other options. 2. Missing/Incomplete installer options - There are three specific customizations I feel that the installer should perform - language selection, homedir selection, and setting default language. The language option is present in the NSIS installer, but it feels a bit awkward, and doesn't integrate with the installer language selection. 3. Based on NSIS - I know this seems like an odd complaint, but I find NSIS installers woefully advanced-user-unfriendly. As mentioned in point 1, it supports very few command line options, placing the burden on the developer to add the necessary capabilities, and setup files cannot be unpacked without performing a complete installation. The general user, of course, wouldn't be affected by this, but any developers or administrators working with GnuPG may be unnecessarily inconvenienced. I could, of course, write a script to make these customizations after installation, but then the installer itself wouldn't know about them. Upon uninstallation things would get left behind, during upgrades or reinstalls preferences would get overwritten, etc. Because of all of these reasons, I felt it would be best create a new installer that includes all of the capabilities mentioned above, and using a more user-friendly packager than NSIS. So, I turned to Inno Setup, a Free, Open Source Windows packaging application with which I already have fairly extensive experience. The new installer supports all of the features of the original installer, plus the following: * Installer translations for all GPG-supported languages, except Esperanto * GnuPG language selection integration with installer * Ability to specify home directory * Ability to add GnuPG to system path * Ability to specify language and home directory via command line options * Large number of silent deployment options provided by Inno Setup I hope I've adequately explained by I wrote this new installer. Since I do feel that it would be beneficial to the GnuPG community at large, I wanted to share the installer script with this group. The installer, scripts, and source package can be downloaded from the following location (didn't want to add attachments to this e-mail since it's already pretty long): http://www.legroom.net/~jbreland/gnupg/ I hope you find this useful, and consider it for inclusion in the official GnuPG distribution. Comments and questions very much welcome. Thanks. -- Jared Breland GnuPG public key: jbreland@legroom.net http://www.legroom.net/jbreland.asc From JPClizbe at comcast.net Tue Jan 24 03:30:37 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Tue Jan 24 04:12:00 2006 Subject: [svn] gpg-error - r154 - in trunk: . po In-Reply-To: References: Message-ID: <43D5914D.5000200@comcast.net> no vi.po in checkout. Did it not get checked in? svn author wk wrote: > Author: wk > Date: 2006-01-11 20:28:08 +0100 (Wed, 11 Jan 2006) > New Revision: 154 > > Modified: > trunk/AUTHORS > trunk/NEWS > trunk/po/ChangeLog > trunk/po/LINGUAS > Log: > Add Vietnamese translation > > > Modified: trunk/AUTHORS > =================================================================== > --- trunk/AUTHORS 2005-11-02 10:10:28 UTC (rev 153) > +++ trunk/AUTHORS 2006-01-11 19:28:08 UTC (rev 154) > @@ -11,8 +11,11 @@ > Laurentiu Buzdugan > - TRANSLATION [ro] > > +Clytie Siddall > + - TRANSLATION [vi] > > > + > The RPM specs file libgpg-error.spec has been contributed by > Robert Schiele > > > Modified: trunk/NEWS > =================================================================== > --- trunk/NEWS 2005-11-02 10:10:28 UTC (rev 153) > +++ trunk/NEWS 2006-01-11 19:28:08 UTC (rev 154) > @@ -14,7 +14,7 @@ > > * New error code GPG_ERR_LOCKED. > > - * New translations included for France and Romania. > + * New translations included for France, Romania, and Vietnamese. > > * Interface changes relative to the 1.1 release: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Modified: trunk/po/ChangeLog > =================================================================== > --- trunk/po/ChangeLog 2005-11-02 10:10:28 UTC (rev 153) > +++ trunk/po/ChangeLog 2006-01-11 19:28:08 UTC (rev 154) > @@ -1,3 +1,8 @@ > +2006-01-11 Werner Koch > + > + * vi.po: New. > + * LINGUAS: Add vi. > + > 2005-09-29 Marcus Brinkmann > > * fr.po: New file. > > Modified: trunk/po/LINGUAS > =================================================================== > --- trunk/po/LINGUAS 2005-11-02 10:10:28 UTC (rev 153) > +++ trunk/po/LINGUAS 2006-01-11 19:28:08 UTC (rev 154) > @@ -3,3 +3,4 @@ > pl > ro > fr > +vi -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 669 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060123/a7d50275/signature.pgp From rdieter at math.unl.edu Tue Jan 24 15:45:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue Jan 24 15:45:39 2006 Subject: New GnuPG Installer In-Reply-To: <43D13939.2030803__20605.4322807633$1137799253$gmane$org@legroom.net> References: <43D13939.2030803__20605.4322807633$1137799253$gmane$org@legroom.net> Message-ID: Jared wrote: > 3. Based on NSIS - I know this seems like an odd complaint, but I find NSIS > installers woefully advanced-user-unfriendly. As mentioned in point 1, it ... > Because of all of these reasons, I felt it would be best create a new > installer that includes all of the capabilities mentioned above, and using a > more user-friendly packager than NSIS. So, I turned to Inno Setup, a Free, > Open Source Windows packaging application with which I already have fairly > extensive experience. I've done basically the same thing, but made an .msi installer for AD/Group Policy deployment at our site. http://www.math.unl.edu/~rdieter/Software/Windows/ Unfortunately, I've been using a mostly non-free tool, Advanced Installer, to make these. One of these days I'll have to learn to use wix. -- Rex From wk at gnupg.org Tue Jan 24 20:25:11 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 24 20:31:49 2006 Subject: [svn] gpg-error - r154 - in trunk: . po In-Reply-To: <43D5914D.5000200@comcast.net> (John Clizbe's message of "Mon, 23 Jan 2006 20:30:37 -0600") References: <43D5914D.5000200@comcast.net> Message-ID: <87r76x8m3s.fsf@wheatstone.g10code.de> On Mon, 23 Jan 2006 20:30:37 -0600, John Clizbe said: > no vi.po in checkout. Did it not get checked in? Oops. Just committed. Salam-Shalom, Werner From wk at gnupg.org Tue Jan 24 20:29:21 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 24 20:32:00 2006 Subject: New GnuPG Installer In-Reply-To: (Rex Dieter's message of "Tue, 24 Jan 2006 08:45:34 -0600") References: <43D13939.2030803__20605.4322807633$1137799253$gmane$org@legroom.net> Message-ID: <87lkx58lwu.fsf@wheatstone.g10code.de> On Tue, 24 Jan 2006 08:45:34 -0600, Rex Dieter said: > Unfortunately, I've been using a mostly non-free tool, Advanced > Installer, to make these. One of these days I'll have to learn to use wix. While we are at it: Our group also created a new installer which is kind of a met installer: You may use gpg4win to build your own installer with selected packages. The configure scripts checks what packages are available and creates a suitable installer as well as a second installer with the sources. www.gpg4win.org. Yes, NSIS based and no advanced options. If an admin needs a special version of an installer for a rollout he may build his own version and included versions of the software he actually likes; adding new parts is pretty simple. Shalom-Salam, Werner