Version: 3.1 (using KDE KDE 3.1) Installed from: Debian stable Packages If a certificate is signed by the server itself, kmail pops up a dialog warning about this. If selected "forever" when asked to save the certificate for 'this session only' or 'forever', it still doesn't store it forever; kmail asks for validation each time it is restarted. This didn't happen with kmail <= 3.0.5, it has come up with the 3.1 release.
This seems to be an update problem. I had the same problem but it went away when I re-created my ~/.kde.
i have this exact same problem. i'll check me config files and see if i can find it (deleting .kde sounds unpleasant....) -mcclain
i recreated ~/.kde and am having the same problem still. hmm.
I have the same problem (KDE_3_1, gcc-3.2, Mandrake). When I ask to accept the certificate forever, kmail seems to accept it for only one day. Even if I restart kmail (different from session only I think). - L.
My mail provider's SSL certificate is issued for www.fastmail.fm, but I use different host names to access their IMAP service (such as imap.fastmail.fm). In this situation, I get the same dialog box, and it also forgets the certificate, even if I select remember/accept forever. I have also seen something similar in Konqueror. Is there a generic KDE security handler? Is it possible this is a bug in that component rather than just KMail. I am using KDE 3.1 with KMail 1.5.
Subject: Re: security certificate not stored "forever" On Wednesday 19 February 2003 04:27, Michael Wardle wrote: > I have also seen something similar in Konqueror. Is there a generic > KDE security handler? Is it possible this is a bug in that component > rather than just KMail. Yes. KMail doesn't check the certificates itself.
*** Bug 54964 has been marked as a duplicate of this bug. ***
I check my mail in kmail with pop3s. I get the dialog to accept or not the certificate. I select "forever" Then I go in kcontrol / crypto / peer ssl certificates and check that my certificate is marked "cache permanently" and "accept". I go in kmail and check my mail again. No need to accept the certificate since it is cached and permanently accepted I go in kcontrol / crypto / peer ssl certificates. Surprise. My certificate is no longer cached forever but only for a few hours. Hope it helps... - Leon "cache permanently". Instead it I select "forever" the certificate in kcontrol / Cryptois marked
Subject: kdebase/kcontrol/konqhtml CVS commit by staikos: Make "cancel" work. CCMAIL: 54121-done@bugs.kde.org M +8 -3 pluginopts.cpp 1.24 --- kdebase/kcontrol/konqhtml/pluginopts.cpp #1.23:1.24 @@ -259,6 +259,4 @@ void KPluginOptions::scan() } - // find nspluginscan executable - m_progress = new QProgressDialog( i18n("Scanning for plugins"), i18n("Cancel"), 100, this ); KProcIO* nspluginscan = new KProcIO; QString scanExe = KGlobal::dirs()->findExe("nspluginscan"); @@ -272,4 +270,7 @@ void KPluginOptions::scan() return; } + + // find nspluginscan executable + m_progress = new QProgressDialog( i18n("Scanning for plugins"), i18n("Cancel"), 100, this ); m_progress->setProgress( 5 ); @@ -281,4 +282,6 @@ void KPluginOptions::scan() connect(nspluginscan, SIGNAL(processExited(KProcess *)), this, SLOT(scanDone())); + connect(m_progress, SIGNAL(cancelled()), this, SLOT(scanDone())); + if (nspluginscan->start()) kapp->enter_loop(); @@ -290,4 +293,5 @@ void KPluginOptions::scan() load(); delete m_progress; + m_progress = 0; } @@ -295,5 +299,6 @@ void KPluginOptions::progress(KProcIO *p { QString line; - while(proc->readln(line) > 0); + while(proc->readln(line) > 0) + ; m_progress->setProgress(line.stripWhiteSpace().toInt()); }
My apologies, wrong bug :)
I hate to tell you but I can't reproduce this right now. I'm connecting to a site with an expired certificate for testing. I've tried everything I can think of, all combinations of actions, etc. I'm using HEAD. Any possible hints on how to trigger it beyond what's listed here?
Subject: Re: security certificate not stored "forever" On Sunday 09 March 2003 11:18 pm, you wrote: > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=54121 > > ------- Additional Comments From staikos@kde.org 2003-03-10 05:18 ------- > I hate to tell you but I can't reproduce this right now. I'm connecting to > a site with an expired certificate for testing. I've tried everything I > can think of, all combinations of actions, etc. I'm using HEAD. Any > possible hints on how to trigger it beyond what's listed here? Mine is not expired but self signed. I will install a debug version of kssl and try to pinpoint what the problem is. - L.
can you reproduce it in 3.1? It could be it's fixed already in HEAD and no one closed this bug.
Subject: Re: security certificate not stored "forever" On Monday 10 March 2003 11:33, you wrote: > can you reproduce it in 3.1? It could be it's fixed already in HEAD and no > one closed this bug. No I cannot. I would have been the person to fix this anyways, since it's my code and I still maintain it. Perhaps it was fixed as a side-effect of another patch. I actively use 3.1-branch and HEAD though, and I don't see it anywhere. Note: the certificate I mentioned is not just expired, it's also self-signed.
I just tried with KDE_3_1_BRANCH. The bug is gone. Everything seems to work properly now. I would have liked to know what has changed. - Leon
Subject: Re: security certificate not stored "forever" On Monday 10 March 2003 18:23, you wrote: > I just tried with KDE_3_1_BRANCH. The bug is gone. > Everything seems to work properly now. > I would have liked to know what has changed. Me too. :-) What exact code were you using before? Maybe I can do a cvs diff from there.
Subject: Re: security certificate not stored "forever" > Me too. :-) > What exact code were you using before? Maybe I can do a cvs > diff from there. I was using Mandrake's kdelibs-3.1-33mdk (cooker). I inspected all the mdk patches and found nothing relevant. I also looked at all the cvs changes in KDE_3_1_BRANCH and found nothing relevant. News: the problem appears again when I replace libkio.so by the version found in the kdelibs-3.1-55mdk binaries. This definitely *is* a mandrake problem. Still I scanned all the differences between this and KDE_3_1_BRANCH to no avail. I also tried to compile KDE_3_1_BRANCH with Mandrake compilation options without reproducing the bug either. At this point I vote for dumping the bug to Mandrake and closing it in the KDE database. - L.
Subject: Fwd: [kdelibs] New: security certificate not stored "forever" http://qa.mandrakesoft.com/show_bug.cgi?id=3150 Product: kdelibs Component: kdelibs Summary: security certificate not stored "forever" Version: 3.1-55mdk Platform: PC URL: http://bugs.kde.org/show_bug.cgi?id=54121 OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: kde@mandrakesoft.com ReportedBy: leon@bottou.org This KDE bug has been found to be Mandrake specific. http://bugs.kde.org/show_bug.cgi?id=54121 ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
The original reported reported this against Debian Unstable, and I am experiencing this with Red Hat Phoebe (the latest series of betas that will become Red Hat 8.1.). Both use KDE 3.1 final. I don't know why there's all this talk about the bug being Mandrake specific.
Subject: Re: security certificate not stored "forever" On Monday 10 March 2003 22:15, you wrote: > 04:15 ------- The original reported reported this against Debian Unstable, > and I am experiencing this with Red Hat Phoebe (the latest series of betas > that will become Red Hat 8.1.). > > Both use KDE 3.1 final. > > I don't know why there's all this talk about the bug being Mandrake > specific. Do you have any more information you can provide? I can't reproduce this.
The only information I can think of I provided earlier in this bug. Basically I'm using IMAPS for a host whose SSL certificate doesn't match.
Subject: Re: security certificate not stored "forever" On Monday 10 March 2003 22:41, you wrote: > 04:41 ------- The only information I can think of I provided earlier in > this bug. Basically I'm using IMAPS for a host whose SSL certificate > doesn't match. Ok for those who still see this bug, which gcc version was your KDE compiled with (specifically)?
I see this on KDE 3.1 release. I am unsure whether the bug still exhibits itself in a build from the latest version in the tree. I believe Red Hat 8.0.94 uses GCC 3.2.1.
Subject: Re: security certificate not stored "forever" > I don't know why there's all this talk about the bug being Mandrake > specific. I'm using kde 3.1 packages for Debian woody, originally from the official KDE mirrors, and currently Ralf's packages. I've been getting this bug right from the switch from KDE 3.0 to KDE 3.1. I use SSL for POP, and the certificate is self-signed from a company. Certificates from other service providers, like gmx.net and myrealbox.com don't give this warning, though. Maybe they are signed by some central authority.
I'm also using Debian packages, Karolina's GCC 2.95.2 versions. Their fairly similar to Ralfs.
Subject: Re: security certificate not stored "forever" On Monday 10 March 2003 10:15 pm, you wrote: > 04:15 ------- The original reported reported this against Debian Unstable, > and I am experiencing this with Red Hat Phoebe (the latest series of betas > that will become Red Hat 8.1.). > Both use KDE 3.1 final. Then i am obviously wrong. If the bug also shows in Debian and Redhat, it is not mandrake specific. To summarize my results: The bug occurs with the kdelibs-3.1-33mdk binaries and does not occur when replacing libkio.so.4.1.0 by a version compiled from the KDE_3_1_BRANCH as of March 9th. It comes back when using the libkio.so.4.1.0 from kdelibs-3.1-55mdk. I attach the output of diff -r -u8 --exclude Makefile\* kde/cvs/kdelibs/kio rpm/BUILD/kdelibs-3.1/kio in case someone sees something (no a very long diff) What I should do (and haven't done yet) is to apply the diff to KDE_3_1_BRANCH and recompile in the hope of reproducing the bug. So far I always had the bug with precompiled binaries. - L. - L. Created an attachment (id=1147) 55mdk.diff
Subject: Re: security certificate not stored "forever" > What I should do (and haven't done yet) is to apply the diff to > KDE_3_1_BRANCH and recompile in the hope of reproducing the bug. So far I > always had the bug with precompiled binaries. I just did that. No bug! I have now two versions of libkio.so.4.1.0 compiled from the same source below kdelibs/kio. One has the bug and the other does not. There are small differences in them such as the order of the subroutines. But the following commands return exactly the same results for both binaries: # Counts how many times each assembly language instruction occurs. $ objdump -d libkio.so.4.1.0 | grep '^ *[0-9a-f]*:' | cut -f3 | cut -d' ' -f1 | sort | uniq -c | sort -nr 207998 mov 54008 call 26714 lea 19703 jmp 18317 nop .... # Compare relocation records $ objdump -C --dynamic-reloc libkio.so.4.1.0 | sort .... 00299814 R_386_JUMP_SLOT QDir::absPath() const .... Next step for me is to perform 'rpm -ba' on Mandrake's source rpm and check the resulting libkio.so.4.1.0... Any better idea? - Leon
Subject: Re: security certificate not stored "forever" > I have now two versions of libkio.so.4.1.0 compiled from the same > source below kdelibs/kio. One has the bug and the other does not. Bingo. The difference is that the mandrake binary was compiled with the include files for openssl-0.9.7 and mine was compiled with the include files for openssl-0.9.6b. Yet the file kio/kssl/openssl.cc prefers loading libssl.so.0.9.6 even though kssl might be compiled with the 0.9.7 include files. These versions of openssl are *not* binary compatible. The openssl code tries the following library names 1) "libssl.so" This is the development library. It gets installed when the libssl0-devel package is installed (rare on end user machines). When installed it most likely corresponds to the include files installed on this machine, but not necessarily to those installed on the machine where kssl was compiled. 2) "libssl.so.0" On my machine this comes with libssl0-devel and links to libssl.so.0.9.6. 3) "libssl.so.0.9.6" "libssl.so.0.9.6b" "libssl.so.0.9.6c" This is the 0.9.6 version of the library. Of course things will go wrong if kssl was compiled for 0.9.7. My system has both /usr/lib/libssl.so.0.9.6 and /usr/lib/libssl.so.0.9.7 for compatibility purposes I guess. The development files are those for 0.9.6. But the mandrake binaries were compiled with the development files for 0.9.7. I think openssl.cc should include <openssl/opensslv.h> to find out the version number of the include files used for compiling kssl. The macros are documented in the include file. The macro SHLIB_VERSION_XXX are particularly relevant. The code should first try to load the exact version used for compiling. Only then should it try unversionned library names such as "libssl.so". Same for libcrypto I guess. - L.
Subject: Re: security certificate not stored "forever" Here is a simple workaround for people experiencing the problem. > The openssl code tries the following library names > 1) "libssl.so" > This is the development library. It gets installed when > the libssl0-devel package is installed (rare on end user machines). > When installed it most likely corresponds to the include files > installed on this machine, but not necessarily to those installed > on the machine where kssl was compiled. This should provide a workaround for people experiencing the problem. Make sure you install the development files for the version of openssl installed on your system. - mandrake(cooker): libopenssl0.9.7-devel-0.9.7a-1mdk.i586.rpm - redhat(rawhide): openssl-devel-0.9.7-2.i386.rpm - debian(unstable): libssl-dev 0.9.7a-1 This provides a libssl.so pointing to the 0.9.7 version. Kssl should prefer this one over the hardcoded 0.9.6 version. That should get rid of the bug. - L. P.S. -- Using 0.9.7 yields the following debug messages: kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: undefined symbol: PKCS7_content_free kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: undefined symbol: OpenSSL_add_all_algorithms kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: undefined symbol: OpenSSL_add_all_algorithms_conf kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: undefined symbol: OpenSSL_add_all_algorithms_noconf Georges would know whether this is important. Maybe openssl-0.9.7 requires other source code changes...
Subject: Re: security certificate not stored "forever" On Tuesday 11 March 2003 13:54, you wrote: > > I have now two versions of libkio.so.4.1.0 compiled from the same > > source below kdelibs/kio. One has the bug and the other does not. > > Bingo. > > The difference is that the mandrake binary was compiled > with the include files for openssl-0.9.7 and mine was compiled > with the include files for openssl-0.9.6b. > > Yet the file kio/kssl/openssl.cc prefers loading libssl.so.0.9.6 > even though kssl might be compiled with the 0.9.7 include files. > These versions of openssl are *not* binary compatible. > > The openssl code tries the following library names > 1) "libssl.so" > This is the development library. It gets installed when > the libssl0-devel package is installed (rare on end user machines). > When installed it most likely corresponds to the include files > installed on this machine, but not necessarily to those installed > on the machine where kssl was compiled. > 2) "libssl.so.0" > On my machine this comes with libssl0-devel and links to > libssl.so.0.9.6. 3) "libssl.so.0.9.6" "libssl.so.0.9.6b" "libssl.so.0.9.6c" > This is the 0.9.6 version of the library. > Of course things will go wrong if kssl was compiled for 0.9.7. > > My system has both /usr/lib/libssl.so.0.9.6 and /usr/lib/libssl.so.0.9.7 > for compatibility purposes I guess. The development files are those for > 0.9.6. But the mandrake binaries were compiled with the development files > for 0.9.7. > > I think openssl.cc should include <openssl/opensslv.h> to find out the > version number of the include files used for compiling kssl. The macros > are documented in the include file. The macro SHLIB_VERSION_XXX are > particularly relevant. The code should first try to load the exact version > used for compiling. Only then should it try unversionned library names such > as "libssl.so". Same for libcrypto I guess. This is an ongoing problem. opensslv.h was not used in the past because it did not exist and we were still compatible with those versions. However it makes it even more of a portability nightmare to try to formulate shared library names. There is another possibility that I am toying with for 3.2.0. I may make a new KDE library that statically links in all of the OpenSSL functionality it needs. Then we could dlopen that library instead of dlopening libssl itself. I think that would be a bit safer. I'll do what I can to address this issue asap.
Subject: Re: security certificate not stored "forever" On Tuesday 11 March 2003 14:14, you wrote: > P.S. -- > > Using 0.9.7 yields the following debug messages: > kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: > undefined symbol: PKCS7_content_free kdecore (KLibLoader): WARNING: > KLibrary: /usr/lib/libkdecore.so.4: undefined symbol: > OpenSSL_add_all_algorithms kdecore (KLibLoader): WARNING: KLibrary: > /usr/lib/libkdecore.so.4: undefined symbol: OpenSSL_add_all_algorithms_conf > kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: > undefined symbol: OpenSSL_add_all_algorithms_noconf > > Georges would know whether this is important. > Maybe openssl-0.9.7 requires other source code changes... This is already fixed in 3.1.1 and HEAD.
Can anyone show that this bug still happens even without an openssl binary incompatibility? Otherwise I would like to close this now. It looks pretty clear to me.
Seems to be a result of openssl BIC. No other solution here.
Subject: Re: security certificate not stored "forever" Georges, A solution for openssl BIC would be to use of opensslv.h. You told me that not all versions of openssl had this file. It seems however that the openssl autoconf detection relies on the presence of this file. In fact configure stops if this include file is not present. See KDE_CHECK_SSL in admin/acinclude.m4.in. The attached patch changes kopenssl.cc to first try the library version suggested by openssl/opensslv.h. Otherwise it reverts the the same default library names, including the hardcoded 0.9.6 library names. I know you have better plans for 3.2. But this little patch could find its way in the 3.1 branch. - L Created an attachment (id=1271) kopenssl.cc.diff
Subject: Re: security certificate not stored "forever" On March 29, 2003 17:38, Leon Bottou wrote: > Georges, > > A solution for openssl BIC would be to use of opensslv.h. > You told me that not all versions of openssl had this file. > > It seems however that the openssl autoconf detection > relies on the presence of this file. In fact configure > stops if this include file is not present. > See KDE_CHECK_SSL in admin/acinclude.m4.in. > > The attached patch changes kopenssl.cc to first try > the library version suggested by openssl/opensslv.h. > Otherwise it reverts the the same default library names, > including the hardcoded 0.9.6 library names. > > I know you have better plans for 3.2. > But this little patch could find its way in the 3.1 branch. > > - L > > Created an attachment (id=1271) > --> (http://bugs.kde.org/attachment.cgi?id=1271&action=view) > kopenssl.cc.diff Either kio(kio_http) is broken, or your attachment was empty. Please attach it privately. Thanks!
*** Bug 59324 has been marked as a duplicate of this bug. ***
I am having this problem with RedHat 9.0, KDE3.1-11, KMail 1.5. Two of my servers (one POP3, one IMAP) have been changed. The old server was "mail.spamcop.net" for both POP3 and IMAP. The new servers are POP.SPAMCOP.NET and IMAP.SPAMCOP.NET. Please see if you can reproduce this problem using RedHat 9. I upgraded from RedHat 8.0, so there's a POSSIBILITY that some of the libraries are still in use from the old version of RH. My OpenSSL versions are : openssl095a-0.9.5a-21 openssl-perl-0.9.7a-5 openssl096-0.9.6-17 openssl-0.9.7a-5 openssl-devel-0.9.7a-5 openssl096b-0.9.6b-6 Thanks...
Depends which version of the code redhat uses. Try removing 'openssl-devel-0.9.7a-5'. - L.
*** Bug 62151 has been marked as a duplicate of this bug. ***
*** Bug 65929 has been marked as a duplicate of this bug. ***
I think this problem only happens if the resolved hostname differs from the hostname listed in the certificate, for me eg the cert lists pop.gmx.net and I use pop.gmx.de as the hostname in kmail. Btw. my current OpenSSL version is 0.9.6j but it also happened with earlier versions.
*** Bug 101588 has been marked as a duplicate of this bug. ***
I am having this problem in kmail 1.9.6, kde 3.5.6, gcc-4.1.1, and open-ssl 0.9.8d. I see that it was resolved invalid why? is there a working work around?
same problem, kubuntu packages. kmail 1.9.6, kde 3.5.6, gcc 4.1.2, OpenSSL 0.9.8c 05 Sep 2006 I have to access gmail through some localhost ports provided by ssh, thanks to my ridiculous proxy situation. I tried fiddling with crypto options, it's too soon to know if that helped.
fiddling with crypto options did not help. why is this bug marked as resolved if it's still giving people trouble after all these years? judging by the big gap in comments, maybe it was fixed for a while and then broke again.
This problem still exists. I also get the following errors from kded when accessing https:// sites: kdecore (KLibLoader): WARNING: KLibrary: /usr/lib64/libcrypto.so.0.9.8: undefined symbol: PKCS7_content_free kdecore (KLibLoader): WARNING: KLibrary: /usr/lib64/libcrypto.so.0.9.8: undefined symbol: OpenSSL_add_all_algorithms kdecore (KLibLoader): WARNING: KLibrary: /usr/lib64/libcrypto.so.0.9.8: undefined symbol: OPENSSL_add_all_algorithms kdecore (KLibLoader): WARNING: KLibrary: /usr/lib64/libcrypto.so.0.9.8: undefined symbol: OpenSSL_add_all_algorithms_conf
I still have this problem in the lastest kde 4.2 beta1
Uhm I think I need to clerify. I didn't have this problem in 3.x, it only came once I moved to 4.x. The certificate in question has not been changed and is valid a few years more.
We have the same problem at work on all our machines since we upgraded to kde4.
I just found something out about Peer SSL certificates in konqueror. I had a bunch of outdated certificates, so I removed them. But when I closed konqueror and restarted it they were back. I do use gnome for the moment, but I almost exclusively use kde apps.
Should be fixed in revision 914920 (trunk) and 4.2.1. KConfig was confused by binary config group names and couldn't retrieve stored certificate rules in some cases.
Yes! Seems to be fixed on Architecture: amd64 Version: 4:4.2.0-0ubuntu1~intrepid~ppa3 Thanks!