Bug#973472: fetchmail: Fails to connect using SSL
On Wed, Nov 11, 2020 at 9:23 PM Kurt Roeckx wrote: > On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote: > > Thanks for possibly the best solution. Meanwhile OpenSSL 1.1.1h-1 > > migrated to testing; closing this bug report. > > That is not a fix. Fetchmail should not be checking the version. > > The libssl1.1 package will ensure that the correct versioned > depenencies are there. You are right, that's what soname for - define the used and compatible library dependencies. Matthias, what's your intention with the forced OpenSSL library check? Do you plan to remove that upstream or should I comment that out? Regards, Laszlo/GCS
Bug#973472: fetchmail: Fails to connect using SSL
On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote: > On Fri, Nov 6, 2020 at 9:09 AM Michal Palenik wrote: > > for those stumbling on this via searching, the workaround mentioned > > above is: > [...] > > apt -t unstable install libssl1.1:amd64 > Thanks for possibly the best solution. Meanwhile OpenSSL 1.1.1h-1 > migrated to testing; closing this bug report. That is not a fix. Fetchmail should not be checking the version. The libssl1.1 package will ensure that the correct versioned depenencies are there. There might be cases that an older version than the one you compiled against might not work, when not using Debian's dependencies system, but in that case you'll get a linker error. Kurt
Bug#973472: fetchmail: Fails to connect using SSL
On Mon, 2 Nov 2020 10:34:35 +0100 Timo van Roermund wrote: > On Sun, 01 Nov 2020 14:25:03 -0800 Bill Wohler wrote: > > > Thanks for explaining the situation. Sounds like just some bad luck. > > Even so, it would still be good if a mechanism could be created that > > would prevent this from happening in the future. > > Yes, some mechanism to prevent this would be good. I only noticed this > issue after approximately two days and therefore received some e-mails > (too) late. > > > I appreciate your sending the link to the prior package. It made it much > > easier to go back, and now my mail is flowing again.. I've also held the > > package until I see an OpenSSL update. > > I took a different approach and upgraded the openssl and libssl1.1 > packages to version 1.1.1h-1 (from unstable). I did so because I am not > affected by any of the regressions listed at the oppenssl package > tracker (https://tracker.debian.org/pkg/openssl). With this approach, I > don't need to take any further manual actions later on (to unhold the > package). for those stumbling on this via searching, the workaround mentioned above is: create priority for testing: /etc/apt/apt.conf.d/default-release with APT::Default-Release "testing"; add into sources (with your favourite mirror): deb http://ftp.debian.sk/debian/ unstable main contrib non-free apt update and reinstall apt -t unstable install libssl1.1:amd64 -- Michal Páleník
Bug#973472: fetchmail: Fails to connect using SSL
On Sun, 01 Nov 2020 14:25:03 -0800 Bill Wohler wrote: > Thanks for explaining the situation. Sounds like just some bad luck. > Even so, it would still be good if a mechanism could be created that > would prevent this from happening in the future. Yes, some mechanism to prevent this would be good. I only noticed this issue after approximately two days and therefore received some e-mails (too) late. > I appreciate your sending the link to the prior package. It made it much > easier to go back, and now my mail is flowing again.. I've also held the > package until I see an OpenSSL update. I took a different approach and upgraded the openssl and libssl1.1 packages to version 1.1.1h-1 (from unstable). I did so because I am not affected by any of the regressions listed at the oppenssl package tracker (https://tracker.debian.org/pkg/openssl). With this approach, I don't need to take any further manual actions later on (to unhold the package). > Thanks again for your Debian participation. We really appreciate it! Also a big thanks from my side -- really appreciated! The above is only meant as constructive feedback, certainly not as criticism. Cheers, Timo
Bug#973472: fetchmail: Fails to connect using SSL
Thanks for explaining the situation. Sounds like just some bad luck. Even so, it would still be good if a mechanism could be created that would prevent this from happening in the future. I appreciate your sending the link to the prior package. It made it much easier to go back, and now my mail is flowing again.. I've also held the package until I see an OpenSSL update. Thanks again for your Debian participation. We really appreciate it! László Böszörményi (GCS) wrote: > On Sun, Nov 1, 2020 at 1:06 AM Bill Wohler wrote: > > Same here. > > > > Will you be able to fix this now so that everyone using fetchmail can > > get mail without having to jump through hoops like building fetchmail or > > finding the previous package? > You can fetch the previous package version and its binaries[1] if you > would like to. You can also enable the Sid repository, upgrade _only_ > libssl1.1 from there then disable it. > I will not be able to fix this due to how the packaging system works. > When a Debian maintainer releases a new package version, s/he builds > and tests it with the Sid/unstable repository. Buildd machines do very > similar: build the package if the specified build dependencies and > those minimal versions are met. Basically after some days the package > migrates to testing / Bullseye if the following are true: the package > built on all primary architectures it supports, doesn't have a serious > bug reported against, its dependencies are in testing (or can migrate > at the same time) and the package self-tests are successful. > It was true for fetchmail but the new OpenSSL package (possibly due to > upstream change) breaks other packages and can't migrate as is. But > compiled code in fetchmail checks if the OpenSSL library is at least > that version which was used for compilation. This is not true and it > refuses to work. It will be solved by itself as soon as the OpenSSL > package is fixed - unfortunately I don't see any steps toward this. > Until then you can grab the previous fetchmail package version or > upgrade to the newer OpenSSL package in Sid (which may break other > packages using that). > > Regards, > Laszlo/GCS > [1] http://snapshot.debian.org/package/fetchmail/6.4.12-1/ > -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Bug#973472: fetchmail: Fails to connect using SSL
On Sun, Nov 1, 2020 at 1:57 PM Klaumi Klingsporn wrote: > On Sun, 1 Nov 2020 08:22:27 +0100 > =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= > wrote: > > I will not be able to fix this due to how the > > packaging system works. [...] > you're right. But it might help the next time, if you could > add a conflict to the package to all versions of libssl1.1 > smaller than the one it is compiled with. While it can help, I'm not sure if it's a good solution. > Otherwise the problem will reappear every time a new > version of fetchmail enters testing before the version of > openssl it is compiled with. This case is rare. If OpenSSL and fetchmail are uploaded at the same time, they should migrate to testing together. If OpenSSL uploaded a day or more earlier, then it should be in testing sooner than fetchmail. If it's fetchmail that is uploaded sooner, then it will be built with an earlier OpenSSL version. Such a problem only happens if OpenSSL is stuck in Sid which should not happen as it breaks all packages that compiled with that version and can migrate to testing on its own. That is, OpenSSL should be maintained properly. However it's missing manpower for one and half decades [1]. :( Cheers, Laszlo/GCS [1] https://bugs.debian.org/332498
Bug#973472: fetchmail: Fails to connect using SSL
On Sun, 1 Nov 2020 08:22:27 +0100 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > I will not be able to fix this due to how the > packaging system works. When a Debian maintainer releases > a new package version, s/he builds and tests it with the > Sid/unstable repository. ... But compiled code in > fetchmail checks if the OpenSSL library is at least that > version which was used for compilation. This is not true > and it refuses to work. It will be solved by itself as > soon as the OpenSSL package is fixed - unfortunately I > don't see any steps toward this. Dear Lazlo, you're right. But it might help the next time, if you could add a conflict to the package to all versions of libssl1.1 smaller than the one it is compiled with. Otherwise the problem will reappear every time a new version of fetchmail enters testing before the version of openssl it is compiled with. Thanks for maintaining the package! Klaumi --- Klaus-Michael Klingsporn mail: klaumi...@gmx.de web: www.klaumikli.de
Bug#973472: fetchmail: Fails to connect using SSL
On Sun, Nov 1, 2020 at 1:06 AM Bill Wohler wrote: > Same here. > > Will you be able to fix this now so that everyone using fetchmail can > get mail without having to jump through hoops like building fetchmail or > finding the previous package? You can fetch the previous package version and its binaries[1] if you would like to. You can also enable the Sid repository, upgrade _only_ libssl1.1 from there then disable it. I will not be able to fix this due to how the packaging system works. When a Debian maintainer releases a new package version, s/he builds and tests it with the Sid/unstable repository. Buildd machines do very similar: build the package if the specified build dependencies and those minimal versions are met. Basically after some days the package migrates to testing / Bullseye if the following are true: the package built on all primary architectures it supports, doesn't have a serious bug reported against, its dependencies are in testing (or can migrate at the same time) and the package self-tests are successful. It was true for fetchmail but the new OpenSSL package (possibly due to upstream change) breaks other packages and can't migrate as is. But compiled code in fetchmail checks if the OpenSSL library is at least that version which was used for compilation. This is not true and it refuses to work. It will be solved by itself as soon as the OpenSSL package is fixed - unfortunately I don't see any steps toward this. Until then you can grab the previous fetchmail package version or upgrade to the newer OpenSSL package in Sid (which may break other packages using that). Regards, Laszlo/GCS [1] http://snapshot.debian.org/package/fetchmail/6.4.12-1/
Bug#973472: fetchmail: Fails to connect using SSL
Same here. Will you be able to fix this now so that everyone using fetchmail can get mail without having to jump through hoops like building fetchmail or finding the previous package? -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Bug#973472: fetchmail: Fails to connect using SSL
On Sat, 31 Oct 2020 19:50:09 +0100 Klaumi Klingsporn wrote: > I think it's because the new version of fetrchmail is > compiled against openssl in sid, which is blocked there > because of regressions. As I thought: I rebuilt the fetchmail 6.4.13-1 package in testing against the openssl-libraries in testing and voilá all works fine again! As a workaround you can find my fetchmail-package 6.4.13-1~kmk1 at apt.klaumikli.de/testing Dear maintainer, it would be nice, if you updated the package in unstable to version 6.4.13-2 and changed the dependencies for libssl1.1 to '(=1.1.1h)'. Fetchmail seems to worry about the libraries it is compiled against. Have a nice day again! Klaumi --- Klaus-Michael Klingsporn mail: klaumi...@gmx.de web: www.klaumikli.de
Bug#973472: fetchmail: Fails to connect using SSL
On Sat, 31 Oct 2020 09:39:46 +0100 Alex Bernier wrote: > Package: fetchmail > Version: 6.4.13-1 > Severity: important > > Connections using SSL fails with the following error > message : > > fetchmail: Loaded OpenSSL library 0x1010107f older than > headers 0x1010108f, refusing to work. Same here! Since todays upgrade in testing fetchmail doesn't work any more: "fetchmail: Loaded OpenSSL library 0x1010107f older than headers 0x1010108f, refusing to work." I think it's because the new version of fetrchmail is compiled against openssl in sid, which is blocked there because of regressions. This should not happen! Most people will only recognize it after hours or even days! klaumi --- Klaus-Michael Klingsporn mail: klaumi...@gmx.de web: www.klaumikli.de
Bug#973472: fetchmail: Fails to connect using SSL
Package: fetchmail Version: 6.4.13-1 Severity: important Dear Maintainer, Connections using SSL fails with the following error message : fetchmail: Loaded OpenSSL library 0x1010107f older than headers 0x1010108f, refusing to work. fetchmail: xxx.domain.com: SSL connection failed. fetchmail: socket error while fetching from y...@xxx.domain.com fetchmail: Query status=2 (SOCKET) It does not seesm that OpenSSL has been renctly updates on my system. Best wishes, Alex Bernier *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetchmail depends on: ii adduser 3.118 ii debianutils 4.11.2 ii libc6 2.31-4 ii libcom-err2 1.45.6-1 ii libgssapi-krb5-2 1.17-10 ii libkrb5-3 1.17-10 ii libssl1.1 1.1.1g-1 ii lsb-base 11.1.0 Versions of packages fetchmail recommends: ii ca-certificates 20200601 Versions of packages fetchmail suggests: ii exim4-daemon-light [mail-transport-agent] 4.94-8 pn fetchmailconf pn resolvconf -- no debconf information
