Summary: | mail/fetchmail: 6.4.12 fixes regression in README and 6.4.10 regression of not finding TLS v1.2/v1.3 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Matthias Andree <mandree> | ||||||||||
Component: | Individual Port(s) | Assignee: | Matthias Andree <mandree> | ||||||||||
Status: | Closed FIXED | ||||||||||||
Severity: | Affects Only Me | CC: | chalpin | ||||||||||
Priority: | --- | Keywords: | patch-ready | ||||||||||
Version: | Latest | Flags: | chalpin:
maintainer-feedback+
mandree: merge-quarterly+ |
||||||||||
Hardware: | Any | ||||||||||||
OS: | Any | ||||||||||||
Attachments: |
|
Created attachment 217692 [details]
Revised patch for 6.4.11 update
With the previous patch, I get a size mismatch during fetch. I also note that the SHA256 in the attached doesn't match the one in the fetchmail-6.4.11 release announcement. If I regenerate distinfo via `make makesum`, the newly generated hash matches the one from the release announcement and then the fetch succeeds.
After that small tweak, reflected in the attached "revised patch", mail/fetchmail passes 'poudriere testport' on both i386 and amd64 under 11.3, 11.4, and 12.1 for the following configurations:
- Default settings
- Default settings, build as non-root
- ssl=base, GSSAPI_MIT
- ssl=base, GSSAPI_NONE
- ssl=openssl
- ssl=openssl with SSL2 and SSL3 disabled
- ssl=openssl, GSSAPI_NONE
- ssl=libressl
- ssl=libressl, GSSAPI_NONE
mail/fetchmailconf passes 'poudriere testport' on both i386 and amd64 under
11.3, 11.4, and 12.1 with default settings
I've added a 'fetchmail -V' invocation inside the script run w/in the `testport` to check where the TLS v1.3 warnings appear. I see them with OpenSSL 1.0.2s, OpenSSL 1.0.2u, and LibreSSL. AFAICT, these warning are all correct.
Corey, thanks for the distinfo remark. I have been trying to reproduce what caused this, but it appears that I've cleaned out the tarball I used for "make makesum" so cannot find the actual difference any more. In one other 6.4.11 computer in a different build directory of my Linux computer, the tarball differs in the fetchmail-FAQ.pdf (which is auto-generated apparently in a non-reproducible manner) - and the README file in the uploaded tarball (that your SHA256 matches) is broken and contains a fragment from NEWS. The tarball is also auto-generated, and I've identified the cause: my dist-tools/makerelease.pl script would write a "README" file into the output directory, which then gets picked up next time (instead of the original README from the repo). I have fixed that script and released 6.4.12. Created attachment 217735 [details]
mail/fetchmail port update to 6.4.12
This passed test builds in my poudriere for these jails:
11.3-RELEASE-p7 amd64
11.3-RELEASE-p7 i386
12.1-RELEASE 1201000 mips.mips64
12.1-RELEASE-p3 1201000 arm64.aarch64
12.1-RELEASE-p3 i386
12.1-RELEASE-p4 amd64
WRT your TLS v1.3 complaints, it is expected that OpenSSL 1.0.2* and LibreSSL are not offering TLS 1.3, but OpenSSL 1.1.1 does.
Created attachment 217736 [details]
/!\ not to apply, only to peruse - diff between 6.4.11 and 6.4.12 tarballs
(In reply to Matthias Andree from comment #3) This looks good to me, continues to pass `poudriere testport` for the list of configurations mentioned above, and is working nicely on my machines when installed. I approve the patch. Thank you! A commit references this bug: Author: mandree Date: Fri Sep 4 16:04:52 UTC 2020 New revision: 547549 URL: https://svnweb.freebsd.org/changeset/ports/547549 Log: mail/fetchmail: update to 6.4.12 (regression fixes) Fixes these regressions: - Misleading false complaints that TLSv1.3 support were missing from the system but still auto-negotiating it (broken in 6.4.9, fixed in 6.4.11). - README contained NEWS fragments (broken since c. 1 year/c. 6.4.2, fixed in 6.4.12) instead of the actual contents. (This was also the reason to skip 6.4.11). For the potential MFH 6.4.8 -> 6.4.12, 6.4.9 also adds to the manual page which has is used for fingerprints, MD5, and adds a Romanian-language translation by Florentina Musat. PR: 249009 Approved by: Corey Halpin (maintainer) MFH: 2020Q3 (manpage, README fixes, added translation) Changes: head/mail/fetchmail/Makefile head/mail/fetchmail/distinfo A commit references this bug: Author: mandree Date: Mon Sep 21 16:18:26 UTC 2020 New revision: 549455 URL: https://svnweb.freebsd.org/changeset/ports/549455 Log: MFH: r546739 r547549 mail/fetchmail: update to 6.4.12 (from 6.4.8) (Note this isn't the usual MFH changelog as that doesn't make sense in this particular case; head/ had some churn around a regression in 6.4.10 that this MFH-of-two-changeset nicely skips over.) Add: Romanian-language translation by Florentina Musat Add: manual page now mentions that --sslfingerprint hash is of MD5 type. Fix: README contained NEWS fragments (broken since c. 1 year/c. 6.4.2, fixed in 6.4.12) instead of the actual contents. Update: the > 2^31 "long long" local patch so it patches the right place of the NEWS file. PR: 248954 Approved by: Corey Halpin (maintainer) PR: 249009 Approved by: Corey Halpin (maintainer) Approved by: ports-secteam@ (fluffy@) Changes: _U branches/2020Q3/ branches/2020Q3/mail/fetchmail/Makefile branches/2020Q3/mail/fetchmail/distinfo branches/2020Q3/mail/fetchmail/files/patch-ZZZ-87626c2707cc0d82e49e160ab3c85430ff33534f branches/2020Q3/mail/fetchmail/pkg-plist branches/2020Q3/mail/fetchmailconf/Makefile |
Created attachment 217642 [details] patch to update the fetchmail port from 6.4.10 to 6.4.11 fetchmail 6.4.10's configure script causes a regression that lets it skip TLS1.2 and TLS1.3 tests if the SSL library isn't linked with -lssl, but - for instance - as /usr/lib/libssl.so as happens on FreeBSD. While - given a sufficient implementation of libssl - the _automatic_ negotiation of TLS v1.2 and v1.3 still works, fetchmail 6.4.10 prints bogus warnings about the SSL's implementation quality in some places (reproducer: fetchmail -V). 6.4.11 fixes that. Test builds succeeded in my poudriere: 11.3-i386, 11.3-amd64, 12.1-i386, 12.1-amd64, 12.1-mips64, 12.1-arm64.