From klos at radiologie.klinik.uni-mainz.de Tue Nov 2 10:08:23 2004 From: klos at radiologie.klinik.uni-mainz.de (Gordon Klos) Date: Tue Nov 2 10:12:13 2004 Subject: GnuPG --status-fd vs. Windows Message-ID: <41874E87.6010606@radiologie.klinik.uni-mainz.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm calling GnuPG from my Win32-Application to en-/decrypt and sign files. For logging the signature-check I need to parse the information piped to '--status-fd'. Using the file descriptor from an opened file doesn't work. Piping to stdout (1) and stderr (2) works fine. I investigated the sources and found the parameter '--status-file'. If I enable this for Windows and recompile gpg it does what I want. I think using a self compiled gpg isn't the best solution. I'd rather like to link to the gpg site for the newest release. Is there any reason that this parameter is only enabled for 'riscos' or could it be enabled for windows too in the 'official release'? With kind regards, Gordon Klos -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBh06B9MbKKPTphh4RApW6AJ9POkkI6NlTqSF5cpTnEca7mDxJiwCbBWdY ZGcjqQuP0HJVoxPCg5w1of4= =7uyy -----END PGP SIGNATURE----- From npcole at yahoo.co.uk Tue Nov 2 13:52:57 2004 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Tue Nov 2 13:49:57 2004 Subject: [Announce] GnuPG 1.3.92 released (development) In-Reply-To: <87d5z3c9dp.fsf@wheatstone.g10code.de> Message-ID: <20041102125257.15215.qmail@web25403.mail.ukl.yahoo.com> Built 1.3.92 for debian testing on i686 with no unusual options. -- Bug report: $ gpg --show-sig-subpackets --with-colons --list-sigs gpg: Invalid option "--show-sig-subpackets" -- Sorry for not providing a patch! I'm sure it's something simple. Also the file on rfc2440 in the doc directory provides a link to a page that doesn't exist. Best, N. ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From dshaw at jabberwocky.com Tue Nov 2 14:18:19 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Nov 2 14:15:46 2004 Subject: [Announce] GnuPG 1.3.92 released (development) In-Reply-To: <20041102125257.15215.qmail@web25403.mail.ukl.yahoo.com> References: <87d5z3c9dp.fsf@wheatstone.g10code.de> <20041102125257.15215.qmail@web25403.mail.ukl.yahoo.com> Message-ID: <20041102131819.GC2170@jabberwocky.com> On Tue, Nov 02, 2004 at 12:52:57PM +0000, Nicholas Cole wrote: > Built 1.3.92 for debian testing on i686 with no > unusual options. > > -- > Bug report: > > $ gpg --show-sig-subpackets --with-colons --list-sigs > gpg: Invalid option "--show-sig-subpackets" > -- show-sig-subpackets is a list-option. It is not an option itself. David From npcole at yahoo.co.uk Tue Nov 2 15:37:53 2004 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Tue Nov 2 15:34:55 2004 Subject: [Announce] GnuPG 1.3.92 released (development) In-Reply-To: <20041102131819.GC2170@jabberwocky.com> Message-ID: <20041102143753.91884.qmail@web25406.mail.ukl.yahoo.com> --- David Shaw wrote: > On Tue, Nov 02, 2004 at 12:52:57PM +0000, Nicholas > Cole wrote: > > Built 1.3.92 for debian testing on i686 with no > > unusual options. > > > > -- > > Bug report: > > > > $ gpg --show-sig-subpackets --with-colons > --list-sigs > > gpg: Invalid option "--show-sig-subpackets" > > -- > > show-sig-subpackets is a list-option. It is not an > option itself. > > David > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From npcole at yahoo.co.uk Tue Nov 2 15:59:43 2004 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Tue Nov 2 15:58:26 2004 Subject: [Announce] GnuPG 1.3.92 released (development) In-Reply-To: <20041102143753.91884.qmail@web25406.mail.ukl.yahoo.com> Message-ID: <20041102145943.13054.qmail@web25402.mail.ukl.yahoo.com> > > show-sig-subpackets is a list-option. It is not > an > > option itself. So it is. I shall go and feel stupid somewhere. Best, N. ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From patrick.brunschwig at gmx.net Mon Nov 8 22:09:31 2004 From: patrick.brunschwig at gmx.net (Patrick Brunschwig) Date: Mon Nov 8 22:06:07 2004 Subject: Error creating backup of trustdb with 1.3.92 Message-ID: <418FE08B.4010907@gmx.net> When I (e.g.) change the ownertrust of a key, the trustdb is recalculated upon the following start of gpg. As shown below (Win32 system), this leads to an error causing gpg to return exit code 2, even though the operation itself completes successfully. This looks like a bug ... -Patrick Log from gpg: C:\Documents and Settings\patrick>gpg --edit-key testkey@invalid.domain gpg (GnuPG) 1.3.92; Copyright (C) 2004 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! Secret key is available. pub 1024D/B1443985 created: 2004-11-08 expires: never usage: CS trust: marginal validity: unknown sub 2048g/892AE1FD created: 2004-11-08 expires: never usage: E [ unknown] (1). Testkey Command> trust pub 1024D/B1443985 created: 2004-11-08 expires: never usage: CS trust: marginal validity: unknown sub 2048g/892AE1FD created: 2004-11-08 expires: never usage: E [ unknown] (1). Testkey Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 4 pub 1024D/B1443985 created: 2004-11-08 expires: never usage: CS trust: full validity: unknown sub 2048g/892AE1FD created: 2004-11-08 expires: never usage: E [ unknown] (1). Testkey Please note that the shown key validity is not necessarily correct unless you restart the program. Command> quit C:\Documents and Settings\patrick>gpg --list-key testkey@invalid.domain gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: checking the trustdb gpg: public key 57BBB132 is 4104 seconds newer than the signature gpg: renaming `C:/Documents and Settings/patrick/Application Data/GnuPG\pubring. gpg' to `C:/Documents and Settings/patrick/Application Data/GnuPG\pubring.bak' failed: Permission denied gpg: failed to rebuild keyring cache: file rename error gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 6 signed: 18 trust: 0-, 0q, 0n, 0m, 0f, 6u gpg: depth: 1 valid: 18 signed: 13 trust: 10-, 0q, 0n, 3m, 5f, 0u gpg: depth: 2 valid: 10 signed: 3 trust: 6-, 1q, 0n, 1m, 2f, 0u gpg: depth: 3 valid: 2 signed: 0 trust: 2-, 0q, 0n, 0m, 0f, 0u gpg: next trustdb check due at 2005-12-31 pub 1024D/B1443985 2004-11-08 uid Testkey sub 2048g/892AE1FD 2004-11-08 C:\Documents and Settings\patrick>echo %errorlevel% 2 C:\Documents and Settings\patrick> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20041108/4aa8e11c/signature-0001.bin From twoaday at freakmail.de Tue Nov 9 07:51:06 2004 From: twoaday at freakmail.de (Timo Schulz) Date: Tue Nov 9 08:34:57 2004 Subject: Error creating backup of trustdb with 1.3.92 In-Reply-To: <418FE08B.4010907@gmx.net> References: <418FE08B.4010907@gmx.net> Message-ID: <20041109065106.GB336@daredevil.joesixpack.net> On Mon Nov 08 2004; 22:09, Patrick Brunschwig wrote: > system), this leads to an error causing gpg to return exit code 2, even > though the operation itself completes successfully. But in the case you've shown the process was _not_ successfull. > gpg: renaming `C:/Documents and Settings/patrick/Application > Data/GnuPG\pubring. > gpg' to `C:/Documents and Settings/patrick/Application > Data/GnuPG\pubring.bak' failed: Permission denied > gpg: failed to rebuild keyring cache: file rename error Is it possible that another process or maybe yourself created the pubring.bak in this directory? If you delete or rename pubring.bak to pubring2.bak, it should work and the return should be zero. Timo From patrick.brunschwig at gmx.net Tue Nov 9 18:28:55 2004 From: patrick.brunschwig at gmx.net (Patrick Brunschwig) Date: Tue Nov 9 18:25:26 2004 Subject: Error creating backup of trustdb with 1.3.92 In-Reply-To: <20041109065106.GB336@daredevil.joesixpack.net> References: <418FE08B.4010907@gmx.net> <20041109065106.GB336@daredevil.joesixpack.net> Message-ID: <4190FE57.8030807@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Timo Schulz wrote: > On Mon Nov 08 2004; 22:09, Patrick Brunschwig wrote: > > >>system), this leads to an error causing gpg to return exit code 2, even >>though the operation itself completes successfully. > > > But in the case you've shown the process was _not_ successfull. Kind of yes (concerning renaming the file), kind of no :-) The list of the keys (which was what I asked for) was returned normally. >>gpg: renaming `C:/Documents and Settings/patrick/Application >>Data/GnuPG\pubring. >>gpg' to `C:/Documents and Settings/patrick/Application >>Data/GnuPG\pubring.bak' failed: Permission denied >>gpg: failed to rebuild keyring cache: file rename error > > > Is it possible that another process or maybe yourself created the > pubring.bak in this directory? If you delete or rename pubring.bak > to pubring2.bak, it should work and the return should be zero. No, that's not possible, there is no pubring.bak file in the directory. Instead, there's a file pubring.tmp. I have also double checked the permissions, and all is as it should be. By the way, I'm not the only one to have noticed this bug. Some Enigmail users tell me about the same issue. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.92 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBkP5W2KgHx8zsInsRAhL9AJ9ZuRJaahMbtj4dcUTIdemATT6N7QCgxAaC 0N4ZlNQK9FP5NtwtOPWGyNU= =1wvw -----END PGP SIGNATURE----- From wk at gnupg.org Tue Nov 9 19:05:46 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 9 19:09:28 2004 Subject: Error creating backup of trustdb with 1.3.92 In-Reply-To: <4190FE57.8030807@gmx.net> (Patrick Brunschwig's message of "Tue, 09 Nov 2004 18:28:55 +0100") References: <418FE08B.4010907@gmx.net> <20041109065106.GB336@daredevil.joesixpack.net> <4190FE57.8030807@gmx.net> Message-ID: <87bre63nk5.fsf@wheatstone.g10code.de> On Tue, 09 Nov 2004 18:28:55 +0100, Patrick Brunschwig said: > Instead, there's a file pubring.tmp. I have also double checked the > permissions, and all is as it should be. By the way, I'm not the only > one to have noticed this bug. Some Enigmail users tell me about the same Please report such problems to this list. We can only fix things we know about. Timo once mentioned that we had a similar problem but he wasn't later able to replicate it. The most likely thing here is that the file is still open while we are trying to rename it. This is the usual Windows sillyness of a missing inode concept. Werner From barry at bpuk.net Tue Nov 9 20:17:52 2004 From: barry at bpuk.net (Barry Porter) Date: Tue Nov 9 20:14:57 2004 Subject: Error creating backup of trustdb with 1.3.92 In-Reply-To: <87bre63nk5.fsf@wheatstone.g10code.de> References: <418FE08B.4010907@gmx.net> <20041109065106.GB336@daredevil.joesixpack.net> <4190FE57.8030807@gmx.net> <87bre63nk5.fsf@wheatstone.g10code.de> Message-ID: <419117E0.4070709@bpuk.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Werner Koch wrote: > Please report such problems to this list. We can only fix things we > know about. Timo once mentioned that we had a similar problem but he > wasn't later able to replicate it. I can reliably reproduce this problem on my system: Windows XP Pro SP2 with GnuPG 1.3.92. I get exactly the same permission denied error for pubring.bak There is no pubring.bak, only a pubring.tmp to which there is full access and no permissions issues. - -- Regards Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.92 (Windows XP Pro SP2) Comment: Public Key: http://bpuk.net/openpgpkey1.html Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBkRfe3wKVPLs2unURAutxAJ9+vHIy5M9yBThfUuUOqfATy9XfCwCdEvYk HpnrZFhV0RAFp1WE1ZLxuHI= =mkYT -----END PGP SIGNATURE----- From mc_mc_mc at lycos.de Wed Nov 10 11:29:23 2004 From: mc_mc_mc at lycos.de (Markus Bauer) Date: Wed Nov 10 11:26:25 2004 Subject: zlib-compressed gpg-encrypted data files Message-ID: <1100082563022482@lycos-europe.com> Hi, (if you do not want to help me, do you have an idea, who could help me/us? I would give a lot if such a system would work) I have (not my own) an important gpg file on a formatted hard drive which occupies exactly 8811 data blocks on an ext2 file system (one block 4096 bytes), so the file size is ca. 37MB. The different data blocks are distributed on a file system with 3500000 blocks (14GB). The file is very important so I started recovering it. The facts: - I already recovered whole gpg meta data, keyring etc - I wrote a program to find the beginning of the gpg file. I've found the first blocks. - There is a file that contains the file size of the file before formatting. So I know that the exact size should be 8811 blocks. The file was encrypted with default settings, so also compressed with zlib. I've already recovered the first 13 blocks (because I found the beginning as already mentioned. Luckily there was only one gpg file on the hard disk). And inspecting the file (decrypting with debug options of gpg) tell me, that it's exactly the right file. The encrypted file was 'data.zip' and even the original size was printed by gpg. Now I downloaded gpg sources and changed the sources a bit and wrote a small shellscript in order to find the whole file (by scanning the whole partition). Among other files, I added the following line to g10/compress.c, ~ line 176 (sources from 1.0.6): fprintf(stdout, "%u\n", (long long)iobuf_tell(a)); I know that this isn't completely correct but my file is not larger than 50MB. How big is the "zlib block size" by default? Looking at g10/compress.c ~ line 65, I would think that block size is 8192 bytes, so it's 2 blocks on the file system, so I should have luck that at least two blocks are back-to-back. I hope, you know what I mean. The followong script should scan the whole file system trying to string together the original file. My modified gpg executeable is in the same directory as the script and when starting the script, the beinning of the file is in file .current, size 53248. Trying to compress this file I get 51496 bytes from the fprintf line inserted above: #!/bin/bash declare -i lastsize declare -i cursize declare -i divisor declare -i i # make sure that all error output from gpg is redirected to /dev/null # as well as decrpted output and normal messages so that we only get # my number from inserted fprintf line lastsize=`./gpg -q --batch --homedir /home/mark/.gnupg_recover --output /dev/null -d .current 2>/dev/null` i=0 while true; do # try to read 10 blocks ar once dd if=/sda1/data.bin bs=4096 count=10 skip=$i of=.buffer 2>/dev/null # merge old and new file to a new file '.test' in order # to test if more fragments could be decrypted cat .current .buffer > .test # read out length of successfully decrypted data from new file cursize=`./gpg -q --batch --homedir /home/mark/.gnupg_recover --output /dev/null -d .test 2>/dev/null` # debug (Block, lastsize and currentsize) echo -e "B: $i\tL: $lastsize, C: $cursize" if test $cursize -gt $lastsize; then # YEEEEAH!!! We've found another piece!!! echo "Woooow, we've found a new fragment. old size: $lastsize, new size: $cursize" | tee log.txt # how many blocks on the filesystem is that? divisor=$(( $cursize / 4096 )) if test $(( $cursize % 4096 )) -ne 0; then divisor=$divisor+1; fi # add new data found to file .current rm -f .current dd if=.test of=.current bs=4096 count=$divisor 2>/dev/null lastsize=$cursize i=$(( $i + $divisor)) else # no new data was found. Just increase loop variable i=$i+1 fi done The script runs now for ~15 days (yes, big harddrive) and there were no new fragments found. First I startet the script with i=3081920 (the offset where I found the beginning of the gpg file) and after that, I searched the data before (starting from block 0). I hope you can understand what I do here. Why does this script not find the next piece? The file is very old and so it should not be too much fragmented. But is my beginning correct or is anything wrong with the offset where the zblib compressor outputs its error message? I would be very, very happy, if anybody could help me because the file is important and the facts are not so bad ("small" size, length known, beginning known, all keys known, encryption settings known, chance is good that file is not much fragmented) Thanks a lot!! Markus PS: This file is from a good friend of mine, and no. He does not have backups! The file also contains projects and source code for programs we developed together a long time ago. PPS: Sorry that I write to this list but I think my problem can only answer a developer who knows interna of the zlib compression... null Sichern Sie sich Ihre Premium E-Mail-Adresse bei Lycos: eigene Domain, 1000 MB Mailspeicher, 100 free SMS, POP3, Weiterleitung und Hightech Spamschutz: http://mail.lycos.de From tony.cheung at asiayeah.com Thu Nov 11 04:32:24 2004 From: tony.cheung at asiayeah.com (Tony Yat-Tung Cheung) Date: Thu Nov 11 04:28:41 2004 Subject: GnuPG port for Palm OS? Message-ID: <4192DD48.4010504@asiayeah.com> Hi, I think this has been raised out before. Is there any GnuPG port for Palm OS? Is there any good PGP solution for Palm OS, as a SDK? Thank you! Tony Cheung From patrick.brunschwig at gmx.net Thu Nov 11 09:08:24 2004 From: patrick.brunschwig at gmx.net (Patrick Brunschwig) Date: Thu Nov 11 09:27:46 2004 Subject: Error creating backup of trustdb with 1.3.92 In-Reply-To: <87bre63nk5.fsf@wheatstone.g10code.de> References: <418FE08B.4010907@gmx.net> <20041109065106.GB336@daredevil.joesixpack.net> <4190FE57.8030807@gmx.net> <87bre63nk5.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > On Tue, 09 Nov 2004 18:28:55 +0100, Patrick Brunschwig said: > > >>Instead, there's a file pubring.tmp. I have also double checked the >>permissions, and all is as it should be. By the way, I'm not the only >>one to have noticed this bug. Some Enigmail users tell me about the same > > > Please report such problems to this list. We can only fix things we > know about. Timo once mentioned that we had a similar problem but he > wasn't later able to replicate it. Sure, that's what I'm doing :-) But before I report a bug, I try to reproduce it myself. If there's anything I can do to help, just let me know. -Patrick From Holger.Sesterhenn at smgwtest.aachen.utimaco.de Fri Nov 12 12:41:11 2004 From: Holger.Sesterhenn at smgwtest.aachen.utimaco.de (Holger Sesterhenn) Date: Fri Nov 12 12:38:11 2004 Subject: Time conflicts not checked on subkey signatures? Message-ID: <4194A157.2060606@smgwtest.aachen.utimaco.de> Hi, I have done some research on how gnupg handles time conflicts between signature packets and public key packets/public subkey packets. Signatures are checked in g10/sig-check.c. do_check_messages() compares the public key packet timestamp and the signature packet timestamp. The error code "G10ERR_TIME_CONFLICT" is not set somewhere else in sig-check.c. The function check_key_signature2() calls do_check_messages() via do_check(). The subkey packet is just hashed but not checked for time conflicts. You can see the problem with this key: ./gpg --with-colon --fingerprint --fixed-list-mode --check-sig (GnuPG 1.3.6, 1.2.4 looks slightly different, I hope the output is not that much crippled) pub:r:1024:17:131E92BF5A16ADD7:936832137:::-:::sca: fpr:::::::::02A3BC00358327E518CEA199131E92BF5A16ADD7: rev:!::17:131E92BF5A16ADD7:949365009::::RavingCow :20x: uid:r::::942521984::9AAA48F52CA77FF628A75CB8BD913287A0DCBD68::RavingCow : sig:?::17:F8601C136A6CF305:943903355:::::10x: rev:%::17:131E92BF5A16ADD7:943631147::::[unknown signature class] :28x: rev:%::17:131E92BF5A16ADD7:944264133::::[unknown signature class] :28x: sig:!::17:131E92BF5A16ADD7:942521984::::RavingCow :10x: sig:?::17:83CAAC2837AA3A5B:943575352:951783352::::10x: uid:r::::936832137::62BA3AFE78F6DCD72279A4F934C8AD45FD547D68::David Greenaway : sig:?::17:F8601C136A6CF305:943793261:::::10x: rev:%::17:131E92BF5A16ADD7:943631147::::[unknown signature class] :28x: rev:%::17:131E92BF5A16ADD7:944264133::::[unknown signature class] :28x: sig:!::17:131E92BF5A16ADD7:936832137::::RavingCow :10x: sig:?::17:83CAAC2837AA3A5B:943575352:951783352::::10x: sig:?::1:2CCA5AD654E87F1B:949364968::1 120:::10x: sub:r:1024:16:97EF615D82E6AFC4:936832142::::::e: sig:!::17:131E92BF5A16ADD7:936832142::::RavingCow :18x: rev:!::17:131E92BF5A16ADD7:943631147::::RavingCow :28x: sub:r:2048:16:B65DC362D7433511:942462001:946522801:::::e: sig:-::17:131E92BF5A16ADD7:936832142::::RavingCow :18x: rev:!::17:131E92BF5A16ADD7:944264133::::RavingCow :28x: sig:!::17:131E92BF5A16ADD7:942522219::::RavingCow :18x: sub:i:2048:16:066E0F3E0BDA77F9:946609201::::::: sub:r:4096:16:141ED9B26ED48A96:942462001:946522801:::::e: sig:-::17:131E92BF5A16ADD7:936832142::::RavingCow :18x: sig:!::17:131E92BF5A16ADD7:942522407::::RavingCow :18x: sub:r:4096:16:EAE3081B816B7B04:946609201:954385201:::::e: sig:-::17:131E92BF5A16ADD7:936832142::::RavingCow :18x: sig:!::17:131E92BF5A16ADD7:943632086::::RavingCow :18x: ^^^^^^^^ Signature creation date is older than subkey creation date. sub:i:4096:16:D0743C0946315695:946609201::::::: sig:-::17:131E92BF5A16ADD7:936832142::::RavingCow :18x: rev:-::17:131E92BF5A16ADD7:943631147::::RavingCow :28x: rev:-::17:131E92BF5A16ADD7:944264133::::RavingCow :28x: I know that this key is crippled but nevertheless the revoke signature on the subkey should not be treated as valid. Key fetched from hkp://subkeys.pgp.net yesterday. Verified with GnuPG 1.2.4, 1.3.6cvs, 1.3.93cvs (last 'cvs update' 12 hours ago). Any comments? -- Best Regards, Holger Sesterhenn --- Internet http://www.utimaco.com From dshaw at jabberwocky.com Mon Nov 15 01:39:32 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Nov 15 01:36:34 2004 Subject: Time conflicts not checked on subkey signatures? In-Reply-To: <4194A157.2060606@smgwtest.aachen.utimaco.de> References: <4194A157.2060606@smgwtest.aachen.utimaco.de> Message-ID: <20041115003931.GF12059@jabberwocky.com> On Fri, Nov 12, 2004 at 12:41:11PM +0100, Holger Sesterhenn wrote: > Hi, > > I have done some research on how gnupg handles time conflicts between > signature packets and public key packets/public subkey packets. > > Signatures are checked in g10/sig-check.c. > > do_check_messages() compares the public key packet timestamp and the > signature packet timestamp. The error code "G10ERR_TIME_CONFLICT" is not > set somewhere else in sig-check.c. > > The function check_key_signature2() calls do_check_messages() via > do_check(). The subkey packet is just hashed but not checked for time > conflicts. > > You can see the problem with this key: > > ./gpg --with-colon --fingerprint --fixed-list-mode --check-sig > > (GnuPG 1.3.6, 1.2.4 looks slightly different, I hope the output is not > that much crippled) > > pub:r:1024:17:131E92BF5A16ADD7:936832137:::-:::sca: > fpr:::::::::02A3BC00358327E518CEA199131E92BF5A16ADD7: > rev:!::17:131E92BF5A16ADD7:949365009::::RavingCow > :20x: > uid:r::::942521984::9AAA48F52CA77FF628A75CB8BD913287A0DCBD68::RavingCow > : > sig:?::17:F8601C136A6CF305:943903355:::::10x: > rev:%::17:131E92BF5A16ADD7:943631147::::[unknown signature class] :28x: > rev:%::17:131E92BF5A16ADD7:944264133::::[unknown signature class] :28x: > sig:!::17:131E92BF5A16ADD7:942521984::::RavingCow > :10x: > sig:?::17:83CAAC2837AA3A5B:943575352:951783352::::10x: > uid:r::::936832137::62BA3AFE78F6DCD72279A4F934C8AD45FD547D68::David > Greenaway : > sig:?::17:F8601C136A6CF305:943793261:::::10x: > rev:%::17:131E92BF5A16ADD7:943631147::::[unknown signature class] :28x: > rev:%::17:131E92BF5A16ADD7:944264133::::[unknown signature class] :28x: > sig:!::17:131E92BF5A16ADD7:936832137::::RavingCow > :10x: > sig:?::17:83CAAC2837AA3A5B:943575352:951783352::::10x: > sig:?::1:2CCA5AD654E87F1B:949364968::1 120:::10x: > sub:r:1024:16:97EF615D82E6AFC4:936832142::::::e: > sig:!::17:131E92BF5A16ADD7:936832142::::RavingCow > :18x: > rev:!::17:131E92BF5A16ADD7:943631147::::RavingCow > :28x: > sub:r:2048:16:B65DC362D7433511:942462001:946522801:::::e: > sig:-::17:131E92BF5A16ADD7:936832142::::RavingCow > :18x: > rev:!::17:131E92BF5A16ADD7:944264133::::RavingCow > :28x: > sig:!::17:131E92BF5A16ADD7:942522219::::RavingCow > :18x: > sub:i:2048:16:066E0F3E0BDA77F9:946609201::::::: > sub:r:4096:16:141ED9B26ED48A96:942462001:946522801:::::e: > sig:-::17:131E92BF5A16ADD7:936832142::::RavingCow > :18x: > sig:!::17:131E92BF5A16ADD7:942522407::::RavingCow > :18x: > > sub:r:4096:16:EAE3081B816B7B04:946609201:954385201:::::e: > sig:-::17:131E92BF5A16ADD7:936832142::::RavingCow > :18x: > sig:!::17:131E92BF5A16ADD7:943632086::::RavingCow > :18x: > > ^^^^^^^^ Signature creation date is older than subkey creation date. > > sub:i:4096:16:D0743C0946315695:946609201::::::: > sig:-::17:131E92BF5A16ADD7:936832142::::RavingCow > :18x: > rev:-::17:131E92BF5A16ADD7:943631147::::RavingCow > :28x: > rev:-::17:131E92BF5A16ADD7:944264133::::RavingCow > :28x: > > I know that this key is crippled but nevertheless the revoke signature > on the subkey should not be treated as valid. I'm not sure if I agree with this. To be sure, the revocation signature is dated before the subkey itself, but since the subkey is required to generate the revocation signature in the first place, one (or both) of the dates are wrong. People revoke keys for a reason. I don't think it is good to un-revoke a key because someone's clock was wrong... David From mcgrof at ruslug.rutgers.edu Wed Nov 10 20:56:02 2004 From: mcgrof at ruslug.rutgers.edu (Luis R. Rodriguez) Date: Mon Nov 15 08:52:35 2004 Subject: PGP/MIME assistance In-Reply-To: <20041110192505.GA30049@ruslug.rutgers.edu> References: <20041110192505.GA30049@ruslug.rutgers.edu> Message-ID: <20041110195602.GC30049@ruslug.rutgers.edu> On Wed, Nov 10, 2004 at 02:25:05PM -0500, Luis R. Rodriguez wrote: > > Hello, > > I am writing a php mailer so users can contact me through my website and > I want to enable PGP/MIME messaging. I'm able to have the mailer > generate what seems to be a proper attachment and a proper PGP/MIME > e-mail but for some reason the encrypted content seems to be > empty all the time. If I try to decrypt the content manually it displays > correctly but my MUA (mutt) is displaying the content as empty. I am > also not getting any errrors through my MUA. > > I'm sure I'm missing something silly here, I just can't figured it out. > > Here is what a PGP/MIME e-mail looks like when I receive it through my > mailer: > > http://mcgrof.com/pgp-mime.txt > > And here is my source: > > http://mcgrof.com/contact/index.phps > > Any help would be appreciated. > > Thanks, > > Luis > Well nevermind it works. What I was doing is just doing 1-line e-mail tests and the message was empty. The first line just seems to be truncated. I read the RFC but was unsure if it meant to say that we should include a content-type line on the encrypted message.. perhaps the answer is yes. Can someone verify? Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20041110/ec5d475f/attachment.bin From mcgrof at ruslug.rutgers.edu Wed Nov 10 21:07:36 2004 From: mcgrof at ruslug.rutgers.edu (Luis R. Rodriguez) Date: Mon Nov 15 08:52:39 2004 Subject: PGP/MIME assistance In-Reply-To: <20041110195602.GC30049@ruslug.rutgers.edu> References: <20041110192505.GA30049@ruslug.rutgers.edu> <20041110195602.GC30049@ruslug.rutgers.edu> Message-ID: <20041110200736.GD30049@ruslug.rutgers.edu> On Wed, Nov 10, 2004 at 02:56:02PM -0500, Luis R. Rodriguez wrote: > On Wed, Nov 10, 2004 at 02:25:05PM -0500, Luis R. Rodriguez wrote: > > > > Hello, > > > > I am writing a php mailer so users can contact me through my website and > > I want to enable PGP/MIME messaging. I'm able to have the mailer > > generate what seems to be a proper attachment and a proper PGP/MIME > > e-mail but for some reason the encrypted content seems to be > > empty all the time. If I try to decrypt the content manually it displays > > correctly but my MUA (mutt) is displaying the content as empty. I am > > also not getting any errrors through my MUA. > > > > I'm sure I'm missing something silly here, I just can't figured it out. > > > > Here is what a PGP/MIME e-mail looks like when I receive it through my > > mailer: > > > > http://mcgrof.com/pgp-mime.txt > > > > And here is my source: > > > > http://mcgrof.com/contact/index.phps > > > > Any help would be appreciated. > > > > Thanks, > > > > Luis > > > > Well nevermind it works. What I was doing is just doing 1-line e-mail > tests and the message was empty. The first line just seems to be truncated. > I read the RFC but was unsure if it meant to say that we should include a > content-type line on the encrypted message.. perhaps the answer is yes. > Can someone verify? > OK I have verified once again that this is the case. If I e-mail myself the following message: 1. A boy's car died 2. Eddy fears goats 3. Helen ignores Jorge 4. Kelly likes Mike Mutt will only display lines 2-4. If I decrypt the file manually I will get all lines. Can someone explain why? Thanks, Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20041110/6a780f36/attachment.bin From atom at suspicious.org Mon Nov 15 16:06:45 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Nov 15 16:23:19 2004 Subject: OpenPGP headers In-Reply-To: <20040806230905.W79076@willy_wonka> References: <20040806230905.W79076@willy_wonka> Message-ID: <20041115150655.18915.qmail@suspicious.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 simon josefsson and i have prepared a formal draft for an OpenPGP mail and news header field. The OpenPGP mail and news header i'd like to solicit comments first from the gnupg-devel list, then post a link to gnupg-users and pgp-basics. then we'll submit it to the IETF and see what happens. - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "We're doing better than people think. And a year from now, I'll be very surprised if there is not some grand square in Baghdad that is named after President Bush." -- Richard Perle, 22 September 2003 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBmMYLAAoJEAx/d+cTpVcibZIH/AydhudllurqFLqiJqZRWKAs lMHRwKWnM5xcNun2Ij7Ad38qbMzmkMxDiQhcrEPJ/G79CFqJifAijVPqYxzPgcA1 9L7w9RKj+JGmD4ZvDRro2+a/WIGN6BxrJh9aFN7GxOjiFVDc17p2yrcddg3MxC6y t48nRZVJAu9qmgOFtQMbRRhgN5mxdLsyUqk5JgOlTC7hg1nJwjqtMMUun/MJWmsA Lu2c0MdqtqcjrE8suAsB7CVl8DZqwJ/Vgn68vAr78omC0FUg6nhBpNQpfl1WZhsB /wJSuFhx21E027HZlxjMNv4ItnQHTMAZYygTwJTURkzuWLWiA+sevmN21Uyfs50= =uZdY -----END PGP SIGNATURE----- From mo at g10code.com Mon Nov 15 17:14:00 2004 From: mo at g10code.com (Moritz Schulte) Date: Mon Nov 15 17:10:10 2004 Subject: OpenPGP headers In-Reply-To: <20041115150655.18915.qmail@suspicious.org> References: <20040806230905.W79076@willy_wonka> <20041115150655.18915.qmail@suspicious.org> Message-ID: <20041115161400.GA5180@sarkutty> On Mon, Nov 15, 2004 at 10:06:45AM -0500, Atom 'Smasher' wrote: Hello, > The OpenPGP mail and news header Could you please explain the rationale behind this header field slightly more verbose than you did in this paper? I am not convinced that is is necessary. Reason: keys should be on keyservers (keyservers are a standard) and all those information, which are to be encoded with this header field can be derived from the key itself. In other words: the only necessary information is something like a key ID (in case the mail is not signed). What am I missing? Thanks, Moritz -- Moritz Schulte From atom at suspicious.org Mon Nov 15 17:50:00 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Nov 15 17:46:37 2004 Subject: OpenPGP headers In-Reply-To: <20041115161400.GA5180@sarkutty> References: <20040806230905.W79076@willy_wonka> <20041115150655.18915.qmail@suspicious.org> <20041115161400.GA5180@sarkutty> Message-ID: <20041115165010.91824.qmail@suspicious.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, 15 Nov 2004, Moritz Schulte wrote: > Could you please explain the rationale behind this header field slightly > more verbose than you did in this paper? I am not convinced that is is > necessary. > > Reason: keys should be on keyservers (keyservers are a standard) and all > those information, which are to be encoded with this header field can be > derived from the key itself. In other words: the only necessary > information is something like a key ID (in case the mail is not signed). > > What am I missing? =========================== let's say you get an email from "bob". you go to the keyservers and find several keys that claim to belong to bob, but you're not sure which one(s) are currently in use, or even which one ~really~ belongs to bob (none of the keys are signed). this header ads a _convenience_ (that shouldn't be considered secure!) to determine what key bob is using. i've also run into cases where i find 2-3 (or more) keys that all have several signatures, but i have no idea which one i'm supposed to use. more often than not, the private key was lost on several of the old keys. if this header is adopted as a standard, it could also allow MUAs to import a key when replying (but it must be understood that it's a convenience that may not be secure). let's not fool ourselves, this is NOT secure... but as a convenience it's rather cool. once a key is retrieved, the security burden (as always) rests with the person who decides to import and use the key. - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "According to Business Week, the average CEO [Chief Executive Officer] made 42 times the average blue-collar worker's pay in 1980, 85 times in 1990 and a staggering 531 times in 2000." -- AFL-CIO 'Executive Paywatch' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBmN49AAoJEAx/d+cTpVci03wIALbWPclxf7XmsBDl2Mg0b/Ox v6ygcQAh/9HkAYHQ+anS9gIEc3MAiYsomnibw5uFP6Mou7hOHznikMT9p8HiXF4p OZTaQjceXt3KPnPjBepvwraJSqtlhR2lBJq2dSuiUz6v1I3rJjpKKT9kZnGOMDNl 5soxMK9LroqIrh8TjrLlzcN6AFTHwNp1EIWo7pDB9ecOGUoFzcawhmaKoZTXZnmh wRFiiV0hWR/ow5efSNtAwI2nS/oivOzx3tbNelR2jC0POzSZmae+Vc+TLixi6Gcg sfs/CIPeZmwJSHiKgWovOU18abx8KgME1NaUKJRI2lgmIS1Ftg7NPUeCJYZfazM= =pFPQ -----END PGP SIGNATURE----- From atom at suspicious.org Mon Nov 15 18:59:03 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Nov 15 18:55:46 2004 Subject: RSA_OR_IDEA Message-ID: <20041115175915.41328.qmail@suspicious.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 while browsing through the status-fd section of DETAILS i noticed RSA_OR_IDEA: The IDEA algorithms has been used in the data. A program might want to fallback to another program to handle the data if GnuPG failed. This status message used to be emitted also for RSA but this has been dropped after the RSA patent expired. However we can't change the name of the message. with the release of 1.4 looming, is this the time to change the RSA_OR_IDEA status keyword to just IDEA? - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "We really haven't done everything we could to protect our customers... Our products just aren't engineered for security" -- Brian Valentine, Senior Vice President of Microsoft, Windows Division -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBmO5tAAoJEAx/d+cTpVciZIkH/Rt3B3ONERspSrxpDYGFhlsz gvZxcHUDlVnXbDUScm7Ch8eDgozQ/HaihB5TIyJDUOkWlcxhsU65/joyWdPcKOKZ 5O6buhq37Hdet4Y/dPHv0v1xKNszCx60rbEO9AIFXXLsDtGUZBeSaRy6PrFWulj5 YaubuX1hMXKGhItL3UsdeCV7LkZp2jB4/vBtLepqMorQxzdeU9/vPMV6NSQMGOUx hpXoqFwSRTeSUvuprJY100/lAuZF56AEG2BS0k63v9EH9yRQqD/SpRXXC8KfT0CN JNPE4Sl1SzmhwYrvi239Q9i/b2ttaKPZLGhJP/Z5soDqszVm0GIZnZLzqlkO9t8= =DmNi -----END PGP SIGNATURE----- From mo at g10code.com Mon Nov 15 19:09:51 2004 From: mo at g10code.com (Moritz Schulte) Date: Mon Nov 15 19:06:09 2004 Subject: OpenPGP headers In-Reply-To: <20041115165010.91824.qmail@suspicious.org> References: <20040806230905.W79076@willy_wonka> <20041115150655.18915.qmail@suspicious.org> <20041115161400.GA5180@sarkutty> <20041115165010.91824.qmail@suspicious.org> Message-ID: <20041115180951.GA12710@sarkutty> On Mon, Nov 15, 2004 at 11:50:00AM -0500, Atom 'Smasher' wrote: > let's say you get an email from "bob". you go to the keyservers and > find several keys that claim to belong to bob, but you're not sure > which one(s) are currently in use, or even which one ~really~ > belongs to bob (none of the keys are signed). this header ads a > _convenience_ (that shouldn't be considered secure!) to determine > what key bob is using. Well, yes. As i tried to clarify in my first mail: the information, which makes most sense to me, is the key ID. They key ID is something, which cannot be derived from the mail, in case it is not signed. > if this header is adopted as a standard, it could also allow MUAs to > import a key when replying (but it must be understood that it's a > convenience that may not be secure). Well. gpg does that for me: moritz@sarkutty:~/.gnupg $ grep auto gpg.conf # auto-key-retrieve = automatically fetch keys as needed from the keyserver keyserver-options auto-key-retrieve moritz@sarkutty:~/.gnupg $ Thanks, Moritz -- Moritz Schulte From atom at suspicious.org Mon Nov 15 19:16:31 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Nov 15 19:13:08 2004 Subject: OpenPGP headers In-Reply-To: <20041115180951.GA12710@sarkutty> References: <20040806230905.W79076@willy_wonka> <20041115150655.18915.qmail@suspicious.org> <20041115161400.GA5180@sarkutty> <20041115165010.91824.qmail@suspicious.org> <20041115180951.GA12710@sarkutty> Message-ID: <20041115181642.53726.qmail@suspicious.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, 15 Nov 2004, Moritz Schulte wrote: > On Mon, Nov 15, 2004 at 11:50:00AM -0500, Atom 'Smasher' wrote: > >> let's say you get an email from "bob". you go to the keyservers and >> find several keys that claim to belong to bob, but you're not sure >> which one(s) are currently in use, or even which one ~really~ belongs >> to bob (none of the keys are signed). this header ads a _convenience_ >> (that shouldn't be considered secure!) to determine what key bob is >> using. > > Well, yes. As i tried to clarify in my first mail: the information, > which makes most sense to me, is the key ID. They key ID is something, > which cannot be derived from the mail, in case it is not signed. =================== the "url" seems to be of general interest. for the sake of v3 keys and/or paranoid persons, the other fields seem to be of interest to people. >> if this header is adopted as a standard, it could also allow MUAs to >> import a key when replying (but it must be understood that it's a >> convenience that may not be secure). > > Well. gpg does that for me: > > moritz@sarkutty:~/.gnupg $ grep auto gpg.conf > # auto-key-retrieve = automatically fetch keys as needed from the keyserver > keyserver-options auto-key-retrieve ====================== that only works if you're replying to a signed message. - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Vietnam was the first war ever fought without any censorship. Without censorship, things can get terribly confused in the public mind." -- General William Westmoreland -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBmPKEAAoJEAx/d+cTpVcifBEH/2UqzuYETu+dOqySMYmz9wET uXX+ESsFdc66Z50cOS9aQP/O8xFlCeYE4u3JlQdFj8Ol2I8cui6IoHU4zLsZRvVU RDJzyrjGuIeykWHmH52YnG7sxPUxvH6+B+PaF/d9BUsoiUn+m6Cz9dWRPMrYT2Xl 7pEJFibPN7nShpMlhcH77bpZLFgDwODK40MHN3ABBYzAdB2GUhpyS9PC6va3+cV5 I8u9v4tyscPzRtlYLagjGqz7L6Z6Z9STqI4sKvSbtgnslvcD0QSOrAVQBYHppTFn Yy/rFPdTQhpsRKxI+ZiPvfAyPKRg/m0p6T7qSTU4kD6Yh0ZxXbT67V7eYoTLz6c= =fJ8f -----END PGP SIGNATURE----- From alex at bofh.net.pl Tue Nov 16 09:35:41 2004 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Tue Nov 16 09:32:16 2004 Subject: RSA_OR_IDEA In-Reply-To: <20041115175915.41328.qmail@suspicious.org> References: <20041115175915.41328.qmail@suspicious.org> Message-ID: <20041116083540.GD2877@syjon.fantastyka.net> On Mon, Nov 15, 2004 at 12:59:03PM -0500, Atom 'Smasher' wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > while browsing through the status-fd section of DETAILS i noticed > RSA_OR_IDEA: > The IDEA algorithms has been used in the data. A program might > want to fallback to another program to handle the data if GnuPG > failed. This status message used to be emitted also for RSA but > this has been dropped after the RSA patent expired. However we > can't change the name of the message. > > with the release of 1.4 looming, is this the time to change > the RSA_OR_IDEA status keyword to just IDEA? Mhm, which part of: "This status message used to be emitted also for RSA but this has been dropped after the RSA patent expired. However we can't change the name of the message." you didn't understand? Hint: backwards compatibility. Alex -- mors ab alto 0x46399138 From wk at gnupg.org Tue Nov 16 09:31:24 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 16 09:34:33 2004 Subject: RSA_OR_IDEA In-Reply-To: <20041115175915.41328.qmail@suspicious.org> (atom@suspicious.org's message of "Mon, 15 Nov 2004 12:59:03 -0500 (EST)") References: <20041115175915.41328.qmail@suspicious.org> Message-ID: <874qjqry8z.fsf@wheatstone.g10code.de> On Mon, 15 Nov 2004 12:59:03 -0500 (EST), Atom 'Smasher' said: > with the release of 1.4 looming, is this the time to change the > RSA_OR_IDEA status keyword to just IDEA? No we don't change keywords. Of course this status message is only issued for IDEA and not for RSA anymore. Werner From zvrba at zax.CARNET Mon Nov 15 19:30:15 2004 From: zvrba at zax.CARNET (Zeljko Vrba) Date: Tue Nov 16 16:07:52 2004 Subject: support for non-openpgp cards Message-ID: <20041115183015.GA1269@zax.CARNET> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hi to everybody.. I have made a patch to GNUPG 1.3.92 which makes possible to use general PKCS#11 tokens with GPG. You can retrieve the patch and signature at: http://www.core-dump.com.hr/software/gnupg-1.3.92-pkcs11.patch http://www.core-dump.com.hr/software/gnupg-1.3.92-pkcs11.patch.asc (the patch also includes p11howto.txt - the deisgn document). Now there are several issues to address with this patch in combination with the MUSCLE project (http://www.linuxnet.com): - - I use libmusclepkcs11.so with Cryptoflex 8k card. The library is, IMHO, incorrect in several respects with regards to PKCS#11: - it requires to specify CKA_TOKEN when generating keys - it expects the data to be PKCS#11 padded before encryption (although it explicitly knows that the card supports only raw rsa); and this is the main problem - supports only 2 keypairs on Cryptoflex cards (32k and 8k; the code is common). The alternative is to use the MUSCLE API (also described on the above site) which limits the library usage to JAVA cards with MUSCLE applet installed only (MUSCLE works on many UNICES and Win32). Given this input, here are some questions (both for users and developers; thus this mail goes to both lists): 1. Is there enough interest from GPG users to pursue further development of non-OpenPGP smart-cards? (either with PKCS#11 which I'd prefer, or with MUSCLE API; if there is enough interest I'll contact the developers of MUSCLE to resolve PKCS#11 issues). 2. Does GPG do PKCS#1 padding before signing or encryption? 3. Is it possible to make GPG generate only 1, or 2 keys on the card? (AFAIK, the generate command always tries to generate 3 keys and this command is the only way to make gpg learn about the card..) Even better, is it possible to make GPG use pre-generated keys on the card? I have already talked to Werner about this, and he didn't like the idea because of GPL license (the result of linking proprietary PKCS#11 lib with GPG is undefined). So please, no arguments about that. I'll leave to each user's conscience whether to run legally-undefined program, or not. MUSCLE itself is released under BSD license. - -- The corresponding public key is located at: http://ds.carnet.hr:11371/pks/lookup?op=get&search=0x5081D08A1DC7E994 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBmPWRUIHQih3H6ZQRA7J+AJ9gJp5bUEfAB9GQuaXP+kACFHtC0QCeOBZ9 tKk/pliIkJlE045G/bTEaGQ= =+/x9 -----END PGP SIGNATURE----- From wk at gnupg.org Tue Nov 16 20:33:18 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 16 20:34:41 2004 Subject: support for non-openpgp cards In-Reply-To: <20041115183015.GA1269@zax.CARNET> (Zeljko Vrba's message of "Mon, 15 Nov 2004 19:30:15 +0100") References: <20041115183015.GA1269@zax.CARNET> Message-ID: <87zn1hoagx.fsf@wheatstone.g10code.de> On Mon, 15 Nov 2004 19:30:15 +0100, Zeljko Vrba said: > I have already talked to Werner about this, and he didn't like the idea > because of GPL license (the result of linking proprietary PKCS#11 lib with > GPG is undefined). So please, no arguments about that. I'll leave to Sorry but this is not just undefined: it is a clear violation of the GPL. Salam-Shalom, Werner From jas at extundo.com Tue Nov 16 22:01:11 2004 From: jas at extundo.com (Simon Josefsson) Date: Tue Nov 16 21:58:04 2004 Subject: support for non-openpgp cards References: <20041115183015.GA1269@zax.CARNET> Message-ID: Zeljko Vrba writes: > 1. Is there enough interest from GPG users to pursue further development of > non-OpenPGP smart-cards? (either with PKCS#11 which I'd prefer I'd like to see GnuPG support generic PKCS#11 tokens. > I have already talked to Werner about this, and he didn't like the idea > because of GPL license (the result of linking proprietary PKCS#11 lib with > GPG is undefined). So please, no arguments about that. I'll leave to > each user's conscience whether to run legally-undefined program, or not. > MUSCLE itself is released under BSD license. To me, the license issue seem critical, and can't be ignored like this. If the proprietary PKCS#11 library is GPL-incompatible (which I suppose a "proprietary" library would be), to me this looks like a clear a violation of the GPL. Further, even if MUSCLE and its drivers are BSD licensed, I believe you would have to treat the combined work as licensed under GPL. However, it seems like there may be both GPL-compatible PKCS#11 libraries, and GPL-compatible PKCS#11 card drivers, in which case your work could be used legally. So I think your work would be useful. I didn't look at the code, I'm just speaking generally. Thanks. From ahaas at airmail.net Tue Nov 16 18:41:27 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Nov 16 22:30:09 2004 Subject: [PATCH] Trivial fix for scripts/autogen.sh Message-ID: <20041116174127.GS2993@artsapartment.org> Hi. The 'aclocal' test needs to test against the '$automake_vers' variable, not the '$autoconf_vers'. Art Haas Index: scripts/autogen.sh =================================================================== RCS file: /cvs/gnupg/gnupg/scripts/autogen.sh,v retrieving revision 1.24 diff -u -r1.24 autogen.sh --- scripts/autogen.sh 26 Oct 2004 19:32:44 -0000 1.24 +++ scripts/autogen.sh 16 Nov 2004 17:34:38 -0000 @@ -252,7 +252,7 @@ check_version $AUTOHEADER $autoconf_vers_num $autoconf_vers autoconf fi if check_version $AUTOMAKE $automake_vers_num $automake_vers; then - check_version $ACLOCAL $automake_vers_num $autoconf_vers automake + check_version $ACLOCAL $automake_vers_num $automake_vers automake fi if check_version $GETTEXT $gettext_vers_num $gettext_vers; then check_version $MSGMERGE $gettext_vers_num $gettext_vers gettext -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From atom at suspicious.org Wed Nov 17 04:00:10 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Wed Nov 17 03:57:00 2004 Subject: RSA_OR_IDEA In-Reply-To: <20041116083540.GD2877@syjon.fantastyka.net> References: <20041115175915.41328.qmail@suspicious.org> <20041116083540.GD2877@syjon.fantastyka.net> Message-ID: <20041117030022.22102.qmail@suspicious.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 16 Nov 2004, Janusz A. Urbanowicz wrote: > Mhm, which part of: "This status message used to be emitted also for RSA > but this has been dropped after the RSA patent expired. However we > can't change the name of the message." you didn't understand? Hint: > backwards compatibility. ============== yeah, i did notice that, but i was wondering if major version changes are a time to _sometimes_ break compatibility, if it's justified. i suppose it's not justified in this case. - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Unix is simple. It just takes a genius to understand its simplicity." -- Dennis Ritchie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBmr7AAAoJEAx/d+cTpVci+eUH/Ao7sU4ZiNVSg1qs0yI6zw3b AR1lHU0a7ml4HBlpBdWdfovVpM1g2BqZJeYBODedbMGYNeWQv7XdBSRtFQ2wvQH8 bScI70wo4j6mzJmWCaHQp6Z0ZaDH8R4PTydePk/lnPo+v40DFYVWsJD6/EKbnOkf NatO/m2jugp4hXu9iwGnqFgSQ6T/7CwtAiiypBgY+sPmtZLpgZJYYtVJsBiDtv/x p5i0FaB75CrDDJTtQyEhudzkQLHhiU8PcKSHDpE9JMuAe7t3CepXs1fnNMzc9i39 BHrawdpn4kacJcDjIMISe8TowSZVrJI0hfrMp6YXnKZMuyvbBuJm65YYEDmQ8fM= =Au66 -----END PGP SIGNATURE----- From sam at rfc1149.net Wed Nov 17 11:27:37 2004 From: sam at rfc1149.net (Samuel Tardieu) Date: Wed Nov 17 11:38:13 2004 Subject: support for non-openpgp cards References: <20041115183015.GA1269@zax.CARNET> <87zn1hoagx.fsf@wheatstone.g10code.de> Message-ID: <87hdnobwiu.fsf@beeblebrox.rfc1149.net> >>>>> "Werner" == Werner Koch writes: Werner> On Mon, 15 Nov 2004 19:30:15 +0100, Zeljko Vrba said: >> I have already talked to Werner about this, and he didn't like the >> idea because of GPL license (the result of linking proprietary >> PKCS#11 lib with GPG is undefined). So please, no arguments about >> that. I'll leave to Werner> Sorry but this is not just undefined: it is a clear violation Werner> of the GPL. Linking a GPL program with proprietary code is allowed a long as you don't distribute the result in binary form. Sam -- Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam From alex at bofh.net.pl Wed Nov 17 11:51:04 2004 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Wed Nov 17 11:47:37 2004 Subject: RSA_OR_IDEA In-Reply-To: <20041117030022.22102.qmail@suspicious.org> References: <20041115175915.41328.qmail@suspicious.org> <20041116083540.GD2877@syjon.fantastyka.net> <20041117030022.22102.qmail@suspicious.org> Message-ID: <20041117105103.GK2877@syjon.fantastyka.net> On Tue, Nov 16, 2004 at 10:00:10PM -0500, Atom 'Smasher' wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Tue, 16 Nov 2004, Janusz A. Urbanowicz wrote: > > >Mhm, which part of: "This status message used to be emitted also for RSA > >but this has been dropped after the RSA patent expired. However we > >can't change the name of the message." you didn't understand? Hint: > >backwards compatibility. > ============== > > yeah, i did notice that, but i was wondering if major version changes are > a time to _sometimes_ break compatibility, if it's justified. > > i suppose it's not justified in this case. Adoption of crypto is already very difficult from technical point of view and there is no point in making this one step harder in the name of, yeah of what? Alex -- mors ab alto 0x46399138 From clbianco at tiscalinet.it Thu Nov 18 12:35:14 2004 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Thu Nov 18 12:36:59 2004 Subject: Building 1.3.92 (and maybe 1.4.0) for Win32 Message-ID: Dear GnuPG developers, I am trying to apply the "alternative" MinGW/MSYS compilation technique described at point 5 on my page: to GnuPG 1.3.92 (the "legacy" technique, point 4, works perfectly). Unfortunately I get into the following error (I omitted in [...] all the CFLAGS optimization stuff like -mcpu, -mtune, -O3, ecc.): --------------------------------------------------------------------------- gcc [...] -o bftest.exe bftest.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lintl -lwsock32 ../util/libutil.a(ttyio.o)(.text+0x1f6):ttyio.c: undefined reference to `vasprintf' ../util/libutil.a(ttyio.o)(.text+0x2ed):ttyio.c: undefined reference to `vasprintf' collect2: ld returned 1 exit status make[2]: *** [bftest.exe] Error 1 make[2]: Leaving directory `/home/gnupg-1.3.92/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gnupg-1.3.92' make: *** [all] Error 2 --------------------------------------------------------------------------- I tried to make some modification to the source code by myself, to fix the error, but I got lost very soon... Any comment / suggestion? I agree that "legacy" build with the included libraries works perfectly, and then maybe such "alternative" compilation using the native Win32 libraries (gettext, libiconv, ecc.) is not worthed the time it needs to be fixed. But I think that this "alternative" way can help to remove many "#ifdef _WIN32" from the GnuPG source code, thus making the work of GnuPG developers much easier letting them focus on crypto stuff and not on OS sillinesses... ;-) Moreover, this does not "break" in any way the possibility to build GnuPG for Win32 using a cross-compiler from Linux, because such "native" libraries are just plain .zip files which can be easily installed in a cross-compilation environment. That's why I prefer so strongly the "alternative" way vs. the "legacy" one and why, IMVHO, it would be very useful to have it working also in 1.4.0 release... What do you think about? Thank you in advance for your reply! Best regards, Carlo Luciano -- | Carlo Luciano Bianco | ICQ UIN: 109517158 | |______________________| Home page: | |GPG DSA/ElG 1024/4096:|_________________________________________________| |KeyID:0x5324A0DA - Fingerprint:8B00C61034120506111B143DEDBF71B45324A0DA | From pragai at rubin.hu Thu Nov 18 15:39:46 2004 From: pragai at rubin.hu (=?ISO-8859-1?Q?=22Pr=E1gai=2C_R=F3bert=22?=) Date: Thu Nov 18 15:37:06 2004 Subject: support for non-openpgp cards In-Reply-To: <20041115183015.GA1269@zax.CARNET> References: <20041115183015.GA1269@zax.CARNET> Message-ID: <419CB432.5010104@rubin.hu> Hi Zeljko, big welcome for the pkcs11 patch for gnupg! We use cryptoflex e-gate 32k cards here and planned to make such a patch, too. You were the quicker:) My question: is the MUSCLE pkcs11 library required for this patch or any other pkcs11 (e.g. opensc-pkcs11) library will do the job? > > 1. Is there enough interest from GPG users to pursue further development of > non-OpenPGP smart-cards? (either with PKCS#11 which I'd prefer, or with > MUSCLE API; if there is enough interest I'll contact the developers of > MUSCLE to resolve PKCS#11 issues). > Yes there is! I think like opensc-pkcs11 support would also be nice. However, maybe there is no need for it if MUSCLE pkcs11 support works just fine... Thanks for this patch, Robert From zuxy.meng at gmail.com Thu Nov 18 15:57:26 2004 From: zuxy.meng at gmail.com (Zuxy) Date: Thu Nov 18 15:54:24 2004 Subject: Building 1.3.92 (and maybe 1.4.0) for Win32 In-Reply-To: References: Message-ID: vasprintf is defined for Win32 in util\strgutil.c. Did you accidentally modify the #ifdef _WIN32 and #endif pair around its definition? On Thu, 18 Nov 2004 11:35:14 +0000 (UTC), Carlo Luciano Bianco wrote: > Dear GnuPG developers, > > I am trying to apply the "alternative" MinGW/MSYS compilation technique > described at point 5 on my page: > > > > > Unfortunately I get into the following error (I omitted in [...] all the > CFLAGS optimization stuff like -mcpu, -mtune, -O3, ecc.): > > --------------------------------------------------------------------------- > gcc [...] -o bftest.exe bftest.o ../cipher/libcipher.a ../mpi/libmpi.a > ../util/libutil.a -lintl -lwsock32 > ../util/libutil.a(ttyio.o)(.text+0x1f6):ttyio.c: undefined reference to > `vasprintf' > ../util/libutil.a(ttyio.o)(.text+0x2ed):ttyio.c: undefined reference to > `vasprintf' collect2: ld returned 1 exit status > make[2]: *** [bftest.exe] > Error 1 make[2]: Leaving directory `/home/gnupg-1.3.92/tools' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/gnupg-1.3.92' > make: *** [all] Error 2 > --------------------------------------------------------------------------- Now there are too many possible combinations of compiler/shell/library when you port gnupg to Win32. I myself currently use MSYS+MinGW+zlib+libbzip2+libiconv+libgw32c to build gpg under Windows (all libs statically linked except libiconv), but people can also build it natively with just MSYS+MinGW, or cross-build it with MinGW-CPD. For the developers of GnuPG, it might be best to avoid any unnecessary asumption of the building enviroments other than Linux. I guess that's why they include zlib and simplified regex and gettext within the package. I hope one day Win32 will supply full POSIX compatibility. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6 From JPClizbe at comcast.net Thu Nov 18 16:17:25 2004 From: JPClizbe at comcast.net (John Clizbe) Date: Thu Nov 18 16:14:25 2004 Subject: Build error in 1.3.93-cvs for Win32 Message-ID: <419CBD05.7020900@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ran into this last night building 1.3.93-cvs on Windows 2000 with MinGW Making all in g10 make[2]: Entering directory `/home/jpclizbe/gnupg-cvs/gnupg-head/g10' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall - -Wcast-align -Wshadow -Wstrict-prototypes -Wformat-nonliteral -MT g10.o - -MD -MP -MF ".deps/g10.Tpo" -c -o g10.o g10.c; \ then mv -f ".deps/g10.Tpo" ".deps/g10.Po"; else rm -f ".deps/g10.Tpo"; exit 1; fi g10.c: In function `open_info_file': g10.c:951: error: `S_IRGRP' undeclared (first use in this function) g10.c:951: error: (Each undeclared identifier is reported only once g10.c:951: error: for each function it appears in.) g10.c:951: error: `S_IWGRP' undeclared (first use in this function) make[2]: *** [g10.o] Error 1 S_I[RWX]GRP are not defined for MSCVRT, only S_I[RWX]USR $ diff -u g10/g10.c~ g10/g10.c - --- g10/g10.c~ Wed Nov 17 10:04:21 2004 +++ g10/g10.c Thu Nov 18 09:05:12 2004 @@ -947,8 +947,13 @@ do { if (for_write) +#ifdef _WIN32 + fd = open (fname, O_CREAT | O_TRUNC | O_WRONLY, + S_IRUSR | S_IWUSR); +#else fd = open (fname, O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP); +#endif else fd = open (fname, O_RDONLY | MY_O_BINARY); } $ - -- 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.93-cvs-2004-11-18 (Windows 2000 SP4) Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG Comment: Annoy John Asscraft -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBnL0EHQSsSmCNKhARAslzAKD1u27fvpSeCp2n975elCUifoLx4ACg1PLd 7h1KdPEkLj8qFRATLV/6GkM= =/OgB -----END PGP SIGNATURE----- From wk at gnupg.org Thu Nov 18 16:48:41 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 18 16:49:33 2004 Subject: Build error in 1.3.93-cvs for Win32 In-Reply-To: <419CBD05.7020900@comcast.net> (John Clizbe's message of "Thu, 18 Nov 2004 09:17:25 -0600") References: <419CBD05.7020900@comcast.net> Message-ID: <87actf2m5i.fsf@wheatstone.g10code.de> On Thu, 18 Nov 2004 09:17:25 -0600, John Clizbe said: > g10.c:951: error: `S_IRGRP' undeclared (first use in this function) > g10.c:951: error: (Each undeclared identifier is reported only once Thanks for noting, I have not yet build it for Windows. Usually I fix those things right before doing a release. Werner From dshaw at jabberwocky.com Thu Nov 18 16:59:57 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Nov 18 16:56:55 2004 Subject: Build error in 1.3.93-cvs for Win32 In-Reply-To: <87actf2m5i.fsf@wheatstone.g10code.de> References: <419CBD05.7020900@comcast.net> <87actf2m5i.fsf@wheatstone.g10code.de> Message-ID: <20041118155957.GA29385@jabberwocky.com> On Thu, Nov 18, 2004 at 04:48:41PM +0100, Werner Koch wrote: > On Thu, 18 Nov 2004 09:17:25 -0600, John Clizbe said: > > > g10.c:951: error: `S_IRGRP' undeclared (first use in this function) > > g10.c:951: error: (Each undeclared identifier is reported only once > > Thanks for noting, I have not yet build it for Windows. Usually I fix > those things right before doing a release. Maybe it would be better to not use S_IRGRP and S_IWGRP even on Unixish machines. Why give group access at all? David From zvrba at globalnet.hr Thu Nov 18 19:59:39 2004 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Thu Nov 18 19:51:56 2004 Subject: support for non-openpgp cards In-Reply-To: <419CB432.5010104@rubin.hu> References: <20041115183015.GA1269@zax.CARNET> <419CB432.5010104@rubin.hu> Message-ID: <419CF11B.8030104@globalnet.hr> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Pr?gai, R?bert wrote: | Hi Zeljko, | | big welcome for the pkcs11 patch for gnupg! We use cryptoflex | e-gate 32k cards here and planned to make such a patch, too. You | were the quicker:) My question: is the MUSCLE pkcs11 library | required for this patch or any other pkcs11 (e.g. opensc-pkcs11) | library will do the job? | | I believe that any PKCS#11 implementation for that card should work in theory. Unfortunately, I have seen few PKCS#11 implementations (even commercial) that correctly implement PKCS#11 spec in all relevant aspects. So that supporting different PKCS#11 _implementation_ (even for the same card) could result in big code changes.. So, what _in theory_ should be ONE source, _in practice_ that source gets many #ifdefs for various PKCS#11 implementations.. :( Even my implementation has flaws that I described in my first mail (what I believe are bugs in MUSCLE PKCS#11 implementation). So the only way to find out if it will work with OpenSC is to TRY and see if it works. If it doesn't work, debug :) I don't have much time to spend on this, but I'll give OpenSC a try for the weekend and post the results. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBnPEaUIHQih3H6ZQRA0DeAKDI9dcpDPWSB4nNLxHPw1f88FcP+ACfeh5K OP0nb2OsADRrx/O8oRqkVwU= =8F20 -----END PGP SIGNATURE----- From clbianco at tiscalinet.it Thu Nov 18 20:08:02 2004 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Thu Nov 18 20:04:35 2004 Subject: Building 1.3.92 (and maybe 1.4.0) for Win32 References: Message-ID: Zuxy wrote: Well. first of all thanks a lot for the reply and for your help! > vasprintf is defined for Win32 in util\strgutil.c. Did you > accidentally modify the #ifdef _WIN32 and #endif pair around its > definition? No, the only modifications I did are the three described on my page (enabling gettext, LDAP, and fixing paths) and are all in the "configure" script only. When I build the "legacy" way (i.e. with the included simple-gettext) everything goes right. But if I modify configure to link with the external gettext and libiconv, I get the error. "configure" finds both gettext and libiconv without problems, BTW... Now I tried also to check the libutil.a: ------------------------------------------------ $ strings -a util/libutil.a | grep "vas" _libintl_vasprintf _libintl_vasprintf vasprintf() failed _vasprintf ------------------------------------------------ So it seems that the vasprintf function has been correctly compiled in the library... Can this be a gcc problem not finding it when linking? And what is _libintl_vasprintf? Should it be used instead of plain _vasprintf? > Now there are too many possible combinations of compiler/shell/library > when you port gnupg to Win32. Yes, I agree... There are even four different ports of libiconv with different names.... > I myself currently use > MSYS+MinGW+zlib+libbzip2+libiconv+libgw32c to build gpg under Windows I use the same + gettext, but not libgw32c... It was not required up to 1.2.6, beside for the dlopen() funcion... Or am I missing something? > (all libs statically linked except libiconv), but people can also > build it natively with just MSYS+MinGW, or cross-build it with > MinGW-CPD. For the developers of GnuPG, it might be best to avoid any > unnecessary asumption of the building enviroments other than Linux. I > guess that's why they include zlib and simplified regex and gettext > within the package. I fully agree, that's why I try to set up a MinGW environment as much "standard and clean" as possible. If this is possible, then maybe many "#ifdef _WIN32" could be removed from GnuPG souce code, simplifying very much the developers' work! I do not want to ask them to make more assumptions on the building environments, but to make less! ;-) -- | Carlo Luciano Bianco | ICQ UIN: 109517158 | |______________________| Home page: | |GPG DSA/ElG 1024/4096:|_________________________________________________| |KeyID:0x5324A0DA - Fingerprint:8B00C61034120506111B143DEDBF71B45324A0DA | From jas at extundo.com Thu Nov 18 23:35:20 2004 From: jas at extundo.com (Simon Josefsson) Date: Thu Nov 18 23:37:47 2004 Subject: support for non-openpgp cards References: <20041115183015.GA1269@zax.CARNET> <419CB432.5010104@rubin.hu> <419CF11B.8030104@globalnet.hr> Message-ID: Zeljko Vrba writes: > Pr=E1gai, R=F3bert wrote: > > | Hi Zeljko, > | > | big welcome for the pkcs11 patch for gnupg! We use cryptoflex > | e-gate 32k cards here and planned to make such a patch, too. You > | were the quicker:) My question: is the MUSCLE pkcs11 library > | required for this patch or any other pkcs11 (e.g. opensc-pkcs11) > | library will do the job? > | > | > I believe that any PKCS#11 implementation for that card should work in > theory. > > Unfortunately, I have seen few PKCS#11 implementations (even > commercial) that correctly implement PKCS#11 spec in all relevant > aspects. So that supporting different PKCS#11 _implementation_ (even > for the same card) could result in big code changes.. > > So, what _in theory_ should be ONE source, _in practice_ that source > gets many #ifdefs for various PKCS#11 implementations.. :( IMHO, you should not care about broken implementations. There is a well-defined PKCS#11 specification, even including header files. Write code for the specification. If something doesn't work because someone isn't implementing the specification, that's their problem. Polluting GnuPG code with #ifdef would make GnuPG users pay the price of other's bad work. To make things work in the real world, and not just a dream world where everyone implement the specification, you can write a module that translate from broken PKCS#11 to correct PKCS#11. IMHO, this is much better than coding for broken PKCS#11 directly. But hey, I'm not doing any work, so if you are, you get to chose the strategy. ;-) There is a GNU PKCS#11 package: http://gpkcs11.sourceforge.net/ Alas, it uses OpenSSL. Regards, Simon From clbianco at tiscalinet.it Fri Nov 19 01:41:52 2004 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Fri Nov 19 01:38:33 2004 Subject: Is direct calling "iconv.dll" really needed in Win32? Message-ID: Dear all, when I was trying to fix the building problem with GnuPG 1.3.92 and the "vasprintf" function (see previous message), I did also the following experiment: I removed from util/strgutil.c all the "#ifdef _WIN32" code for direct calling the "iconv.dll" library, i.e. I applied the attached patch. Of course, I added a "-liconv" to makefiles. Well... it worked. The resulting gpg.exe, of course, explicitly depends on libiconv-2.dll, and all "make check" are ok (beside the two which never worked in MSYS environment). So here comes my question. If the "standard" GnuPG code which works in a Linux environment works also without problems in Win32, why adding a "#ifdef _WIN32" code to do the same thing with a direct loading of "iconv.dll"? Is this "special" code really needed for something else or can it be just dropped in favor of the "standard" one, which maybe can even be linked statically with libiconv.a solving some of the problems currently under discussion on gnupg-users list? Maybe I am completely wrong, let me know... --- strgutil.c Wed Oct 27 16:15:59 2004 +++ strgutil.c.clb Thu Nov 18 23:47:47 2004 @@ -38,9 +38,7 @@ #ifdef USE_GNUPG_ICONV # include -# ifndef _WIN32 -# include -# endif +# include #endif #include "types.h" @@ -102,62 +100,6 @@ static int use_iconv = 0; -#ifdef _WIN32 -typedef void* iconv_t; -#ifndef ICONV_CONST -#define ICONV_CONST const -#endif - -iconv_t (* __stdcall iconv_open) (const char *tocode, const char *fromcode); -size_t (* __stdcall iconv) (iconv_t cd, - const char **inbuf, size_t *inbytesleft, - char **outbuf, size_t *outbytesleft); -int (* __stdcall iconv_close) (iconv_t cd); - -#endif /*_WIN32*/ - - - -#ifdef _WIN32 -static int -load_libiconv (void) -{ - static int done; - - if (!done) - { - void *handle; - - done = 1; /* Do it right now because we might get called recursivly - through gettext. */ - - handle = dlopen ("iconv.dll", RTLD_LAZY); - if (handle) - { - iconv_open = dlsym (handle, "libiconv_open"); - if (iconv_open) - iconv = dlsym (handle, "libiconv"); - if (iconv) - iconv_close = dlsym (handle, "libiconv_close"); - } - if (!handle || !iconv_close) - { - log_error (_("error loading `%s': %s\n"), - "iconv.dll", dlerror ()); - iconv_open = NULL; - iconv = NULL; - iconv_close = NULL; - if (handle) - dlclose (handle); - } - } - return iconv_open? 0: -1; -} -#endif /* _WIN32 */ - - - - void free_strlist( STRLIST sl ) { @@ -529,11 +471,6 @@ #ifdef USE_GNUPG_ICONV else { iconv_t cd; - -#ifdef _WIN32 - if (load_libiconv ()) - return G10ERR_GENERAL; -#endif /*_WIN32*/ cd = iconv_open (full_newset, "utf-8"); if (cd == (iconv_t)-1) { -- | Carlo Luciano Bianco | ICQ UIN: 109517158 | |______________________| Home page: | |GPG DSA/ElG 1024/4096:|_________________________________________________| |KeyID:0x5324A0DA - Fingerprint:8B00C61034120506111B143DEDBF71B45324A0DA | From clbianco at tiscalinet.it Fri Nov 19 01:41:53 2004 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Fri Nov 19 01:46:46 2004 Subject: Building 1.3.92 (and maybe 1.4.0) for Win32 References: Message-ID: Carlo Luciano Bianco wrote: > Now I tried also to check the libutil.a: > > ------------------------------------------------ > $ strings -a util/libutil.a | grep "vas" > _libintl_vasprintf > _libintl_vasprintf > vasprintf() failed > _vasprintf > ------------------------------------------------ > > So it seems that the vasprintf function has been correctly compiled in > the library... Can this be a gcc problem not finding it when linking? > And what is _libintl_vasprintf? Should it be used instead of plain > _vasprintf? Well... I tried and if I change the "vasprintf" occurrences in ttyio.c into "libintl_vasprintf" everything works. Moreover, Joe Vender pointed out to me that this problem does not happen at all if I do a "-static" build. I checked and the building process works correctly also with the unpatched ttyio.c. So it seems a MinGW gcc and/or ld problem (or, at least, of their configuration)... :-/ By the way, do you think it is correct to change "vasprintf" into "libintl_vasprintf" in ttyio.c? Beside the compilation, also "make check" seems ok... Thank you all for your help! -- | Carlo Luciano Bianco | ICQ UIN: 109517158 | |______________________| Home page: | |GPG DSA/ElG 1024/4096:|_________________________________________________| |KeyID:0x5324A0DA - Fingerprint:8B00C61034120506111B143DEDBF71B45324A0DA | From zuxy.meng at gmail.com Fri Nov 19 04:22:46 2004 From: zuxy.meng at gmail.com (Zuxy) Date: Fri Nov 19 04:19:43 2004 Subject: Is direct calling "iconv.dll" really needed in Win32? In-Reply-To: References: Message-ID: Simply because iconv.dll is not yet installed in most Windows desktops, so it's better for gnupg to check if it really exists. On Fri, 19 Nov 2004 00:41:52 +0000 (UTC), Carlo Luciano Bianco wrote: > Dear all, > > when I was trying to fix the building problem with GnuPG 1.3.92 and the > "vasprintf" function (see previous message), I did also the following > experiment: > > I removed from util/strgutil.c all the "#ifdef _WIN32" code for direct > calling the "iconv.dll" library, i.e. I applied the attached patch. Of > course, I added a "-liconv" to makefiles. > > So here comes my question. If the "standard" GnuPG code which works in a > Linux environment works also without problems in Win32, why adding a > "#ifdef _WIN32" code to do the same thing with a direct loading of > "iconv.dll"? > > Is this "special" code really needed for something else or can it be just > dropped in favor of the "standard" one, which maybe can even be linked > statically with libiconv.a solving some of the problems currently under > discussion on gnupg-users list? Most people here work under GNU/Linux and therefore they may consider a statically linked version as unnecessary. And most people here speak Western languages with only 26 letters and therefore they don't really need iconv.dll at all! -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6 From wk at gnupg.org Fri Nov 19 09:06:51 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Nov 19 09:09:33 2004 Subject: Build error in 1.3.93-cvs for Win32 In-Reply-To: <20041118155957.GA29385@jabberwocky.com> (David Shaw's message of "Thu, 18 Nov 2004 10:59:57 -0500") References: <419CBD05.7020900@comcast.net> <87actf2m5i.fsf@wheatstone.g10code.de> <20041118155957.GA29385@jabberwocky.com> Message-ID: <87is821cv8.fsf@wheatstone.g10code.de> On Thu, 18 Nov 2004 10:59:57 -0500, David Shaw said: > Maybe it would be better to not use S_IRGRP and S_IWGRP even on > Unixish machines. Why give group access at all? Its for debugging anyway and the fix was really trivial. Werner From pgut001 at cs.auckland.ac.nz Fri Nov 19 09:27:04 2004 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri Nov 19 09:23:57 2004 Subject: support for non-openpgp cards In-Reply-To: <419CF11B.8030104@globalnet.hr> Message-ID: Zeljko Vrba writes: >I believe that any PKCS#11 implementation for that card should work in >theory. > >Unfortunately, I have seen few PKCS#11 implementations (even commercial) that >correctly implement PKCS#11 spec in all relevant aspects. So that supporting >different PKCS#11 _implementation_ (even for the same card) could result in >big code changes.. > >So, what _in theory_ should be ONE source, _in practice_ that source gets >many #ifdefs for various PKCS#11 implementations.. :( I've spent a *lot* of time tuning the PKCS #11 code in cryptlib (http://www.cs.auckland.ac.nz/~pgut001/cryptlib/index.html) for a large number of (often quite buggy) PKCS #11 drivers. It's available under a GPL- compatible licence, so you could always just use that, it'll work with pretty much any PKCS #11 device except one or two extremely broken ones. Peter. From pgut001 at cs.auckland.ac.nz Fri Nov 19 09:32:20 2004 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri Nov 19 09:29:14 2004 Subject: support for non-openpgp cards In-Reply-To: Message-ID: Simon Josefsson writes: >IMHO, you should not care about broken implementations. There is a well- >defined PKCS#11 specification, even including header files. Write code for >the specification. If something doesn't work because someone isn't >implementing the specification, that's their problem. That would rule out about 99% of all PKCS #11 implementations in existence. The problem is twofold, firstly the spec is very flexible (since it covers a large number of crypto devices ranging from little tinkertoy smart cards up to high-end crypto coprocessors) so there's a lot of room for interpretation, secondly since the major driving force for PKCS #11 for many years was Netscape, many vendors implemented whatever Netscape needed, which includes Netscape bugs. So you can't create an implementation "for the specification" both because there are many ways to interpret it and because historically drivers have done things other than the way the spec said they should. Peter. From clbianco at tiscalinet.it Fri Nov 19 11:04:47 2004 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Fri Nov 19 11:01:21 2004 Subject: Is direct calling "iconv.dll" really needed in Win32? References: Message-ID: Zuxy wrote in news:a18e06b404111819224e166060__ 15581.9667656489$1100835276$gmane$org@mail.gmail.com: > Simply because iconv.dll is not yet installed in most Windows > desktops, so it's better for gnupg to check if it really exists. Well... OK, but this is not exactly my point. The code I cut away is not only to check if iconv.dll is present, but also to use its functions via a direct call and without actually linking the gpg.exe to libiconv. My question is why the Win32 version should have such a strange behavior, instead of just linking with libiconv and stop? With a plain link the check for iconv.dll presence is done by the OS itself... [...] > Most people here work under GNU/Linux and therefore they may consider > a statically linked version as unnecessary. I agree, I do not like static versions too, that's why I have not put a "LDFLAGS='-static'" in the instructions on my web page... > And most people here speak > Western languages with only 26 letters and therefore they don't really > need iconv.dll at all! So, let me understand: Is all this code just to allow some Win32 users to use their gpg.exe without having an iconv.dll installed if they do not need it? -- | Carlo Luciano Bianco | ICQ UIN: 109517158 | |______________________| Home page: | |GPG DSA/ElG 1024/4096:|_________________________________________________| |KeyID:0x5324A0DA - Fingerprint:8B00C61034120506111B143DEDBF71B45324A0DA | From wk at gnupg.org Fri Nov 19 15:50:14 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Nov 19 15:54:34 2004 Subject: Is direct calling "iconv.dll" really needed in Win32? In-Reply-To: (Carlo Luciano Bianco's message of "Fri, 19 Nov 2004 10:04:47 +0000 (UTC)") References: Message-ID: <87brdtrizd.fsf@wheatstone.g10code.de> On Fri, 19 Nov 2004 10:04:47 +0000 (UTC), Carlo Luciano Bianco said: > My question is why the Win32 version should have such a strange behavior, > instead of just linking with libiconv and stop? I don't understand what you mean by strange. It is a convenience to the user to allow running without a installed iconv.dll. I can't see what your problem is except for the little bug that it returns an error code if iconv was not found. > So, let me understand: Is all this code just to allow some Win32 users to 34 lines of straightforward code isn't much. > use their gpg.exe without having an iconv.dll installed if they do not need > it? Yes. Werner From jas at extundo.com Fri Nov 19 17:25:49 2004 From: jas at extundo.com (Simon Josefsson) Date: Fri Nov 19 17:22:29 2004 Subject: support for non-openpgp cards References: Message-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Simon Josefsson writes: > >>IMHO, you should not care about broken implementations. There is a well- >>defined PKCS#11 specification, even including header files. Write code for >>the specification. If something doesn't work because someone isn't >>implementing the specification, that's their problem. > > That would rule out about 99% of all PKCS #11 implementations in existence. > The problem is twofold, firstly the spec is very flexible (since it covers a > large number of crypto devices ranging from little tinkertoy smart cards up to > high-end crypto coprocessors) so there's a lot of room for interpretation, > secondly since the major driving force for PKCS #11 for many years was > Netscape, many vendors implemented whatever Netscape needed, which includes > Netscape bugs. So you can't create an implementation "for the specification" > both because there are many ways to interpret it and because historically > drivers have done things other than the way the spec said they should. Then we could try to fix those buggy implementations, and improve the specification. Meanwhile, a realistic way forward might be to write clean code that rely on unambiguous APIs, and move the bug workaround ugliness into some library that talks with the drivers. Then ideally, over time, as implementations are improved, the middle library will gradually be smaller and smaller. And throughout that time, the core application code will be clean and readable. I think that writing code that cater to buggy external packages lead to unreadable and potentially dangerous code. So I believe strongly that bug-compatibility code should be separated from core applications. For POSIX/C99 functions, I recommend gnulib . Another advantage is that many packages will benefit from the same middle-layer code. That leads to higher quality of the bug-compatibility code, than what could be hoped for if every project had to maintain it's own such code. The OpenSSH team seem to use a similar strategy, and the code is almost a joy to read now. Regards, Simon From pgut001 at cs.auckland.ac.nz Sat Nov 20 07:40:10 2004 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sat Nov 20 07:37:04 2004 Subject: support for non-openpgp cards In-Reply-To: Message-ID: Simon Josefsson writes: >Then we could try to fix those buggy implementations, and improve the >specification. That'll never happen. Many vendors won't even *respond* to bug reports, let alone try and fix them. If you're a major customer and you have a showstopper bug you can probably get it fixed if sales are hinging on it, but that's about it. (OK, all vendors aren't that bad, particularly if you can figure out how to get past their wetware firewalls to the techies, but in general it doesn't look good). >Meanwhile, a realistic way forward might be to write clean code that rely on >unambiguous APIs, and move the bug workaround ugliness into some library that >talks with the drivers. Urgh, then you end up with a huge pile of mapping layers, one for each driver version (not just driver vendor, but individual driver version). The way to do this is to write lowest-common-demoninator code that works for most drivers. As I mentioned in a previous message, I've already done this for almost everything that's out there. >Then ideally, over time, as implementations are improved, This assumes that implementations will improve over time. Peter. From zvrba at globalnet.hr Sun Nov 21 09:42:36 2004 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Sun Nov 21 09:34:44 2004 Subject: PKCS#11 card status summary Message-ID: <41A054FC.5010906@globalnet.hr> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 I caught some time this weekend to play with OpenSC + GPG. Now here are the results: ===== (conclusion first, as this also goes to users list) In conclusion, the best I could do, both with MUSCLE and OpenSC[1], is the following scenario: 1. Support ONE RSA/1024 keypair per card. 2. This keypair would be used exclusively for signing. 3. The card and keypair is initialized by some extra utilities unknown to GPG. 4. The configuration about existing keypair (and other meta-data that GNUPG stores normally on OpenPGP card) is read/written from/to configuration file (in the patch is an example of pkcs11.config). What I don't know how to do is persuade GPG that a signing keypair is on the card. GPG 'generate' command assumes that the user has an OpenPGP card and always tries to generate 3 keypairs. [1] Within the scope of making a patch to support PKCS#11 cards in GNUPG. If I had the time I could also make patches to MUSCLE and/or OpenSC but I think it would be unacceptable to most existing users of those tools. Also I don't have the time to keep pace with development of those libraries. ===== (technical details regarding OpenSC) 1. OpenSC pkcs15-init is the only way to format the card and create PKCS#15 file structure on it (PKCS#15 is what OpenSC is all about). The sequence goes something like this: pkcs15-init -E -C pkcs15-init --store-pin --auth-id 0 After formatting, the Cryptoflex key files are missing. I am not able to generate a key by PKCS#11 interface after this procedure. 2. After that I generate the key with pkcs15-init -G rsa/1024 --auth-id 0 Unfortunately the key is marked as sign only for PKCS#11, and the PKCS#11 reports that the key is inconsistent with its usage when I call C_DecryptInit. I have not found a way to mark the same key decrypt+sign. Browsing through the source, it should be made automatically if possible. Why do I even need C_Decrypt? Well, PKCS#11 tokens can return public and private keys in arbitrary order and they do not have to be labeled in any way. I need to pair them and present them as a single fingerprint to GPG. So I iterate over all public keys on the card, encrypt a sample message and try decryption with each private key. When the decryption gives back the original content, I've found a keypair. I can accomplish the same goal with C_Sign. 3. OpenSC thinks that my card (Cryptoflex 8k) doesn't have RSA keygen capability so it generates the key off-card and imports it. Well, it thinks plain *WRONG*. Cryptoflex 8k *DOES* have a keygen capability (some do, some don't. but anyway, why not first try to generate on-card and if the card reports an error, generate off-card and import. the card capabilities are *HARD-CODED* into OpenSC). (BTW, I have rather old cards, OpenSC didn't have my ATR in its database so I already did hack throught that part of the code). 4. OpenSC Cryptoflex card profile is strange so that I can't have more than one key pair. Strangely, pkcs15-init leaves about 4k for user data which is unused, but there is no room for another keypair directory (long story about filesystem allocation on cards..) 5. My original idea was using OpenSC PKCS#15 API to access the card. However, Werner rejected the idea (in private communication) on the grounds that OpenSC is unstable regarding the API (i.e. arbitrary API changes between versions, breaking ABI without changing the major library version number etc.). Based on his arguments (which I hold valid) I decided to make a new patch using PKCS#11 and disregard the idea of using OpenSC's PKCS#15 API. - -- The corresponding PGP public key can be found at: http://ds.carnet.hr:11371/pks/lookup?op=get&search=0x5081D08A1DC7E994 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBoFT8UIHQih3H6ZQRAx/vAKDZLEJeDfJrpqoVOyu7Ct15Gl0rYgCfUV5R A/VB8Wdik8m9/vxjhR9oDns= =J9DE -----END PGP SIGNATURE----- From Barry.Schwartz at chemoelectric.org Mon Nov 22 12:49:42 2004 From: Barry.Schwartz at chemoelectric.org (Barry.Schwartz@chemoelectric.org) Date: Mon Nov 22 12:46:39 2004 Subject: gnupg 1.9.12 fix Message-ID: <20041122114942.GA1286@crud.crud.mn.org> I had a little segmentation violation problem with gpg-agent in the gnupg-1.9.12 package. Here's the fix I used, hoping I'm not duplicating someone else's work or making a mistake: --- gnupg-1.9.12.ORIG/jnlib/logging.c 2004-10-21 19:00:25.000000000 +0000 +++ gnupg-1.9.12/jnlib/logging.c 2004-11-22 11:41:01.029095930 +0000 @@ -411,9 +411,12 @@ int log_test_fd (int fd) { - int tmp = fileno (logstream); - if ( tmp != -1 && tmp == fd) - return 1; + if (logstream != NULL) + { + int tmp = fileno (logstream); + if ( tmp != -1 && tmp == fd) + return 1; + } if (log_socket != -1 && log_socket == fd) return 1; return 0; From wk at gnupg.org Mon Nov 22 14:01:41 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Nov 22 14:04:41 2004 Subject: gnupg 1.9.12 fix In-Reply-To: <20041122114942.GA1286@crud.crud.mn.org> (Barry Schwartz's message of "Mon, 22 Nov 2004 05:49:42 -0600") References: <20041122114942.GA1286@crud.crud.mn.org> Message-ID: <87oehqm40a.fsf@wheatstone.g10code.de> On Mon, 22 Nov 2004 05:49:42 -0600, Barry Schwartz said: > I had a little segmentation violation problem with gpg-agent in the > gnupg-1.9.12 package. Here's the fix I used, hoping I'm not > duplicating someone else's work or making a mistake: That seems to be correct. Thanks, Werner From envite at rolamasao.org Sat Nov 27 00:56:44 2004 From: envite at rolamasao.org (Noel Torres) Date: Sat Nov 27 00:53:15 2004 Subject: Unconsistence in gpgme.info Message-ID: <41A7C2BC.1040609@rolamasao.org> I found an unconsistence in gpgme.info, section 7.1 Funktion: gpgme_error_t gpgme_new (gpgme_ctx_t *CTX) The function `gpgme_data_new' creates a new `gpgme_ctx_t' object and returns a handle for it in CTX. As you can see, it gives two diferent names to the same function: gpgme_new gpgme_data_new er Envite From mo at g10code.com Mon Nov 29 21:27:29 2004 From: mo at g10code.com (Moritz Schulte) Date: Mon Nov 29 21:23:51 2004 Subject: Poldi 0.2 released Message-ID: <20041129192155.GA3009@sarkutty> Poldi 0.2 has been released. Poldi is a PAM module implementing authentication via OpenPGP smart cards. Files: ftp://ftp.gnupg.org/people/moritz/poldi/poldi-0.2.tar.gz (287K) ftp://ftp.gnupg.org/people/moritz/poldi/poldi-0.2.tar.gz.asc MD5 sums are: e6c6923ac6fe02bdadd1975761464e20 poldi-0.2.tar.gz d12ec8a769b63b4cb61c76c85609b501 poldi-0.2.tar.gz.asc ChangeLog: * Source re-organization; * New maintaince tool `poldi-ctrl' (supports adding/removing of keys, dumping card information, testing the authentication mechanism, ...; poldi-key2sexp has been removed, since it is obsoleted by poldi-ctrl); * Supports `wait-for-card' feature (allows login programs to wait for insertion of a card instead of querying for a username); * Improved documentation; * Bug fixes and minor feature enhancements. Happy hacking, Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : /pipermail/attachments/20041129/90f8159a/attachment.bin