From aegypten-issues at intevation.de Tue Aug 3 08:23:43 2004 From: aegypten-issues at intevation.de (Hase) Date: Tue Aug 3 08:20:45 2004 Subject: [issue239] Abwesenheitsnotiz: Pfiiqs Message-ID: <3D9D3A7E0F11E042987522FCC2A1DC6101E37E@HERMES> New submission from Hase : I will be back in the office on 05 August 2004. For urgent matters please contact Ms Christine Jeulin (jeulin@gfa-management.de). Thank you! Regards, Inke Hase ---------- messages: 1249 nosy: hase status: unread title: Abwesenheitsnotiz: Pfiiqs ______________________________________________________ Aegypten issue tracker ______________________________________________________ From wk at gnupg.org Wed Aug 4 19:11:49 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 4 19:13:30 2004 Subject: pinentry: minor annoyances with --help In-Reply-To: <200407222028.39621.peter_e@gmx.net> (Peter Eisentraut's message of "Thu, 22 Jul 2004 20:28:39 +0200") References: <200407222028.39621.peter_e@gmx.net> Message-ID: <87k6weu8tm.fsf@wheatstone.g10code.de> On Thu, 22 Jul 2004 20:28:39 +0200, Peter Eisentraut said: > This is concerning pinentry 0.7.1. For some reason, the output of > pinentry-foo --help goes to stderr, not stdout. This is inconsistent Thanks for reporting. I just fixed it in the CVS. > $ pinentry-qt --version/--help > Xlib: extension "GLX" missing on display ":0.0". > Xlib: extension "GLX" missing on display ":0.0". > [real information follows...] That is the usual way of doing thing. Some options are to be passed to the GUI and the usual way to handle this is by letting the GUI init fucntion remove the args from the array and then continue with the application's option parsing. The advantage is that the GUI lib may add new GUI options to all applications without the need to change the applications proper. Adding an extra hook to parse "--help" is theoretically possible but not good style. Anyway the Xlibn error stuff should go to stderr and --help and ---version go to stdout. Thanks, Werner From aegypten-issues at intevation.de Fri Aug 6 18:22:53 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Mon Aug 9 13:21:15 2004 Subject: [issue240] kleopatra: segfault when reimporting deleted certificates Message-ID: <1091809373.82.0.778807861538.issue240@intevation.de> New submission from Bernhard Herzog : segfault when reimporting deleted certificates. To reproduce: - switch to hierarchical view - select a root certificate and all its children. Export them all into a pem so that we can reimport them later. - select the root certificate alone - Contextmenu: Delete - Confirm that you want to delete that root cert and all its children. After that the certificates are gone. - now import the pem you exported earlier -> sefault after clicking OK in the dialog with the import result. Traceback: [New Thread 1024 (LWP 22579)] 0x41729a59 in wait4 () from /lib/libc.so.6 #0 0x41729a59 in wait4 () from /lib/libc.so.6 #1 0x417a0e48 in __check_rhosts_file () from /lib/libc.so.6 #2 0x415eb453 in waitpid () from /lib/libpthread.so.0 #3 0x40acb5dd in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #4 0x415e8f54 in pthread_sighandler () from /lib/libpthread.so.0 #5 0x416b26b8 in sigaction () from /lib/libc.so.6 #6 0x400c34c4 in Kleo::KeyListViewItem::KeyListViewItem (this=0x8194220, parent=0x815d890, key=@0x815b850) at keylistview.cpp:357 #7 0x400c2ad1 in Kleo::KeyListView::doHierarchicalInsert (this=0x8125bd0, key=@0x815b850) at keylistview.cpp:238 #8 0x400c286d in Kleo::KeyListView::slotUpdateTimeout (this=0x8125bd0) at keylistview.cpp:213 #9 0x400c7918 in Kleo::KeyListView::flushKeys (this=0x8125bd0) at keylistview.h:199 #10 0x08065ee2 in CertManager::updateStatusBarLabels (this=0x8100b60) at certmanager.cpp:440 #11 0x08065dbd in CertManager::disconnectJobFromStatusBarProgress ( this=0x8100b60, err=@0xbfffed84) at certmanager.cpp:428 #12 0x08066d32 in CertManager::slotKeyListResult (this=0x8100b60, res=@0xbfffed84) at certmanager.cpp:583 #13 0x0806b7d5 in CertManager::qt_invoke (this=0x8100b60, _id=83, _o=0xbfffed30) at certmanager.moc:266 #14 0x40f1432a in QObject::activate_signal (this=0x816f730, clist=0x819db58, o=0xbfffed30) at kernel/qobject.cpp:2333 #15 0x40099252 in Kleo::KeyListJob::result (this=0x816f730, t0=@0xbfffed84) at keylistjob.moc:113 #16 0x400aba43 in Kleo::QGpgMEKeyListJob::doOperationDoneEvent (this=0x816f730) at qgpgmekeylistjob.cpp:101 #17 0x400ab05d in Kleo::QGpgMEJob::doSlotOperationDoneEvent (this=0x816f758, context=0x8130ef0, e=@0xbfffef80) at qgpgmejob.cpp:135 #18 0x400ac388 in Kleo::QGpgMEKeyListJob::slotOperationDoneEvent ( this=0x816f730, context=0x8130ef0, e=@0xbfffef80) at qgpgmekeylistjob.h:63 #19 0x400abc7a in Kleo::QGpgMEKeyListJob::qt_invoke (this=0x816f730, _id=4, _o=0xbfffeeac) at qgpgmekeylistjob.moc:95 #20 0x40f1432a in QObject::activate_signal (this=0x8145240, clist=0x8146488, o=0xbfffeeac) at kernel/qobject.cpp:2333 #21 0x401d91f1 in QGpgME::EventLoopInteractor::operationDoneEventSignal ( this=0x8145240, t0=0x8130ef0, t1=@0xbfffef80) at eventloopinteractor.moc:153 #22 0x401d8d00 in QGpgME::EventLoopInteractor::operationDoneEvent ( this=0x8145240, context=0x8130ef0, e=@0xbfffef80) at eventloopinteractor.cpp:96 #23 0x40209011 in GpgME::EventLoopInteractor::Private::eventIOCb ( data=0x8130ef0, type=GPGME_EVENT_DONE, type_data=0xbffff058) at eventloopinteractor.cpp:125 #24 0x40220eaf in _gpgme_wait_user_event_cb (data=0x819aae0, type=GPGME_EVENT_DONE, type_data=0xbffff058) at wait-user.c:123 #25 0x4022cd0a in gpgsm_io_event (engine=0x819f638, type=GPGME_EVENT_DONE, type_data=0xbffff058) at engine-gpgsm.c:1557 #26 0x40227b89 in _gpgme_engine_io_event (engine=0x8198398, type=GPGME_EVENT_DONE, type_data=0xbffff058) at engine.c:485 #27 0x40220d62 in _gpgme_user_io_cb_handler (data=0x8175168, fd=19) at wait-user.c:70 #28 0x40209377 in GpgME::EventLoopInteractor::actOn (this=0x8145268, fd=19, dir=Read) at eventloopinteractor.cpp:180 #29 0x401d8c65 in QGpgME::EventLoopInteractor::slotReadActivity ( this=0x8145240, socket=19) at eventloopinteractor.cpp:84 #30 0x401d9329 in QGpgME::EventLoopInteractor::qt_invoke (this=0x8145240, _id=3, _o=0xbffff194) at eventloopinteractor.moc:166 #31 0x40f1432a in QObject::activate_signal (this=0x81bce98, clist=0x81a6ab0, o=0xbffff194) at kernel/qobject.cpp:2333 #32 0x40f146f3 in QObject::activate_signal (this=0x81bce98, signal=2, param=19) at kernel/qobject.cpp:2426 #33 0x412659da in QSocketNotifier::activated (this=0x81bce98, t0=19) at .moc/debug-shared-mt/moc_qsocketnotifier.cpp:85 #34 0x40f328a2 in QSocketNotifier::event (this=0x81bce98, e=0xbffff408) at kernel/qsocketnotifier.cpp:271 #35 0x40eadcd5 in QApplication::internalNotify (this=0xbffff674, receiver=0x81bce98, e=0xbffff408) at kernel/qapplication.cpp:2582 #36 0x40eacdbb in QApplication::notify (this=0xbffff674, receiver=0x81bce98, e=0xbffff408) at kernel/qapplication.cpp:2305 #37 0x40a3e5b9 in KApplication::notify (this=0xbffff674, receiver=0x81bce98, event=0xbffff408) at kapplication.cpp:507 #38 0x4125bd94 in QApplication::sendEvent (receiver=0x81bce98, event=0xbffff408) at .moc/debug-shared-mt/../../kernel/qapplication.h:492 #39 0x40e9c6e2 in QEventLoop::activateSocketNotifiers (this=0x80cd8c0) at kernel/qeventloop_unix.cpp:579 #40 0x40e56a3c in QEventLoop::processEvents (this=0x80cd8c0, flags=4) at kernel/qeventloop_x11.cpp:340 #41 0x40ec4290 in QEventLoop::enterLoop (this=0x80cd8c0) at kernel/qeventloop.cpp:198 #42 0x40ec41c9 in QEventLoop::exec (this=0x80cd8c0) at kernel/qeventloop.cpp:145 #43 0x40eade8d in QApplication::exec (this=0xbffff674) at kernel/qapplication.cpp:2705 #44 0x080637f9 in main (argc=1, argv=0xbffff7e4) at main.cpp:83 ---------- messages: 1265 nosy: bh priority: bug status: unread title: kleopatra: segfault when reimporting deleted certificates topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Aug 10 02:49:49 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Tue Aug 10 02:46:34 2004 Subject: [issue241] Add *.p7m to filter for import dialog Message-ID: <1092098989.34.0.467244789301.issue241@intevation.de> New submission from Jan-Oliver Wagner : The menu item File->Import certificates raises a dialog where you currently can not easily select a *.p7c file. The default filter should add *.p7c, so that by default we see all *.pem, *.der, *.p12 and *.p7c. ---------- assignedto: marc messages: 1278 nosy: jan, marc priority: urgent status: unread title: Add *.p7m to filter for import dialog topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Aug 10 03:00:08 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Tue Aug 10 02:56:52 2004 Subject: [issue242] mutt: string problem Message-ID: <1092099608.29.0.402532959512.issue242@intevation.de> New submission from Jan-Oliver Wagner : If you choose to sign or encrypt with S/MIME, there is a message like S/MIME: Signieren (PGP/MIME) or S/MIME: Verschl?sseln (PGP/MIME) Apparently it is not PGP/MIME. I suspect a string problem here. ---------- assignedto: moritz messages: 1281 nosy: jan, moritz priority: bug status: unread title: mutt: string problem topic: mutt ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Tue Aug 10 14:07:36 2004 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Tue Aug 10 14:04:20 2004 Subject: [issue243] kleopatra: make key length for new keypairs configurable Message-ID: <1092139656.26.0.0418896551187.issue243@intevation.de> New submission from Bernhard Herzog : The key length of a new key pair should be configurable in the wizard. Currently it's hard wired to 1024 bits. ---------- messages: 1285 nosy: bh priority: bug status: unread title: kleopatra: make key length for new keypairs configurable topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Aug 12 01:59:21 2004 From: aegypten-issues at intevation.de (Moritz Schulte) Date: Thu Aug 12 01:56:06 2004 Subject: [issue244] Mutt: crash when canceling pinentry dialog Message-ID: <1092268761.58.0.172790825105.issue244@intevation.de> New submission from Moritz Schulte : I just noticed that my Mutt crashes when clicking "cancel" in my pinentry dialog box; at least when I'm about to sign a message. I will debug this later on today. ---------- assignedto: moritz messages: 1297 nosy: moritz priority: critical status: in-progress title: Mutt: crash when canceling pinentry dialog ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Mon Aug 16 12:00:37 2004 From: aegypten-issues at intevation.de (Bernhard Reiter) Date: Mon Aug 16 11:57:20 2004 Subject: [issue246] mutt does not do additional encrypt-to Message-ID: <1092650437.31.0.316568308954.issue246@intevation.de> New submission from Bernhard Reiter : Mutt 1.5.6i CVS from last week patch-1.5.6cvs.g10.gpgme.3 patch-1.5.6cvs.g10.largefile.1 patch-1.5.6cvs.g10.issue236.1 patch-1.5.6cvs.g10.mdn.2 patch-1.5.6cvs.g10.SmimeCryptAlg.1 in .gnupg/gpgsm.conf there is a line: encrypt-to 59:42:F3:ED:0C:7F:6B:E3:ED:91:B4:18:7B:EF:DD:B4:B3:A6:05:99 when doing gpgsm -er someother x >x.e x.e is encrypted to someother and my key given above. But when sending an email with mutt, the object is not encrypted to the key. I don't know if this a gpgme or mutt problem. ---------- assignedto: werner messages: 1306 nosy: bernhard, bh, werner priority: bug status: unread title: mutt does not do additional encrypt-to topic: GPGME, mutt ______________________________________________________ Aegypten issue tracker ______________________________________________________ From joschua10 at gmx.de Mon Aug 16 12:10:39 2004 From: joschua10 at gmx.de (joschua10@gmx.de) Date: Mon Aug 16 12:07:52 2004 Subject: export function Message-ID: <28000.1092651039@www68.gmx.net> I used GPA for a long time to do my key management work. Thank you all for this great utility! But now I tried to export my public key to send them with email. I wondered why the key is not exported "armored". Thus I had to use gnupg to export my armored key which is more complicated then GPA. I wondered why GPA is doing so and if there is a disadvantage of armored output to dearmored output? Greetings, Josch -- NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler! GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl From bernhard at intevation.de Mon Aug 16 14:09:06 2004 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon Aug 16 14:05:51 2004 Subject: export function In-Reply-To: <28000.1092651039@www68.gmx.net> References: <28000.1092651039@www68.gmx.net> Message-ID: <20040816120906.GA1244@intevation.de> On Mon, Aug 16, 2004 at 12:10:39PM +0200, joschua10@gmx.de wrote: > I used GPA for a long time to do my key management work. Thank you all for > this great utility! > But now I tried to export my public key to send them with email. I wondered > why the key is not exported "armored". Thus I had to use gnupg to export my > armored key which is more complicated then GPA. I wondered why GPA is doing > so and if there is a disadvantage of armored output to dearmored output? There is no disadvantage of armored that I can think of. The file will get slightly larger, but that is a minor drawback. Maybe this is just an oversight within GPA. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040816/bb341fa7/attachment.bin From joschua10 at gmx.de Mon Aug 16 22:11:26 2004 From: joschua10 at gmx.de (Markus Hassler) Date: Mon Aug 16 22:08:40 2004 Subject: export function References: <20040816120906.GA1244@intevation.de> Message-ID: <21675.1092687086@www41.gmx.net> Ok, I hope this will be fixed in the future. > On Mon, Aug 16, 2004 at 12:10:39PM +0200, joschua10@gmx.de wrote: > > I used GPA for a long time to do my key management work. Thank you all > for > > this great utility! > > But now I tried to export my public key to send them with email. I > wondered > > why the key is not exported "armored". Thus I had to use gnupg to export > my > > armored key which is more complicated then GPA. I wondered why GPA is > doing > > so and if there is a disadvantage of armored output to dearmored output? > > There is no disadvantage of armored that I can think of. > The file will get slightly larger, but that is a minor drawback. > > Maybe this is just an oversight within GPA. > -- NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler! GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl From mcoca at gnu.org Tue Aug 17 01:10:23 2004 From: mcoca at gnu.org (Miguel Coca) Date: Tue Aug 17 01:07:11 2004 Subject: export function In-Reply-To: <28000.1092651039@www68.gmx.net> References: <28000.1092651039@www68.gmx.net> Message-ID: <20040816231023.GA1660@mycroft> Hi, On Mon, Aug 16, 2004 at 12:10:39 +0200, joschua10@gmx.de wrote: > I used GPA for a long time to do my key management work. Thank you all for > this great utility! > But now I tried to export my public key to send them with email. I wondered > why the key is not exported "armored". Thus I had to use gnupg to export my > armored key which is more complicated then GPA. I wondered why GPA is doing > so and if there is a disadvantage of armored output to dearmored output? You can export armored keys in advanced mode. Open the preferences dialog (edit/preferences) and set "Use advanced mode" to "Yes". With that option several options that are considered confusing for beginners are enabled. Cheers, -- Miguel Coca (mcoca@gnu.org) http://miguel.cocabarrionuevo.com/ OpenPGP: E60A CBF4 5C6F 914E B6C1 C402 8C4D C7B6 27FC 3CA8 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20040817/ea0701b6/attachment.bin From cepl at surfbest.net Tue Aug 17 17:19:32 2004 From: cepl at surfbest.net (Matej Cepl) Date: Tue Aug 17 17:52:10 2004 Subject: Problems with importing a GTE CyberTrust Root cert Message-ID: <200408171119.37261.cepl@surfbest.net> Hi, I've got an email from somebody who has a S/MIME cert issued by "CN=Comodo Class 3 Security Services CA,OU=(c)2002 Comodo Limited+OU=Terms and Conditions of use: http://www.comodo.net/repository+OU=Comodo Trust Network,O=Comodo Limited,C=GB" (serial no. 0200029B), which was in turn issued by "CN=GTE CyberTrust Root,O=GTE Corporation,C=US" (serial no. 01A3). Unfortunately when I have downloaded all required certificates (GTE ones are from http://www.instantssl.com/ssl-certificate-support/cert_installation/GTECyberTrustRootCA.crt and http://www.instantssl.com/ssl-certificate-support/cert_installation/GTECyberTrustGlobalRoot2018.crt), I've got attached result from gpgsm --list-sigs GTE. Is the mistake in the keys themselves or in gpgsm (BTW, I am using gpgsm 0.9.4 on Debian/woody from a binary package from www.backports.org)? How can I make this work? Thanks, Matej Cepl -- Matej Cepl, http://www.ceplovi.cz/matej GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC 138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488 He has never been known to use a word that might send a reader to the dictionary. -- William Faulkner (about Ernest Hemingway) -------------- next part -------------- /home/matej/.gnupg/pubring.kbx ------------------------------ Serial number: 01A5 Issuer: /CN=GTE CyberTrust Global Root/OU=GTE CyberTrust Solutions, Inc./O=GTE Corporation/C=US Subject: /CN=GTE CyberTrust Global Root/OU=GTE CyberTrust Solutions, Inc./O=GTE Corporation/C=US validity: 1998-08-13 00:29:00 Z through 2018-08-13 23:59:00 Z key usage: [error: No Value] chain length: [error: No Value] fingerprint: 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74 Serial number: 01A3 Issuer: /CN=GTE CyberTrust Root/O=GTE Corporation/C=US Subject: /CN=GTE CyberTrust Root/O=GTE Corporation/C=US validity: 1996-02-23 23:01:00 Z through 2006-02-23 23:59:00 Z key usage: [error: No Value] chain length: [error: No Value] fingerprint: 90:DE:DE:9E:4C:4E:9F:6F:D8:86:17:57:9D:D3:91:BC:65:A6:89:64 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : /pipermail/attachments/20040817/281e6ecb/attachment.bin From bernhard at intevation.de Tue Aug 17 18:53:10 2004 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Aug 17 18:49:55 2004 Subject: Problems with importing a GTE CyberTrust Root cert In-Reply-To: <200408171119.37261.cepl@surfbest.net> References: <200408171119.37261.cepl@surfbest.net> Message-ID: <20040817165310.GD22092@intevation.de> On Tue, Aug 17, 2004 at 11:19:32AM -0400, Matej Cepl wrote: > I've got an email from somebody who has a S/MIME cert issued by > "CN=Comodo Class 3 Security Services CA,OU=(c)2002 Comodo Limited+OU=Terms > and Conditions of use: http://www.comodo.net/repository+OU=Comodo Trust > Network,O=Comodo Limited,C=GB" (serial no. 0200029B), which was in turn > issued by "CN=GTE CyberTrust Root,O=GTE Corporation,C=US" (serial no. > 01A3). Unfortunately when I have downloaded all required certificates (GTE > ones are from > http://www.instantssl.com/ssl-certificate-support/cert_installation/GTECyberTrustRootCA.crt > and > http://www.instantssl.com/ssl-certificate-support/cert_installation/GTECyberTrustGlobalRoot2018.crt), > I've got attached result from gpgsm --list-sigs GTE. > > Is the mistake in the keys themselves or in gpgsm (BTW, I am using gpgsm > 0.9.4 on Debian/woody from a binary package from www.backports.org)? How > can I make this work? Try the gpgsm from the latest gnupg-1.9.x, this is the supported version. If the problem persists, please report is as bug. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040817/eca4cfcf/attachment.bin From bernhard at intevation.de Tue Aug 17 18:54:09 2004 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Aug 17 18:50:51 2004 Subject: GPA export function In-Reply-To: <20040816231023.GA1660@mycroft> References: <28000.1092651039@www68.gmx.net> <20040816231023.GA1660@mycroft> Message-ID: <20040817165409.GE22092@intevation.de> On Tue, Aug 17, 2004 at 01:10:23AM +0200, Miguel Coca wrote: > On Mon, Aug 16, 2004 at 12:10:39 +0200, joschua10@gmx.de wrote: > > I used GPA for a long time to do my key management work. Thank you all for > > this great utility! > > But now I tried to export my public key to send them with email. I wondered > > why the key is not exported "armored". Thus I had to use gnupg to export my > > armored key which is more complicated then GPA. I wondered why GPA is doing > > so and if there is a disadvantage of armored output to dearmored output? > > You can export armored keys in advanced mode. Open the preferences > dialog (edit/preferences) and set "Use advanced mode" to "Yes". With > that option several options that are considered confusing for > beginners are enabled. I agree with joschua10, it probably should be switched around and have armored by default for regular users with advanced user being able to switch it off. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040817/532e1dc2/attachment.bin From cepl at surfbest.net Tue Aug 17 21:04:40 2004 From: cepl at surfbest.net (Matej Cepl) Date: Tue Aug 17 21:03:07 2004 Subject: Problems with importing a GTE CyberTrust Root cert In-Reply-To: <20040817165310.GD22092@intevation.de> References: <200408171119.37261.cepl@surfbest.net> <20040817165310.GD22092@intevation.de> Message-ID: <200408171504.43370.cepl@surfbest.net> On Tuesday 17 of August 2004 12:53, Bernhard Reiter wrote: > Try the gpgsm from the latest gnupg-1.9.x, > this is the supported version. Is there any Debian package for gnupg-1.9.* (especially Debian/woody would be helpful, but I am willing to backport any other one) and libgpgme? Thanks for reply, Matej Cepl -- Matej Cepl, http://www.ceplovi.cz/matej GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC 138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488 Just remember, brothers and sisters--their skins may be white, but their souls are just as black as ours! -- a black preacher From aegypten-issues at intevation.de Thu Aug 19 15:20:03 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Thu Aug 19 15:16:48 2004 Subject: [issue247] encrypted drafts not re-editable Message-ID: <1092921603.13.0.206799781678.issue247@intevation.de> New submission from Jan-Oliver Wagner : When I store an encrypted draft it looks all ok in the draft folder. But reediting it, makes stange charcters appear in the composer field. I loose the whole text! ---------- assignedto: marc messages: 1318 nosy: jan, marc priority: critical status: unread title: encrypted drafts not re-editable topic: KMail ______________________________________________________ Aegypten issue tracker ______________________________________________________ From mcoca at gnu.org Sat Aug 21 19:49:20 2004 From: mcoca at gnu.org (Miguel Coca) Date: Sat Aug 21 19:46:06 2004 Subject: Turkish translation files In-Reply-To: <40D57829.8020303@su.sabanciuniv.edu> References: <40D57829.8020303@su.sabanciuniv.edu> Message-ID: <20040821174920.GB20933@mycroft> On Sun, Jun 20, 2004 at 14:42:33 +0300, Can Berk G?der wrote: > Sorry for the incredible delay, but I was dealing with my finals. > Attached are the Turkish translation files for GPA 0.7 I just added the translation to CVS. I'm really sorry it took so long. Thanks, -- Miguel Coca (mcoca@gnu.org) http://miguel.cocabarrionuevo.com/ OpenPGP: E60A CBF4 5C6F 914E B6C1 C402 8C4D C7B6 27FC 3CA8 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20040821/2894a73b/attachment.bin From mcoca at gnu.org Sat Aug 21 19:51:45 2004 From: mcoca at gnu.org (Miguel Coca) Date: Sat Aug 21 19:48:40 2004 Subject: GPA export function In-Reply-To: <20040817165409.GE22092@intevation.de> References: <28000.1092651039@www68.gmx.net> <20040816231023.GA1660@mycroft> <20040817165409.GE22092@intevation.de> Message-ID: <20040821175145.GC20933@mycroft> On Tue, Aug 17, 2004 at 18:54:09 +0200, Bernhard Reiter wrote: > I agree with joschua10, it probably should be switched around > and have armored by default for regular users > with advanced user being able to switch it off. Agreed. When changing it, I realize having unarmored as the default was really a bug. In advanced mode, armored was actually selected by default. It's fixed now. Thanks, -- Miguel Coca (mcoca@gnu.org) http://miguel.cocabarrionuevo.com/ OpenPGP: E60A CBF4 5C6F 914E B6C1 C402 8C4D C7B6 27FC 3CA8 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20040821/e3863edf/attachment.bin From aegypten-issues at intevation.de Tue Aug 24 14:13:27 2004 From: aegypten-issues at intevation.de (Jan-Oliver Wagner) Date: Tue Aug 24 14:10:11 2004 Subject: [issue248] Kleopatra: missing german translations Message-ID: <1093349607.29.0.694612333321.issue248@intevation.de> New submission from Jan-Oliver Wagner : In the Kleoptra configration, Group "Verzeichnisdienste": Various strings are untranslated, e.g. "X.500 Directory Services", "Add Service...", "Remove Service", "LDAP timeout (minutes:seconds)", etc. Also look into the Add Service dialog - there are english terms as well. ---------- assignedto: marc messages: 1326 nosy: jan, marc priority: urgent status: unread title: Kleopatra: missing german translations topic: certmanager ______________________________________________________ Aegypten issue tracker ______________________________________________________ From info at moritz-naumann.com Mon Aug 16 21:49:06 2004 From: info at moritz-naumann.com (Moritz Naumann) Date: Tue Sep 21 09:04:30 2004 Subject: Key creation wizard calculates incorrect key expiry date Message-ID: <41211077.9090708@moritz-naumann.com> Hi, I just realized that GPA v0.7.0 would create keys valid for only one day when using the "expires after" option and requesting a 1 year expiry. I typed "1" into the amount box and selected "years" (in my german language version it actually says "Jahren") as the unit. I did not try this in any other language version. What irritates me a little is that it is possible to edit the unit string. This should be a non-editable drop-down box IMHO. I could imagine that the key creation wizard checks whether the unit string entered by the user (or chosen via the drop-down menu) equals the english-language terms for "days", "weeks", "months", "years" only and defaults to "days" if no match is found. This would not work with non-english unit terms, of course. I did not check the source code, though. So this is just an assumption. Thanks for this fine piece of software and thanks to the other german tax payers for partially funding its development. ;-) Greetings, Moritz Naumann -- Moritz Naumann Schulterblatt 62 20357 Hamburg Phone ++ 49 (0)40 27141282 Mobile ++ 49 (0)179 4697962 eMail YOURFIRSTNAME.YOURLASTNAME@moritz-naumann.com (Please replace 'YOURFIRSTNAME' and 'YOURLASTNAME' but keep the dot) From l.savernik at aon.at Thu Aug 19 19:28:09 2004 From: l.savernik at aon.at (Leo Savernik) Date: Tue Sep 21 09:04:35 2004 Subject: [patch] really use rpath Message-ID: <200408191935.33871.l.savernik@aon.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, If --enable-rpath is given, it should actually be linked into the executable. mfg Leo PS.: Please CC me, I'm not subscribed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBJOTjj5jssenUYTsRAtbTAJ9Cc831L9KX1IGq7ycqquOWq5oakQCaAzNQ uNpa41B7n33Tga4wKwymCKU= =vBcL -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.am.diff Type: text/x-makefile Size: 443 bytes Desc: not available Url : /pipermail/attachments/20040819/5026016a/Makefile.am-0001.bin From marc at klaralvdalens-datakonsult.se Wed Aug 25 12:18:15 2004 From: marc at klaralvdalens-datakonsult.se (Marc Mutz) Date: Tue Sep 21 09:04:38 2004 Subject: gpgme license Message-ID: <200408251221.17885.marc@klaralvdalens-datakonsult.se> Hi, since the Aegypten-2 project, we committed ourselves to use gpgme in KDEPIM to interface to gnupg 1.x (and pre-2.0). Unfortunately, this conflicts with the possibility to have KDEPIM native on Windows. The problem here is of course that Qt on Windows is not available in a GPL version, and the alternative cygwin solution is considered by many to not be native enough to compete with native Windows solutions. So on behalf of the KDEPIM team I'd like to ask the gpgme team to consider a change in the license of gpgme. We would be interested in having either the Qt exception added (see below for the exact wording (same as the one suggested in the FSF FAQ)), or go the full way and have it LGPL. The benfits for gpgme/gnupg would be a chance to gain in the size of the user base. As we have seen during Aegypten-2, KDEPIM using gpgme seriously let to a lot of bug fixes and portability fixes for gpgme being posted back upstream from libgpgme-copy in KDEPIM CVS. The change in usebase from Unix to Windows could have a similar effect on the stability and portability of gpgme. What are your thoughts on this issue? Qt exception as is is currently worded in KMail: In addition, as a special exception, the copyright holders give permission to link the code of this program with any edition of the Qt library by Trolltech AS, Norway (or with modified versions of Qt that use the same license as Qt), and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than Qt. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. Marc -- Marc Mutz -- marc@klaralvdalens-datakonsult.se, mutz@kde.org Klar?lvdalens Datakonsult AB, Platform-independent software solutions