From aegypten-issues at intevation.de Fri Apr 2 02:26:46 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Fri Apr 2 02:23:57 2004 Subject: [issue131] gpgme_key_t->can_sign == false on secret keylisting of OpenPGP keys Message-ID: <1080865606.72.0.186387446409.issue131@intevation.de> New submission from Marc Mutz : Since the flag is set on secret key listings of S/MIME keys, I suspect this is a bug and not me misunderstanding a feature. I've commited a work-around to gpgme++ that always returns true for OpenPGP keys, so it's not urgent, but of course it should be fixed. ---------- assignedto: werner messages: 607 nosy: marc, werner priority: bug status: unread title: gpgme_key_t->can_sign == false on secret keylisting of OpenPGP keys topic: GPGME, gpg ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Fri Apr 2 13:22:12 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Fri Apr 2 13:19:23 2004 Subject: [issue132] gpgme_op_keylist_ext_start (CMS) fails to return any key if one of the patterns given is an OpenPGP fingerprint Message-ID: <1080904932.65.0.445834347366.issue132@intevation.de> New submission from Marc Mutz : The equivalent gpgsm command line works, though: $ gpgsm --list-secret-keys compare this to $./test_gpgme_secret_keylisting $./test_gpgme_secret_keylisting (only that) The same thing on a context set to GPGME_PROTOCOL_OpenPGP works (ie. returns the OpenPGP key, ignores the S/MIME fingerprint). This is the expected result. Anything else makes op_keylist useless for looking up keys by person or email. Test app (code from info gpgme, adjusted to use _ext_, CMS, and argv, as well as to make it compile :P) attached. ---------- assignedto: werner files: test_gpgme_secret_keylisting.c messages: 608 nosy: marc, werner priority: urgent status: unread title: gpgme_op_keylist_ext_start (CMS) fails to return any key if one of the patterns given is an OpenPGP fingerprint topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_gpgme_secret_keylisting.c Type: text/x-csrc Size: 1146 bytes Desc: not available Url : /pipermail/attachments/20040402/efd88dbb/test_gpgme_secret_keylisting.bin From aegypten-issues at intevation.de Fri Apr 2 15:09:37 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Fri Apr 2 15:06:46 2004 Subject: [issue133] composer hardcodes micalg=sha1 and micalg=pgp-sha1. Message-ID: <1080911377.25.0.098515506363.issue133@intevation.de> New submission from Marc Mutz : I think I rememeber that info gpgme said what can be used by the caller of gpgme_op_sign for the micalg parameter, but searching the current gpgme.info doesn't give a hit on "migalg". "pgp-" + gpgme_hash_algo_name() for OpenPGP and gpgme_hash_algo_name() for S/MIME? What about the case where the gpgme_sign_result_t->signatures contains more than one entry and those entries differ in their hash_algo fields? Comma-separate them? ---------- assignedto: marc messages: 611 nosy: marc, marcus priority: bug status: unread title: composer hardcodes micalg=sha1 and micalg=pgp-sha1. topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From wk at gnupg.org Fri Apr 2 15:35:58 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Apr 2 15:22:08 2004 Subject: [issue133] composer hardcodes micalg=sha1 and micalg=pgp-sha1. In-Reply-To: <1080911377.25.0.098515506363.issue133@intevation.de> (Marc Mutz's message of "Fri, 02 Apr 2004 13:09:37 +0000") References: <1080911377.25.0.098515506363.issue133@intevation.de> Message-ID: <87fzbmec3l.fsf@vigenere.g10code.de> On Fri, 02 Apr 2004 13:09:37 +0000, Marc Mutz said: > "pgp-" + gpgme_hash_algo_name() for OpenPGP and gpgme_hash_algo_name() > for S/MIME? What about the case where the gpgme_sign_result_t->signatures Right, but lowercased. > contains more than one entry and those entries differ in their hash_algo fields? > Comma-separate them? Just take the first one (or sha1), the mic-alg is a silly thing anyway. From jan at intevation.de Sat Apr 3 20:53:19 2004 From: jan at intevation.de (Jan-Oliver Wagner) Date: Sat Apr 3 20:50:28 2004 Subject: =?iso-8859-15?q?=C4gypten2?= info page Message-ID: <20040403185319.GB12081@intevation.de> Dear developers, I've set up an info page for the ?gypten2 project. It summarizes the aims, a module overview and build instructions. http://www.gnupg.org/aegypten2/index.html All the best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From aegypten-issues at intevation.de Mon Apr 5 11:57:06 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Mon Apr 5 11:54:29 2004 Subject: [issue134] gpgme/gpgsm: GPGME_SIG_MODE_NORMAL doesn't work (at least for cms) Message-ID: <1081159026.52.0.437657806281.issue134@intevation.de> New submission from Marc Mutz : Try this in current KMail (aegypten_2_0_0_pre3_release tag): Define an identity with only S/MIME keys (see #132 for why). Open a composer, select the above identity, select "S/MIME" format, say yes to sign? and no to encrypt? and. This will succeed. Do the same, but use "S/MIME opaque". This will fail with an invalid crypto engine error. Why is the a backend problem? Run KMail in gdb, and set a break point to gpgme_op_sign. In the first, case above (the one orginally succeeding), change the mode parameter inside a gpgme funtion from the normal GPGME_SIG_MODE_DETACH to GPGME_SIG_MODE_NORMAL. -> Signing fails, and we have only changed this single variable. Likewise, in the originally failing case of S/MIME opaque, set the mode parameter from the normal GPGME_SIG_MODE_NORMAL to GPGME_SIG_MODE_DETACH. -> Signing will succeed, although it will of course not result in a valid message, due to the opaque/detached mismatch between gpgme and kmail. ---------- assignedto: werner messages: 613 nosy: marc, werner priority: critical status: unread title: gpgme/gpgsm: GPGME_SIG_MODE_NORMAL doesn't work (at least for cms) topic: GPGME, gpgsm ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Apr 6 14:33:15 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Tue Apr 6 14:30:26 2004 Subject: [issue135] error when decrypting mail encrypted with sign only key Message-ID: <1081254795.41.0.632953292563.issue135@intevation.de> New submission from Bernhard Herzog : When decrypting a mail encrypted with a signature only key, the backend reports Assuan processing failed: write error. See attached files for an example mail and the secret key needed to decrypt it. This is probably similar to Issue76. ---------- files: encrypted-with-signonly-key.mbox messages: 625 nosy: bh priority: bug status: unread title: error when decrypting mail encrypted with sign only key ______________________________________________________ Aegypten issue tracker ______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: encrypted-with-signonly-key.mbox Type: application/octet-stream Size: 1794 bytes Desc: not available Url : /pipermail/attachments/20040406/ee25cb11/encrypted-with-signonly-key-0001.exe From aegypten-issues at intevation.de Wed Apr 7 12:24:43 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Wed Apr 7 12:21:52 2004 Subject: [issue136] when editing an identity, the S/MIME encryption certificate key requester stays blank Message-ID: <1081333483.7.0.821206559262.issue136@intevation.de> New submission from Marc Mutz : due to the corresponding keylisting not emitting a key. ---------- assignedto: marc messages: 632 nosy: marc priority: bug status: unread title: when editing an identity, the S/MIME encryption certificate key requester stays blank topic: KMail, libkleopatra ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 7 12:33:48 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Wed Apr 7 12:30:55 2004 Subject: [issue137] composer chooses to encrypt/sign with OpenPGP, although no encrypt-to-self keys are configured for OpenPGP Message-ID: <1081334028.11.0.421181657307.issue137@intevation.de> New submission from Marc Mutz : In KAddressBook: Create an entry with the following preferences: Allowed protocols: OpenPGP/MIME, S/MIME, S/MIME opaque Sign: Always sign Encrypt: Ask Whenever Possible Assign both preferred OpenPGP and S/MIME keys to that contact. In KMail: Open a composer, choose an identity with no OpenPGP sign/encrypt keys, but only S/MIME sign/encrypt keys. Uncheck the sign and the encrypt buttons and choose "Any" in the format selection. On send, you'll get an error message telling you that it chose to encrypt/sign with OpenPGP, but that there is no OpenPGP encrypt-to-self key available. If you have disabled encrypt-to-self, then it will ask the same thing b/c of the missing sign key. It should use S/MIME instead, of course. ---------- assignedto: marc messages: 636 nosy: marc priority: urgent status: in-progress title: composer chooses to encrypt/sign with OpenPGP, although no encrypt-to-self keys are configured for OpenPGP topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 8 16:43:15 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Thu Apr 8 16:40:23 2004 Subject: [issue138] default to .p10 for saving certificate request to file Message-ID: <1081435395.65.0.685498676355.issue138@intevation.de> New submission from Jan-Oliver Wagner : default to .p10 suffix for saving certificate request to file for the file dialog launched from Kleopatra. ---------- assignedto: marc messages: 645 nosy: jan, marc priority: minor bug status: unread title: default to .p10 for saving certificate request to file topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 8 16:46:15 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Thu Apr 8 16:43:23 2004 Subject: [issue139] Selection of sign-key and/or encryption key Message-ID: <1081435575.59.0.871411203207.issue139@intevation.de> New submission from Jan-Oliver Wagner : When creating a key pair and a certification request, the dialogs must allow to create keys for - signing only - encryption only - both (the default) ---------- assignedto: marc messages: 646 nosy: jan, marc priority: bug status: unread title: Selection of sign-key and/or encryption key topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 8 18:34:37 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Thu Apr 8 18:31:44 2004 Subject: [issue140] dirmngr infinite loop Message-ID: <1081442077.51.0.713837141116.issue140@intevation.de> New submission from Bernhard Herzog : dirmngr sometimes enters an infite loop, freezing the entire kmail7ageypten. Killing it and trying the aborted action again helps. It doesn't hang a second time. I can reproduce the problem quite reliably. do dirmngr --flush and try to verify a signature in kmail. ---------- assignedto: werner messages: 647 nosy: bh, werner priority: bug status: unread title: dirmngr infinite loop topic: DirMngr ______________________________________________________ Aegypten issue tracker ______________________________________________________ From cbguder at su.sabanciuniv.edu Fri Apr 9 01:45:11 2004 From: cbguder at su.sabanciuniv.edu (=?ISO-8859-9?Q?Can_Berk_G=FCder?=) Date: Fri Apr 9 01:42:25 2004 Subject: Turkish localization & cross-compiling for Windows... Message-ID: <4075E407.3080809@su.sabanciuniv.edu> Hi there, I and a friend will be localizing GPA as part of our project course, and I have a few questions: 1. Does GPA use a localization engine, or does the localization have to be at the source-code level? 2. Have there been any past efforts for Turkish localization? 3. We have to present binaries for both Windows or Linux. Do we need to cross-compile for the Windows binary? Regards, -- Can Berk Guder Sabanci University Istanbul, Turkey From wk at gnupg.org Fri Apr 9 10:27:06 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Apr 9 10:11:49 2004 Subject: Turkish localization & cross-compiling for Windows... In-Reply-To: <4075E407.3080809@su.sabanciuniv.edu> (Can Berk =?iso-8859-1?q?G=FCder's?= message of "Fri, 09 Apr 2004 02:45:11 +0300") References: <4075E407.3080809@su.sabanciuniv.edu> Message-ID: <87fzbd36at.fsf@vigenere.g10code.de> On Fri, 09 Apr 2004 02:45:11 +0300, Can Berk G?der said: > 1. Does GPA use a localization engine, or does the localization have > to be at the source-code level? Sure, it uses the usual gettext stuff. We have currently these translations: de fr zh_TW.Big5 pt_BR ja nl es sv > 2. Have there been any past efforts for Turkish localization? No. You might want to use Nilgun Belma Buguner's (nilgun at technologist dot com) tr translation for gnupg as a reference. > 3. We have to present binaries for both Windows or Linux. Do we need > to cross-compile for the Windows binary? I don't think that it is currently possible to build gpa for Windows; it might work using Cygwin. Salam-Shalom, Werner From lfarkas at bppiac.hu Fri Apr 9 10:42:29 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri Apr 9 10:39:39 2004 Subject: More user id for one key Message-ID: <407661F5.9080401@bppiac.hu> hi, in a key one can define more user id. in gpa there is no way to define more user id neithe when you generate a key neither later. eg. in WinPT (the windows frontend for gnupg) there is a submenu when you right-click on a row for user ids and sub keys. this would be useful for gpa too! this is the command line tools --edit-key's subcommand like : adduid deluid etc. is there any chance to use it in the near future? yours. -- Levente "Si vis pacem para bellum!" From aegypten-issues at intevation.de Fri Apr 9 11:36:37 2004 From: aegypten-issues at intevation.de (David Faure) Date: Fri Apr 9 11:33:48 2004 Subject: [issue141] Cancellation during key generation leaves disabled buttons Message-ID: <1081503397.47.0.844892063813.issue141@intevation.de> New submission from David Faure : In the certificate generation wizard, fill in the first pages, then click the "Generate Certificate" button. In the password dialog (pineentry-qt), press Cancel. Then "Generate Certificate" and "Back" are disabled, and "Next" is enabled, I guess it should be the other way round. CertificateWizardImpl::slotResult is called with res.error() set to a strange value (when casting to int I get 587202659), but strangely enough, the if (res.error()) test is false, so it goes to the 'success' case. Cancelling should go to the first branch, but without the KMessageBox. ---------- assignedto: marc messages: 651 nosy: david, marc priority: bug status: unread title: Cancellation during key generation leaves disabled buttons topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From cbguder at su.sabanciuniv.edu Fri Apr 9 12:21:11 2004 From: cbguder at su.sabanciuniv.edu (=?ISO-8859-9?Q?Can_Berk_G=FCder?=) Date: Fri Apr 9 12:18:25 2004 Subject: Turkish localization & cross-compiling for Windows... In-Reply-To: <87fzbd36at.fsf@vigenere.g10code.de> References: <4075E407.3080809@su.sabanciuniv.edu> <87fzbd36at.fsf@vigenere.g10code.de> Message-ID: <40767917.1060208@su.sabanciuniv.edu> First of all, thanks for the quick reply... =) The GPA website says that it can be compiled for various platforms, so I thought Win32 was one of them... Anwyay, we'll just stick with Linux then. We better start translating now, Thanks and take care, Can Berk G?der Werner Koch wrote: > On Fri, 09 Apr 2004 02:45:11 +0300, Can Berk G?der said: > > >>1. Does GPA use a localization engine, or does the localization have >>to be at the source-code level? > > > Sure, it uses the usual gettext stuff. We have currently these > translations: > > de fr zh_TW.Big5 pt_BR ja nl es sv > > >>2. Have there been any past efforts for Turkish localization? > > > No. You might want to use Nilgun Belma Buguner's (nilgun at > technologist dot com) tr translation for gnupg as a reference. > > >>3. We have to present binaries for both Windows or Linux. Do we need >>to cross-compile for the Windows binary? > > > I don't think that it is currently possible to build gpa for Windows; > it might work using Cygwin. > > > Salam-Shalom, > > Werner > From bernhard at intevation.de Tue Apr 13 12:47:23 2004 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Apr 13 12:44:38 2004 Subject: mailman-bug: Breaking signatures In-Reply-To: <20040108141145.GM698@intevation.de> References: <20031001172446.GG7049@intevation.de> <20040108141145.GM698@intevation.de> Message-ID: <20040413104723.GE6115@intevation.de> On Thu, Jan 08, 2004 at 03:11:45PM +0100, Bernhard Reiter wrote: > Is there nobody out there that could help to fix > this Mailman 2.1.x bug or raise awareness for this bug? I have created a patch, also to be found at: ftp.intevation.de/users/bernhard/mailman Mailman might still break signatures if text/html parts are filtered out. At least this is what I expect, but did not test. > Gpa-dev also runs it and signatures will not be worth much, > if we don't consider mail transport systems that break them > a real security problem. People will learn that if a mail was > manipulated, the mailsystem will be the most likely cause. > So in practice a really manipulated email will go unnoticed > with a lot higher chance. > On Wed, Oct 01, 2003 at 07:24:46PM +0200, Bernhard Reiter wrote: > > I've finally reproduced and reported that Mailman 2.1.x bug > > that causes some signatures to break. > > > > (Somebody said Ingo already nailed that bug, but I could > > not find the Mailman bug report for it, so he might not have > > reported it.) > > > > On Tue, Sep 30, 2003 at 10:46:57AM -0700, SourceForge.net wrote: > > > Bugs item #815297, was opened at 2003-09-30 19:42 > > > Message generated for change (Comment added) made by ber > > > You can respond by visiting: > > > https://sourceforge.net/tracker/?func=detail&atid=100103&aid=815297&group_id=103 > > > > > > > > Initial Comment: > > > Mailman _must_ not touch MIME-parts which are nested > > > more deeply in the mail. As tested with Mailman 2.1.2, > > > header lines will be sometimes reformatted in > > > message/rfc822 attachments which will break the OpenPGP > > > signature > > > (also conforming to the PGP/MIME standard) on that part. > > > > > This is an email security affecting bug, because if people > > > start believing that a *BAD* signature does not mean much, > > > because they get many broken by mailman, they will not > > > react > > > to a seriously manipulated email anymore! > > > > -- > Professional Service for Free Software (intevation.net) > The FreeGIS Project (freegis.org) > Association for a Free Informational Infrastructure (ffii.org) > FSF Europe (fsfeurope.org) > _______________________________________________ > Gpa-dev mailing list > Gpa-dev@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gpa-dev -- Professional Service for Free Software (intevation.net) The FreeGIS Project (freegis.org) Association for a Free Informational Infrastructure (ffii.org) FSF Europe (fsfeurope.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2145 bytes Desc: not available Url : /pipermail/attachments/20040413/a418203f/smime-0001.bin From aegypten-issues at intevation.de Tue Apr 13 15:55:12 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Tue Apr 13 15:52:19 2004 Subject: [issue142] propagate warnings during decryption to the frontend Message-ID: <1081864512.85.0.518950121587.issue142@intevation.de> New submission from Bernhard Herzog : Part of the problem discussed in Issue135 is that there's no way to propagate warnings generated by the backend during decryption back to the front end. This should be fixed. ---------- messages: 667 nosy: bh priority: bug status: unread title: propagate warnings during decryption to the frontend topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Apr 13 19:47:04 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Tue Apr 13 19:44:12 2004 Subject: [issue143] kmail: doesn't split messages (1) Message-ID: <1081878424.94.0.324977436419.issue143@intevation.de> New submission from Marc Mutz : In KAddressBook, configure one contact with OpenPGP/MIME as only allowed protocol, and another contact with both S/MIME formats as only allowed protocols. Send a message to both (To), with both sign and encrypt buttons switched off and format selection "Any". KMail should create two messages: One OpenPGP/MIME encrypted, and the other one S/MIME encrypted. It creates only the OpenPGP/MIME one, maybe b/c the "S/MIME contact" also has OpenPGP encryption keys available. (the (1) is there since I expect there to be many other cases where this fails) ---------- assignedto: marc messages: 669 nosy: marc priority: bug status: unread title: kmail: doesn't split messages (1) topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Apr 13 19:52:59 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Tue Apr 13 19:50:06 2004 Subject: [issue144] kmail treats "Always Encrypt If Possible" and "" as conflicting crypto preferences Message-ID: <1081878779.35.0.248098356593.issue144@intevation.de> New submission from Marc Mutz : Subject says all ---------- assignedto: marc messages: 670 nosy: marc priority: minor bug status: unread title: kmail treats "Always Encrypt If Possible" and "" as conflicting crypto preferences topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 14 16:34:04 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Wed Apr 14 16:31:10 2004 Subject: [issue145] kmail doesn't set mime boundary Message-ID: <1081953244.44.0.175454782365.issue145@intevation.de> New submission from Bernhard Herzog : kmail (Tag aegypten_2_0_0_pre3_release from today) doesn't set a mime boundary anymore in multipart mixed mails. See attached file for an example. The boundary is not even set if the body text contains "--" mutt doesn't recognize attachments anymore with those mails. KMail and oort gnus do. ---------- assignedto: marc files: mail-without-boundary messages: 680 nosy: bh, marc priority: urgent status: unread title: kmail doesn't set mime boundary topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: mail-without-boundary Type: application/octet-stream Size: 1943 bytes Desc: not available Url : /pipermail/attachments/20040414/4afdd862/mail-without-boundary.exe From aegypten-issues at intevation.de Wed Apr 14 21:08:52 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 14 21:05:58 2004 Subject: [issue146] store uncrypted local emails does not work Message-ID: <1081969732.29.0.294843143433.issue146@intevation.de> New submission from Jan-Oliver Wagner : Deactivating option "Store sent messages encrypted" should lead to unencrypted emails in sent-folder. Indeed they are not encrypted, but the Content-Type says smime-type=enveloped-data which should be something else. I tried SMIME multipart-signed. The email was also signed. ---------- assignedto: marc messages: 685 nosy: jan, marc priority: bug status: unread title: store uncrypted local emails does not work topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 14 21:17:38 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Wed Apr 14 21:14:45 2004 Subject: [issue147] re-implement expiry warnings in KMail's composer Message-ID: <1081970258.9.0.292708798806.issue147@intevation.de> New submission from Marc Mutz : $subject says it all ---------- assignedto: marc messages: 686 nosy: marc priority: bug status: unread title: re-implement expiry warnings in KMail's composer topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 14 21:23:26 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Wed Apr 14 21:20:34 2004 Subject: [issue148] Reorganise Security Page in KMail Message-ID: <1081970606.53.0.14998992474.issue148@intevation.de> New submission from Marc Mutz : Move "automatically import attached keys" to "General" and rename "General" to "Reading". ---------- messages: 687 nosy: marc priority: minor bug status: unread title: Reorganise Security Page in KMail topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 14 21:44:48 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 14 21:41:55 2004 Subject: [issue149] kwatchgnupg does not really work properly Message-ID: <1081971888.47.0.431281217508.issue149@intevation.de> New submission from Jan-Oliver Wagner : running kwatchgnupg, the tool comes up nicely, but after the very first crypto operation is simply freezes. Can anyone confirm this behaviour? ---------- assignedto: marc messages: 688 nosy: jan, marc priority: bug status: unread title: kwatchgnupg does not really work properly topic: Kwatchgnupg ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 15 10:18:49 2004 From: aegypten-issues at intevation.de (David Faure) Date: Thu Apr 15 10:16:09 2004 Subject: [issue150] dirmngr's gpgconf entries are mis-labelled Message-ID: <1082017129.67.0.989756360527.issue150@intevation.de> New submission from David Faure : The gpgconf entry "max-replies" for dirmngr is in the CRL group, which is very confusing since (according to marc), max-replies is about remote keylistings, i.e. totally unrelated to CRLs. The second part of this bug is that the description of the dirmngr component is "CRL Manager", but that's not the only thing that dirmngr does, right? I suggest 1) moving max-entries to the LDAP group (that's where it belongs, right?) 2) removing the CRL group (it has no other item) 3) changing the description of dirmngr ---------- messages: 691 nosy: david priority: minor bug status: unread title: dirmngr's gpgconf entries are mis-labelled topic: DirMngr, gpg ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 15 15:21:41 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Thu Apr 15 15:18:49 2004 Subject: [issue151] gpgme_key_t->expired == false on expired (S/MIME) key with validating keylisting. Message-ID: <1082035300.43.0.0849094654786.issue151@intevation.de> New submission from Marc Mutz : This is what a validating keylisting returns for my old CN=Marc Mutz,L=org,OU=KMail,O=KDE,C=DE key that expired June 2003: (gdb) p *key $5 = {_refs = 1, revoked = 0, expired = 0, disabled = 0, invalid = 0, can_encrypt = 1, can_sign = 1, can_certify = 0, secret = 1, can_authenticate = 0, _unused = 0, protocol = GPGME_PROTOCOL_CMS, issuer_serial = 0x8138390 "0B", issuer_name = 0x817cd80 "CN=Test-ZS3,O=Intevation GmbH,C=DE", chain_id = 0x8177698 "09AA5F1DE795237656239C9A78536B07E43C15AC", owner_trust = GPGME_VALIDITY_UNKNOWN, subkeys = 0x8177900, uids = 0x8199688, _last_subkey = 0x8177900, _last_uid = 0x8171128} (gdb) p *key->uids $6 = {next = 0x8171128, revoked = 0, invalid = 1, _unused = 0, validity = GPGME_VALIDITY_UNKNOWN, uid = 0x81996ac "CN=Marc Mutz,OU=KMail,O=KDE,L=org,C=DE", name = 0x81996d2 "", email = 0x81996d2 "", comment = 0x81996d2 "", signatures = 0x0, _last_keysig = 0x0} (gdb) p *key->subkeys $7 = {next = 0x0, revoked = 0, expired = 0, disabled = 0, invalid = 1, can_encrypt = 1, can_sign = 1, can_certify = 0, secret = 0, can_authenticate = 0, _unused = 0, pubkey_algo = GPGME_PK_RSA, length = 1024, keyid = 0x8177914 "528130280665A867", _keyid = "528130280665A867", fpr = 0x81997f8 "67348E8ACF3DFBB38121353B528130280665A867", timestamp = 1042554823, expires = 1058106823} (gdb) p time(0) $8 = 1082034803 cf. the values of $8 and $7.expires... The effect is that all certs are marked as valid in certmanager with the new validate certs function... Same goes for revoked certs: $ gpgsm --list-keys --with-validation C86D3C261BC257877CA44EFB2E6C6ECF0A280532 Secure memory is not locked into core gpgsm: NOTE: THIS IS A DEVELOPMENT VERSION! gpgsm: It is only intended for test purposes and should NOT be gpgsm: used in a production environment or with production keys! /home/marc/.gnupg/pubring.kbx ----------------------------- Serial number: 0C Issuer: /CN=ZS 4/O=Intevation GmbH/C=DE Subject: /CN=David Faure/O=Klar??lvdalens Datakonsult AB/L=Cheval Blanc/C=SE aka: dfaure@klaralvdalens-datakonsult.se validity: 2004-02-18 10:05:42 through 2006-02-17 10:05:42 key usage: digitalSignature nonRepudiation keyEncipherment fingerprint: C8:6D:3C:26:1B:C2:57:87:7C:A4:4E:FB:2E:6C:6E:CF:0A:28:05:32 gpgsm: no running dirmngr - starting one can't connect to `/home/marc/.gnupg/log-socket': Connection refused switching logging to stderr dirmngr[30273.0x80646b8] DBG: -> OK Dirmngr 0.5.4-cvs at your service gpgsm: DBG: connection to dirmngr established dirmngr[30273.0x80646b8] DBG: <- ISVALID 0EFFD19584318700CE22B0528C0E005F722A69A7.0C dirmngr[30273]: opening cache file `/home/marc/.gnupg/dirmngr-cache.d/crl-0EFFD19584318700CE22B0528C0E005F722A69A7.db' dirmngr[30273]: S/N 0C is not valid; reason=00 date=20040224T115352 dirmngr[30273]: command ISVALID failed: Certificate revoked dirmngr[30273.0x80646b8] DBG: -> ERR 167772254 Certificate revoked [certificate has been revoked] dirmngr[30273.0x80646b8] DBG: <- ISVALID 7F2A402CBB016A9146D613568C89D3596A4111AA.01 dirmngr[30273]: opening cache file `/home/marc/.gnupg/dirmngr-cache.d/crl-7F2A402CBB016A9146D613568C89D3596A4111AA.db' dirmngr[30273]: S/N 01 is valid, it is not listed in the CRL dirmngr[30273.0x80646b8] DBG: -> OK gpgsm: no running gpg-agent - starting one gpg-agent[30274]: Secure memory is not locked into core gpg-agent[30274]: NOTE: this is a development version! can't connect to `/home/marc/.gnupg/log-socket': Connection refused switching logging to stderr gpg-agent[30274.0x8073b18] DBG: -> OK Your orders please gpgsm: DBG: connection to agent established gpg-agent[30274.0x8073b18] DBG: <- RESET gpg-agent[30274.0x8073b18] DBG: -> OK gpg-agent[30274.0x8073b18] DBG: <- OPTION display=:0 gpg-agent[30274.0x8073b18] DBG: -> OK gpg-agent[30274.0x8073b18] DBG: <- OPTION ttyname=/dev/pts/3 gpg-agent[30274.0x8073b18] DBG: -> OK gpg-agent[30274.0x8073b18] DBG: <- OPTION ttytype=xterm gpg-agent[30274.0x8073b18] DBG: -> OK gpg-agent[30274.0x8073b18] DBG: <- OPTION lc-ctype=C gpg-agent[30274.0x8073b18] DBG: -> OK gpg-agent[30274.0x8073b18] DBG: <- OPTION lc-messages=C gpg-agent[30274.0x8073b18] DBG: -> OK gpg-agent[30274.0x8073b18] DBG: <- ISTRUSTED A6935DD34EF3087973C706FC311AA2CCF733765B gpg-agent[30274.0x8073b18] DBG: -> OK dirmngr[30273.0x80646b8] DBG: <- ISVALID 7F2A402CBB016A9146D613568C89D3596A4111AA.00 dirmngr[30273]: S/N 00 is valid, it is not listed in the CRL dirmngr[30273.0x80646b8] DBG: -> OK [certificate is bad: Certificate revoked] secmem usage: 1344/16384 bytes in 2 blocks dirmngr[30273.0x80646b8] DBG: <- [EOF] yet: (gdb) p *key $9 = {_refs = 1, revoked = 0, expired = 0, disabled = 0, invalid = 0, can_encrypt = 1, can_sign = 1, can_certify = 0, secret = 0, can_authenticate = 0, _unused = 0, protocol = GPGME_PROTOCOL_CMS, issuer_serial = 0x81a2578 "0C", issuer_name = 0x81a0828 "CN=ZS 4,O=Intevation GmbH,C=DE", chain_id = 0x819a328 "28126047B34F852D9408A968508F21F065E65E44", owner_trust = GPGME_VALIDITY_UNKNOWN, subkeys = 0x8197fe0, uids = 0x815bfc8, _last_subkey = 0x8197fe0, _last_uid = 0x81a7d40} (gdb) p *key->uids $10 = {next = 0x81a7d40, revoked = 1, invalid = 0, _unused = 0, validity = GPGME_VALIDITY_UNKNOWN, uid = 0x815bfec "CN=David Faure,O=Klar??lvdalens Datakonsult AB,L=Cheval Blanc,C=SE", name = 0x815c02e "", email = 0x815c02e "", comment = 0x815c02e "", signatures = 0x0, _last_keysig = 0x0} (gdb) p *key->subkeys $11 = {next = 0x0, revoked = 1, expired = 0, disabled = 0, invalid = 0, can_encrypt = 1, can_sign = 1, can_certify = 0, secret = 0, can_authenticate = 0, _unused = 0, pubkey_algo = GPGME_PK_RSA, length = 1024, keyid = 0x8197ff4 "2E6C6ECF0A280532", _keyid = "2E6C6ECF0A280532", fpr = 0x81a96a0 "C86D3C261BC257877CA44EFB2E6C6ECF0A280532", timestamp = 1077098742, expires = 1140170742} As you can, in this case, the problem is that gpgme_key_t->revoked is not set, although gpgme_subkey_t->revoked and gpgme_user_id_t->revoked are. ---------- assignedto: werner messages: 693 nosy: marc, werner priority: bug status: unread title: gpgme_key_t->expired == false on expired (S/MIME) key with validating keylisting. topic: GPGME, gpgsm ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 15 16:20:50 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Thu Apr 15 16:17:59 2004 Subject: [issue152] kmail crashes when fetching encrypted mails Message-ID: <1082038849.74.0.317966945085.issue152@intevation.de> New submission from Bernhard Herzog : KMail (aegypten_2_0_0_pre3_release from yesterday) just crashed on me when looking for new mail. Apparently it was after the email had been fetched and put into the inbox, because starting kmail again produces the same crash. I could briefly see that apparently all new emails were encrypted. The taceback is the same in both cases: #0 0x4238da59 in wait4 () from /lib/libc.so.6 #1 0x42404e48 in __check_rhosts_file () from /lib/libc.so.6 #2 0x42272453 in waitpid () from /lib/libpthread.so.0 #3 0x4171ae7d in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #4 0x4226ff54 in pthread_sighandler () from /lib/libpthread.so.0 #5 0x423166b8 in sigaction () from /lib/libc.so.6 #6 0x413099be in gpgme_get_sig_key (ctx=0x8414a38, idx=0, r_key=0xbfffe7f4) at verify.c:663 #7 0x4125ecb7 in obtain_signature_information (ctx=0x8414a38, overallStatus=@0xbfffe874, sigmeta=0xbfffea64, attrOrder=0x0, unknownAttrsHandling=0x8350c90 "INFIX", signatureFound=0x0) at cryptplug.cpp:2053 #8 0x4125f2e4 in CryptPlug::checkMessageSignature (this=0x8243960, cleartext=0xbfffea94, signaturetext=0x83f7628 "0\200\006\t*\206H\206?\r\001\a\003 \2000\200\002\001", signatureIsBinary=true, signatureLen=2045, sigmeta=0xbfffea64, attrOrder=0x0, unknownAttrsHandling=0x8350c90 "INFIX") at cryptplug.cpp:2212 #9 0x41263adc in CryptPlugWrapper::checkMessageSignature (this=0x823cb48, cleartext=0xbfffea94, signaturetext=0x83f7628 "0\200\006\t*\206H\206?\r\001\a\003 \2000\200\002\001", signatureIsBinary=true, signatureLen=2045, sigmeta=0xbfffea64) at cryptplugwrapper.cpp:1190 #10 0x4030d2b1 in KMail::ObjectTreeParser::writeOpaqueOrMultipartSignedData ( this=0xbfffef08, data=0x0, sign=@0x84a7ce8, fromAddress=@0x84a7d70, doCheck=true, cleartextData=0x0, paramSigMeta=0x0, hideErrors=false) at objecttreeparser.cpp:459 #11 0x4031431d in KMail::ObjectTreeParser::processApplicationPkcs7MimeSubtype ( this=0xbfffef08, node=0x84a7ce8, result=@0xbfffee08) at objecttreeparser.cpp:1680 #12 0x4031b06b in {anonymous}::ApplicationPkcs7MimeBodyPartFormatter::process ( this=0x81f3658, otp=0xbfffef08, node=0x84a7ce8, result=@0xbfffee08) at bodypartformatter.cpp:114 #13 0x4030c615 in KMail::ObjectTreeParser::parseObjectTree (this=0xbfffef08, node=0x84a7ce8) at objecttreeparser.cpp:271 #14 0x4022e87f in KMReaderWin::parseMsg (this=0x8117408, aMsg=0x82f6940) at kmreaderwin.cpp:1123 #15 0x4022e0af in KMReaderWin::displayMessage (this=0x8117408) at kmreaderwin.cpp:1054 #16 0x4022dad7 in KMReaderWin::updateReaderWin (this=0x8117408) at kmreaderwin.cpp:996 #17 0x4023492f in KMReaderWin::qt_invoke (this=0x8117408, _id=47, _o=0xbffff1f8) at kmreaderwin.moc:271 #18 0x41b5f99a in QObject::activate_signal (this=0x81174b8, clist=0x813b0a8, o=0xbffff1f8) at kernel/qobject.cpp:2333 #19 0x41b5f7f4 in QObject::activate_signal (this=0x81174b8, signal=2) at kernel/qobject.cpp:2302 #20 0x41eb6336 in QTimer::timeout (this=0x81174b8) at .moc/debug-shared-mt/moc_qtimer.cpp:82 #21 0x41b82673 in QTimer::event (this=0x81174b8, e=0xbffff438) at kernel/qtimer.cpp:219 #22 0x41af8e15 in QApplication::internalNotify (this=0xbffff7a0, receiver=0x81174b8, e=0xbffff438) at kernel/qapplication.cpp:2582 #23 0x41af7efb in QApplication::notify (this=0xbffff7a0, receiver=0x81174b8, e=0xbffff438) at kernel/qapplication.cpp:2305 #24 0x4168e3d0 in KApplication::notify (this=0xbffff7a0, receiver=0x81174b8, event=0xbffff438) at kapplication.cpp:506 #25 0x41eab044 in QApplication::sendEvent (receiver=0x81174b8, event=0xbffff438) at .moc/debug-shared-mt/../../kernel/qapplication.h:492 #26 0x41ae765a in QEventLoop::activateTimers (this=0x8092f70) at kernel/qeventloop_unix.cpp:557 #27 0x41aa13fa in QEventLoop::processEvents (this=0x8092f70, flags=4) at kernel/qeventloop_x11.cpp:346 #28 0x41b0f590 in QEventLoop::enterLoop (this=0x8092f70) at kernel/qeventloop.cpp:198 #29 0x41b0f4c9 in QEventLoop::exec (this=0x8092f70) at kernel/qeventloop.cpp:145 #30 0x41af8fcd in QApplication::exec (this=0xbffff7a0) at kernel/qapplication.cpp:2705 #31 0x0804ae1a in main (argc=1, argv=0xbffff924) at main.cpp:115 ---------- assignedto: marc messages: 694 nosy: bh, marc priority: critical status: unread title: kmail crashes when fetching encrypted mails topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 15 19:00:44 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Thu Apr 15 18:57:51 2004 Subject: [issue153] wrong message when no secret key is found Message-ID: <1082048444.45.0.093218118278.issue153@intevation.de> New submission from Bernhard Herzog : When KMail (pre3 tag) has to decrypt a message for which no suitable secret key can be found KMail displays an error message about signatures and that even when the mail is not signed at all (which it wouldn't know because it can't look inside...): Not enough information to check signature. [Details] Status: No status information available. End of signed message This is probably related to Issue152 as it occurred after that was fixed. ---------- assignedto: marc messages: 705 nosy: bh, marc priority: urgent status: unread title: wrong message when no secret key is found topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 15 19:07:21 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Thu Apr 15 19:04:26 2004 Subject: [issue154] incorrect statistics for pkcs#12 imports Message-ID: <1082048841.08.0.726559415609.issue154@intevation.de> New submission from Bernhard Herzog : When importing a pkcs#12 file with only a secret key (as exported by kleopatra) and no corresponding certificate is known yet, the statistics in the results dialog box say that no secret keys have been imported even though the actually *has* been imported. If a suitable certificate is imported later the secret key can be used and e.g. exported again. This is probably a backend problem. ---------- assignedto: werner messages: 706 nosy: bh, werner priority: bug status: unread title: incorrect statistics for pkcs#12 imports topic: gpgsm ______________________________________________________ Aegypten issue tracker ______________________________________________________ From wk at gnupg.org Fri Apr 16 10:22:21 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Apr 16 10:06:22 2004 Subject: optional gpgme support for mutt In-Reply-To: <874qru4e2g.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 08 Apr 2004 18:41:43 +0200") References: <874qru4e2g.fsf@vigenere.g10code.de> Message-ID: <87u0zkib7m.fsf@vigenere.g10code.de> Hi! patch-1.5.6cvs.g10.gpgme.1.gz This patch enables Mutt to use GPGME based crypto; i.e. OpenPGP and S/MIME. You need a decent gpgme development package and a Mutt version with patch-1.5.6cvs.g10.cryptmod.1 already applied. To actually build with this support you have to use the configure option "--enable-gpgme". To use the GPGME backend you must add the line set crypt_use_gpgme to ~/.muttrc. Without that option the regular S/MIME and PGP support will we used. The latest gnupg-1.9.x version should be installed too (for S/MIEM and the gpg-agent). For details see http://www.gnupg.org/aegypten2/. The patch files are available at ftp://ftp.gnupg.org/gcrypt/alpga/aegypten/ mutt-patch-1.5.6cvs.g10.cryptmod.1.gz mutt-patch-1.5.6cvs.g10.gpgme.1.gz Apply both to the 1.5.6 tarball and do ./prepare --enable-gpgme && make I have not checked whether they still apply to the current CVS. The patch is about a week old; I merely forgot to announce the second one. Werner From moritz at g10code.com Fri Apr 16 17:26:07 2004 From: moritz at g10code.com (Moritz Schulte) Date: Sun Apr 18 18:56:33 2004 Subject: Libgcrypt-1.2.0 released Message-ID: We are pleased to announce the availability of Libgcrypt 1.2.0, which is the first stable release of this general purpose crypto library based on GnuPG code. Note, that Libgcrypt is neither a replacement for GnuPG nor does it contain a library version of GnuPG. It is only of interest for developers of crypto applications with a need for crypto building blocks available under the GNU Lesser General Public License. Complete source packages: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.0.tar.gz (927k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.0.tar.gz.sig Patch against version 1.9.94: ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.1.94-1.2.0.diff.gz (246k) Mirrors are listed at http://www.gnupg.org/download/mirrors.html. MD5 sums are: 5c508072d8387ce17d1ab05075c2be40 libgcrypt-1.2.0.tar.gz a1657523beebf926ca7992cc6b9ea9b5 libgcrypt-1.1.94-1.2.0.diff.gz Except for one bug fix this release is basically equivalent to the last pre-release. Thanks to all who have worked on Libgcrypt (and thanks to those who have worked on other things as well). Happy hacking. -- Moritz Schulte g10 Code GmbH http://www.g10code.com -=- The GnuPG Experts -=- From aegypten-issues at intevation.de Mon Apr 19 09:45:44 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Mon Apr 19 09:42:59 2004 Subject: [issue155] inline OpenPGP doesn't work at all Message-ID: <1082360744.55.0.1925072755.issue155@intevation.de> New submission from Marc Mutz : inline is quite differernt from the others in that it need the combined sign/encrypt operation, which the others don't need (they nest signing and encryption). ---------- assignedto: marc messages: 707 nosy: marc priority: bug status: unread title: inline OpenPGP doesn't work at all ______________________________________________________ Aegypten issue tracker ______________________________________________________ From michaelnottebrock at gmx.net Mon Apr 19 13:17:34 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 13:14:51 2004 Subject: Help, I'm confused (how to package cryptplug) Message-ID: <4083B54E.50901@gmx.net> Hi, As you might remember, I maintain a couple of freebsd ports which provide the the crypto plugins for KDE's kmail. Since the inclusion of gpg-agent and gpgsm into the gnupg-1.9.x versions, the deprecation of newpg and the recent updates to libgcrypt, all those programs have become ever harder to sync. Can anybody tell me what is the recommended way to provide the crypto plugins right now? Use the development branch of gnupg and libgcrypt-1.2.0? Are there distributions of pinentry and dirmngr available which will work with libgcrypt-1.2.0? I'm confused. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 260 bytes Desc: not available Url : /pipermail/attachments/20040419/4011b436/attachment.bin From wk at gnupg.org Mon Apr 19 14:27:04 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 19 14:11:20 2004 Subject: Help, I'm confused (how to package cryptplug) In-Reply-To: <4083B54E.50901@gmx.net> (Michael Nottebrock's message of "Mon, 19 Apr 2004 13:17:34 +0200") References: <4083B54E.50901@gmx.net> Message-ID: <87k70cdug7.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 13:17:34 +0200, Michael Nottebrock said: > gpg-agent and gpgsm into the gnupg-1.9.x versions, the deprecation of > newpg and the recent updates to libgcrypt, all those programs have > become ever harder to sync. Frankly, I hope that things will get better now. newpg used to be only a transitional package. > Can anybody tell me what is the recommended way to provide the crypto > plugins right now? Use the development branch of gnupg and For the old Kmail (the one using cryptplug), you definitely need to use gpgme-0.3.16. This will still work with the old backend but is of paramount importance when using the new backend. Using the new backend is definitley the way to go. That old newpg will not be maintained anymore. Thus for the *backend*, use the instructions given at www.gnupg.org/aegypten2/. I can't speak for the KDE part, though. > libgcrypt-1.2.0? Are there distributions of pinentry and dirmngr Yes please use libgcrypt 1.2 all over the palce, it is the first stable version and thus we will take great care not to break the ABI or API anymore. (Using 1.1.94 is okay too if you applied the patch I posted right after the release). The latest dirmngr and gnupg tarballs should all work fine with libgcrypt 1.2. pinentry does not need libgcrypt, but you need to take care which Qt version to use. Salam-Shalom, Werner From michaelnottebrock at gmx.net Mon Apr 19 14:23:08 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 14:20:40 2004 Subject: Help, I'm confused (how to package cryptplug) In-Reply-To: <87k70cdug7.fsf@vigenere.g10code.de> References: <4083B54E.50901@gmx.net> <87k70cdug7.fsf@vigenere.g10code.de> Message-ID: <200404191423.09004.michaelnottebrock@gmx.net> On Monday 19 April 2004 14:27, Werner Koch wrote: > On Mon, 19 Apr 2004 13:17:34 +0200, Michael Nottebrock said: > > gpg-agent and gpgsm into the gnupg-1.9.x versions, the deprecation of > > newpg and the recent updates to libgcrypt, all those programs have > > become ever harder to sync. > > Frankly, I hope that things will get better now. newpg used to be > only a transitional package. > > > Can anybody tell me what is the recommended way to provide the crypto > > plugins right now? Use the development branch of gnupg and > > For the old Kmail (the one using cryptplug), you definitely need to > use gpgme-0.3.16. This will still work with the old backend but is of > paramount importance when using the new backend. Just to make sure I'm getting this right: gnupg 1.9.x (== the backend?) can be built with both gpgme-0.3.16 (which I would need to do, since it's the gpgme version available in ports and I want to provide crypto plugins for the kmail in KDE_3_2_BRANCH) and gpgme-0.4.x? -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/1c139f1b/attachment-0001.bin From wk at gnupg.org Mon Apr 19 15:01:44 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 19 14:46:33 2004 Subject: Help, I'm confused (how to package cryptplug) In-Reply-To: <200404191423.09004.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Mon, 19 Apr 2004 14:23:08 +0200") References: <4083B54E.50901@gmx.net> <87k70cdug7.fsf@vigenere.g10code.de> <200404191423.09004.michaelnottebrock@gmx.net> Message-ID: <8765bwdsuf.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 14:23:08 +0200, Michael Nottebrock said: > Just to make sure I'm getting this right: gnupg 1.9.x (== the backend?) can be > built with both gpgme-0.3.16 (which I would need to do, since it's the gpgme Better to say: Applications linked against gpgme-0.3.16 may be *used* with GnuPG >= 1.9.x (as well as with the old newpg). GnuPG >= 1.9 may be used with any GPGME version >= 0.3.16 (including of course 0.4.x). > version available in ports and I want to provide crypto plugins for the kmail > in KDE_3_2_BRANCH) and gpgme-0.4.x? As I always get the Kmail/KDE versions wrong, Marc should answer this;-) Just to make it clear what the backend consists of: GnuPG 1.9 including the programs gpgsm, gpg2 gpg-agent, scdaemon and gpgconf (gpg2 is basically an older version of gpg 1.3.x and it is in general better to use the regular gpg (gnupg 1.2.x or gnupg 1.3.x) - thus we changed the name to gpg2) Dirmngr pinentry Well, actually it is a kind of hermaphrodite as it is used by the backend but actually be a part of the frontend (visible by the user) GPGME is part of the backend from the view of the developers but not from a user's POV because it is linked to Kmail and other KDE apps. Shalom-Salam, Werner From aegypten-issues at intevation.de Mon Apr 19 14:59:21 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Mon Apr 19 14:56:29 2004 Subject: [issue156] Improve message for truncated LDAP search output in Kleopatra Message-ID: <1082379561.72.0.953523093958.issue156@intevation.de> New submission from Jan-Oliver Wagner : Curently, if for a LDAP search more hits than the configured maximum are found a message box comes up and says "The server returned truncated output; please use a more-specific search string to get all results." This text is misleading. Better is something like "The query has more than N hits. N is the configured maximum that is returned for a query. You may either change the maximum in the configuration dialog or refine the query string." ---------- assignedto: marc messages: 716 nosy: jan, marc priority: bug status: unread title: Improve message for truncated LDAP search output in Kleopatra topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From michaelnottebrock at gmx.net Mon Apr 19 15:06:12 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 15:03:29 2004 Subject: Help, I'm confused (how to package cryptplug) In-Reply-To: <8765bwdsuf.fsf@vigenere.g10code.de> References: <4083B54E.50901@gmx.net> <200404191423.09004.michaelnottebrock@gmx.net> <8765bwdsuf.fsf@vigenere.g10code.de> Message-ID: <200404191506.16405.michaelnottebrock@gmx.net> On Monday 19 April 2004 15:01, Werner Koch wrote: > On Mon, 19 Apr 2004 14:23:08 +0200, Michael Nottebrock said: > > Just to make sure I'm getting this right: gnupg 1.9.x (== the backend?) > > can be built with both gpgme-0.3.16 (which I would need to do, since it's > > the gpgme > > Better to say: Applications linked against gpgme-0.3.16 may be *used* > with GnuPG >= 1.9.x (as well as with the old newpg). > > GnuPG >= 1.9 may be used with any GPGME version >= 0.3.16 (including > of course 0.4.x). Cool. > Just to make it clear what the backend consists of: > > [...] Thanks! -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/8aa52f29/attachment.bin From aegypten-issues at intevation.de Mon Apr 19 15:06:37 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Mon Apr 19 15:03:47 2004 Subject: [issue157] dows not work: Automatically add new servers discovered in CRL distributions points Message-ID: <1082379997.35.0.447877000321.issue157@intevation.de> New submission from Jan-Oliver Wagner : If I enable this feature in the Kleopatra configuration, delete the Intevation LDAP server and Validate my own certificate or one of the other ones of the Intevation CA, the Intevation LDAP is not added to the list as it should be. Maybe this is a backend-problem, but this should be clearified first. ---------- assignedto: marc messages: 718 nosy: jan, marc priority: bug status: unread title: dows not work: Automatically add new servers discovered in CRL distributions points topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From michaelnottebrock at gmx.net Mon Apr 19 15:44:51 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 15:42:04 2004 Subject: libassuan troubles Message-ID: <200404191544.55570.michaelnottebrock@gmx.net> I'm now trying to get the dependencies together for gnupg-1.9.x and libassuan seems to have many issues on FreeBSD: 1.) assuan-socket-connect.c and assuan-socket-server.c need an additional #include before #include (this bug exists in the local copies of libassuan in pinentry/dirmngr as well). 2.) assuan-domain-connect.c also needs sys/types.h included as described above and additionally needs to include isc/eventlib.h for the iovec structure. 3.) The replacement function for putc_unlocked.c does not compile: cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -O -pipe -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'putc_unlocked.c' || echo './'`putc_unlocked.c putc_unlocked.c:29: redefinition of `__sputc' /usr/include/stdio.h:361: `__sputc' previously defined here -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/88740a1a/attachment.bin From michaelnottebrock at gmx.net Mon Apr 19 16:28:41 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 16:25:56 2004 Subject: libassuan troubles In-Reply-To: <200404191544.55570.michaelnottebrock@gmx.net> References: <200404191544.55570.michaelnottebrock@gmx.net> Message-ID: <200404191628.45357.michaelnottebrock@gmx.net> On Monday 19 April 2004 15:44, Michael Nottebrock wrote: > 3.) The replacement function for putc_unlocked.c does not compile: > > cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -O -pipe -Wall > -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'putc_unlocked.c' || > echo './'`putc_unlocked.c > putc_unlocked.c:29: redefinition of `__sputc' > /usr/include/stdio.h:361: `__sputc' previously defined here I just remembered how I worked around that in the newpg port, autoconf's check for putc_unlocked is buggy and wrongly detects putc_unlocked as missing in FreeBSD... guess there's nothing you can do about that. ;-) -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/62b6b1b9/attachment.bin From wk at gnupg.org Mon Apr 19 16:41:03 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 19 16:26:18 2004 Subject: libassuan troubles In-Reply-To: <200404191544.55570.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Mon, 19 Apr 2004 15:44:51 +0200") References: <200404191544.55570.michaelnottebrock@gmx.net> Message-ID: <87r7ukav40.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 15:44:51 +0200, Michael Nottebrock said: > 1.) assuan-socket-connect.c and assuan-socket-server.c need an additional > #include before #include (this bug exists in the Thanks. > 2.) assuan-domain-connect.c also needs sys/types.h included as described above > and additionally needs to include isc/eventlib.h for the iovec structure. We need to to write a autoconf check for them. You may for now simply remove the function; it is currently not used. > 3.) The replacement function for putc_unlocked.c does not compile: > cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -O -pipe -Wall > -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'putc_unlocked.c' || > echo './'`putc_unlocked.c > putc_unlocked.c:29: redefinition of `__sputc' > /usr/include/stdio.h:361: `__sputc' previously defined here Seems that the configure check for putc_unlocked failed; can you please check this? Werner From wk at gnupg.org Mon Apr 19 16:46:55 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 19 16:46:12 2004 Subject: libassuan troubles In-Reply-To: <200404191544.55570.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Mon, 19 Apr 2004 15:44:51 +0200") References: <200404191544.55570.michaelnottebrock@gmx.net> Message-ID: <87n058auu8.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 15:44:51 +0200, Michael Nottebrock said: > #include before #include (this bug exists in the > local copies of libassuan in pinentry/dirmngr as well). pinentry uses a struipped down version of libassuan and dirmngr does not anymore source include libassuan. May it be that your versions are too old? Werner From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 19 16:34:51 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Apr 19 16:46:26 2004 Subject: libassuan troubles In-Reply-To: <200404191544.55570.michaelnottebrock@gmx.net> References: <200404191544.55570.michaelnottebrock@gmx.net> Message-ID: <87u0zgvxx0.wl@ulysses.g10code.de> At Mon, 19 Apr 2004 15:44:51 +0200, Michael Nottebrock wrote: > > 2.) assuan-domain-connect.c also needs sys/types.h included as described above > and additionally needs to include isc/eventlib.h for the iovec structure. The standard header for iovec is . Is that avaiable and defines struct iovec on your system? > 3.) The replacement function for putc_unlocked.c does not compile: > > cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -O -pipe -Wall > -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'putc_unlocked.c' || > echo './'`putc_unlocked.c > putc_unlocked.c:29: redefinition of `__sputc' > /usr/include/stdio.h:361: `__sputc' previously defined here This seems spurious. Maybe putc_unlocked is only defined as a macro on BSD, and thus circumvents the autoconf tests? This would sound broken to me (it may be allowed to define it as a macro, but it should still be defined as a function in the library). Thanks, Marcus From wk at gnupg.org Mon Apr 19 17:03:11 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 19 16:47:23 2004 Subject: libassuan troubles In-Reply-To: <200404191628.45357.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Mon, 19 Apr 2004 16:28:41 +0200") References: <200404191544.55570.michaelnottebrock@gmx.net> <200404191628.45357.michaelnottebrock@gmx.net> Message-ID: <87d664au34.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 16:28:41 +0200, Michael Nottebrock said: > for putc_unlocked is buggy and wrongly detects putc_unlocked as missing in > FreeBSD... guess there's nothing you can do about that. ;-) We need to fix the check of course. Has it been reported to the autoconf folks? Werner > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org > _______________________________________________ > Gpa-dev mailing list > Gpa-dev@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gpa-dev From michaelnottebrock at gmx.net Mon Apr 19 16:52:07 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 16:49:14 2004 Subject: libassuan troubles In-Reply-To: <87n058auu8.fsf@vigenere.g10code.de> References: <200404191544.55570.michaelnottebrock@gmx.net> <87n058auu8.fsf@vigenere.g10code.de> Message-ID: <200404191652.07489.michaelnottebrock@gmx.net> On Monday 19 April 2004 16:46, Werner Koch wrote: > On Mon, 19 Apr 2004 15:44:51 +0200, Michael Nottebrock said: > > #include before #include (this bug exists in > > the local copies of libassuan in pinentry/dirmngr as well). > > pinentry uses a struipped down version of libassuan and dirmngr does > not anymore source include libassuan. May it be that your versions > are too old? They're behind the latest releases indeed - I'm not sure why I didn't update them, perhaps there was trouble. I'll updating the whole bunch to the latest versions later and report any troubles I'm running into. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/b72dc039/attachment-0001.bin From michaelnottebrock at gmx.net Mon Apr 19 16:54:37 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 16:51:46 2004 Subject: libassuan troubles In-Reply-To: <87u0zgvxx0.wl@ulysses.g10code.de> References: <200404191544.55570.michaelnottebrock@gmx.net> <87u0zgvxx0.wl@ulysses.g10code.de> Message-ID: <200404191654.38213.michaelnottebrock@gmx.net> On Monday 19 April 2004 16:34, Marcus Brinkmann wrote: > This seems spurious. Maybe putc_unlocked is only defined as a macro > on BSD, and thus circumvents the autoconf tests? This would sound > broken to me (it may be allowed to define it as a macro, but it should > still be defined as a function in the library). Yes, it's a macro. However, I don't see what's wrong about that other than making autoconf's life harder. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/b3d07f34/attachment.bin From michaelnottebrock at gmx.net Mon Apr 19 17:12:25 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 17:09:39 2004 Subject: libassuan troubles In-Reply-To: <87d664au34.fsf@vigenere.g10code.de> References: <200404191544.55570.michaelnottebrock@gmx.net> <200404191628.45357.michaelnottebrock@gmx.net> <87d664au34.fsf@vigenere.g10code.de> Message-ID: <200404191712.25526.michaelnottebrock@gmx.net> On Monday 19 April 2004 17:03, Werner Koch wrote: > On Mon, 19 Apr 2004 16:28:41 +0200, Michael Nottebrock said: > > for putc_unlocked is buggy and wrongly detects putc_unlocked as missing > > in FreeBSD... guess there's nothing you can do about that. ;-) > > We need to fix the check of course. Has it been reported to the > autoconf folks? At least not by me. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/4e82d4dd/attachment.bin From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 19 17:15:08 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Apr 19 17:11:06 2004 Subject: libassuan troubles In-Reply-To: <200404191654.38213.michaelnottebrock@gmx.net> References: <200404191544.55570.michaelnottebrock@gmx.net> <87u0zgvxx0.wl@ulysses.g10code.de> <200404191654.38213.michaelnottebrock@gmx.net> Message-ID: <87pta4vw1v.wl@ulysses.g10code.de> At Mon, 19 Apr 2004 16:54:37 +0200, Michael Nottebrock wrote: > > [1 ] > On Monday 19 April 2004 16:34, Marcus Brinkmann wrote: > > > This seems spurious. Maybe putc_unlocked is only defined as a macro > > on BSD, and thus circumvents the autoconf tests? This would sound > > broken to me (it may be allowed to define it as a macro, but it should > > still be defined as a function in the library). > > Yes, it's a macro. However, I don't see what's wrong about that other than > making autoconf's life harder. putc_unlocked is specified as a function that may be defined as a macro. The fact that it is defined as a macro does not relief you from also declaring and defining it as a function. IE, the following must be possible in a program: #undef putc_unlocked putc_unlocked ('a'); At least this is my interpretation of the wording in POSIX. In fact, if you not only take into account the specification, but also the application usage, it becomes apparent: 16064 APPLICATION USAGE 16065 Since they may be implemented as macros, getc_unlocked( ) and putc_unlocked( ) may treat 16066 incorrectly a stream argument with side effects. In particular, getc_unlocked(*f++) and 16067 putc_unlocked(*f++) do not necessarily work as expected. Therefore, use of these functions in 16068 such situations should be preceded by the following statement as appropriate: 16069 #undef getc_unlocked 16070 #undef putc_unlocked The autoconf test relies on the function in the library object file. This will work for almost all functions, except those for which POSIX explicitely allows the lack of a function definition (like setjmp, FD_CLR, etc). Thanks, Marcus From michaelnottebrock at gmx.net Mon Apr 19 17:44:46 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 17:41:59 2004 Subject: libassuan troubles In-Reply-To: <87pta4vw1v.wl@ulysses.g10code.de> References: <200404191544.55570.michaelnottebrock@gmx.net> <200404191654.38213.michaelnottebrock@gmx.net> <87pta4vw1v.wl@ulysses.g10code.de> Message-ID: <200404191744.46403.michaelnottebrock@gmx.net> On Monday 19 April 2004 17:15, Marcus Brinkmann wrote: > At Mon, 19 Apr 2004 16:54:37 +0200, > > Michael Nottebrock wrote: > > [1 ] > > > > On Monday 19 April 2004 16:34, Marcus Brinkmann wrote: > > > This seems spurious. Maybe putc_unlocked is only defined as a macro > > > on BSD, and thus circumvents the autoconf tests? This would sound > > > broken to me (it may be allowed to define it as a macro, but it should > > > still be defined as a function in the library). > > > > Yes, it's a macro. However, I don't see what's wrong about that other > > than making autoconf's life harder. > > putc_unlocked is specified as a function that may be defined as a > macro. The fact that it is defined as a macro does not relief you > from also declaring and defining it as a function. It seems our standards guys agree and indeed FreeBSD 5 has putc_unlocked defined in libc and the autoconf check does work there, too, so only FreeBSD 4.x is affected. I'm not sure if that's still worth the trouble of adding a special case (in libassuan or autoconf). -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/0186563c/attachment.bin From michaelnottebrock at gmx.net Mon Apr 19 18:58:40 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 18:55:54 2004 Subject: gnupg 1.9.7 troubles Message-ID: <200404191858.43384.michaelnottebrock@gmx.net> With the libassuan issues solved, I've proceeded to gnupg-1.9.7 and again had to jump a few hurdles: 1.) In common/fopencookie.c, the compilation fails with fopencookie.c:31: syntax error before `cookie_io_functions_t' I can work around that by recycling a typedef from the newpg sources: #include "util.h" +typedef struct +{ + ssize_t (*read)(void*,char*,size_t); + ssize_t (*write)(void*,const char*,size_t); + int (*seek)(void*,off_t*,int); + int (*close)(void*); +} _IO_cookie_io_functions_t; +typedef _IO_cookie_io_functions_t cookie_io_functions_t; + FILE * fopencookie (void *cookie, const char *opentype, cookie_io_functions_t funclist) 2.) kbx/keybox-blob.c and kbx/keybox-dump.c need to include ../jnlib/types.h in order to compile: +#include "../jnlib/types.h" #include "keybox-defs.h" 3.) agent/gpg-agent.c needs additional includes as well: # include #endif +#include +#include + #define JNLIB_NEED_LOG_LOGV #include "agent.h" #include /* malloc hooks */ 4.) cc -I/usr/local/include -O -pipe -mcpu=pentiumpro -I/usr/local/include -L/usr/local/lib -Wall -L/usr/local/lib -L/usr/local/lib -o gpgconf gpgconf.o gpgconf-comp.o no-libgcrypt.o ../jnlib/libjnlib.a ../common/libcommon.a /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib -lz gpgconf-comp.o: In function `retrieve_options_from_program': gpgconf-comp.o(.text+0xd15): undefined reference to `getline' gpgconf-comp.o(.text+0xfe5): undefined reference to `getline' gpgconf-comp.o: In function `retrieve_options_from_file': gpgconf-comp.o(.text+0x1282): undefined reference to `getline' gpgconf-comp.o: In function `change_options_file': gpgconf-comp.o(.text+0x1ada): undefined reference to `getline' gpgconf-comp.o(.text+0x1c98): undefined reference to `getline' gpgconf-comp.o(.text+0x2029): more undefined references to `getline' follow I haven't found a workaround for that one yet. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/22b6c2aa/attachment.bin From michaelnottebrock at gmx.net Mon Apr 19 19:20:57 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 19:18:11 2004 Subject: gnupg 1.9.7 troubles In-Reply-To: <200404191858.43384.michaelnottebrock@gmx.net> References: <200404191858.43384.michaelnottebrock@gmx.net> Message-ID: <200404191920.58254.michaelnottebrock@gmx.net> On Monday 19 April 2004 18:58, Michael Nottebrock wrote: > 4.) cc -I/usr/local/include -O -pipe -mcpu=pentiumpro -I/usr/local/include > -L/usr/local/lib -Wall -L/usr/local/lib -L/usr/local/lib -o gpgconf > gpgconf.o gpgconf-comp.o > no-libgcrypt.o ../jnlib/libjnlib.a ../common/libcommon.a > /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib -lz > gpgconf-comp.o: In function `retrieve_options_from_program': > gpgconf-comp.o(.text+0xd15): undefined reference to `getline' > gpgconf-comp.o(.text+0xfe5): undefined reference to `getline' > gpgconf-comp.o: In function `retrieve_options_from_file': > gpgconf-comp.o(.text+0x1282): undefined reference to `getline' > gpgconf-comp.o: In function `change_options_file': > gpgconf-comp.o(.text+0x1ada): undefined reference to `getline' > gpgconf-comp.o(.text+0x1c98): undefined reference to `getline' > gpgconf-comp.o(.text+0x2029): more undefined references to `getline' follow > > I haven't found a workaround for that one yet. I just read in the source that this is a known issue. It would seem I need to go back a few versions to get one that will compile on !glibc platforms such as FreeBSD - are there any serious issues with version 1.9.3 or is it safe to use for the moment? -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/bc3bf1d4/attachment.bin From wk at gnupg.org Mon Apr 19 20:04:06 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 19 19:46:16 2004 Subject: libassuan troubles In-Reply-To: <200404191744.46403.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Mon, 19 Apr 2004 17:44:46 +0200") References: <200404191544.55570.michaelnottebrock@gmx.net> <200404191654.38213.michaelnottebrock@gmx.net> <87pta4vw1v.wl@ulysses.g10code.de> <200404191744.46403.michaelnottebrock@gmx.net> Message-ID: <871xmjc0a1.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 17:44:46 +0200, Michael Nottebrock said: > It seems our standards guys agree and indeed FreeBSD 5 has putc_unlocked > defined in libc and the autoconf check does work there, too, so only FreeBSD > 4.x is affected. I'm not sure if that's still worth the trouble of adding a > special case (in libassuan or autoconf). The autoconf check should indeed catch this for FreeBSD < 5. Werner From wk at gnupg.org Mon Apr 19 20:08:42 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 19 19:51:16 2004 Subject: gnupg 1.9.7 troubles In-Reply-To: <200404191858.43384.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Mon, 19 Apr 2004 18:58:40 +0200") References: <200404191858.43384.michaelnottebrock@gmx.net> Message-ID: <87wu4balhx.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 18:58:40 +0200, Michael Nottebrock said: > 1.) In common/fopencookie.c, the compilation fails with > fopencookie.c:31: syntax error before `cookie_io_functions_t' There is again a problem with an autoconf check. I checked the whole stuff once on netbsd. *BSD provides funopen and at most places we use funopen and emulate it using fopencookie on glibc. > +#include "../jnlib/types.h" > #include "keybox-defs.h" Hmmm....are you sure that your system is properly configured? Did you override the CFLAGS? > gpgconf-comp.o(.text+0xd15): undefined reference to `getline' Okay this is known. Werner From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 19 19:58:48 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Apr 19 19:54:48 2004 Subject: libassuan troubles In-Reply-To: <871xmjc0a1.fsf@vigenere.g10code.de> References: <200404191544.55570.michaelnottebrock@gmx.net> <200404191654.38213.michaelnottebrock@gmx.net> <87pta4vw1v.wl@ulysses.g10code.de> <200404191744.46403.michaelnottebrock@gmx.net> <871xmjc0a1.fsf@vigenere.g10code.de> Message-ID: <87oepnx31j.wl@ulysses.g10code.de> At Mon, 19 Apr 2004 20:04:06 +0200, Werner Koch wrote: > > On Mon, 19 Apr 2004 17:44:46 +0200, Michael Nottebrock said: > > > It seems our standards guys agree and indeed FreeBSD 5 has putc_unlocked > > defined in libc and the autoconf check does work there, too, so only FreeBSD > > 4.x is affected. I'm not sure if that's still worth the trouble of adding a > > special case (in libassuan or autoconf). > > The autoconf check should indeed catch this for FreeBSD < 5. The autoconf check (AC_CHECK_FUNCS) is not at fault. It does exactly what it is supposed to do. If anything, we could hack in a special check for FreeBSD based on the target OS to not check with AC_REPLACE_FUNC, but hardwire HAVE_PUTC_UNLOCKED. Thanks, Marcus From michaelnottebrock at gmx.net Mon Apr 19 20:17:26 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 20:14:42 2004 Subject: gnupg 1.9.7 troubles In-Reply-To: <87wu4balhx.fsf@vigenere.g10code.de> References: <200404191858.43384.michaelnottebrock@gmx.net> <87wu4balhx.fsf@vigenere.g10code.de> Message-ID: <200404192017.29518.michaelnottebrock@gmx.net> On Monday 19 April 2004 20:08, Werner Koch wrote: > On Mon, 19 Apr 2004 18:58:40 +0200, Michael Nottebrock said: > > 1.) In common/fopencookie.c, the compilation fails with > > > > fopencookie.c:31: syntax error before `cookie_io_functions_t' > > There is again a problem with an autoconf check. FWIW, config.h yields: /* #undef HAVE_FOPENCOOKIE */ and #define HAVE_FUNOPEN 1 which is correct. > I checked the whole > stuff once on netbsd. *BSD provides funopen and at most places we use > funopen and emulate it using fopencookie on glibc. > > > +#include "../jnlib/types.h" > > #include "keybox-defs.h" > > Hmmm....are you sure that your system is properly configured? Did you > override the CFLAGS? This is readily reproducable on several systems (and it's been an issue back in newpg as well). The errors are: cc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl -DLOCALEDIR=\"/usr/local/share/locale\" -I../common -I../intl -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -O -pipe -I/usr/local/include -L/usr/local/lib -Wall -c `test -f 'keybox-blob.c' || echo './'`keybox-blob.c In file included from keybox-blob.c:116: /usr/local/include/gcrypt.h:174: warning: `struct timeval' declared inside parameter list /usr/local/include/gcrypt.h:174: warning: its scope is only this definition or declaration, which is probably not what you want. keybox-blob.c:149: syntax error before `ulong' keybox-blob.c:153: syntax error before `ulong' keybox-blob.c: In function `create_blob_header': keybox-blob.c:554: structure has no member named `off_kid_addr' keybox-blob.c:568: structure has no member named `off_addr' keybox-blob.c:603: structure has no member named `off_kid_addr' keybox-blob.c:608: structure has no member named `off_kid_addr' keybox-blob.c:609: structure has no member named `off_kid_addr' keybox-blob.c:622: structure has no member named `off_addr' and cc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl -DLOCALEDIR=\"/usr/local/share/locale\" -I../common -I../intl -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -O -pipe -I/usr/local/include -L/usr/local/lib -Wall -c `test -f 'keybox-dump.c' || echo './'`keybox-dump.c keybox-dump.c:30: syntax error before `get32' keybox-dump.c:31: warning: return-type defaults to `int' keybox-dump.c: In function `get32': keybox-dump.c:32: syntax error before `a' keybox-dump.c:33: `a' undeclared (first use in this function) keybox-dump.c:33: (Each undeclared identifier is reported only once keybox-dump.c:33: for each function it appears in.) keybox-dump.c:38: warning: control reaches end of non-void function keybox-dump.c: At top level: keybox-dump.c:41: syntax error before `get16' keybox-dump.c:42: warning: return-type defaults to `int' keybox-dump.c: In function `get16': keybox-dump.c:43: syntax error before `a' keybox-dump.c:44: `a' undeclared (first use in this function) keybox-dump.c:47: warning: control reaches end of non-void function keybox-dump.c: In function `_keybox_dump_blob': keybox-dump.c:95: syntax error before `n' keybox-dump.c:110: `n' undeclared (first use in this function) keybox-dump.c:163: `rawdata_off' undeclared (first use in this function) keybox-dump.c:164: `rawdata_len' undeclared (first use in this function) keybox-dump.c:169: `nkeys' undeclared (first use in this function) keybox-dump.c:176: `keyinfolen' undeclared (first use in this function) keybox-dump.c:180: warning: left-hand operand of comma expression has no effect keybox-dump.c:183: syntax error before `kidoff' keybox-dump.c:188: `kidoff' undeclared (first use in this function) keybox-dump.c:194: `kflags' undeclared (first use in this function) keybox-dump.c:200: `nserial' undeclared (first use in this function) keybox-dump.c:206: warning: left-hand operand of comma expression has no effect keybox-dump.c:212: `nuids' undeclared (first use in this function) keybox-dump.c:214: `uidinfolen' undeclared (first use in this function) keybox-dump.c:218: warning: left-hand operand of comma expression has no effect keybox-dump.c:220: syntax error before `uidoff' keybox-dump.c:222: `uidoff' undeclared (first use in this function) keybox-dump.c:223: `uidlen' undeclared (first use in this function) keybox-dump.c:244: `uflags' undeclared (first use in this function) keybox-dump.c:262: `nsigs' undeclared (first use in this function) keybox-dump.c:264: `siginfolen' undeclared (first use in this function) keybox-dump.c:268: warning: left-hand operand of comma expression has no effect keybox-dump.c:270: syntax error before `sflags' keybox-dump.c:272: `sflags' undeclared (first use in this function) -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040419/922c982c/attachment.bin From wk at gnupg.org Mon Apr 19 20:56:36 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 19 20:41:19 2004 Subject: libassuan troubles In-Reply-To: <87oepnx31j.wl@ulysses.g10code.de> (Marcus Brinkmann's message of "Mon, 19 Apr 2004 19:58:48 +0200") References: <200404191544.55570.michaelnottebrock@gmx.net> <200404191654.38213.michaelnottebrock@gmx.net> <87pta4vw1v.wl@ulysses.g10code.de> <200404191744.46403.michaelnottebrock@gmx.net> <871xmjc0a1.fsf@vigenere.g10code.de> <87oepnx31j.wl@ulysses.g10code.de> Message-ID: <87r7ujaja3.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 19:58:48 +0200, Marcus Brinkmann said: > The autoconf check (AC_CHECK_FUNCS) is not at fault. It does exactly > what it is supposed to do. If anything, we could hack in a special > check for FreeBSD based on the target OS to not check with > AC_REPLACE_FUNC, but hardwire HAVE_PUTC_UNLOCKED. Please do that. Although that gnupg 1.9 does currently not support Slowaris etc. we should make it as easy as possible for the common Free OSes. FreeBSD 4 is still in widespread use and if KDE runs on it, gnupg 1.9 must be able to run there too. Werner From michaelnottebrock at gmx.net Mon Apr 19 22:17:52 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Apr 19 22:15:06 2004 Subject: libassuan troubles In-Reply-To: <87n058auu8.fsf@vigenere.g10code.de> References: <200404191544.55570.michaelnottebrock@gmx.net> <87n058auu8.fsf@vigenere.g10code.de> Message-ID: <200404192217.54092.michaelnottebrock@gmx.net> On Monday 19 April 2004 16:46, Werner Koch wrote: > On Mon, 19 Apr 2004 15:44:51 +0200, Michael Nottebrock said: > > #include before #include (this bug exists in > > the local copies of libassuan in pinentry/dirmngr as well). > > pinentry uses a struipped down version of libassuan and dirmngr does > not anymore source include libassuan. May it be that your versions > are too old? dirmngr does compile without any problems, but pinentry, even the latest version from CVS, still contains a bogus check for fopencookie and bails during configure stage if it isn't found. Btw: The autogen.sh script fails with FreeBSD's /bin/sh: if [ $(( `("$1" --version || echo "0") | cvtver` >= $2 )) == 1 ] ^ one too many -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org From michaelnottebrock at gmx.net Tue Apr 20 00:04:43 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Tue Apr 20 00:02:01 2004 Subject: libassuan troubles In-Reply-To: <200404192217.54092.michaelnottebrock@gmx.net> References: <200404191544.55570.michaelnottebrock@gmx.net> <87n058auu8.fsf@vigenere.g10code.de> <200404192217.54092.michaelnottebrock@gmx.net> Message-ID: <200404200004.47309.michaelnottebrock@gmx.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040420/13a9fb9e/attachment.bin From wk at gnupg.org Tue Apr 20 07:08:34 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 20 06:51:29 2004 Subject: libassuan troubles In-Reply-To: <200404200004.47309.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Tue, 20 Apr 2004 00:04:43 +0200") References: <200404191544.55570.michaelnottebrock@gmx.net> <87n058auu8.fsf@vigenere.g10code.de> <200404192217.54092.michaelnottebrock@gmx.net> <200404200004.47309.michaelnottebrock@gmx.net> Message-ID: <873c6z9qy5.fsf@vigenere.g10code.de> On Tue, 20 Apr 2004 00:04:43 +0200, Michael Nottebrock said: > I've checked out pinentry from CVS again and hacked at it until it compiled. Aiihh. I fixed this on Jan 30 but obviously I forgot to commit it. Please try the current CVS again. Werner From wk at gnupg.org Tue Apr 20 09:19:22 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 20 09:01:19 2004 Subject: gnupg 1.9.7 troubles In-Reply-To: <200404192017.29518.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Mon, 19 Apr 2004 20:17:26 +0200") References: <200404191858.43384.michaelnottebrock@gmx.net> <87wu4balhx.fsf@vigenere.g10code.de> <200404192017.29518.michaelnottebrock@gmx.net> Message-ID: <87oepn86bp.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 20:17:26 +0200, Michael Nottebrock said: >> > +#include "../jnlib/types.h" >> > #include "keybox-defs.h" You are right, we need to track the definitions for byte, u16 and u32. This won't allow us to keep the KBX part source-separated from the rest of the system but that's okay. I'll commit a fix in a few minutes. Thanks, Werner From wk at gnupg.org Tue Apr 20 09:23:23 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 20 09:06:15 2004 Subject: gnupg 1.9.7 troubles In-Reply-To: <200404192017.29518.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Mon, 19 Apr 2004 20:17:26 +0200") References: <200404191858.43384.michaelnottebrock@gmx.net> <87wu4balhx.fsf@vigenere.g10code.de> <200404192017.29518.michaelnottebrock@gmx.net> Message-ID: <87k70b8650.fsf@vigenere.g10code.de> On Mon, 19 Apr 2004 20:17:26 +0200, Michael Nottebrock said: > FWIW, config.h yields: > /* #undef HAVE_FOPENCOOKIE */ Okay, the problem was that we still included an AC_REPLACE_FUNCS for fopencookie, alhough we didn't used it in this way. I have removed the test and fopencokkie.c. Thanks, Werner From michaelnottebrock at gmx.net Tue Apr 20 11:20:51 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Tue Apr 20 11:18:02 2004 Subject: libassuan troubles In-Reply-To: <873c6z9qy5.fsf@vigenere.g10code.de> References: <200404191544.55570.michaelnottebrock@gmx.net> <200404200004.47309.michaelnottebrock@gmx.net> <873c6z9qy5.fsf@vigenere.g10code.de> Message-ID: <200404201120.54515.michaelnottebrock@gmx.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040420/f23d3caf/attachment.bin From wk at gnupg.org Tue Apr 20 12:20:16 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 20 12:06:11 2004 Subject: libassuan troubles In-Reply-To: <200404201120.54515.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Tue, 20 Apr 2004 11:20:51 +0200") References: <200404191544.55570.michaelnottebrock@gmx.net> <200404200004.47309.michaelnottebrock@gmx.net> <873c6z9qy5.fsf@vigenere.g10code.de> <200404201120.54515.michaelnottebrock@gmx.net> Message-ID: <8765bv7xy7.fsf@vigenere.g10code.de> On Tue, 20 Apr 2004 11:20:51 +0200, Michael Nottebrock said: > My patches for assuan/mkerrors and secmem/secmem.c are still needed here. > Without the extra newline after the EOF in assuan/mkerrors, I get Okay. > and without the extra typedef in secmem/secmem.c I get I solved that in a different way. Please check out the latest CVS. If pinentry works for you I will do a new release. Thanks, Werner From michaelnottebrock at gmx.net Tue Apr 20 12:38:40 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Tue Apr 20 12:35:57 2004 Subject: libassuan troubles In-Reply-To: <8765bv7xy7.fsf@vigenere.g10code.de> References: <200404191544.55570.michaelnottebrock@gmx.net> <200404201120.54515.michaelnottebrock@gmx.net> <8765bv7xy7.fsf@vigenere.g10code.de> Message-ID: <200404201238.44482.michaelnottebrock@gmx.net> On Tuesday 20 April 2004 12:20, Werner Koch wrote: > Please check out the latest CVS. If pinentry works for you I will do > a new release. Working now out of the box. Thanks! -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: signature Url : /pipermail/attachments/20040420/f6074d13/attachment.bin From aegypten-issues at intevation.de Tue Apr 20 18:35:04 2004 From: aegypten-issues at intevation.de (Marcus Brinkmann) Date: Tue Apr 20 18:32:10 2004 Subject: [issue159] gpg-error should initialize locale Message-ID: <1082478904.03.0.473245389588.issue159@intevation.de> New submission from Marcus Brinkmann : gpg-error should initialize the locale, so you can see the localized messages. ---------- messages: 748 nosy: marcus priority: minor bug status: deferred title: gpg-error should initialize locale ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Apr 20 18:14:37 2004 From: aegypten-issues at intevation.de (Marcus Brinkmann) Date: Tue Apr 20 19:36:35 2004 Subject: [issue158] gpgconf should not keep too many backup files Message-ID: <1082477677.01.0.76036194551.issue158@intevation.de> New submission from Marcus Brinkmann : gpgconf currently creates a backup file each time a conf file is changed. Of course, this is superfluous, although it is convenient while debugging and testing. Eventually, the superfluous backup files should be removed. However, it is not clear if it is good enough to keep only the last backup file, or several. ---------- messages: 747 nosy: marcus priority: minor bug status: deferred title: gpgconf should not keep too many backup files topic: gpg ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 21 16:24:45 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 21 16:21:56 2004 Subject: [issue160] kwatchgnupg: always error message when chaninging config Message-ID: <1082557485.34.0.174409311526.issue160@intevation.de> New submission from Jan-Oliver Wagner : Each time I change one of the config options of kwatchgnupg, a error message dialog is raised telling that the operation is not allowed. However, it seems that the changes are commited though. ---------- assignedto: marc messages: 752 nosy: jan, marc priority: bug status: unread title: kwatchgnupg: always error message when chaninging config topic: Kwatchgnupg ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 21 16:28:11 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 21 16:25:22 2004 Subject: [issue161] kwatchgnupg: config button behaving strange Message-ID: <1082557691.7.0.270972201277.issue161@intevation.de> New submission from Jan-Oliver Wagner : When I change a option and hit Appy, the OK and Aply are greyed out and I only can hit Cancel to leave the dialog. Usually that means that the changes are reverted and not applied. But here the changes are applied. The button functionality should be clarified. Either no Apply button or revertable Cancel-functionality. ---------- assignedto: marc messages: 753 nosy: jan, marc priority: bug status: unread title: kwatchgnupg: config button behaving strange ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 21 16:30:13 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 21 16:27:23 2004 Subject: [issue162] kwatchgnupg: no word wrapping Message-ID: <1082557813.47.0.669388183815.issue162@intevation.de> New submission from Jan-Oliver Wagner : Configuring word wrapping changes nothing in the view. Lines are still longer than the window. So, AFAIKS this is a bug. ---------- assignedto: marc messages: 754 nosy: jan, marc priority: minor bug status: unread title: kwatchgnupg: no word wrapping topic: Kwatchgnupg ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 21 16:33:37 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 21 16:30:45 2004 Subject: [issue163] kwatchgnupg: umlauts not discplayed correctly Message-ID: <1082558017.75.0.706699023732.issue163@intevation.de> New submission from Jan-Oliver Wagner : If the debug output contains some German Umlauts (e.g. in DN), these Umlauts are not displayed correctly. ---------- assignedto: marc messages: 755 nosy: jan, marc priority: minor bug status: unread title: kwatchgnupg: umlauts not discplayed correctly topic: Kwatchgnupg ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 21 17:53:39 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 21 17:50:44 2004 Subject: [issue164] kwatchgnupg: No documentation Message-ID: <1082562819.19.0.0749930345036.issue164@intevation.de> New submission from Jan-Oliver Wagner : There is no handbook comeing up when the corresponding menu item is selected. I guess it is not yet written. There must be a handbook that explains the GUI, the configuration and where/how to read about watchgnupg. ---------- assignedto: marc messages: 758 nosy: jan, marc priority: bug status: unread title: kwatchgnupg: No documentation topic: Kwatchgnupg ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 21 17:55:05 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 21 17:52:11 2004 Subject: [issue165] kwatchgnupg: Translation into german Message-ID: <1082562905.8.0.079101247433.issue165@intevation.de> New submission from Jan-Oliver Wagner : Once all other issues on kwatchgnupg are resolved, the translation of the GUI and of the Manual should be made. ---------- assignedto: marc messages: 759 nosy: jan, marc priority: bug status: unread title: kwatchgnupg: Translation into german topic: Kwatchgnupg ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 21 18:57:37 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 21 18:54:41 2004 Subject: [issue166] certmanager reports wrong number when importung certs Message-ID: <1082566657.51.0.498364720801.issue166@intevation.de> New submission from Jan-Oliver Wagner : Export a single certificate into a file. Import it again: Message says that 3 certificates have not been considered. The message should say: 1 ---------- assignedto: marc messages: 761 nosy: jan, marc priority: bug status: unread title: certmanager reports wrong number when importung certs topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 21 19:38:47 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 21 19:35:53 2004 Subject: [issue167] Store displayed messages unencrypted Message-ID: <1082569126.77.0.707871561736.issue167@intevation.de> New submission from Jan-Oliver Wagner : The option in kmailrc [Reader]store-displayed-messages-unencrypted=true does not work. I tried a simple signed&encrypted SMIME E-Mail. It is a good idea to inform the user each time a encryption has been removed from a mail. I even think that a message box popping up is a good idea. Furthermore, this option must be documented in the KMail handbook ---------- assignedto: marc messages: 765 nosy: jan, marc priority: bug status: unread title: Store displayed messages unencrypted topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From wk at gnupg.org Wed Apr 21 21:51:42 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 21 21:36:13 2004 Subject: pinentry 0.7.1 released Message-ID: <871xmh3y9d.fsf@vigenere.g10code.de> Hi! I have just release pinentry 0.7.1 which fixes a a couple of minor bugs and should build fine on FreeBSD and probably also on *BSD. ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.7.1.tar.gz (339k) ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.7.1.tar.gz.sig Or as a patch agains 0.7.0: ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.7.0-0.7.1.diff.gz (38k) Happy Hacking, Werner -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org From aegypten-issues at intevation.de Thu Apr 22 15:32:11 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Thu Apr 22 15:29:19 2004 Subject: [issue168] non-ascii wrong in pkcs12 export Message-ID: <1082640731.82.0.232757438419.issue168@intevation.de> New submission from Bernhard Herzog : When exporting secret keys with kleopatra, non-ascii characters in the text displayed by pinentry is handled incorrectly. When exporting a secret key, a pinentry window comes up two times, once to unlock the secret key, and once to protect the pkcs12. When using pinentry-gtk, non-ascii characters are shown incorrectly in the first message, but correctly in the second. When using pinetry-qt it's the other way round. my guess is that the lc-ctype is not communicated to the pinentry, and that the second message is in the locale's ctype and not in utf8. This looks mostly like a backend bug to me. ---------- assignedto: werner messages: 779 nosy: bh, werner status: unread title: non-ascii wrong in pkcs12 export topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From mutz at kde.org Fri Apr 23 09:32:06 2004 From: mutz at kde.org (Marc Mutz) Date: Fri Apr 23 09:41:22 2004 Subject: Help, I'm confused (how to package cryptplug) In-Reply-To: <200404191423.09004.michaelnottebrock@gmx.net> References: <4083B54E.50901@gmx.net> <87k70cdug7.fsf@vigenere.g10code.de> <200404191423.09004.michaelnottebrock@gmx.net> Message-ID: <200404230932.10072.mutz@kde.org> On Monday 19 April 2004 14:23, Michael Nottebrock wrote: > Just to make sure I'm getting this right: gnupg 1.9.x (== the > backend?) can be built with both gpgme-0.3.16 (which I would need to > do, since it's the gpgme version available in ports and I want to > provide crypto plugins for the kmail in KDE_3_2_BRANCH) and > gpgme-0.4.x? KDE_3_{1,2}_BRANCH only works with CryptPlugs, which require gpgme 0.3.x. Note that due to a bug in KMail, you will need a post-KDE 3.1.5 KMail for the new backend to work (3.2.x is fine), ie. from CVS. We will do a release of HEAD kdepim as "kdepim 3.3 for KDE 3.2" later this year, which will include a KMail that doesn't use CryptPlugs anymore, and which requires gpgme >= 0.4.5. Hope this helps, Marc -- The DMCA is unconstitutional, but they don't care. Until it's ruled unconstitutional, they've won. If they can scare software companies, ISPs, programmers, and T-shirt manufacturers [...] into submission, they've won for another day. The entertainment industry is fighting a holding action, and fear, uncertainty, and doubt are their weapons. We need to win this, and we need to win it quickly. Every day we don't win is a loss. -- Bruce Schneier, Crypto-Gram Aug 2001 From aegypten-issues at intevation.de Fri Apr 23 19:02:19 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Fri Apr 23 18:59:25 2004 Subject: [issue169] certificate selection dialog allows selection of invalid keys Message-ID: <1082739739.46.0.302328771769.issue169@intevation.de> New submission from Bernhard Herzog : The certificate selection dialog allows the selection of invalid keys even when it is able to determine the validity correctly. For instance when you have separate keys for encryption and signing the dialog by default doesn't show the encryption cert when a signature cert is to be selected. However, when the "hide invalid keys" checkbox is unchecked, it is shown too an can be selected. Most of the time if such an invalid key is selected the OK button is grayed out. It can happen, though, that it isn't. It happens especially just after the checkbox has been unchecked and the newly visible key is selected. Furthermore, when a key is selected and the dialog closed by double clicking on the key, the key is selected regardless of whether it is valid or not. ---------- assignedto: marc messages: 802 nosy: bh, marc priority: minor bug status: unread title: certificate selection dialog allows selection of invalid keys topic: KMail, libkleopatra ______________________________________________________ Aegypten issue tracker ______________________________________________________ From jmartin at desertflood.com Fri Apr 23 15:49:42 2004 From: jmartin at desertflood.com (Joseph A. Martin) Date: Sat Apr 24 10:07:01 2004 Subject: Installing Agypten with KDE 3.2 Message-ID: <200404230949.42580.jmartin@desertflood.com> Hi, I am using Debian unstable with KDE3.2 installed. I've been trying off and on for the past six months to install the Agypten plugins with KMail. I would like to be able to sign/encrypt my e-mails using S/MIME encryption. Is this possible with Debian and Agypten? Can I use the Debian compiled KMail or do I have to build my own? Does the Debian KMail (3.2.2) require patching? What packages (and versions) do I need? I've tried (several times) following the instructions found on http://www.gnupg.org/aegypten/development.en.html. When I load the plugin into KMail, I get the following error: Error: Plug-in "GPGMe-SMIME" initialization unsuccessful. library: /usr/lib/cryptplug/gpgme-smime.so version: 0.3.16 Plug-in is out-dated or not installed properly. At this point, the actual software on my system is a complete mixture of Debian and locally compiled packages. I should probably clean it out and start over from scratch. But first I want to know if it is possible, exactly what versions of what packages need to be used, and how to do it. Can I use Agypten with the S/MIME plugin to sign/encrypt e-mail on KMail 1.6.2 (KDE 3.2.2)? Thanks! ~joe -- Joseph (LittleRed) Martin jmartin@desertflood.com http://www.desertflood.com/ From jmartin at desertflood.com Sat Apr 24 17:24:01 2004 From: jmartin at desertflood.com (Joseph A. Martin) Date: Mon Apr 26 15:32:38 2004 Subject: Installing Agypten with KDE 3.2 In-Reply-To: <200404230949.42580.jmartin@desertflood.com> References: <200404230949.42580.jmartin@desertflood.com> Message-ID: <200404241124.01826.jmartin@desertflood.com> After aggressively cleaning out old versions of the Agypten libraries and following the instructions at http://www.gnupg.org/aegypten2/index.html (but still using cryptplug for the KMail interface), I finally managed to compile a S/MIME plugin that works with KMail. I can view encrypted S/MIME messages that were sent to me. After entering my password, I am able to view the decrypted contents. However, I am not able to check the signature on the e-mail. I see the following message instead: "Not enough information to check signature. [Details] Status: A system error occurred." When I attempt to send signed e-mails, KMail hangs. The processor utilization goes to 100% and KMail appears totally frozen. I used ps to check running processes. It appears that KMail is continually re-launching gpgsm. gpgsm launches gpg-agent. Apparently gpg-agent dies or quits, gpgsm then dies or quits and KMail relaunches everything. Any ideas? I am running the following versions of the libraries: cryptplug-0.3.16 gpgme-0.3.16 libgpg-error-0.7 dirmngr-0.5.2 libassuan-0.6.4 libksba-0.9.5 gnupg-1.9.7 libgcrypt-1.2.0 pinentry-0.7.1 KMail 1.6.2 (from KDE 3.2.2) On Friday 23 April 2004 09:49 am, Joseph A. Martin wrote: > Hi, > > I am using Debian unstable with KDE3.2 installed. I've been trying off and > on for the past six months to install the Agypten plugins with KMail. I > would like to be able to sign/encrypt my e-mails using S/MIME encryption. > Is this possible with Debian and Agypten? Can I use the Debian compiled > KMail or do I have to build my own? Does the Debian KMail (3.2.2) require > patching? What packages (and versions) do I need? > > I've tried (several times) following the instructions found on > http://www.gnupg.org/aegypten/development.en.html. When I load the plugin > into KMail, I get the following error: > > Error: Plug-in "GPGMe-SMIME" initialization unsuccessful. > library: /usr/lib/cryptplug/gpgme-smime.so > version: 0.3.16 > Plug-in is out-dated or not installed properly. > > At this point, the actual software on my system is a complete mixture of > Debian and locally compiled packages. I should probably clean it out and > start over from scratch. But first I want to know if it is possible, > exactly what versions of what packages need to be used, and how to do it. > > Can I use Agypten with the S/MIME plugin to sign/encrypt e-mail on KMail > 1.6.2 (KDE 3.2.2)? > > Thanks! > > ~joe -- Joseph (LittleRed) Martin jmartin@desertflood.com http://www.desertflood.com/ From mutz at kde.org Mon Apr 26 16:37:51 2004 From: mutz at kde.org (Marc Mutz) Date: Mon Apr 26 16:47:48 2004 Subject: Installing Agypten with KDE 3.2 In-Reply-To: <200404241124.01826.jmartin@desertflood.com> References: <200404230949.42580.jmartin@desertflood.com> <200404241124.01826.jmartin@desertflood.com> Message-ID: <200404261637.55542.mutz@kde.org> On Saturday 24 April 2004 17:24, Joseph A. Martin wrote: > gpgme-0.3.16 You need 0.3.17 for gnupg 1.9.x -- Ich gegen meinen Bruder. Ich und mein Bruder gegen unseren Cousin. Ich, mein Bruder und unser Cousin gegen unsere Nachbarn. Wir alle gegen den Fremden. -- Beduinen-Sprichwort From wk at gnupg.org Mon Apr 26 17:27:28 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 26 17:10:58 2004 Subject: Installing Agypten with KDE 3.2 In-Reply-To: <200404261637.55542.mutz@kde.org> (Marc Mutz's message of "Mon, 26 Apr 2004 16:37:51 +0200") References: <200404230949.42580.jmartin@desertflood.com> <200404241124.01826.jmartin@desertflood.com> <200404261637.55542.mutz@kde.org> Message-ID: <87d65uyd27.fsf@vigenere.g10code.de> On Mon, 26 Apr 2004 16:37:51 +0200, Marc Mutz said: > On Saturday 24 April 2004 17:24, Joseph A. Martin wrote: >> gpgme-0.3.16 > You need 0.3.17 for gnupg 1.9.x Sorry, there is no gpgme-0.3.17 - 0.3.16 is okay. Werner From aegypten-issues at intevation.de Mon Apr 26 17:42:53 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Mon Apr 26 17:56:28 2004 Subject: [issue170] show certificate dump in kleopatra Message-ID: <1082994173.64.0.458300912826.issue170@intevation.de> New submission from Bernhard Herzog : Kleopatra needs a way to display all information about a certificate that gpgsm can provide. The --dump-keys option was added to gpgsm for this purpose already. Now kleopatry should show the output of that command in the details view. ---------- assignedto: marc messages: 820 nosy: bh, marc priority: urgent status: unread title: show certificate dump in kleopatra topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 12:18:17 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Wed Apr 28 12:15:25 2004 Subject: [issue171] make all composer crypto operations async Message-ID: <1083147497.96.0.0154077844719.issue171@intevation.de> New submission from Marc Mutz : And provide a progress bar and cancel button, like in Kleopatra. ---------- messages: 825 nosy: marc priority: wish status: unread title: make all composer crypto operations async topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 12:19:11 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Wed Apr 28 12:16:22 2004 Subject: [issue172] make all reader crypto operations async Message-ID: <1083147551.73.0.567380832941.issue172@intevation.de> New submission from Marc Mutz : And provide a progress bar and cancel button, like in Kleopatra. ---------- messages: 826 nosy: marc priority: wish status: unread title: make all reader crypto operations async topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 12:21:30 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Wed Apr 28 12:18:32 2004 Subject: [issue173] OpenPGP-Integration for Kleopatra. Message-ID: <1083147690.12.0.289631498751.issue173@intevation.de> New submission from Marc Mutz : Allow side-by-side view of OpenPGP and S/MIME keys, extend the view-details dialog and enable the edit interface for OpenPGP keys. ---------- messages: 827 nosy: marc priority: wish status: unread title: OpenPGP-Integration for Kleopatra. topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 12:26:14 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Wed Apr 28 12:23:17 2004 Subject: [issue174] Add a debug stream that writes to the watchgnupg socket, for backend-synchronised messages from applications. Message-ID: <1083147974.07.0.338202624336.issue174@intevation.de> New submission from Marc Mutz : API should look like gpgLog("kmail") << "starting decryption of message " << msg->subject() << endl; Implementation hint: create std::ostream or QTextStream on the socket and return that. ---------- messages: 828 nosy: marc priority: feature status: unread title: Add a debug stream that writes to the watchgnupg socket, for backend-synchronised messages from applications. topic: libkleopatra ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 12:33:39 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Wed Apr 28 12:30:44 2004 Subject: [issue175] create semi-automatic migration tool for encryption preferences from kpgprc to kaddressbook Message-ID: <1083148419.0.0.303553318718.issue175@intevation.de> New submission from Marc Mutz : See $subject. ---------- messages: 829 nosy: marc priority: wish status: unread title: create semi-automatic migration tool for encryption preferences from kpgprc to kaddressbook ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 16:34:45 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 28 16:31:48 2004 Subject: [issue176] Kleopatra: Stop Operation does not work Message-ID: <1083162885.71.0.366335620012.issue176@intevation.de> New submission from Jan-Oliver Wagner : First, the menu item "Stop Operation" should be bound to ESC by default. The main problem is: executing this command during a LDAP search seems to have no effect. The search always ends with "done" in the status bar. There should be a information "operation stopped" or something like that if the operaiton is stopped. ---------- assignedto: marc messages: 834 nosy: jan, marc priority: critical status: unread title: Kleopatra: Stop Operation does not work topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 16:43:10 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 28 16:40:14 2004 Subject: [issue177] Kleopatra: collapse and expand for hierarchical view Message-ID: <1083163390.63.0.554378838421.issue177@intevation.de> New submission from Jan-Oliver Wagner : Add two menu items after hierrarchical view: Collapse all Expand all (or any other UI that helps with getting a better overview on the certificates) ---------- assignedto: marc messages: 835 nosy: jan, marc priority: bug status: unread title: Kleopatra: collapse and expand for hierarchical view topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 16:50:57 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 28 16:48:01 2004 Subject: [issue178] Kleopatra: DN Config: empty at startup Message-ID: <1083163857.38.0.027154948426.issue178@intevation.de> New submission from Jan-Oliver Wagner : Entering the DN config dialog the first time, in the list to the right there is no item, not even _X_. But Kleopatra shows the DN. This is not consistent. If the right list is empty, actually no DN Info should be displayed. ---------- assignedto: marc messages: 836 nosy: jan, marc priority: bug status: unread title: Kleopatra: DN Config: empty at startup topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 16:53:08 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 28 16:50:14 2004 Subject: [issue179] Kleopatra: DN Config: not possible to set a single element Message-ID: <1083163988.19.0.463506977355.issue179@intevation.de> New submission from Jan-Oliver Wagner : In the DN config dialog: If I specify only C to use, actually C and afterwards some others are shown. Onl specifying C should only show C, shouldn't it? ---------- assignedto: marc messages: 837 nosy: jan, marc priority: bug status: unread title: Kleopatra: DN Config: not possible to set a single element topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 16:55:10 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 28 16:52:14 2004 Subject: [issue180] Kleopatra: translation into german Message-ID: <1083164110.82.0.0599513403868.issue180@intevation.de> New submission from Jan-Oliver Wagner : Once all other GUI issues on Kleopatra are resolved, the translation of the GUI and of the Manual should be made. ---------- assignedto: marc messages: 838 nosy: jan, marc priority: bug status: unread title: Kleopatra: translation into german topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 16:57:08 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Wed Apr 28 16:54:12 2004 Subject: [issue181] Kleopatra: complete documentation Message-ID: <1083164228.86.0.824298092355.issue181@intevation.de> New submission from Jan-Oliver Wagner : The documentation is no yet updated with the new GUI and configuration features. This should be done right after feature completenss. ---------- assignedto: marc messages: 839 nosy: jan, marc priority: bug status: unread title: Kleopatra: complete documentation topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Wed Apr 28 17:36:00 2004 From: aegypten-issues at intevation.de (Bernhard Reiter) Date: Wed Apr 28 17:33:07 2004 Subject: [issue182] MDN not integrated Message-ID: <1083166560.4.0.396802448208.issue182@intevation.de> New submission from Bernhard Reiter : Mutt 1.5.6i (2004-02-01) patch-1.5.6cvs.g10.cryptmod.1 patch-1.5.6cvs.g10.gpgme.1 Error in .muttrc, line 8: mdn_enable: unknown variable Error in .muttrc, line 9: mdn_confirm: unknown variable Error in .muttrc, line 12: mdn_dnt_defaults: unknown command Error in .muttrc, line 13: mdn_dnt_defaults: unknown command ---------- assignedto: werner messages: 840 nosy: bernhard, jan, werner priority: minor bug status: unread title: MDN not integrated topic: mutt ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 29 00:13:07 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Thu Apr 29 00:10:14 2004 Subject: [issue183] backend takes up to 10 secs until a cancellation request is completed. Message-ID: <1083190386.83.0.82585235149.issue183@intevation.de> New submission from Marc Mutz : (assigned to gpgme for now - might be dirmngr's fault) Start a search in external certificates in Kleopatra, and then hit 'Esc' (to cancel the operation). Kleo freezes a few seconds, then shows the "Canceled." message in the statusbar. This delay is too long. The user sees a frozen app, and if she tries fast enough to close it, even the frozen-app-catcher (think xkill-wrapper) kicks in and offers to kill the unresponsive application. ---------- assignedto: marcus messages: 849 nosy: marc, marcus priority: bug status: unread title: backend takes up to 10 secs until a cancellation request is completed. topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 29 13:37:31 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Thu Apr 29 13:34:47 2004 Subject: [issue184] gpgme: no error propagation for validating keylisting Message-ID: <1083238649.84.0.554832894341.issue184@intevation.de> New submission from Marc Mutz : When validating an old key of mine, I get the following watchgnupg output (see CRL too old), but that error is not propagated back to the application, nor seems there to be a way to do this in the more-than-one-key case: operation-done event: Breakpoint 3, GpgME::EventLoopInteractor::Private::eventIOCb(void*, gpgme_event_io_t, void*) (data=0x813f1d0, type=GPGME_EVENT_DONE, type_data=0xbffff0f8) (gdb) p *(gpgme_error_t*)type_data $7 = 0 watchgnupg output: [2004-04-29T13:26:03] Log started [client at fd 7 connected] 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: -> OK GNU Privacy Guard's S/M server ready 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: <- OPTION display=:0 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: -> OK 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: <- OPTION ttyname=/dev/pts/2 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: -> OK 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: <- OPTION ttytype=xterm 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: -> OK 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: <- OPTION lc-ctype=C 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: -> OK 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: <- OPTION lc-messages=C 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: -> OK 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: <- OPTION list-mode=1 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: -> OK 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: <- OPTION with-validation=1 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: -> OK 7 - 2004-04-29 13:26:10 gpgsm[29667.0x807b3b8] DBG: <- LISTKEYS 67348E8ACF3DFBB38121353B528130280665A867 [client at fd 8 connected] 8 - 2004-04-29 13:26:10 gpg-agent[4720]: handler for fd 0 started 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: -> OK Your orders please 7 - 2004-04-29 13:26:10 gpgsm[29667]: DBG: connection to agent established 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: <- RESET 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: -> OK 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: <- OPTION display=:0 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: -> OK 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: <- OPTION ttyname=/dev/pts/2 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: -> OK 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: <- OPTION ttytype=xterm 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: -> OK 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: <- OPTION lc-ctype=C 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: -> OK 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: <- OPTION lc-messages=C 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: -> OK 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: <- HAVEKEY CC196D8407CB29D2919947748D09AA9E19B8439C 8 - 2004-04-29 13:26:10 gpg-agent[4720.0x808c030] DBG: -> OK 7 - 2004-04-29 13:26:10 gpgsm[29667]: no running dirmngr - starting one [client at fd 9 connected] 9 - 2004-04-29 13:26:10 dirmngr[29668.0x80646b8] DBG: -> OK Dirmngr 0.5.4-cvs at your service 7 - 2004-04-29 13:26:10 gpgsm[29667]: DBG: connection to dirmngr established 9 - 2004-04-29 13:26:10 dirmngr[29668.0x80646b8] DBG: <- ISVALID 6834DCA5687039635544337EC5EB5DDEF81C90C0.0B 9 - 2004-04-29 13:26:10 dirmngr[29668]: no CRL available for issuer id 6834DCA5687039635544337EC5EB5DDEF81C90C0 9 - 2004-04-29 13:26:10 dirmngr[29668.0x80646b8] DBG: -> INQUIRE SENDCERT 9 - 2004-04-29 13:26:10 dirmngr[29668.0x80646b8] DBG: <- [ 44 20 30 82 03 6d 30 82 02 d6 a0 03 02 01 02 02 01 0b 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 30 3a 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 11 30 0f 06 03 55 04 03 0c 08 54 65 73 74 2d 5a 53 33 30 1e 17 25 30 44 30 33 30 31 31 34 31 34 33 33 34 33 5a 17 25 30 44 30 33 30 37 31 33 31 34 33 33 34 33 5a 30 4d 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 0c 30 25 30 41 06 03 55 04 07 13 03 6f 72 67 31 0c 30 25 30 41 06 03 55 04 25 30 41 13 03 4b 44 45 31 0e 30 0c 06 03 55 04 0b 13 05 4b 4d 61 69 6c 31 12 30 10 06 03 55 04 03 13 09 4d 61 72 63 20 4d 75 74 7a 30 81 9f 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 b0 06 4e 90 16 9e 44 19 13 91 cf 1e 4c ae 7a 88 8d 4d cb 7a f9 d6 56 9a dc aa 06 e8 a2 98 ef 83 27 b4 b4 2f b3 5c 3b d8 3d b5 8a 0e c7 d3 a7 bf 52 5c 97 f2 15 61 73 cf 81 fd 03 93 33 78 3a af 56 25 30 41 e8 e1 c8 98 58 e2 35 89 52 a7 66 b3 fe c5 f5 74 8f 6d e2 f4 9a 6b ca 25 32 35 99 3a d4 ce 95 bb c8 c2 13 fb 89 09 d8 5c 43 e6 a3 71 c6 a8 81 ff 78 4d 7c f2 69 55 99 11 b4 ee eb fa eb a5 ba 75 02 03 01 00 01 a3 82 01 6e 30 82 01 6a 30 0c 06 03 55 1d 13 01 01 ff 04 02 30 00 30 0e 06 03 55 1d 0f 01 01 ff 04 04 03 02 05 e0 30 6c 06 03 55 1d 1f 04 65 30 63 30 61 a0 5f a0 5d 86 5b 6c 64 61 70 3a 2f 2f 74 68 65 74 69 73 2e 69 6e 74 65 76 61 74 69 6f 6e 2e 6f 72 67 2f 63 6e 3d 54 65 73 74 2d 5a 53 33 2c 20 6f 3d 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 2c 20 63 3d 44 45 3f 63 65 72 74 69 66 69 63 61 74 65 52 65 76 6f 63 61 74 69 6f 6e 4c 69 73 74 30 3e 06 09 60 86 48 01 86 f8 42 01 25 30 44 04 31 16 2f 43 65 72 74 69 66 69 63 61 74 65 20 67 65 6e 65 72 61 74 65 64 20 62 79 20 c3 84 67 79 70 74 65 6e 20 50 72 6f 6a 65 63 74 20 63 72 65 77 2e 30 1d 06 03 55 1d 0e 04 16 04 14 e2 bc 5f ff 21 fa 0b 78 47 a3 1d 2a 6c 6c d7 c8 32 f2 f1 e3 30 64 06 03 55 1d 23 04 5d 30 5b 80 14 09 40 f1 73 93 0e 42 03 8b 3e 60 4d 5e ce 95 4e 69 8a 75 9e a1 40 a4 3e 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 82 01 03 30 17 06 03 55 1d 11 04 10 30 0e 81 0c 6d 75 74 7a 40 6b 64 65 2e 6f 72 67 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 03 81 81 00 44 c3 b1 f2 e4 6d 0e 08 7b 2a 65 47 ad fc 4d 3a 7d 4d b2 5e 3a 64 ef e8 9c a4 03 e9 c1 d8 20 4f c1 40 4c a1 c3 4b 8c cc 7f 94 35 cf b2 d2 83 b1 9f 1b 0f 77 0b bf e9 11 e2 3f d6 65 16 b2 b5 4b c6 39 9d dc 1f 7e 82 4d 6e 11 0e 8a b0 99 a8 49 f8 24 f4 f1 60 b1 72 25 30 44 3d 04 fd 09 5d cc 3f d7 5d f7 4a e9 a2 9f 5a da 04 88 ff 99 3d 24 85 81 ed f8 3a 5f 9c 66 25 32 35 dd a3 fa 59 f6 02 82 52 68 ] 9 - 2004-04-29 13:26:10 dirmngr[29668.0x80646b8] DBG: <- END 9 - 2004-04-29 13:26:16 dirmngr[29668]: found attributes `certificateRevocationList;binary' at second try 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: -> INQUIRE SENDCERT CN=Test-ZS3,O=Intevation GmbH,C=DE 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- [ 44 20 30 82 03 c6 30 82 03 2f a0 03 02 01 02 02 01 03 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 30 1e 17 25 30 44 30 32 30 37 30 31 31 36 33 31 31 38 5a 17 25 30 44 30 33 30 37 30 31 31 36 33 31 31 38 5a 30 3a 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 11 30 0f 06 03 55 04 03 0c 08 54 65 73 74 2d 5a 53 33 30 81 9f 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 bf 1f 25 30 41 3c 6d fc 5f 13 0e b7 f3 64 db 02 ac a0 fa d0 08 0e b6 56 fa d3 6b 12 8b c0 8a 64 f1 00 ff 9c 7e 56 c6 9e 9d cd 05 39 68 ae 5f eb bc f3 b7 10 f1 b0 60 d8 d8 d7 92 60 6c 33 9c 09 c2 b3 9a 9a 3e 5f 54 76 e5 c2 c7 da 8d 9d 41 c3 a9 2a 9c 26 71 d1 41 f5 b1 03 d4 fa 03 0c 19 f8 73 aa 55 34 8d 44 b1 fd 33 7f 12 35 c9 59 23 be 9d 38 d0 68 e0 8e 4e bd 58 3e 2f d9 a6 dc 04 e4 b1 cd 02 03 01 00 01 a3 82 01 d8 30 82 01 d4 30 0f 06 03 55 1d 13 01 01 ff 04 05 30 03 01 01 ff 30 0b 06 03 55 1d 0f 04 04 03 02 01 06 30 6e 06 03 55 1d 1f 04 67 30 65 30 63 a0 61 a0 5f 86 5d 6c 64 61 70 3a 2f 2f 74 68 65 74 69 73 2e 69 6e 74 65 76 61 74 69 6f 6e 2e 6f 72 67 2f 63 6e 3d 54 65 73 74 2d 50 4b 49 20 32 2c 20 6f 3d 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 2c 20 63 3d 44 45 3f 63 65 72 74 69 66 69 63 61 74 65 52 65 76 6f 63 61 74 69 6f 6e 4c 69 73 74 30 47 06 09 60 86 48 01 86 f8 42 01 25 30 44 04 3a 16 38 43 65 72 74 69 66 69 63 61 74 65 20 69 73 73 75 65 64 20 62 79 20 c3 84 67 79 70 74 65 6e 20 50 72 6f 6a 65 63 74 20 63 72 65 77 20 66 6f 72 20 74 65 73 74 69 6e 67 2e 30 1d 06 03 55 1d 0e 04 16 04 14 09 40 f1 73 93 0e 42 03 8b 3e 60 4d 5e ce 95 4e 69 8a 75 9e 30 64 06 03 55 1d 23 04 5d 30 5b 80 14 22 55 58 18 27 1c aa b8 21 d7 5a bc cb 90 de 01 21 e8 47 a3 a1 40 a4 3e 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 82 01 00 30 3a 06 03 55 1d 11 04 33 30 31 81 18 69 6e 74 65 76 61 74 69 6f 6e 40 69 6e 74 65 76 61 74 69 6f 6e 2e 64 65 86 15 68 74 74 70 3a 2f 2f 69 6e 74 65 76 61 74 69 6f 6e 2e 6e 65 74 30 3a 06 03 55 1d 12 04 33 30 31 81 18 69 6e 74 65 76 61 74 69 6f 6e 40 69 6e 74 65 76 61 74 69 6f 6e 2e 64 65 86 15 68 74 74 70 3a 2f 2f 69 6e 74 65 76 61 74 69 6f 6e 2e 6e 65 74 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 03 81 81 00 6a 7a 27 90 c5 2e c8 20 28 e1 1f a3 17 3b 37 bf 84 70 a8 da 43 4c 93 0c 53 25 30 44 27 38 be 22 9a c8 77 43 e6 e6 94 b9 e8 f6 94 c5 16 64 df 08 74 02 41 c9 13 7f cb 94 58 a2 86 ae 27 03 b4 78 82 54 d8 8c ca 35 7b dc 12 e9 f6 52 78 e2 3b 92 68 f0 92 86 35 7a 23 90 78 20 ca 4d 25 30 44 3a 28 20 6b 7a 6d 6e cc 19 31 89 d1 32 dc ae 93 1e 9e aa e9 3c a8 c9 a1 3d 7c 55 db 94 ] 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- [ 44 20 47 11 37 57 8b 1e 8d 97 ] 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- END 9 - 2004-04-29 13:26:16 dirmngr[29668]: update times of this CRL: this=20030612T162434 next=20030703T162434 9 - 2004-04-29 13:26:16 dirmngr[29668]: new CRL still too old; it expired on 20030703T162434 9 - 2004-04-29 13:26:16 dirmngr[29668]: crl_cache_insert via DP failed: CRL too old 9 - 2004-04-29 13:26:16 dirmngr[29668]: command ISVALID failed: CRL too old 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: -> ERR 167772256 CRL too old 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- ISVALID F93F11EB77C81BA819676BA892CBA89A95C9C344.03 9 - 2004-04-29 13:26:16 dirmngr[29668]: no CRL available for issuer id F93F11EB77C81BA819676BA892CBA89A95C9C344 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: -> INQUIRE SENDCERT 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- [ 44 20 30 82 03 c6 30 82 03 2f a0 03 02 01 02 02 01 03 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 30 1e 17 25 30 44 30 32 30 37 30 31 31 36 33 31 31 38 5a 17 25 30 44 30 33 30 37 30 31 31 36 33 31 31 38 5a 30 3a 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 11 30 0f 06 03 55 04 03 0c 08 54 65 73 74 2d 5a 53 33 30 81 9f 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 bf 1f 25 30 41 3c 6d fc 5f 13 0e b7 f3 64 db 02 ac a0 fa d0 08 0e b6 56 fa d3 6b 12 8b c0 8a 64 f1 00 ff 9c 7e 56 c6 9e 9d cd 05 39 68 ae 5f eb bc f3 b7 10 f1 b0 60 d8 d8 d7 92 60 6c 33 9c 09 c2 b3 9a 9a 3e 5f 54 76 e5 c2 c7 da 8d 9d 41 c3 a9 2a 9c 26 71 d1 41 f5 b1 03 d4 fa 03 0c 19 f8 73 aa 55 34 8d 44 b1 fd 33 7f 12 35 c9 59 23 be 9d 38 d0 68 e0 8e 4e bd 58 3e 2f d9 a6 dc 04 e4 b1 cd 02 03 01 00 01 a3 82 01 d8 30 82 01 d4 30 0f 06 03 55 1d 13 01 01 ff 04 05 30 03 01 01 ff 30 0b 06 03 55 1d 0f 04 04 03 02 01 06 30 6e 06 03 55 1d 1f 04 67 30 65 30 63 a0 61 a0 5f 86 5d 6c 64 61 70 3a 2f 2f 74 68 65 74 69 73 2e 69 6e 74 65 76 61 74 69 6f 6e 2e 6f 72 67 2f 63 6e 3d 54 65 73 74 2d 50 4b 49 20 32 2c 20 6f 3d 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 2c 20 63 3d 44 45 3f 63 65 72 74 69 66 69 63 61 74 65 52 65 76 6f 63 61 74 69 6f 6e 4c 69 73 74 30 47 06 09 60 86 48 01 86 f8 42 01 25 30 44 04 3a 16 38 43 65 72 74 69 66 69 63 61 74 65 20 69 73 73 75 65 64 20 62 79 20 c3 84 67 79 70 74 65 6e 20 50 72 6f 6a 65 63 74 20 63 72 65 77 20 66 6f 72 20 74 65 73 74 69 6e 67 2e 30 1d 06 03 55 1d 0e 04 16 04 14 09 40 f1 73 93 0e 42 03 8b 3e 60 4d 5e ce 95 4e 69 8a 75 9e 30 64 06 03 55 1d 23 04 5d 30 5b 80 14 22 55 58 18 27 1c aa b8 21 d7 5a bc cb 90 de 01 21 e8 47 a3 a1 40 a4 3e 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 82 01 00 30 3a 06 03 55 1d 11 04 33 30 31 81 18 69 6e 74 65 76 61 74 69 6f 6e 40 69 6e 74 65 76 61 74 69 6f 6e 2e 64 65 86 15 68 74 74 70 3a 2f 2f 69 6e 74 65 76 61 74 69 6f 6e 2e 6e 65 74 30 3a 06 03 55 1d 12 04 33 30 31 81 18 69 6e 74 65 76 61 74 69 6f 6e 40 69 6e 74 65 76 61 74 69 6f 6e 2e 64 65 86 15 68 74 74 70 3a 2f 2f 69 6e 74 65 76 61 74 69 6f 6e 2e 6e 65 74 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 03 81 81 00 6a 7a 27 90 c5 2e c8 20 28 e1 1f a3 17 3b 37 bf 84 70 a8 da 43 4c 93 0c 53 25 30 44 27 38 be 22 9a c8 77 43 e6 e6 94 b9 e8 f6 94 c5 16 64 df 08 74 02 41 c9 13 7f cb 94 58 a2 86 ae 27 03 b4 78 82 54 d8 8c ca 35 7b dc 12 e9 f6 52 78 e2 3b 92 68 f0 92 86 35 7a 23 90 78 20 ca 4d 25 30 44 3a 28 20 6b 7a 6d 6e cc 19 31 89 d1 32 dc ae 93 1e 9e aa e9 3c a8 c9 a1 3d 7c 55 db 94 ] 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- [ 44 20 47 11 37 57 8b 1e 8d 97 ] 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- END 9 - 2004-04-29 13:26:16 dirmngr[29668]: found attributes `certificateRevocationList;binary' at second try 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: -> INQUIRE SENDCERT CN=Test-PKI 2,O=Intevation GmbH,C=DE 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- [ 44 20 30 82 03 31 30 82 02 9a a0 03 02 01 02 02 01 00 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 30 1e 17 25 30 44 30 32 30 36 32 37 31 39 35 37 32 34 5a 17 25 30 44 30 33 30 36 32 37 31 39 35 37 32 34 5a 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 30 81 9f 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 ce 8b b3 b3 a8 2e a8 57 46 ef df 71 ab 2a 52 57 f8 3c 4b 6e 76 a5 dc fa b2 69 a6 35 c8 0c 98 2b 5f 44 c6 22 c2 d5 ce 3a 8f 90 94 d6 ed f4 4a 1c 01 91 b3 d5 86 a3 d5 ea c0 eb fa a2 eb 8a be c6 f6 6d 91 82 15 03 8f aa be 5f 2a e7 f7 7b ab fe 0f 4d c6 24 44 92 05 f0 b6 d7 00 0b 2a 25 32 35 34 3b ef 74 6b 20 fb fe aa 95 44 4e 15 05 1f 21 b3 e7 fb c7 8a 63 fd a5 c8 8c df e4 f6 85 d7 be 56 6d 02 03 01 00 01 a3 82 01 41 30 82 01 3d 30 1d 06 03 55 1d 0e 04 16 04 14 22 55 58 18 27 1c aa b8 21 d7 5a bc cb 90 de 01 21 e8 47 a3 30 64 06 03 55 1d 23 04 5d 30 5b 80 14 22 55 58 18 27 1c aa b8 21 d7 5a bc cb 90 de 01 21 e8 47 a3 a1 40 a4 3e 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 82 01 00 30 0f 06 03 55 1d 13 01 01 ff 04 05 30 03 01 01 ff 30 69 06 03 55 1d 1f 04 62 55 52 49 3a 6c 64 61 70 3a 2f 2f 74 68 65 74 69 73 2e 69 6e 74 65 76 61 74 69 6f 6e 2e 6f 72 67 2f 63 6e 3d 54 65 73 74 2d 50 4b 49 20 31 2c 20 6f 3d 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 2c 20 63 3d 44 45 3f 63 65 72 74 69 66 69 63 61 74 65 52 65 76 6f 63 61 74 69 6f 6e 4c 69 73 74 25 30 41 30 3a 06 03 55 1d 11 04 33 30 31 81 18 69 6e 74 65 76 61 74 69 6f 6e 40 69 6e 74 65 76 61 74 69 6f 6e 2e 64 65 86 15 68 74 74 70 3a 2f 2f 69 6e 74 65 76 61 74 69 6f 6e 2e 6e 65 74 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 03 81 81 00 b0 98 45 a7 68 00 0b 00 12 2a 97 41 12 6c 01 33 c8 2b 89 f1 fb fc 44 82 50 3c 49 4b 61 92 72 fc 21 31 7f 33 79 10 2b 14 eb 75 f0 65 61 3c 91 27 e5 46 4c 89 5e 6f 46 29 25 30 41 a0 13 13 9e d5 46 c1 8d 17 60 35 cc 0c 3e 5f e8 ba e0 3e fb dd f5 55 3a 6b 48 23 00 ed aa cf bf 5e 05 84 bb 7f f5 05 28 f5 09 df 5c 67 2d e6 3a a3 7e 86 08 3f 70 32 43 da 60 c1 c3 ff 8d 13 dc 0c be 13 d4 c1 8d 0c ] 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- END 9 - 2004-04-29 13:26:16 dirmngr[29668]: update times of this CRL: this=20030623T154853 next=20030629T154853 9 - 2004-04-29 13:26:16 dirmngr[29668]: new CRL still too old; it expired on 20030629T154853 9 - 2004-04-29 13:26:16 dirmngr[29668]: crl_cache_insert via DP failed: CRL too old 9 - 2004-04-29 13:26:16 dirmngr[29668]: command ISVALID failed: CRL too old 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: -> ERR 167772256 CRL too old 8 - 2004-04-29 13:26:16 gpg-agent[4720.0x808c030] DBG: <- ISTRUSTED 959BF86A3BDE383E97006EB9AF546F0720881AA7 8 - 2004-04-29 13:26:16 gpg-agent[4720.0x808c030] DBG: -> OK 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- ISVALID F93F11EB77C81BA819676BA892CBA89A95C9C344.00 9 - 2004-04-29 13:26:16 dirmngr[29668]: no CRL available for issuer id F93F11EB77C81BA819676BA892CBA89A95C9C344 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: -> INQUIRE SENDCERT 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- [ 44 20 30 82 03 31 30 82 02 9a a0 03 02 01 02 02 01 00 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 30 1e 17 25 30 44 30 32 30 36 32 37 31 39 35 37 32 34 5a 17 25 30 44 30 33 30 36 32 37 31 39 35 37 32 34 5a 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 30 81 9f 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 ce 8b b3 b3 a8 2e a8 57 46 ef df 71 ab 2a 52 57 f8 3c 4b 6e 76 a5 dc fa b2 69 a6 35 c8 0c 98 2b 5f 44 c6 22 c2 d5 ce 3a 8f 90 94 d6 ed f4 4a 1c 01 91 b3 d5 86 a3 d5 ea c0 eb fa a2 eb 8a be c6 f6 6d 91 82 15 03 8f aa be 5f 2a e7 f7 7b ab fe 0f 4d c6 24 44 92 05 f0 b6 d7 00 0b 2a 25 32 35 34 3b ef 74 6b 20 fb fe aa 95 44 4e 15 05 1f 21 b3 e7 fb c7 8a 63 fd a5 c8 8c df e4 f6 85 d7 be 56 6d 02 03 01 00 01 a3 82 01 41 30 82 01 3d 30 1d 06 03 55 1d 0e 04 16 04 14 22 55 58 18 27 1c aa b8 21 d7 5a bc cb 90 de 01 21 e8 47 a3 30 64 06 03 55 1d 23 04 5d 30 5b 80 14 22 55 58 18 27 1c aa b8 21 d7 5a bc cb 90 de 01 21 e8 47 a3 a1 40 a4 3e 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 82 01 00 30 0f 06 03 55 1d 13 01 01 ff 04 05 30 03 01 01 ff 30 69 06 03 55 1d 1f 04 62 55 52 49 3a 6c 64 61 70 3a 2f 2f 74 68 65 74 69 73 2e 69 6e 74 65 76 61 74 69 6f 6e 2e 6f 72 67 2f 63 6e 3d 54 65 73 74 2d 50 4b 49 20 31 2c 20 6f 3d 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 2c 20 63 3d 44 45 3f 63 65 72 74 69 66 69 63 61 74 65 52 65 76 6f 63 61 74 69 6f 6e 4c 69 73 74 25 30 41 30 3a 06 03 55 1d 11 04 33 30 31 81 18 69 6e 74 65 76 61 74 69 6f 6e 40 69 6e 74 65 76 61 74 69 6f 6e 2e 64 65 86 15 68 74 74 70 3a 2f 2f 69 6e 74 65 76 61 74 69 6f 6e 2e 6e 65 74 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 03 81 81 00 b0 98 45 a7 68 00 0b 00 12 2a 97 41 12 6c 01 33 c8 2b 89 f1 fb fc 44 82 50 3c 49 4b 61 92 72 fc 21 31 7f 33 79 10 2b 14 eb 75 f0 65 61 3c 91 27 e5 46 4c 89 5e 6f 46 29 25 30 41 a0 13 13 9e d5 46 c1 8d 17 60 35 cc 0c 3e 5f e8 ba e0 3e fb dd f5 55 3a 6b 48 23 00 ed aa cf bf 5e 05 84 bb 7f f5 05 28 f5 09 df 5c 67 2d e6 3a a3 7e 86 08 3f 70 32 43 da 60 c1 c3 ff 8d 13 dc 0c be 13 d4 c1 8d 0c ] 9 - 2004-04-29 13:26:16 dirmngr[29668.0x80646b8] DBG: <- END 9 - 2004-04-29 13:26:23 dirmngr[29668]: found attribute `certificateRevocationList;binary' 9 - 2004-04-29 13:26:23 dirmngr[29668.0x80646b8] DBG: -> INQUIRE SENDCERT CN=Test-PKI 2,O=Intevation GmbH,C=DE 9 - 2004-04-29 13:26:23 dirmngr[29668.0x80646b8] DBG: <- [ 44 20 30 82 03 31 30 82 02 9a a0 03 02 01 02 02 01 00 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 30 1e 17 25 30 44 30 32 30 36 32 37 31 39 35 37 32 34 5a 17 25 30 44 30 33 30 36 32 37 31 39 35 37 32 34 5a 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 30 81 9f 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 ce 8b b3 b3 a8 2e a8 57 46 ef df 71 ab 2a 52 57 f8 3c 4b 6e 76 a5 dc fa b2 69 a6 35 c8 0c 98 2b 5f 44 c6 22 c2 d5 ce 3a 8f 90 94 d6 ed f4 4a 1c 01 91 b3 d5 86 a3 d5 ea c0 eb fa a2 eb 8a be c6 f6 6d 91 82 15 03 8f aa be 5f 2a e7 f7 7b ab fe 0f 4d c6 24 44 92 05 f0 b6 d7 00 0b 2a 25 32 35 34 3b ef 74 6b 20 fb fe aa 95 44 4e 15 05 1f 21 b3 e7 fb c7 8a 63 fd a5 c8 8c df e4 f6 85 d7 be 56 6d 02 03 01 00 01 a3 82 01 41 30 82 01 3d 30 1d 06 03 55 1d 0e 04 16 04 14 22 55 58 18 27 1c aa b8 21 d7 5a bc cb 90 de 01 21 e8 47 a3 30 64 06 03 55 1d 23 04 5d 30 5b 80 14 22 55 58 18 27 1c aa b8 21 d7 5a bc cb 90 de 01 21 e8 47 a3 a1 40 a4 3e 30 3c 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 18 30 16 06 03 55 04 25 30 41 0c 0f 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 31 13 30 11 06 03 55 04 03 0c 25 30 41 54 65 73 74 2d 50 4b 49 20 32 82 01 00 30 0f 06 03 55 1d 13 01 01 ff 04 05 30 03 01 01 ff 30 69 06 03 55 1d 1f 04 62 55 52 49 3a 6c 64 61 70 3a 2f 2f 74 68 65 74 69 73 2e 69 6e 74 65 76 61 74 69 6f 6e 2e 6f 72 67 2f 63 6e 3d 54 65 73 74 2d 50 4b 49 20 31 2c 20 6f 3d 49 6e 74 65 76 61 74 69 6f 6e 20 47 6d 62 48 2c 20 63 3d 44 45 3f 63 65 72 74 69 66 69 63 61 74 65 52 65 76 6f 63 61 74 69 6f 6e 4c 69 73 74 25 30 41 30 3a 06 03 55 1d 11 04 33 30 31 81 18 69 6e 74 65 76 61 74 69 6f 6e 40 69 6e 74 65 76 61 74 69 6f 6e 2e 64 65 86 15 68 74 74 70 3a 2f 2f 69 6e 74 65 76 61 74 69 6f 6e 2e 6e 65 74 30 25 30 44 06 09 2a 86 48 86 f7 25 30 44 01 01 04 05 00 03 81 81 00 b0 98 45 a7 68 00 0b 00 12 2a 97 41 12 6c 01 33 c8 2b 89 f1 fb fc 44 82 50 3c 49 4b 61 92 72 fc 21 31 7f 33 79 10 2b 14 eb 75 f0 65 61 3c 91 27 e5 46 4c 89 5e 6f 46 29 25 30 41 a0 13 13 9e d5 46 c1 8d 17 60 35 cc 0c 3e 5f e8 ba e0 3e fb dd f5 55 3a 6b 48 23 00 ed aa cf bf 5e 05 84 bb 7f f5 05 28 f5 09 df 5c 67 2d e6 3a a3 7e 86 08 3f 70 32 43 da 60 c1 c3 ff 8d 13 dc 0c be 13 d4 c1 8d 0c ] 9 - 2004-04-29 13:26:23 dirmngr[29668.0x80646b8] DBG: <- END 9 - 2004-04-29 13:26:23 dirmngr[29668]: update times of this CRL: this=20030623T154853 next=20030629T154853 9 - 2004-04-29 13:26:23 dirmngr[29668]: new CRL still too old; it expired on 20030629T154853 9 - 2004-04-29 13:26:23 dirmngr[29668]: crl_cache_insert via issuer failed: CRL too old 9 - 2004-04-29 13:26:23 dirmngr[29668]: command ISVALID failed: CRL too old 9 - 2004-04-29 13:26:23 dirmngr[29668.0x80646b8] DBG: -> ERR 167772256 CRL too old 7 - 2004-04-29 13:26:23 gpgsm[29667.0x807b3b8] DBG: -> D crs:i:1024:1:528130280665A867:20030114T143343:20030713T143343:0B::CN=Test-ZS3,O=Intevation GmbH,C=DE::esES:% 0Afpr:::::::::67348E8ACF3DFBB38121353B528130280665A867:::09AA5F1DE795237656239C9A78536B07E43C15AC: %0Auid:i::::::::CN=Marc Mutz,OU=KMail,O=KDE,L=org,C=DE::%0Auid:i::::::::::%0A 7 - 2004-04-29 13:26:23 gpgsm[29667.0x807b3b8] DBG: -> OK 7 - 2004-04-29 13:26:23 gpgsm[29667.0x807b3b8] DBG: <- BYE 7 - 2004-04-29 13:26:23 gpgsm[29667.0x807b3b8] DBG: -> OK closing connection [client at fd 7 disconnected] 9 - 2004-04-29 13:26:23 dirmngr[29668.0x80646b8] DBG: <- [EOF] 8 - 2004-04-29 13:26:23 gpg-agent[4720.0x808c030] DBG: <- [EOF] 8 - 2004-04-29 13:26:23 gpg-agent[4720]: handler for fd 0 terminated [client at fd 9 disconnected] ---------- assignedto: marcus messages: 866 nosy: marc, marcus priority: bug status: unread title: gpgme: no error propagation for validating keylisting topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ From wk at gnupg.org Thu Apr 29 15:00:57 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Apr 29 14:45:44 2004 Subject: [issue184] gpgme: no error propagation for validating keylisting In-Reply-To: <1083238649.84.0.554832894341.issue184@intevation.de> (Marc Mutz's message of "Thu, 29 Apr 2004 11:37:31 +0000") References: <1083238649.84.0.554832894341.issue184@intevation.de> Message-ID: <87hdv3kkfq.fsf@vigenere.g10code.de> > crs:i:1024:1:528130280665A867:20030114T143343: [...] ^^^ The key is flagged invalid - don't you get this trough the gpgme interface? From cbguder at su.sabanciuniv.edu Thu Apr 29 15:18:00 2004 From: cbguder at su.sabanciuniv.edu (=?ISO-8859-9?Q?Can_Berk_G=FCder?=) Date: Thu Apr 29 15:15:14 2004 Subject: Turkish localization again... Message-ID: <40910088.4060402@su.sabanciuniv.edu> Hi there again, Due to some problems, we haven't been able to start translating yet. The thing is that, our supervisor wants us to provide a Windows binary no matter what. So we can't stick with Linux, as I've previously told we would. Anyway, the question is: Can old versions of GPA be cross-compiled for Windows? If there are such versions, which one is the latest? Regards, -- Can Berk Guder Sabanci University Istanbul, Turkey From aegypten-issues at intevation.de Thu Apr 29 15:40:02 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Thu Apr 29 15:37:08 2004 Subject: [issue185] validating a large number of certificates fails Message-ID: <1083246002.5.0.374796763293.issue185@intevation.de> New submission from Bernhard Herzog : I have a test user with 37 certificates in the keybox. In kleopatra I select all of them and invoke "validate" from the context menu and I get the error: An error occurred while fetching the certificates from the backend: Invalid crypto engine watchgnupg output: 5 - 2004-04-29 15:37:26 gpgsm[27151.0x807a588] DBG: <- [Invalid line] 5 - 2004-04-29 15:37:26 gpgsm[27151]: Assuan processing failed: line too long [client at fd 5 disconnected] Not sure whether this is a bug in the backend or the front end, so I'm assigning this to marc who can then assign this to g10code if he likes :) ---------- assignedto: marc messages: 872 nosy: bh, marc priority: bug status: unread title: validating a large number of certificates fails topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Apr 29 17:14:23 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Thu Apr 29 17:11:36 2004 Subject: [issue186] kleopatra problems with incorrect ldap servers Message-ID: <1083251663.16.0.162318805395.issue186@intevation.de> New submission from Bernhard Herzog : I've noticed two problems with an accidentally misconfigured ldap server. The misconfiguration was a domain name where no server was listening on port 389. In one case I got a segfault after I clicked OK on the message with the error message: An error occurred while fetching the certificates from the backend: Verbindungsaufbau abgelehnt I can't reproduce the crash anymore, though. A traceback is below. However, I do see one other strange problem. If "hierarchical key list" is checked, the message box above doesn't appear and the keylist is simply empty. If "hierarchical key list" is not checked, the error message does appear. Here's the backtrace from the segfault: [New Thread 1024 (LWP 26906)] 0x41747a59 in wait4 () from /lib/libc.so.6 #0 0x41747a59 in wait4 () from /lib/libc.so.6 #1 0x417bee48 in __check_rhosts_file () from /lib/libc.so.6 #2 0x41609453 in waitpid () from /lib/libpthread.so.0 #3 0x40ab7e7d in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #4 0x41606f54 in pthread_sighandler () from /lib/libpthread.so.0 #5 0x416d06b8 in sigaction () from /lib/libc.so.6 #6 0x40e9cefb in QApplication::notify (this=0xbffff694, receiver=0x8153d30, e=0x81157b8) at kernel/qapplication.cpp:2305 #7 0x40a2b3d0 in KApplication::notify (this=0xbffff694, receiver=0x8153d30, event=0x81157b8) at kapplication.cpp:506 #8 0x41250044 in QApplication::sendEvent (receiver=0x8153d30, event=0x81157b8) at .moc/debug-shared-mt/../../kernel/qapplication.h:492 #9 0x40e9ef34 in QApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qapplication.cpp:3204 #10 0x40e9ec8f in QApplication::sendPostedEvents () at kernel/qapplication.cpp:3115 #11 0x40e4571f in QEventLoop::processEvents (this=0x80c87f8, flags=4) at kernel/qeventloop_x11.cpp:144 #12 0x40eb4590 in QEventLoop::enterLoop (this=0x80c87f8) at kernel/qeventloop.cpp:198 #13 0x40eb44c9 in QEventLoop::exec (this=0x80c87f8) at kernel/qeventloop.cpp:145 #14 0x40e9dfcd in QApplication::exec (this=0xbffff694) at kernel/qapplication.cpp:2705 #15 0x08062b29 in main (argc=1, argv=0xbffff804) at main.cpp:85 ---------- assignedto: marc messages: 878 nosy: bh, marc priority: bug status: unread title: kleopatra problems with incorrect ldap servers topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________