fetchmail-devel — Development related discussion

Re: [Fetchmail-devel] set sha1 fingerprint checking correctly on fetchmail

[Matthias A. <mat...@gm...>]

Am 03.10.2017 um 15:42 schrieb Globe Trotter via Fetchmail-devel:
> Hi, 
>
> My mail service provider gmx.com recently appears to have changed their fingerprint to SHA1 (I am guessing) as a result of which my fetchmail has stopped working.

No. Fetchmail 6.3.26 will use MD5 fingerprints no matter what.

> Here is the fingerprint I get:
> $openssl s_client -connect pop.gmx.com:995 | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint
You're asking OpenSSL for the SHA1 fingerprint, but you need the MD5
fingerprint, as specified in fetchmail's manual page, and that's what
you get in the "mismatch" reporting. Given that you can only specify one
fingerprint, for big sites such as GMX it's /currently/  (in fetchmail
6.3.X) better to use --sslcertck and rely on certificate checking. You
need to install the root certificate though, most distributions have a
package such as ca-certificates, nss_root_ca, or similar, and it should
Just Work™.

Also see README.SSL as shipped with fetchmail.

[Fetchmail-devel] set sha1 fingerprint checking correctly on fetchmail

[Globe T. <its...@ya...>]

Hi, 

My mail service provider gmx.com recently appears to have changed their fingerprint to SHA1 (I am guessing) as a result of which my fetchmail has stopped working.
Here is the fingerprint I get:
$openssl s_client -connect pop.gmx.com:995 | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G3
verify return:1
depth=0 C = DE, ST = Rhineland-Palatinate, L = Montabaur, O = 1&1 Mail & Media GmbH, CN = pop.gmx.com
verify return:1
SHA1 Fingerprint=4D:69:52:FB:5F:18:34:5E:02:E2:7D:B5:95:B8:BD:3E:E1:8F:FD:F8



So, I set the following in my .fetchmailrc

sslfingerprint "4D:69:52:FB:5F:18:34:5E:02:E2:7D:B5:95:B8:BD:3E:E1:8F:FD:F8"

but I get the following:
$fetchmail -cv
fetchmail: --check mode enabled, not fetching mail
fetchmail: 6.3.26 querying pop.gmx.com (protocol POP3) at Mon 02 Oct 2017 11:24:50 PM CDT: poll started
Trying to connect to 212.227.17.171/995...connected.
fetchmail: Server certificate:
fetchmail: Issuer Organization: GeoTrust Inc.
fetchmail: Issuer CommonName: GeoTrust SSL CA - G3
fetchmail: Subject CommonName: pop.gmx.com
fetchmail: Subject Alternative Name: pop.gmx.com
fetchmail: pop.gmx.com key fingerprint: 6F:3E:88:EF:14:35:2C:69:7A:22:03:C8:2B:90:B3:8C
fetchmail: pop.gmx.com fingerprints do not match!
fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from gt...@gm...@pop.gmx.com
fetchmail: 6.3.26 querying pop.gmx.com (protocol POP3) at Mon 02 Oct 2017 11:24:50 PM CDT: poll completed

The fingerprint is quite different from the fingerprint that is reported (and included in my .fetchmailrc). 

What am I doing wrong?
Many thanks for any help!

Re: [Fetchmail-devel] Imap idle and SIGUSR1

[Matthias A. <mat...@gm...>]

Am 07.03.2017 um 14:33 schrieb Jef Driesen:
> Hi,
>
> I have a fetchmailrc to poll a single imap server, with the "idle" 
> option enabled for instant notifications. This works really great, 
> except that once in a while, the server appears to get confused. It 
> still responds to the idle command as it should:
>
> fetchmail: IMAP> A0117 IDLE
> fetchmail: IMAP< + idling
> fetchmail: IMAP> DONE
> fetchmail: IMAP< A0117 OK IDLE completed
> fetchmail: IMAP> A0118 IDLE
> fetchmail: IMAP< + idling
> fetchmail: IMAP> DONE
> fetchmail: IMAP< A0118 OK IDLE completed
>
> But for some reason it doesn't notice new mail has arrived. This is 
> probably a server side bug, for which I'm trying to find a workaround.

There is none in fetchmail.

> I tried to send SIGUSR1 to wakeup the fetchmail daemon. But that doesn't 
> seem to have any effect. It looks like fetchmail ignores the signal 
> while it's waiting on idle. Is that intentional? I would expect it to 
> end the idle, and start a new poll.

SIGUSR1 is set to SIG_IGN all the time, except when fetchmail is
sleeping at the end of a poll and waiting for the daemon sleeping
interval to expire before the next poll. There might be a nasty
interaction around EINTR pseudo-failures to system calls while signals
are delivered in the IDLE mode, because we already have a SIGALRM-based
path for read timeouts (in case the system doesn't figure the connection
has gone down).

> How can I force fetchmail to start over, other than restarting the 
> daemon completely?

Currently you can't, sorry. IDLE is fraught with limitations and
"cannot"s and whatnot, and it appears that upstream servers also have
their quirks judging from your observation. Short of reviewing,
redesigning and rewriting considerable parts of fetchmail's concept and
implementation, that cannot easily be fixed, and I wonder if other IMAP
extensions might be more useful.

[Fetchmail-devel] Imap idle and SIGUSR1

[Jef D. <jef...@ho...>]

Hi,

I have a fetchmailrc to poll a single imap server, with the "idle" 
option enabled for instant notifications. This works really great, 
except that once in a while, the server appears to get confused. It 
still responds to the idle command as it should:

fetchmail: IMAP> A0117 IDLE
fetchmail: IMAP< + idling
fetchmail: IMAP> DONE
fetchmail: IMAP< A0117 OK IDLE completed
fetchmail: IMAP> A0118 IDLE
fetchmail: IMAP< + idling
fetchmail: IMAP> DONE
fetchmail: IMAP< A0118 OK IDLE completed

But for some reason it doesn't notice new mail has arrived. This is 
probably a server side bug, for which I'm trying to find a workaround.

I tried to send SIGUSR1 to wakeup the fetchmail daemon. But that doesn't 
seem to have any effect. It looks like fetchmail ignores the signal 
while it's waiting on idle. Is that intentional? I would expect it to 
end the idle, and start a new poll.

How can I force fetchmail to start over, other than restarting the 
daemon completely?

Jef

[Fetchmail-devel] fetchmail 6.4.0-beta2 released - please test

[Matthias A. <mat...@gm...>]

[Attempt to re-send, this time with intact signature. I hope.]

Greetings,

I have just released fetchmail 6.4.0-beta2, and can be
downloaded from
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

