Bug 282413

Comment 1 Matthias Andree 2024-10-30 01:38:06 UTC

Oh, and given the stance of the license authors, OpenSSL 3 now being under the Apache License v2, which is incompatible with the GPL v2, we need to invoke the "or any later version" on the fetchmail sources, so effectively fetchmail 6.5.0 will now be under GPL v3.

If someone found that objectionable they could then add wolfSSL support because the latter can be GPLv2 licensed so fetchmail linking to wolfSSL would also be distributable under the older GPLv2 "or any later version" terms, too.

So proposed additional change is to change LICENSE=GPLv2+ to GPLv3+ for the package because we use OpenSSL. Strictly speaking we don't need that on FreeBSD 13 which has OpenSSL 1.1.x and fetchmail parts have a relevant exemption when linking against - namely - *OpenSSL* (but not other packages using the OpenSSL license, so we don't have an exception to link our GPLv2+ parts to LibreSSL and the latter is out as I read it unless part of the OS (I only know OpenBSD ships LibreSSL as part of the system)).

Comment 2 Matthias Andree 2024-10-30 07:56:26 UTC

...or can we leave that as GPLv2 because we still do have the OpenSSL linking exception (which wasn't limited to particular OpenSSL versions) so we can continue with GPLv2+ as long as we link against OpenSSL, or a GPLv2-compatible SSL library (wolfSSL itself is GPLv2 licensed but not part of our port)?

As for the license, if it's possible to leave it as GPLv2 because of the linking exception then I think that would be preferable. Fewer surprises for users that way. The reasoning you outline for why that should be acceptable seems sound to me.

As for poudriere tests, mail/fetchmail passes 'poudriere testport' on both amd64 and i386 under 14.1 and 13.4 for the following configurations:
  - Default settings 
  - ssl=base, GSSAPI_MIT
  - ssl=base, GSSAPI_NONE
  - ssl=openssl
  - ssl=openssl with SSL2 and SSL3 disabled
  - ssl=openssl, GSSAPI_NONE

mail/fetchmailconf passes 'poudriere testport' on both amd64 and i386 under 14.1 and 13.4 with default settings


Unfortunately, there are build failures when using the wolfSSL port:

./tls-aux.h:22:5: error: "wolfSSL was compiled without -DOPENSSL_COMPATIBLE_DEFAULTS. Recompile and reinstall wolfSSL!"

From what I can tell, the wolfSSL port doesn't provide a way to rebuild with that option. But maybe it should?

Comment 4 Matthias Andree 2024-10-30 20:36:28 UTC

Uh, thanks for sharing the wolfSSL finding. 

Looks like an oversight, in two ways:

- I can work around the missing openssl compatible defaults with SSL_CTX_set_mode(SSL_MODE_AUTO_RETRY). We use that since 6.4.25, but the compile-time check is in a different file, and when I merged that into the 6.5 branch, I forgot to manually remove the run-time check from tls-aux.h.

- The HAVE_EX_DATA stuff that results in ./tls-aux.h:25:5: error: "wolfSSL was configured without --enable-context-extra-user-data. Recompile and reinstall wolfSSL!" is checked here but I would consider this a mis-merge from the "next" branch that is to spawn fetchmail 7.0 later, X509_STORE_CTX_get_ex_data and thereabouts, 6.5 does not use that but sticks to the file-global variables fetchmail has used for ages.

Bottom line: both checks will be removed upstream and I will add a patch to kill them for our 6.5.0 port, too, but we need wolfSSL to provide the other in the future when fetchmail 7.0 materializes, so I have filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282430 to ask about adding that compile-time option so we have it by the time we will need it.

Thanks for the review, I'll fix these tls-aux.h errors and commit.

Comment 5 commit-hook 2024-10-30 20:56:15 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=205eb9b92486da1ce7495c8ce4cbd4b66f5e4a8b

commit 205eb9b92486da1ce7495c8ce4cbd4b66f5e4a8b
Author:     Matthias Andree <mandree@FreeBSD.org>
AuthorDate: 2024-10-30 00:18:40 +0000
Commit:     Matthias Andree <mandree@FreeBSD.org>
CommitDate: 2024-10-30 20:55:35 +0000

    mail/fetchmail*: update to 6.5.0

    Improve upon the prior opie handling and use the port on FreeBSD 14.
    For the FreeBSD 13 base OpenSSL 1.x version, allow it by patching
    socket.c, and also simplify the EVP_MD* API update check which will go
    upstream.

    PR:             282413
    Approved by:    Corey Halpin <chalpin@cs.wisc.edu> (maintainer)

 mail/fetchmail/Makefile                            |  13 +-
 mail/fetchmail/distinfo                            |   6 +-
 ...87626c2707cc0d82e49e160ab3c85430ff33534f (gone) | 160 ---------------------
 mail/fetchmail/files/patch-socket.c (new)          |  24 ++++
 mail/fetchmail/files/patch-tls-aux.h (new)         |  18 +++
 mail/fetchmail/pkg-plist                           |  16 ---
 mail/fetchmailconf/Makefile                        |   2 +-
 7 files changed, 53 insertions(+), 186 deletions(-)

Comment 6 Matthias Andree 2024-10-30 21:09:37 UTC

One remark on a compiler warning:

socket.c:1351:71: warning: flag '#' results in undefined behavior with 'p' conversion specifier [-Wformat]
 1351 |                         report(stderr, GT_("fetchmail: sock %d: wolfSSL_check_domain_name(%#p, \"%s\") returned %d, trying to continue\n"),
      |                                                                                           ~^~
./i18n.h:8:24: note: expanded from macro 'GT_'
    8 | #define GT_(s) gettext(s)
      |                        ^
1 warning generated.


While the compiler is right that %#p is UB per the standards, we are still safe on all currently supported FreeBSD versions 13.3, 13.4, 14.1 (and currently also what man.freebsd.org serves for 15-CURRENT), printf(3) documents that it shall ignore # on a p conversion (this wording is FreeBSD specific and an extension to the standard, but non-portable):

       •   Zero	or more	of the following flags:

	   `#'		The  value should be converted to an "alternate	form".
			For c, d, i, n,	p, s, and u conversions,  this	option
			has  no	 effect.  [...]

Upstream already has a fix that goes without changing translations, see https://gitlab.com/fetchmail/fetchmail/-/commit/0b9cc022e48f2b5631fb6d6fb0e9421e7d0159f5