From bernhard at intevation.de Tue Jun 1 14:28:40 2004 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat Jun 5 11:15:24 2004 Subject: Help needed while encrypting using UNIX shell script In-Reply-To: <20040519224614.38936.qmail@web40614.mail.yahoo.com> References: <20040519224614.38936.qmail@web40614.mail.yahoo.com> Message-ID: <20040601122840.GB21974@intevation.de> On Wed, May 19, 2004 at 11:46:14PM +0100, Iyer, Hari wrote: > gpg: WARNING: using insecure memory! > gpg: please see http://www.gnupg.org/faq.html for more information > gpg: can't open `/t027/oracle/.gnupg/pubring.gpg' > gpg: keydb_search failed: file open error > gpg: Print Mail: skipped: file open error > gpg: ./hari.txt: encryption failed: file open error > > > > I am under a very tight schedule so if any help could be given would > be great. If you are under a tight schedule I recommend using a support offer by one of the companies dealing with GNUPG professionally (and commercially) of course. E.g. g10code http://www.g10code.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040601/93763f66/attachment.bin From aegypten-issues at intevation.de Tue Jun 1 20:47:06 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Sat Jun 5 11:15:33 2004 Subject: [issue210] A note on the backend interface design (process) Message-ID: <200406012043.07463.marc@klaralvdalens-datakonsult.se> New submission from Marc Mutz : Hi Werner, Marcus. Reading #183 and #199 again makes me wonder how much of that suff will actually survive the next {gpgme,gnupg} version. One one hand, you fight against adding new interfaces (read: functions) to gpgme, and keep adding command line hacks that make Kleopatra a more and more unmaintainable mixture of gpgconf/gpgme/gpgsm calls, OTOH, you keep overloading the keylist operation with more and more semantics that don't have anything to do with key listing. Setting root certs trust through a keylisting? Hello? The operations that you overloaded on gpgme_op_keylist naturally share a common code path in Kleopatra, different operations differentiating themselves through minor usage of the occasional ternary operator. This is fine, apart from the overloaded keylist semantics. But now I am asked (#183) to break up all these common code paths, duplicating a lot of code, writing a lot of new code, so that gpgme can keep adding even more semantics to it's existing interfaces, keeping _it's_ code paths shared, to a point (trust setting) that's getting ridiculous fast. Also, imposing arbitrary restrictions on a long-established interface just as bugs show up is not a sign of good interface design. There is nothing stopping me from presenting the user with a listbox and [Add...] and [Remove] buttons to build up a list of patterns to send to gpgme for listing. Qt won't impose any restrictions other than stuff like MAXINT and the available memory. And I would have _no way_ of imposing a limit on the number of patterns in the GUI, since I do not know where that limit is. This limit is an implementation detail of the gpgme<->gpg/gpgsm protocol, and only these two components know about that limit. One of them enforces the limit, but the other one doesn't understand the error, and returns the not very helpful error message "invalid engine". If there's a limit, enforce it and return a meaningful error message/code. And provide an interface for the common task of validating a list of keys, something _useful_ like: gpgme_error_t gpgme_op_validate_start( gpgme_key_t * keys, ... ); that doesn't have this limit. Its passed gpgme_key_t's so that I don't need to guess that it's probably fingerprints that you want passed in that case, and an equivalent function for this root trust setting, although a decent command line interface would be more fitting there. Whether or not you internally map that to a keylist is up to you, but at least this is what I would call a clear, to-the-point interface, instead of the mish-mash that keylist is now. There are some other areas in gpgme where the semantics are not well-defined (I've written the occasional mail about them, but didn't have the time or right spirit to argue over such small things) and stuff has been added ad-hoc. The identification of root certs, e.g., is one of them that immediately comes to mind, since it caused shotgun surgery on our side. I've since added a method GpgME::Key::isRoot() since I coudn't for the live of me remember whether chain_id == subkeys->fpr or !chain_id was meant to mean "isRoot". A simple flag in gpgme_key_t or an inline function gpgme_key_is_rootcert( gpgme_key_t ) would've made dealing with this sort of thing so much easier. I've also added GpgME::Key::fingerprint(), which associates a fingerprint with a _key_, which is what you use it for when doing a validating keylisting, as well as GpgME::Key::keyID() and ::shortKeyID(), which are probably very wrong for RSA and/or X.509 keys, but without which a decent UI isn't possible. All in all, your arguments at the beginning of the project for not adding requested functions/features were that they would expose implementation details of gpgme/gpg/gpgsm/whatever in the interface. However, what has come out of this project is a gpgme that requires the user (of the API) to rely on undocumented behaviour of the API, accept implementation-defined and non-queriable limits, interspersing of gpgme calls with direct calls to the gpg/gpgsm/gpgconf commandline, and so on. Actually, I think I should stop here. I just wanted to point out that I think the handling of the gpgme API was too strict and that the addition of a keymanager API on top of the gpgme one (and splitting keyring handling operations such as delete_key out of gpgme into that keymanager-interface) would have made much more sense than the current patchwork of ad-hoc hacks. Somehow I get the idea that you hope that (S/MIME) key managers for GnuPG will go away again after this project. Which is kind of funny, since I remember Werner violently agreeing that the trend for OpenPGP and .S/MIME over the next years will be to more and more integrate them with each other (OpenPGP keys for TLS, OpenPGP sigs with X.509 keys, etc), so I can't really understand the reluctance on your side, but there you go... Thanks for listening, Marc ---------- messages: 1034 nosy: marc status: unread title: A note on the backend interface design (process) ______________________________________________________ Aegypten issue tracker ______________________________________________________ From cbguder at su.sabanciuniv.edu Wed Jun 2 13:52:58 2004 From: cbguder at su.sabanciuniv.edu (=?ISO-8859-9?Q?Can_Berk_G=FCder?=) Date: Sat Jun 5 11:16:01 2004 Subject: Turkish translation ready! Message-ID: <40BDBF9A.10207@su.sabanciuniv.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, We're finally done with the Turkish translation I mentioned, and it looks like it's ready for the next possible release. Now how do I go about sending it? CVS? Regards, - -- Can Berk G?der Sabanc? University Istanbul, TURKEY -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAvb+aXAlM7GjkjgwRAsFCAJ9Bv79t/DUQIjApYxEmIWz0/7x9ogCgr3kw jbIYEljwWpwNYwxMRFebAxk= =ZsUb -----END PGP SIGNATURE----- From aegypten-issues at intevation.de Wed Jun 2 22:53:34 2004 From: aegypten-issues at intevation.de (Marcus Brinkmann) Date: Sat Jun 5 11:16:10 2004 Subject: [issue211] better error code for over-long keylist patterns Message-ID: <1086209614.65.0.825480699375.issue211@intevation.de> New submission from Marcus Brinkmann : See #185. If an over long keylist pattern is used that exceeds the assuan line length limit, give a better error value than "Invalid Engine". ---------- assignedto: marcus messages: 1047 nosy: marcus priority: minor bug status: unread title: better error code for over-long keylist patterns topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Jun 3 22:10:31 2004 From: aegypten-issues at intevation.de (=?utf-8?q?Ingo_Kl=C3=B6cker?=) Date: Sat Jun 5 11:16:18 2004 Subject: [issue212] KMail: Message was signed on 01.01.1970 01:00 (not!) Message-ID: <1086293431.63.0.888327031347.issue212@intevation.de> New submission from Ingo Kl?cker : KMail currently shows Message was signed on 01.01.1970 01:00 with unknown key 0x... But obviously the message was not signed on this date. ---------- messages: 1051 nosy: ingo priority: bug status: unread title: KMail: Message was signed on 01.01.1970 01:00 (not!) ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Sat Jun 5 14:41:52 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Sat Jun 5 15:25:09 2004 Subject: [issue214] gpgme: add gpgme_key_t->fpr Message-ID: <1086439311.95.0.684374702987.issue214@intevation.de> New submission from Marc Mutz : Whenever I need to identify a key I'm told to use "the fingerprint". E.g. when saving the preferred signing key for an identity to a config file, or when trying to determine whether or not a given key represents a root certificate. Whenever I do key->subkeys->fpr, therefore, I do wonder why it isn't key->subkeys->next->fpr that I should use. What happens if the first subkey is deleted from a key, or revoked? This looks even more curious in gpgme++: const char * fpr = key.subkey(0).fingerprint(); // why _0_? I therefore added Key::primaryFingerprint() to gpgme++, to hide this particular question-raising-whenever-reading-the-code. Maybe much of the need for this could go away when some functions in gpgme took gpgme_key_t's instead of const char *, see e.g. #213, and esp. a gpgme_op_keylist_* variant. ---------- assignedto: marcus messages: 1055 nosy: marc, marcus priority: wish status: unread title: gpgme: add gpgme_key_t->fpr topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Sat Jun 5 14:30:48 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Sat Jun 5 15:25:51 2004 Subject: [issue213] gpgme: add int gpgme_key_is_root(cert)( gpgme_key_t * ) Message-ID: <1086438648.27.0.154560664869.issue213@intevation.de> New submission from Marc Mutz : This is to make it easier for the user of gpgme to determine whether a given key is a root certificate. An alternative would be to add an is_root flag in gpgme_key_t, but you are right in that this would duplicate information already available through the chain_id (albeit needing a string comparison). I've implemented this in gpgme++ like this: bool Key::isRoot() const { return d->key && d->key->subkeys && d->key->subkeys->fpr && d->key->chain _id && strcasecmp( d->key->subkeys->fpr, d->key->chain_id ) == 0; } ---------- assignedto: marcus messages: 1054 nosy: marc, marcus priority: wish status: unread title: gpgme: add int gpgme_key_is_root(cert)( gpgme_key_t * ) topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Sat Jun 5 15:41:48 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Sat Jun 5 15:38:46 2004 Subject: [issue215] gpgme: should have different types for the validity and ownertrust enums Message-ID: <1086442908.29.0.30537242882.issue215@intevation.de> New submission from Marc Mutz : Another topic that I think is strange is that ownertrust and validity share a common enum gpgme_validity_t. It should have a gpgme_(owner)trust_t for the ownertrust values instead, as these are two different things, and the compiler should be able to detect when you try to use one for the other (C doesn't do this, but C++ will). ---------- assignedto: marcus messages: 1061 nosy: marc, marcus priority: wish status: unread title: gpgme: should have different types for the validity and ownertrust enums topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ From cbguder at su.sabanciuniv.edu Sat Jun 5 16:27:45 2004 From: cbguder at su.sabanciuniv.edu (=?ISO-8859-9?Q?Can_Berk_G=FCder?=) Date: Sat Jun 5 16:24:47 2004 Subject: Turkish translation ready! Message-ID: <40C1D861.9040707@su.sabanciuniv.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, We're finally done with the Turkish translation I mentioned, and it looks like it's ready for the next possible release. Now how do I go about sending it? CVS? Regards, - -- Can Berk G?der Sabanc? University Istanbul, TURKEY -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAwdhgXAlM7GjkjgwRAlJeAKCBHQEigeybYh272N2cnTLXWXT9XACdHW8p yOe3zs2+cVjOIOH9MvIuy+I= =b460 -----END PGP SIGNATURE----- From aegypten-issues at intevation.de Sun Jun 6 12:09:16 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Sun Jun 6 12:06:21 2004 Subject: [issue216] gpgme: trust (u, n, ?) of root certificates is contained in uid validity field, should be in key ownertrust field Message-ID: <1086516556.36.0.302494488559.issue216@intevation.de> New submission from Marc Mutz : It's "trust", after all. ---------- assignedto: marcus messages: 1064 nosy: marc, marcus priority: bug status: unread title: gpgme: trust (u,n,?) of root certificates is contained in uid validity field, should be in key ownertrust field topic: GPGME, gpg-agent, gpgsm ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Sun Jun 6 17:17:57 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Sun Jun 6 17:15:00 2004 Subject: [issue217] gpgme: use gpgme_userid_t->email instead of gpgme_userid_t->uid for x.509 email addresses. Message-ID: <1086535077.52.0.0150492684655.issue217@intevation.de> New submission from Marc Mutz : There is this weird convention that the DN of an x.509 cert is in key->uids->uid, and the email address(es) in key->uids->(next->)+uid, enclosed in . However, there is an "email" field in gpgme_userid_t, which in these cases is NULL. A more logical place would be that email field, of course, but it should be extended to keep a list of emails, so as to better reflect the structure of X.509 keys/certs. An OpenPGP key would still have only one email address there, or you keep the email field, and add the array as email_s_. ---------- assignedto: marcus messages: 1076 nosy: marc, marcus priority: wish status: unread title: gpgme: use gpgme_userid_t->email instead of gpgme_userid_t->uid for x.509 email addresses. topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Sun Jun 6 17:23:55 2004 From: aegypten-issues at intevation.de (Marc Mutz) Date: Sun Jun 6 17:20:51 2004 Subject: [issue218] gpgme: include a struct dn_pair * dn; in either gpgme_userid_t or gpgme_key_t Message-ID: <1086535434.99.0.907867746119.issue218@intevation.de> New submission from Marc Mutz : Currently, every application needs to include it's own DN parsing code. We, e.g. use a slightly C++-ified version of what is presumably the original code in gpgsm. Since that is not exactly trivial code, it would be best to not require the gpgme user to write it :) A new field struct dn_pair * dn; in gpgme_key_t (since there's only ever one of them, like the issuer_serial and chain_id), or, if it must be, in gpgme_userid_t. After all, you also provide a parsed-down version of OpenPGP uids: (name,comment,email). ---------- assignedto: marcus messages: 1077 nosy: marc, marcus priority: wish status: unread title: gpgme: include a struct dn_pair * dn; in either gpgme_userid_t or gpgme_key_t topic: GPGME ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Jun 8 12:17:28 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Tue Jun 8 12:14:32 2004 Subject: [issue219] Kleopatra: import of certs: jump to first imported. Message-ID: <1086689848.86.0.499306966277.issue219@intevation.de> New submission from Jan-Oliver Wagner : After importing certificates, they are selected in the list view of Kleopatra. However, the view is not scrolled to the first selected one but rather may show only unselected entries where the user first has to scroll to find the imported ones. So, jumping to the first selected=imported certificate helps to let the user know that imported certs are selected automatically and avoids the need to scroll. ---------- assignedto: marc messages: 1092 nosy: jan, marc priority: bug status: unread title: Kleopatra: import of certs: jump to first imported. topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Jun 8 17:14:27 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Tue Jun 8 17:11:27 2004 Subject: [issue220] kmail: does not report about illegal use of sign-only certs Message-ID: <1086707667.59.0.675578624159.issue220@intevation.de> New submission from Jan-Oliver Wagner : E-Mails that have been encrypted with a sign-only key are not declared as such when KMail reads the email. The Log-File shows that the backend recognizes this, so somehow this information did not find its way up the KMail GUI. (For signed with a encrypt-only key it works) Attached is a illegal email and the corresponding key (p12 and p7c). The passw is smime ---------- assignedto: marc files: test-encrypt-with-signonly.mbox messages: 1098 nosy: jan, marc priority: urgent status: unread title: kmail: does not report about illegal use of sign-only certs topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test-encrypt-with-signonly.mbox Type: application/octet-stream Size: 1781 bytes Desc: not available Url : /pipermail/attachments/20040608/8224b885/test-encrypt-with-signonly.exe From bernhard at intevation.de Tue Jun 8 19:19:23 2004 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Jun 8 19:16:25 2004 Subject: Turkish localization again... In-Reply-To: <40910088.4060402@su.sabanciuniv.edu> References: <40910088.4060402@su.sabanciuniv.edu> Message-ID: <20040608171923.GC15355@intevation.de> On Thu, Apr 29, 2004 at 04:18:00PM +0300, Can Berk G?der wrote: > 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? Yes, 0.4.3 to my best knowledge. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040608/b43fdaf9/attachment.bin From bernhard at intevation.de Tue Jun 8 19:21:02 2004 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Jun 8 19:18:00 2004 Subject: Turkish translation ready! In-Reply-To: <40C1D861.9040707@su.sabanciuniv.edu> References: <40C1D861.9040707@su.sabanciuniv.edu> Message-ID: <20040608172102.GD15355@intevation.de> On Sat, Jun 05, 2004 at 05:27:45PM +0300, Can Berk G?der wrote: > -----BEGIN PGP SIGNED MESSAGE----- ups ^^^ that is still deprecated non-MIME OpenPGP, BTW. > We're finally done with the Turkish translation I mentioned, and it > looks like it's ready for the next possible release. > > Now how do I go about sending it? CVS? Put it up for download and send the URL here. Otherwise if it is short enough, mail it here. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040608/1aa28f14/attachment.bin From wk at gnupg.org Tue Jun 8 21:42:21 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Jun 8 21:40:52 2004 Subject: New gnupg 1.9 release Message-ID: <87vfi1bzvm.fsf@vigenere.g10code.de> Hi! I have just released GnuPG 1.9.9 with some minor fixes. Note that this is the S/MIME enhanced version of GnuPG which should peacefully coexists with other GnupG versions (1.2.x or 1.3.x). See the README and NEWS file for details. ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.9.tar.gz ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.9.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.8-1.9.9.diff.gz You also need to update two of the libraries: ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.7.tar.gz ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.7.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.6-0.9.7.diff.gz ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.6.6.tar.gz ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.6.6.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.6.5-0.6.6.tar.gz Noteworthy changes are: * [gpg-agent] The new option --allow-mark-trusted is now required to allow gpg-agent to add a key to the trustlist.txt after user confirmation. * Creating PKCS#10 requests does now honor the key usage. Happy hacking, Werner -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org From michaelnottebrock at gmx.net Tue Jun 8 21:58:41 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Tue Jun 8 21:55:42 2004 Subject: New gnupg 1.9 release In-Reply-To: <87vfi1bzvm.fsf@vigenere.g10code.de> References: <87vfi1bzvm.fsf@vigenere.g10code.de> Message-ID: <200406082158.41404.michaelnottebrock@gmx.net> On Tuesday 08 June 2004 21:42, Werner Koch wrote: > Noteworthy changes are: > > * [gpg-agent] The new option --allow-mark-trusted is now required to > allow gpg-agent to add a key to the trustlist.txt after user > confirmation. > > * Creating PKCS#10 requests does now honor the key usage. Does this release have the getline calls removed or backed up by a replacement (see http://lists.gnupg.org/pipermail/gpa-dev/2004-April/001892.html)? We still have to ship 1.9.3 in FreeBSD ports because of this. -- ,_, | 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/20040608/87708bbd/attachment.bin From aegypten-issues at intevation.de Wed Jun 9 16:55:12 2004 From: aegypten-issues at intevation.de (Praedor Atrebates) Date: Wed Jun 9 16:52:13 2004 Subject: [issue221] cryptplugin in kmail produces bad sigs Message-ID: <1086792912.41.0.495102486305.issue221@intevation.de> New submission from Praedor Atrebates : Using kmail-1.6.1 in KDE 3.2.1 on Mandrake 10.0 Official. Signed messages using the crypt plugin (gpgme/agypten) invariably come up as being bad. The key ID comes up prepended by 8 extra alphanumerics that produces a bad sig message. Encrypting or decrypting messages using the crypt plugin works fine, however. I have a key id of 0x193BDEFF. If I sign a message using the builtin OpenPGP plugin in kmail, it works fine and comes up as valid. If I select the cryptplug plugin, the sig is rendered bad and the key ID becomes 0x4936A9A1193DBEFF (8 alphanumerics are now prepended on my actual keyid). ---------- messages: 1104 nosy: praedor priority: bug status: unread title: cryptplugin in kmail produces bad sigs ______________________________________________________ Aegypten issue tracker ______________________________________________________ From Axel.Thimm at ATrpms.net Wed Jun 9 00:38:52 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed Jun 9 17:16:30 2004 Subject: o[c]sc_get_status typo? (was: New gnupg 1.9 release) In-Reply-To: <87vfi1bzvm.fsf@vigenere.g10code.de> References: <87vfi1bzvm.fsf@vigenere.g10code.de> Message-ID: <20040608223852.GC23206@neu.nirvana> On Tue, Jun 08, 2004 at 09:42:21PM +0200, Werner Koch wrote: > I have just released GnuPG 1.9.9 with some minor fixes. Note that > this is the S/MIME enhanced version of GnuPG which should peacefully > coexists with other GnupG versions (1.2.x or 1.3.x). See the README > and NEWS file for details. > > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.9.tar.gz > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.9.tar.gz.sig > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.8-1.9.9.diff.gz > > You also need to update two of the libraries: > > ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.7.tar.gz > ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.7.tar.gz.sig > ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.6-0.9.7.diff.gz > > ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.6.6.tar.gz > ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.6.6.tar.gz.sig > ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.6.5-0.6.6.tar.gz The build fails with: apdu.c: In function `apdu_get_status': apdu.c:1721: warning: implicit declaration of function `osc_get_status' apdu.c: At top level: apdu.c:1313: warning: `ocsc_get_status' defined but not used [...] gcc -I/usr/include -O2 -g -pipe -march=i386 -mcpu=i686 -fPIE -pie -Wall -o scdaemon scdaemon.o command.o card.o card-p15.o apdu.o ccid-driver.o iso7816.o tlv.o app.o app-help.o app-openpgp.o app-nks.o app-dinsig.o../jnlib/libjnlib.a ../common/libcommon.a -L/usr/lib -lopensc -lpcsclite -lpthread -lgcrypt -lgpg-error -L/usr/lib -lpth -lksba -lgpg-error -lassuan -lgpg-error -ldl -lz apdu.o(.text+0x20af): In function `apdu_get_status': /var/tmp/bach-build/BUILD/gnupg-1.9.9/scd/apdu.c:1721: undefined reference to `osc_get_status' > Noteworthy changes are: > > * [gpg-agent] The new option --allow-mark-trusted is now required to > allow gpg-agent to add a key to the trustlist.txt after user > confirmation. > > * Creating PKCS#10 requests does now honor the key usage. > > > Happy hacking, > > Werner > > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040609/381221de/attachment-0001.bin From aegypten-issues at intevation.de Wed Jun 9 17:30:36 2004 From: aegypten-issues at intevation.de (Matej Cepl) Date: Wed Jun 9 17:27:33 2004 Subject: [issue222] Interoperability issues between KMail and Mozilla with S/MIME signed message Message-ID: <1086795036.78.0.0521261586945.issue222@intevation.de> New submission from Matej Cepl : Hi, I have filed for this bug on http://bugs.kde.org/show_bug.cgi?id=76090 and on http://bugzilla.mozilla.org/show_bug.cgi?id=236466, because I really do not know where the problem is (so sorry for cross-posting). Using kmail 1.6.2 (from KDE 3.2.2) from download.kde.org packages for Debian/woody, with Aegypten from http://www.opensides.be woody/main (gpgsm version 0.9.4) and Mozilla Thunderbird 0.5. Thanks for any reply. Matej ---------- messages: 1105 nosy: cepl status: unread title: Interoperability issues between KMail and Mozilla with S/MIME signed message ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Sat Jun 12 00:37:27 2004 From: aegypten-issues at intevation.de (=?utf-8?q?Ingo_Kl=C3=B6cker?=) Date: Tue Jun 15 08:50:21 2004 Subject: [issue223] KMail: Crash when composing mail for recipient with known expired PGP key Message-ID: <1086993447.84.0.155213610358.issue223@intevation.de> New submission from Ingo Kl?cker : http://bugs.kde.org/show_bug.cgi?id=83093 Stephan Binner wrote: ===== Have an expired PGP key (culprit here 0xEB3B7E0D), Message/New Message, enter an address of the key into "To:" and wait (one or two minutes?). Don't know what it triggers but: kmail: Kleo::KeyResolver::lookup( "Dirk Mueller ", false ) kmail: returned 2 keys *** KMail got signal 11 (Crashing) ===== This obviously happens when the dead letter is written. ---------- messages: 1106 nosy: ingo priority: bug status: unread title: KMail: Crash when composing mail for recipient with known expired PGP key ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Sat Jun 12 01:03:53 2004 From: aegypten-issues at intevation.de (=?utf-8?q?Ingo_Kl=C3=B6cker?=) Date: Tue Jun 15 08:50:23 2004 Subject: [issue224] KMail: Never expiring key expires in 4294954719 days Message-ID: <1086995033.55.0.710560875971.issue224@intevation.de> New submission from Ingo Kl?cker : http://bugs.kde.org/show_bug.cgi?id=83079 Martin Koller wrote: ===== Trying to send a mail which shall be signed pops up a dialog: Your OpenPGP signing key Martin Koller (KeyID 0x8DFB0F86) expires in less than 4294954719 days. Well, yes ... and ? ;-) (The key has unlimited expiration) ===== Inverting the calculation of daysTillExpiry yields that subkey.expirationTime() must have returned a very low value. But if it would be 0 then subkey.neverExpires() should already have returned true. Is there a known bug in some versions of gpgme? ---------- messages: 1107 nosy: ingo priority: minor bug status: unread title: KMail: Never expiring key expires in 4294954719 days ______________________________________________________ Aegypten issue tracker ______________________________________________________ From wk at gnupg.org Mon Jun 14 09:08:07 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Jun 15 08:59:42 2004 Subject: New gnupg 1.9 release In-Reply-To: <200406082158.41404.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Tue, 8 Jun 2004 21:58:41 +0200") References: <87vfi1bzvm.fsf@vigenere.g10code.de> <200406082158.41404.michaelnottebrock@gmx.net> Message-ID: <87n0368vmw.fsf@vigenere.g10code.de> On Tue, 8 Jun 2004 21:58:41 +0200, Michael Nottebrock said: > Does this release have the getline calls removed or backed up by a replacement Sorry no. I'll take care of this now. Thanks, Werner From aegypten-issues at intevation.de Mon Jun 14 18:15:12 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Tue Jun 15 09:00:47 2004 Subject: [issue225] kleopatra: broken translation %n key. Message-ID: <1087229712.18.0.297844842607.issue225@intevation.de> New submission from Bernhard Herzog : Start kleopatra in a german locale (LANG=de_DE@euro). After a while, but pretty quickly, a message appears in the status bar: BROKEN TRANSLATION %n Key. In the debug output in the terminal window I get a more precise message: kleopatra: ERROR: translation of "%n Key." doesn't contain 2 different plural forms as expected ---------- assignedto: marc messages: 1108 nosy: bh, marc priority: bug status: unread title: kleopatra: broken translation %n key. topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Jun 15 20:58:57 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Tue Jun 15 20:55:52 2004 Subject: [issue226] kmail doesn't save s/mime validation settings Message-ID: <1087325936.94.0.971886728958.issue226@intevation.de> New submission from Bernhard Herzog : Kmail doesn't actually apply the settings of the S/MIME Validation Tab in the Security config dialog. E.g. switching ocsp on or off and clicking OK has no effect. The next time you open the dialog the old setting is back. The gpgsm config file hasn't been changed. Doing the same setting through the crpyto-backends tab with the configure button works and changes made there are reflected in the S/MIME Validation Tab when you close and reopen the dialog. ---------- assignedto: marc messages: 1113 nosy: bh, marc priority: bug status: unread title: kmail doesn't save s/mime validation settings topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From dfaure at klaralvdalens-datakonsult.se Thu Jun 10 19:15:10 2004 From: dfaure at klaralvdalens-datakonsult.se (David Faure) Date: Wed Jun 16 10:16:12 2004 Subject: patch for assuan-handler.c Message-ID: <200406101915.10207.dfaure@klaralvdalens-datakonsult.se> --- assuan.orig/assuan-handler.c 2004-02-18 19:05:37.000000000 +0100 +++ assuan/assuan-handler.c 2004-06-10 19:12:18.571573877 +0200 @@ -22,6 +22,7 @@ #include #include #include +#include #include "assuan-defs.h" This is necessary to compile gpgme-0.9.0 on systems without fopencookie/funopen, since assuan_get_data_fp sets errno on such systems. Assuan is copied to other libs than gpgme, right? Inside gpgme, assuan_get_data_fp is totally unused. ======== On another note the freebsd people had to add this to assuan-domain-connect.c #ifdef __FreeBSD__ #include #endif Not sure why, ask groot@kde.org -- David Faure -- faure@kde.org, dfaure@klaralvdalens-datakonsult.se Qt/KDE/KOffice developer Klar?lvdalens Datakonsult AB, Platform-independent software solutions From wk at gnupg.org Wed Jun 16 16:21:56 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Jun 16 16:20:41 2004 Subject: o[c]sc_get_status typo? In-Reply-To: <20040608223852.GC23206@neu.nirvana> (Axel Thimm's message of "Wed, 9 Jun 2004 00:38:52 +0200") References: <87vfi1bzvm.fsf@vigenere.g10code.de> <20040608223852.GC23206@neu.nirvana> Message-ID: <87wu27vb0b.fsf@vigenere.g10code.de> On Wed, 9 Jun 2004 00:38:52 +0200, Axel Thimm said: > apdu.o(.text+0x20af): In function `apdu_get_status': > /var/tmp/bach-build/BUILD/gnupg-1.9.9/scd/apdu.c:1721: undefined reference to `osc_get_status' Thanks for noting. I have not tested the OpenSC version for quite some time due to the flux in the OpenSC API. Werner From cbguder at su.sabanciuniv.edu Sun Jun 20 13:42:33 2004 From: cbguder at su.sabanciuniv.edu (=?ISO-8859-9?Q?Can_Berk_G=FCder?=) Date: Mon Jun 21 13:12:10 2004 Subject: Turkish translation files Message-ID: <40D57829.8020303@su.sabanciuniv.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for the incredible delay, but I was dealing with my finals. Attached are the Turkish translation files for GPA 0.7 Regards, - -- Can Berk Guder Sabanci University Istanbul, TURKEY -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA1XgpXAlM7GjkjgwRAg+fAJ0byx6DJH32+AJD4HG0ntAbbEVM+wCfaF6f 4rZVjFVdzZfpaUn4CTrtYCU= =XUK9 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: tr.gmo Type: application/octet-stream Size: 29867 bytes Desc: not available Url : /pipermail/attachments/20040620/66dc9dff/tr-0001.exe -------------- next part -------------- A non-text attachment was scrubbed... Name: tr.po Type: text/x-po Size: 40238 bytes Desc: not available Url : /pipermail/attachments/20040620/66dc9dff/tr-0001.bin From deano at price4.org Fri Jun 25 21:59:43 2004 From: deano at price4.org (Dean Price) Date: Mon Jun 28 10:15:53 2004 Subject: Kmail - gpg/pgp - Fedora 1 and 2 Message-ID: <200406251559.51372.deano@price4.org> The instructions that I found at this website http://kmail.kde.org/kmail-pgpmime-howto.html work up till it says to add the command to .xsession or startkde... when I log in to my box now I get a warning that states the following: The use of GnuPG Agent is enabled in GnuPG's configuration file (/home/dprice/.gnupg/gpg.conf). However, the agent doesn't seem to run. This could result in problems with signing/decryption. Please disable GnuPG Agent from KGpg settings, or fix the agent. I do not subscribe to the list so would someone be so kind to send to my email address -- Thank You, Dean Price deano@price4.org dprice153@charter.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : /pipermail/attachments/20040625/bee57552/attachment.bin From peter_e at gmx.net Sun Jun 27 11:09:19 2004 From: peter_e at gmx.net (Peter Eisentraut) Date: Mon Jun 28 10:15:58 2004 Subject: pinentry: compilation failure Message-ID: <200406271109.19467.peter_e@gmx.net> Please see the attached typescript for a compilation failure when pinentry 0.7.1 is built without curses fallback. I was able to fix it by adding -I$(top_srcdir)/pinentry to AM_CPPFLAGS in qt/Makefile.am. (You can remove it from ncurses_include as it would then be redundant.) On an unrelated note, you might want to update your config.guess and config.sub; they are more than a year old. A good time might be before every release. -------------- next part -------------- A non-text attachment was scrubbed... Name: typescript.gz Type: application/x-gzip Size: 3142 bytes Desc: not available Url : /pipermail/attachments/20040627/78a92d9b/typescript.bin From wk at gnupg.org Mon Jun 28 10:26:03 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Jun 28 10:28:21 2004 Subject: Kmail - gpg/pgp - Fedora 1 and 2 In-Reply-To: <200406251559.51372.deano@price4.org> (Dean Price's message of "Fri, 25 Jun 2004 15:59:43 -0400") References: <200406251559.51372.deano@price4.org> Message-ID: <87y8m85bs4.fsf@wheatstone.g10code.de> On Fri, 25 Jun 2004 15:59:43 -0400, Dean Price said: > Please disable GnuPG Agent from KGpg settings, or fix the agent. Please check that the agent is running using ps ax | grep gpg-agen[t] and if it is running, give it a HUP: pkill -1 gpg-agent it should start working then. The problem is due to a race condition in the logging code; A fix is already in the GnuPG cvs and a new release will follow soon. Salam-Shalom, Werner From aegypten-issues at intevation.de Tue Jun 29 14:35:40 2004 From: aegypten-issues at intevation.de (David Faure) Date: Tue Jun 29 21:12:52 2004 Subject: [issue228] KMail composer: disabling signing for an attachment leads to no body sent Message-ID: <1088512540.54.0.786862851628.issue228@intevation.de> New submission from David Faure : In KMail, compose a new mail, and * choose OpenPGP/MIME * activate signing in the toolbar * write some text in the body * add an attachment * disable signing for that attachment * send the mail (to yourself) The resulting mail has no body at all, only the attachment. The difference with the normal case is: mEarlyAddAttachments=false and mAllAttachmentsAreInBody=false (they are true when signing the attachment) Hmm, not sure if related, but the code basically does if ( mEarlyAddAttachments ) { ... } else { // !earlyAddAttachments // the signed body must not be 8bit encoded mOldBodyPart.setBodyAndGuessCte(body, allowedCTEs, ..., doSign); } // create S/MIME body part for signing and/or encrypting mOldBodyPart.setBodyEncoded( body ); Doesn't the last line invalidate the contents of the "else"? Anyway the problem is later, since mEncodedBody is OK. Further investigation shows that the && ( !mEarlyAddAttachments || !mAllAttachmentsAreInBody ) in MessageComposer::addBodyAndAttachments() is the first problem (those are false, but there *is* an attachment in this mail, so we need to go in the first part of this if() AFAICS). But even commenting that out doesn't help, still no body in the resulting mail. The Dw* stuff totally escapes me so I'm stopping there... ---------- assignedto: marc messages: 1145 nosy: david, marc priority: bug status: unread title: KMail composer: disabling signing for an attachment leads to no body sent topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Jun 29 14:34:24 2004 From: aegypten-issues at intevation.de (David Faure) Date: Tue Jun 29 21:13:49 2004 Subject: [issue227] KMail composer: sign/encrypt checkboxes don't appear after adding attachment Message-ID: <1088512464.68.0.273891630443.issue227@intevation.de> New submission from David Faure : In KMail, compose a new mail, and * choose OpenPGP/MIME * add an attachment => the checkboxes in the mime tree don't appear. I have to re-select OpenPGP/MIME in the combo for them to appear. ---------- assignedto: marc messages: 1144 nosy: david, marc priority: bug status: unread title: KMail composer: sign/encrypt checkboxes don't appear after adding attachment topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________