Important changes:
- SSL code reworked a bit with support for newer TLS protocols, more
options for --sslproto, and some decoupling of the SSL protocol version
versus if a service is SSL-wrapped (--ssl option) or uses STARTTLS
(default).
- SSLv2 dropped, SSLv3 deprecated and not negotiated by default.
- Compatibility improved with newer OpenSSL releases, and - albeit
unsupported - LibreSSL.
- --sslcertck is now default.
- Optimized UIDL handling in POP3 configurations with --keep and servers
supporting the UIDL command. I meant to ship this only with fetchmail
7.0.x but there is no point in holding it back.
- .tar.bz2 is no longer created, the .tar.xz is much smaller and xz is
now mature and widely available.

Important non-changes:
- except where deprecated protocol versions are in use, the
configuration file and data files (.fetchids, .fetchmail.pid) should be
compatible with recent 6.3.X releases.

Future directions:
I intend to release fetchmail 6.4.0 formally in a few weeks, and abandon
the fetchmail 6.3.X branch (legacy_63). There are no features, and I
intend to keep the 6.4.X branch (legacy_64) only for important bug
fixes, features are merged onto the master branch that should end up as
fetchmail 7.0 some day.

The SSL changes in particular need thorough testing and possibly a bit
more documentation.
Let me know what you'll find. I am looking forward to your beta test
findings.

Happy fetching!

Matthias

[Fetchmail-devel] fetchmail 6.4.0-beta2 released - please test

[Matthias A. <mat...@gm...>]

Greetings,

I have just released fetchmail 6.4.0-beta2, and can be
downloaded from
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

Important changes:
- SSL code reworked a bit with support for newer TLS protocols, more
options for --sslproto, and some decoupling of the SSL protocol version
versus if a service is SSL-wrapped (--ssl option) or uses STARTTLS
(default).
- SSLv2 dropped, SSLv3 deprecated and not negotiated by default.
- Compatibility improved with newer OpenSSL releases, and - albeit
unsupported - LibreSSL.
- --sslcertck is now default.
- Optimized UIDL handling in POP3 configurations with --keep and servers
supporting the UIDL command. I meant to ship this only with fetchmail
7.0.x but there is no point in holding it back.
- .tar.bz2 is no longer created, the .tar.xz is much smaller and xz is
now mature and widely available.

Important non-changes:
- except where deprecated protocol versions are in use, the
configuration file and data files (.fetchids, .fetchmail.pid) should be
compatible with recent 6.3.X releases.

Future directions:
I intend to release fetchmail 6.4.0 formally in a few weeks, and abandon
the fetchmail 6.3.X branch (legacy_63). There are no features, and I
intend to keep the 6.4.X branch (legacy_64) only for important bug
fixes, features are merged onto the master branch that should end up as
fetchmail 7.0 some day.

The SSL changes in particular need thorough testing and possibly a bit
more documentation.
Let me know what you'll find. I am looking forward to your beta test
findings.

Happy fetching!

Matthias

Re: [Fetchmail-devel] logging Message-Id header from fetched messages?

[Norman R. <nr...@cs...>]

 > True enough - and Message-Id isn't a mandatory header in E-Mail per
 > RFC-5322

Agreed.  RFC-5322 says,

   Though listed as optional in the table in section 3.6, every
   message SHOULD have a "Message-ID:" field.  

This recommendation is the next level down from SHALL or MUST, and
it's still pretty strong.

> - what do we log if it's missing?

If it's missing, I think the right thing to log is the From: and Date:
fields, which are mandated.  Such a log should include an indication
that these fields are logged in lieu of a missing Message-Id:.


Norman

Re: [Fetchmail-devel] logging Message-Id header from fetched messages?

[Matthias A. <mat...@gm...>]

Am 21.09.2016 um 23:27 schrieb Norman Ramsey:
> In an attempt to diagnose some problems with mail delivery,
> I looked to my logs to see what messages fetchmail had fetched.
> Fetchmail does not appear to log the incoming Message-Id header,
> even with debugging turned up (fetchmail -vvv).
Hi Norman,

True enough - and Message-Id isn't a mandatory header in E-Mail per
RFC-5322 - what do we log if it's missing?

Other than that, your message is sufficient as a feature requests,
thanks for sharing the idea and taking the time to writing it up so clearly.

Best,
Matthias

[Fetchmail-devel] logging Message-Id header from fetched messages?

[<nr...@cs...>]

In an attempt to diagnose some problems with mail delivery,
I looked to my logs to see what messages fetchmail had fetched.
Fetchmail does not appear to log the incoming Message-Id header,
even with debugging turned up (fetchmail -vvv).

Running
   env LC_ALL=C fetchmail -V -v --nodetach --nosyslog 
as recommended in the FAQ turns up the information that
  Idfile is /home/nr/.fetchids
but this file does not exist.
I am running fetchmail from the command line, as myself, so the
directory should be writable.

I am running a fetchmail built from the git repository whose latest
commit is

  commit 5aaa3cec988329f11d27911aa3994f4776139c0b
  Author: Matthias Andree <mat...@gm...>
  Date:   Wed Jul 27 22:31:28 2016 +0200

      Document use of address literals for SMTP.


After consulting the FAQ, I hope my situation is covered under

  G4. I have this idea for a neat feature. Will you add it?

I would like for fetchmail to log the Message-Id of each message fetched.
I think it would be a good default, but I am certainly willing for it
to be available through a configuration option or command-line option.

I cannot find instructions about how to proceed.  My best guess was to
subscribe to and write to fetchmail-devel.  A request for a new feature
is not a bug report, but if desired, I can gather the information
appropriate to a bug report.


Norman Ramsey

Re: [Fetchmail-devel] [PATCH] Support credential retrieval from OS X Keychain

[Matthias A. <mat...@gm...>]

Am 14.09.2016 um 15:45 schrieb Peter Griess:
> Hi Matthias,
>
> This patch is against 6.3.26. Would you prefer a patch against master
> instead? Or perhaps a pull request (not sure if GitLab supports this)?

Hi Peter,

thanks. Since this is a new feature, I'd prefer a patch against master,
but if we can make a case why this should be in 6.4.0, I'd also accept a
patch against legacy_64 in Git. Whether you send a patch here or send a
pull request through Gitlab, does not really matter to me, as long as
your mailer does not reformat the patch (spaces vs. tab or thereabouts).

Thanks again,
Matthias

Re: [Fetchmail-devel] [PATCH] Support credential retrieval from OS X Keychain

[Peter G. <pg...@gm...>]

Hi Matthias,

This patch is against 6.3.26. Would you prefer a patch against master
instead? Or perhaps a pull request (not sure if GitLab supports this)?

Peter

On Thu, Aug 25, 2016 at 3:36 AM, Peter Griess <pg...@gm...> wrote:

