From dshaw at jabberwocky.com Thu Sep 1 05:05:16 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Sep 1 05:06:16 2005 Subject: [Sks-devel] Re: zero-length MPIs (was: Re: mpi error with check-trustdb in 1.4.2 - resolved) In-Reply-To: <20050824130716.GA4211@suse.de> References: <42F97044.9050603@comcast.net> <42FAC641.9040507@comcast.net> <20050811160217.GC358@wilma.widomaker.com> <20050811182144.GA33562@wilma.widomaker.com> <20050811195459.GB12783@opium.palfrader.org> <20050812002243.GD358@wilma.widomaker.com> <20050824130716.GA4211@suse.de> Message-ID: <20050901030516.GA20299@jabberwocky.com> On Wed, Aug 24, 2005 at 03:07:17PM +0200, Klaus Singvogel wrote: > I noticed that these messages are coming from > mpi/mpicoder.c:mpi_read() and had a closer look at it. :-) > > The second if check, for "goto overflow;" seems a bit doubtful (maybe > a copy&paste without to much thinking whats coming next ? :-) As > there are no mandatory reads from the iobuf coming, only optional > reads, I changed the code to "if (++nread > nmax)" and the problem > was gone (see attached patch). I think this is very close, but not perfect. You must also protect against accidentally reading too many bytes, as then you can't parse the rest of the stream. Try this patch. David -------------- next part -------------- Index: mpicoder.c =================================================================== --- mpicoder.c (revision 3878) +++ mpicoder.c (working copy) @@ -80,16 +80,20 @@ mpi_limb_t a; MPI val = MPI_NULL; + if (nread == nmax) + goto overflow; if( (c = iobuf_get(inp)) == -1 ) goto leave; - if (++nread >= nmax) + nread++; + nbits = c << 8; + + if (nread == nmax) goto overflow; - nbits = c << 8; if( (c = iobuf_get(inp)) == -1 ) goto leave; - if (++nread >= nmax) - goto overflow; + nread++; nbits |= c; + if( nbits > MAX_EXTERN_MPI_BITS ) { log_error("mpi too large for this implementation (%u bits)\n", nbits); goto leave; @@ -112,7 +116,7 @@ for( ; j > 0; j-- ) { a = 0; for(; i < BYTES_PER_MPI_LIMB; i++ ) { - if (nread >= nmax) { + if (nread == nmax) { #ifdef M_DEBUG mpi_debug_free (val); #else From sadam at CLEMSON.EDU Thu Sep 1 05:56:26 2005 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Thu Sep 1 05:56:35 2005 Subject: [Sks-devel] Re: zero-length MPIs In-Reply-To: <20050901030516.GA20299@jabberwocky.com> References: <42F97044.9050603@comcast.net> <42FAC641.9040507@comcast.net> <20050811160217.GC358@wilma.widomaker.com> <20050811182144.GA33562@wilma.widomaker.com> <20050811195459.GB12783@opium.palfrader.org> <20050812002243.GD358@wilma.widomaker.com> <20050824130716.GA4211@suse.de> <20050901030516.GA20299@jabberwocky.com> Message-ID: <43167BEA.1080205@clemson.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > Try this patch. I get an MPI error with this patch I didn't get with Klaus'. *snip* gpg: mpi larger than indicated length (2 bytes) gpg: keyring_get_keyblock: read error: invalid packet gpg: keydb_get_keyblock failed: invalid keyring *snip* Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFDFnvqjU1oaHEI4wgRAv/MAKCltzlrWdWElPm4Gis173DWKeHKvACYyJdW xXcd3RTxVp7/8OF7TeezrA== =bdKw -----END PGP SIGNATURE----- From sadam at CLEMSON.EDU Thu Sep 1 05:58:47 2005 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Thu Sep 1 05:58:29 2005 Subject: [Sks-devel] Re: zero-length MPIs In-Reply-To: <20050901030516.GA20299@jabberwocky.com> References: <42F97044.9050603@comcast.net> <42FAC641.9040507@comcast.net> <20050811160217.GC358@wilma.widomaker.com> <20050811182144.GA33562@wilma.widomaker.com> <20050811195459.GB12783@opium.palfrader.org> <20050812002243.GD358@wilma.widomaker.com> <20050824130716.GA4211@suse.de> <20050901030516.GA20299@jabberwocky.com> Message-ID: <43167C77.2020009@clemson.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please ignore my previous email. The patch works for me. Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFnx3jU1oaHEI4wgRAihPAJkB2BpJW+fej/HfvStxYCQTdCvETQCg4jA4 DA7CvncNxh2hDubCGbIoO2A= =Can1 -----END PGP SIGNATURE----- From harry_b at mm.st Thu Sep 1 10:49:03 2005 From: harry_b at mm.st (harry_b@mm.st) Date: Thu Sep 1 10:49:22 2005 Subject: GPG/GPGME problem In-Reply-To: <87k6isf8y6.wl@ulysses.g10code.de> References: <1123261674.1504.240068676@webmail.messagingengine.com> <87k6isf8y6.wl@ulysses.g10code.de> Message-ID: <6D81B7D9696A0683EAB7EBBA@[192.168.42.12]> Hi Marcus, I can reproduce this weird behavior with gpg each time - even without my own program when I use one of the buggy data file. The problem only occurs, when I encrypt and sign the file - encryption or signing only does not have this problem and works like expected. Wgen I run 'gpg --debug-all --decrypt BUGGYFILE' I get this debug output before it terminates: [...] gpg: DBG: iobuf-14.0: close `file_filter(fd)' gpg: DBG: /home/harry/.gnupg/pubring.gpg: close fd 6 gpg: DBG: fd_cache_close (/home/harry/.gnupg/pubring.gpg) used existing slot gpg: DBG: finish_lookup: checking key XXXXXXXX (all)(req_usage=0) gpg: DBG: using key XXXXXXXX gpg: DBG: cache_user_id: already in cache gpg: DBG: iobuf-13.0: close `file_filter(fd)' gpg: DBG: /home/harry/.gnupg/pubring.gpg: close fd 7 gpg: DBG: fd_cache_close (/home/harry/.gnupg/pubring.gpg) used existing slot gpg: Good signature from "my key " gpg: DBG: free_packet() type=6 gpg: DBG: mpi_free [...] gpg: DBG: dummy m_size called gpg: DBG: mpi_free_limb_space of size 0 gpg: DBG: free_packet() type=8 gpg: [don't know]: invalid packet (ctb=14) gpg: DBG: free_packet() type=18 gpg: DBG: iobuf-1.2: underflow: req=8192 gpg: DBG: iobuf-1.2: underflow: got=0 rc=-1 gpg: DBG: iobuf-1.2: pop `(null)' in underflow (!len) gpg: DBG: iobuf chain: 1.0 `file_filter(fd)' filter_eof=0 start=4675 len=4675 gpg: DBG: iobuf-1.0: underflow: eof gpg: DBG: iobuf-1.0: close `file_filter(fd)' gpg: DBG: check-data-410-1.data.gpg: close fd 3 gpg: DBG: fd_cache_close (check-data-410-1.data.gpg) new slot created random usage: poolsize=600 mixed=4 polls=0/28 added=140/2464 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 1408/3968 bytes in 2/9 blocks of pool 5472/32768 I could send you my program and a detailted description to run my tests - it basically is just a configure, make, make test scenario so maybe you can reproduce this on your side. Unfortunately I have access to Debian unstable machines and there it continually behaves this weird. I am not sure if it's the case on other Linux' as well. :-/ Is there anything I can do to track this further down? Harry --On Thursday, August 11, 2005 11:41:05 PM +0200 Marcus Brinkmann wrote: > At Fri, 05 Aug 2005 19:07:54 +0200, > harry_b@mm.st wrote: >> I am pretty confused about a problem with gpg and gpgme. I am working on >> an encryption program and for this I wrote some test sequences which now >> give me a hard time. Every 1000 runs or so, the following steps produce >> a weird error which even gpg itself messes up. :-/ >> >> I am on Debian unstable and use GPG 1.4.1 and gpgme 1.0.2. >> >> My test runs these steps: >> 1. Create some random XML data file >> 2. gzip this file (as my application does using zlib) >> $ gzip -9 FILE_A >> 3. encode it with a testkey >> $ echo "1234567890" | GNUPGHOME=./tests GPG_AGENT_INFO= gpg >> --no-tty --recipient="TESTKEY" --passphrase-fd 0 --armour --sign >> --encrypt --output="FILE_B" "FILE_A" >> 4. run my application and see if it can decrypt the file and write >> the same data again >> 5. compare the gpg file with my own file >> >> The problem now is, that even gpg can't decrypt it's own file FILE_B. I >> tried this with several keys and it happens with all of my keys. :-( > > You may try to keep debug logs of the gpg runs in step 3, so that you > can catch the failing case and at least have some information about > it. Then check if it is reproducible with the same data set (ie, run > only step 3 on the same data a couple thousand times). > >> I get these two errors: >> - gpg reports: gpg: [don't know]: invalid packet (ctb=14) >> - gpgme reports: Unexpected signature summary: 0x800 > > The GPGME output may itself be a bit problematic if GPGME doesn't cope > with the error output of gpg very well (that may be the case, we can > look at this individually, for example if you send me the broken file > so I can reproduce it). But of course if your step 3 above creates an > invalid file, then the problem must be GPG or the way you are using it > (although the command line looks basically OK to me). > >> The weird thing is, that it seems to depend on the data which I create >> pretty randomly with a little perl script. > > If it depends on the data, that would be good, because then step 3 > would be reproducible. If it fails sometimes and works some other > times on the same data set, then this points to a completely different > class of bugs, which can be harder to track down. > >> Any ideas what I can do about this very weird thing? > > A better (ie more isolated, more specific) test case would be good. > >> PS: Some of these buggy files are in the attached tar.gz file. >> [2 buggy-files.tar.gz ] > > I get EOF on all of them, not even invalid packet... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050901/06eed909/attachment.pgp From kssingvo at suse.de Thu Sep 1 13:28:47 2005 From: kssingvo at suse.de (Klaus Singvogel) Date: Thu Sep 1 13:29:24 2005 Subject: [Sks-devel] Re: zero-length MPIs In-Reply-To: <43167C77.2020009@clemson.edu> References: <42F97044.9050603@comcast.net> <42FAC641.9040507@comcast.net> <20050811160217.GC358@wilma.widomaker.com> <20050811182144.GA33562@wilma.widomaker.com> <20050811195459.GB12783@opium.palfrader.org> <20050812002243.GD358@wilma.widomaker.com> <20050824130716.GA4211@suse.de> <20050901030516.GA20299@jabberwocky.com> <43167C77.2020009@clemson.edu> Message-ID: <20050901112846.GA5580@suse.de> -----BEGIN PGP SIGNED MESSAGE----- I can confirm too that the patch of David Shaw is working fine. Thanks. Regards, Klaus. Adam Schreiber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Please ignore my previous email. The patch works for me. > > > Adam Schreiber > > - -- > Why isn't all of your email protected? > http://gnupg.org > http://enigmail.mozdev.org > http://seahorse.sourceforge.net > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFDFnx3jU1oaHEI4wgRAihPAJkB2BpJW+fej/HfvStxYCQTdCvETQCg4jA4 > DA7CvncNxh2hDubCGbIoO2A= > =Can1 > -----END PGP SIGNATURE----- - -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQCVAwUBQxbl7rbjw8ZQaHktAQF9PgP/Z0Xs81u0SjC98iCK9mmQEKI/c/5Q54CO /fj/LkkunLQ7r+5ywwxJ/5htLEHKz4iY5QCvYCGc72H8S0IqX1KN3ThTTTsWiDy6 FWVb/svpOfQks9Zu6MJegxiphX+oHwieza6SVB3Y5/r2pC/gzQF3syiC/YOoI6r1 DbMPEtF0FSE= =ran3 -----END PGP SIGNATURE----- From harakiri_23 at yahoo.com Thu Sep 1 14:30:08 2005 From: harakiri_23 at yahoo.com (Harakiri) Date: Thu Sep 1 14:30:56 2005 Subject: Bug in GPG for Windows - gpg: invalid key resource URL for keyrings Message-ID: <20050901123009.28402.qmail@web53009.mail.yahoo.com> Hi, im using the same version (1.4.2) and tested this on multiple WinXP clients - this seems to be an issue with the cygwin GNUPG - i installed gpg through the setup installer of cygwin. Anyone else have the same issues ? > > --- Michael Schierl wrote: > > > Harakiri schrieb: > > > > > gpg --homedir c:\keys\tmp --batch --yes > --verbose > > > --status-fd 2 --no-default-keyring --keyring > > > c:\keys\tmp\pubring.gpg --secret-keyring > > > c:\keys\tmp\secring.gpg --import > c:\keys\mykey.asc > > > > > > output : > > > > > > gpg: invalid key resource URL > > > `c:\keys\tmp\secring.gpg' > > > gpg: keyblock resource `(null)': general error > > > gpg: invalid key resource URL > > > `c:\keys\tmp\pubring.gpg' > > > gpg: keyblock resource `(null)': general error > > > > > > (you can copy and paste this and verify it for > > > yourself - you dont even need to have these > > > directories or a key) > > > > Hmm: > > > > C:\>gpg --homedir c:\keys\tmp --batch --yes > > --verbose --status-fd 2 > > --no-default-keyring --keyring > > c:\keys\tmp\pubring.gpg > > --secret-keyring c:\keys\tmp\secring.gpg > > --import c:\keys\mykey.asc > > > > gpg: keyblock resource `c:\keys\tmp\secring.gpg': > > file open error > > gpg: keyblock resource `c:\keys\tmp\pubring.gpg': > > file open error > > gpg: can't open `c:\keys\mykey.asc': No such file > or > > directory > > gpg: Total number processed: 0 > > [GNUPG:] IMPORT_RES 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > > > After creating c:\keys\tmp it works as expected. > > > > C:\>gpg --version > > gpg (GnuPG) 1.4.2 > > > > C:\>ver > > > > Microsoft Windows 2000 [Version 5.00.2195] > > > > Please supply more information. > > > > Michael > > > > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From benjamin at pythagoras.no-ip.org Fri Sep 2 13:47:36 2005 From: benjamin at pythagoras.no-ip.org (Benjamin Donnachie) Date: Fri Sep 2 13:52:21 2005 Subject: OpenPGG Card Message-ID: <85000712c0e502626e38ba79992949d3@www.pythagoras.no-ip.org> Alon Bar-Lev wrote: >I think that gpg should support PKCS#11 interface for smartcards, so >that it can be used with all smartcards that support this standard. I've had a quick look at the PKCS#11 and I think that you may have a point! >I don't understand why gpg developers choose to implement their own >smartcard standard... Nor me - the OpenPGP card seems to be anything but open to me! >The most reasonable claim I've got was the licensing issue... But nobody >succeeded in proving that there is a licensing problem. I think MUSCLE (Movement for the Use of SmartCards in a Linux Environment http://www.linuxnet.com) uses PKCS - I could be wrong though, I need to read through it in more detail. >You can look for messages with "PKCS#11 support for gpg-agent" subject >for future information at gnupg-users. I saw that... Perhaps we should "fork" GPG and work on a PKCS#11 compliant version... I'm fairly new to smartcards, but I have a fair bit of other programming experience... I don't think it would be too difficult to implement with the libraries that are available once I get hold of a suitable card... -- Benjamin benjamin@pythagoras.no-ip.org From alon.barlev at gmail.com Thu Sep 1 12:54:52 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri Sep 2 15:54:56 2005 Subject: OpenPGG Card In-Reply-To: References: <84ee92c719bd8f3b10caaec695f20cc2__25836.3736131743$1125141464$gmane$org@www.pythagoras.no-ip.org> Message-ID: <4316DDFC.5060804@gmail.com> Hello, I am sorry to intrude... But I had a discussion with Werner Koch about a similar issue. I think that gpg should support PKCS#11 interface for smartcards, so that it can be used with all smartcards that support this standard. PKCS#11 is the most used and most implemented standard. I don't understand why gpg developers choose to implement their own smartcard standard... The most reasonable claim I've got was the licensing issue... But nobody succeeded in proving that there is a licensing problem. You can look for messages with "PKCS#11 support for gpg-agent" subject for future information at gnupg-users. Best Regards, Alon Bar-Lev. Joe Smith wrote: > There is no need to post a message to the list three times. > >> Is it possible to obtain further details on the OpenPGP card? >> >> I have such a card and a working smartcard reader but, ideally, I'd >> like to >> obtain copies of the sourcecode and program my own cards. However, it's >> extremely difficult to track down any specific information! > > > You can get aditional information, but unfortunately the information > available is not to particularly satisfying. > > That said these are the details I know: > The openPGP cards are manufactured by PPC Card Systems using a chip > created by Atmel, running BasicCard OS, and code written presumably by > Werner Koch. The cards are non-reprogrammable, they are set to state > 'RUN'. > > The last I asked there were no other manufactures of OpenPGP Card > complient smartcards. > > ----- > > Ideally one should be able to just buy a smart card with rsa support, > download OpenPGP card source, and compile it. Then flash it and any > other things you wish to have on the card. However it sadly does not > work that way. > > Source code is not available. Here is a quote from an email Werner > sent me: > >>> Is the source for the program on the card available? >> >> >> No, this is not possible because the chip vendors supply chips only to >> large card vendors due to fear of litigation through Pay TV channels. >> They had pretty bad experience with that in recent years. Same goes >> with the firmare supplied with the chip which is the base of the >> (actual very small) application we did. Atmel will even stop the >> production of the chip we are currently using due to force by Pay TV >> lawyers (the same chip is used in many Pay TV scrambling systems; and >> they all use security by litigation). Its all a very sad and >> ridiculous situation. > > > If you can somehow manage to get ahold of a BasicCard OS-based > smartcard that has support for RSA, it would not be too difficult to > program it. Most of the crypto stuff is handled by the chip, so the > code needed to be written is mainly interface code. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From alon.barlev at gmail.com Fri Sep 2 15:13:45 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri Sep 2 15:54:58 2005 Subject: OpenPGP Card In-Reply-To: <85000712c0e502626e38ba79992949d3@www.pythagoras.no-ip.org> References: <85000712c0e502626e38ba79992949d3@www.pythagoras.no-ip.org> Message-ID: <43185009.6060206@gmail.com> Benjamin Donnachie wrote: >Alon Bar-Lev wrote: > > >>I think that gpg should support PKCS#11 interface for smartcards, so >>that it can be used with all smartcards that support this standard. >> >> > >I've had a quick look at the PKCS#11 and I think that you may have a point! > > >>I don't understand why gpg developers choose to implement their own >>smartcard standard... >> >> > >Nor me - the OpenPGP card seems to be anything but open to me! > > Finally someone who understand... I had no such luck with Werner Koch, who argues that OpenPGP card is standard... I've promised him to not bother any more with this issue... >>The most reasonable claim I've got was the licensing issue... But nobody >>succeeded in proving that there is a licensing problem. >> >> > >I think MUSCLE (Movement for the Use of SmartCards in a Linux Environment >http://www.linuxnet.com) uses PKCS - I could be wrong though, I need to read >through it in more detail. > > Yes... I don't think there is a problem with licensing... All problems are in result of an approach that each application may define how its smartcard should be built. This approach like any other proprietary approach will disappear along with its software, as it was with other software that did not support generic devices like printers, modems etc... >>You can look for messages with "PKCS#11 support for gpg-agent" subject >>for future information at gnupg-users. >> >> > > >I saw that... Perhaps we should "fork" GPG and work on a PKCS#11 compliant >version... I'm fairly new to smartcards, but I have a fair bit of other >programming experience... >I don't think it would be too difficult to implement with the libraries that >are available once I get hold of a suitable card... > > I don't think it is wise... There are some suitable cards that provide PKCS#11 in Linux, forcing your card to use gpg will not allow you to use it with your browser or with your standard mail client. Just a thought... why do you use gpg? which feature you require? Maybe there are some alternatives without using proprietary hardware. Best Regards, Alon Bar-Lev. From alon.barlev at gmail.com Fri Sep 2 17:45:53 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri Sep 2 16:55:51 2005 Subject: OpenPGP Card In-Reply-To: <200509021613.47029.joerg@schmitz-linneweber.de> References: <85000712c0e502626e38ba79992949d3@www.pythagoras.no-ip.org> <43185009.6060206@gmail.com> <200509021613.47029.joerg@schmitz-linneweber.de> Message-ID: <431873B1.3050703@gmail.com> Joerg Schmitz-Linneweber wrote: > Hi Alon! > > I would like to see support for PKCS#11 too but... > (won't elaborate on this now ;-) I will be glad if you will... It seems that I am the only one that don't understand gpg motivation. > > Regarding the "open-ness" of OpenGPG: Why do you (and Benjamin) think its not > open (enough)? > The specs are there and you are free to implement "both sides" of the (smart) > card. > For me the specs allow(ed) it to try implementing OpenGPG on a IBM JavaCard > (and it *would* be possible to have a JavaCard implement OpenGPG in parallel > to PKCS#11...) > > Just my 2cts... Salut, J?rg > This is EXACTLY the problem. If you have a RSA private key and X.509v3 certificate that refers to the public key, you expect this key to be shared among all applications that you use. If you had to write an separate applet and provider for each application you make the cost of smartcard integration EXTREMELY high! On the other hand, if you implement a software API for accessing a generic smartcard, then you don't need to implement any special software in order to use smartcard type A or smartcard type B. This is all PKCS#11 is about (Or Microsoft CSP in Windows environment...) It provides a generic API to access cryptographic tokens. Most smartcard vendors, including IBM, provide PKCS#11 library that communicates with their card. PKCS#11 application can benefit from it as well as the user... No proprietary code should be written in order to make your software work with your hardware. Best Regards, Alon Bar-Lev. From wk at gnupg.org Fri Sep 2 17:45:31 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Sep 2 17:51:23 2005 Subject: OpenPGP Card In-Reply-To: <431873B1.3050703@gmail.com> (Alon Bar-Lev's message of "Fri, 02 Sep 2005 18:45:53 +0300") References: <85000712c0e502626e38ba79992949d3@www.pythagoras.no-ip.org> <43185009.6060206@gmail.com> <200509021613.47029.joerg@schmitz-linneweber.de> <431873B1.3050703@gmail.com> Message-ID: <87vf1jiick.fsf@wheatstone.g10code.de> On Fri, 02 Sep 2005 18:45:53 +0300, Alon Bar-Lev said: > environment...) It provides a generic API to access cryptographic > tokens. Most smartcard vendors, including IBM, provide PKCS#11 library > that communicates with their card. Again: Feel free to provide one. The only thing you need is libassuan to connect to gpg-agent. libassuan is even under LGPL so you can use it with any kind of application - just put it into a shared library. If something should be missing in gpg-agent to implement this, I will help by adding the required facilities. However, I don't have the time to write a pkcs#11 library for gpg-agent/scdaemon for free. If this is that important for you and you don't want to do it yourself, well ask me at my company address. Shalom-Salam, Werner From wk at gnupg.org Fri Sep 2 17:37:52 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Sep 2 19:22:06 2005 Subject: OpenPGP Card In-Reply-To: <43185009.6060206@gmail.com> (Alon Bar-Lev's message of "Fri, 02 Sep 2005 16:13:45 +0300") References: <85000712c0e502626e38ba79992949d3@www.pythagoras.no-ip.org> <43185009.6060206@gmail.com> Message-ID: <87zmqviipb.fsf@wheatstone.g10code.de> On Fri, 02 Sep 2005 16:13:45 +0300, Alon Bar-Lev said: > Finally someone who understand... I had no such luck with Werner Koch, who > argues that OpenPGP card is standard... Well it is as much a standard as pkcs#15 is one. Who decides what a standard is? RSA Corporation defines standards known as PKCS, we define an ISO7816 compliant standard for a card, dubbed OpenPGP card. You may use this one or do it like 99% of the smartcard vendors and use a proprietary card application where the specs are in the best case only available under NDA. > an approach that each application may define how its smartcard should > be built. > This approach like any other proprietary approach will disappear along > with its software, Huh? It is not about a particular application, it just happens that gpg suuports this card. There are other application unrelated to gpg also using this card, for example the Poldi PAM. I also know of other projjects using this card - just because it is well defined and the specs are open. > I don't think it is wise... There are some suitable cards that provide > PKCS#11 in Linux, Please go an read the standard before talking about it: No card implements PKCS#11 because that is an API between a token provider and an application. No ISO compliant card will be able to implement PKCS#11. You might be thinking about pkcs#15 - this is indeed a standard which defines how a card application may appear to software. However there are many variants of pkcs#15, it is complicated and experience showed that it didn't helped much with interoperability. Given that card application are pretty small beasts, it seems to me far easier to add its counterpart to the host application than to hammer it into a limited framework. Salam-Shalom, Werner -- An engineer, a chemist, and a standards designer are stranded on a desert island with absolutely nothing on it. One of them finds a can of spam washed up by the waves. The engineer says "Taking the strength of the seams into account, we can calculate that bashing it against a rock with a given force will open it up without destroying the contents". The chemist says "Taking the type of metal the can is made of into account, we can calculate that further immersion in salt water will corrode it enough to allow it to be easily opened after a day". The standards designer gives the other two a condescending look, gazes into the middle distance, and begins "Assuming we have an electric can opener...". - from Peter Gutman's X.509 Style Guide From jsogo at debian.org Sat Sep 3 10:49:37 2005 From: jsogo at debian.org (Jose Carlos Garcia Sogo) Date: Sat Sep 3 10:49:43 2005 Subject: GnuPG has switched to Subversion In-Reply-To: <874qaem44p.fsf@wheatstone.g10code.de> References: <874qaem44p.fsf@wheatstone.g10code.de> Message-ID: <1125737377.14221.1.camel@gimli.tribulaciones.org> El vie, 29-07-2005 a las 10:02 +0200, Werner Koch escribi?: > Hi! > > I have justed finished switching GnuPG from CVS to Subversion. And this should be changed in webpage. It still refer to CVS. Thanks -- Jose Carlos Garcia Sogo jsogo@debian.org From wk at gnupg.org Sun Sep 4 13:42:45 2005 From: wk at gnupg.org (Werner Koch) Date: Sun Sep 4 13:44:20 2005 Subject: GPGol released Message-ID: <8764thawju.fsf@wheatstone.g10code.de> Hi, I have just released a first version of GPGol, the new GPG plugin for MS Outlook. The intention is to replace the old G-DATA plugin by more modern code. We basically rewrote it from scratch and thus a lot of bugs are to be expected. Successful tests have only be done with Outlook 2003 and there are reports that it does not work at all with OL 2000. The general design of the plugin has basically been carried over from the G-DATA plugin; however we are currently investigating whether it will be possible to make use of custom forms for better integration and to avoid some of the more ugly hacks. ftp://ftp.g10code.com/g10code/gpgol/gpgol-0.9.0.zip (274k) ftp://ftp.g10code.com/g10code/gpgol/gpgol-0.9.0.zip.sig Noteworthy changes for version 0.9.0 (2005-09-04) ================================================= * Major rewrite. Renamed the package to GPGol. Note, that there used to be intermediate versions unter the name OutlGPG * The package as been renamed to GPGol and consist of only one DLL named "gpgol.dll". Installation of gpgme.dll and libgpg-error.dll is required. * It may by now only be build using the Mingw32 toolchain. * GPGol now uses the standard GPGME. Installation ============ To install this plugin, copy it to some directory (e.g. where gpg lives), make sure that the libgpg-error.dll and gpgme.dll are available in a directory where Windows searches for DLLs (e.g. c:\winnt\system32), stop Outlook, run the command "regsvr32 outlgpg.dll" and start Outlook. You should then find a new tab named "GnuPG" in Outlook's option menu. Note: For building in src/ you need to throw an original mapi32.dll into this directory. This is due to a bug in the binutils: ld is not able to properly read a DEF file but will happily use the same information from an actual DLL. The problem is that symbols like HrSetOneProp@8 are actually written without the "@8" into the import table when used with a DEF file and generated import lib. Needs more debugging - any BFD cracks who can lend me a helping hand? (wk). Bug reporting: First click on the logo on the GnuPG options tab to check whether a newer version has been released - try this first. If this does not help, check out the mailing lists and also the bug archive at http://bugs.gnupg.org (use username and password "guest", select "query" and there category "gpgol") if you did not found any information there please send a report, including all relevant version numbers to the address given at the top of this AUTHORS file. Subversion access ================= The code is also available in a Subversion repository: svn co svn://cvs.gnupg.org/gpgol/trunk gpgol An online version is also available: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/?root=GPGol Failure and success reports are greatly appreciated. Salam-Shalom, Werner -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org Join the Fellowship and protect your Freedom! http://www.fsfe.org From wk at gnupg.org Sun Sep 4 19:29:06 2005 From: wk at gnupg.org (Werner Koch) Date: Sun Sep 4 19:31:23 2005 Subject: GPGol released In-Reply-To: <8764thawju.fsf@wheatstone.g10code.de> (Werner Koch's message of "Sun, 04 Sep 2005 13:42:45 +0200") References: <8764thawju.fsf@wheatstone.g10code.de> Message-ID: <878xycagil.fsf@wheatstone.g10code.de> On Sun, 04 Sep 2005 13:42:45 +0200, Werner Koch said: > directory where Windows searches for DLLs (e.g. c:\winnt\system32), > stop Outlook, run the command "regsvr32 outlgpg.dll" and start Small bug: Run regsvr32 gpgol.dll and not outlgpg.dll (which was the old name of the DLL). Shalom-Salam, Werner From pgut001 at cs.auckland.ac.nz Mon Sep 5 05:07:22 2005 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon Sep 5 06:04:38 2005 Subject: OpenPGG Card In-Reply-To: <85000712c0e502626e38ba79992949d3@www.pythagoras.no-ip.org> Message-ID: Benjamin Donnachie writes: >I saw that... Perhaps we should "fork" GPG and work on a PKCS#11 compliant >version... I'm fairly new to smartcards, but I have a fair bit of other >programming experience... I'd already offered the use of my PKCS #11 interface code from cryptlib for GPG use some time ago. This should do everything you need and has had years of tuning to work with all the bugs in various PKCS #11 drivers, it's vastly easier than going through the entire learning curve yourself. Peter. From alon.barlev at gmail.com Mon Sep 5 14:16:37 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon Sep 5 13:16:12 2005 Subject: OpenPGP Card In-Reply-To: Message-ID: >I'd already offered the use of my PKCS #11 interface code from cryptlib for GPG use some time ago. This > should do everything you need and has had years of tuning to work with all the bugs in various PKCS #11 > drivers, it's vastly easier than going through the entire learning curve yourself. Nice! The conclusion of my discussion with people here is that the need of using PKCS#11 for accessing various smartcards is not clear. I've tried to highlight the advantages of using standard software API to access external devices, but I've failed. Best Regards, Alon Bar-Lev. From pgut001 at cs.auckland.ac.nz Mon Sep 5 15:23:51 2005 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon Sep 5 15:23:54 2005 Subject: OpenPGP Card In-Reply-To: Message-ID: "Alon Bar-Lev" writes: >The conclusion of my discussion with people here is that the need of using >PKCS#11 for accessing various smartcards is not clear. I've tried to >highlight the advantages of using standard software API to access external >devices, but I've failed. Users of crypto tokens tend to fall into two classes, hobbyists/enthusiasts (who don't mind hacking their own glue code, so PKCS #11 isn't too important), and commercial/business users (who really need PKCS #11 but who probably wouldn't use GPG). The result is, as you've found, something of a lack of a market for PKCS #11 combined with GPG. Peter. From wk at gnupg.org Mon Sep 5 16:26:21 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 5 16:31:26 2005 Subject: OpenPGG Card In-Reply-To: (Peter Gutmann's message of "Mon, 05 Sep 2005 15:07:22 +1200") References: Message-ID: <87d5nn7fqq.fsf@wheatstone.g10code.de> On Mon, 05 Sep 2005 15:07:22 +1200, Peter Gutmann said: > I'd already offered the use of my PKCS #11 interface code from cryptlib for > GPG use some time ago. This should do everything you need and has had years Thanks. That would indeed help to write a pkcs#11 implementation to connect Mozilla et al with gpg-agent/scdaemon. Regarding use of pkcs#11 below scdaemon: This might be possible by writing an app-p11 module. However, I still doubt that it makes much sense. Tweaking app-p15 for the existing cards seems to be a cleaner way to me. BTW, I just committed support for T=0 cards, tested with the Beglian eID card. Shalom-Salam, Werner From wk at gnupg.org Mon Sep 5 16:43:40 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 5 16:46:21 2005 Subject: OpenPGP Card In-Reply-To: (Peter Gutmann's message of "Tue, 06 Sep 2005 01:23:51 +1200") References: Message-ID: <87zmqr60df.fsf@wheatstone.g10code.de> On Tue, 06 Sep 2005 01:23:51 +1200, Peter Gutmann said: > and commercial/business users (who really need PKCS #11 but who probably > wouldn't use GPG). The result is, as you've found, something of a lack of a I won't agree to this because there is at least one large company in Germany using Smartcards along with gpgsm. Salam-Shalom, Werner From zvrba at globalnet.hr Mon Sep 5 16:38:05 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Mon Sep 5 17:17:40 2005 Subject: OpenPGG Card In-Reply-To: References: Message-ID: <431C584D.7020506@globalnet.hr> Peter Gutmann wrote: > > I'd already offered the use of my PKCS #11 interface code from cryptlib for > GPG use some time ago. This should do everything you need and has had years > of tuning to work with all the bugs in various PKCS #11 drivers, it's vastly > easier than going through the entire learning curve yourself. > That's correct, it was my proposal in question. The problem is that, under Linux, I couldn't find a smart-card + PKCS#11 combination that works correctly enough (out of the box) to be usable with cryptlib. GPG needs at three different keys and static data storage. I have a patch emulating static data storage, enabling the use of pre-generated keys. I don't remember exactly all the details, but I did disregard cryptlib for some reason (not because of its quality which is superb, but because of the state of.. smart-card and PKCS#11 issues on Linux). For interested parties in this thread: OpenPGP Java card applet (almost finished): http://www.core-dump.com.hr/index.pl?node_id=421 Patch that enables the use of any smart-card with GnuPG. It allows the use of cards with pregenerated keys and uses an auxiliray file to feed metadata into GnuPG (I'm assuming a read-only token). Signing works correctly. 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 There is a g10/p11howto.txt describing how to use it. I've given up on maintaining it because of Werner's attitude towards PKCS#11. If someone else wants to maintain it - be welcome. I will provide you some help if neccessary. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050905/c0700e81/signature.pgp From alon.barlev at gmail.com Mon Sep 5 18:27:17 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon Sep 5 17:27:05 2005 Subject: OpenPGP Card In-Reply-To: Message-ID: >>The conclusion of my discussion with people here is that the need of >>using >>PKCS#11 for accessing various smartcards is not clear. I've tried to >>highlight the advantages of using standard software API to access >>external devices, but I've failed. >Users of crypto tokens tend to fall into two classes, hobbyists/enthusiasts (who don't mind hacking their > own glue code, so PKCS #11 isn't too important), and commercial/business users (who really need > PKCS #11 but who probably wouldn't use GPG). The result is, as you've found, something of a lack > of a market for PKCS #11 combined with GPG. I agree... But I was still amazed... If you read the PKCS#11 corresponding you will notice that there is a remote possibility to agree the usage of PKCS#11 in a way that gpg will be the provider... So that other applications can use gpg keys... This was really strange. The whole idea is to separate between application logic (gpg) and device access (Smartcards, HSM)... Best Regards, Alon Bar-Lev. From alon.barlev at gmail.com Mon Sep 5 18:38:20 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon Sep 5 17:38:13 2005 Subject: OpenPGP Card In-Reply-To: <431C584D.7020506@globalnet.hr> Message-ID: Hello, >That's correct, it was my proposal in question. The problem is that, under Linux, I couldn't find a smart-card + PKCS#11 > combination that works correctly enough (out of the box) to be usable with cryptlib. I use Athena smartcard www.athena-scs.com which works perfectly in term of Linux and PKCS#11. I enjoy using it with Java JCE, Mozilla, Tunderbird, PAM_PKCS11, I've encrypted my disk using aes-loop and then required gpg to support PKCS#11... And here we are... > Patch that enables the use of any smart-card with GnuPG. It allows the use of cards with pregenerated keys and uses an auxiliray file to > feed metadata into GnuPG (I'm assuming a read-only token). Signing works correctly. > 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 > There is a g10/p11howto.txt describing how to use it. I've given up on maintaining it because of Werner's attitude towards PKCS#11. > If someone else wants to maintain it - be welcome. I will provide you some help if neccessary. This is great work! But the work needs to be moved into gpg-agent... :( I would have help merging it if I knew that there is a chance to merge it into to gpg source. Best Regards, Alon Bar-Lev. From pgut001 at cs.auckland.ac.nz Mon Sep 5 17:57:51 2005 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon Sep 5 17:57:50 2005 Subject: OpenPGP Card In-Reply-To: <87zmqr60df.fsf@wheatstone.g10code.de> Message-ID: Werner Koch writes: >On Tue, 06 Sep 2005 01:23:51 +1200, Peter Gutmann said: >> and commercial/business users (who really need PKCS #11 but who probably >> wouldn't use GPG). The result is, as you've found, something of a lack of a > >I won't agree to this because there is at least one large company in Germany >using Smartcards along with gpgsm. Well OK, so there's always exceptions, but I don't think there's enough to drive significant demand for this - all the commercial users I've seen who want smart cards/PKCS #11/whatever want to use it with standard commercial software and, you know, that stuff with the 'X' and some digits in it :-). Peter. From pgut001 at cs.auckland.ac.nz Mon Sep 5 18:08:02 2005 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon Sep 5 18:07:57 2005 Subject: OpenPGG Card In-Reply-To: <431C584D.7020506@globalnet.hr> Message-ID: Zeljko Vrba writes: >Peter Gutmann wrote: >> I'd already offered the use of my PKCS #11 interface code from cryptlib for >> GPG use some time ago. This should do everything you need and has had years >> of tuning to work with all the bugs in various PKCS #11 drivers, it's vastly >> easier than going through the entire learning curve yourself. > >That's correct, it was my proposal in question. The problem is that, under >Linux, I couldn't find a smart-card + PKCS#11 combination that works >correctly enough (out of the box) to be usable with cryptlib. I think the problem is more a generalisation of that, it's "under Linux, I couldn't find a smart-card + PKCS#11 combination that works correctly". I've heard of (from memory) four PKCS #11-for-Linux projects by commercial vendors that either ended up as pre-alpha quality releases/abandonware or were shelved beause the vendor couldn't find a business model for them (this was a few years ago, it may be better now). The one PKCS #11-under-Linux driver that I know of that was completed, the nCipher one, works fine with cryptlib. Everything else is Windows only... actually Eracom have Solaris and some other OS support (PHUX?), and there's some OEM'd Cryptoswift supported under Solaris. (Which other Linux PKCS #11 drivers are there?). Peter. From pgut001 at cs.auckland.ac.nz Mon Sep 5 18:23:38 2005 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon Sep 5 18:23:35 2005 Subject: OpenPGP Card In-Reply-To: Message-ID: "Alon Bar-Lev" writes: >I use Athena smartcard www.athena-scs.com which works perfectly in term of >Linux and PKCS#11. I enjoy using it with Java JCE, Mozilla, Tunderbird, >PAM_PKCS11, I've encrypted my disk using aes-loop and then required gpg to >support PKCS#11... And here we are... Oh, that's the old Aladdin stuff. Well, they've certainly come a *long* way since I last looked at them - in the 1999-2000 time frame they had the worst PKCS #11 driver I've ever seen, and their "support" consisted of telling you to buy more copies of their $700 SDK to see whether they'd fixed any of the bugs in the version you already had. I still have some of their hardware lying around as a paperweight somewhere. (Disclaimer: I have no idea what it's like now (it certainly sounds a lot better than it used to be), I'm just saying that at one point it was really bad). Peter. From pgut001 at cs.auckland.ac.nz Mon Sep 5 18:30:24 2005 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon Sep 5 18:30:21 2005 Subject: OpenPGP Card Message-ID: I wrote: >Oh, that's the old Aladdin stuff. Well, they've certainly come a *long* way >since I last looked at them - in the 1999-2000 time frame they had the worst >PKCS #11 driver I've ever seen, and their "support" consisted of telling you >to buy more copies of their $700 SDK to see whether they'd fixed any of the >bugs in the version you already had. Argh, sorry, wrong driver, it's the ActivCard drivers (and support) that were that bad, not Aladdin. Aladdin (and by extension ASECard and Athena Cards, and eTokens as well) work just fine. Just to repeat that: Nothing wrong with Aladdin's PKCS #11. Peter. From zvrba at globalnet.hr Mon Sep 5 18:57:54 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Mon Sep 5 18:57:37 2005 Subject: OpenPGP Card In-Reply-To: References: Message-ID: <431C7912.5080407@globalnet.hr> Alon Bar-Lev wrote: > > I use Athena smartcard www.athena-scs.com which works perfectly in term of > Linux and PKCS#11. I enjoy using it with Java JCE, Mozilla, Tunderbird, > PAM_PKCS11, I've encrypted my disk using aes-loop and then required gpg to > support PKCS#11... And here we are... > Great! When I was developing my patch, I had only Cryptoflex 8k cards available (still have a few of them, but not at my current geographical location :)). > > This is great work! > Thanks. > > But the work needs to be moved into gpg-agent... :( > Probably not too difficult, but still time-consuming to understand the existing code.. and that would probably be wasted time, unless you want to make a life-time commitment to keep the patch in pace with gpg development. > > I would have help merging it if I knew that there is a chance to merge it > into to gpg source. > Judging by the discussion on this list.. it seems that there is no chance for that :( Look in the archives of gnupg lists, IIRC it is around November 2004, for threads started by me. I was quickly discouraged by Werner and nowhere as persistent as you in trying to persuade him into the usefulness of PKCS#11. IMHO, PKCS#11 has succeeded where ISO7816 has failed: providing a (relatively) simple way to interface with many smart-card implementations, many of which aren't ISO7816-compliant above level 3 - they even don't support basic interindustry commands, but provide their own proprietary and undocumented command set. Personally, I think that applications not supporting PKCS#11 and/or MS CAPI will become extinct much before than non-compliant ISO7816 cards. These two have become the de-facto industry standards. I'm no fortune teller, so time will prove me right or wrong :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050905/55037bf5/signature-0001.pgp From alon.barlev at gmail.com Mon Sep 5 20:19:45 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon Sep 5 19:19:00 2005 Subject: OpenPGP Card In-Reply-To: <431C7912.5080407@globalnet.hr> Message-ID: Zeljko wrote: >> >> I would have help merging it if I knew that there is a chance to merge >> it into to gpg source. >> > Judging by the discussion on this list.. it seems that there is no chance for that :( > Look in the archives of gnupg lists, IIRC it is around November 2004, for threads started by me. I was quickly discouraged by Werner and > nowhere as persistent as you in trying to persuade him into the usefulness of PKCS#11. Yes... I agree... I gave up... Tried to help... And failed. > IMHO, PKCS#11 has succeeded where ISO7816 has failed: providing a > (relatively) simple way to interface with many smart-card implementations, many of which aren't ISO7816-compliant above level 3 - they even don't > support basic interindustry commands, but provide their own proprietary and undocumented command set. I agree! > Personally, I think that applications not supporting PKCS#11 and/or MS CAPI will become extinct much before than non-compliant ISO7816 cards. > These two have become the de-facto industry standards. I'm no fortune teller, so time will prove me right or wrong :) This is exactly my claim... I've tried to introduce this argument to Werner... But without any success... I was out of new arguments when I gave up... I think that an open source project that does not support software interaction standards will be replaced by a different solution when the time comes. Best Regards, Alon Bar-Lev. From alon.barlev at gmail.com Mon Sep 5 20:19:45 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon Sep 5 19:19:16 2005 Subject: OpenPGP Card In-Reply-To: Message-ID: Peter wrote: >>Oh, that's the old Aladdin stuff. Well, they've certainly come a >>*long* way since I last looked at them - in the 1999-2000 time frame >>they had the worst PKCS #11 driver I've ever seen, and their "support" >>consisted of telling you to buy more copies of their $700 SDK to see >>whether they'd fixed any of the bugs in the version you already had. > Argh, sorry, wrong driver, it's the ActivCard drivers (and support) that were that bad, not Aladdin. > Aladdin (and by extension ASECard and Athena Cards, and eTokens as well) work just fine. Just to > repeat that: Nothing wrong with Aladdin's PKCS #11. I am glad you corrected your-self... ActivCard did not implement a good CSP/PKCS#11 on Windows too... :( Athena and Aladdin produce good support software... I am using their cards and I am very happy... Athena support Linux well... And even share the same cards between Windows CSP/PKCS#11 and Linux PKCS#11!!! Best Regards, Alon Bar-Lev From alon.barlev at gmail.com Mon Sep 5 20:19:45 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon Sep 5 19:19:46 2005 Subject: OpenPGP Card In-Reply-To: Message-ID: >> I won't agree to this because there is at least one large company in >> Germany using Smartcards along with gpgsm. > Well OK, so there's always exceptions, but I don't think there's enough to drive significant > demand for this - all the commercial users I've seen who want smart cards/PKCS #11/whatever want > to use it with standard commercial software and, you know, that stuff with the 'X' and some > digits in it :-). I think that many enterprises are looking first for open source solutions... If they find one that is suitable, they don't buy commercial product. The problem is that the open source community does not always understand which standard to support, and many, like gpg, inventing their own... Best Regards, Alon Bar-Lev. From zvrba at globalnet.hr Mon Sep 5 19:36:07 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Mon Sep 5 19:35:43 2005 Subject: OpenPGP Card In-Reply-To: References: Message-ID: <431C8207.7080004@globalnet.hr> Alon Bar-Lev wrote: > Zeljko wrote: > >>IMHO, PKCS#11 has succeeded where ISO7816 has failed: providing a >>(relatively) simple way to interface with many smart-card implementations, > And I've forgot to mention one thing that may be important to some people: PKCS#11 is not limited to smart-cards. If GPG were to support it, it could be used with top-grade crypto modules (providing physical security and self-destruct on tampering) such as Thales WebSentry or nCipher. And for these things there is *no* universal standard except for PKCS#11 and MS CAPI. From experience I know that Thales was delivering RG732 crypto modules with their own development kit, and they've switched to PKCS#11 + MS CAPI in their new products (i.e. WebSentry). Yes, these devices are expensive for individuals. But if company already does own (for some) reason one of these, maybe they would also like to use it for e.g. storing a company "master key" that signs employees' keys. That's just one use-case example. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050905/1a15f387/signature.pgp From pgut001 at cs.auckland.ac.nz Mon Sep 5 20:10:40 2005 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon Sep 5 20:10:34 2005 Subject: OpenPGP Card In-Reply-To: <431C8207.7080004@globalnet.hr> Message-ID: Zeljko Vrba writes: >Yes, these devices are expensive for individuals. Although they're less expensive on ebay :-). Keep an eye on that long enough and you'll find almost anything turning up, for example there's almost always some Spyrus Lynks cards on sale by someone. Some of the stuff even has previous CA's keys still in the HW. >PKCS#11 is not limited to smart-cards. Yup, and that's an important point. If you want big-iron style crypto HW support, your choice is either PKCS #11, CryptoAPI, or a per-hardware-device custom API. I know which one I'd want... Peter. From alon.barlev at gmail.com Mon Sep 5 21:32:40 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon Sep 5 20:32:07 2005 Subject: OpenPGP Card In-Reply-To: Message-ID: Peter wrote: > Zeljko Vrba writes: >> Yes, these devices are expensive for individuals. > Although they're less expensive on ebay :-). Keep an eye on that long enough and you'll find almost > anything turning up, for example there's almost always some Spyrus Lynks cards on sale by someone. > Some of the stuff even has previous CA's keys still in the HW. >> PKCS#11 is not limited to smart-cards. > Yup, and that's an important point. If you want big-iron style crypto HW support, your choice is > either PKCS #11, CryptoAPI, or a per-hardware-device custom API. I know which one I'd want... I agree... So if we all understand the need of PKCS#11 in order to access cryptographic tokens, what I don't understand is how come people choose to develop low-level applications in order to work with specific devices? Best Regards, Alon Bar-Lev. From zvrba at globalnet.hr Mon Sep 5 21:03:49 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Mon Sep 5 21:03:22 2005 Subject: OpenPGP Card In-Reply-To: References: Message-ID: <431C9695.9060904@globalnet.hr> Alon Bar-Lev wrote: > > I agree... So if we all understand the need of PKCS#11 in order to access > cryptographic tokens, what I don't understand is how come people choose to > develop low-level applications in order to work with specific devices? > Neither do I understand that. Werner didn't give a single plausible argument except possibly of license incompatibility. But in my understanding, just incorporating PKCS#11 support into GnuPG would NOT cause license incompatibility. It would happen at run-time if the user chooses to load GPL-incompatible binary PKCS#11 driver (which most of them are). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050905/2fbaf03c/signature.pgp From alon.barlev at gmail.com Mon Sep 5 22:14:41 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon Sep 5 21:14:00 2005 Subject: OpenPGP Card In-Reply-To: <431C9695.9060904@globalnet.hr> Message-ID: Zeljko Vrba wrote: > Alon Bar-Lev wrote: >> >> I agree... So if we all understand the need of PKCS#11 in order to >> access cryptographic tokens, what I don't understand is how come >> people choose to develop low-level applications in order to work with specific devices? >> > Neither do I understand that. Werner didn't give a single plausible argument except possibly of license incompatibility. But in my understanding, > just incorporating PKCS#11 support into GnuPG would NOT cause license incompatibility. It would happen at run-time if the user chooses to > load GPL-incompatible binary PKCS#11 driver (which most of them are). Right... This argument was given to me also... But I could not find any justification for it... Let's say you use GPLed licensed program on windows... It loads kernel32.dll, right? Since your GPLed program does not contain any other licensed code it is still GPLed... The same goes with GPLed licensed program that loads PKCS#11 module... I think it is the same as gpg works with vendor's X card... The card runs an operating system that is not GPLed... And yet... gpg is GPL... Moreover, I've found that opensc and PAM PKCS11 are LGPL and that openCryptoki (http://sourceforge.net/projects/opencryptoki) is GPL. So... I think licensing should not be an issue... Best Regards, Alon Bar-Lev. From alon.barlev at gmail.com Mon Sep 5 22:43:33 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon Sep 5 21:43:02 2005 Subject: OpenPGP Card In-Reply-To: <20050905193309.GC3205@straylight.m.ringlet.net> Message-ID: Peter Pentchev wrote: > Hate to jump into this discussion, but isn't this *exactly* why Werner always keeps mentioning *shared* libraries? :) Why hate? Can you please elaborate? I don' t understand what you mean... Best Regards, Alon Bar-Lev. From broonie at sirena.org.uk Mon Sep 5 21:54:10 2005 From: broonie at sirena.org.uk (Mark Brown) Date: Mon Sep 5 23:57:02 2005 Subject: OpenPGP Card In-Reply-To: References: <431C9695.9060904@globalnet.hr> Message-ID: <20050905195409.GA4956@sirena.org.uk> On Mon, Sep 05, 2005 at 10:14:41PM +0200, Alon Bar-Lev wrote: > Let's say you use GPLed licensed program on windows... It loads > kernel32.dll, right? > Since your GPLed program does not contain any other licensed code it is > still GPLed... Note that the GPL has a specific exception in it for libraries like kernel32.dll that are shipped as part of the operating system. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From alon.barlev at gmail.com Tue Sep 6 01:16:00 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue Sep 6 00:15:14 2005 Subject: OpenPGP Card In-Reply-To: Message-ID: Joe Smith wrote: > *PKCS#11 has nothing at all to do with smartcards.* The fact that many propretary card drivers export a PKCS #11 interface > is mearly coincedence. PKCS#11 and Microsoft cryptographic providers are the two APIs available for accessing cryptographic tokens. Every application that wishes to use services of vendor in depended cryptographic tokens uses one of these APIs. So vendors that developing smartcard provide these interfaces so their card will be usable. Enterprises (which are the larger clients) will not but a smartcard that does not support PKCS#11. > One of the larger reasons why Werner is probably reluctant to support > PKCS#11 in GPG is that X509 (which pkcs#11 is almost always used with) does not interface well with OpenPGP. It makes beteter sense to > have a separate X509 key, rather than use your key for both X509 and OpenPGP. For example, your CA can revoke your key leaving you > with one key that is invalid X.509, but valid OpenPGP? Yuck! I think you got revocation wrong... Revocation is letting OTHERS know that a key should not be trusted... There is nothing wrong in leaving the private key in the smartcard. Regardless this point PKCS#11 token can be organized that the same X.509 and PGP certificates will refer to the same private key, so if that private key is deleted both certificate will be unusable. > Werner designed the OpenPGP Card such that the interface works well with OpenPGP. OpenPGP cards are intended to be used for > authentication and OpenPGP only. They are not designed for things such as SSL, SSH, TLS, S/MIME , or any other cryptographic purpose. > It is important to ensure that people do not confuse X.509 and OpenPGP, but implementing PKCS#11 in gpg may blur things too much. But each user should have one smartcard... It is not logical to force user to keep several cards in his wallet in order to use several applications. One smartcard can be used to have tree types of identities: Authentication, Signature (Email and data), Decryption (Email and data). There is no reason to divide these into several physical containers. Users will simply select a different software which can access the same card as other software... Application that forces users to use a specific exclusive card will slowly vanish. > Besides it is hard enough to support just one card, imagine the problems that could arise if people started using cards with broken PKCS#11 > drivers, and asssumed the problem was in gpg. But this is exactly the point! You should not develop low-level code to access each card's processor in order to add the ability to work with smartcards, resulting in N separate implementations. You can benefit from the PKCS#11 high-level API in order to access cryptographic tokens (Smartcards, HSM, software). PKCS#11 is a standard that most vendors support, I can agree that if vendor did not implement the standard correctly, its token will not work with applications. For example, Mozilla Firefox will not work with some of the smartcards out there... And I have no claims to Mozilla, they have done a great job! Best Regards, Alon Bar-Lev. From pgut001 at cs.auckland.ac.nz Tue Sep 6 05:14:56 2005 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue Sep 6 05:15:00 2005 Subject: OpenPGP Card In-Reply-To: <20050905204407.GA7834@tofu.mamane.lu> Message-ID: Lionel Elie Mamane writes: >On Mon, Sep 05, 2005 at 10:14:41PM +0200, Alon Bar-Lev wrote: >> Since your GPLed program does not contain any other licensed code it is >> still GPLed... >> The same goes with GPLed licensed program that loads PKCS#11 >> module... > >Not unless that PKCS#11 module "is normally distributed with the major >components of the operating system". (Assuming here that the PKCS#11 module >would is a library that GnuPG would be dlopen.) PKCS #11 is a device driver without which it's impossible to use critical (to the application) hardware. If you take this interpretation then GPG already violates it because it ends up using all manner of components (RAID drivers, ATI/nVidia video drivers, PC/SC drivers, etc) that aren't distributed as part of the OS. In fact if you wanted to go reductio ad absurdum even kernel32.dll is excluded because the hotfixes that are constantly applied to it aren't "normally distributed with the system components" - they're a special download. On the other hand using a particular interpretation of the GPL in order to make it impossible for GPG to be able to support widespread smart cards and crypto hardware is a great example of cutting off your nose to spite your face. I guess you can always tell people who want to use crypto devices with PGP to go with the commercial PGP instead. Or cryptlib :-). Peter. From lionel at mamane.lu Tue Sep 6 08:16:09 2005 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Tue Sep 6 08:16:15 2005 Subject: OpenPGP Card In-Reply-To: References: <20050905204407.GA7834@tofu.mamane.lu> Message-ID: <20050906061609.GA28526@tofu.mamane.lu> On Tue, Sep 06, 2005 at 03:14:56PM +1200, Peter Gutmann wrote: > Lionel Elie Mamane writes: >>On Mon, Sep 05, 2005 at 10:14:41PM +0200, Alon Bar-Lev wrote: >>> Since your GPLed program does not contain any other licensed code it is >>> still GPLed... >>> The same goes with GPLed licensed program that loads PKCS#11 >>> module... >>Not unless that PKCS#11 module "is normally distributed with the major >>components of the operating system". (Assuming here that the PKCS#11 module >>would is a library that GnuPG would be dlopen.) > PKCS #11 is a device driver without which it's impossible to use > critical (to the application) hardware. If you take this > interpretation then GPG already violates it because it ends up using > all manner of components (RAID drivers, ATI/nVidia video drivers, > PC/SC drivers, etc) that aren't distributed as part of the OS. GnuPG doesn't *link* to RAID drivers or video drivers. They don't end up "running linked together in a shared address space". They communicate over syscalls or sockets; mechanisms that are well-known as to be "GPL-safe" (as long as the coupling between them isn't too tight). See http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation . On the other hand, some people interpret the GPL in a way saying that if a library implements a "standard" ABI, then one can link GPL software to it. I think it is a good idea to stick to the copyright holder's interpretation. > In fact if you wanted to go reductio ad absurdum even kernel32.dll > is excluded because the hotfixes that are constantly applied to it > aren't "normally distributed with the system components" - they're a > special download. Do I have to answer that? > On the other hand using a particular interpretation of the GPL in > order to make it impossible for GPG to be able to support widespread > smart cards and crypto hardware is a great example of cutting off > your nose to spite your face. That's a choice for the copyright holder to make. -- Lionel From joerg at schmitz-linneweber.de Fri Sep 2 16:13:40 2005 From: joerg at schmitz-linneweber.de (Joerg Schmitz-Linneweber) Date: Tue Sep 6 11:52:28 2005 Subject: OpenPGP Card In-Reply-To: <43185009.6060206@gmail.com> References: <85000712c0e502626e38ba79992949d3@www.pythagoras.no-ip.org> <43185009.6060206@gmail.com> Message-ID: <200509021613.47029.joerg@schmitz-linneweber.de> Hi Alon! I would like to see support for PKCS#11 too but... (won't elaborate on this now ;-) Regarding the "open-ness" of OpenGPG: Why do you (and Benjamin) think its not open (enough)? The specs are there and you are free to implement "both sides" of the (smart) card. For me the specs allow(ed) it to try implementing OpenGPG on a IBM JavaCard (and it *would* be possible to have a JavaCard implement OpenGPG in parallel to PKCS#11...) Just my 2cts... Salut, J?rg -- gpg/pgp key # 0xd7fa4512 fingerprint 4e89 6967 9cb2 f548 a806 ?7e8b fcf4 2053 d7fa 4512 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050902/dd21d257/attachment.pgp From roam at ringlet.net Mon Sep 5 21:33:09 2005 From: roam at ringlet.net (Peter Pentchev) Date: Tue Sep 6 11:52:37 2005 Subject: OpenPGP Card In-Reply-To: References: <431C9695.9060904@globalnet.hr> Message-ID: <20050905193309.GC3205@straylight.m.ringlet.net> On Mon, Sep 05, 2005 at 10:14:41PM +0200, Alon Bar-Lev wrote: > Zeljko Vrba wrote: > > Alon Bar-Lev wrote: > >> > >> I agree... So if we all understand the need of PKCS#11 in order to > >> access cryptographic tokens, what I don't understand is how come > >> people choose to develop low-level applications in order to work with > specific devices? > >> > > Neither do I understand that. Werner didn't give a single plausible > argument except possibly of license incompatibility. But in my > understanding, > > just incorporating PKCS#11 support into GnuPG would NOT cause license > incompatibility. It would happen at run-time if the user chooses to > > load GPL-incompatible binary PKCS#11 driver (which most of them are). > > Right... This argument was given to me also... > But I could not find any justification for it... > Let's say you use GPLed licensed program on windows... It loads > kernel32.dll, right? > Since your GPLed program does not contain any other licensed code it is > still GPLed... > The same goes with GPLed licensed program that loads PKCS#11 module... Hate to jump into this discussion, but isn't this *exactly* why Werner always keeps mentioning *shared* libraries? :) G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20050905/0a0fe6cd/attachment.pgp From lionel at mamane.lu Mon Sep 5 22:44:07 2005 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Tue Sep 6 11:52:42 2005 Subject: OpenPGP Card In-Reply-To: References: <431C9695.9060904@globalnet.hr> Message-ID: <20050905204407.GA7834@tofu.mamane.lu> On Mon, Sep 05, 2005 at 10:14:41PM +0200, Alon Bar-Lev wrote: > Zeljko Vrba wrote: >> Neither do I understand that. Werner didn't give a single plausible >> argument except possibly of license incompatibility. But in my >> understanding, just incorporating PKCS#11 support into GnuPG would >> NOT cause license incompatibility. It would happen at run-time if >> the user chooses to load GPL-incompatible binary PKCS#11 driver >> (which most of them are). > Right... This argument was given to me also... > But I could not find any justification for it... > Let's say you use GPLed licensed program on windows... It loads > kernel32.dll, right? kernel32.dll falls under the following language in the GPL: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. > Since your GPLed program does not contain any other licensed code it is > still GPLed... > The same goes with GPLed licensed program that loads PKCS#11 > module... Not unless that PKCS#11 module "is normally distributed with the major components of the operating system". (Assuming here that the PKCS#11 module would is a library that GnuPG would be dlopen.) -- Lionel From kfitzner at excelcia.org Tue Sep 6 13:21:51 2005 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Tue Sep 6 14:26:38 2005 Subject: Keys listed twice when --keyring used - request to filter Message-ID: <431D7BCF.40104@excelcia.org> I have found that if the same keyring that is normally used by GnuPG is also specified on the command line with --keyring, then GnuPG will list the keys in it twice. While this isn't a bug per se, I am hoping I can convince the developers to implement some code that will filter out duplicate keyrings so that they are only ever shown once. The GPGME library has no command to return the name of the keyrings that GnuPG is using by default. So, it is difficult for a front-end (one that uses GPGME) to determine what the configured keyrings are. Thus, when a front-end allows the specification of extra keyring files, it is difficult to determine if this will cause duplicate keys to appear. This might all be listed under "end user beware", but I received enough bug reports of duplicate keys that for GPGee, I ended up implementing a hash table key filter to eliminate duplications. It should be fairly easy to maintain a list in GnuPG of keyrings that have already been processed, and to check against that list when processing of a new keyring is contemplated. Consider this my request that such filtering be implemented in GnuPG. Thanks, Kurt Fitzner From zvrba at globalnet.hr Tue Sep 6 15:56:22 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Tue Sep 6 15:55:49 2005 Subject: OpenPGP Card In-Reply-To: References: <431C7912.5080407__34242.7164003768$1125939585$gmane$org@globalnet.hr> Message-ID: <431DA006.6000807@globalnet.hr> Joe Smith wrote: > > For example, your CA can revoke your key leaving you with one key that > is invalid X.509, but valid OpenPGP? Yuck! > Using the X.509 cert and OpenPGP public key (having the same private key) could be useful in the following scenario: 1. You must periodically pay to your CA to renew your certificate 2. OpenPGP trust model isn't as 'strong' as X.509 (i.e. there aren't many trusted introducers) So, you pay ONCE to some CA to issue you short-lived, widely-trusted certificate. It will expire after a year or so, but.. you can continue to use your OpenPGP key as long as you deem it's OK. The point is that your _identity_ doesn't change when the X.509 cert expires. So, continuing to use the X.509 (expired) private key solves problem 1. Having X.509 cert in the first place, solves problem 2. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050906/1e5b0a68/signature.pgp From zvrba at globalnet.hr Tue Sep 6 16:04:28 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Tue Sep 6 16:04:05 2005 Subject: OpenPGP Card In-Reply-To: <20050906094219.GC2863@tofu.mamane.lu> References: <20050905231617.GC7834@tofu.mamane.lu> <20050906094219.GC2863@tofu.mamane.lu> Message-ID: <431DA1EC.9090907@globalnet.hr> 'Lionel Elie Mamane' wrote: > > I had understood that it was not a _protocol_ but a library API. HTTP > is a _protocol_ for data interchange over the network. I thought > PKCS#11 was a _library_ API and that you linked (dynamically at > run-time) a particular "implementation" of it (the card driver) into > your program to use it. If that's not the case, my previous messages > are void and meaningless. > PKCS#11 IS a library API. But really, how is API different from a protocol? Is the only difference linking in the same address space? Anyway, the "right" way, as I've understood Alon, is to make gpg use gpg-agent. They communicate via a well defined _protocol_ and are not _linked_ together. So actually, the PKCS#11 licensing issue can be solved by independently writing a BSD-licensed version of the gpg-agent. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050906/9b0f5831/signature.pgp From zvrba at globalnet.hr Tue Sep 6 16:17:07 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Tue Sep 6 16:16:37 2005 Subject: OpenPGP Card In-Reply-To: <431DA15C.1020205@gmail.com> References: <431C7912.5080407__34242.7164003768$1125939585$gmane$org@globalnet.hr> <431DA006.6000807@globalnet.hr> <431DA15C.1020205@gmail.com> Message-ID: <431DA4E3.3090802@globalnet.hr> Alphax wrote: > Zeljko Vrba wrote: > >>Joe Smith wrote: >> >> >>>For example, your CA can revoke your key leaving you with one key that >>>is invalid X.509, but valid OpenPGP? Yuck! >>> >> >>Using the X.509 cert and OpenPGP public key (having the same private >>key) could be useful in the following scenario: >> > > Is that even allowed?? > In what sense allowed? PKCS#11 know nothing about policies.. It just exposes a set of objects on the card (certificate, public and private keys and maybe some other data objects along with certificates). The application is free to do whatever it wants with these objects, given sufficient authentication to the card (PIN). Technically, there is nothing CA can do to prevent you to use your X.509 keys as OpenPGP keys. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050906/2990ac4f/signature.pgp From zvrba at globalnet.hr Tue Sep 6 16:26:05 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Tue Sep 6 16:25:42 2005 Subject: OpenPGP Card In-Reply-To: <431DA1EC.9090907@globalnet.hr> References: <20050905231617.GC7834@tofu.mamane.lu> <20050906094219.GC2863@tofu.mamane.lu> <431DA1EC.9090907@globalnet.hr> Message-ID: <431DA6FD.5030602@globalnet.hr> Zeljko Vrba wrote: > > PKCS#11 IS a library API. But really, how is API different from a > protocol? Is the only difference linking in the same address space? > BTW, I can imagine writing a version of ld.so (BSD licensed!) that will execute different shared libraries as separate processes, and will NOT link them in the same address space with the application in question (i.e. GnuPG). So the "procedure call" will call to a stub in the BSD licensed ld.so which will just "pass a message" to the real shared library and return a result code to the application. Thing like this would forever end this GPL madness about what is "derivative work". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050906/aacdce94/signature.pgp From lionel at mamane.lu Tue Sep 6 16:31:14 2005 From: lionel at mamane.lu ('Lionel Elie Mamane') Date: Tue Sep 6 16:31:40 2005 Subject: OpenPGP Card In-Reply-To: <431DA1EC.9090907@globalnet.hr> References: <20050905231617.GC7834@tofu.mamane.lu> <20050906094219.GC2863@tofu.mamane.lu> <431DA1EC.9090907@globalnet.hr> Message-ID: <20050906143114.GB9347@tofu.mamane.lu> On Tue, Sep 06, 2005 at 04:04:28PM +0200, Zeljko Vrba wrote: > 'Lionel Elie Mamane' wrote: >>I had understood that it was not a _protocol_ but a library API. HTTP >>is a _protocol_ for data interchange over the network. I thought >>PKCS#11 was a _library_ API and that you linked (dynamically at >>run-time) a particular "implementation" of it (the card driver) into >>your program to use it. If that's not the case, my previous messages >>are void and meaningless. > PKCS#11 IS a library API. But really, how is API different from a > protocol? Is the only difference linking in the same address space? The fact that they have to run in the same address space suggests that they exchange "complex data structures" and that the intercoupling (interdependency?) between them is quite tight. I suppose this is the FSF's reasoning. -- Lionel From lionel at mamane.lu Tue Sep 6 16:35:04 2005 From: lionel at mamane.lu ('Lionel Elie Mamane') Date: Tue Sep 6 16:35:15 2005 Subject: OpenPGP Card In-Reply-To: <431DA6FD.5030602@globalnet.hr> References: <20050905231617.GC7834@tofu.mamane.lu> <20050906094219.GC2863@tofu.mamane.lu> <431DA1EC.9090907@globalnet.hr> <431DA6FD.5030602@globalnet.hr> Message-ID: <20050906143504.GC9347@tofu.mamane.lu> On Tue, Sep 06, 2005 at 04:26:05PM +0200, Zeljko Vrba wrote: >> PKCS#11 IS a library API. But really, how is API different from a >> protocol? Is the only difference linking in the same address space? > BTW, I can imagine writing a version of ld.so (BSD licensed!) that > will execute different shared libraries as separate processes, Please do so. I'm curious how you will handle: 1) Pointers being passed By copying the whole address space back and forth at each call and return? "Morally" that's not running in separate address spaces! 2) A library that calls exec() or fork() or setuid() such a "process state changing" syscall. I don't think you can keep the semantics of all libraries in this way. > and will NOT link them in the same address space with the > application in question (i.e. GnuPG). > So the "procedure call" will call to a stub in the BSD licensed > ld.so which will just "pass a message" to the real shared library > and return a result code to the application. > Thing like this would forever end this GPL madness about what is > "derivative work". It would certainly be a fun legal challenge. I don't believe however, you would win it. But I'm not a lawyer, he. By all means, please follow through on this plan. It will be very fun to watch! -- Lionel From zvrba at globalnet.hr Tue Sep 6 16:52:55 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Tue Sep 6 16:52:28 2005 Subject: OpenPGP Card In-Reply-To: <20050906143504.GC9347@tofu.mamane.lu> References: <20050905231617.GC7834@tofu.mamane.lu> <20050906094219.GC2863@tofu.mamane.lu> <431DA1EC.9090907@globalnet.hr> <431DA6FD.5030602@globalnet.hr> <20050906143504.GC9347@tofu.mamane.lu> Message-ID: <431DAD47.5050907@globalnet.hr> 'Lionel Elie Mamane' wrote: > > Please do so. I'm curious how you will handle: > > 1) Pointers being passed > > By copying the whole address space back and forth at each call and > return? "Morally" that's not running in separate address spaces! > Make the programs share their _data_ segments, but NOT their _code_ segments. GPL is about _code_, not about the _data_ created and used by the code. The first pointer-sharing reference will trigger a fault which will be handled by the ld.so and it will create an appropriate data-sharing mapping. "Morally" I don't care, even in the case of copying. Technically, making the programs share their data segments is, IMHO, not a violation of GPL since no code is shared between the programs. But then again, I'm not a lawyer. I'm always interested in other opinions. > > 2) A library that calls exec() or fork() or setuid() such a > "process state changing" syscall. > > > I don't think you can keep the semantics of all libraries in this > way. > By providing the support for few such critical things within ld.so, so it can change the state of the 'right' process. I don't have all details worked-out, but none of them seem really unsurmountable. In the extreme case, nothing that couldn't be solved with little kernel-side work and support. > > It would certainly be a fun legal challenge. I don't believe however, > you would win it. But I'm not a lawyer, he. > Neither am I. > > By all means, please follow through on this plan. It will be very fun > to watch! > In what way "fun"? :) I don't have the time currently, sadly. But, the biggest journey begins with the first step, so I just might start to write some design paper in my spare time :) Either I'll be the first one to do it, or someone will get ahead of me. In any case, Werner will run out of his only reasonable argument (IMHO) for not supporting PKCS#11 and users will (hopefully) profit ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050906/a38657a3/signature.pgp From kfitzner at excelcia.org Tue Sep 6 16:09:57 2005 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Tue Sep 6 17:30:55 2005 Subject: [Announce] GnuPG Explorer Extension (GPGee) version 1.2.0 released Message-ID: <431DA335.6020304@excelcia.org> Version 1.2.0 of GPGee has been released - head to the homepage at http://gpgee.excelcia.org to download it. New features include: - Support for creating signatures with more than one key at once. - Support for verifying multi-signed documents. - Automated new version checking (this was actually added in 1.1.3 but that version was unannounced) - Can automatically change the status of source files to read-only after they are signed. Useful for cases where a certain type of file's reader (MS Excel with spreadsheets is one) changes the file when it is opened even if it isn't edited. Since this would invalidate a signature, you can now have GPGee set the file read-only. In addition to that, there are a few bug fixes incorporated for good measure. For those that aren't familliar with GPGee, it is a Windows shell extension that adds GnuPG support to explorer's right-click menu. You can sign, sign+encrypt, encrypt, verify, and decrypt files right from within the Windows explorer. _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From alphasigmax at gmail.com Tue Sep 6 16:18:45 2005 From: alphasigmax at gmail.com (Alphax) Date: Tue Sep 6 18:39:00 2005 Subject: OpenPGP Card In-Reply-To: <431DA4E3.3090802@globalnet.hr> References: <431C7912.5080407__34242.7164003768$1125939585$gmane$org@globalnet.hr> <431DA006.6000807@globalnet.hr> <431DA15C.1020205@gmail.com> <431DA4E3.3090802@globalnet.hr> Message-ID: <431DA545.6030708@gmail.com> Zeljko Vrba wrote: > Alphax wrote: > >> Zeljko Vrba wrote: >> >>> Joe Smith wrote: >>> >>> >>>> For example, your CA can revoke your key leaving you with one key that >>>> is invalid X.509, but valid OpenPGP? Yuck! >>>> >>> >>> Using the X.509 cert and OpenPGP public key (having the same private >>> key) could be useful in the following scenario: >>> >> >> Is that even allowed?? >> > In what sense allowed? PKCS#11 know nothing about policies.. It just > exposes a set of objects on the card (certificate, public and private > keys and maybe some other data objects along with certificates). > It terms of using the same generic public/private keypair... how does that work? > The application is free to do whatever it wants with these objects, > given sufficient authentication to the card (PIN). Technically, there is > nothing CA can do to prevent you to use your X.509 keys as OpenPGP keys. I think I might have seen something like that with a Thawte Freemail root certificate or something... it wasn't pretty :( (eh, I think I just answered my own question, but I still don't "get it"...) -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 | X Against HTML email & vCards http://tinyurl.com/cc9up | / \ From lionel at mamane.lu Tue Sep 6 18:57:01 2005 From: lionel at mamane.lu ('Lionel Elie Mamane') Date: Tue Sep 6 18:57:08 2005 Subject: OpenPGP Card In-Reply-To: <431DAD47.5050907@globalnet.hr> References: <20050905231617.GC7834@tofu.mamane.lu> <20050906094219.GC2863@tofu.mamane.lu> <431DA1EC.9090907@globalnet.hr> <431DA6FD.5030602@globalnet.hr> <20050906143504.GC9347@tofu.mamane.lu> <431DAD47.5050907@globalnet.hr> Message-ID: <20050906165701.GB14872@tofu.mamane.lu> On Tue, Sep 06, 2005 at 04:52:55PM +0200, Zeljko Vrba wrote: > 'Lionel Elie Mamane' wrote: >>Please do so. I'm curious how you will handle: >> >> 1) Pointers being passed >> >> By copying the whole address space back and forth at each call and >> return? "Morally" that's not running in separate address spaces! > Make the programs share their _data_ segments, but NOT their _code_ > segments. GPL is about _code_, not about the _data_ created and used by > the code. The pointer may point to code. It can be a pointer to a function. For a callback, for example. > I don't have all details worked-out, but none of them seem really > unsurmountable. In the extreme case, nothing that couldn't be solved > with little kernel-side work and support. >> By all means, please follow through on this plan. It will be very fun >> to watch! > In what way "fun"? :) 1) Scientifically, see interesting problems tackled. 2) From a slightly more "Schadenfreude" perspective, watch the legal discussions and / or flamewars it will create. White papers flying around! Eben Moglen saying your mechanism doesn't circumvent the GPL, you disagreeing and arguing back, a new GPL revision coming out to address the "loophole" you have demonstrated (if it gets settled that it _is_ a loophole), etc. You saying that the revised GPL version doesn't count, because not derivative work and thus legally cannot enforce limitations. Fun to watch from the sidelines, cheering on, etc ;-) > In any case, Werner will run out of his only reasonable argument > (IMHO) for not supporting PKCS#11 and users will (hopefully) profit > ;) I find the following argument very reasonable: I have no interest in implementing PKCS#11 and nobody has stepped up to pay me to do it. He won't run out of *this* argument ;-) -- Lionel From lionel at mamane.lu Tue Sep 6 18:58:59 2005 From: lionel at mamane.lu ('Lionel Elie Mamane') Date: Tue Sep 6 18:59:23 2005 Subject: OpenPGP Card In-Reply-To: <431DAD47.5050907@globalnet.hr> References: <20050905231617.GC7834@tofu.mamane.lu> <20050906094219.GC2863@tofu.mamane.lu> <431DA1EC.9090907@globalnet.hr> <431DA6FD.5030602@globalnet.hr> <20050906143504.GC9347@tofu.mamane.lu> <431DAD47.5050907@globalnet.hr> Message-ID: <20050906165859.GC14872@tofu.mamane.lu> On Tue, Sep 06, 2005 at 04:52:55PM +0200, Zeljko Vrba wrote: > 'Lionel Elie Mamane' wrote: >> 1) Pointers being passed >> By copying the whole address space back and forth at each call and >> return? "Morally" that's not running in separate address spaces! > "Morally" I don't care, even in the case of copying. "Morally" is what a judge will look at. So it is the crux of the matter. -- Lionel From alon.barlev at gmail.com Tue Sep 6 20:12:53 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue Sep 6 19:12:20 2005 Subject: OpenPGP Card In-Reply-To: <20050906165701.GB14872@tofu.mamane.lu> Message-ID: 'Lionel Elie Mamane' wrote: > I find the following argument very reasonable: I have no interest in implementing PKCS#11 and nobody has stepped up to pay me to do it. When I started this discussion, I wanted to ask whether implementing a feature of gpg-agent to access PKCS#11 token is in the roadmap... I will gladly get the answer, yes... If someone will pay for the implementation... When you raise this issue... It seems that PKCS#11 is not implemented not because of licensing problems... But because if PKCS#11 will be implemented then there will be no work to be done for each specific card... Best Regards, Alon Bar-Lev. From zvrba at globalnet.hr Tue Sep 6 19:35:34 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Tue Sep 6 19:35:09 2005 Subject: OpenPGP Card In-Reply-To: References: Message-ID: <431DD366.1030405@globalnet.hr> Alon Bar-Lev wrote: > > When you raise this issue... It seems that PKCS#11 is not implemented not > because of licensing problems... But because if PKCS#11 will be implemented > then there will be no work to be done for each specific card... > But this strategy can, and will backfire :) From personal experience, companies are much more likely to choose a standard, interoperable solution (-> PKCS#11 -> X.509) than paying for a proprietary[1] solution. [1] In a sense that I can't describe exactly, OpenPGP card + GnuPG feels more proprietary than any closed-source smart card with PKCS#11 driver provided. The metric of 'proprietary-ness' would be in this case: the number of different smart-cards and interfaces supported by GnuPG. IMHO, the overall situation would get better for GnuPG and OpenPGP card if someone wrote a GPL-compatible PKCS#11 driver for the OpenPGP card. Then: a) OpenPGP cards can be used by other applications, not just GnuPG. (OK, they can be used in other applications even now, but noone sane will write card-specific code when they can use a high-level, universal API like PKCS#11). b) GnuPG switches to PKCS#11 and uses the GPL-compatible PKCS#11 for the OpenPGP card. It doesn't even have to dynamically link to it. As Alon did remark earlier, the general movement in the industry is towards multi-purpose smart-cards. OpenPGP card currently doesn't fall into this category. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050906/f851d8c4/signature.pgp From wk at gnupg.org Tue Sep 6 20:32:45 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 6 20:36:25 2005 Subject: Belgian eID card now supported by GPGSM Message-ID: <87oe76xd0y.fsf@wheatstone.g10code.de> Hi! After some trouble figuring out the correct PIN and fixing a Bug in the BCD mangling code, gpgsm from Subversion is now able to make use of the Belgian eID card. As time permits I will also add ssh support for this card and otehr pkcs#15 cards. Shalom-Salam, Werner From wk at gnupg.org Tue Sep 6 20:35:36 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 6 20:41:25 2005 Subject: OpenPGP Card In-Reply-To: <431DA1EC.9090907@globalnet.hr> (Zeljko Vrba's message of "Tue, 06 Sep 2005 16:04:28 +0200") References: <20050905231617.GC7834@tofu.mamane.lu> <20050906094219.GC2863@tofu.mamane.lu> <431DA1EC.9090907@globalnet.hr> Message-ID: <87k6huxcw7.fsf@wheatstone.g10code.de> On Tue, 06 Sep 2005 16:04:28 +0200, Zeljko Vrba said: > Anyway, the "right" way, as I've understood Alon, is to make gpg use > gpg-agent. They communicate via a well defined _protocol_ and are not > _linked_ together. Just for the record: Linking is only one indication that the whole is a derived work. There is no one to one relation ship and in particular even two separate processes might make up a derived work. Salam-Shalom, Werner From wk at gnupg.org Tue Sep 6 20:39:47 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 6 20:41:45 2005 Subject: OpenPGP Card In-Reply-To: <431DD366.1030405@globalnet.hr> (Zeljko Vrba's message of "Tue, 06 Sep 2005 19:35:34 +0200") References: <431DD366.1030405@globalnet.hr> Message-ID: <87d5nmxcp8.fsf@wheatstone.g10code.de> On Tue, 06 Sep 2005 19:35:34 +0200, Zeljko Vrba said: > As Alon did remark earlier, the general movement in the industry is > towards multi-purpose smart-cards. OpenPGP card currently doesn't fall > into this category. Not true. The OpenPGP card specification is a card application and you may put as many other applications on a card as you like and the EEPROM allows to. With 6k (and even less possible) it is actually a pretty small application. Shalom-Salam, Werner From alon.barlev at gmail.com Tue Sep 6 22:34:33 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue Sep 6 21:33:50 2005 Subject: OpenPGP Card In-Reply-To: <87d5nmxcp8.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: >> As Alon did remark earlier, the general movement in the industry is >> towards multi-purpose smart-cards. OpenPGP card currently doesn't fall >> into this category. > Not true. The OpenPGP card specification is a card application and you may put as many other applications on a card as you like and the > EEPROM allows to. With 6k (and even less possible) it is actually a pretty small application. Werner, you fail to understand the user requirements... The low level specifications of the cards is not important, programmers (except of you guys...) do not program low-level code in order to access devices. There is PKCS#11 which is high-level SOFTWARE API that is cross-platform, cross-device, and easy to use. This is the only specification to which I can write software and make sure that the user will be free to choose his hardware. Best Regards, Alon Bar-Lev. From wk at gnupg.org Wed Sep 7 08:57:24 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 7 09:01:38 2005 Subject: OpenPGP Card In-Reply-To: <431DA006.6000807@globalnet.hr> (Zeljko Vrba's message of "Tue, 06 Sep 2005 15:56:22 +0200") References: <431C7912.5080407__34242.7164003768$1125939585$gmane$org@globalnet.hr> <431DA006.6000807@globalnet.hr> Message-ID: <87zmqpwejv.fsf@wheatstone.g10code.de> On Tue, 06 Sep 2005 15:56:22 +0200, Zeljko Vrba said: > 2. OpenPGP trust model isn't as 'strong' as X.509 (i.e. there aren't > many trusted introducers) OpenPGP does not define any trust model. Instead it provides the mechanisms to implement any kind of trust modell on top of it. Salam-Shalom, Werner From alphasigmax at gmail.com Tue Sep 6 16:02:04 2005 From: alphasigmax at gmail.com (Alphax) Date: Wed Sep 7 13:04:34 2005 Subject: OpenPGP Card In-Reply-To: <431DA006.6000807@globalnet.hr> References: <431C7912.5080407__34242.7164003768$1125939585$gmane$org@globalnet.hr> <431DA006.6000807@globalnet.hr> Message-ID: <431DA15C.1020205@gmail.com> Zeljko Vrba wrote: > Joe Smith wrote: > >> >> For example, your CA can revoke your key leaving you with one key that >> is invalid X.509, but valid OpenPGP? Yuck! >> > Using the X.509 cert and OpenPGP public key (having the same private > key) could be useful in the following scenario: > Is that even allowed?? -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 | X Against HTML email & vCards http://tinyurl.com/cc9up | / \ From alphasigmax at gmail.com Wed Sep 7 12:32:56 2005 From: alphasigmax at gmail.com (Alphax) Date: Wed Sep 7 13:04:42 2005 Subject: OpenPGP Card In-Reply-To: <87d5nmxcp8.fsf@wheatstone.g10code.de> References: <431DD366.1030405@globalnet.hr> <87d5nmxcp8.fsf@wheatstone.g10code.de> Message-ID: <431EC1D8.7090809@gmail.com> Werner Koch wrote: > On Tue, 06 Sep 2005 19:35:34 +0200, Zeljko Vrba said: > > >>As Alon did remark earlier, the general movement in the industry is >>towards multi-purpose smart-cards. OpenPGP card currently doesn't fall >>into this category. > > > Not true. The OpenPGP card specification is a card application and > you may put as many other applications on a card as you like and the > EEPROM allows to. With 6k (and even less possible) it is actually a > pretty small application. > Um... slightly OT, but... 1. What's the standard size of the EEPROM on a smartcard suitable for OpenPGP? 2. What else could you fit on such a card? 3. Is it possible to have multiple things on a smartcard without them conflicting? Thanks, -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 | X Against HTML email & vCards http://tinyurl.com/cc9up | / \ From alex at bofh.net.pl Wed Sep 7 13:13:02 2005 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Wed Sep 7 13:14:09 2005 Subject: OpenPGP Card In-Reply-To: <431EC1D8.7090809@gmail.com> References: <431DD366.1030405@globalnet.hr> <87d5nmxcp8.fsf@wheatstone.g10code.de> <431EC1D8.7090809@gmail.com> Message-ID: <20050907111302.GG16716@syjon.fantastyka.net> On Wed, Sep 07, 2005 at 08:02:56PM +0930, Alphax wrote: > > Not true. The OpenPGP card specification is a card application and > > you may put as many other applications on a card as you like and the > > EEPROM allows to. With 6k (and even less possible) it is actually a > > pretty small application. > 3. Is it possible to have multiple things on a smartcard without them > conflicting? This is what Werner above said. An card application is a ,,partition'' on a card that is used for one purpose. I think you can access OpenPGP card from other computer app and use it as any other crypto smartcard, and it won't interfere with OpenPGP stuff on it. Alex PS> The whole discussion made me curious; I worked with smartcards extensively few years ago and was grossly disappointed with the stuff from the development side, but times they are a'changin... Where can I purchase a couple of OpenPGP cards and readers suitable for use with Debian? Preferably within the European Union. -- mors ab alto 0x46399138 From pgut001 at cs.auckland.ac.nz Wed Sep 7 13:31:51 2005 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Wed Sep 7 13:31:58 2005 Subject: OpenPGP Card In-Reply-To: <431DA15C.1020205@gmail.com> Message-ID: Alphax writes: >Zeljko Vrba wrote: >> Joe Smith wrote: >>> For example, your CA can revoke your key leaving you with one key that >>> is invalid X.509, but valid OpenPGP? Yuck! >>> >> Using the X.509 cert and OpenPGP public key (having the same private >> key) could be useful in the following scenario: > >Is that even allowed?? SPENGLER (emphatic): Don't cross PGP and X.509. VENKMAN: Why not? SPENGLER: Trust me. It will be bad. VENKMAN: What do you mean "bad?" SPENGLER: It's hard to explain, but try to imagine Werner appearing suddenly and beating you to death with a large copy of the GNU manifesto. VENKMAN (with military authority): That's it! No X.509. You guys are dangerous. Peter. From alphasigmax at gmail.com Wed Sep 7 13:39:05 2005 From: alphasigmax at gmail.com (Alphax) Date: Wed Sep 7 13:41:55 2005 Subject: OpenPGP Card In-Reply-To: References: Message-ID: <431ED159.90207@gmail.com> Peter Gutmann wrote: > Alphax writes: > >>Zeljko Vrba wrote: >> >>>Joe Smith wrote: >>> >>>>For example, your CA can revoke your key leaving you with one key that >>>>is invalid X.509, but valid OpenPGP? Yuck! >>>> >>> >>>Using the X.509 cert and OpenPGP public key (having the same private >>>key) could be useful in the following scenario: >> >>Is that even allowed?? > > > SPENGLER (emphatic): Don't cross PGP and X.509. > > VENKMAN: Why not? > > SPENGLER: Trust me. It will be bad. > > VENKMAN: What do you mean "bad?" > > SPENGLER: It's hard to explain, but try to imagine Werner appearing suddenly > and beating you to death with a large copy of the GNU manifesto. > > VENKMAN (with military authority): That's it! No X.509. You guys are > dangerous. > Wait, where's Richard Stallman in all of this? :) -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 | X Against HTML email & vCards http://tinyurl.com/cc9up | / \ From zvrba at globalnet.hr Wed Sep 7 14:58:50 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Wed Sep 7 14:58:30 2005 Subject: OpenPGP Card In-Reply-To: <431EC1D8.7090809@gmail.com> References: <431DD366.1030405@globalnet.hr> <87d5nmxcp8.fsf@wheatstone.g10code.de> <431EC1D8.7090809@gmail.com> Message-ID: <431EE40A.4090005@globalnet.hr> Alphax wrote: > > 1. What's the standard size of the EEPROM on a smartcard suitable for > OpenPGP? > YOu have cards ranging from 8k to 64k > > 2. What else could you fit on such a card? > debit/credit applications, X.509 PKI applications, data-containers, etc. > > 3. Is it possible to have multiple things on a smartcard without them > conflicting? > yes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050907/107f4d34/signature.pgp From zvrba at globalnet.hr Wed Sep 7 18:56:49 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Wed Sep 7 18:56:31 2005 Subject: OpenPGP Card In-Reply-To: References: Message-ID: <431F1BD1.2000208@globalnet.hr> Alon Bar-Lev wrote: > > But the work needs to be moved into gpg-agent... :( > You were referring to my PKCS#11 patch.. After studying the GPG architecture a bit, I think this needs to be moved into the scdaemon. gpg-agent actually does nothing with smart-cards - it uses scdaemon to do the work. Which is good, since the scdaemon's work is pretty simple; much simpler than that of gpg-agent's. The communication PROTOCOL (not API!) is publicly defined and is UNIX-socket based. I believe that writing a BSD-licensed PKCS#11 version of scdaemon is feasible. Then you use the 'p11-scdaemon' (let's call it that way) instead of the gpg's and voila! You have PKCS#11 support. Opinions? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050907/40e7f927/signature.pgp From alon.barlev at gmail.com Wed Sep 7 19:05:56 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed Sep 7 19:10:25 2005 Subject: OpenPGP Card In-Reply-To: <431F1BD1.2000208@globalnet.hr> References: <431F1BD1.2000208@globalnet.hr> Message-ID: <431F1DF4.7030302@gmail.com> Zeljko Vrba wrote: > Alon Bar-Lev wrote: > > > >> But the work needs to be moved into gpg-agent... :( >> > You were referring to my PKCS#11 patch.. After studying the GPG > architecture a bit, I think this needs to be moved into the scdaemon. > gpg-agent actually does nothing with smart-cards - it uses scdaemon to > do the work. > > Which is good, since the scdaemon's work is pretty simple; much simpler > than that of gpg-agent's. > > The communication PROTOCOL (not API!) is publicly defined and is > UNIX-socket based. I believe that writing a BSD-licensed PKCS#11 version > of scdaemon is feasible. Then you use the 'p11-scdaemon' (let's call it > that way) instead of the gpg's and voila! You have PKCS#11 support. > > Opinions? Great! Super! Amazing! If you can do it with a little effort I will glad to check and use it. But after looking at the source... it does not looked like a very simple interface... Best Regards, Alon Bar-Lev. From zvrba at globalnet.hr Wed Sep 7 19:21:58 2005 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Wed Sep 7 19:21:48 2005 Subject: OpenPGP Card In-Reply-To: <431F1DF4.7030302@gmail.com> References: <431F1BD1.2000208@globalnet.hr> <431F1DF4.7030302@gmail.com> Message-ID: <431F21B6.7060602@globalnet.hr> Alon Bar-Lev wrote: > > Great! Super! Amazing! > If you can do it with a little effort I will glad to check and use it. > Not so little. I don't have any card or PKCS#11 driver. Mozilla NSS is a pain to set up. I have no idea how to use its softtoken implementation. Opencryptoki uses ^$@@#$$#&^!!ng autotools bootstrap so I'm not even able to compile it for its softtoken! Obviously, I need *some* PKCS#11 to be able to test the thing :) > > But after looking at the source... it does not looked like a very simple > interface... > It is. Text-based. There is libassuan to help implement the details of the protocol if needed. libassuan is LGPL so there should be no license issues if it is used. Best regards, Zeljko. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050907/75530646/signature-0001.pgp From benjamin at pythagoras.no-ip.org Wed Sep 7 21:29:21 2005 From: benjamin at pythagoras.no-ip.org (Benjamin Donnachie) Date: Wed Sep 7 21:38:29 2005 Subject: OpenPGP Card Message-ID: PLEASE PLEASE PLEASE stop cc'ing messages to me if they are also addressed to the list!!!! -- Benjamin benjamin@pythagoras.no-ip.org From lionel at mamane.lu Wed Sep 7 22:47:46 2005 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Wed Sep 7 22:47:50 2005 Subject: OpenPGP Card In-Reply-To: <20050907111302.GG16716@syjon.fantastyka.net> References: <431DD366.1030405@globalnet.hr> <87d5nmxcp8.fsf@wheatstone.g10code.de> <431EC1D8.7090809@gmail.com> <20050907111302.GG16716@syjon.fantastyka.net> Message-ID: <20050907204746.GA6265@tofu.mamane.lu> On Wed, Sep 07, 2005 at 01:13:02PM +0200, Janusz A. Urbanowicz wrote: > PS> The whole discussion made me curious; I worked with smartcards > extensively few years ago and was grossly disappointed with the stuff from > the development side, but times they are a'changin... Where can I purchase a > couple of OpenPGP cards and readers suitable for use with Debian? Preferably > within the European Union. http://www.kernelconcepts.de/products/security.shtml (Web site in German, but they speak English if you call or email them.) -- Lionel From wk at gnupg.org Fri Sep 9 13:00:00 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Sep 9 13:01:20 2005 Subject: ssh support for Beligian eID cards Message-ID: <87vf1aecb3.fsf@wheatstone.g10code.de> Hi! I just committed changes to GnuPG 1.9 to allow the use of the Beligian eID card now also with ssh. To use this, you need to install the gpg-agent with ssh support (see the manual) and put the card into a reader. Note, that due to the fact that this card is T=0, the internal CCID driver of GnuPG won't work and you need to use pcsc. svn://cvs.gnupg.org/gnupg/branches/GNUPG-1-9-BRANCH When running "ssh-add -l" you will see the fingerprint and the card number as printed on the front matter (e.g. 000-0002011-71). The signing key key is used for this. This new code should work with all pkcs#15 cards. Salam-Shalom, Werner From kfitzner at excelcia.org Thu Sep 8 14:41:58 2005 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Fri Sep 9 14:06:46 2005 Subject: [Announce] GnuPG Explorer Extension (GPGee) Version 1.2.1 Released Message-ID: <43203196.8080806@excelcia.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Version 1.2.1 of GPGee has now been released and is available at http://gpgee.excelcia.org. This is mainly a bugfix release to correct a couple of functional bugs that appeared shortly after 1.2.0 was released. Bugs fixes include: - - Performing sign+encrypt no longer results in GPGee causing Explorer to hang. - - Change in the URL used for the automatic version check (the previous URL pointed at an ISP that cached its web pages, causing repeated notices to "upgrade" to an earlier version). - - Version now only occurs once per day as it was intended. Additionally, the version checking now compares build numbers rather than performing a simple string equality check. There should never again, regardless of ISP problems, be a notice to upgrade to an earlier version. There is one added feature for 1.2.1, designed to work with the multi-key signatures added in 1.2.0. It is now possible to append new signatures to an existing detached signature. In this way you can have one person sign a document, give the document and signature to another person at another maching and that person can add another signature. For those that aren't familliar with GPGee, it is a Windows shell extension that adds GnuPG support to explorer's right-click menu. You can sign, sign+encrypt, encrypt, verify, and decrypt files right from within the Windows explorer. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQyAxlt366Kf2Ie2tAQMpqAf+LzFDQ+T30gUwQR1sOP7FmXx8rWZgWOWE 2yKh6BAnINyL8SUnojU1gClgdpeJ/JS87d0//WJaE9z96kv+VR5/qKlpTqbQtTSB 68NOnk1Iszc6NLpRGe2sHxssJSVxnEUKvAfevLGW3JEdeCkenJ1CVbY184eFu5JM Xxc9yrWy6M2gELM56+BIA2f2Zaj9smTybCwhcCnsqgGJvosXttnFeS1Vw2K3aTP1 wFpeWT7Posn0BrquF+5YBsOVJuFgEdJrxXM+546nti3FWiT+iG/Pp/aMaXGZyjFQ p8d+F+8F3Av44UXw2Nw4BxN3JaUQVaxq1i4cnz6mWvxPDF8b/UUmkQ== =/eNV -----END PGP SIGNATURE----- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Mon Sep 12 14:24:56 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Sep 12 14:25:17 2005 Subject: Keys listed twice when --keyring used - request to filter In-Reply-To: <431D7BCF.40104@excelcia.org> References: <431D7BCF.40104@excelcia.org> Message-ID: <873boaiicn.wl@ulysses.g10code.de> At Tue, 06 Sep 2005 05:21:51 -0600, Kurt Fitzner wrote: > The GPGME library has no command to return the name of the keyrings that > GnuPG is using by default. In fact, gpg doesn't have a way to return the name of the keyrings that it is using by default. You have to figure it out from the configuration file. I haven't checked it out, but those filenames could even be relative instead of absolute, adding another complication. > So, it is difficult for a front-end (one > that uses GPGME) to determine what the configured keyrings are. Thus, > when a front-end allows the specification of extra keyring files, it is > difficult to determine if this will cause duplicate keys to appear. GPGME doesn't allow the specification of extra keyring files, and thus I don't see how you could allow it in the application, unless you are mixing GPGME with your own gpg invocations. The latter is possible, but can lead to inconsistencies as you describe quite naturally. Also for example that a key can be found in the "with extra keyrings gpg invocation", but not with GPGME operations. It is our opinion that keyring settings are a crypto engine configuration that should be done in gpg.conf (thus setting it for all applications). If you need total control over the crypto backend, you can from 1.1.x on create a separate .gnupg home directory and activate it on a per-gpgme context (or per application) with gpgme_set_engine_info. Thanks, Marcus From wk at gnupg.org Mon Sep 12 15:39:23 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 12 15:41:21 2005 Subject: Keys listed twice when --keyring used - request to filter In-Reply-To: <873boaiicn.wl@ulysses.g10code.de> (Marcus Brinkmann's message of "Mon, 12 Sep 2005 14:24:56 +0200") References: <431D7BCF.40104@excelcia.org> <873boaiicn.wl@ulysses.g10code.de> Message-ID: <87u0gqo16c.fsf@wheatstone.g10code.de> On Mon, 12 Sep 2005 14:24:56 +0200, Marcus Brinkmann said: > It is our opinion that keyring settings are a crypto engine > configuration that should be done in gpg.conf (thus setting it for all > applications). If you need total control over the crypto backend, you Let me add that the concept of several keyrings or keyrings at all might soon vanish. For performance reasons we will put everything into one database and provide meta data with the source of the key (e.g. from keyserver xyz) or whether this key is read-only (e.g. to emulate Debian distributed keyrings). Shalom-Salam, Werner From wk at gnupg.org Mon Sep 12 15:29:20 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 12 15:43:54 2005 Subject: [Announce] GnuPG 1.9.19 (S/MIME and gpg-agent) released Message-ID: <87y862o1n3.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Mon Sep 12 15:48:54 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Sep 12 15:50:15 2005 Subject: setenv in assuan-pipe-connect.c In-Reply-To: <0IM300B0LUB782@pmismtp01.mcilink.com> References: <0IM300B0LUB782@pmismtp01.mcilink.com> Message-ID: <871x3uiegp.wl@ulysses.g10code.de> At Wed, 31 Aug 2005 15:59:31 -0500, Martin Traviolia wrote: > > I am building libassuan-0.6.10 on Solaris 9 using Sun's 5.6 C compiler. > > In the file "assuan-pipe-connect.c" is a call to "setenv" which is not > available on Solaris 9. [...] > Looking at the Single UNXI Specification Version 2 the portable, but > non-reentrant, call is "putenv". Otherwise, one would need to copy from > "extern char** environ;" and use "execve". Actually, current POSIX and Single UNIX specifications (version 3) recommend the use of setenv over putenv: "The setenv() function is preferred over this function." Unfortunately, neither putenv nor setenv is guaranteed to be thread-safe! But then, using fork in a threaded context is always a bit of a gamble. > Since Solaris is not a supported platform this may not be worth changing. > > I think I can safely comment it out as I just need gpg-agent. Can you please try the attached patch? It is unfortunately rather big, because I changed the gnulib setup completely to make it automatic (the setenv replacement function has so many dependencies that this seems simpler to me). Please let me know if this patch works for you. -------------- next part -------------- A non-text attachment was scrubbed... Name: assuan-gnulib.patch.gz Type: application/octet-stream Size: 22783 bytes Desc: not available Url : /pipermail/attachments/20050912/c9489505/assuan-gnulib.patch-0001.obj -------------- next part -------------- From marcus.brinkmann at ruhr-uni-bochum.de Mon Sep 12 16:25:10 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Sep 12 16:30:12 2005 Subject: msg__control, msg_controllen, and msg_flags in assuan-domain-connect.c In-Reply-To: <0IM300JB0V986O@pmismtp06.mcilink.com> References: <0IM300JB0V986O@pmismtp06.mcilink.com> Message-ID: <87wtlmgy7t.wl@ulysses.g10code.de> At Wed, 31 Aug 2005 16:19:56 -0500, Martin Traviolia wrote: > > I am building libassuan-0.6.10 on Solaris 9 using Sun's 5.6 C compiler. > > In the file "assuan-domain-connect.c" the fields "msg_control", > "msg_controllen" and "msg_flags" are used from "struct msghdr". > > These fields are only defined on Solaris if "_XOPEN_SOURCE" and > _XOPEN_SOURCE_EXTENDED" are defined, or if "_XOPEN_SOURCE" = 500 Can you try this patch? If it doesn't work, I need the value of ac_cv_host in config.log (or whatever it was called :) 2005-09-12 Marcus Brinkmann * configure.ac: Call AC_CANONICAL_HOST. Add definitions for Solaris. Thanks, Marcus Index: configure.ac =================================================================== --- configure.ac (Revision 187) +++ configure.ac (Arbeitskopie) @@ -70,6 +70,7 @@ # # Options depending on the host OS. # +AC_CANONCICAL_HOST have_dosish_system=no have_w32_system=no case "${host}" in @@ -77,6 +78,11 @@ have_dosish_system=yes have_w32_system=yes ;; + *-*-solaris* ) + AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Needed to get declarations for msg_control and msg_controllen on Solaris) + AC_DEFINE(_XOPEN_SOURCE, 2, Needed to get declarations for msg_control and msg_controllen on Solaris) + AC_DEFINE(__EXTENSIONS__, 1, Needed to get declarations for msg_control and msg_controllen on Solaris) + ;; esac if test "$have_dosish_system" = yes; then From marcus.brinkmann at ruhr-uni-bochum.de Mon Sep 12 17:05:10 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Sep 12 17:10:08 2005 Subject: gpgme-1.0.3: 'make check' fails In-Reply-To: <42F7C03B.4020803@math.unl.edu> References: <42F7C03B.4020803@math.unl.edu> Message-ID: <87u0gqgwd5.wl@ulysses.g10code.de> At Mon, 08 Aug 2005 15:27:39 -0500, Rex Dieter wrote: > > I've tried building gpgme-1.0.3 on both Red Hat 9 (gcc-3.2.2) and Fedora > Core 4 (gcc-4.0.1), and they both fail 1 test in 'make check': > > Making check in gpgsm > make[3]: Entering directory `/usr/local/tmp/BUILD/gpgme-1.0.3/tests/gpgsm' > make check-TESTS > make[4]: Entering directory `/usr/local/tmp/BUILD/gpgme-1.0.3/tests/gpgsm' > PASS: t-import > Key has unexpected number of user IDs > FAIL: t-keylist I can't reproduce this with gpgsm 1.9.15. Which version do you use? Marcus From kfitzner at excelcia.org Mon Sep 12 17:09:48 2005 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Mon Sep 12 17:10:37 2005 Subject: Keys listed twice when --keyring used - request to filter In-Reply-To: <873boaiicn.wl@ulysses.g10code.de> References: <431D7BCF.40104@excelcia.org> <873boaiicn.wl@ulysses.g10code.de> Message-ID: <43259A3C.3020807@excelcia.org> I was probably unclear. I didn't mean for changes for GPGME, but for GnuPG itself. Any --keyring command given on the GnuPG command line causes GnuPG to consider another keyring, irrespective of whether or not that keyring has already been considered for other reasons. For internal handling, this makes no difference, other than the fact GnuPG might take a few more milliseconds to complete a command. But when, for example, you ask GnuPG to list keys, then GnuPG will happily list all the keys from its default keyring, and then from any other keyring specified on the command line, even if it has already listed them before. What I am asking is that, when listing keys, GnuPG keep a simple talley of keyrings it has listed before and not list them twice. Marcus Brinkmann wrote: > At Tue, 06 Sep 2005 05:21:51 -0600, > Kurt Fitzner wrote: > >>The GPGME library has no command to return the name of the keyrings that >>GnuPG is using by default. I am actually using Timo's Windows port (MyGPGME). I patched this to support feeding in keyrings at the request of GPGee users who keep additional keys on removeable media. > In fact, gpg doesn't have a way to return the name of the keyrings > that it is using by default. You have to figure it out from the > configuration file. I haven't checked it out, but those filenames > could even be relative instead of absolute, adding another complication. This is pretty much my point. Because it is impossible to know without parsing the options file (something I'm not about to get into for my little front end), it's impossible to know whether the user has supplied my front end with a keyring file that is already the default one so that I know not to feed that keyring file to GnuPG. > It is our opinion that keyring settings are a crypto engine > configuration that should be done in gpg.conf (thus setting it for all > applications). If you need total control over the crypto backend, you > can from 1.1.x on create a separate .gnupg home directory and activate > it on a per-gpgme context (or per application) with > gpgme_set_engine_info. While not totally relevant to this discussion (on whether GnuPG should filter multiple keyring files in user output), I should go on record that I don't agree with this assessment. There are many times that a front-end may want to deal with keys coming from alternative keyrings. Keys on USB-dongle-devices and other removable media, for example. A friend comes over and his keyring is on a USB device. I shouldn't have to adjust the "crypto back end" - the GnuPG options file in this case - if I want to temporarily add it. My feeling, and the reason why I patched --keyring support into Timo's MyGPGME library in the first place, is that the front end should be able to tell GnuPG to do whatever it is the user wants. To require the user to modify the GnuPG options is placing a heavy burden on front-end developers who want to provide the user with the ability to access keyrings on a temporary basis. Kurt. From kfitzner at excelcia.org Mon Sep 12 17:13:18 2005 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Mon Sep 12 17:13:19 2005 Subject: Keys listed twice when --keyring used - request to filter In-Reply-To: <87u0gqo16c.fsf@wheatstone.g10code.de> References: <431D7BCF.40104@excelcia.org> <873boaiicn.wl@ulysses.g10code.de> <87u0gqo16c.fsf@wheatstone.g10code.de> Message-ID: <43259B0E.3090409@excelcia.org> Werner Koch wrote: > Let me add that the concept of several keyrings or keyrings at all > might soon vanish. For performance reasons we will put everything > into one database and provide meta data with the source of the key > (e.g. from keyserver xyz) or whether this key is read-only (e.g. to > emulate Debian distributed keyrings). I'm not sure I understand this completely. There is going to be a central database where each key can have meta-data that (potentially) tells GnuPG that the key is actually located somewhere else - such as on a keyserver? So the database's key entry itself would be simply a stub - placeholder data to indicate that GnuPG needs to retrieve the key from elsewhere? Kurt. From dshaw at jabberwocky.com Mon Sep 12 17:56:01 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Sep 12 17:56:40 2005 Subject: Keys listed twice when --keyring used - request to filter In-Reply-To: <43259A3C.3020807@excelcia.org> References: <431D7BCF.40104@excelcia.org> <873boaiicn.wl@ulysses.g10code.de> <43259A3C.3020807@excelcia.org> Message-ID: <20050912155601.GA11238@jabberwocky.com> On Mon, Sep 12, 2005 at 09:09:48AM -0600, Kurt Fitzner wrote: > I was probably unclear. I didn't mean for changes for GPGME, but for > GnuPG itself. > > Any --keyring command given on the GnuPG command line causes GnuPG to > consider another keyring, irrespective of whether or not that keyring > has already been considered for other reasons. For internal handling, > this makes no difference, other than the fact GnuPG might take a few > more milliseconds to complete a command. But when, for example, you ask > GnuPG to list keys, then GnuPG will happily list all the keys from its > default keyring, and then from any other keyring specified on the > command line, even if it has already listed them before. > > What I am asking is that, when listing keys, GnuPG keep a simple talley > of keyrings it has listed before and not list them twice. If you want to avoid the default keyrings being listed twice, why not just not supply them twice? See the --no-default-keyring option. David From rdieter at math.unl.edu Mon Sep 12 18:33:48 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon Sep 12 18:33:46 2005 Subject: gpgme-1.0.3: 'make check' fails In-Reply-To: <87u0gqgwd5.wl@ulysses.g10code.de> References: <42F7C03B.4020803@math.unl.edu> <87u0gqgwd5.wl@ulysses.g10code.de> Message-ID: <4325ADEC.4080108@math.unl.edu> Marcus Brinkmann wrote: >At Mon, 08 Aug 2005 15:27:39 -0500, >Rex Dieter wrote: > > >>I've tried building gpgme-1.0.3 on both Red Hat 9 (gcc-3.2.2) and Fedora >>Core 4 (gcc-4.0.1), and they both fail 1 test in 'make check': >> >>Making check in gpgsm >>make[3]: Entering directory `/usr/local/tmp/BUILD/gpgme-1.0.3/tests/gpgsm' >>make check-TESTS >>make[4]: Entering directory `/usr/local/tmp/BUILD/gpgme-1.0.3/tests/gpgsm' >>PASS: t-import >>Key has unexpected number of user IDs >>FAIL: t-keylist >> >> > >I can't reproduce this with gpgsm 1.9.15. Which version do you use? > > gnupg2-1.9.18. Upon further investigation/testing, it turns out all checks PASS when building against gnupg2-1.9.17. -- Rex From rdieter1 at unl.edu Mon Sep 12 19:04:41 2005 From: rdieter1 at unl.edu (Rex Dieter) Date: Mon Sep 12 19:04:56 2005 Subject: gpgme-1.0.3: 'make check' fails In-Reply-To: <4325ADEC.4080108@math.unl.edu> References: <42F7C03B.4020803@math.unl.edu> <87u0gqgwd5.wl@ulysses.g10code.de> <4325ADEC.4080108@math.unl.edu> Message-ID: <4325B529.5040303@unl.edu> Rex Dieter wrote: > Marcus Brinkmann wrote: > >> At Mon, 08 Aug 2005 15:27:39 -0500, >> Rex Dieter wrote: >> >> >>> I've tried building gpgme-1.0.3 on both Red Hat 9 (gcc-3.2.2) and >>> Fedora Core 4 (gcc-4.0.1), and they both fail 1 test in 'make check': >>> >>> Making check in gpgsm >>> make[3]: Entering directory >>> `/usr/local/tmp/BUILD/gpgme-1.0.3/tests/gpgsm' >>> make check-TESTS >>> make[4]: Entering directory >>> `/usr/local/tmp/BUILD/gpgme-1.0.3/tests/gpgsm' >>> PASS: t-import >>> Key has unexpected number of user IDs >>> FAIL: t-keylist >>> >> >> >> I can't reproduce this with gpgsm 1.9.15. Which version do you use? >> >> > gnupg2-1.9.18. Upon further investigation/testing, it turns out all > checks PASS when building against gnupg2-1.9.17. Turns out gpgme-1.0.3 'make check' fails the t-keylist test too with the just released gnupg-1.9.19 as well, error is: $ gpgme-1.0.3/tests/gpgsm/t-keylist Less keys returned than expected -- Rex From wk at gnupg.org Mon Sep 12 19:56:40 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 12 20:01:21 2005 Subject: Keys listed twice when --keyring used - request to filter In-Reply-To: <43259B0E.3090409@excelcia.org> (Kurt Fitzner's message of "Mon, 12 Sep 2005 09:13:18 -0600") References: <431D7BCF.40104@excelcia.org> <873boaiicn.wl@ulysses.g10code.de> <87u0gqo16c.fsf@wheatstone.g10code.de> <43259B0E.3090409@excelcia.org> Message-ID: <87y862i2zr.fsf@wheatstone.g10code.de> On Mon, 12 Sep 2005 09:13:18 -0600, Kurt Fitzner said: > I'm not sure I understand this completely. There is going to be a > central database where each key can have meta-data that (potentially) > tells GnuPG that the key is actually located somewhere else - such as on > a keyserver? No. Sometimes it makes sense to know from where the key has been imported. I am not yet sure about this, it is just one option. > So the database's key entry itself would be simply a stub - placeholder > data to indicate that GnuPG needs to retrieve the key from elsewhere? No. In fact the plan is also to provide a generic backend for key retrieval, so that people can implement their own storage backend. Shalom-Salam, Werner From marcus.brinkmann at ruhr-uni-bochum.de Mon Sep 12 20:33:57 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Sep 12 20:35:09 2005 Subject: gpgme-1.0.3: 'make check' fails In-Reply-To: <4325B529.5040303@unl.edu> References: <42F7C03B.4020803@math.unl.edu> <87u0gqgwd5.wl@ulysses.g10code.de> <4325ADEC.4080108@math.unl.edu> <4325B529.5040303@unl.edu> Message-ID: <87ek7um8yy.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 12 Sep 2005 12:04:41 -0500, Rex Dieter wrote: > > gnupg2-1.9.18. Upon further investigation/testing, it turns out all > > checks PASS when building against gnupg2-1.9.17. > > Turns out gpgme-1.0.3 'make check' fails the t-keylist test too with the > just released gnupg-1.9.19 as well, error is: > > $ gpgme-1.0.3/tests/gpgsm/t-keylist > Less keys returned than expected Thanks. It's not surprising. The tests are very strict, and maybe overly so. Changes in gpg/gpgsm can easily lead to "spurious" test failures which are simply fixed by adapting to the new output or relaxing the test. Or, of course, the test failures can indicate bugs in gpg/gpgsm :) When I update my gpg/gpgsm, I'll take another look at it. Thanks, Marcus From twoaday at gmx.net Tue Sep 13 21:05:40 2005 From: twoaday at gmx.net (Timo Schulz) Date: Tue Sep 13 22:03:22 2005 Subject: [svn] GPGol - r93 - trunk/src In-Reply-To: References: Message-ID: <20050913190540.GH1174@daredevil.joesixpack.net> On Tue Sep 13 2005; 19:21, svn author wk wrote: Habe ich irgendwo was ?bersehen oder benutzt du nur "\n" als Zeilenendungen? Ich weiss nicht ob Outlook die konvertiert, da ich aber kein fopen (.., "t") sehe, w?rde ich vorschlagen wir nehmen hier immer "\r\n". Timo From schierlm at gmx.de Fri Sep 16 17:08:16 2005 From: schierlm at gmx.de (Michael Schierl) Date: Fri Sep 16 17:10:11 2005 Subject: Controlling --desig-revoke on command line Message-ID: <432ADFE0.5080005@gmx.de> Hi, Situation: There are three keys, "Designated Revoker Test" "Revoker1" "Revoker2" "Revoker1" and "Revoker2" may both revoke "Designated Revoker Test". GPG Version is 1.4.2 for Windows from gnupg.org. Trying to revoke this key interactively looks like this: > C:\temp>gpg --homedir \temp --desig-revoke Designated > > pub 512D/68E771D3 2005-09-16 Designated Revoker Test > To be revoked by: > sec 512D/8116F98A 2005-09-16 Revoker1 > Create a designated revocation certificate for this key? (y/N) n > > pub 512D/68E771D3 2005-09-16 Designated Revoker Test > To be revoked by: > sec 512D/0571B852 2005-09-16 Revoker2 > Create a designated revocation certificate for this key? (y/N) n But, when using --with-colons, --command-fd, --status-fd and such, it is impossible to tell which key is which: > C:\temp>gpg --homedir \temp --with-colons --no-tty --status-fd 1 --command-fd 0 --desig-revoke Designated > [GNUPG:] GET_BOOL gen_desig_revoke.okay > n > [GNUPG:] GOT_IT > [GNUPG:] GET_BOOL gen_desig_revoke.okay > n > [GNUPG:] GOT_IT Am I again missing some option (either to make it more verbose or to specify the correct revoker on command line) or is this a bug? There *is* a workaround I know - just continue with the revocation stuff until the passphrase is asked for; then you'll get the key id in the USERID_HINT. And if it is the wrong one, close the pgp process and retry the next one... However, this is quite a "dirty hack" - and it does not work if one of the revokers does not have any passphrase... Michael From maschoch at compuserve.com Sun Sep 18 07:01:21 2005 From: maschoch at compuserve.com (Martin Schoch) Date: Sun Sep 18 08:21:59 2005 Subject: GnuPG 1.4.2 Windows LDAP problems Message-ID: <309586841.20050918070121@compuserve.com> Hi list, I updated GnuPG from version 1.4.1 to 1.4.2 on Windows 2000 SP4 and have no problems when GnuPG wants to download keys from a server with the LDAP protocol. gpg: Signature made 08/08/05 20:12:43 using DSA key ID XXXXXXXX gpg: requesting key XXXXXXXX from ldap server horowitz.surfnet.nl gpg: Keine g?ltigen OpenPGP-Daten gefunden. gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 0 gpg: Unterschrift kann nicht gepr?ft werden: ?ffentlicher Schl?ssel nicht gefunden Did I miss something, do I have to change something in the configuration? Thanks for help. -- Best regards, Martin Schoch maschoch@compuserve.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 244 bytes Desc: not available Url : /pipermail/attachments/20050918/9edef36c/attachment.pgp From JPClizbe at comcast.net Mon Sep 19 04:54:00 2005 From: JPClizbe at comcast.net (John Clizbe) Date: Mon Sep 19 05:03:41 2005 Subject: GnuPG 1.4.2 Windows LDAP problems In-Reply-To: <309586841.20050918070121@compuserve.com> References: <309586841.20050918070121@compuserve.com> Message-ID: <432E2848.9050908@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Schoch wrote: > Hi list, > > I updated GnuPG from version 1.4.1 to 1.4.2 on Windows 2000 SP4 > and have no problems when GnuPG wants to download keys from a > server with the LDAP protocol. > > gpg: Signature made 08/08/05 20:12:43 using DSA key ID XXXXXXXX > gpg: requesting key XXXXXXXX from ldap server horowitz.surfnet.nl > gpg: Keine g?ltigen OpenPGP-Daten gefunden. > gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 0 > gpg: Unterschrift kann nicht gepr?ft werden: ?ffentlicher Schl?ssel nicht gefunden > > > Did I miss something, do I have to change something in the > configuration? You probably missed this announcement. keyserver x-hkp://minsky.surfnet.nl I believe the only LDAP keyservers still operational are the pgp.com ones. - -John - -------- Original Message -------- Subject: Traditional LDAP keyserver going off line Date: Tue, 09 Aug 2005 12:27:21 +0200 From: Teun Nijssen Organization: Tilburg University To: pgp-keyserver-folk@alt.org, gnupg-devel@gnupg.org, sks-devel@nongnu.org, pgp-keyserver-folk@kjsl.com, pgp-users@lists.cryptorights.org Hi, for a very, very long time (even when a keyserver was a Perl script), SURFnet has been funding PGP keyservers. In august 2004, SURFnet installed a new dedicated SKS keyserver hkp://pgp.surfnet.nl:11371 which is also known as minsky.surfnet.nl The previous machine, horowitz.surfnet.nl is currently still operational; it handles between 1M and 2M *LDAP* keyserver requests per month. Nevertheless, at the end of this month good old horowitz (a Solaris Enterprise 1 box of previous century quality) will go off-line. Its problem is not the age of the hardware but the fading away of Solaris at Tilburg University. (We're a Debian site now.) I have requested PGP.com to point the europe.keys.pgp.com cname alias to one of their own servers. cheers, teun - -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3-cvs-3894-2005-09-16 (Windows 2000 SP4) Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG Comment: Be part of the ?33t ECHELON -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDLihGHQSsSmCNKhARAimzAKDz75lvWRvpUdhZRbq9WTrDgxsaagCeK0hj m8Yu5KpM7v32rqKKxF4Q3Dw= =Tbu+ -----END PGP SIGNATURE----- From hawke at hawkesnest.net Mon Sep 19 19:08:44 2005 From: hawke at hawkesnest.net (Alex Mauer) Date: Mon Sep 19 19:12:35 2005 Subject: Smart card fragility? Message-ID: Please forgive my potential lack of understanding on this topic... It seems to me that there is a pretty big vulnerability of smart cards: that of the Admin PIN. All a malicious card terminal would have to do is enter an invalid Admin PIN 3 times, and you've got a somewhat expensive and thoroughly ineffective paperweight. The solution I see to this is, instead of treating a zeroed Admin pin failure counter as a flag denying access to the private key, instead treat it as a flag that tells the card to wipe all private keys. When all keys have been wiped, and verified as such, reset the Admin PIN and regular PIN to defaults, and reset the counters to 3. (and maybe reset the user name and so forth) Is there some reason that this would not work, or would create a vulnerability? It seems to me that this would be a major benefit in terms of cost of a card, since you could re-use cards as much as you wanted and you wouldn't have the risk of completely destroying it, whether through accident or malicious intent. Thoughts? -Alex Mauer "hawke" -- Bad - You get pulled over for doing 90 in a school zone and you're drunk off your ass again at three in the afternoon. Worse - The cop is drunk too, and he's a mean drunk. FUCK! - A mean drunk that's actually a swarm of semi-sentient flesh-eating beetles. OpenPGP key id: 0x51192FF2 @ subkeys.pgp.net From wk at gnupg.org Tue Sep 20 10:23:30 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 20 10:26:34 2005 Subject: Smart card fragility? In-Reply-To: (Alex Mauer's message of "Mon, 19 Sep 2005 12:08:44 -0500") References: Message-ID: <87mzm81725.fsf@wheatstone.g10code.de> On Mon, 19 Sep 2005 12:08:44 -0500, Alex Mauer said: > It seems to me that there is a pretty big vulnerability of smart cards: > that of the Admin PIN. All a malicious card terminal would have to do > is enter an invalid Admin PIN 3 times, and you've got a somewhat > expensive and thoroughly ineffective paperweight. Correct. There is no way to prevent this. One could imagine a reader with keypad which reliable enforces the use of the pinpad by catching all VERIFY commands and somehow is able tell the user which PIN has been requested (requires knowledge of the smart card application). I don't know such a reader. > The solution I see to this is, instead of treating a zeroed Admin pin > failure counter as a flag denying access to the private key, instead > treat it as a flag that tells the card to wipe all private keys. When Yes, this is possible. > Is there some reason that this would not work, or would create a > vulnerability? It seems to me that this would be a major benefit in > terms of cost of a card, since you could re-use cards as much as you Actually card vendors won't see that as a benefit to them. After all there business is to sell cards. For the user the real damage is not the locked card but the loss of the keys which are far more valuable than that piece plastic and silicon. OTOH, I understand your concerns. In particular when developing applications a complete wipe out command would be a nice to have. We already discussed whether we can add such a thing as an optional feature to the next release of the specification. Shalom-Salam, Werner From hawke at hawkesnest.net Tue Sep 20 19:15:25 2005 From: hawke at hawkesnest.net (Alex Mauer) Date: Tue Sep 20 19:21:20 2005 Subject: Smart card fragility? In-Reply-To: <87mzm81725.fsf__7776.52525944195$1127204880$gmane$org@wheatstone.g10code.de> References: <87mzm81725.fsf__7776.52525944195$1127204880$gmane$org@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > One could imagine a reader with keypad which reliable enforces the use > of the pinpad by catching all VERIFY commands and somehow is able tell > the user which PIN has been requested (requires knowledge of the smart > card application). I don't know such a reader. Or a standardized way for a card reader to respond to any application with that information. I'm not going to hold my breath for such a solution though. :-D >>treat it as a flag that tells the card to wipe all private keys. > > Yes, this is possible. Possible, surely. But how likely to get into the OpenPGP card? > Actually card vendors won't see that as a benefit to them. After all > there business is to sell cards. Of course it would not be an immediate benefit, but I think they would find that many more people would be interested in their product if it didn't have a built-in self-destruct mechanism. I know I'd be much more inclined to push for my company to use a smart card that was reusable. > For the user the real damage is not > the locked card but the loss of the keys which are far more valuable > than that piece plastic and silicon. The relative value of the key vs. the card depends on the application. For something like a CA, the key is almost definitely more valuable. (I guess the term "CA" doesn't really apply to OpenPGP ... so say a very well-known key pair) But in a case where the card is used primarily for authentication, or really any "client-side" type application, the card is probably going to be more valuable. For me, I use the card for a signing subkey and auth subkey only (for just this reason) so if the key is lost, I could just generate a new signing key and carry on without losing anything. But if the card is lost/locked I have to buy a new one, which is a hassle and expense I'd prefer not to have to deal with. > OTOH, I understand your concerns. In particular when developing > applications a complete wipe out command would be a nice to have. We > already discussed whether we can add such a thing as an optional > feature to the next release of the specification. That would be excellent if it's likely to actually be implemented. Thanks -Alex Mauer "hawke" -- Bad - You get pulled over for doing 90 in a school zone and you're drunk off your ass again at three in the afternoon. Worse - The cop is drunk too, and he's a mean drunk. FUCK! - A mean drunk that's actually a swarm of semi-sentient flesh-eating beetles. OpenPGP key id: 0x51192FF2 @ subkeys.pgp.net From unknown_kev_cat at hotmail.com Tue Sep 20 22:43:10 2005 From: unknown_kev_cat at hotmail.com (Joe Smith) Date: Tue Sep 20 22:46:29 2005 Subject: Smart card fragility? References: Message-ID: ----- Original Message ----- From: "Alex Mauer" Newsgroups: gmane.comp.encryption.gpg.devel Sent: Monday, September 19, 2005 1:08 PM Subject: Smart card fragility? > Please forgive my potential lack of understanding on this topic... > > It seems to me that there is a pretty big vulnerability of smart cards: > that of the Admin PIN. All a malicious card terminal would have to do > is enter an invalid Admin PIN 3 times, and you've got a somewhat > expensive and thoroughly ineffective paperweight. > This is one of the reasons I don't yet have one of these. Cost, location, and the current linux smart card hell are some others. Key loss should not be too critical. A wise person would not gerneate keys on the card at all, but generate them on a known secure, non-internet connected machine, (as root, onto a ramdrive). They would upload them to the cards, but keep a backup, on optical medium in some safe place like perhaps a bank safety deposit box. From ryan at malayter.com Thu Sep 22 05:47:10 2005 From: ryan at malayter.com (Ryan Malayter) Date: Thu Sep 22 07:26:02 2005 Subject: large file support in Win32 Message-ID: <5d7f07420509212047b59cb0e@mail.gmail.com> Werner, this is a follow-up post to the recent threads on the gnupg-users lists. I just ran some tests on a 45 GB file called myfile.bkf. GPG 1.4.2 actually encrypts the entire file without reporting any errors on Win XP SP2. However, the resulting file is corrupt. The file cannot be decrypted, even with redirection to stdout. Encrypting files using redirection to stdin and stdout does work around the problem, but as you mentioned it should be working using standard filename parameters. So here is a transcript of my test session, with the -vv parameter. Please let me know if you would like me to test anything else: E:\>dir e:\myfile.bkf 09/18/2005 05:44 AM 45,284,360,192 myfile.bkf E:\>gpg -c -vv -z 1 --cipher aes -o c:\temp\myfile.bkf.gpg e:\myfile.bkf gpg: using cipher AES gpg: writing to `c:\temp\myfile.bkf.gpg' E:\>dir c:\temp\myfile.bkf.gpg 09/21/2005 10:06 AM 31,336,076,736 myfile.bkf.gpg E:\>gpg -d -vv -o e:\myfile2.bkf c:\temp\myfile.bkf.gpg :symkey enc packet: version 4, cipher 7, s2k 3, hash 2 salt 6b08ed303fb90a22, count 96 gpg: AES encrypted data :encrypted data packet: length: unknown mdc_method: 2 gpg: encrypted with 1 passphrase :compressed packet: algo=1 :literal data packet: mode b (62), created 1127307875, name="myfile.bkf", raw data: 2334687232 bytes gpg: original file name='myfile.bkf' gpg: [don't know]: invalid packet (ctb=5f) gpg: [don't know]: indeterminate length for invalid packet type 5 gpg: WARNING: encrypted message has been manipulated! gpg: [don't know]: invalid packet (ctb=74) E:\>dir e:\myfile2.bkf Volume in drive E is Backup disk Volume Serial Number is 9EE2-3002 Directory of e:\ 09/21/2005 07:32 PM 2,334,687,232 myfile2.bkf E:\>gpg -d -vv c:\temp\myfile.bkf.gpg > e:\myfile2.bkf :symkey enc packet: version 4, cipher 7, s2k 3, hash 2 salt 6b08ed303fb90a22, count 96 gpg: AES encrypted data :encrypted data packet: length: unknown mdc_method: 2 gpg: encrypted with 1 passphrase :compressed packet: algo=1 :literal data packet: mode b (62), created 1127307875, name="myfile.bkf", raw data: 2334687232 bytes gpg: original file name='myfile.bkf' gpg: [don't know]: invalid packet (ctb=5f) gpg: [don't know]: indeterminate length for invalid packet type 5 gpg: WARNING: encrypted message has been manipulated! gpg: [don't know]: invalid packet (ctb=74) E:\>dir e:\myfile2.bkf 09/21/2005 08:09 PM 2,334,687,232 myfile2.bkf From wk at gnupg.org Thu Sep 22 09:58:02 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Sep 22 10:01:51 2005 Subject: large file support in Win32 In-Reply-To: <5d7f07420509212047b59cb0e@mail.gmail.com> (Ryan Malayter's message of "Wed, 21 Sep 2005 22:47:10 -0500") References: <5d7f07420509212047b59cb0e@mail.gmail.com> Message-ID: <87d5n1mt4l.fsf@wheatstone.g10code.de> On Wed, 21 Sep 2005 22:47:10 -0500, Ryan Malayter said: > 09/18/2005 05:44 AM 45,284,360,192 myfile.bkf > :literal data packet: > mode b (62), created 1127307875, name="myfile.bkf", > raw data: 2334687232 bytes This number is exactly the remainder of 45284360192 / 2^32. Thus my conclusion is that GetFizeSize does not return a proper error as ist should according to the documentation. Maybe this did not happen with W98. The easiest way of fixing it would be using GetFileSizeEx but that function is only available with W2000 Professional. So either I try to figure out why GetFileSize does not return an error anymore or I need to dynamically load GetFileSizeEx; did the later at other places too. Many thanks for running this test. Werner From ryan at malayter.com Thu Sep 22 14:45:54 2005 From: ryan at malayter.com (Ryan Malayter) Date: Thu Sep 22 14:46:26 2005 Subject: large file support in Win32 In-Reply-To: <87d5n1mt4l.fsf@wheatstone.g10code.de> References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> Message-ID: <5d7f07420509220545680ffbf7@mail.gmail.com> Looking at the PLatform SDK documentation, it isn't clear that GetFileSize will fail when a file is > 4 GB. Maybe I'm reading it incorrectly, and it is certainly very vague, but nowhere does it say "if a file is greater than 4 GB, INVALID_FILE_SIZE will be returned". It only sayd about "if the function fails", not that a file size > 4GB will cause it to fail. I suppose the only thing to do would be to pass a lpFileSizeHigh value and test combinations with GetLastError to see what the function's behavior really is. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp On 9/22/05, Werner Koch wrote: > On Wed, 21 Sep 2005 22:47:10 -0500, Ryan Malayter said: > > > 09/18/2005 05:44 AM 45,284,360,192 myfile.bkf > > > :literal data packet: > > mode b (62), created 1127307875, name="myfile.bkf", > > raw data: 2334687232 bytes > > This number is exactly the remainder of 45284360192 / 2^32. > > Thus my conclusion is that GetFizeSize does not return a proper error > as ist should according to the documentation. Maybe this did not > happen with W98. > > The easiest way of fixing it would be using GetFileSizeEx but that > function is only available with W2000 Professional. So either I try to > figure out why GetFileSize does not return an error anymore or I need > to dynamically load GetFileSizeEx; did the later at other places too. > > Many thanks for running this test. > > Werner > > -- RPM ========================= All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous From alaricd at pengdows.com Thu Sep 22 15:21:50 2005 From: alaricd at pengdows.com (Alaric Dailey) Date: Thu Sep 22 15:22:35 2005 Subject: large file support in Win32 In-Reply-To: <5d7f07420509220545680ffbf7@mail.gmail.com> References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> <5d7f07420509220545680ffbf7@mail.gmail.com> Message-ID: <4332AFEE.7010808@pengdows.com> GetFileSize shouldn't be the API call you are making you should be using GetFileSizeEx, but... DWORD GetFileSize (HANDLE hFile, LPDWORD pHighOrder) it returns a low order unsigned long, and if you want the larger portion you need to pass in a pointer to a DWORD to get the HIGH ORDER portion of the file size (greater than 4Gig). http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getfilesize.asp Ryan Malayter wrote: > Looking at the PLatform SDK documentation, it isn't clear that > GetFileSize will fail when a file is > 4 GB. Maybe I'm reading it > incorrectly, and it is certainly very vague, but nowhere does it say > "if a file is greater than 4 GB, INVALID_FILE_SIZE will be returned". > It only sayd about "if the function fails", not that a file size > 4GB > will cause it to fail. > > I suppose the only thing to do would be to pass a lpFileSizeHigh value > and test combinations with GetLastError to see what the function's > behavior really is. > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp > > > On 9/22/05, Werner Koch wrote: > >> On Wed, 21 Sep 2005 22:47:10 -0500, Ryan Malayter said: >> >> >>> 09/18/2005 05:44 AM 45,284,360,192 myfile.bkf >>> >>> :literal data packet: >>> mode b (62), created 1127307875, name="myfile.bkf", >>> raw data: 2334687232 bytes >>> >> This number is exactly the remainder of 45284360192 / 2^32. >> >> Thus my conclusion is that GetFizeSize does not return a proper error >> as ist should according to the documentation. Maybe this did not >> happen with W98. >> >> The easiest way of fixing it would be using GetFileSizeEx but that >> function is only available with W2000 Professional. So either I try to >> figure out why GetFileSize does not return an error anymore or I need >> to dynamically load GetFileSizeEx; did the later at other places too. >> >> Many thanks for running this test. >> >> Werner >> >> >> > > > -- > RPM > ========================= > All problems can be solved by diplomacy, but violence and treachery > are equally effective, and more fun. > -Anonymous > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3544 bytes Desc: S/MIME Cryptographic Signature Url : /pipermail/attachments/20050922/d8751d1b/smime.bin From wk at gnupg.org Thu Sep 22 18:58:00 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Sep 22 19:01:37 2005 Subject: large file support in Win32 In-Reply-To: <5d7f07420509220545680ffbf7@mail.gmail.com> (Ryan Malayter's message of "Thu, 22 Sep 2005 07:45:54 -0500") References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> <5d7f07420509220545680ffbf7@mail.gmail.com> Message-ID: <87d5n1kpk7.fsf@wheatstone.g10code.de> On Thu, 22 Sep 2005 07:45:54 -0500, Ryan Malayter said: > I suppose the only thing to do would be to pass a lpFileSizeHigh value > and test combinations with GetLastError to see what the function's > behavior really is. My reading was that it returns an error. Am not sure, but I think I tested this once with Windows ME. Anyway, I solved it now by using GetFileSizeEx. I ran a test today and it works. I was only abe to do the decrytpion to nul but it didn't reported an error. On pre W2000 system GetFileSize will be used. Salam-Shalom, Werner From wk at gnupg.org Thu Sep 22 18:59:32 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Sep 22 19:01:46 2005 Subject: large file support in Win32 In-Reply-To: <4332AFEE.7010808@pengdows.com> (Alaric Dailey's message of "Thu, 22 Sep 2005 08:21:50 -0500") References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> <5d7f07420509220545680ffbf7@mail.gmail.com> <4332AFEE.7010808@pengdows.com> Message-ID: <878xxpkphn.fsf@wheatstone.g10code.de> On Thu, 22 Sep 2005 08:21:50 -0500, Alaric Dailey said: > GetFileSize shouldn't be the API call you are making you should be > using GetFileSizeEx, but... Which is not availabe for old systems. > it returns a low order unsigned long, and if you want the larger > portion you need to pass in a pointer to a DWORD to get the HIGH ORDER > portion of the file size (greater than 4Gig). I better don't change the code - it might break things under W95. Shalom-Salam, Werner From ryan at malayter.com Thu Sep 22 21:48:37 2005 From: ryan at malayter.com (Ryan Malayter) Date: Thu Sep 22 21:49:12 2005 Subject: large file support in Win32 In-Reply-To: <87d5n1kpk7.fsf@wheatstone.g10code.de> References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> <5d7f07420509220545680ffbf7@mail.gmail.com> <87d5n1kpk7.fsf@wheatstone.g10code.de> Message-ID: <5d7f074205092212485acd5447@mail.gmail.com> On 9/22/05, Werner Koch wrote: > Anyway, I solved it now by using GetFileSizeEx. I ran a test today > and it works. I was only abe to do the decrytpion to nul but it didn't > reported an error. > > On pre W2000 system GetFileSize will be used. Fatastic! Any idea what version it will be in? I was going to give mingw/msys another try soon... this seems like a good opportunity. Or is it just easier to do a cross-compile from Linux? Thanks for all your great work, -- RPM ========================= All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous From michael at mh-area.de Thu Sep 22 21:48:01 2005 From: michael at mh-area.de (Michael Holschbach) Date: Thu Sep 22 23:26:01 2005 Subject: outdated keyring on write lock Message-ID: <200509222148.02493.michael@mh-area.de> Hi, i found a problem (at least for me) with keyring locking: 1. start two "gpg --edit-key" programs for different keys 2. sign one key per program 3. close first program with "save" new keyring files are written to disk, including the new signature 4. close second program with "save" new keyring files are written to disk, but the first signature is lost So, is there a "read lock" available in gpg? Or a way to reload the keyring after the write lock is acquired? Michael From cedar at 3web.net Fri Sep 23 02:05:03 2005 From: cedar at 3web.net (cdr) Date: Fri Sep 23 04:56:00 2005 Subject: large file support in Win32 In-Reply-To: <87d5n1kpk7.fsf@wheatstone.g10code.de> References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> <5d7f07420509220545680ffbf7@mail.gmail.com> <87d5n1kpk7.fsf@wheatstone.g10code.de> Message-ID: <433346AF.70809@3web.net> Werner Koch wrote: > Anyway, I solved it now by using GetFileSizeEx. I ran a test today > and it works. I was only abe to do the decrytpion to nul but it didn't > reported an error. > > On pre W2000 system GetFileSize will be used. It is generally preferable for application developers to warn the users against creating and processing files which are larger than 2**31 bytes, than to try to make their particular application process such files in 32-bit windows systems. A file is almost never an object dealt with exclusively by a single application or program; it is almost certain that it will sooner or later be dealt with by an operating system component or third party utility, many (if not most) of which on Win32 family of operating systems will choke on such files, or, worse, fail without giving any indication of the fact. cdr From wk at gnupg.org Fri Sep 23 10:04:29 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Sep 23 10:06:34 2005 Subject: outdated keyring on write lock In-Reply-To: <200509222148.02493.michael@mh-area.de> (Michael Holschbach's message of "Thu, 22 Sep 2005 21:48:01 +0200") References: <200509222148.02493.michael@mh-area.de> Message-ID: <874q8cjjle.fsf@wheatstone.g10code.de> On Thu, 22 Sep 2005 21:48:01 +0200, Michael Holschbach said: > 3. close first program with "save" > new keyring files are written to disk, including the new signature > 4. close second program with "save" > new keyring files are written to disk, but the first signature is lost This is the standard strategy, last save wins. It is the same as with all text editors (although some may warn about trying to save a meanwhile changed file). > So, is there a "read lock" available in gpg? Or a way to reload the keyring > after the write lock is acquired? No. It does not make much sense out of two resons: * A stale process might hold the read lock and it would be cumbersome for the user to walk/login to that machine and close the edit there. * In almost all cases there is something wrong if you are editing two keys or even the same key at the same time. gpg is not a database application and thus provides no means of locking. Well, there is some locking but it is only required to maintain the integrity of the keyrings. Shalom-Salam, Werner From ryan at malayter.com Fri Sep 23 17:41:02 2005 From: ryan at malayter.com (Ryan Malayter) Date: Fri Sep 23 17:41:40 2005 Subject: large file support in Win32 In-Reply-To: <433346AF.70809@3web.net> References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> <5d7f07420509220545680ffbf7@mail.gmail.com> <87d5n1kpk7.fsf@wheatstone.g10code.de> <433346AF.70809@3web.net> Message-ID: <5d7f0742050923084112e635c3@mail.gmail.com> On 9/22/05, cdr wrote: > It is generally preferable for application developers to warn the > users against creating and processing files which are larger than > 2**31 bytes, than to try to make their particular application > process such files in 32-bit windows systems. > > A file is almost never an object dealt with exclusively by a single > application or program; it is almost certain that it will sooner or > later be dealt with by an operating system component or third party > utility, many (if not most) of which on Win32 family of operating > systems will choke on such files, or, worse, fail without giving any > indication of the fact. Oracle, Microsoft, Veritas/Symantec, Computer Associates, IBM, Adobe, and most other major software shops seem to disagree with you. Every single video, database, or enterprise backup application built for Windows deals with large files on a routine basis. Large file support has stable on the windows NT platform since the NT 3.5 release, so long as NTFS is the chosen file system. NT 3.5 was released in 1994. In fact, the only "major" application I can think of that has trouble with large files is WinZip prior to 9.0, and that is because the entrenched ZIP file format only uses 32-bit file size fields. Come to think of it, I seem to have trouble with large files on Windows only when dealing with ported POSIX utilities like gzip, rsync, gnupg, and the like. -- RPM ========================= All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous From alaricd at pengdows.com Fri Sep 23 21:14:36 2005 From: alaricd at pengdows.com (Alaric Dailey) Date: Fri Sep 23 21:15:25 2005 Subject: Problem with PGP key Message-ID: <4334541C.3090803@pengdows.com> Over at CAcert we are having problems with a user trying to get his PGP key signed. This PGP key works properly under PGP, but fails to even be imported with any version of GPG we have tried. Can someone tell me what the problem is, is this a bug, is this just a bad way to form the user ID or what? -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP 8.1 Comment: mQELBEMzmUUBCACnhTj12NjPH7K6xwRKejFmUEaISxU31Ge/hEVrZTkdF+V7xgbS pI+4vTnThYr1U4e8tbbFt2aDP/lCREBRN25uJmvTkisEL+9aIyenJA6hpJQY5D4X flLe4qb5VjbFe0RbVeb0xxyF8aWRFRavLnOmW8Dnif165B93JGMeK/KteLCC4kR+ LEmsuAKGAod1KMLl8gJemikYxRz0j5PEpV+jnbb/PbFNAgaFFOS7Bkg/qPf759WS DMphaWoATRalW7KUtJd9One50/Ae3cEVUnGDC8jWyrEURtlVgSWgJN8r3DpeyDan FvZQJ8WNiI+0nSP0nJOEss7XuW7QLItw6NefAAYptDpKT0hOIFcuIE1PT1JFIElJ SSAoR1NXb1Q6VVM6MjYpIDxqb2hubW9vcmUzcmRAam9pbWFpbC5jb20+iQE6BBMB AwAkAhsDBwsJCAcDAgEEFQIIAwQWAgMBAh4BAheABQJDM5+eAhkBAAoJEBCGy9eA tCsPYOoH/3uTgttfoHITHSKG5WATC6xotfKwXGjj60dvURvDkMWSXcZY7foKMMd+ LSKdWktQq3HEc+MJQExzAeQiXUM7VjNy+f80BzJbNIIK98Ft35YT23rU/6z2WKhy CHjFhOysgsDX5ciFWonR/GVfLDhOyQGdA+IXNmUKlOwgDxMUQ7IuNi/LjaF8V5jL NH+QEScDJlYAivDIoxPAM09m0JPJiLGweKcjjko2hE1Jz3mT0f+J+DuhHQ8tzuBj +NoHoa/7Mm//huqkFULrhKpk3/EaNiLdcX1/fiLMRCu9ZMkx8gd/ejvIKMNoMeO2 kYdTjrncd7EMtH83OSUpMqgQVwVKQECISgQTEQMACgUCQzOdmwMFAngACgkQnCmZ hrerneXjrwCffGfopwA+H1YBdTySfXiwfzqqr4cAoIwmYMvtT2uy13i0D0/uGBi7 aDDluQMNBEMzmiIQDADFf/BDrR25NRGDOlLwQj7/bYDwPGotpkpcIuCcwdWlzP9T snSLH/0RZeo4TpCdL9KVfPmPOt7zYmHA7SW7Cc5AaPGyGnAy/uqoq8xnekcBcCvf gFmSPUEJeDBNwUxOmuxCl9mZndSmubbaSxb7camZIyw0TaMctEZCiGn2vYRaIuWE sCs9D2JHzrV9kmmk4q8KK0PAq5S/AskpomVkjUtIPzHNoNAOKLpjrsgqBt1silR2 JGd3OLKZOwdKN8rNGBBd8epi2x7VErgCDCQ7PAMM4AXQqhPpOzY42YnNFID2AENa J6ILzipmSKlsrbkoaHMK67Gq81ZbmIOzAtjwI+7BuE3pQ9/+YIvNcQOSJWE1ROrI q4QjGgafwHt5Q9HUwPWuoEFyHf69kQ07Z0GnXFtZfmhtS/NRmXsUF++Dpoy3m0kD OPkJTzEaj5N6/LVM1u9eLSvdltFSAIqeIM6b4WIaO06nEj8najaF0w+h5YdYYO2z QvFDBzQ6wzQmgVrEXjMAAwUL/2XygP3P2MxA7ZxbzuNoQC3Uq4R6hmNHZDJc9Gd4 C29N8sZZWnc+HU3Mbxdi+U0Uf3DfG+kY6SKzqBula1wM4p6Jd7mBuBJVPb1C2i/T plWKUSZCPUyGfEZPTJhBTkYeTN/6JFe5ApMXVBj8z6WAxk7I7nMeBWp+An0bIvvb cB2jFD6nluvMS+Z3wI9uYjjaviZo0N3a1itdm+kX5/4oNzN7azwJZUCcLOPuj/4R VtXJO99rD3j7TNkwcTWSvAQkk1VxVdt2ztfWKWX9k9jJaA66UkV/X0cgTEERgp0j Nzp+NEXapiCk2HjUZDKnJar8NfkBLlGR6LsJS66MOmVTTmWRId4QzDTPl23HjNlf ojyVg+MXPo3PEQZJsY5RhmPjgkHhaZnFnca1oyV1+GRNP0HKYbmHsURuoZWtH5pm 0Q7FObXmgG8KoOwOjvdxssJ/daRHsc3/2clGevUIgCL2ivAPFKPgjXOhe73H1tIl 0fO9RPMsT0L8HkK63bwLIGxsHokBHwQYAQMACQUCQzOaIgIbDAAKCRAQhsvXgLQr D2/eCACNDjiQTaPcGiAlB3WdwGaLolmPW1r1pfGSwIN2BjzEgwKWUOAYO4qzRwow IiGbflZqAGF2AUu6ockE6QX5L1Hszvb0Vp313ivpKjZtcaFdMp07usPNm2cMOP5b Y+BpMyjFnmFa11DqZXY3alQXcB4vzyv8emKOE9V8EU4hCDekDDK2yAXuRMXUoi1R pVapn4EkzntstcoHOYe39CAIdQuGv3UJGr5vc7aT87wL0+M7RVbS/LNb2+JZNndu L69/Pchvy5v3heckMvmEwzOnTHr83AlQQv1O2fH9KrM9pS2xo+NNHH7bdZU9pLz/ tur/RKip24Jlmprg4ymDV/UalvA/ =BwW0 -----END PGP PUBLIC KEY BLOCK----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3544 bytes Desc: S/MIME Cryptographic Signature Url : /pipermail/attachments/20050923/30bd2de0/smime.bin From broonie at sirena.org.uk Fri Sep 23 22:17:43 2005 From: broonie at sirena.org.uk (Mark Brown) Date: Fri Sep 23 22:17:44 2005 Subject: Problem with PGP key In-Reply-To: <4334541C.3090803@pengdows.com> References: <4334541C.3090803@pengdows.com> Message-ID: <20050923201743.GA17661@sirena.org.uk> On Fri, Sep 23, 2005 at 02:14:36PM -0500, Alaric Dailey wrote: > Over at CAcert we are having problems with a user trying to get his PGP > key signed. This PGP key works properly under PGP, but fails to even be > imported with any version of GPG we have tried. Can someone tell me what > the problem is, is this a bug, is this just a bad way to form the user > ID or what? This key: pub 2048R/80B42B0F 2005-09-23 Key fingerprint = 971D C3C0 2397 8113 2C7D 5145 1086 CBD7 80B4 2B0F uid JOHN W. MOORE III (GSWoT:US:26) sub 3072g/684C50FA 2005-09-23 appears to import just fine with at least GnuPG 1.4.1 but... > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: PGP 8.1 > Comment: ...it only does so once the empty comment field is repaired (either by removing it or filling it in). Without that GnuPG barfs before looking at the key data itself: | gpg: invalid armor header: Comment: -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : /pipermail/attachments/20050923/7125602b/attachment.pgp From jvender at owensboro.net Fri Sep 23 23:40:09 2005 From: jvender at owensboro.net (Joe Vender) Date: Sat Sep 24 01:26:01 2005 Subject: Problem with PGP key In-Reply-To: <4334541C.3090803@pengdows.com> References: <4334541C.3090803@pengdows.com> Message-ID: <6.2.5.4.0.20050923163700.03922780@owensboro.net> After removing the "Comment:" line, gnupg imported this key to my keyring. Key 80B42B0F: public key "JOHN W. MOORE III (GSWoT:US:26) " imported Total number processed: 1 imported: 1 At 02:14 PM 9/23/05, Alaric Dailey wrote: >Over at CAcert we are having problems with a user trying to get his >PGP key signed. This PGP key works properly under PGP, but fails to >even be imported with any version of GPG we have tried. Can someone >tell me what the problem is, is this a bug, is this just a bad way >to form the user ID or what? > >-----BEGIN PGP PUBLIC KEY BLOCK----- >Version: PGP 8.1 >Comment: > >mQELBEMzmUUBCACnhTj12NjPH7K6xwRKejFmUEaISxU31Ge/hEVrZTkdF+V7xgbS >pI+4vTnThYr1U4e8tbbFt2aDP/lCREBRN25uJmvTkisEL+9aIyenJA6hpJQY5D4X >flLe4qb5VjbFe0RbVeb0xxyF8aWRFRavLnOmW8Dnif165B93JGMeK/KteLCC4kR+ >LEmsuAKGAod1KMLl8gJemikYxRz0j5PEpV+jnbb/PbFNAgaFFOS7Bkg/qPf759WS >DMphaWoATRalW7KUtJd9One50/Ae3cEVUnGDC8jWyrEURtlVgSWgJN8r3DpeyDan >FvZQJ8WNiI+0nSP0nJOEss7XuW7QLItw6NefAAYptDpKT0hOIFcuIE1PT1JFIElJ >SSAoR1NXb1Q6VVM6MjYpIDxqb2hubW9vcmUzcmRAam9pbWFpbC5jb20+iQE6BBMB >AwAkAhsDBwsJCAcDAgEEFQIIAwQWAgMBAh4BAheABQJDM5+eAhkBAAoJEBCGy9eA >tCsPYOoH/3uTgttfoHITHSKG5WATC6xotfKwXGjj60dvURvDkMWSXcZY7foKMMd+ >LSKdWktQq3HEc+MJQExzAeQiXUM7VjNy+f80BzJbNIIK98Ft35YT23rU/6z2WKhy >CHjFhOysgsDX5ciFWonR/GVfLDhOyQGdA+IXNmUKlOwgDxMUQ7IuNi/LjaF8V5jL >NH+QEScDJlYAivDIoxPAM09m0JPJiLGweKcjjko2hE1Jz3mT0f+J+DuhHQ8tzuBj >+NoHoa/7Mm//huqkFULrhKpk3/EaNiLdcX1/fiLMRCu9ZMkx8gd/ejvIKMNoMeO2 >kYdTjrncd7EMtH83OSUpMqgQVwVKQECISgQTEQMACgUCQzOdmwMFAngACgkQnCmZ >hrerneXjrwCffGfopwA+H1YBdTySfXiwfzqqr4cAoIwmYMvtT2uy13i0D0/uGBi7 >aDDluQMNBEMzmiIQDADFf/BDrR25NRGDOlLwQj7/bYDwPGotpkpcIuCcwdWlzP9T >snSLH/0RZeo4TpCdL9KVfPmPOt7zYmHA7SW7Cc5AaPGyGnAy/uqoq8xnekcBcCvf >gFmSPUEJeDBNwUxOmuxCl9mZndSmubbaSxb7camZIyw0TaMctEZCiGn2vYRaIuWE >sCs9D2JHzrV9kmmk4q8KK0PAq5S/AskpomVkjUtIPzHNoNAOKLpjrsgqBt1silR2 >JGd3OLKZOwdKN8rNGBBd8epi2x7VErgCDCQ7PAMM4AXQqhPpOzY42YnNFID2AENa >J6ILzipmSKlsrbkoaHMK67Gq81ZbmIOzAtjwI+7BuE3pQ9/+YIvNcQOSJWE1ROrI >q4QjGgafwHt5Q9HUwPWuoEFyHf69kQ07Z0GnXFtZfmhtS/NRmXsUF++Dpoy3m0kD >OPkJTzEaj5N6/LVM1u9eLSvdltFSAIqeIM6b4WIaO06nEj8najaF0w+h5YdYYO2z >QvFDBzQ6wzQmgVrEXjMAAwUL/2XygP3P2MxA7ZxbzuNoQC3Uq4R6hmNHZDJc9Gd4 >C29N8sZZWnc+HU3Mbxdi+U0Uf3DfG+kY6SKzqBula1wM4p6Jd7mBuBJVPb1C2i/T >plWKUSZCPUyGfEZPTJhBTkYeTN/6JFe5ApMXVBj8z6WAxk7I7nMeBWp+An0bIvvb >cB2jFD6nluvMS+Z3wI9uYjjaviZo0N3a1itdm+kX5/4oNzN7azwJZUCcLOPuj/4R >VtXJO99rD3j7TNkwcTWSvAQkk1VxVdt2ztfWKWX9k9jJaA66UkV/X0cgTEERgp0j >Nzp+NEXapiCk2HjUZDKnJar8NfkBLlGR6LsJS66MOmVTTmWRId4QzDTPl23HjNlf >ojyVg+MXPo3PEQZJsY5RhmPjgkHhaZnFnca1oyV1+GRNP0HKYbmHsURuoZWtH5pm >0Q7FObXmgG8KoOwOjvdxssJ/daRHsc3/2clGevUIgCL2ivAPFKPgjXOhe73H1tIl >0fO9RPMsT0L8HkK63bwLIGxsHokBHwQYAQMACQUCQzOaIgIbDAAKCRAQhsvXgLQr >D2/eCACNDjiQTaPcGiAlB3WdwGaLolmPW1r1pfGSwIN2BjzEgwKWUOAYO4qzRwow >IiGbflZqAGF2AUu6ockE6QX5L1Hszvb0Vp313ivpKjZtcaFdMp07usPNm2cMOP5b >Y+BpMyjFnmFa11DqZXY3alQXcB4vzyv8emKOE9V8EU4hCDekDDK2yAXuRMXUoi1R >pVapn4EkzntstcoHOYe39CAIdQuGv3UJGr5vc7aT87wL0+M7RVbS/LNb2+JZNndu >L69/Pchvy5v3heckMvmEwzOnTHr83AlQQv1O2fH9KrM9pS2xo+NNHH7bdZU9pLz/ >tur/RKip24Jlmprg4ymDV/UalvA/ >=BwW0 >-----END PGP PUBLIC KEY BLOCK----- > > > > >_______________________________________________ >Gnupg-devel mailing list >Gnupg-devel@gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Mon Sep 26 10:02:08 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 26 10:06:41 2005 Subject: large file support in Win32 In-Reply-To: <5d7f074205092212485acd5447@mail.gmail.com> (Ryan Malayter's message of "Thu, 22 Sep 2005 14:48:37 -0500") References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> <5d7f07420509220545680ffbf7@mail.gmail.com> <87d5n1kpk7.fsf@wheatstone.g10code.de> <5d7f074205092212485acd5447@mail.gmail.com> Message-ID: <87slvsgsu7.fsf@wheatstone.g10code.de> On Thu, 22 Sep 2005 14:48:37 -0500, Ryan Malayter said: > Fatastic! Any idea what version it will be in? I was going to give > mingw/msys another try soon... this seems like a good opportunity. Or > is it just easier to do a cross-compile from Linux? Cross compiling using a Debian system will for sure be easier. I have uploaded an upx packed gpg binary for testing: ftp://ftp.gnupg.org/people/werner/scratch/gpg.exe (387k) ftp://ftp.gnupg.org/people/werner/scratch/gpg.exe.sig Note, that this just for testing and will be removed in form that location at some point. Salam-Shalom, Werner From ryan at malayter.com Mon Sep 26 15:18:30 2005 From: ryan at malayter.com (Ryan Malayter) Date: Mon Sep 26 15:19:04 2005 Subject: large file support in Win32 In-Reply-To: <87slvsgsu7.fsf@wheatstone.g10code.de> References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> <5d7f07420509220545680ffbf7@mail.gmail.com> <87d5n1kpk7.fsf@wheatstone.g10code.de> <5d7f074205092212485acd5447@mail.gmail.com> <87slvsgsu7.fsf@wheatstone.g10code.de> Message-ID: <5d7f07420509260618138779d7@mail.gmail.com> On 9/26/05, Werner Koch wrote: > Cross compiling using a Debian system will for sure be easier. I have > uploaded an upx packed gpg binary for testing: It looks like this is working well... thanks Werner! See the transcript of my test below. I created a different ~4.5 GB file for testing (the 45 GB file took too long). Do you think I need to do the same testing with a compressible file? - - - - - - - - - - - - - C:\>gpg --version gpg (GnuPG) 1.4.3-cvs C:\>dir e:\myfile.dat 09/26/2005 05:49 AM 4,697,620,480 myfile.dat C:\>gpg -vv -c -z 0 --cipher-algo AES -o c:\temp\myfile.dat.gpg e:\myfile.dat gpg: using cipher AES gpg: writing to `c:\temp\myfile.dat.gpg' C:\>gpg -vv -d -o e:\myfile2.dat c:\temp\myfile.dat.gpg :symkey enc packet: version 4, cipher 7, s2k 3, hash 2 salt 56008c37ea561c64, count 96 gpg: AES encrypted data :encrypted data packet: length: unknown mdc_method: 2 gpg: encrypted with 1 passphrase :literal data packet: mode b (62), created 1127739087, name="myfile.dat", raw data: unknown length gpg: original file name='myfile.dat' :mdc packet: length=20 gpg: decryption okay C:\>gpg --print-md sha1 e:\myfile.dat e:\myfile.dat: D494 D886 6589 96C3 B7DF F446 D9A3 80BD 6B37 ECAB C:\>gpg --print-md sha1 e:\myfile2.dat e:\myfile2.dat: D494 D886 6589 96C3 B7DF F446 D9A3 80BD 6B37 ECAB -- RPM ========================= All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous From wk at gnupg.org Tue Sep 27 08:22:25 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 27 08:26:41 2005 Subject: large file support in Win32 In-Reply-To: <5d7f07420509260618138779d7@mail.gmail.com> (Ryan Malayter's message of "Mon, 26 Sep 2005 08:18:30 -0500") References: <5d7f07420509212047b59cb0e@mail.gmail.com> <87d5n1mt4l.fsf@wheatstone.g10code.de> <5d7f07420509220545680ffbf7@mail.gmail.com> <87d5n1kpk7.fsf@wheatstone.g10code.de> <5d7f074205092212485acd5447@mail.gmail.com> <87slvsgsu7.fsf@wheatstone.g10code.de> <5d7f07420509260618138779d7@mail.gmail.com> Message-ID: <877jd3do7y.fsf@wheatstone.g10code.de> On Mon, 26 Sep 2005 08:18:30 -0500, Ryan Malayter said: > It looks like this is working well... thanks Werner! See the > transcript of my test below. I created a different ~4.5 GB file for > testing (the 45 GB file took too long). Thanks. > Do you think I need to do the same testing with a compressible file? No, I don't think that this is required. Shalom-Salam, Werner From kristian.fiskerstrand at kfwebs.net Sun Sep 25 03:56:00 2005 From: kristian.fiskerstrand at kfwebs.net (Kristian Fiskerstrand) Date: Fri Dec 16 11:58:56 2005 Subject: [gpgol] Problem reports Message-ID: <4335EB6D.7060208@kfwebs.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 894 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050925/3216c36c/signature.pgp