Bug#1076604: fetchmail: “configuration invalid, you normally need --ssl for port 995” ← probably incorrect msg
Control: tags -1 upstream confirmed fixed-upstream Control: severity -1wishlist Am 19.07.24 um 15:30 schrieb Manny: Package: fetchmail Version: 6.4.37-1 Severity: minor Tags: upstream X-Debbugs-Cc: debbug.fetchm...@sideload.33mail.com This warning: fetchmail: WARNING: pop.yandex.com configuration invalid, you normally need --ssl for port 995/service pop3s. is triggered by this configuration stanza: poll pop.yandex.com no dns plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050" protocol pop3 port 995 username manny sslproto 'SSL3+' sslcertck sslfingerprint "94:6A:CF:B1:A7:BE:30:11:B5:E0:B1:F9:0C:3B:37:B7" fetchall The 'SSL3+' is not accidental or arbitrary. It is there after a struggle with the normal parameters (“ssl”) and experimentation found SSL3+ was necessary in order to establish a connection. I stopped using Yandex when they started blocking Tor years ago, so it’s unclear whether “SSL3+” still needed. But that’s irrelevant anyway. Thanks for the report. The thing is fetchmail cannot assess what plugin you have, such for the use with "plugin" - but you can probably omit the "port" line or change it to "port 110". I'll see (as upstream maintainer) if I can quench the warning and related ones with plugin in use. Fixed upstream in Git commit 98a71f86, repos on gitlab.com/fetchmail/fetchmail and sf.net/projects/fetchmail branch legacy_6x.
Bug#1036030: asciidoc-base: asciidoc fails to find icons for embedding; iconsdir apparently mismatching asciidoc-common layout
I think not fixing this in the package as a regular fix (it's a patch after all) is ill-advised, but for those who find this bug unfixed in their installation: The workaround is to install asciidoc through pip install --user asciidoc instead, or possibly with pipx. Example in line #6 of my test build script here: https://gitlab.com/fetchmail/fetchmail/-/commit/bf6c7b1eb8d476eb8c71419096e5f5470d205dfb#c5cb59670c749d48bf0114e280b297d49e50f3ac_0_6
Bug#1036030: asciidoc-base: asciidoc fails to find icons for embedding; iconsdir apparently mismatching asciidoc-common layout
Package: asciidoc-base
Version: 10.2.0-1
Severity: important
Dear Maintainer,
as a maintainer of the fetchmail upstream package,
I want to build documentation with asciidoc.
As part of fetchmail's build with meson on the legacy_6x branch of
fetchmail, asciidoc is being run, but cannot find icons:
[68/70] Generating Mailbox-Names-UTF7.html with a custom command
sh: 1: cannot open /etc/asciidoc/icons/warning.png: No such file
asciidoc: WARNING: Mailbox-Names-UTF7.txt: line 157: {sys:"/usr/bin/python3" -u
-c "import base64,sys; base64.encode(sys.stdin.buffer,sys.stdout.buffer)" <
"/etc/asciidoc/icons/warning.png"}: non-zero exit status
[70/70] Generating fetchmail-man.html with a custom command (wrapped by meson
to capture output)
dpkg -L asciidoc-common suggests that asciidoc-base should either refer to
/usr/share/asciidoc/icons, or maintain proper links directly or through the
alternatives mechanism.
Minimal reproducer:
apt install --no-install-recommends -y asciidoc
cat >test.adoc <<'_EOF'
:icons:
WARNING: test text,
more test text
_EOF
/usr/bin/asciidoc --attribute=data-uri -o test.html test.adoc
Yields:
# /usr/bin/asciidoc --attribute=data-uri -o test.html test.adoc
sh: 1: cannot open /etc/asciidoc/icons/warning.png: No such file
asciidoc: WARNING: test.adoc: line 3: {sys:"/usr/bin/python3" -u -c "import
base64,sys; base64.encode(sys.stdin.buffer,sys.stdout.buffer)" <
"/etc/asciidoc/icons/warning.png"}: non-zero exit status
Note this is in a podman-based container setup of debian:testing per:
REPOSITORY TAG IMAGE ID CREATED
SIZE
docker.io/library/debian testing 4601c669d9dc 10 days ago
121 MB
-- System Information:
Debian Release: 12.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.2.14-300.fc38.x86_64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages asciidoc-base depends on:
ii asciidoc-common 10.2.0-1
ii docbook-xsl 1.79.2+dfsg-2
ii libxml2-utils2.9.14+dfsg-1.2
ii python3 3.11.2-1+b1
ii xsltproc 1.1.35-1
Versions of packages asciidoc-base recommends:
pn xmlto
Versions of packages asciidoc-base suggests:
pn asciidoc-doc
pn docbook-utils
pn source-highlight
-- no debconf information
Bug#1025252: fetchmail: man page for fetchmailrc misses arg after fastuidl
Francesco, none of the options in that nroff table "user descriptions and options" mentions arguments to any options, with the exception of sslfingerprint that gets it wrong - its intention (as inherited from Eric Raymond) seems to just list the long and their short equivalents, but the redudancy is also a maintenance burden. What I figured when looking for what you meant is that the --help output also lacks the argument... --fastuidl do a binary search for UIDLs So that warrants fixing. And another round of translations... :-o Cheers, Matthias
Bug#1025252: (no subject)
https://gitlab.com/fetchmail/fetchmail/-/issues/56
Bug#1000110: leafnode: depends on obsolete pcre3 library
Control: tags -1 +upstream +fixed-upstream +confirmed Control: fixed -1 1.12.0 Please note that I have very recently released leafnode 1.12.0 which now uses PCRE2 instead of PCRE1. Also note that there is no longer a .bz2 package, only .xz and .gz. https://sourceforge.net/projects/leafnode/files/leafnode/1.12.0/ Changelog (high-level, edited): https://gitlab.com/leafnode-2/leafnode-1/-/raw/1.12.0/NEWS Changelog (low-level, semiautomated): https://gitlab.com/leafnode-2/leafnode-1/-/raw/1.12.0/ChangeLog
Bug#986130: ,fetchmailconf: No update/upgrade possible due to error
Does this warrant "grave"? This looks like trying to configure fetchmailconf before fetchmail is configured, and before fetchmail saw configuration. However why is fetchmail being "restart"ed? It could not have been running before...
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 17:11 schrieb Karsten: Basically you can install the self-signed certificate (if you or a trusted party signed it, and you have transmitted it over a secure channel, for instance, via SFTP or SCP) into the trust store (assuming it suits both the TLS server and the signing CA roles - which was set when you created it). Just for understanding - the installation is the public certificate of the server, or must be a special file derived from the private certificate? "It depends" - on how you exactly you generated it - even if you only created it with "openssl req -x509 ...", the openssl configuration files matter. Normally, 1. the client's trust store (OpenSSL on the fetchmail computer) needs the CA certificate, i. e. one with the CA flag set to true in the basicConstraints, or basicContraints missing, see the x509(1ssl) manual page under CERTIFICATE EXTENSIONS. 2. Then, the server needs to present a certificate that is suitable as "SSL Server" (extendedKeyUsage = serverAuth) role. See the x509v3_config(5ssl) manual page for details. If your server's certificate does not fulfill both criteria, you better start over and set up a ca (and store its private key password-protected in a safe place, as you seldomly need it), and a separate server cert signed by your own ca. easy-rsa may help with that. Check /usr/share/doc/easy-rsa, easy-rsa has README files, but no manual page. To check: openssl x509 -noout -text -in whatever.crt # or whatever.pem shows you that, here for a CA certificate: X509v3 Basic Constraints: CA:TRUE ... X509v3 Key Usage: Certificate Sign, CRL Sign The TLS server has X509v3 Basic Constraints: CA:FALSE ... X509v3 Extended Key Usage: TLS Web Server Authentication Some of this may not be enforced in currently shipping fetchmail versions, but since a lot of public foot-shooting was involved in third-party documentation that advised trust-on-first-use schemes without warning people of the dangers involved, future versions might actually tighten things even more, so, f.i. validate CA flags of all but the server certificate. I don't currently use Debian or derivatives as so you need to check [update-]ca-certificates documentation and configuration to be sure that your certificate is (a) put in the right place where update-ca-certificate finds it, (b) "enabled" in configuration and processed into the output trust store, and (c) not in a place where it will be removed on system upgrades. dpkg-reconfigure ca-certificates - possibly with some modified priority option - might be required. That stackexchange link in the earlier message hints that there were changes somewhen in the past, and also be sure to re-check documentation since the answer there is older than Debian 11. No, where does that access happen? The trust store is local to your computer and fetchmail might use your system's DNS resolver (which can have privacy implications) and will connect to the servers you point it to. First you send your certificate to the public CA to sign it. Then an client must connect the CA to proove that the public certificate is correct signed. Correct or wrong? If I am my own CA, I am not sending something anywhere. I install the ca certificate on my clients' trust stores, put its (the CA) private keys on a CD or USB key so it's not left on my computer (let alone on my server), and that's it. I've been doing that for more than a dozen years; for public services however Let's Encrypt is a viable alternative.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 14:03 schrieb Karsten: Am 02.01.22 um 12:15 schrieb Matthias Andree: I am the owner of the domain so nobody is hijacked! Are you the owner of "mydomain.de" or of the unnamed domain you intended not to show to the public? Do you want to help with this new certificate issue or discuss the ownership of domains? In this case, the latter. There are dedicated domain names for everyone to use for documentation and test purposes, https://datatracker.ietf.org/doc/html/rfc6761#section-6.5 With the search "install OpenSSL trust store" i could find this article: https://support.code42.com/CP/Admin/On-premises/6/Configuring/Use_OpenSSL_to_install_a_keystore that explains much of the stuff, but not how to use an self-signed certificate. https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list/ but check the fine print and lower rated comments, too -- for recent ca-certificates packages. Basically you can install the self-signed certificate (if you or a trusted party signed it, and you have transmitted it over a secure channel, for instance, via SFTP or SCP) into the trust store (assuming it suits both the TLS server and the signing CA roles - which was set when you created it). This worked for more then 5 years with TLS1.2 without any problem. Why this must be a problem now? Because "working" does not imply "working safely and securely". Take the example Mozilla and please explain why it works without an "OpenSSL trust store" ? Mozilla applications ship with their own trust store and do not use OpenSSL, but incorporate their own TLS library called NSS. Untrue. Mozilla's certificates are installed for offline use by Debian, Fedora, FreeBSD and derived distros under names such as ca-certificates, ca_root_nss or similar. AFAICS and up to and including OpenSSL 3.0.0, OpenSSL does not perform Online Certificate Status Protocol (OCSP) polls, so no calling home involved to date. O.K. Then you have no request to this CA-servers for every connect to a server with a certificate, but every private server is registered there and every client will request the "trust" once to access the server. So you can made a profil who is using a server. That's the simple goal of it. No, where does that access happen? The trust store is local to your computer and fetchmail might use your system's DNS resolver (which can have privacy implications) and will connect to the servers you point it to. Thanks - but now i still have no idea where to search for the trust store of fetschmail? It uses OpenSSL's unless you override that (see man fetchmail for --ssl... options). Why it is not possible to give the needed commands like before, like openssl req -x509 -newkey rsa:4096 -keyout /etc/exim4/exim.key.pem -out /etc/exim4/exim.cert.pem -days 365 -nodes ? The reason is the lack of understanding what has changed and what must be done and not to bother you. I understand, but too many variables involved and neither of us has time for guesswork. I don't know how your CA (even if only implied for that certificate) is set up or whatever else is needed, and I don't intend to do consulting. Figuratively speaking, you need to learn how to fish, not be given the fish. When this is a standard procedure, why it is not possible to find existing examples how to handle it? Why it is still possible to fetch Data with TLS1.2 from the FTP-Server without similar problems? fetchmail doesn't do FTP, and FTP is being phased out because it's hard to get right with its two connections, active/passive mode, firewalls/NAT/conntrack, TLS being added afterwards and I guess it was superseded by many other protocols that either tunnel through SSH or use one TLS connection, for instance, DAV. It is probably not about TLS version numbers anyways, but generally tightened security. You upgraded the entire client system, and that brought a lot of changes. https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1 might also be involved.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 14:24 schrieb Karsten: Am 02.01.22 um 12:28 schrieb Matthias Andree: But it would be helpful for others what must be done to create and install this new "client side certificate" that appears about 2018? I think the certificate issue was there right from the beginning. Definitely no. Mails where fetched for about 5 years without any problem. Untrue. Messages were fetched without proper protection from MITM/eavesdropping attacks, unless you were using *other* options to ensure authenticity of the server. Which I doubt, else you would have asked specific questions about fetchmail options. That's true - but you change the privacy with an voluntary registration at an CA-authority. I don't see anyone suggested that, but tell me how... The people that can make MITM/eavesdropping attacks can fake an CA-authority too. ...that CA certificate would make it into your trust store. There used to be ill-advised instructions by fourth parties that gave the wrong advise to download and storing the server's certificate into the trust store. If the faked CA authority certificate is not in your trust store, certificate validation will flag the missing trust anchor or issue "self-signed certificate" errors. In practice, Linux and BSD distros usually deploy the CAs from Mozilla's CA Program https://blog.mozilla.org/security/category/ca-program/ and Mozilla have banned CAs that were abusive. Do you think it is possible to make thousands of MITM/eavesdropping attacks parallel for every private server? You can safely bet it happens at scale, and million-fold each and every day. The question is who will make the faked CA authority trustworthy? Company networks with malware-scanning outside proxies, free WiFi sites, you name it. You don't verify, you don't know. Can you please recommend *other* options to ensure more security with self signed certificates? See my previous messages, put the CA certificate (not private key) that signed your server's certificate into the OpenSSL trust store of the computer running fetchmail, or into a local place that you point fetchmail to. That won't work without reading documentation on how certification chains and trust delegation work. In the Debian world, things revolve around update-ca-certificates from the ca-certificates package. I'm caring about safety and privacy, that's the reason encryption with private certificates are used. Nonsense. That's the reason why fetchmail 6.4.0 finally broke compatibility with broken sites and finally (far too late) enforces proper X.509 certificate chains to so-called trust anchors. Can you explain this a little bit more please? Using encryption with an self-signed certificate cannot be more nonsense then to use no encryption at all. This makes no sense for me from a logic point. That's not what I wrote, but the logic you refer to is why fetchmail 6.4 - finally - forbids unverified certificates by default. Meaning: No more connection to sites with incomplete certification chains or where the certification chain cannot be anchored to a trusted CA. Why have older fetchmail versions made proper trust verification optional? :-) 6.3 appeared in 2005, before E. Snowden hat blown the whistle and before web browsers started to flag sites with unverified certification chains as insecure - and 6.3.X has kept compatibility and defaults. Before this turns into more gossip, I propose to close the bug report now. Do that by replying to 1002910-cl...@bugs.debian.org instead of the 1002910@ address.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 11:54 schrieb Karsten: Am 01.01.22 um 17:53 schrieb László Böszörményi (GCS): On Sat, Jan 1, 2022 at 2:30 PM Karsten wrote: But it would be helpful for others what must be done to create and install this new "client side certificate" that appears about 2018? I think the certificate issue was there right from the beginning. Definitely no. Mails where fetched for about 5 years without any problem. Untrue. Messages were fetched without proper protection from MITM/eavesdropping attacks, unless you were using *other* options to ensure authenticity of the server. Which I doubt, else you would have asked specific questions about fetchmail options. I'm caring about safety and privacy, that's the reason encryption with private certificates are used. Nonsense. That's the reason why fetchmail 6.4.0 finally broke compatibility with broken sites and finally (far too late) enforces proper X.509 certificate chains to so-called trust anchors. In this case the original private certificate from the server is needed? Why a client must have additional files now to access an server No. That's the wrong question to ask. Do not ask "why they are needed now", but "why have older fetchmail versions made proper trust verification optional" for so many years. And another question to ask is "why do users ignore manuals and NEWS files of the applications they use" And a third one, to third parties and outside of this bug's context "how do we get proper yet concise certificate trust management documentation in prominent places?". One half is really OpenSSL basic usage and how to maintain its trust store, and one half is, sorry to be so blunt, a half-baked approach at trying to be your own CA without knowing what you are doing. Fetchmail's expectation is that the server-presented single self-signed certificate, or normally certificate chain, traces back to a root signing certificate that is "trusted" and is installed in your local computer's OpenSSL trust store (the one running fetchmail), and trusted in a way that it properly verifies the sub-CAs it authenticates with respect to the policies and practices they implement. But this is all OpenSSL trust handling and, again, not specific to fetchmail.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 01.01.22 um 14:26 schrieb Karsten: Hello Matthias, Am 01.01.22 um 14:10 schrieb Matthias Andree: Notice something? i notice everything. :-) You hijack somebody else's domain for "anonymization" purposes and expect someone to help you, and you did not respond to hints the server CA's signing certificate might be missing from the trust store. I am the owner of the domain so nobody is hijacked! Are you the owner of "mydomain.de" or of the unnamed domain you intended not to show to the public? A self signing certificate is absolutely sufficient and perfect for private use. Then install your own CA or (if marked as CA-suitable) issuer certificate it into your fetchmail client's OpenSSL trust store, or a separate location, and move on. The same TLS1.2 as before shall be used, so it is not understandable why addtional things are mandantory now? Why old certificates cannot be used any more when the client that uses a server is upgraded? It is not about certificates, but - as László pointed out - about repairing fetchmail's security requirements from substandard to "Stand der Technik". fetchmail 6.4.0 made --sslcertck the default, as various places of the documentation (man page, NEWS file) point out. The standard use case for fetchmail is to fetch mail from "big sites" and those can be expected to handle proper certification chains. Your use case is "run my own TLS server"; in that case fetchmail can safely assume people are aware what they are doing and how to handle trust. In the Internet are a mass of similar problems with fetchmail, but no description what exactly must be done to solve it. Because "similar problems" are usually a broken setup of either server-side certificates that don't trace back to commonly used and trusted stores (Mozilla's trusted CA package, mostly), or local broken setups. This "stores" are a big problem of public monitoring, because every certificate causes requests to this central "stores". Untrue. Mozilla's certificates are installed for offline use by Debian, Fedora, FreeBSD and derived distros under names such as ca-certificates, ca_root_nss or similar. AFAICS and up to and including OpenSSL 3.0.0, OpenSSL does not perform Online Certificate Status Protocol (OCSP) polls, so no calling home involved to date. https://manpages.debian.org/buster/ca-certificates/update-ca-certificates.8.en.html might be a starting point. But it would be helpful for others what must be done to create and install this new "client side certificate" that appears about 2018? That's standard TLS library procedure and not specific to fetchmail. The only specific part is that fetchmail uses OpenSSL, so your self-signing server certificate belongs into OpenSSL's trust store, or you can use one or both of the --sslcert* options to fetchmail.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Happy new year Karsten. Am 01.01.22 um 13:53 schrieb Karsten: Hello Matthias, Am 31.12.21 um 20:05 schrieb Matthias Andree: What must be done to get it working again? This question has not been answered. [...] The security relevant logdata is of course anonymized or altered. Notice something? . . . You hijack somebody else's domain for "anonymization" purposes and expect someone to help you, and you did not respond to hints the server CA's signing certificate might be missing from the trust store. Checking with another computer that has a proper installation is impossible if you fake data. Be sure to install and configure the ca-certificates package - in case you had installed fetchmail with --no-install-recommends. In the Internet are a mass of similar problems with fetchmail, but no description what exactly must be done to solve it. Because "similar problems" are usually a broken setup of either server-side certificates that don't trace back to commonly used and trusted stores (Mozilla's trusted CA package, mostly), or local broken setups. HTH - else you need to provide original data and more information. Regards, Matthias
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 31.12.21 um 16:32 schrieb Karsten: Package: fetchmail Version: 6.4.16-4+deb11u1 Severity: important I upgraded the server from Debian 9 to 11 and afterwards it seems not possible to get fetchmail to work. I tried every possible option of ssl and sslproto, but fetchmail can't fetch the mails. The log says: fetchmail: Trying to connect to 185.11.xxx.xxx/993...connected. fetchmail: Server certificate: fetchmail: Issuer Organization: mydomain fetchmail: Issuer CommonName: mydomain.de fetchmail: Subject CommonName: mydomain.de fetchmail: mydomain.de key fingerprint: 7C:CA:43:33:2A:12:B6:8D:83:3C:6E:88:0F:40:4B:6F fetchmail: Server certificate verification error: self signed certificate fetchmail: Missing trust anchor certificate: /C=DE/ST=germany/L=here/O=mydomain/OU=Privacy/CN=mydomain.de/emailAddress=webmas...@mydomain.de fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. See README.SSL for details. fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed fetchmail: mydomain.de: SSL connection failed. It is possible to work with Tunderbird (Debian11) direct with the mailserver (Dovecot on Debian 8), but not to download the emails with fetchmail. What must be done to get it working again? Unless you own "mydomain.de" you've now hit innocent bystanders, and in that case, making up log data with a domain you do not own is not helpful. If Thunderbird can fetch, either it has a local trust setting, or you've missed installing the ca-certificates package, or, as László suggested, the certificate is self-signed and you have not installed the signing CA's certificate in the trust store.
Bug#981464: systemctl --user start fetchmail.service
Am 24.11.21 um 18:56 schrieb László Böszörményi (GCS): It would be best if upstream integrates it to the source code. Even if 6.4.25 is just around the corner. After some discussion behind the scenes, added to contrib/systemd/ as of 6.4.25.rc2, without installation support. It should be easy enough for a distribution to add two post-install lines for contrib/systemd/README.systemd to the docs dir and the unit file to /usr/lib/systemd/user/.
Bug#993163: fetchmail: CVE-2021-39272
Just a word of warning, this isn't your pick three git commits with trivial fixes - the backport will require proper testing, too, and it will require some of the 42 patches since fetchmail 6.4.21 that are NOT marked SECURITY - for instance, 74771392 and 616e8c70, and translation updates as they are now trickling in, and documentation updates that suggest limiting TLS to TLS1.2+, so anything that looks like SSL or TLS documentation update. Feel free to ask simple "do I need commit c0decafe to fix this CVE" questions on the fetchmail-devel@ list for the benefit of other distributors backporting. Note that there was a lot of drive-by bugfixing that also warrants updating independent of the CVE.
Bug#992400: fetchmail: segfault with specific .fetchmailrc
On Wed, 18 Aug 2021 19:20:01 +0200 Matthias Andree wrote: > The attached patch should fix the crash. envelope is special in that it > can take the value STRING_DISABLED == (char *)-1 for "no envelope", and > the optmerge() function did not take this into account and tried to > strdup(-1). Minor detail, this happens in strlen(-1). This is a regression that happened in 6.4.3 release (or 6.4.3-beta1, to be precise) and affects all 6.4.x versions up to and including 6.4.21.
Bug#992400: fetchmail: segfault with specific .fetchmailrc
The attached patch should fix the crash. envelope is special in that it
can take the value STRING_DISABLED == (char *)-1 for "no envelope", and
the optmerge() function did not take this into account and tried to
strdup(-1).
This will likely become part of a future 6.4.22 and 6.5.0 release.
diff --git a/fetchmail.c b/fetchmail.c
index ac8e4607..71ecc1b0 100644
--- a/fetchmail.c
+++ b/fetchmail.c
@@ -996,7 +996,7 @@ static void optmerge(struct query *h2, struct query *h1, int force)
list_merge(>antispam, >antispam, force);
#define FLAG_MERGE(fld) do { if (force ? !!h1->fld : !h2->fld) h2->fld = h1->fld; } while (0)
-#define STRING_MERGE(fld) do { if (force ? !!h1->fld : !h2->fld) { if (h2->fld) free((void *)h2->fld), h2->fld = 0; if (h1->fld) h2->fld = xstrdup(h1->fld); } } while (0)
+#define STRING_MERGE(fld) do { if (force ? !!h1->fld : !h2->fld) { if (h2->fld) free((void *)h2->fld), h2->fld = 0; if (h1->fld) { if (h1->fld != STRING_DISABLED) h2->fld = xstrdup(h1->fld); else h2->fld = STRING_DISABLED; } } } while (0)
STRING_MERGE(server.via);
FLAG_MERGE(server.protocol);
STRING_MERGE(server.service);
Bug#925282: fetchmail: the message [This account is currently not available] is ambigious
Am 22.03.19 um 12:55 schrieb Graeme Vetterlein: > Package: fetchmail > Version: 6.3.26-3 > Severity: minor > Tags: patch > > Dear Maintainer, > > > I've just hit an "issue" WRT fetchmail, which I now relaise I hit about 10 > years ago and didn't report > (shame on me) the "fix" is a simple text edit so I hope you'll consider it. > > I was getting the message: > > reading message b...@mail..net:1 of 26 (16491 octets) #<...many > stars elided...>*This account is currently not available. > > The way I was invoking it (as part of debugging, originally a cronjob[mail]) > > >> sudo -u mail /usr/bin/fetchmail -f fetchmail-testrc -v -d0 > Where fetchmail-testrc, said: > > poll mail.XXX.net tracepolls with protocol POP3 user box1 password > options fetchall mda "/usr/bin/maildrop /etc/maildroprc.manual" > > Where /etc/maildroprc.manual had a complex config which split the mail into > multiple users and invoked sendmail. > > So the code we have running is: >fetchmail >maildrop >sendmail (exim4) > > All these have suid/sgid. > > The users involved are: > mail > Debian-exim > fetchmail > courier > > > So I'm getting a message "This account is currently not available" . It might > be > coming from any of the above programs, the user might be any of the above > users. > I've just spent another 2 days working on this (presumably longer 10 years > ago) > before resolving it using "diff(1)" of my old system. > > But the error was: > > passwd> mail:x:8:8:mail:/var/mail:/usr/sbin/nologin > > The fix was: > > # usermod -s /bin/bash mail > > So, my proposal :-) This would have been vastly quicker to find and fix had > the message read: > > Instead of: > "This account is currently not available" > > The text: > "fetchmail: The account "mail" is currently not available" > > or better (if it's true) > "fetchmail: The account "mail" does not have a valid shell (e.g. > bash)" > > (my guess is you don't directly issue this message) Graeme, The guess is correct, this is not fetchmail speaking, "This account is currently not available" is /usr/sbin/nologin. My maildrop binary does not contain this text either if I grep the binary or the output of "strings /usr/bin/maildrop". I can reproduce a similar situation (by using /usr/sbin/nologin for the MDA), but my log then also contains "fetchmail: MDA returned nonzero status 1", however IF something in your /etc/maildroprc.manual causes the exit status to be lost, then that may go missing. I have not used Exim for more than ten years now and if your mailfilter is complex... I don't know how those pieces interact, and maildrop also has multiple modes of operation (delivery and standard modes and whatnot). Graeme, can you debug this a bit more and see what really triggers the issue and reassign this bug to the right software? Or should we just close this bug? Thanks in advance. Best regards, Matthias
Bug#986130: fetchmailconf: No update/upgrade possible due to error
Am 30.03.21 um 09:04 schrieb dk8kk:
> Package: fetchmailconf
> Version: 6.4.0~beta4-3+deb10u1
> Severity: grave
> Tags: a11y
> Justification: renders package unusable
>
> Dear Maintainer,
>
> apt-get update/apt-get upgrade suggests these package for upgrade:
> - fetchmail (6.4.0~beta4-3+deb10u1)
> - fetchmailconf (6.4.0~beta4-3+deb10u1)
>
> Installation/Configurations fails afterwards because of the
> following error:
>
> fetchmail (6.4.0~beta4-3+deb10u1) wird eingerichtet ...
> Job for fetchmail.service failed because the control process exited with
> error code.
> See "systemctl status fetchmail.service" and "journalctl -xe" for details.
> invoke-rc.d: initscript fetchmail, action "restart" failed.
> ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
>Loaded: loaded (/etc/init.d/fetchmail; generated)
>Active: failed (Result: exit-code) since Tue 2021-03-30 08:59:33 CEST; 4ms
> ago
> Docs: man:systemd-sysv-generator(8)
> Process: 3556 ExecStart=/etc/init.d/fetchmail start (code=exited,
> status=1/FAILURE)
As external/upstream maintainer I cannot comment on this part.
> Mär 30 08:59:33 regulus.fritz.box systemd[1]: Starting LSB: init-Script for
> system wide fetchmail daemon...
> Mär 30 08:59:33 regulus.fritz.box fetchmail[3556]: Starting mail retriever
> agent: fetchmailfetchmail: es wurden keine Mailserver spezifiziert.
This means "no mail servers configured", i. e. virgin installation.
> Mär 30 08:59:33 regulus.fritz.box fetchmail[3556]: failed!
> Mär 30 08:59:33 regulus.fritz.box systemd[1]: fetchmail.service: Control
> process exited, code=exited, status=1/FAILURE
> Mär 30 08:59:33 regulus.fritz.box systemd[1]: fetchmail.service: Failed with
> result 'exit-code'.
> Mär 30 08:59:33 regulus.fritz.box systemd[1]: Failed to start LSB:
> init-Script for system wide fetchmail daemon.
> dpkg: Fehler beim Bearbeiten des Paketes fetchmail (--configure):
> »installiertes fetchmail-Skript des Paketes post-installation«-Unterprozess
> gab den Fehlerwert 1 zurück
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von fetchmailconf:
> fetchmailconf hängt ab von fetchmail (>= 6.4.0~beta4-3+deb10u1); aber:
> Paket fetchmail ist noch nicht konfiguriert.
This means fetchmailconf can't be configured while fetchmail is pending
configuration.
> dpkg: Fehler beim Bearbeiten des Paketes fetchmailconf (--configure):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> Fehler traten auf beim Bearbeiten von:
> fetchmail
> fetchmailconf
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
>
>
> Trying to configure fetchmailconf manually fails too:
>
> root@regulus:/etc# fetchmailconf --configure
> Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/fetchmailconf.py", line 2081, in
>
> "version"])
> File "/usr/lib/python2.7/getopt.py", line 88, in getopt
> opts, args = do_longs(opts, args[0][2:], longopts, args[1:])
> File "/usr/lib/python2.7/getopt.py", line 152, in do_longs
> has_arg, opt = long_has_args(opt, longopts)
> File "/usr/lib/python2.7/getopt.py", line 169, in long_has_args
> raise GetoptError('option --%s not recognized' % opt, opt)
> getopt.GetoptError: option --configure not recognized
To the submitter: That is expected and cannot possibly work.
If you were to manually try to configure fetchmailconf, you'd have to
run: dpkg --configure fetchmailconf.
fetchmailconf is a Python-Tk-(Tkinter)-based graphical configuration
utility.
Bug#984960: fetchmail: DEP8 tests for fetchmail
Control: tags -1 +fixed-upstream Integrated upstream into the legacy_6x branch for a future 6.5 release. https://gitlab.com/fetchmail/fetchmail/-/commit/1b374b5f85147e1714b2499184002b1dc86b8258
Bug#980766: Acknowledgement (fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010101f, trying to continue.)
+ László Am 22.01.21 um 21:46 schrieb Erich Wälde: > Hello, > > I found the problem: > > The fetchmail config said "tls1" instead of "tls1+", and > apparently the email hoster enforces tls1.2 now. > Which is good. > > So this bug may be closed. > Sorry for the noise. > > Erich > Erich, Glad you've got that sorted, however this looks like an instance of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928916 which was apparently only fixed in 6.4.0~rc1-1. This patch fixed the issue at the time: https://gitlab.com/fetchmail/fetchmail/blob/080d4632298636a9a1b21c3419c059b95fb3cd37/socket.c#L1225 and it added some code to trap the error and print Server shut down connection prematurely during SSL_connect(). gcs@ please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928916#43 and #53. Regards, Matthias
Bug#961412: fetchmail: restart silently fails, then start doesn't help
Hi Leszek, Unfortunately, this has two issues: 1. part of it is in Polish, a language I cannot understand, 2. apparently the debug-run masks the bug. Please 2a. try creating a logfile, 2b. then configure fetchmail to log to the logfile (and not to syslog) 2c. run fetchmail, restart, whatever you need to do to reproduce the problem; 2d. post the log, and for the past few lines, translate them to English please. Doesn't have to be exact. That may help find the issue. If in the future, fetchmail 6.4.13 appears in backports (gcs@ suggested he might want to do that, but it's not yet ready), it is worth trying to see if the issue goes away, there were both lock file (pid file) fixes as well as logging fixes when logging to syslog in daemon mode. Regards, Matthias
Bug#524758: (no subject)
Control: tags -1 + patch With a patch available from Git, I am tagging this accordingly.
Bug#837877: (no subject)
Control: tags -1 moreinfo Is this still relevant?
Bug#961412: fetchmail: restart silently fails, then start doesn't help
Control: tags -1 + moreinfo fetchmail 6.4.13 contains some additional PID handling fixes, but it's unclear whether those fixes address the issue described here. The logs provided are insufficient. Please provide logs with full debug trace.
Bug#800422: fetchmail doesn't seem to be able to write /var/tmp/messages als log
Please provide logs, such as the debug run from the rcscript
Bug#775255: fetchmail: Fails to start when libssl has SSLv3 disabled
Control: tags -1 + moreinfo Is this still an issue with any of the 6.4 versions, including betas? I believe that all 6.4.X should be fine.
Bug#961412: fetchmail: restart silently fails, then start doesn't help
README.Debian mentions: /etc/init.d/fetchmail debug-run what does this get you?
Bug#733622: bogofilter: Crash on several emails with realloc(): invalid next size
https://sourceforge.net/p/bogofilter/bugs/116/#52a0 i. e. this was fixed 91 commits before bogofilter-1.2.5.rc1. I don't know if the commit (Git cd33fc00802a75fe7b3b8a967bf879f7bc33c320) works standalone or only in context, and I'm not researching this because for me as upstream maintainer, this is done with the 1.2.5 release. => I think someone should package 1.2.5 for sid/unstable... more than half a year after its release.
Bug#746814: Should build against and link with system's libtrio
trio is only used when the system libraries are insufficient, which should not be the case with GNU libc. If a recent Debian build of bogofilter were to include libtrio in the build, please report that upstream via Gitlab (preferred) or mailing list with full logs so we can fix that. trio is also going away in future releases. So I'd say NEEDINFO WONTFIX - please tag this bug accordingly, and possibly demote severity.
Bug#524758: bogofilter: Bogofilter crashes on some mails
tags 524758 -moreinfo tags 524758 +confirmed +upstream +fixed-upstream thanks I think upstream Git commit 8eaeb85c should fix this. To appear in the next release after 1.2.5 (which has already been released). If it does not, please recompile bogofilter with debug log, provide your test message, your database, your configuration, the command line, and a backtrace.
Bug#524758: bogofilter: Bogofilter crashes on some mails
Tags: +confirmed -moreinfo Found: 1.2.4+dfsg1-13 Found: 1.2.4+dfsg1-9 One simple way to reproduce this appears to be running this without pre-existing wordlist.db: echo $'\ngood' | bogofilter -n echo $'\ngood' | bogofilter -Rv I am adding a related "make check" test upstream as bogofilter/src/tests/t.debian-bug-524758.
Bug#740373: fetchmail: Generated emails about authentication failure is missing message-id
Am 05.12.19 um 09:07 schrieb Petter Reinholdtsen: > > Anyway, I was just curious what the answer to the question "why" would > be. Now I know. Thank you for the clarifying answer. :) > The answer is actually a bit more complex, with aspects of "problem already solved externally", "not mandated by standards", and "not trivial to implement and document". There are so many questions that will want to be asked back, for instance, what should the domain part be, do we need to make it configurable (either way it needs documentation) and all that. High cost, little potential gain, I dare say not frequently needed, and as shown the problem has already been solved by others externally - and in a way (not quite coincidentally) that you can integrate into your setup. And it's really only necessary for the specific circumstance that further parts of the mail setup really fail in hard or very awkward ways if the Message-ID is missing, and that seems to be a feature of older notmuch implementations fixed a few releases ago. There are other feature requests that won't catch a "wontfix" tag that quickly because either they have low cost, or are hard to solve externally (for instance, expire kept messages on server after N days) or are otherwise more sensible to do without duplicating existing solutions.
Bug#740373: fetchmail: Generated emails about authentication failure is missing message-id
Am 04.12.19 um 10:14 schrieb Petter Reinholdtsen: > [Matthias Andree 2014-05-20] > While it sure is optional according to RFC5322, it is considered best > practice to include in in emails. What is the reason the fetchmail > developers do not want to include Message-ID into these notification? > I currently use fetchmail+procmail to receive emails from IMAP servers, > and the IMAP servers seem to make sure Message-ID is present. The > issue at hand here are emails not originating from the IMAP servers, > unfortunatly. What is the reason people use inferior software and then only to a small stretch of its possibilities, and then try to put convenience features into other packages? What is the new argument that could sway the original decision? Or think that the fetchmail developers would have to answer such questions at all? If the issue is with procmail + notmuch not generating that header, or coping without, then fix that. So? If you must use that unmaintained piece from the museum of anti-designs called "procmail", you can as well rig it to pipe all ingress mail through "formail -a Message-ID" if notmuch still fails without such a header. formail is part of the procmail package. Or you could use reformail from the maildrop package. Other options might exist.
Bug#941308: fetchmail: Fail to start with buffer overflow detected
Control: tags -1 upstream fixed-upstream confirmed Control: severity -1 grave Christian, thanks for the report. It is a known issue that happens with fortifying compilers. Please use either the former rc3, rc4 or the upcoming 6.4.1. László (gcs@) is aware of it.
Bug#941129: fetchmail: pidfile behavior changed
Am 28.09.19 um 00:59 schrieb Alex Andreotti: > Attention, I was using it with a relative path and it worked, the > behavior change is that it stopped working, I believe with one of the > two updates below: fetchmail behaved inconsistently between daemon and non-detaching modes in the upstream version without Debian patches already until 6.4.0-rc4, and that needed fixing, and is what I've fixed. If there are additional issues, I hope the package maintainer (Laszlo) can see to them. > > September 4 > > fetchmail (6.4.0~rc4-1) unstable; urgency=medium > > * New major upstream RC release. > * Remove outdated and Python 2 only fetchmailconf package (closes: > #936512). > * Drop merged in patches. > * Update remaining patches. > * Remove old upgrade code from postinst. > > September 6 > > fetchmail (6.4.0~rc4-2) unstable; urgency=medium > > * Remove all parts of fetchmailconf (closes: #939522).
Bug#941129: fetchmail: pidfile behavior changed
Control: tags -1 confirmed upstream Alex, thanks for your report, you've found a very long-standing inconsistency in fetchmail's behaviour. The workaround is to give an *absolute* path for FETCHMAILHOME in daemon mode. This will be fixed in 6.4.0.
Bug#941129: [PATCH] env.c: make FETCHMAILHOME (fmhome) absolute.
If FETCHMAILHOME is specified as relative path, then it can become
the victim of a chdir("/") that happens in daemon mode, so that
switching to daemon mode will change behaviour of FETCHMAILHOME.
Reported by Alex Andreotti, Debian Bug #941129.
---
NEWS | 3 +++
env.c | 15 ++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 006a5969..1a4ea966 100644
--- a/NEWS
+++ b/NEWS
@@ -188,6 +188,9 @@ fetchmail-6.4.0 (not yet released):
that quoted-printable-encoded multipart messages can get decoded.
(Regression in 5.0.0 on 1999-03-27, as a side effect of a PGP-mimedecode fix
attributed to Henrik Storner.)
+* FETCHMAILHOME can now safely be a relative path, which will be qualified
+ through realpath(). Previously, it had to be absolute in daemon mode.
+ Reported by Alex Andreotti, Debian Bug#941129.
## UPDATED TRANSLATIONS - THANKS TO:
* CS: Petr Pisar [Czech]
diff --git a/env.c b/env.c
index f1fb2cdf..06cfcb38 100644
--- a/env.c
+++ b/env.c
@@ -29,6 +29,7 @@
#if defined(HAVE_SETLOCALE) && defined(ENABLE_NLS) && defined(HAVE_STRFTIME)
#include
#endif
+#include
#ifndef HAVE_DECL_GETENV
extern char *getenv(const char *); /* needed on sysV68 R3V7.1. */
@@ -115,8 +116,20 @@ void envquery(int argc, char **argv)
home = xstrdup(pwp->pw_dir);
/* compute fetchmail's home directory */
-if (!(fmhome = getenv("FETCHMAILHOME")))
+fmhome = getenv("FETCHMAILHOME");
+if (NULL == fmhome) {
fmhome = home;
+}
+/* and make it an absolute path, so we
+ * can optionally chdir("/") later in daemonize()
+ * without changing behaviour.
+ * This is to fix Debian Bug#941129 by Alex Andreotti.
+ */
+{
+ static char _fmhome_abs[_POSIX_PATH_MAX];
+char *tmp = realpath(fmhome, _fmhome_abs);
+if (tmp) fmhome = _fmhome_abs;
+}
#define RCFILE_NAME"fetchmailrc"
/*
--
2.21.0
Bug#931568: fetchmail: Loaded OpenSSL library 0x1010103f newer than headers 0x1010101f, trying to continue.
On Sun, 07 Jul 2019 15:10:57 -0400 karl wrote: > Package: libssl1.1.1c-1 > Version: libssl1.1 > Severity: important > > > Began losing email and or attachments 5/19 with a fetchmailrc that had worked for years. > > > (fetchmail -v) > > fetchmail: Loaded OpenSSL library 0x1010103f newer than headers 0x1010101f, trying to continue. This is a warning only to notify the user that the system is inconsistently installed and the OpenSSL library loaded at run-time was newer than the OpenSSL headers on the build host. This does not mention the fetchmail version, and it appears that fetchmail wasn't rebuilt after an OpenSSL upgrade. Please check if upgrading the entire system fixes the issue, and if not, please provide further logging to show that and how fetchmail "loses mail".
Bug#873668: fetchmail: Wrong octets number displayed after 2-GB-threshold
Tags: fixed-upstream This is fixed in the legacy_6x branch on Gitlab, https://gitlab.com/fetchmail/fetchmail/commit/87626c2707cc0d82e49e160ab3c85430ff33534f Note the fix requires C99 support because it uses the "long long" type, else the bug would remain unfixed on 32-bit systems.
Bug#872754: fetchmail: tls_process_server_hello:unsupported protocol
On Fri, 21 Jun 2019 11:44:28 +0200 Matthias Andree wrote: > On Sat, 27 Oct 2018 20:16:17 +0200 Nicolas Boulenguez > wrote: > > Package: fetchmail > > Followup-For: Bug #872754 > > > > Hello. > > I have tried 6.4.0~beta4-1 in experimental. > > This resulted in: > > > > reading message for *:1 among * flushed > > (maybe unrelated) show_signal_msg: 1 callbacks suppressed > > fetchmail: segfault at 14 ip 560d2f73a718 sp 7ffe8242c790 > error 6 in fetchmail[560d2f716000+44000] > > > > Feel free to contact me if you want to reproduce the issue. > > Nicolas, > > If you can reproduce the issue, please install debug symbols and get me > a stack backtrace. Merci d'avance. > > Regards, > Matthias Nicolas, can you reproduce this and get me a stack backtrace? I need to urge a bit since I need to release 6.4.0 soonish and would want to fix a crasher bug... Merci. Regards, Matthias signature.asc Description: OpenPGP digital signature
Bug#932906: e2fsprogs: FTBFS on x32:, Tests failed: f_pre_1970_date_encoding
It would seem that this fix should also help FreeBSD architectures where sizeof(time_t) == 8 everywhere except i386, but 32-bit RISC architectures such as ARM usually have sizeof(long) == sizeof(void *) == 4. Basically the bug fixed by tytso@'s patch hits when sizeof(long) < sizeof(time_t) because strtoul() is insufficient to parse into time_t in that situation. I'll cherry-pick the patch from Git into FreeBSD, to appear as e2fsprogs-1.45.3_2. FreeBSD reporter vs. ARM (on a BananaPi) on Bcc:.
Bug#872754: fetchmail: tls_process_server_hello:unsupported protocol
On Sat, 27 Oct 2018 20:16:17 +0200 Nicolas Boulenguez wrote: > Package: fetchmail > Followup-For: Bug #872754 > > Hello. > I have tried 6.4.0~beta4-1 in experimental. > This resulted in: > > reading message for *:1 among * flushed > (maybe unrelated) show_signal_msg: 1 callbacks suppressed > fetchmail: segfault at 14 ip 560d2f73a718 sp 7ffe8242c790 error 6 in fetchmail[560d2f716000+44000] > > Feel free to contact me if you want to reproduce the issue. Nicolas, If you can reproduce the issue, please install debug symbols and get me a stack backtrace. Merci d'avance. Regards, Matthias
Bug#921450: Info received (Bug#921450: (no subject))
Control: tags -1 confirmed upstream fixed-upstream -moreinfo -unreproducible This got fixed in upstream Git as of commit 8c57ec38ae327fcd648569acc915f47f0eb2547d - please cherry-pick this. https://gitlab.com/fetchmail/fetchmail/commit/8c57ec38ae327fcd648569acc915f47f0eb2547d
Bug#921450: (no subject)
Generally, a POP3 DELE becomes effective only with the following QUIT that completes the session, so the server is compliant. I shall have a look at the stack and valgrind traces later to see if I can find the cause.
Bug#872754: fetchmail: tls_process_server_hello:unsupported protocol
Please check and report back if this is fixed in 6.4.0~beta4-1 (experimental).
Bug#798803: fetchmail: Slowness when .fetchids file grows large
Given the long expected release time until 7.0.0, and that we do not need to change the interface, I have decided to merge the P-tree .fetchids acceleration code back into 6.4.0. Laszlo has uploaded the beta4 release to experimental for your, well, experimentation. Feedback solicited.
Bug#804604: [pkg-fetchmail-maint] Bug#804604: fetchmail: FTBFS: undefined reference to `SSLv3_client_method'
Am 15.11.2015 um 06:00 schrieb peter green: > Tags 804604 +patch > thanks > >> socket.o: In function `SSLOpen': >> /fetchmail-6.3.26/socket.c:917: undefined reference to >> `SSLv3_client_method' >> collect2: error: ld returned 1 exit status >> Makefile:699: recipe for target 'fetchmail' failed >> make[3]: *** [fetchmail] Error 1 > > I just fixed this in raspbian, debdiff at > http://debdiffs.raspbian.org/main/f/fetchmail/fetchmail_6.3.26-1%2brpi1.debdiff > . No intent to NMU in Debian Dear Peter and Lászlo, I have stuff in fetchmail's upstream Git repository that should fix that officially -- it's on branch legacy_64 here: https://gitlab.com/fetchmail/fetchmail/tree/legacy_64 it also adds TLS 1.1/1.2 support, and is spread out across several commits (because just taking away SSLv3 without adding TLS v1.1 and v1.2 seems pointless to me).
Bug#798803: [pkg-fetchmail-maint] Bug#798803: fetchmail: Slowness when .fetchids file grows large
Actually, O(n * m), where m is the - limited - length of the UID strings, and in practice, few comparisons are claimed to be necessary on the average case, on many servers, UID are either very short or share common prefixes. It feels a lot faster at any rate with some 10,000 messages in the upstream server's mailbox, where my computer got quite slow already.
Bug#798803: [pkg-fetchmail-maint] Bug#798803: fetchmail: Slowness when .fetchids file grows large
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am 13.09.2015 um 02:38 schrieb Mark Triggs: > Dear Maintainer, > > Recently I've noticed that running 'fetchmail' to awake my > background fetchmail daemon is quite slow. It takes around 5 > seconds to return, where previously it was pretty much > instantaneous. Hi Mark, Nico forwarded your input to me as the upstream maintainer, and asking my input. > I ran fetchmail under callgrind and found that it was spending all > of its time loading my (large) .fetchids file into a linked list. > I've got a POP3 server with all messages kept on it, and my > .fetchids file contains around 50,000 entries (I should probably > switch to IMAP ;) Well, no...t yet. fetchmail does not yet implement client-side tracking of "seen" messages in IMAP. (There have been incomplete patches offered in the past but those neglected looking at the UIDVALIDITY and were thus unsuitable for deployment.) >> From what I can see, the issue is that each ID from .fetchids is > appended to a linked list (by initialize_saved_lists() in uid.c), > but the append operation (save_str) has to scan the entire linked > list from head to tail on every append operation. As a result, the > process of reading the file is O(N^2) instead of O(N). > > There's a struct member on 'struct query' called 'oldsavedend' > that was unused and seemed like it might have been intended to > track the end of the linked list, so I've modified uid.c to use > that variable--keeping track of the last node in the linked list > and avoiding the full scan. I've attached a patch for that, and > performance is back to instantaneous in my testing. > > It's a pretty minor thing, but easy enough to fix so I thought I'd > report it. Your assessment is correct, and I have been considering such a change as you are proposing, but rejected it. Ultimately, unless fetchmail changes data structures, it cannot get any better than O(n^2) because n times the linear search of a linear list with n elements remains in the code path, and bogs the entire UID handling still down to O(n^2). I have received and integrated a contribution by Rainer Weikusat into the upstream's Git master branch, and also let it afoot with 7.0.0 alpha releases since alpha2, which switches the entire list handling to use Patricia trees (radix trees) instead, which should AFAICT bring the entire UID handling to sane levels, O(n log n). For reference, the relevant places to look at are, in the upstream Git repository, in the uid_db.c and uid_db.h files. 1. 3e0432c01c37e7cd4f059be7dfd1a1ca2286683b - merge of feature branch (unsuitable for cherry-picking or thereabouts, and I don't mean to backport it because we need to forward with TLS, too) 2. e3b838cb8db9a4cb2f1449d5535a918282e6855d - fixes a regression in 3e0432c affecting POP3 polls. The Git repository resides at these places currently: https://gitlab.com/fetchmail/fetchmail http://sourceforge.net/p/fetchmail/git/ci/master/tree/ Hope that helps. Nico, I propose: confirmed upstream fixed-upstream. Best, Matthias -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJWAyr1AAoJEOQSsVbv84Va1LoP/3wgA6WoBWcwJihYZxS0pESO Fbj8/tL13ziY/DfRaAb8hZa1ClWFHYaMwozHLB5ZDU6w/WQbouna9eCtnA4ztFO+ iTSx6KsuHtgpI7rmDVZK7fH5qf8Kgx/SmTQnJkIffNccQkqIUw+zbRVfbXZYusMj JewUhuI0nH3hLqXuWfWiHXOv1I2cEybYKsFuQcgdDx2lS1gaW76k0IqJ17tQx9Cq 00+PZQD3Q02jVAjcB5oJ7GRlXvh5relhtAo8jui2JTnfdTl0zfu0O3/L5fCt5jRX 7+Eqvkd3HNkcWH4jXwW63JT8G/US79Maj94h4AmKy8238eW3J/BHQ0jpxyPPOr2I BHJLj1jyWR77UGsU5kz12tLQZB4A3o08gj+IVRnZyyBJIaqyiA+LJ4enEtFYt3BI oc5vuFbnimmBIeEfOEQ0LIIr8/QAl1Q25mAB5nYoEGq8KizdUFfAQ1OIxa493z7j 3P/H+qTiTk5a1KfOuDw7uqwOU6MdBJcJgPDyUGNeVNgJLQLIcnv+ur8jpX0SQXWj LmReSsyMHBZwKvR0B/WLtH/IL19m4nmwPsNL+Ks1sI8dltCn8Jz+CeoXMb2l8/IC VBNrE8XIgRt3ownkxIwVQbB8/n4STyL5kxR342wNL3oHUP+fMDd4k+Coz3Dwxi3G LXKyfuU3psgKawwvOppJ =I+7o -END PGP SIGNATURE-
Bug#781803: [l10n] [de] fetchmail: german translation abgeschossen
tags 781803 confirmed upstream fixed-upstream l10n thanks Am 03.04.2015 um 16:40 schrieb Nico Golde: Thanks for the report! Being a native speaker myself, I don't care either way to be honest, but I can see how beendet sounds a little more professional. Matthias, do you mind changing this? Changed three occurrences for the future 6.4.0 and 7.0.0 releases. https://gitlab.com/fetchmail/fetchmail/commit/8ad7b4f7a368cf6b4d0bf4b95e46cb199b60b2be Cheers, Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775255: fetchmail: Fails to start when libssl has SSLv3 disabled
When pulling patches, please also grab e6340bf from Git on top of a2ae6f8 (i. e. apply both, a2... first then e6...). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775255: fetchmail: Fails to start when libssl has SSLv3 disabled
Am 16.01.2015 um 01:24 schrieb Debian Bug Tracking System: Processing control commands: tags -1 + experimental Bug #775255 [fetchmail] fetchmail: Fails to start when libssl has SSLv3 disabled Added tag(s) experimental. IMO this is an error from the shell and the dynamic run-time linker, not a fetchmail issue, and Sebastian is right, symbol removal REQUIRES bumping the .so version appropriately. It needs to be OpenSSL 2.0 then (at least libssl) in my understanding. I wonder how people get the package build though, if the symbol is dropped from the lib it most certainly should also be dropped from the header, and that would already jam the build. (OK chances are that the library package is younger than the fetchmail package, please check that. You should NOT be able to build fetchmail on a libssl that has SSLv3 disable, else please file a bug against the libssl*-dev package.) Now, if OpenSSL chooses to disable options in an incompatible way, by causing compile or run-time link trouble by removing symbols, so be it, the proposed fix however is wrong and rejected. For 6.3 the proper fix will be to amend to configure and conditionally disable SSLv3, but it will need to tell the user what the matter is, so just silently removing a line without adjusting parsers and thereabout is an offense. For 7.x I may consider killing SSLv3 support altogether, it's no longer default in the Git version since 2014-10-15 anyhow. I would need to add a deprecation warning in a 6.x release though, and distributors may also need to do that. Having said all that, grab a2ae6f8d15d7caf815d7bdd13df833fd1b2af5cc from one of the three upstream Git mirrors and extract the relevant parts. If you break it, you get to keep the pieces, though... My take is that this bug should be demoted to wishlist and also bestowed with upstream, fixed-upstream, patch tags. HTH -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768843: fetchmail: Improved TLS support
Am 09.11.2014 um 17:02 schrieb Kurt Roeckx: Package: fetchmail Tags: patch Hi, The attached patch improves fethcmail SSL/TLS support. It seems to have some misunderstandings of openssl / SSL / TLS. Dear Kurt, thank you very much for spending time on this matter. What you are writing is generally correct (while I have not audited your patch in minute detail). The SSL support patches that went into fetchmail years ago, from various authors, in various stages, are flakey and used to be incomplete in older versions. Some of that was due to the very scattered and incomplete SSL documentation in general. Some of the original contributors mingled SSL/TLS versions with the point in time when negotiation takes place: up front (SSL/TLS-wrapped), or in-band after STLS/STARTTLS, or not at all. The option set fetchmail offers is awkward in 6.x. Sorting this out, however, isn't easily done without breaking existing semantics. While I appreciate very much that your change also affects documentation, I fear the patch is inacceptable for stable releases. (About future releases, please see the end of this message.) First, STARTTLS should work with both SSL and TLS, not just from TLS 1.0. The TLS in STARTTLS does not mean it's TLS only, TLS is just a different name for SSL. I understand that, the original contributors did not. (Technically, TLS 1.0 is SSL v3.1, TLS 1.1 SSL v3.2, TLS 1.2 SSL v3.3 during handshakes, for instance.) It also still seems to think only TLS 1.0 is supported while there are more recent versions, and it encourages SSL3 because SSL2 is broken. True. I've also changed the way in which opportunistic TLS works a little. It seems to have only done this with TLS1 for the above stated reasons which were wrong. This patch results in the following changes with a server support STARTTLS: | --ssl | no option | sslproto ssl23| sslproto tls1 Old: | TLS 1.2 | TLS1.0| not working | TLS1.0 New: | TLS 1.2 | TLS1.2| TLS1.2| TLS1.0 The sslproto ssl23 case just send logout, I assume because maybe_tls returns false. This started by making the call to SSLv3_client_method() optional in case openssl doesn't support it. I am not sure I understand the last two phrases. The next-to-last is probably a matter of reading code and perhaps debugging (also your later sslproto behaving differently than an omitted sslproto option - this may have to do with automated repolls for opportunistic TLS). I am rather loathe to propose/endorse/support changing option semantics for a stable release; we'd probably need to add new switches. Please have a look at the current state of fetchmail's master (note: it is non-default, so you'll need to git checkout master after cloning) branch in Git, either here https://gitorious.org/fetchmail/fetchmail/source/master: or here: http://sourceforge.net/p/fetchmail/git/ci/master/tree/ and let me know what you think of the --sslmode and --sslproto as you've found, if documentation is missing or inaccurate. I would personally prefer discussion through the fetchmail-devel@ mailing list (which has public archives, but requires subscrption), but if you can't be bothered, the Debian BTS will be better than no feedback. We should then see if we want to backport that without the obsolete-options-warnings (but perhaps with an --ssl-newstyle option required to switch semantics) or if we leave that for 7.x. Thank you very much. Best regards, Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740373: [pkg-fetchmail-maint] Bug#740373: fetchmail: Generated emails about authentication failure is missing message-id
Am 28.02.2014 19:26, schrieb Petter Reinholdtsen: Package: fetchmail Version: 6.3.21-4 Hi. When fetchmail is unable to log into the IMAP server to fetch emails, it inject an email into the mail spool to report this problem. But the injected email lack message-id, causing the notmuch mail indexing system to not handle these emails very well. I discovered this when my scripts processing emails just failed to discover these when looping over all message-ids. The header is optional according to RFC5322. If notmuch does not cope with that, have fetchmail inject mail into an MTA that works and generates missing Message-ID headers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744907: [pkg-fetchmail-maint] Bug#744907: fetchmail should not localize header field names in authentication failure emails
Am 16.04.2014 07:43, schrieb Gonzalo Pérez de Olaguer Córdoba: AFAIK, the header field name should remain in english (Subject, not Asunto) no matter which language is used for the subject body. Right, thank you for the bug report. I have fixed this in Git -- but it is unclear if I will ever release a 6.3.27 release, or if the fix will only go into a future 7.0.0 release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525004: Time to close Bug#525004
libdb4.6 is being phased out according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510270#35, perhaps it's time to close this bug on grounds that this was a libdb4.6 bug, not a bogofilter bug and the requested information hasn't been received in more than three years. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#389270: Random (fetchmail) name resolution errors again
Francesco, this is not at all useful without further logs and traces; reopening the bugs you should have seen what information and research we've had to do to find the bug and that it was considered fixed for half a decade. It is very likely that relevant regressions, if any and not real temporary issues, are caused by changes in the resolver rigging (name server, lwresd, whatever, plus nscd and other daemons used by the libc); and in that situation, I will need API documentation to the extent that it allows me, from fetchmail code, to reinitialize the resolver library. Nico, what is the resolver configuration in the fetchmail build, what daemons is libc supposed to use on the affected systems? Is lwresd involved? Francesco, I will also need further logs to evidence: - please show me the config.h and config.log (perhaps Nico can dig these out from buildd logs, too) - that the bug persists in fetchmail 6.3.26 which is the current upstream version, - the fetchmail configuration and logs per FAQ item #G3 (URL earlier in the bug), - a documentation of resolv.conf, host.conf, nsswitch.conf before/after changes, and how that relates to resolver trouble, - a proof that nscd is not running and providing negative cache entries, or is otherwise having its cache flushed when nsswitch.conf changes, - an ltrace excerpt showing how fetchmail is attempting to resolve the relevant names or reinitializing the resolver library (or not) - proof that other software can resolve the names in the very same instant (a fake poll entry with ssh for its plugin might do that). Best regards Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466299: fetchmail: Fails if unable to set \Seen flag
Nico, the issue is that fetchmail is currently unable to fetch from read-only mailboxes and aborts. This will not be fixed for 6.X, but in the long term (7.X), I plan to track seen/unseen IMAP mail on the client side (like we already do with POP3 + UIDL), and then this will work. The only open questions are the when? and the severity of the bug. It can be anywhere from wishlist to important (as it stands) -- I don't have any stakes there. Best Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707934: (no subject)
I am planning to change this in the next major (7.X) fetchmail release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466299: (no subject)
The issue is that the user expects fetchmail to get along with setting \Deleted, but in fact it additionally sets \Seen. Achieving this requires changes that are unsuitable for the 6.X series of fetchmail releases, and requires SEARCH by flags, which not all servers implement. Cloning bug to wishlist; Nico, feel free to reopen this and merge the bugs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706045: Fwd: fetchmail mimedecode option drops last message line
Package: fetchmail Version: 6.3.18-2 Severity: grave Tags: upstream confirmed fixed-upstream Control: found 6.3.9~rc2-4+lenny2 Control: found 6.3.21-4 Control: found 6.3.22-2 The bug report included below was filed against Ubuntu, it is an upstream bug that also affects Debian. It was originally found by Lars Hecking in 2011. Original-Nachricht Betreff: [Bug 1171818] [NEW] fetchmail mimedecode option drops last message line Datum: Tue, 23 Apr 2013 11:14:30 - Von: Axel G. Rossberg 1171...@bugs.launchpad.net Antwort an: Bug 1171818 1171...@bugs.launchpad.net Public bug reported: Over the last year or so (perhaps since update to fetchmail 6.3.21), I had a problem that in messages sent from one particular mail server (Microsoft Exchange) the messages I recieved had no text in the body at all. I then found that for plain text messages that are not terminated with a newline (sent using the ms webmail interface) the last line of the message gets lost. I assume that HTML messages are sent as a single, unterminated line, and therefore get entirely lost. The problem disappeared (at least that for plain text messages) when turning the mimedecode option off under fetchmail. Ubunutu release: 12.04 ** Affects: fetchmail (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to fetchmail in Ubuntu. https://bugs.launchpad.net/bugs/1171818 Title: fetchmail mimedecode option drops last message line -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706045: [pkg-fetchmail-maint] Bug#706045: Fwd: fetchmail mimedecode option drops last message line
XREF Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=955814 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705291: fetchmail: redundant fetch when configured for more than one user
This is expected behaviour. --user (or -u) is not a selector, but only overrides the default (which is the user name of the user running fetchmail). Effectively, the -u option overrides all username stanzas. I am demoting this to wishlist because it matches documentation: *We would need an option to specify and match the username in addition to the pollname.* This is not fetchmail 6.x stuff, however, it will have to wait for 7.x. The workaround is to use a pollname that is distinct from the server's host name. It might look like (untested): skip fred-pop.safe-mail.net via pop.safe-mail.net protocol imap port 993 interval 3 username fred.flintst...@safe-mail.net ssl sslcertck fetchall ... skip barney-pop.safe-mail.net via pop.safe-mail.net protocol imap port 993 interval 3 username barney.rub...@safe-mail.net ssl sslcertck fetchall ... (the same scheme for wilma). The poll name (the ...-pop.safe-mail.net right after skip) now no longer specifies the server name, but only an internal name to fetchmail. The actual host name goes after via. It's a bit longer to spell out, but should solve your problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703738: fetchmail: Dot at 1st column of any line cuts delivered message
To answer the remaining questions: 1. the POP3 server needs to byte-stuff (prepend another dot to lines starting with a dot) 2. the POP3 clients needs to undo the byte-stuffing (fetchmail's part) 3. an SMTP client needs to byte-stuff (also fetchmail's part) HTH. signature.asc Description: OpenPGP digital signature
Bug#703738: fetchmail: Dot at 1st column of any line cuts delivered message
I cannot reproduce this from a POP3 interface of Exchange 2003, or for a Dovecot IMAP interface. Please adhere to standard bug reporting policies at http://www.fetchmail.info/fetchmail-FAQ.html#G3 (mask passwords where necessary). This is likely due to misconfiguration or faults with the software that fetchmail forwards the downloaded message to, inappropriate local Exim/qmail/... setup, wrong options for re-injection, or similar. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#146306: fetchmail: so called bouncing of mail is braindead
Note that some protocols (ETRN, ODMR) require to send non-delivery notifications, because we cannot just leave messages on server with them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700266: fetchmail: --sslfingerprint uses MD5
Thanks for mentioning this. This will not be fixed in a 6.X version for compatibility reasons. (I might fix the manual page for 6.3.25 though.) I am not tagging wontfix because I do intend to fix this for the future 7.0.X series. We'd also need to add support for multiple fingerprints (for failover configurations) at the same time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688015: [PATCH] Re: Bug#688015: memory leak
Now that was a useful pointer, thanks a bunch!
We have had this leak ever since the subjectAltName support was added in
2005 (fetchmail 6.2.9)... it strikes whenever we manage to extract these
fields from a certificate while verifying it.
This bug only hurts in daemon mode, because the leak accumulates only then.
Can either of the reporters see and report back if the attached patch
improves the situation for you?
From 7ffec45913adc02a5c5f6a2cfe95a41d42ae535c Mon Sep 17 00:00:00 2001
From: Matthias Andree matthias.and...@gmx.de
Date: Thu, 13 Dec 2012 23:44:37 +0100
Subject: [PATCH] Plug a memory leak in OpenSSL's certificate verification
callback.
This would affect fetchmail configurations running with SSL in daemon mode
more than one-shot runs.
Reported by Erik Thiele, and pinned by Dominik, Debian Bug #688015.
This bug was introduced into fetchmail 6.2.9 (committed 2005-10-29)
when support for subjectAltName was added through a patch by Roland
Stigge, submitted as Debian Bug#201113.
---
socket.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/socket.c b/socket.c
index 634b476..3e4a3ac 100644
--- a/socket.c
+++ b/socket.c
@@ -689,7 +689,7 @@ static int SSL_verify_callback( int ok_return, X509_STORE_CTX *ctx, int strict )
}
}
}
- sk_GENERAL_NAME_free(gens);
+ GENERAL_NAMES_free(gens);
}
if (name_match(p1, p2)) {
matched = 1;
--
1.7.9.5
signature.asc
Description: OpenPGP digital signature
Bug#688015: memory leak data update
Erik, without either debugging info of a leak detector, or bare necessities to reproduce the situation per the FAQ http://www.fetchmail.info/fetchmail-FAQ.html#G3, there is no chance this can ever be fixed. (This does not rule out a lucky coincidence, but such a coincidence might happen in a few years, or never.) While the memory stats might hint to a leak, more info is required, and I propose to also provide information from lsof -c fetchmail (run as root). I will personally also not investigate bugs in 6.3.18, but only in 6.3.22 -- I might be willing to look at bug reports that pinpoint the location in a code excerpt, however. It all hinges on a way for me to reproduce the problem, or someone to send a patch and/or a good explanation how the leak would show up. Sorry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688015: memory leak
Am 18.09.2012 13:49, schrieb Erik Thiele: Am 18.09.2012 12:53, schrieb Nico Golde: Hi, * Erik Thiele erik.thi...@thiele-hydraulik.de [2012-09-18 09:48]: [...] how can I further supply information on this issue? It is a production machine, but maybe I can somehow help find the cause of the issue anyway? Or is that memory leakage a known issue? This is not known to me at least. Unfortunately the logs don't show that fetchmail had memory issues. The kernel randomly starts killing processes (depending on your policy) if no memory can be allocated anymore. Could you log the virtual memory usage of specifically fetchmail? at the end of my report you see daily logs of last two days of fetchmail memory consumption. i will continue to log that log to see if it further increases. actually the kernel killed many (174) processes until it finally killed fetchmail, then there where no more oom kills left. since fetchmail is the last to be killed, i suggest that fetchmail was the problem. Any proof? Or did another process just run away with all the memory and killing fetchmail was the first process to yield sufficient memory for the rampant OOM killer to settle down? Possibly run without memory overcommit just to make sure that there is no need for the OOM killer to go raging at all? At any rate, the resident set size (RSS) of your fetchmail process is largish, it should be a few MBytes. Some state is cached in daemon mode, so if you have a large .fetchids file, that might be the culprit; OTOH should a process using 75 MB of memory not destabilize your system. Fetchmail does not lock pages into memory, so the kernel should just page it out if needed. there was only one single kill of fetchmail. i am quite sure that fetchmail must be the process that used all system memory here. I would not jump to that conclusion - fetchmail used 75 MB per your figures, which is a smaller portion of your 1.5 GB address space. [...] does this mean take debian source package, recompile with debug flags, run under valgrind and terminate after two days with valgrind option show-reachable or so and send you that output then? or is there an easier way? Please consider it's a production system on a non-IT company which should just run... A valgrind trace of a leak would be most helpful. For starters, just running valgrind on the code might help to see if there are real leaks (and those inside OpenSSL or glibc need to be reported to the appropriate places, they do not count against fetchmail). Show-reachable is less interesting than real leaks, if any - that is because fetchmail caches internal state, and that will all be show-reachable (some of that code, especially around parsed configuration, is only freed on exit - so that would show up as false positive). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671294: (no subject)
Alexander, thank you for the patch. I have committed it to fetchmail's Git repository, but it is not yet part of a formal release. http://gitorious.org/fetchmail/fetchmail/commit/f77204551bb10e8c05acd8a607ee9db4ad48cf47 NEWS file entry: http://gitorious.org/fetchmail/fetchmail/commit/82a9a7dd5fc4b8febfa27ee77e0fec141c56b840 Best regards, Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676268: SMTP 553 5.1.3 invalid route address error after MAIL FROM causes failure of fetching
Trevor, thank you for taking the time to report a problem. However, it is not helpful if bug reporters get carried away to guess what might have happened, and draw false conclusions. Facts: - fetchmail treats response codes the same no matter if they are returned in reponse to MAIL FROM, or RCPT TO. - antispam and 553-code special handling do apply to MAIL FROM - fetchmail's softbounce feature can cause messages to be left on the POP3 or IMAP server. Use --nosoftbounce to delete permanently undeliverable mail. - Trevor's log contains a socket error. Chances are that the POP3 server or session crashed at that point, and got restarted for the next login. In order to make progress, please post a relevant transcript with sufficient verbosity, according to http://www.fetchmail.info/fetchmail-FAQ.html#G3, and leave it to the experts to interpret it. I currently believe that the POP3 server is faulty, and not fetchmail. Best regards, Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663963: leafnode: Fails to build on Hurd
Does Hurd support pathconf(/var/spool/news, _PC_PATH_MAX)? Which value does it return? Does Hurd return a value no smaller than _POSIX_PATH_MAX (256)? I might consider replacing PATH_MAX by a pathconf all to the spool directory for systems where PATH_MAX is missing, because that is covered by POSIX -- but if the Hurd requires application programmers to jump through hoops because the Hurd violates POSIX, you'll need to get along without the upstream support. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597607: (no subject)
This should be 'normal' severity, changing it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638773: fetchmail critical fix from upstream
Package: fetchmail Version: 6.3.18-2 Severity: important Tags: upstream, fixed-upstream, patch Hi Nico, just to remind you there's a patch at http://gitorious.org/fetchmail/fetchmail/commit/138baebcae334c2c222c0d0299148fe1aef0315c that fixes a bug where fetchmail's IMAP client, in versions 6.3.5 to 6.3.20, inserts a NUL byte when the last IMAP line is not terminated with LF. For newer releases consider 6.3.21. For stable, consider if you want a stable release update or just the patch. Best Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637478: [pkg-fetchmail-maint] Bug#637478: fetchmail: 28 minute IDLE timeout, should be configurable
Am 22.08.2011 00:22, schrieb Anders Kaseorg: On 08/12/2011 03:19 AM, Matthias Andree wrote: The IMAP standard (RFC-3501) has clear requirements with respect to how long servers need to tolerate connections left idle by clients, As much as the proxy’s behavior sucks, the proxy is under no obligation to support the IMAP standard. Well, I believe in freedom of religion, but I'm not interested in compensating for your IT dept's disinterest in standards or their deploying underfeatured proxies. Set a low daemon interval instead. Most commercial ISPs permit intervals as low as 60 seconds for IMAP, so check what is permitted for your site. And consider if you really need near-real-time mail access and get distracted from other work. Mail isn't meant as real-time or full-duplex medium. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637478: [pkg-fetchmail-maint] Bug#637478: fetchmail: 28 minute IDLE timeout should be configurable
Am 12.08.2011 00:13, schrieb Anders Kaseorg:
Package: fetchmail
Version: 6.3.18-2
I’m running fetchmail through a proxy server that drops any connections
left idle for more than a little over 2 minutes. In order to be able to
use IMAP IDLE, I need to reduce this hardcoded timeout value in
imap_idle():
if (has_idle) {
/* special timeout to terminate the IDLE and re-issue it
* at least every 28 minutes:
* (the server may have an inactivity timeout) */
mytimeout = idle_timeout = 1680; /* 28 min */
It would be nice to have that as a configuration option.
In the unlikely event that this is helpful to someone else, here’s the
i386 binary patch I’m using now (28 m = 0x690 s, 2 m = 0x78 s):
perl -0777 -pe 's/(\xc7\x05.{4})\x90\x06\x00\x00/$1\x78\x00\x00\x00/g' -i
/usr/bin/fetchmail
Anders,
The IMAP standard (RFC-3501) has clear requirements with respect to how
long servers need to tolerate connections left idle by clients, and if
the connection gets dropped so soon, IDLE support gets pointless.
Please file a bug or support request against the proxy that drops the
connection so soon in the IDLE phase.
Best regards,
Matthias
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632479: [pkg-fetchmail-maint] Bug#632479: fetchmail: accept -f and --pidfile option even when background running
Am 02.07.2011 19:52, schrieb Samuel Thibault: Package: fetchmail Version: 6.3.19-1 Severity: normal Hello, I run two fetchmail daemones, one using idle mode for one imap account, and one in batch mode for all the other ones. I'm thus using the -f and --pidfile option so that they don't interfere with each other. However, I can't trigger the batch one to proceed: $ fetchmail -f .fetchmailrc-all --pidfile .fetchmail.pid-all fetchmail: can't accept options while a background fetchmail is running. Fetchmail should at least accept -f and --pidfile in this case. Probably. Meanwhile, you can do this to work around this obstacle: 1. to just wake up the sleeping fetchmail daemon, send a SIGUSR1 signal. (Documented.) 2. separate the fetchmail configurations into their own directories, and run at least one with the FETCHMAILHOME variable set. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622054: PATCH: fix SSLv2_client_method-related FTBFS.
commit c22a3afca46c83ee6d53a6ee58deb122f309c460
Author: Matthias Andree matthias.and...@gmx.de
Date: Mon Apr 11 14:08:32 2011 +0200
Remove support for SSLv2 (fixes Debian Bug #622054).
SSLv2 has been deprecated since 1996, and is insecure.
Remove --sslproto SSL2 support.
Set SSL_OP_NO_SSLvSSL_CTX 2 option so that the SSLv23 multi-version
client no longer negotiates SSLv2.
Note that some distributions (such as Debian) build OpenSSL 1.0.0
without SSLv2 support, so on those, the build would fail.
Fixes Debian Bug #622054
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622054
diff --git a/NEWS b/NEWS
index 922bf0f..221bfcf 100644
--- a/NEWS
+++ b/NEWS
@@ -57,6 +57,10 @@ removed from a 6.4.0 or newer release.)
fetchmail-6.3.20 (not yet released):
# CHANGES
+* fetchmail no longer supports SSL v2, nor the corresponding SSL2 option to
+ --sslproto. SSLv2 is insecure and had been deprecated 15 years ago. fetchmail
+ will actively forbid SSLv2 negotiation by means of SSL_OP_NO_SSLv2.
+ To fix Debian Bug#622054.
* fetchmail now always uses its own MD5 implementation. The library and header
variants are too diverse, and we've been bitten before -- and configure
complains noisily on Cyrus-SASL's RFC1321 md5.h.
diff --git a/fetchmail.man b/fetchmail.man
index 495a60e..69aa887 100644
--- a/fetchmail.man
+++ b/fetchmail.man
@@ -474,8 +474,9 @@ Also see \-\-sslcert above.
(Keyword: sslproto)
.br
Forces an SSL/TLS protocol. Possible values are \fB''\fP,
-\'\fBSSL2\fP', '\fBSSL23\fP', (use of these two values is discouraged
-and should only be used as a last resort) \'\fBSSL3\fP', and
+\'\fBSSL23\fP' (note however that fetchmail, since v6.3.20, prohibits
+negotiation of SSLv2 -- it has been deprecated for 15 years and is
+insecure), \'\fBSSL3\fP', and
\'\fBTLS1\fP'. The default behaviour if this option is unset is: for
connections without \-\-ssl, use \'\fBTLS1\fP' so that fetchmail will
opportunistically try STARTTLS negotiation with TLS1. You can configure
diff --git a/options.c b/options.c
index d53044f..aee616b 100644
--- a/options.c
+++ b/options.c
@@ -651,7 +651,7 @@ int parsecmdline (int argc /** argument count */,
P(GT_( --sslcertpath path to trusted-CA ssl certificate directory\n));
P(GT_( --sslcommonname expect this CommonName from server (discouraged)\n));
P(GT_( --sslfingerprint fingerprint that must match that of the server's cert.\n));
- P(GT_( --sslprotoforce ssl protocol (SSL2/SSL3/TLS1)\n));
+ P(GT_( --sslprotoforce ssl protocol (SSL23/SSL3/TLS1)\n));
#endif
P(GT_( --plugin specify external command to open connection\n));
P(GT_( --plugout specify external command to open smtp connection\n));
diff --git a/po/de.po b/po/de.po
index 6340260..6158050 100644
--- a/po/de.po
+++ b/po/de.po
@@ -2269,8 +2269,8 @@ msgstr
Servers.\n
#: options.c:654
-msgid --sslprotoforce ssl protocol (SSL2/SSL3/TLS1)\n
-msgstr --sslprotoSSL-Protokoll erzwingen (SSL2/SSL3/TLS1)\n
+msgid --sslprotoforce ssl protocol (SSL23/SSL3/TLS1)\n
+msgstr --sslprotoSSL-Protokoll erzwingen (SSL23/SSL3/TLS1)\n
#: options.c:656
msgid --plugin specify external command to open connection\n
@@ -3174,9 +3174,9 @@ msgstr Datei-Deskriptor außerhalb des Bereichs für SSL
#: socket.c:901
#, c-format
-msgid Invalid SSL protocol '%s' specified, using default (SSLv23).\n
+msgid Invalid SSL protocol '%s' specified, using default (SSL23).\n
msgstr
-Ungültiges SSL-Protokoll „%s“ angegeben, benutze Voreinstellung (SSLv23).\n
+Ungültiges SSL-Protokoll „%s“ angegeben, benutze Voreinstellung (SSL23).\n
#: socket.c:994
msgid Certificate/fingerprint verification was somehow skipped!\n
diff --git a/socket.c b/socket.c
index 1adc839..fad21c5 100644
--- a/socket.c
+++ b/socket.c
@@ -889,16 +889,14 @@ int SSLOpen(int sock, char *mycert, char *mykey, const char *myproto, int certck
/* Make sure a connection referring to an older context is not left */
_ssl_context[sock] = NULL;
if(myproto) {
- if(!strcasecmp(ssl2,myproto)) {
- _ctx[sock] = SSL_CTX_new(SSLv2_client_method());
- } else if(!strcasecmp(ssl3,myproto)) {
+ if(!strcasecmp(ssl3,myproto)) {
_ctx[sock] = SSL_CTX_new(SSLv3_client_method());
} else if(!strcasecmp(tls1,myproto)) {
_ctx[sock] = SSL_CTX_new(TLSv1_client_method());
} else if (!strcasecmp(ssl23,myproto)) {
myproto = NULL;
} else {
- fprintf(stderr,GT_(Invalid SSL protocol '%s' specified, using default (SSLv23).\n), myproto);
+ fprintf(stderr,GT_(Invalid SSL protocol '%s' specified, using default (SSL23).\n), myproto);
myproto = NULL;
}
}
@@ -910,7 +908,7 @@ int SSLOpen(int sock, char *mycert, char *mykey, const char *myproto, int certck
return(-1);
}
- SSL_CTX_set_options(_ctx[sock], SSL_OP_ALL);
+ SSL_CTX_set_options(_ctx[sock], SSL_OP_ALL | SSL_OP_NO_SSLv2);
if (certck) {
SSL_CTX_set_verify
Bug#397632: amd64 support for gpart
Greetings, I've recently patched at least the DOS/NTFS probing stuff for amd64, see http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/gpart/ or more specifically these two patches: http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/gpart/files/patch-src__gpart.h?rev=1.1 http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/gpart/files/patch-src__gm_ntfs.h?rev=1.1 It does detect partition tables on DOS and recognizes FreeBSD slices (partitions in Linux lingo) but doesn't go all the way (meaning I haven't audited the whole code, particularly it may still assume little endian all over the map). I wonder if we should either try to unify our (maintainer) forces to get this gpart thingy polished and portable and possibly extended for NTFS5, ZFS and thereabouts, or if the whole package should be ditched in favour of something more modern, such as http://www.cgsecurity.org/wiki/TestDisk (note I haven't tried it yet). -- Matthias Andree (FreeBSD ports committer) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603861: Further information
The bug was caused by a bogus downstream patch that got imported from Ubuntu, 01_fetchmailconf.patch, that contained a bogus workaround for a different bug. This should never have made it into the package. Note that 01_fetchmailconf.patch and 03_fetchmailconf_python2.6.patch (as of svn://svn.debian.org/pkg-fetchmail/trunk rev 545) are both bogus and should be removed. If any issues remain, then either automake or python are broken. Corresponding downstream Bugs in Ubuntu are: https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/669066 https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/684228 But it is not to be expected that Ubuntu will see to those in the near future. -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603861: fetchmailconf: looks in the wrong place for fetchmailconf.py
Greetings,
I am confused. The upstream package contains a trivial fetchmailconf script
that gets generated by these Makefile.am rules: (the second is actually one long
line):
fetchmailconf:
( echo '#! /bin/sh' echo 'exec @PYTHON@ @pythondir@/fetchmailconf.py
$$@'
) $@ chmod +x $@ || { rm -f $@ ; exit 1; }
And PYTHON/pythondir are acquired by autoconf calling python's sysconfig module
-- through automake.
So if the path is wrong, then please check if
python2.6 -c import sys; from distutils import sysconfig;
sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='$am_py_prefix')) ; \
echo
yields the proper output path - if not, it's a fault in the Python packages, or
the call fails during ./configure (check config.log!)
This code snippet above is actually copied from configure (on openSUSE 11.3
though, generated by autoconf 2.65 and automake 1.11.1).
If that python call, however, _does_ yield the proper path (dist-packages), then
check the build scripts where it gets overridden, if there are siteconfig files
for autoconf, or config.caches where a wrong pythondir might get picked up.
HTH
--
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494418: fetchmail loses mail when From address malformed
This is mostly solved - 6.3.10 and newer have a softbounce option that can be set to keep mail on the POP3 server even if the SMTP server refuses such mail. However, I still think that such illegit mail should not be allowed to clog up the inbox and should be deleted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531589: Debian Bug#531589
This bug seems non-trivial to fix: in imap_idle(), we wait for untagged responses, and may be deep in SSL_peek -- and that restarts the underlying blocking read() from the socket, so we never break out of the SSL_peek() with SIGUSR1. This won't be fixed in fetchmail 6.3.X. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568455: fetchmail TLS/SSL with Exchange 2007 results in Autorization failures
It appears after another couple of hours of debugging and trying that depending on the excact circumstances, the GSS library in use may return when the actual AUTH SASL process has not completed, for instance, because credentials are missing. However, fetchmail has never cancelled the authentication phase properly in that situation. Ever since the gssapi.c code had been added to fetchmail in February 2001, fetchmail sent a blank line to wake up the server, which worked in some circumstances. However, according to various RFCs (1734/5034, 3501), fetchmail was supposed to send an asterisk, *, on a line by its own, to really cancel the AUTHentication phase. Also, the authentication framework in fetchmail sent the star to cancel things a bit later, but did not wait for and did not pick up the authentication error message that the server is required to send. This caused fetchmail to go out of synch and mistake the GSSAPI AUTH error for an error response to the later USER command. Relevant changes that should fix the bug but require testing are in the upstream test release 6.3.18-pre2; it is spread out across various commits in Git unfortunately. I'd propose that 6.3.18-pre2 be packaged for experimental, or for unstable with a marker to NOT migrate to testing until we have evidence that the bug is really fixed in -pre2. -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568455: (no subject)
Turns out the fix is piecemeal, for instance: if the user has access to multiple Kerberos-enabled accounts, he might get an error that the authenticating user (who uses the ticket from an other computer) weren't in the database. This, again, gets Exchange 2007 in a state where it won't accept further authentication attempts in the same session. Looks like we need to remove the auto feature, or to add a repoll feature for IMAP, too, and trigger it on authentication failures. This also needs a proper framework to lock methods that fail. -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568455: fetchmail TLS/SSL with Exchange 2007 results in Autorization failures
Nico, Héctor, this was repeated again and again on the fetchmail list, and it is a massive regression from Debian 4.0 - and we can solve it with a patch. I have asked Patrick Rynhart and Alan Murrell to test [1] (it may need a few more of the previous commits, too, see [2], and disregard failures to patch NEWS). If that works out well, I will then ask you to merge the patch to all fetchmail versions that are configured and built with ./configure --with-gssapi, and upload new versions. [1] http://gitorious.org/fetchmail/fetchmail/commit/82e1d66f6bee1a8837d8d6c89c7ed6b11f2c0a48 [2] http://gitorious.org/fetchmail/fetchmail/blobs/history/master/gssapi.c Best Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593694: fetchmail: Please merge upstream GSS robustness patch(es)
Package: fetchmail Hi Nico, Hector, please download and merge the patch from the upstream repo at http://gitorious.org/fetchmail/fetchmail/commit/19dc52bcc681165a99e50c6b4d68af2f88d1645c.patch It should apply against a large number of distributions and rectifies compiler warnings; more importantly, it avoids outgoing GSSAPI authentication messages from being malformatted should they happen to contain '%' characters, or crash fetchmail should they happen to contain string formatting strings. Please also review and consider adding http://gitorious.org/fetchmail/fetchmail/commit/e5510f67f15d893bb476a0db5b2de702129e122c.patch which enhances GSS messages in response to bugs such as #568455, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568455 - let's figure what the quarrel between fetchmail and Exchange 2007 is all about. Note that the patch DOES NOT FIX 568455, but helps diagnosing the cause. Best -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582475: [pkg-fetchmail-maint] Bug#582475: Bug#582475: fetchmail: init script should wait for DNS
Am 21.05.2010 15:39, schrieb Nico Golde: Hi, * Jan Braun janbr...@gmx.net [2010-05-21 13:38]: Fetchmail's init script should probably depend on exim4 and $named, rather than just $network. At least here, with dependency-based boot enabled, the first run always fails because DNS (a local pdnsd) is not yet available when fetchmail is started ($network implies only low-level networking). Similarly, fetchmail will usually need an MTA running, so I've added a dependency on exim4 too (as precaution, I didn't experience any failures due to this missing). There doesn't seem to be a $mta target, but you could add other MTAs too if you care. I tend to disagree, you don't need a local nameserver or mta installed in order to use fetchmail so I can't follow you on why it makes sense to depend on those components with the init script. What harm would it do to make sure that fetchmail always starts *after* name services and MTAs are up and running, if such are installed and configured? I take it this is about init script *execution order*, not actual *dependencies*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580796: [pkg-fetchmail-maint] Bug#580796: fetchmail: Connection insecure in spite of sslfingerprint
tags 580796 confirmed upstream thanks Roland Stigge schrieb: Package: fetchmail Version: 6.3.17-1 Severity: normal Hi, I just upgraded fetchmail from 6.3.15-1 to 6.3.17-1 and suddenly, it says: $ fetchmail fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) fetchmail: No mail for stigge at subdomain.domain.tld $ which it didn't before. I'm using a .fetchmail stanza like this: poll subdomain.domain.tld with proto IMAP user 'foo' there with password 'bar' is 'quux' here options fetchall expunge 100 sslproto TLS1 sslfingerprint 'AF:22:16:91:5B:9E:5E:FE:A5:3B:28:3E:39:38:E0:27' I think I can consider the connection secure when I know the fingerprint of the server beforehand and it matches. Indeed you can, providing the reference fingerprint was obtained through a secure channel (and usually not by just looking at fetchmail -v output - which some websites or older documentation recommends). This is an oversight in creating this warning. Sorry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580796: PATCH: fix Debian Bug#580796
tag 580796 patch
thanks
Find attached a patch to hopefully solve that problem.
Works for me, but please test.
diff --git a/socket.c b/socket.c
index a3adfd8..2ebdfc6 100644
--- a/socket.c
+++ b/socket.c
@@ -1009,8 +1009,8 @@ int SSLOpen(int sock, char *mycert, char *mykey, const char *myproto, int certck
}
}
- if (!certck (SSL_get_verify_result(_ssl_context[sock]) != X509_V_OK
-|| !_verify_ok)) {
+ if (!certck !fingerprint
+ (SSL_get_verify_result(_ssl_context[sock]) != X509_V_OK || !_verify_ok)) {
report(stderr, GT_(Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)\n));
}
Bug#578956: Debian Bug#578956: fetchmail message loss?
retitle 578956 fetchmail drops messages with non-header lines in header section severity 578956 wishlist tags 578956 fixed-upstream found 578956 6.3.6-1etch1 found 578956 6.3.6-1etch2 found 578956 6.3.6-1etch3 found 578956 6.3.9~rc2 found 578956 6.3.9~rc2-4+lenny1 found 578956 6.3.9~rc2-4+lenny2 fixed 578956 6.3.15-1 fixed 578956 6.3.16-1 fixed 578956 6.3.16-2 thanks Stop abusing the BTS by assigning bogus severities. fetchmail does not trash external data or the system, nor does it cause data loss. The culprit has already been identified as clamassassin in bug 578953 (likely the use of perror() or equivalent in clamassassin) - so anything beyond normal would be inappropriate for fetchmail. Newer fetchmail versions support a workaround (--bad-header accept), but chances are that your MTA or MUA throw up anyways. The bug is really with another package. pgpiALz7RfGwx.pgp Description: PGP signature
Bug#578764: Please default to 'commit -a' when no changes were added
I'd also concur that default to commit -a would be a most undesireable astonishment for me. Please don't go that way. Thanks. (Not that I believe it stands a chance of upstream integration, but to avoid downstream distro-specific shipwrecks.) -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578764: Please default to 'commit -a' when no changes were added
Am 23.04.2010 22:17, schrieb Goswin von Brederlow: Wincent Colaiuta w...@wincent.com writes: El 23/04/2010, a las 11:03, Goswin von Brederlow escribió: You all say the index is such a great thing. So I might use it eventually. Other people might use it 1 out of 10 times. Yet other people use it 9 out of 10 times. Can you at least accept that the use of the index feature is different for each person? My suggested change, with the --a-if-empty option, would not impose anything on existing usage. But it would benefit those that rarely use an index and would like git to be smart enough to know when to use the index and when not. Yes, it would mean the use of the index ideology is not force upon people anymore. But isn't that a good thing? Free software is about freedom. That should include the freedom not to use the index method. Not really. Git is free in the sense that: (1) it costs nothing; and (2) you can modify the code to do anything you want. But you've also got to recognize that along with your freedom to make modifications, the maintainers are free to either accept or reject them too. And in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations. But you are already rejecting it in the design phase before there even is a patch. In the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less surprising for users coming from other systems, but we'd be throwing away something valuable in the process. If I would ask to disable the indexing feature then you would have a point. But I am not. I'm asking to add something that allows to use git in a less surprising mode that, with the --a-if-empty option, does not alter anything else. Git would still have all its great, big, shiny, differentiating features to set it apart from other SCMs without forcing them down the users throat. I personally don't see the point in having a bunch of SCMs that are all exactly alike. I _like_ that Git's different, and over the years have become so used to the benefits that working with the index the Git way bring, that it's hard to imagine how I ever lived without it. Cheers, Wincent I personaly have to work with different SCMs every day and every time I have to switch minds to work with each specific one. Making git commit work less surprising would be one less thing to keep in mind. You are trying to make Git more difficult to understand for the user. This is easily perceived as non-determinism. Before introducing a code branch (à la if $(git diff-index --quiet HEAD), think twice. It doubles testing efforts, it makes explanations long-winded. What's so difficult about typing [Arrow-Up] [Space] [-] [a] [Enter] if git commit comes up empty. With your option, I need to remember that Git is overzealous and will commit the whole index if nothing is staged, possibly git reset HEAD^ and clean up the mess. This is inconsistent and inefficient. Try git gui or git citool if you can't be bothered to remember how to add changes to your commit. Git isn't alone. Think BitKeeper, DARCS. For other systems, there are extensions to help with committing, and to emulate what DARCS has pioneered, for instance hg record, an extension for Mercurial. You like that Git is different so don't use the --a-if-empty option. You No. I for one like the ability to stage changes and commit logically cohesive changes without having to save files to temporary files. will have lost nothing by allowing that option in. So far I have read arguments from people saying they don't want to USE the option. But no arguments why there could not be such an option. And I'm not the only one that would welcome such an option. Is there no room for a compromise? Bloat. If I were the maintainer, I'd point you to aliases. If Git itself can't do it, tossing a dozen shell lines into git's libexec would do the job. git diff-index --quiet is your friend. signature.asc Description: OpenPGP digital signature
Bug#568455: fetchmail, TLS/SSL with Exchange 2007 results in Autorization failures
This pretty much looks like a pilot error on either end of your link. I can successfully authenticate via GSSAPI (w/ Kerberos V under the hood) to a Cyrus server. It's also documented that fetchmail will try passwordless authentication schemes before exposing the password. Try configuring kerberos properly (krb5.conf or krb5.ini according to site instructions) and running kinit before running fetchmail. If that works, it's a problem on your end. If you can successfully obtain a ticket-granting ticket with kinit, but it's not good for authentication, contact the staff that sees to your Exchange server. I propose to close this bug as it's not a fetchmail bug. (If it can later be proven to be, you can reopen it.) -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576430: fetchmail: Doesn't load all ssl algorhitms
Sjoerd, Nico, I filed an OpenSSL issue, and Stephen Henson replied: It is only needed if certificates use algorithms other than the mandatory ones for general SSL/TLS use. This hasn't been an issue in the past but more and more certificates are starting to appear using the SHA2 algorithms. -- http://rt.openssl.org/Ticket/Display.html?id=2224 - see http://openssl.org/support/rt.html for access credentials. So perhaps that explains why it has gone unnoticed all the time - if certificates only used the mandatory algorithms, it simply wasn't needed. -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576717: fetchmail: interface option don't work
Confirmed - a regression in 6.3.15 (and -beta3). Sorry. Will be fixed in 6.3.16 shortly. -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576430: [pkg-fetchmail-maint] Bug#576430: fetchmail: Doesn't load all ssl algorhitms
Am 04.04.2010, 17:39 Uhr, schrieb Sjoerd Simons: Package: fetchmail Version: 6.3.15-1 Severity: important Tags: patch As the subject says, during openssl initialisation fetchmail doesn't seem to load all ssl algorithms causing the ssl negotiation to fail depending on what the server wants to use.. ssl(3) doesn't state that this OpenSSL_add_all_algorithms() is needed. Neither does SSL_connect or SSL_library_init. The only EVP reference is EVP_md5() explicitly, which doesn't need OpenSSL_add_all_algorithms() either. So could you: 1. please demonstrate an actual failure case 2. tell me how I as programmer should/could have known this in advance? I'm really annoyed that so much ssl lore needs to be retrofitted over time whenever there appears to be some new failure. ssl(3) states I need to run SSL_library_init and seed the RNG on machines without /dev/*random. Nothing about OpenSSL_add_all_algorithms(). If the OpenSSL documentation is so incomplete, I may have to switch the SSL library inside stable versions to avoid such issues. Thank you. -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