> - Attempt to retrieve credentials from the Mac OS X Keychain Services
>   framework based on the account name, server name, and protocol of the
>   configured query. This allows us to avoid storing passwords in the the
>   .fetchmailrc file and to take advantage of Keychain's ACL features to
>   ensure that only fetchmail and a few other select applications have
>   access to these credentials.
> - Add a new configure --with-keychain option gating this feature
> - Update fetchmail.man with description of OS X Keychain item format
>   recognizable by fetchmail and a recipe for adding a conforming item
> ---
>  configure.ac  | 10 +++++++++
>  fetchmail.c   | 70 ++++++++++++++++++++++++++++++
> +++++++++++++++++++++++++++++
>  fetchmail.man | 19 ++++++++++++++++
>  3 files changed, 99 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 5efd8d1..78d3cf7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -527,6 +527,16 @@ if test "$fm_cv_getaddrinfo" = yes ; then
>      fi
>  fi
>
> +# Optionally support credential retrieval from OS X Keychain Services
> +AC_ARG_WITH(keychain,
> +    [AS_HELP_STRING([--with-keychain],
> +            [use the Mac OS X keychain for credential storage])],
> +    [],
> +    [with_keychain=no])
> +AS_IF([test "x$with_keychain" = xyes],
> +        AC_DEFINE([HAVE_KEYCHAIN], [1], [Enable OS X Keychain
> integration])
> +    [LIBS="$LIBS -Wl,-framework -Wl,Security -Wl,-framework
> -Wl,CoreFoundation"])
> +
>  # This version of the Kerberos 4 and 5 options addresses the follwing
> issues:
>  #
>  # * Build correctly under Heimdal kerberos if it is compiled with db2 and
> diff --git a/fetchmail.c b/fetchmail.c
> index ae30f90..9535075 100644
> --- a/fetchmail.c
> +++ b/fetchmail.c
> @@ -37,6 +37,10 @@
>  #include <langinfo.h>
>  #endif
>
> +#ifdef HAVE_KEYCHAIN
> +#include <Security/Security.h>
> +#endif
> +
>  #include "fetchmail.h"
>  #include "socket.h"
>  #include "tunable.h"
> @@ -284,6 +288,9 @@ int main(int argc, char **argv)
>  #ifndef HAVE_RES_SEARCH
>         "-DNS"
>  #endif
> +#ifdef HAVE_KEYCHAIN
> +       "+KEYCHAIN"
> +#endif
>         ".\n";
>         printf(GT_("This is fetchmail release %s"), VERSION);
>         fputs(features, stdout);
> @@ -560,6 +567,69 @@ int main(int argc, char **argv)
>         }
>      }
>
> +#ifdef HAVE_KEYCHAIN
> +    /* look in the OS X keychain for remaining un-set passwords */
> +    for (ctl = querylist; ctl; ctl = ctl->next)
> +    {
> +       if (!ctl->active || NO_PASSWORD(ctl) || ctl->password
> +               || (implicitmode && ctl->server.skip))
> +       {
> +               continue;
> +       }
> +
> +       const char *host = (ctl->server.via) ?
> +               ctl->server.via :
> +               ctl->server.pollname;
> +       const SecProtocolType protocol_type =
> +               (ctl->server.protocol == P_IMAP) ? kSecProtocolTypeIMAP :
> +               (ctl->server.protocol == P_POP2) ? kSecProtocolTypePOP3 :
> +               (ctl->server.protocol == P_POP3) ? kSecProtocolTypePOP3 :
> +               (ctl->server.protocol == P_APOP) ? kSecProtocolTypePOP3 :
> +               (ctl->server.protocol == P_RPOP) ? kSecProtocolTypePOP3 :
> +               kSecProtocolTypeAny;
> +
> +       uint32_t password_len;
> +       void* password_bytes;
> +       OSStatus oss = SecKeychainFindInternetPassword(
> +               NULL,
> +               strlen(host), host, /* server */
> +               0, NULL, /* security domain */
> +               strlen(ctl->remotename), ctl->remotename, /* account name
> */
> +               0, NULL, /* path */
> +               0, /* port */
> +               protocol_type,
> +               kSecAuthenticationTypeDefault,
> +               &password_len, &password_bytes, /* password */
> +               NULL /* SecKeychainItemRef */);
> +
> +       if (oss != errSecSuccess && outlevel >= O_VERBOSE)
> +       {
> +           char errstr[512];
> +           CFStringRef cferrstr = SecCopyErrorMessageString(oss, NULL);
> +           Boolean ok = CFStringGetCString(
> +                   cferrstr,
> +                   errstr,
> +                   sizeof(errstr),
> +                   kCFStringEncodingUTF8);
> +           if (!ok)
> +           {
> +               strcpy(errstr, "Unknown; CFStringGetCString() failed");
> +           }
> +
> +           report(stderr,
> +                  "SecKeychainFindInternetPassword: %s (%d)\n",
> +                  errstr,
> +                  oss);
> +           continue;
> +       }
> +
> +       ctl->password = (char*) xmalloc(password_len + 1);
> +       memmove(ctl->password, password_bytes, password_len);
> +       ctl->password[password_len] = '\0';
> +       (void) SecKeychainItemFreeContent(NULL, password_bytes);
> +    }
> +#endif
> +
>      /* pick up interactively any passwords we need but don't have */
>      for (ctl = querylist; ctl; ctl = ctl->next)
>      {
> diff --git a/fetchmail.man b/fetchmail.man
> index 792ada2..b60238a 100644
> --- a/fetchmail.man
> +++ b/fetchmail.man
> @@ -1200,6 +1200,25 @@ password en clair) whenever the server returns
> AUTH=NTLM in its
>  capability response. Specify a user option value that looks like
>  \&'user@domain': the part to the left of the @ will be passed as the
>  username and the part to the right as the NTLM domain.
> +.PP
> +If your \fBfetchmail\fP was built with OS X Keychain support, the current
> +user's keychain will be searched for credentials. \fBfetchmail\fP looks
> for an
> +entry of type "Internet password" with the "Account" field matching the
> +username used for authentication, and the "Where" field a URI matching the
> +protocol and server name (e.g. "imap://imap.gmail.com").  It does not
> appear
> +possible to create an "Internet password" entry using the \fIKeychain
> Access\fP
> +GUI tool; one must use the \fIsecurity(1)\fP tool. Below is an example of
> using
> +this tool to set up an properly-configured entry for authenticating the
> user
> +"pgriess" to Google's IMAP server:
> +
> +    $ security add-internet-password \\
> +        -a pgriess \\
> +        -r imap \\
> +        -s imap.gmail.com \\
> +        -w <password>
> +
> +Use "-r pop3" for all POP-related \fBfetchmail\fP protocols including
> POP2,
> +APOP, etc.
>
>  .SS Secure Socket Layers (SSL) and Transport Layer Security (TLS)
>  .PP
> --
> 2.8.0-rc2
>
>

