From bernhard at intevation.de Tue May 4 11:32:08 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 4 May 2010 11:32:08 +0200 Subject: =?iso-8859-1?q?_=5BGpg4win-devel=5D_Go_for_2=2E0=2E3=3F_=7F=28Re?= =?iso-8859-1?q?lease_2=2E0=2E2-rc2_as_2=2E0=2E2=3F=29?= In-Reply-To: <201004211207.20751.bernhard@intevation.de> References: <201004081148.26315.bernhard@intevation.de> <201004211207.20751.bernhard@intevation.de> Message-ID: <201005041132.08933.bernhard@intevation.de> Am Mittwoch, 21. April 2010 12:07:17 schrieb Bernhard Reiter: > > * We see some https://issues.kolab.org/issue4302 (Kleo keylisting hangs > > after using Kleo for a while (killing gpgsm helps)) and we do not know if > > this is more fequent with 2.0.2rc2 compared to 2.0.1. > > Does somebody see those hangs with 2.0.1, too? > > As you know, we did the 2.0.2 release. Frequency of this defect to show is > comparitively low and the advantages outweight the drawbacks. > > However it seems that we have found a source for the 4302 hang defect, > so we need to decide if we should do a 2.0.3. (The code is in trunk, we > need to see if 2.0.2+patches would fully resolve the issue.) As you can see from the issue4302, the current patch we have makes the hang less likely, but it is not completely gone. So what speaks for releasing 2.0.3 with the patch is that 2.1.0 is a bit away. On the other hand, the checks for is_socket() that are introduced by the patch could potentially resolve the hang completely if we find the remaining places where we need to apply the same technique. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100504/a6277d39/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100504/a6277d39/attachment.pgp From bernhard at intevation.de Tue May 4 11:33:12 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 4 May 2010 11:33:12 +0200 Subject: [Gpg4win-devel] Go for 2.0.3? (Release 2.0.2-rc2 as 2.0.2?) In-Reply-To: <201005041132.08933.bernhard@intevation.de> References: <201004081148.26315.bernhard@intevation.de> <201004211207.20751.bernhard@intevation.de> <201005041132.08933.bernhard@intevation.de> Message-ID: <201005041133.14946.bernhard@intevation.de> Am Dienstag, 4. Mai 2010 11:32:08 schrieb Bernhard Reiter: > Am Mittwoch, 21. April 2010 12:07:17 schrieb Bernhard Reiter: > > > * We see some https://issues.kolab.org/issue4302 (Kleo keylisting hangs > > > after using Kleo for a while (killing gpgsm helps)) and we do not know > > > if this is more fequent with 2.0.2rc2 compared to 2.0.1. > > > Does somebody see those hangs with 2.0.1, too? > > > > As you know, we did the 2.0.2 release. Frequency of this defect to show > > is comparitively low and the advantages outweight the drawbacks. > > > > However it seems that we have found a source for the 4302 hang defect, > > so we need to decide if we should do a 2.0.3. (The code is in trunk, we > > need to see if 2.0.2+patches would fully resolve the issue.) > > As you can see from the issue4302, the current patch we have makes the hang > less likely, but it is not completely gone. So what speaks for releasing > 2.0.3 with the patch is that 2.1.0 is a bit away. On the other hand, the > checks for is_socket() that are introduced by the patch could potentially > resolve the hang completely if we find the remaining places where we need > to apply the same technique. And there is one more possible defect with a modern Outlook 2003 version on XP that Emanuel is going to test to see if 2.0.2+patch has it. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100504/aebde3fc/smime.bin From bernhard at intevation.de Tue May 4 12:49:06 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 4 May 2010 12:49:06 +0200 Subject: [Gpg4win-devel] 2.1.0 goal build sources Message-ID: <201005041249.13971.bernhard@intevation.de> One goal for the upcoming 2.1.0 release is that we want to have the new GnuPG 2.1 framework, with the dynamically loaded libassuan, the new OpenPGP secret keyhandling and stuff. In addition we want to add to the installer that we can build many packages from source from the packages that are now in as binaries. Currently SVN trunk, to become 2.1 does not run, as we are in the middle of doing this change. The Gnupg folks are doing the crypto improvements this week in the core Gnupg. If someone wants to take over sourcifying a few of the non-crypto libraries for the cross build, this would be a cool junior task for people to help and get into Gpg4win packaging development. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100504/fe978c01/attachment.pgp From emanuel at intevation.de Tue May 11 11:04:44 2010 From: emanuel at intevation.de (Emanuel =?iso-8859-15?q?Sch=FCtze?=) Date: Tue, 11 May 2010 11:04:44 +0200 Subject: [Gpg4win-devel] Go for 2.0.3? (Release 2.0.2-rc2 as 2.0.2?) In-Reply-To: <201005041133.14946.bernhard@intevation.de> References: <201004081148.26315.bernhard@intevation.de> <201005041132.08933.bernhard@intevation.de> <201005041133.14946.bernhard@intevation.de> Message-ID: <201005111104.47717.emanuel@intevation.de> On 04.05.2010 11:33, Bernhard Reiter wrote: > And there is one more possible defect with a modern Outlook 2003 version > on XP that Emanuel is going to test to see if 2.0.2+patch has it. I found this critical issue with gpg4win-2.0.2 and gpg4win-2.0.3-svn1404 (incl. is-socket-patch): kolab/issue4378 (gpgsm process blocks pinentry window if sending a smime signed message with gpgol) [1] Can anybody confirm this behavior? Regards Emanuel [1] https://issues.kolab.org/issue4378 -- Emanuel Sch?tze | ++49-541-33 50 83 - 746 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100511/45794dca/attachment.pgp From bernhard at intevation.de Fri May 21 12:03:22 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 May 2010 12:03:22 +0200 Subject: [Gpg4win-devel] X509 Root certificates and trusting them Message-ID: <201005211203.25415.bernhard@intevation.de> Just got more user feedback that people feel that S/MIME is not working because they do not manage to a) get root certificates to be trustworthy. b) do not disable crl checks when behind a bad firewall. It is my conviction that we should keep the allow-mark-trusted-option off by default as this already is the workaround. The recommended way for a production X509 /CMS system is that a list of trusted X509 root certificates is maintained by the administrator of the system directlty for dirmngr and possibly the global gpgsm. However users do not seem to find our already placed instructions for this. So what are our options to solve a)? i) Place information more prominently! Like: i.1) earlier in the readme, i.2) on the website while downloading i.3.) during the installer ii) Phrase instructions better at all places iii) improve the error message if that condition is met to point people towards the explanation. iv) possibly improve the certification manager to hint towards the condiation? Important: The recommended way must be explained and reasoned for. The workaround (using allow-mark-trusted) must also be explained as what it is: A workaround. Marcus, Emanuel, Werner, marc, can you please suggest improvements for i),ii),iii), iv)? Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100521/8990b8c2/smime.bin From marcus.brinkmann at ruhr-uni-bochum.de Sun May 23 00:58:21 2010 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 23 May 2010 00:58:21 +0200 Subject: [Gpg4win-devel] X509 Root certificates and trusting them In-Reply-To: <201005211203.25415.bernhard@intevation.de> References: <201005211203.25415.bernhard@intevation.de> Message-ID: <4BF8618D.8040302@ruhr-uni-bochum.de> On 05/21/2010 12:03 PM, Bernhard Reiter wrote: > i) Place information more prominently! > Like: i.1) earlier in the readme, > i.2) on the website while downloading > i.3.) during the installer > ii) Phrase instructions better at all places > iii) improve the error message if that condition is met to point people > towards the explanation. > iv) possibly improve the certification manager to hint towards the condiation? > > Important: The recommended way must be explained and reasoned for. > The workaround (using allow-mark-trusted) must also be explained > as what it is: A workaround. > > Marcus, Emanuel, Werner, marc, can you please suggest improvements for > i),ii),iii), iv)? ii) should be done anyway, but will not be effective to solve this particular problem. iii) would be good to have, but may pose technical challenges (for example, detecting that the problem is a firewall rather than a different type of network problem may be very hard, but I am not an expert). And, in any case, error messages are not sufficient here, as some of the issues are policy issues and not error-related, so the trigger that causes errors to be signaled is missing. i) is completely useless: Nobody but me reads READMEs (that's a fact). Messages at download and installation times are untimely and we don't even know if they are shown to the right person (or any person at all). Misdirected messages are worse than silence. I feel quite strongly about this. Software that tells me to do something later which could just as well be done by the software at that later time automatically is totally lame. iv) is a good compromise: It is technically trivial, but not untimely and can be enriched in many ways (for example by offering to automatically set good options for a certain use case scenario). As a first approximation, one could let Kleopatra self-test for lack of allow-mark-trusted resp. lack of disable crl checks and pop up an explanation of these and why they might be useful. Centrally administrated systems should be able to suppress those informational texts by setting some options. It would be sufficient to document that in a README for administrators. Thanks, Marcus From bernhard at intevation.de Tue May 25 12:38:46 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 May 2010 12:38:46 +0200 Subject: [Gpg4win-devel] X509 Root certificates and trusting them In-Reply-To: <4BF8618D.8040302@ruhr-uni-bochum.de> References: <201005211203.25415.bernhard@intevation.de> <4BF8618D.8040302@ruhr-uni-bochum.de> Message-ID: <201005251238.47383.bernhard@intevation.de> Am Sonntag, 23. Mai 2010 00:58:21 schrieb Marcus Brinkmann: > On 05/21/2010 12:03 PM, Bernhard Reiter wrote: > > i) Place information more prominently! > > Like: i.1) earlier in the readme, > > i.2) on the website while downloading > > i.3.) during the installer > > ii) Phrase instructions better at all places > > iii) improve the error message if that condition is met to point people > > towards the explanation. > > iv) possibly improve the certification manager to hint towards the > > condiation? > > > > Important: The recommended way must be explained and reasoned for. > > The workaround (using allow-mark-trusted) must also be explained > > as what it is: A workaround. > > > > Marcus, Emanuel, Werner, marc, can you please suggest improvements for > > i),ii),iii), iv)? > > ii) should be done anyway, but will not be effective to solve this > particular problem. I think it will help because currently people seem to not understand what the recommended way is and why this is the recommended way. > iii) would be good to have, but may pose technical > challenges (for example, detecting that the problem is a firewall rather > than a different type of network problem may be very hard, but I am not an > expert). And, in any case, error messages are not sufficient here, as some > of the issues are policy issues and not error-related, so the trigger that > causes errors to be signaled is missing. I think there is a defect here (at least in gpgsm 2.0.14) that will show "certificate missing", in a missleading situation where the certificate itself is there, but not trusted somehow. And the audit-log can have more extended messages, explaining more of the situations that could also happening. > i) is completely useless: Nobody > but me reads READMEs (that's a fact). Messages at download and > installation times are untimely and we don't even know if they are shown to > the right person (or any person at all). Misdirected messages are worse > than silence. I feel quite strongly about this. Software that tells me to > do something later which could just as well be done by the software at that > later time automatically is totally lame. I also feel strongly about this, if the alternative is to set the workaround allow-mark-trusted to "true" I'd rather improve the documentation. And yes, documentation is getting read, if the message is very strongly placed (and yes this obstructs the user interface somewhat, so it will be a compromise). > iv) is a good compromise: It is technically trivial, but not untimely and > can be enriched in many ways (for example by offering to automatically set > good options for a certain use case scenario). As a first approximation, > one could let Kleopatra self-test for lack of allow-mark-trusted resp. lack > of disable crl checks and pop up an explanation of these and why they might > be useful. I do not think this will be strong enough, the idea is when do to what. Personally I believe we need to use all measures. > Centrally administrated systems should be able to suppress those > informational texts by setting some options. It would be sufficient to > document that in a README for administrators. Agreed of course. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100525/ae143445/attachment.pgp From vilc at bol.com.br Thu May 27 03:38:40 2010 From: vilc at bol.com.br (Vilc Queupe Rufino) Date: Wed, 26 May 2010 22:38:40 -0300 Subject: [Gpg4win-devel] build source from SVN Message-ID: I tried build from SVN, but received the follow error: make[4]: Entering directory `.../trunk/doc/manual' make[4]: *** No rule to make target `indexstyle.ist', needed by `gpg4win-compendium-de.pdf'. Stop. make[4]: Leaving directory `.../trunk/doc/manual' make[3]: *** [all] Error 2 I believe this is to use LaTex to make a manual, probably my LaTex environment is wrong, but How can I run 'make' without to compile manuals??? -- :-) Vilc Q. Rufino -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100526/c1dd60d9/attachment.html From emanuel at intevation.de Fri May 28 09:15:25 2010 From: emanuel at intevation.de (Emanuel =?iso-8859-15?q?Sch=FCtze?=) Date: Fri, 28 May 2010 09:15:25 +0200 Subject: [Gpg4win-devel] build source from SVN In-Reply-To: References: Message-ID: <201005280915.25945.emanuel@intevation.de> Hi Vilc, On 27.05.2010 03:38, Vilc Queupe Rufino wrote: > I tried build from SVN, but received the follow error: please try again (svn r1449). The doc build works now. I forgot to commit the indexstyle.ist file. Sorry. Regards, Emanuel -- Emanuel Sch?tze | ++49-541-33 50 83 - 746 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner