From bernhard at intevation.de Thu Apr 8 11:48:22 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 8 Apr 2010 11:48:22 +0200 Subject: [Gpg4win-devel] Release 2.0.2-rc2 as 2.0.2? Message-ID: <201004081148.26315.bernhard@intevation.de> The current development question we are facing is: Should we release 2.0.2rc2 as 2.0.2 now? Pros: * There is a bit of improvement in 2.0.2rc2 over 2.0.1. Especially on the Kleo side and better looks. See http://lists.wald.intevation.org/pipermail/gpg4win-announce/2010-March/000041.html * 2.0.1 was released a while ago, in september 2009. * 2.1.0 has some more changes and we need at least one testing release and some more testing. So 2.1.0 is a bit away currently (counted in weeks.) Cons: * 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? * The new mode for selection of in some situations does not bring up a selection dialog, see https://issues.kolab.org/issue4197 (Conflict in matching of email addresses doesn't open certificate select dialog) We still miss the configuration option to switch the new mode off. In my personal view withi would not block a release. 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/20100408/c3ee779c/attachment.pgp From bernhard at intevation.de Fri Apr 9 14:37:32 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 9 Apr 2010 14:37:32 +0200 Subject: [Gpg4win-devel] ETA on English Documentation? In-Reply-To: <1270044741.23359.7.camel@drew-northup.unet.maine.edu> References: <1270044741.23359.7.camel@drew-northup.unet.maine.edu> Message-ID: <201004091437.33043.bernhard@intevation.de> Am Mittwoch, 31. M?rz 2010 16:12:21 schrieb Drew Northup: > Is there an ETA on English language documentation? You saw Emanuel's post about the compendium release: http://lists.wald.intevation.org/pipermail/gpg4win-users-en/2010-April/000464.html Am Donnerstag, 1. April 2010 15:22:37 schrieb Emanuel Sch?tze: The current compendium is the last pre-release. The final version 3.0.0 of the German Compendium is scheduled for april/may 2010. Afterwards the translation into English will start! Translations into other language are very welcome! > This isn't enormously > useful if only the techie crowd (outside of German-speaking lands) can > make it work. If you have questions how to make it work, let us know, e.g. via the users-* lists. Thanks for staying interested in this. I agree that the documentation is dragging along for a long while now which it usually shouldn't. 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/20100409/e6cd8a5c/attachment.pgp From bernhard at intevation.de Fri Apr 9 14:40:05 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 9 Apr 2010 14:40:05 +0200 Subject: [Gpg4win-devel] ClawsMail hangs signing if card is present In-Reply-To: <20100324085642.000010f7@unknown> References: <20100324085642.000010f7@unknown> Message-ID: <201004091440.06337.bernhard@intevation.de> Am Mittwoch, 24. M?rz 2010 08:56:42 schrieb Philipp H. v. Loewenfeld: > I'm using my OpenPGP-card V2.0 (in an SCR201 on a WinXP Tablet > PC Edition) to sign mails from ClawsMail, which worked perfectly well > until installing the current GPG4Win 2.0.2 RC2. Did you use 2.0.1 of Gpg4win before? > Now ClawsMail hangs as soon as I click send if the OpenPGP card is > present already -- the pinentry dialog comes up as soon as ClawsMail is > killed. Only if the card is not present a dialog asks me to insert the > card and the message is signed, sent and stored. We are working on a number of smartcard improvements for Gpg4win 2.1.0 (within this quarter I hope we have a release candidate). The usual step for analysing your issue would be to try the stuff on the command line first and see if the issue is reproducable there. 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/20100409/670a2bd0/attachment.pgp From bernhard at intevation.de Wed Apr 14 10:54:57 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 14 Apr 2010 10:54:57 +0200 Subject: [Gpg4win-devel] Fwd: packaging Free Software on Windows: Re: Microsoft CoApp Message-ID: <201004141054.58239.bernhard@intevation.de> For your information: There is a new initative for providing a packaging system for Free Software on windows backed by Microsoft. In the long term this could be interesting for Gpg4win in the future. For the short term they do not have a product and for the mid term our cross compiled NSIS installer is quite complete currently. The KDE windows people started a discussion here: http://mail.kde.org/pipermail/kde-windows/2010-April/thread.html It might be the time to now restate our requirements for such a system, including the mingw and cross compilation options. Best, Bernhard -------------- next part -------------- An embedded message was scrubbed... From: Bernhard Reiter Subject: packaging Free Software on Windows: Re: Microsoft CoApp Date: Mon, 12 Apr 2010 15:37:26 +0200 Size: 5073 Url: http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100414/9f3b8276/attachment.mht -------------- 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/20100414/9f3b8276/attachment.pgp From colin at colino.net Wed Apr 14 11:15:15 2010 From: colin at colino.net (Colin Leroy) Date: Wed, 14 Apr 2010 11:15:15 +0200 Subject: [Gpg4win-devel] Fwd: packaging Free Software on Windows: Re: Microsoft CoApp In-Reply-To: <201004141054.58239.bernhard@intevation.de> References: <201004141054.58239.bernhard@intevation.de> Message-ID: <20100414111515.0e945a6a@paperstreet.colino.net> On Wed, 14 Apr 2010 10:54:57 +0200, Bernhard Reiter wrote: Hi, > It might be the time to now restate our requirements for such a > system, including the mingw and cross compilation options. The current system has the advantage of not requiring Windows to build a gpg4win package, which I find nice as a complete non-user of Windows :) -- Colin From marcus.brinkmann at ruhr-uni-bochum.de Wed Apr 14 14:26:11 2010 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 14 Apr 2010 14:26:11 +0200 Subject: [Gpg4win-devel] Fwd: packaging Free Software on Windows: Re: Microsoft CoApp In-Reply-To: <201004141054.58239.bernhard@intevation.de> References: <201004141054.58239.bernhard@intevation.de> Message-ID: <4BC5B463.5030608@ruhr-uni-bochum.de> On 04/14/2010 10:54 AM, Bernhard Reiter wrote: > For your information: There is a new initative for providing a packaging > system for Free Software on windows backed by Microsoft. Actually it's backed by one developer at Microsoft, who says: "Regardless, this isn't Microsoft's project--it's mine. They just happen to pay me to work on it." This may actually be a good thing. > In the long term this could be interesting for Gpg4win in the future. The project has a very wide scope, similar in scope as the Debian project. > It might be the time to now restate our requirements for such a system, > including the mingw and cross compilation options. One of the stated goals is: "# Be Windows developer friendly. No forcing of building using ?make?, but rather taking advantage of the nifty IDEs we already have. " Well. The project is big on standards (there is hardly anything in the web pages yet, but what is there are policies rather than implementation). Conforming to the standards as they are indicated at this early stage seems doable with some effort. I doubt it is worth it, though: If the project succeeds, gpg4win will probably become obsolete. If it doesn't succeeded, it doesn't help. Thanks, Marcus From wk at gnupg.org Wed Apr 14 15:13:49 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Apr 2010 15:13:49 +0200 Subject: [Gpg4win-devel] Fwd: packaging Free Software on Windows: Re: Microsoft CoApp In-Reply-To: <201004141054.58239.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 14 Apr 2010 10:54:57 +0200") References: <201004141054.58239.bernhard@intevation.de> Message-ID: <87ljcqkwhe.fsf@vigenere.g10code.de> On Wed, 14 Apr 2010 10:54, bernhard at intevation.de said: > It might be the time to now restate our requirements for such a system, > including the mingw and cross compilation options. If we are interested in deploying a new packaging system, I strongly suggest to base it on NixOS. It is the most advanced packing system we have and makes the life for the maintainers and the sysadmins much easier. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From philipp at loewenfeld.de Sat Apr 10 10:34:50 2010 From: philipp at loewenfeld.de (Philipp H. v. Loewenfeld) Date: Sat, 10 Apr 2010 10:34:50 +0200 Subject: [Gpg4win-devel] ClawsMail hangs signing if card is present In-Reply-To: <201004091440.06337.bernhard@intevation.de> References: <20100324085642.000010f7@unknown> <201004091440.06337.bernhard@intevation.de> Message-ID: <20100410103450.00002209@unknown> Hi, Bernhard Reiter schrieb am Fr, 2010-04-09: > Am Mittwoch, 24. M?rz 2010 08:56:42 schrieb Philipp H. v. Loewenfeld: > > I'm using my OpenPGP-card V2.0 (in an SCR201 on a WinXP Tablet > > PC Edition) to sign mails from ClawsMail, which worked perfectly > > well until installing the current GPG4Win 2.0.2 RC2. > Did you use 2.0.1 of Gpg4win before? yes. I thought it was a problem of Claws Mail since being locked is a rather common state of this betaesque piece of software (e. g. while fetching mails, closing folders, ...) and there is no problem signing with gpg2 on the command line. But replacing pinentry-qt4 with pinentry-w32 solves the problem. -- Best regards Philipp H?ffer v. Loewenfeld Bei einer k?rzlichen Umfrage antworteten 76% der Befragten auf die Frage: "Wie lautet der Satz des Pythagoras?" mit "Ich habe keine Ahnung!" - Ich hatte ihn anders in Erinnerung, aber wenn die Mehrheit es sagt ... (Uli Stein) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100410/bcd32d12/signature.pgp From CarstenC.Haucke at web.de Wed Apr 14 14:23:01 2010 From: CarstenC.Haucke at web.de (CarstenC.Haucke@web.de) Date: Wed, 14 Apr 2010 14:23:01 +0200 (CEST) Subject: [Gpg4win-devel] Sicherheit der Downloads von der Website http://www.gpg4win.de/ Message-ID: <28985736.84517.1271247781644.JavaMail.fmail@mwmweb019> Hallo Entwickler-Team, ich finde das Projekt GPG4win und insbesondere Eure Arbeit grandios und m?chte mich als eifriger Nutzer von GPG4win daf?r bei Euch bedanken. Sehr gut finde ich auch, dass Ihr die M?glichkeit gebt, die Integrit?t der Downloads anhand von Signaturen und Hash-Werten zu pr?fen. Da k?nnen sich andere OpenSource-Projekte aber vor allem die meisten kommerziellen Anbieter noch eine ganz dicke Scheibe von abschneiden! Eine Sicherheits-L?cke gibt es aber n.m.M. aber dennoch, auf die ich Euch hiermit gern hinweisen m?chte: Ihr vertraut als Basis der Downloads und damit auch der ?berpr?fungsprozesse auf das leider bislang nicht sichere Domain Name System: Der User gibt (bestenfalls) Eure URL ein oder folgt einem Link unbekannter Quelle und meint dann guten Glaubens, nach Download der Programme und der zugeh?rigen Pr?fmerkmale von Eurer Website und Pr?fung der Programm-Downloads mit den von der gleichen Site herunter geladenen Pr?fsignaturen auf der sicheren Seite zu sein - kann sich dessen aber meiner Meinung nach nicht sicher sein, solange sich die Website nicht auch erfolgreich authenifiziert, z.B. durch eine entsprechendes SSL-Zertifikat. Ohne die mit einem solchen Zertifikat entsprechend verbundene Betreiber-Information und der damit gesicherten Identit?t des Betreibers der Website kann der User durch seine - ggf. umgeleitete oder anderweitig manipulierte DNS-Abfrage bzw. die entsprechend(e) - gefakte - Antwort darauf im heute noch nicht sicheren DNS durchaus auf eine - zwar nur mit einigem Aufwand auch im DNS entsprechend erreichbar zu installierende, aber dennoch durchaus m?glich(e) - gefakte Website gef?hrt worden sein bzw. werden, auf der ihm dann ggf. neben gegen?ber Euren Programm-Ver?ffentlichungen ver?nderten Programm-Dateien auch die zu den gegen?ber den Originalen ge?nderten Programmen geh?rigen anderen Pr?fmerkmale angeboten werden. Euer vermutliches Gegenargument wird nun wohl sein: Aber da ist immer noch die OpenPG/GnuPG-Signatur (ID 0x1CE0C630), die nach Web-of-Trust-Ansatz von so vielen anderen unterschrieben - also Cross-signiert - wurde. Schon richtig, aber solange ich als User keinen - nein, nicht nur einen - sondern nach Vier-Augen-Prinzip nicht wenigstens zwei der Unterzeichner dieses SELFSIGNED ZERTIFICATE pers?nlich kenne und vertraue - bleibt diesem zu vertrauen immer noch ein Wagnis und Risiko. Da setze ich doch mein Vertrauen lieber in ein SSL-Zertifikat von einer nicht-kommerziellen, aber "?ffentlichen" CA wie CAcert. Wie denkt Ihr dar?ber, Euch ein solches SSL-Zertifikat bei CAcert.org zu holen und auf dem Webserver einzusetzen. Positiver Nebeneffekt: Die Downloads k?nnten per HTTPS (SSL-verschl?sselt) erfolgen und die Pr?fprozeduren k?nnten ggf. entfallen. Freue ich auf Eure Antwort und w?nsche uns gemeinsam weiterhin viel Erfolg beim Sichern jeder Internet-Kommunikation. Mit freundlichen Gr??en, Carsten C. Haucke -- HINWEIS: Seit 1.1.2008 bzw. 2009 wurden und werden in Deutschland trotz eines dieses untersagenden h?chstrichterlichen Urteils m?glicherweise immer noch s?mtliche Kommunikationsverbindungsdaten f?r 6 Monate auf Vorrat erfasst. DIESE DATEN W(E/U)RDEN SEIT 1.1.09 - zumindest ab Providergr??e 1.000 Postf?cher - AUCH WIRKLICH GESPEICHERT! Try to keep safe, because it is not a crime: KEEP YOUR SECRETS AND PRIVACY - And remember this: NOT ONLY REALLY BIG BROTHERS ARE WATCHING YOU & ME. Bitte verstehen Sie meine Vorsicht als St?rke: Nur weil Sie und ich NICHT PARANOID sind, hei?t das wirklich nicht, dass - aus welchem nichtigen oder kommerziellen Grund auch immer - nicht doch irgend jemand "hinter Ihnen und/ oder mir bzw. unseren Daten oder dem ggf. nicht trivialem Inhalt unserer Kommunikation her ist". Deshalb: Signieren und Verschl?sseln Sie Ihre gesamte Internet-Kommunikation - und das m?glichst l?ckenlos! Dieser E-Mail wurde zu Ihrer und meiner Sicherheit digital signiert und f?hrt den ?ffentlichen Schl?ssel des Signatur-Zertifikats nach X.509 V3 mit, Sie k?nnen daher mit nahezu jedem E-Mail-System und -Client bereits verschl?sselt darauf antworten. M?chten Sie vertraulich - d.h., mittels vor Kenntnisnahme und Ver?nderung durch Dritte w?hrend der ?bertragung gesch?tzter Nachrichten mit mir zu kommunizieren, so antworten Sie bitte mit verschl?sselter und von Ihnen ebenfalls m?glichst S/MIME-signierter E-Mail. F?r die Verschl?sselung Ihrer Antwort h?ngen dieser E-Mail der ?ffentliche Schl?ssel des von mir zur Signatur verwendeten S/MIME-Zertifikats sowie zur alternativen Benutzung in der Datei 0x1AFE967E.asc auch mein ?ffentlicher PGP-Schl?ssel (ID 0x1AFE967E) an, der durch die Signatur dieser E-Mail vor Ver?nderung gesch?tzt und authentifiziert wird. Das zur Signatur verwendete Zertifikat kann mit seiner Seriennummer auf https://trust.web.de gepr?ft werden. Bitte benutzen Sie zur Signatur m?glichst ebenso ein von einem ?ffentlichen Trustcenter ausgestelltes und online gegen diese CA pr?fbares Zertifikat oder einen mit einer nicht kommerziellen Software wie PGP 2.6.3i bzw. GnuPG mit Versionsstand von mindestens V1.2.2 generierten Keyring und h?ngen Sie dessen ?ffentlichen Schl?ssel Ihrer E-Mail an. Die Verschl?sselung sollte, wenn w?hlbar, mit mindestens 168 Bit oder besser, mit 256 Bit, erfolgen. Beachten Sie bitte auch: Die Root-/ bzw. Sub-Root-Zertifikate des Trustcenter der WEB.DE AG sind ggf. noch nicht im Zertifikatespeicher Ihres Internet-Browsers hinterlegt. Das f?hrt ggf. zur Anzeige eines vermeindlichen Zertifikatfehlers durch den Mail-Client, da dessen Zertifikatpr?fung ggf. ins Leere l?uft. Um Dem dauerhaft abzuhelfen, laden Sie bitte die Sub-/ Root-Zertifikate der Mail-CA der WEB.DE AG per HTTPS vom SSL-Server https://trust.web.de herunter und installieren bzw. lassen Sie diese im Zertifikatspeicher Ihres E-Mail-Systems/ -Clients installieren. Vielen Dank f?r Ihre Unterst?tzung sicherer Kommunikation ?ber das Internet. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x1AFE967E.asc Type: application/octet-stream Size: 1722 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100414/5e40704b/0x1AFE967E.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1763 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100414/5e40704b/smime.bin From bernhard at intevation.de Tue Apr 20 12:53:01 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 20 Apr 2010 12:53:01 +0200 Subject: [Gpg4win-devel] Sicherheit der Downloads von der Website http://www.gpg4win.de/ In-Reply-To: <28985736.84517.1271247781644.JavaMail.fmail@mwmweb019> References: <28985736.84517.1271247781644.JavaMail.fmail@mwmweb019> Message-ID: <201004201253.05159.bernhard@intevation.de> Am Mittwoch, 14. April 2010 14:23:01 schrieb CarstenC.Haucke at web.de: > Hallo Entwickler-Team, Hi Carsten, [Emanuel hat Deine Email auf die Entwickler-Liste umgeleitet. Hier sprechen wir Englisch, deshalb antworte ich mal auf Englisch. Solltest Du Englisch nicht verstehen, dann schreib mir nochmals pers?nlich.] > ich finde das Projekt GPG4win und insbesondere Eure Arbeit grandios und > m?chte mich als eifriger Nutzer von GPG4win daf?r bei Euch bedanken. Sehr > gut finde ich auch, dass Ihr die M?glichkeit gebt, die Integrit?t der > Downloads anhand von Signaturen und Hash-Werten zu pr?fen. Da k?nnen sich > andere OpenSource-Projekte aber vor allem die meisten kommerziellen > Anbieter noch eine ganz dicke Scheibe von abschneiden! Thanks for the praise! You are welcome! (Carsten likes our Gpg4win Initiative and our idea of using signatures and hash values for checking integrety. He sees still a security gap in the unsecure DNS to our webpage and recommends using https with a CAcert.org certificate.) > Eine Sicherheits-L?cke gibt es aber n.m.M. aber dennoch, auf die ich Euch > hiermit gern hinweisen m?chte: Ihr vertraut als Basis der Downloads und > damit auch der ?berpr?fungsprozesse auf das leider bislang nicht sichere > Domain Name System: Der User gibt (bestenfalls) Eure URL ein oder folgt > einem Link unbekannter Quelle und meint dann guten Glaubens, nach Download > der Programme und der zugeh?rigen Pr?fmerkmale von Eurer Website und > Pr?fung der Programm-Downloads mit den von der gleichen Site herunter > geladenen Pr?fsignaturen auf der sicheren Seite zu sein - kann sich dessen > aber meiner Meinung nach nicht sicher sein, solange sich die Website nicht > auch erfolgreich authenifiziert, z.B. durch eine entsprechendes > SSL-Zertifikat. It is true that a fake DNS attack might lead people to a rouge gpg4win.org webpage and they will have a hard time time to discover this. > Ohne die mit einem solchen Zertifikat entsprechend verbundene > Betreiber-Information und der damit gesicherten Identit?t des Betreibers > der Website kann der User durch seine - ggf. umgeleitete oder anderweitig > manipulierte DNS-Abfrage bzw. die entsprechend(e) - gefakte - Antwort > darauf im heute noch nicht sicheren DNS durchaus auf eine - zwar nur mit > einigem Aufwand auch im DNS entsprechend erreichbar zu installierende, aber > dennoch durchaus m?glich(e) - gefakte Website gef?hrt worden sein bzw. > werden, auf der ihm dann ggf. neben gegen?ber Euren > Programm-Ver?ffentlichungen ver?nderten Programm-Dateien auch die zu den > gegen?ber den Originalen ge?nderten Programmen geh?rigen anderen > Pr?fmerkmale angeboten werden. > > Euer vermutliches Gegenargument wird nun wohl sein: Aber da ist immer noch > die OpenPG/GnuPG-Signatur (ID 0x1CE0C630), die nach Web-of-Trust-Ansatz von > so vielen anderen unterschrieben - also Cross-signiert - wurde. Schon > richtig, aber solange ich als User keinen - nein, nicht nur einen - sondern > nach Vier-Augen-Prinzip nicht wenigstens zwei der Unterzeichner dieses > SELFSIGNED ZERTIFICATE pers?nlich kenne und vertraue - bleibt diesem zu > vertrauen immer noch ein Wagnis und Risiko. Da setze ich doch mein > Vertrauen lieber in ein SSL-Zertifikat von einer nicht-kommerziellen, aber > "?ffentlichen" CA wie CAcert. > > Wie denkt Ihr dar?ber, Euch ein solches SSL-Zertifikat bei CAcert.org zu > holen und auf dem Webserver einzusetzen. Positiver Nebeneffekt: Die > Downloads k?nnten per HTTPS (SSL-verschl?sselt) erfolgen und die > Pr?fprozeduren k?nnten ggf. entfallen. Using https would be only a small improvement because it is quite easy for a rouge website to also get a valid certificate. We plan to sign the installer so that windows will check the authentification of the .exe file directly. 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/20100420/4d66a90b/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Tue Apr 20 14:03:04 2010 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 20 Apr 2010 14:03:04 +0200 Subject: [Gpg4win-devel] Sicherheit der Downloads von der Website http://www.gpg4win.de/ In-Reply-To: <201004201253.05159.bernhard@intevation.de> References: <28985736.84517.1271247781644.JavaMail.fmail@mwmweb019> <201004201253.05159.bernhard@intevation.de> Message-ID: <4BCD97F8.9020307@ruhr-uni-bochum.de> Instead of replying point by point, let me try a summary: 1) DNS is not the weak link in the chain here. Attacks are possible but not easy. Also, it is critical infrastructure of the internet and many people are working on fixing its problems for us without us doing anything. Last but not least, we do not rely on DNS for authentication. So there is no problem here, at all. 2) Verifying the authenticity of the web server is not the same as verifying the authenticity of the installer package. The installer package can be distributed in other media, or the web server could be attacked and the file changed. It is important to be able to verify the installer independently of the web page. To be clear: The exe file is signed by a private key that is held by a developer. The web server private key is held by the web server on a public network. The exe signature tells you that the file passed unchanged from the developer's hand to yours. The web server's signature only tells you it passed unchanged from the web server to your browser. 3) CAcert is not part of the trusted list of certificate authorities for many vendors. So the user would still need to be able to make a trust decision, but now even more groups and indirections are involved. 4) The web of trust based on OpenPGP is much more reliable and resilient than X.509 certificates and certificate authorities. You say you need 4 eyes to trust an OpenPGP signature by Werner Koch, but you are willing to trust signatures made by CAcert? Makes no sense to me. You are probably underestimating the strength of OpenPGP and overestimating the strength of X.509 certificates for HTTPS. Even more bluntly: HTTPS is a *joke*. [1] 5) In response to Bernhard, who said that we will sign the exe file: In the light of how broken HTTPS is, I would be extremely reluctant to assign any security value to signed exe files. Chance is that the implementation is as buggy as for web browsers, and of course all criticism of the public CA system apply here as well. I consider signing exe files a usability measure, not a security measure (it get rids of a warning). Thanks, Marcus [1] This deserves an explanation. If you think that X.509 certificates provide a value for HTTPS, then please answer a simple question for me: When is a X.509 certificate valid for a given domain? See the SSL attacks by Dan Kaminsky and Moxie Marlinspike from last year for details. From wk at gnupg.org Tue Apr 20 09:36:54 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Apr 2010 09:36:54 +0200 Subject: [Gpg4win-devel] Sicherheit der Downloads von der Website http://www.gpg4win.de/ In-Reply-To: <28985736.84517.1271247781644.JavaMail.fmail@mwmweb019> (CarstenC Haucke's message of "Wed, 14 Apr 2010 14:23:01 +0200 (CEST)") References: <28985736.84517.1271247781644.JavaMail.fmail@mwmweb019> Message-ID: <87ocheinhl.fsf@vigenere.g10code.de> On Wed, 14 Apr 2010 14:23, CarstenC.Haucke at web.de said: > Euer vermutliches Gegenargument wird nun wohl sein: Aber da ist immer > noch die OpenPG/GnuPG-Signatur (ID 0x1CE0C630), die nach > Web-of-Trust-Ansatz von so vielen anderen unterschrieben - also Das w?re ein Argument. Ich unterzeichne die Downloads immer selbst und der Fingerprint meines Keys ist nun wirklich mehr als gut bekannt. Falls da mal ein Problem aufkommen sollte wird das schnell durch die Presse geistern. Desweiteren posten wir die SHA1 Pr?fsummen nicht nur auf der Webseite (die ?brigens auf einem anderen Server, in einem anderen RZ und unter anderer Kontrolle als der Download Server liegt), sondern auch per Email im Announcement. Gerichtete Angriffe kann man damit zwar nicht verhindern, es erschwert Angriffe aber schon. > Wie denkt Ihr dar?ber, Euch ein solches SSL-Zertifikat bei CAcert.org zu holen und auf dem Webserver einzusetzen. Positiver Nebeneffekt: Die Downloads k?nnten per HTTPS (SSL-verschl?sselt) erfolgen und die Pr?fprozeduren k?nnten ggf. entfallen. SSL t?uscht nur eine bestimmte Sicherheit vor. Ein Angriff mit einem SSL Root Zertifikat ist sicherlich wesentlich einfacher als ein weit angelegter Angriff auf mehrere Server und Email Archive. Es gibt unz?hlige g?ltige Root Zertifikate, deren aktueller Besitzer nicht mehr sicher ermittelbar ist. Die meisten Browser vertrauen mehreren hundert Root Zertifikaten (die man bei Windows z.B. gar nicht sieht, da sie verdeckt nachgeladen werden). Dadurch t?uscht eine HTTPS Verbindung eine Sicherheit vor, die weder der User noch wir nicht kontrollieren konnen. > Freue ich auf Eure Antwort und w?nsche uns gemeinsam weiterhin viel Erfolg beim Sichern jeder Internet-Kommunikation. Vielen Dank. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Wed Apr 21 12:07:17 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 21 Apr 2010 12:07:17 +0200 Subject: [Gpg4win-devel] Release 2.0.2-rc2 as 2.0.2? In-Reply-To: <201004081148.26315.bernhard@intevation.de> References: <201004081148.26315.bernhard@intevation.de> Message-ID: <201004211207.20751.bernhard@intevation.de> Am Donnerstag, 8. April 2010 11:48:22 schrieb Bernhard Reiter: > Cons: > * 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.) -- 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/20100421/6fa19c5d/attachment.pgp From bernhard at intevation.de Thu Apr 22 08:56:34 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 22 Apr 2010 08:56:34 +0200 Subject: [Gpg4win-devel] =?iso-8859-1?q?Strength_of_X509_=28Re=3A__Sicherh?= =?iso-8859-1?q?eit_der_Downloads_von_der_Website=09http=3A//www=2E?= =?iso-8859-1?q?gpg4win=2Ede/_=29?= In-Reply-To: <4BCD97F8.9020307@ruhr-uni-bochum.de> References: <28985736.84517.1271247781644.JavaMail.fmail@mwmweb019> <201004201253.05159.bernhard@intevation.de> <4BCD97F8.9020307@ruhr-uni-bochum.de> Message-ID: <201004220856.37523.bernhard@intevation.de> Am Dienstag, 20. April 2010 14:03:04 schrieb Marcus Brinkmann: > 4) The web of trust based on OpenPGP is much more reliable and resilient > than X.509 certificates and certificate authorities. I doubt that statement holds for the average case, though I agree with your general assessment that the strength https is weak in the average use case and it would not add a lot to our security. (I came to the same conclusion in my post that I did write without seeing Werner's reply.) > You say you need 4 eyes to trust an OpenPGP signature by Werner Koch, but > you are willing to trust signatures made by CAcert? ?Makes no sense to me. I agree that Werner Koch's OpenPGP key provides the stronger authentification and trust level here. > ?You are probably underestimating the strength of OpenPGP and > overestimating the strength of X.509 certificates for HTTPS. > > Even more bluntly: HTTPS is a *joke*. [1] > > 5) In response to Bernhard, who said that we will sign the exe file: ?In > the light of how broken HTTPS is, I would be extremely reluctant to assign > any security value to signed exe files. > > Chance is that the implementation is as buggy as for web browsers, and of > course all criticism of the public CA system apply here as well. ?I > consider signing exe files a usability measure, not a security measure (it > get rids of a warning). You are right in that we will sign it because of the usability problem the current warning gives us. In the general case, if the operating system has a general x509 certificate store which is well maintained by an administrator, I believe this can turn into a more security and an easier solution for users. For the x509 certificates used by S/MIME we can do so. I have seen applications where https was only allowed by client certificates coming out of a few selected certificiates authorities. Overall I believe this beats OpenPGP, because most users really have a hard time to evaluate the trust situation with OpenPGP and for many use cases they will not be able to find a trust chain within a reasonable time frame. Also OpenPGP implementations are not as good on checking the current validity like getting uptodate information if a certificate is revoked. > [1] This deserves an explanation. ?If you think that X.509 certificates > provide a value for HTTPS, then please answer a simple question for me: > When is a X.509 certificate valid for a given domain? ?See the SSL attacks > by Dan Kaminsky and Moxie Marlinspike from last year for details. You accept the certificate if you have unbroken implementations on ca and browser level and successfully getting current revokation information that indicated that the certificate chain is in good order. To my knowledge the researchers you mention have mainly discovered implementation and maintenance flaws. Both type of flaws will be there with OpenPGP or any other system as well. Maybe PKI just attracts more research to unveil them. So the main criticism to X509 probably is that it is not simple enough to be easily implemented. I am no real expert, though. 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/20100422/8c587b3a/smime.bin From wk at gnupg.org Thu Apr 22 10:14:12 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Apr 2010 10:14:12 +0200 Subject: [Gpg4win-devel] Strength of X509 In-Reply-To: <201004220856.37523.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 22 Apr 2010 08:56:34 +0200") References: <28985736.84517.1271247781644.JavaMail.fmail@mwmweb019> <201004201253.05159.bernhard@intevation.de> <4BCD97F8.9020307@ruhr-uni-bochum.de> <201004220856.37523.bernhard@intevation.de> Message-ID: <87d3xrhpkb.fsf_-_@vigenere.g10code.de> On Thu, 22 Apr 2010 08:56, bernhard at intevation.de said: > reasonable time frame. Also OpenPGP implementations are not as good on > checking the current validity like getting uptodate information if a > certificate is revoked. The good thing is that OpenPGP and its implementaions allow to check for revoked keys and diligent users actually do that for important transactions. It is entirely in the certificate/keys[1] owner's hand to publish a revocation - no central authority is required. With X.509 you need to convince your CA to include your certificiate into a CRL and then you need to convince users to actually check the CRL. Given that many large scale CAs have no proper rules on when to include a certificates into a CRL (sometimes they put all expired certificates into their CRLs), it really depends on your PKI and its organization whether this all works. As usual with OpenPGP a central authority is not required and thus makes things easier. It is possible to implement a complete or partial central authority on top of OpenPGP. Thus I conclude that OpenPGP is a superset of what X.509 offers. > To my knowledge the researchers you mention have mainly discovered > implementation and maintenance flaws. Both type of flaws will be there with > OpenPGP or any other system as well. Maybe PKI just attracts more research The mayor drawback of X.509 is that it is too complex: In terms of its goals, it options, its encodings and finally its implementations. It is impossible to get it right because there is no single interpretation of one of the standards. BYW, the Web of Trust as commonly used with OpenPGP is also a PKI - a de-centralized one and not a centralized one as with X.509. Aside from technical attacks on SSL there is the problem of governments forcing CAs to issue fake certificates as described in Soghoian and Stamm's recent paper[1]. The catch here is that browsers trust hundred of certificates and thus they are all implicitly cross-certified. Even if you trust your own governemt not to spy on you, a foreign CA might have been asked to create a fake certificate. Although there are ways to mitigate this threat any centrally controlled infrastructure is inherently subject to such kinds of attacks. > to unveil them. So the main criticism to X509 probably is that it is not > simple enough to be easily implemented. I am no real expert, though. Right. Salam-Shalom, Werner [1] In an attempt to unify key managers some of us once agreed on using the term certificate also for OpenPGP keys. I am not anymore sure whether this was such a good idea, because people always associate "certificate" with X.509 and "key" (or correct "keyblock") with OpenPGP. Using "certificate" in the context of OpenPGP seems to be confusing for most people. [2] http://files.cloudprivacy.net/ssl-mitm.pdf -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 22 17:01:36 2010 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 22 Apr 2010 17:01:36 +0200 Subject: [Gpg4win-devel] Strength of X509 (Re: Sicherheit der Downloads von der Website http://www.gpg4win.de/ ) In-Reply-To: <201004220856.37523.bernhard@intevation.de> References: <28985736.84517.1271247781644.JavaMail.fmail@mwmweb019> <201004201253.05159.bernhard@intevation.de> <4BCD97F8.9020307@ruhr-uni-bochum.de> <201004220856.37523.bernhard@intevation.de> Message-ID: <4BD064D0.4050209@ruhr-uni-bochum.de> On 04/22/2010 08:56 AM, Bernhard Reiter wrote: > Am Dienstag, 20. April 2010 14:03:04 schrieb Marcus Brinkmann: >> 4) The web of trust based on OpenPGP is much more reliable and resilient >> than X.509 certificates and certificate authorities. > > I doubt that statement holds for the average case, though I agree with your > general assessment that the strength https is weak in the average use case > and it would not add a lot to our security. (I came to the same conclusion in > my post that I did write without seeing Werner's reply.) Well, let's separate the issues: HTTPS adds *nothing* to installer package security, because it only verifies that bits are correctly sent from web server to browser. Software packages are sent from the developer to the user and the internet is only a small part of that path. Once we have the gpg4win installer package out of the way, we now have two issues: HTTPS in general on the one hand and X.509 vs OpenPGP on the other. Both have been argued on for a long time now, by smarter people than me. But let's just state here as a reminder that X.509 is not a complete standard, but requires a profile. The relevant profile for SSL seems to be RFC2459, which is a whopping 130 pages long and came pretty late in 1999 (HTTPS was created in 1994, Verisign was founded 1995). If you want a laugh (or maybe crying is the appropriate response), check out GnuTLS's answer how to verify a peer certificate: http://www.gnu.org/software/gnutls/manual/html_node/Verifying-peer_0027s-certificate.html If you need 227 lines of code to verify a certificate chain, and you still don't know if you did it correctly, then in the context of system and process security, that's pre-programmed failure. And of course it is always worth to reference Peter Gutmanns X509 Style Guide, for those who don't know it yet: http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt Now, on package signing: > In the general case, if the operating system has a general x509 certificate > store which is well maintained by an administrator, I believe this can turn > into a more security and an easier solution for users. Sure. Debian is doing this for years. They use OpenPGP, but it doesn't matter: If all aspects of the systems are tightly controlled, X.509 and OpenPGP provide approximately equivalent functionality, because the underlying cryptographic algorithms play a more important role than the (fixed and managable) policy issues. > For the x509 > certificates used by S/MIME we can do so. I have seen applications where > https was only allowed by client certificates coming out of a few selected > certificiates authorities. Overall I believe this beats OpenPGP, because most > users really have a hard time to evaluate the trust situation with OpenPGP > and for many use cases they will not be able to find a trust chain within a > reasonable time frame. This argument is not logically consistent: Client certificates (and software certificates) are not verified by users, not in the case of X.509, but also not in the case of OpenPGP (see the Debian example). > Also OpenPGP implementations are not as good on > checking the current validity like getting uptodate information if a > certificate is revoked. Not so sure about that, but Werner responded already. >> [1] This deserves an explanation. If you think that X.509 certificates >> provide a value for HTTPS, then please answer a simple question for me: >> When is a X.509 certificate valid for a given domain? See the SSL attacks >> by Dan Kaminsky and Moxie Marlinspike from last year for details. > > You accept the certificate if you have unbroken implementations on ca and > browser level and successfully getting current revokation information that > indicated that the certificate chain is in good order. Well, in the case of HTTPS I don't control the CAs, so it is impossible for me to have verifiably unbroken implementations. Strictly, I'd have to stop right there and reject every certificate that I didn't issue myself. I can fix the browser, but I would have a hard job, see the GnuTLS example above. And even if you can figure out what the standards actually mean you would also have to take care of legacy/compatibility issues. The question is: Why do I have to do all this? Why is there not already a program that can do it for me, reliably? > To my knowledge the researchers you mention have mainly discovered > implementation and maintenance flaws. Wild card matching is not an implementation or maintainenance flaw, it's a design/specification flaw. You don't accidentially match wild cards, it needs to be implemented. On what basis? RFC2459 says: "Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements may use such names but shall define the semantics." It's not a bug, it's a feature! > Both type of flaws will be there with OpenPGP or any other system as well. No. Although it is possible to build more complex systems based on OpenPGP that are just as broken, X.509 contains the brokenness right there in the specification. I am not saying that a HTTPS build on top of OpenPGP would be better, so you still make your point. HTTPS is not broken because of X.509 (although that certainly helped), it is just broken. Still, there is reason to believe that starting with OpenPGP and the web of trust could lead to a better design. Consider the case of openssh: You accept a remote certificate on first use, from then on you only get an error if the remote fingerprint changes. This is similar to signing an OpenPGP key the first time you communicate/meet with somebody, and thus such a mechanism and OpenPGP are a natural match (openssh of course shows that the same can be achieved with X.509). Peter Gutmann and others have long proposed to use a similar mechanism in the browser. > Maybe PKI just attracts more research > to unveil them. So the main criticism to X509 probably is that it is not > simple enough to be easily implemented. I am no real expert, though. I'd suggest you reread the Kaminsky paper. It is very instructive to think about the source of the problems, which manifests itself in bugs, but are actually caused by other defects such as lack of specification or wrong defaults/mental models. Now, what I find really exciting is that you identify complexity as the main problem here, because complexity in crypto systems is a fatal flaw. It's not something that can be brushed aside. "Complexity is the worst enemy of security." is a common Schneier quote: http://www.schneier.com/crypto-gram-0003.html#8 details some of the reasons. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Fri Apr 30 02:28:52 2010 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 30 Apr 2010 02:28:52 +0200 Subject: [Gpg4win-devel] user feedback: gpgex 64 bit desired Message-ID: <4BDA2444.1060405@ruhr-uni-bochum.de> Hi, I just got feedback from a user who noticed that Windows 7 64-bit is not compatible with gpgex. The background is this: In Windows Vista 64 bit and some (or all?) Windows 7 versions before the RC version, it was possible to start a separate 32-bit explorer even on 64-bit machines, which could load 32 bit extensions. Apparently this feature was removed from Windows 7 RC and subsequently. This means that GpgEX does not work on Windows 7 64 bit. Please note that if GpgEX does not work for you, all operations possible through GpgEX are also directly available through the Kleopatra main program, by selecting the operation first and then the file to work on. For people who want to work on fixing this: It would be required to build at least libgpg-error, libassuan and gpgex with a 64 bit version of mingw. There may be some 64-bit incompatibilities (in libassuan), though. More importantly (I think), the 64-bit build needs to be integrated into the packaging and release process, which also seems to require a fair amount of work. Thanks, Marcus From dnorthup at maine.edu Fri Apr 30 13:58:31 2010 From: dnorthup at maine.edu (Drew Northup) Date: Fri, 30 Apr 2010 07:58:31 -0400 Subject: [Gpg4win-devel] user feedback: gpgex 64 bit desired In-Reply-To: <4BDA2444.1060405@ruhr-uni-bochum.de> References: <4BDA2444.1060405@ruhr-uni-bochum.de> Message-ID: <1272628711.25144.4.camel@drew-northup.unet.maine.edu> On Fri, 2010-04-30 at 02:28 +0200, Marcus Brinkmann wrote: > The background is this: In Windows Vista 64 bit and some (or all?) Windows 7 > versions before the RC version, it was possible to start a separate 32-bit > explorer even on 64-bit machines, which could load 32 bit extensions. > Apparently this feature was removed from Windows 7 RC and subsequently. This > means that GpgEX does not work on Windows 7 64 bit. Marcus, Thank you for bringing up this information. I was aware that 16-bit applications had been essentially embargoed from Windows 7, but I'd not heard anything about this change. I suspect that it will turn out to be something a great many of us will have to look into. -- ---------------------------------+-------------------------------------- Drew Northup | Technical Support Specialist University of Maine System | Drew.Northup at Maine.edu Computing Center | phone: (207) 561-3513 Orono, ME 04469 | fax: (207) 561-3531