[Fetchmail-devel] [PATCH] Support credential retrieval from OS X Keychain

[Peter G. <pg...@gm...>]

- Attempt to retrieve credentials from the Mac OS X Keychain Services
  framework based on the account name, server name, and protocol of the
  configured query. This allows us to avoid storing passwords in the the
  .fetchmailrc file and to take advantage of Keychain's ACL features to
  ensure that only fetchmail and a few other select applications have
  access to these credentials.
- Add a new configure --with-keychain option gating this feature
- Update fetchmail.man with description of OS X Keychain item format
  recognizable by fetchmail and a recipe for adding a conforming item
---
 configure.ac  | 10 +++++++++
 fetchmail.c   | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 fetchmail.man | 19 ++++++++++++++++
 3 files changed, 99 insertions(+)

diff --git a/configure.ac b/configure.ac
index 5efd8d1..78d3cf7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -527,6 +527,16 @@ if test "$fm_cv_getaddrinfo" = yes ; then
     fi
 fi
 
+# Optionally support credential retrieval from OS X Keychain Services
+AC_ARG_WITH(keychain,
+    [AS_HELP_STRING([--with-keychain],
+            [use the Mac OS X keychain for credential storage])],
+    [],
+    [with_keychain=no])
+AS_IF([test "x$with_keychain" = xyes],
+        AC_DEFINE([HAVE_KEYCHAIN], [1], [Enable OS X Keychain integration])
+    [LIBS="$LIBS -Wl,-framework -Wl,Security -Wl,-framework -Wl,CoreFoundation"])
+
 # This version of the Kerberos 4 and 5 options addresses the follwing issues:
 # 
 # * Build correctly under Heimdal kerberos if it is compiled with db2 and
diff --git a/fetchmail.c b/fetchmail.c
index ae30f90..9535075 100644
--- a/fetchmail.c
+++ b/fetchmail.c
@@ -37,6 +37,10 @@
 #include <langinfo.h>
 #endif
 
+#ifdef HAVE_KEYCHAIN
+#include <Security/Security.h>
+#endif
+
 #include "fetchmail.h"
 #include "socket.h"
 #include "tunable.h"
@@ -284,6 +288,9 @@ int main(int argc, char **argv)
 #ifndef HAVE_RES_SEARCH
 	"-DNS"
 #endif
+#ifdef HAVE_KEYCHAIN
+	"+KEYCHAIN"
+#endif
 	".\n";
 	printf(GT_("This is fetchmail release %s"), VERSION);
 	fputs(features, stdout);
@@ -560,6 +567,69 @@ int main(int argc, char **argv)
 	}
     }
 
+#ifdef HAVE_KEYCHAIN
+    /* look in the OS X keychain for remaining un-set passwords */
+    for (ctl = querylist; ctl; ctl = ctl->next)
+    {
+	if (!ctl->active || NO_PASSWORD(ctl) || ctl->password
+		|| (implicitmode && ctl->server.skip))
+	{
+		continue;
+	}
+
+	const char *host = (ctl->server.via) ?
+		ctl->server.via :
+		ctl->server.pollname;
+	const SecProtocolType protocol_type =
+		(ctl->server.protocol == P_IMAP) ? kSecProtocolTypeIMAP :
+		(ctl->server.protocol == P_POP2) ? kSecProtocolTypePOP3 :
+		(ctl->server.protocol == P_POP3) ? kSecProtocolTypePOP3 :
+		(ctl->server.protocol == P_APOP) ? kSecProtocolTypePOP3 :
+		(ctl->server.protocol == P_RPOP) ? kSecProtocolTypePOP3 :
+		kSecProtocolTypeAny;
+
+	uint32_t password_len;
+	void* password_bytes;
+	OSStatus oss = SecKeychainFindInternetPassword(
+		NULL,
+		strlen(host), host, /* server */
+		0, NULL, /* security domain */
+		strlen(ctl->remotename), ctl->remotename, /* account name */
+		0, NULL, /* path */
+		0, /* port */
+		protocol_type,
+		kSecAuthenticationTypeDefault,
+		&password_len, &password_bytes, /* password */
+		NULL /* SecKeychainItemRef */);
+
+	if (oss != errSecSuccess && outlevel >= O_VERBOSE)
+	{
+	    char errstr[512];
+	    CFStringRef cferrstr = SecCopyErrorMessageString(oss, NULL);
+	    Boolean ok = CFStringGetCString(
+		    cferrstr,
+		    errstr,
+		    sizeof(errstr),
+		    kCFStringEncodingUTF8);
+	    if (!ok)
+	    {
+		strcpy(errstr, "Unknown; CFStringGetCString() failed");
+	    }
+
+	    report(stderr,
+		   "SecKeychainFindInternetPassword: %s (%d)\n",
+		   errstr,
+		   oss);
+	    continue;
+	}
+
+	ctl->password = (char*) xmalloc(password_len + 1);
+	memmove(ctl->password, password_bytes, password_len);
+	ctl->password[password_len] = '\0';
+	(void) SecKeychainItemFreeContent(NULL, password_bytes);
+    }
+#endif
+
     /* pick up interactively any passwords we need but don't have */ 
     for (ctl = querylist; ctl; ctl = ctl->next)
     {
diff --git a/fetchmail.man b/fetchmail.man
index 792ada2..b60238a 100644
--- a/fetchmail.man
+++ b/fetchmail.man
@@ -1200,6 +1200,25 @@ password en clair) whenever the server returns AUTH=NTLM in its
 capability response. Specify a user option value that looks like
 \&'user@domain': the part to the left of the @ will be passed as the
 username and the part to the right as the NTLM domain.
+.PP
+If your \fBfetchmail\fP was built with OS X Keychain support, the current
+user's keychain will be searched for credentials. \fBfetchmail\fP looks for an
+entry of type "Internet password" with the "Account" field matching the
+username used for authentication, and the "Where" field a URI matching the
+protocol and server name (e.g. "imap://imap.gmail.com").  It does not appear
+possible to create an "Internet password" entry using the \fIKeychain Access\fP
+GUI tool; one must use the \fIsecurity(1)\fP tool. Below is an example of using
+this tool to set up an properly-configured entry for authenticating the user
+"pgriess" to Google's IMAP server:
+
+    $ security add-internet-password \\
+        -a pgriess \\
+        -r imap \\
+        -s imap.gmail.com \\
+        -w <password>
+
+Use "-r pop3" for all POP-related \fBfetchmail\fP protocols including POP2,
+APOP, etc.
 
 .SS Secure Socket Layers (SSL) and Transport Layer Security (TLS)
 .PP
-- 
2.8.0-rc2

Re: [Fetchmail-devel] IMAP and UIDs

[Matthias A. <mat...@gm...>]

One more thing, it would seem that <https://tools.ietf.org/html/rfc4549>
"Synchronization Operations for Disconnected IMAP4 Clients" is a useful
reference for the disconnected use (only that we probably would not
normally have offline client uploads pending because fetchmail only
synchronizes in one direction).

Re: [Fetchmail-devel] IMAP and UIDs

[Matthias A. <mat...@gm...>]

Am 25.08.2016 um 16:20 schrieb Peter Griess:
> Nevermind about storing lists for UIDs. I had forgotten about UIDNEXT
> and ranged fetches.
>
> So I think the minimum required state for each folder is simply the
> last seen value of UIDNEXT. Given that this is quite a bit different
> than the lists of UIDs that are being tracked in fetchids, we may
> indeed want a separate file for this stuff. I suppose we could live
> alongside the existing fetchids scheme by encoding these values as a
> fake UID. In this case, the fetchids file would contain entries like
> this the following (with a POP account to start things off to show
> contrast):
>
>     pg...@po... some-pop-uid-1
>     pg...@po... some-pop-uid-94
>     [...]
>     pg...@gm... some-folder/1234567890/14
>     pg...@gm... some-folder/1234567890/17
>     [...]
>
> Peter

Hi Peter,

not sure if that particular encoding would work, or if rather the folder
part, and some IMAP marker, would need to be part of the left-hand-side.

I also wonder how widespread UIDNEXT support in server implementations is.

Given that this is for fetchmail 7.0, I'd also consider overhauling the
file format in general because it's highly redundant, yet at the same
time not very easy to maintain regarding abandoned accounts (their data
will never be removed automatically).

Cheers,
Matthias

Re: [Fetchmail-devel] IMAP and UIDs

[Peter G. <pg...@gm...>]

On Sun, Aug 28, 2016 at 2:00 PM, Matthias Andree <mat...@gm...>
wrote:

> I will also tweak TLS options at the time, and there will not be a 100%
> compatibility either.
>

Slight change of topic, but what TLS changes are planned?

Peter

Re: [Fetchmail-devel] [PATCH] Support credential retrieval from OS X Keychain

[Peter G. <pg...@gm...>]

No problem.

Is there a place in the source-tree that I should update documentation on
how to use this feature? The best that I can find is in `fetchmail.man`
under "ALTERNATE AUTHENTICATION FORMS".

Peter

On Sun, Aug 28, 2016 at 1:49 PM, Matthias Andree <mat...@gm...>
wrote:

> Am 25.08.2016 um 11:18 schrieb Peter Griess:
> > I did not include the re-generated 'configure' and related files in my
> > diff since they were very large (my local version of autotools is
> > different) and not core to the change. If you need me to, I can
> > attempt to re-generate these without such a large amount of noise but
> > I'm not sure how easy it will be to get the proper version(s)
> > installed on my system.
> Hi Peter,
>
> no need to include generated files - for the same reason, they aren't
> registered in Git. The automake/autoconf rig stuffs them into the
> tarballs when I "make dist", so that's all fine.
>
> I'll look at the actual contribution in the next few days, thanks for
> taking the time of writing and submitting the patch.
>
> Cheers,
> Matthias
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Fetchmail-devel mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-devel
>

Re: [Fetchmail-devel] IMAP and UIDs

[Matthias A. <mat...@gm...>]

Am 25.08.2016 um 15:34 schrieb Peter Griess:
> Hi,
>
> I'm thinking of taking a stab at the "Let IMAP code use UID and
> UIDVALIDITY rather than relying on flags that everyone can alter" bug
> since relying on the \Seen state is hurting my multi-client workflow.
>
> I have a few questions before I get started
>
> 1. Do we need to tackle UIDVALIDITY storage and validation as part of
> this? Since client-side handling UIDVALIDITY changes is had to do
> correctly, most (all?) IMAP servers don't do this unless they
> absolutely have to (e.g. there has been some sort of corruption in
> their underlying storage layer). If we can punt on UIDVALIDITY, we can
> store IMAP UIDs similarly to how we handle POP UIDs. Any advice here?

Looking at UIDVALIDITY and invalidating all UIDs if the UIDVALIDITY
changes is crucial.
I will not accept a patch that disregards UIDVALIDITY.
Feel free to add a "force-keep-UID-on-changed-UIDVALIDITY" option, too,
if it defaults to off, that's fine.

Note the patch should be against the master branch, as that one has
considerably faster UID database code (O(n log n) rather than O(n^2))
compared to the legacy branches.
If, on the other hand, you mean to write such code in C++ rather than C,
and it's clean enough, then I'll also be fine with that; I'd propose to
not go beyond C++11 at this time (but if there's something in C++14 you
want to use and it's well supported by 2-year old operating systems,
I'll be happy to review that, too.)

> 2. POP UIDs are alphanumeric strings. IMAP UIDs are unsigned 32-bit
> integers. In order to re-use as much of the existing idlist code as
> possible, I was thinking of storing UIDs as strings, e.g. via
> sprintf(id, "%lu", uid). Not my favorite solution but it should be
> less invasive than other ideas (e.g. making 'idlist.id' a union).
Fine with me. It's advantageous if the .fetchids file can be tweaked in
vim, if the need arises, and given the UIDs are decimal strings "on the
wire", it also seems natural so that the .fetchids data and the wire
protocol data match.
> 3. For the configuration impact of this, allowing --uidl to affect
> IMAP sessions would be the natural choice except that it may have
> unexpected consequences for users who were relying on that being a
> no-op. In this case the consequence would be that they would have an
> idfile get populated. I think this is probably okay as long as we
> preserve the existing behavior that marks fetched messages as seen. I
> think we should add a new --leave-unseen flag that allows uses to
> opt-in to marking messages as un-seen after fetching.
Since this is a new feature I am intending to release in fetchmail 7.0
(not 6.x.y) changing behaviour to "not mark seen" will be fine at that time.

I will also tweak TLS options at the time, and there will not be a 100%
compatibility either.
It'll probably better to have a more flexible way of telling fetchmail
what to pull (all being the default, and unread another) and what to
mark after retrieval for IMAP.

Regarding your other message, where you're writing:

> Nevermind about storing lists for UIDs. I had forgotten about UIDNEXT
> and ranged fetches.
>
> So I think the minimum required state for each folder is simply the
> last seen value of UIDNEXT. Given that this is quite a bit different
> than the lists of UIDs that are being tracked in fetchids, we may
> indeed want a separate file for this stuff. I suppose we could live
> alongside the existing fetchids scheme by encoding these values as a
> fake UID. In this case, the fetchids file would contain entries like
> this the following (with a POP account to start things off to show
> contrast):
>
>     pg...@po... some-pop-uid-1
>     pg...@po... some-pop-uid-94
>     [...]
>     pg...@gm... some-folder/1234567890/14
>     pg...@gm... some-folder/1234567890/17
>     [...]
I am open to adding a second file, perhaps even a per-"poll" (account)
file to get some of the login@account redundancy out.
We used to have code (patches) to that end in the late 6.2.5 and early
6.3.X days that never hit mainstream, and the development of this
feature stalled.
They're at the very bottom of
http://krusty.dt.e-technik.uni-dortmund.de/~ma/fetchmail/ in the fine
print, and are also somewhat polluted in that they contain modernization
stuff for the autotools rigging that shouldn't be in.

Re: [Fetchmail-devel] [PATCH] Support credential retrieval from OS X Keychain

[Matthias A. <mat...@gm...>]

Am 25.08.2016 um 11:18 schrieb Peter Griess:
> I did not include the re-generated 'configure' and related files in my
> diff since they were very large (my local version of autotools is
> different) and not core to the change. If you need me to, I can
> attempt to re-generate these without such a large amount of noise but
> I'm not sure how easy it will be to get the proper version(s)
> installed on my system.
Hi Peter,

no need to include generated files - for the same reason, they aren't
registered in Git. The automake/autoconf rig stuffs them into the
tarballs when I "make dist", so that's all fine.

I'll look at the actual contribution in the next few days, thanks for
taking the time of writing and submitting the patch.

Cheers,
Matthias

Re: [Fetchmail-devel] IMAP and UIDs

[Peter G. <pg...@gm...>]

Nevermind about storing lists for UIDs. I had forgotten about UIDNEXT
and ranged fetches.

So I think the minimum required state for each folder is simply the
last seen value of UIDNEXT. Given that this is quite a bit different
than the lists of UIDs that are being tracked in fetchids, we may
indeed want a separate file for this stuff. I suppose we could live
alongside the existing fetchids scheme by encoding these values as a
fake UID. In this case, the fetchids file would contain entries like
this the following (with a POP account to start things off to show
contrast):

    pg...@po... some-pop-uid-1
    pg...@po... some-pop-uid-94
    [...]
    pg...@gm... some-folder/1234567890/14
    pg...@gm... some-folder/1234567890/17
    [...]

Peter

On Thu, Aug 25, 2016 at 9:34 PM, Peter Griess <pg...@gm...> wrote:
> Hi,
>
> I'm thinking of taking a stab at the "Let IMAP code use UID and
> UIDVALIDITY rather than relying on flags that everyone can alter" bug
> since relying on the \Seen state is hurting my multi-client workflow.
>
> I have a few questions before I get started
>
> 1. Do we need to tackle UIDVALIDITY storage and validation as part of
> this? Since client-side handling UIDVALIDITY changes is had to do
> correctly, most (all?) IMAP servers don't do this unless they
> absolutely have to (e.g. there has been some sort of corruption in
> their underlying storage layer). If we can punt on UIDVALIDITY, we can
> store IMAP UIDs similarly to how we handle POP UIDs. Any advice here?
>
> 2. POP UIDs are alphanumeric strings. IMAP UIDs are unsigned 32-bit
> integers. In order to re-use as much of the existing idlist code as
> possible, I was thinking of storing UIDs as strings, e.g. via
> sprintf(id, "%lu", uid). Not my favorite solution but it should be
> less invasive than other ideas (e.g. making 'idlist.id' a union).
>
> 3. For the configuration impact of this, allowing --uidl to affect
> IMAP sessions would be the natural choice except that it may have
> unexpected consequences for users who were relying on that being a
> no-op. In this case the consequence would be that they would have an
> idfile get populated. I think this is probably okay as long as we
> preserve the existing behavior that marks fetched messages as seen. I
> think we should add a new --leave-unseen flag that allows uses to
> opt-in to marking messages as un-seen after fetching.
>
> Thanks,
> Peter

[Fetchmail-devel] IMAP and UIDs

[Peter G. <pg...@gm...>]

Hi,

I'm thinking of taking a stab at the "Let IMAP code use UID and
UIDVALIDITY rather than relying on flags that everyone can alter" bug
since relying on the \Seen state is hurting my multi-client workflow.

I have a few questions before I get started

1. Do we need to tackle UIDVALIDITY storage and validation as part of
this? Since client-side handling UIDVALIDITY changes is had to do
correctly, most (all?) IMAP servers don't do this unless they
absolutely have to (e.g. there has been some sort of corruption in
their underlying storage layer). If we can punt on UIDVALIDITY, we can
store IMAP UIDs similarly to how we handle POP UIDs. Any advice here?

2. POP UIDs are alphanumeric strings. IMAP UIDs are unsigned 32-bit
integers. In order to re-use as much of the existing idlist code as
possible, I was thinking of storing UIDs as strings, e.g. via
sprintf(id, "%lu", uid). Not my favorite solution but it should be
less invasive than other ideas (e.g. making 'idlist.id' a union).

3. For the configuration impact of this, allowing --uidl to affect
IMAP sessions would be the natural choice except that it may have
unexpected consequences for users who were relying on that being a
no-op. In this case the consequence would be that they would have an
idfile get populated. I think this is probably okay as long as we
preserve the existing behavior that marks fetched messages as seen. I
think we should add a new --leave-unseen flag that allows uses to
opt-in to marking messages as un-seen after fetching.

Thanks,
Peter

Re: [Fetchmail-devel] [PATCH] Support credential retrieval from OS X Keychain

[Peter G. <pg...@gm...>]

I did not include the re-generated 'configure' and related files in my
diff since they were very large (my local version of autotools is
different) and not core to the change. If you need me to, I can
attempt to re-generate these without such a large amount of noise but
I'm not sure how easy it will be to get the proper version(s)
installed on my system.

Thanks,
Peter

On Thu, Aug 25, 2016 at 4:36 PM, Peter Griess <pg...@gm...> wrote:
> - Attempt to retrieve credentials from the Mac OS X Keychain Services
>   framework based on the account name, server name, and protocol of the
>   configured query. This allows us to avoid storing passwords in the the
>   .fetchmailrc file and to take advantage of Keychain's ACL features to
>   ensure that only fetchmail and a few other select applications have
>   access to these credentials.
> - Add a new configure --with-keychain option gating this feature
> ---
>  configure.ac | 10 +++++++++
>  fetchmail.c  | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 80 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 5efd8d1..78d3cf7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -527,6 +527,16 @@ if test "$fm_cv_getaddrinfo" = yes ; then
>      fi
>  fi
>
> +# Optionally support credential retrieval from OS X Keychain Services
> +AC_ARG_WITH(keychain,
> +    [AS_HELP_STRING([--with-keychain],
> +            [use the Mac OS X keychain for credential storage])],
> +    [],
> +    [with_keychain=no])
> +AS_IF([test "x$with_keychain" = xyes],
> +        AC_DEFINE([HAVE_KEYCHAIN], [1], [Enable OS X Keychain integration])
> +    [LIBS="$LIBS -Wl,-framework -Wl,Security -Wl,-framework -Wl,CoreFoundation"])
> +
>  # This version of the Kerberos 4 and 5 options addresses the follwing issues:
>  #
>  # * Build correctly under Heimdal kerberos if it is compiled with db2 and
> diff --git a/fetchmail.c b/fetchmail.c
> index ae30f90..9535075 100644
> --- a/fetchmail.c
> +++ b/fetchmail.c
> @@ -37,6 +37,10 @@
>  #include <langinfo.h>
>  #endif
>
> +#ifdef HAVE_KEYCHAIN
> +#include <Security/Security.h>
> +#endif
> +
>  #include "fetchmail.h"
>  #include "socket.h"
>  #include "tunable.h"
> @@ -284,6 +288,9 @@ int main(int argc, char **argv)
>  #ifndef HAVE_RES_SEARCH
>         "-DNS"
>  #endif
> +#ifdef HAVE_KEYCHAIN
> +       "+KEYCHAIN"
> +#endif
>         ".\n";
>         printf(GT_("This is fetchmail release %s"), VERSION);
>         fputs(features, stdout);
> @@ -560,6 +567,69 @@ int main(int argc, char **argv)
>         }
>      }
>
> +#ifdef HAVE_KEYCHAIN
> +    /* look in the OS X keychain for remaining un-set passwords */
> +    for (ctl = querylist; ctl; ctl = ctl->next)
> +    {
> +       if (!ctl->active || NO_PASSWORD(ctl) || ctl->password
> +               || (implicitmode && ctl->server.skip))
> +       {
> +               continue;
> +       }
> +
> +       const char *host = (ctl->server.via) ?
> +               ctl->server.via :
> +               ctl->server.pollname;
> +       const SecProtocolType protocol_type =
> +               (ctl->server.protocol == P_IMAP) ? kSecProtocolTypeIMAP :
> +               (ctl->server.protocol == P_POP2) ? kSecProtocolTypePOP3 :
> +               (ctl->server.protocol == P_POP3) ? kSecProtocolTypePOP3 :
> +               (ctl->server.protocol == P_APOP) ? kSecProtocolTypePOP3 :
> +               (ctl->server.protocol == P_RPOP) ? kSecProtocolTypePOP3 :
> +               kSecProtocolTypeAny;
> +
> +       uint32_t password_len;
> +       void* password_bytes;
> +       OSStatus oss = SecKeychainFindInternetPassword(
> +               NULL,
> +               strlen(host), host, /* server */
> +               0, NULL, /* security domain */
> +               strlen(ctl->remotename), ctl->remotename, /* account name */
> +               0, NULL, /* path */
> +               0, /* port */
> +               protocol_type,
> +               kSecAuthenticationTypeDefault,
> +               &password_len, &password_bytes, /* password */
> +               NULL /* SecKeychainItemRef */);
> +
> +       if (oss != errSecSuccess && outlevel >= O_VERBOSE)
> +       {
> +           char errstr[512];
> +           CFStringRef cferrstr = SecCopyErrorMessageString(oss, NULL);
> +           Boolean ok = CFStringGetCString(
> +                   cferrstr,
> +                   errstr,
> +                   sizeof(errstr),
> +                   kCFStringEncodingUTF8);
> +           if (!ok)
> +           {
> +               strcpy(errstr, "Unknown; CFStringGetCString() failed");
> +           }
> +
> +           report(stderr,
> +                  "SecKeychainFindInternetPassword: %s (%d)\n",
> +                  errstr,
> +                  oss);
> +           continue;
> +       }
> +
> +       ctl->password = (char*) xmalloc(password_len + 1);
> +       memmove(ctl->password, password_bytes, password_len);
> +       ctl->password[password_len] = '\0';
> +       (void) SecKeychainItemFreeContent(NULL, password_bytes);
> +    }
> +#endif
> +
>      /* pick up interactively any passwords we need but don't have */
>      for (ctl = querylist; ctl; ctl = ctl->next)
>      {
> --
> 2.8.0-rc2
>

[Fetchmail-devel] [PATCH] Support credential retrieval from OS X Keychain

[Peter G. <pg...@gm...>]

- Attempt to retrieve credentials from the Mac OS X Keychain Services
  framework based on the account name, server name, and protocol of the
  configured query. This allows us to avoid storing passwords in the the
  .fetchmailrc file and to take advantage of Keychain's ACL features to
  ensure that only fetchmail and a few other select applications have
  access to these credentials.
- Add a new configure --with-keychain option gating this feature
---
 configure.ac | 10 +++++++++
 fetchmail.c  | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+)

diff --git a/configure.ac b/configure.ac
index 5efd8d1..78d3cf7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -527,6 +527,16 @@ if test "$fm_cv_getaddrinfo" = yes ; then
     fi
 fi
 
+# Optionally support credential retrieval from OS X Keychain Services
+AC_ARG_WITH(keychain,
+    [AS_HELP_STRING([--with-keychain],
+            [use the Mac OS X keychain for credential storage])],
+    [],
+    [with_keychain=no])
+AS_IF([test "x$with_keychain" = xyes],
+        AC_DEFINE([HAVE_KEYCHAIN], [1], [Enable OS X Keychain integration])
+    [LIBS="$LIBS -Wl,-framework -Wl,Security -Wl,-framework -Wl,CoreFoundation"])
+
 # This version of the Kerberos 4 and 5 options addresses the follwing issues:
 # 
 # * Build correctly under Heimdal kerberos if it is compiled with db2 and
diff --git a/fetchmail.c b/fetchmail.c
index ae30f90..9535075 100644
--- a/fetchmail.c
+++ b/fetchmail.c
@@ -37,6 +37,10 @@
 #include <langinfo.h>
 #endif
 
+#ifdef HAVE_KEYCHAIN
+#include <Security/Security.h>
+#endif
+
 #include "fetchmail.h"
 #include "socket.h"
 #include "tunable.h"
@@ -284,6 +288,9 @@ int main(int argc, char **argv)
 #ifndef HAVE_RES_SEARCH
 	"-DNS"
 #endif
+#ifdef HAVE_KEYCHAIN
+	"+KEYCHAIN"
+#endif
 	".\n";
 	printf(GT_("This is fetchmail release %s"), VERSION);
 	fputs(features, stdout);
@@ -560,6 +567,69 @@ int main(int argc, char **argv)
 	}
     }
 
+#ifdef HAVE_KEYCHAIN
+    /* look in the OS X keychain for remaining un-set passwords */
+    for (ctl = querylist; ctl; ctl = ctl->next)
+    {
+	if (!ctl->active || NO_PASSWORD(ctl) || ctl->password
+		|| (implicitmode && ctl->server.skip))
+	{
+		continue;
+	}
+
+	const char *host = (ctl->server.via) ?
+		ctl->server.via :
+		ctl->server.pollname;
+	const SecProtocolType protocol_type =
+		(ctl->server.protocol == P_IMAP) ? kSecProtocolTypeIMAP :
+		(ctl->server.protocol == P_POP2) ? kSecProtocolTypePOP3 :
+		(ctl->server.protocol == P_POP3) ? kSecProtocolTypePOP3 :
+		(ctl->server.protocol == P_APOP) ? kSecProtocolTypePOP3 :
+		(ctl->server.protocol == P_RPOP) ? kSecProtocolTypePOP3 :
+		kSecProtocolTypeAny;
+
+	uint32_t password_len;
+	void* password_bytes;
+	OSStatus oss = SecKeychainFindInternetPassword(
+		NULL,
+		strlen(host), host, /* server */
+		0, NULL, /* security domain */
+		strlen(ctl->remotename), ctl->remotename, /* account name */
+		0, NULL, /* path */
+		0, /* port */
+		protocol_type,
+		kSecAuthenticationTypeDefault,
+		&password_len, &password_bytes, /* password */
+		NULL /* SecKeychainItemRef */);
+
+	if (oss != errSecSuccess && outlevel >= O_VERBOSE)
+	{
+	    char errstr[512];
+	    CFStringRef cferrstr = SecCopyErrorMessageString(oss, NULL);
+	    Boolean ok = CFStringGetCString(
+		    cferrstr,
+		    errstr,
+		    sizeof(errstr),
+		    kCFStringEncodingUTF8);
+	    if (!ok)
+	    {
+		strcpy(errstr, "Unknown; CFStringGetCString() failed");
+	    }
+
+	    report(stderr,
+		   "SecKeychainFindInternetPassword: %s (%d)\n",
+		   errstr,
+		   oss);
+	    continue;
+	}
+
+	ctl->password = (char*) xmalloc(password_len + 1);
+	memmove(ctl->password, password_bytes, password_len);
+	ctl->password[password_len] = '\0';
+	(void) SecKeychainItemFreeContent(NULL, password_bytes);
+    }
+#endif
+
     /* pick up interactively any passwords we need but don't have */ 
     for (ctl = querylist; ctl; ctl = ctl->next)
     {
-- 
2.8.0-rc2

Re: [Fetchmail-devel] [PATCH 2/2] fetchmailconf.py: make fetchmailconf.py python{2, 3}-compliant

[Matthias A. <mat...@gm...>]

Am 08.06.2016 um 21:59 schrieb Samuel Martin:
> Hi Matthias,
> 
> On Wed, Jun 8, 2016 at 9:47 PM, Matthias Andree <mat...@gm...> wrote:
>> Am 08.06.2016 um 21:36 schrieb Samuel Martin:
>>> This change does:
>>> - use repr(...) instead of `...` (see [1]);
>>> - fix print call;
>>> - fix octal numbers.
>>>
>>> [1] https://docs.python.org/release/3.0.1/whatsnew/3.0.html#removed-syntax
>>>
>>> Signed-off-by: Samuel Martin <s.m...@gm...>
>>
>> Hi Samuel,
>>
>> thanks for the submission.
>>
>> Out of curiosity and due to the "from __future__ import
>> print_function()", what is the minimum Python 2.x version that this code
>> will be compatible with?  Anything older than 2.7?
> According to [1], print_function should be available since python-2.6.
> To be honest, I did check with python-2.7, but not with python-2.6
> (long gone on my machine ;-])

Just checked, Python 2.6 is no longer supported, so for legacy_64 that
change should be acceptable because it paves the way this code can run
for a while longer.  I've done away with compatibility with older
OpenSSL anyways and need TLSv1.2 capable implementations, so why stop
there...

Re: [Fetchmail-devel] [PATCH 0/2] fetchmailconf.py: cleanup and python3 compliance

[Matthias A. <mat...@gm...>]

Am 08.06.2016 um 21:36 schrieb Samuel Martin:
> Hi all,
> 
> Here is a couple of patchs fixing only python code formating in the
> fetchmailconf.py file.
> 
> After this series, fetchmailconf.py is compatible with python-2 and
> python-3.

I have applied them to the legacy_64 branch, but it doesn't seem to be
fully compatible, it still uses "hash.has_key(k)" when it should use "k
in hash", doesn't work with execfile(), doesn't know the new tkinter and
tkinter.dialog names, and other issues -- it still needs to run through
2to3.py. (Python 3.4.3 used here.)

Also, it doesn't apply to the master branch currently. Needs to be
redone there properly.

Fetchmailconf.py needs some love for the new SSL options anyways...

Re: [Fetchmail-devel] [PATCH 2/2] fetchmailconf.py: make fetchmailconf.py python{2, 3}-compliant

[Samuel M. <s.m...@gm...>]

Hi Matthias,

On Wed, Jun 8, 2016 at 9:47 PM, Matthias Andree <mat...@gm...> wrote:
> Am 08.06.2016 um 21:36 schrieb Samuel Martin:
>> This change does:
>> - use repr(...) instead of `...` (see [1]);
>> - fix print call;
>> - fix octal numbers.
>>
>> [1] https://docs.python.org/release/3.0.1/whatsnew/3.0.html#removed-syntax
>>
>> Signed-off-by: Samuel Martin <s.m...@gm...>
>
> Hi Samuel,
>
> thanks for the submission.
>
> Out of curiosity and due to the "from __future__ import
> print_function()", what is the minimum Python 2.x version that this code
> will be compatible with?  Anything older than 2.7?
According to [1], print_function should be available since python-2.6.
To be honest, I did check with python-2.7, but not with python-2.6
(long gone on my machine ;-])

>
> I have essentially purged python < 3.4 from all my work so I've
> forgotten the old stuff.
>
> This is mainly to figure out if I want to merge this on the master
> branch only, or on the legacy_64 branch as well.
I forgot to mention it, these patches have been done on top of the
legacy_64 branch.

>
> Cheers,
> Matthias

[1] https://docs.python.org/2/library/__future__.html

Regards,

-- 
Samuel