fetchmail-devel — Development related discussion

Re: [fetchmail-devel] Re: quick overview of branching and tagging in SVN [was: Re: r3948 - trunk]

[Brian C. <B.C...@po...>]

On Fri, Nov 12, 2004 at 01:56:01PM -0600, Graham Wilson wrote:
> > Can you slide a tag if you need to?
> 
> What do you mean?

I mean you tag a particular version of a file ready for a release, and then
at the last minute change your mind, squeeze in a change, and move the
release tag to the modified file.

FreeBSD do it occasionally just before they make a release :-)

[fetchmail-devel] Re: quick overview of branching and tagging in SVN [was: Re: r3948 - trunk]

[Graham W. <gr...@mk...>]

On Fri, Nov 12, 2004 at 07:40:53PM +0000, Brian Candler wrote:
> On Fri, Nov 12, 2004 at 12:12:37PM -0600, Graham Wilson wrote:
> >   $ scp https://decoy.wox.org/svn/fetchmail/trunk \
> >         https://decoy.wox.org/svn/fetchmail/branches/debian \
> >         -m "Create a Debian branch of fetchmail."
> 
> OT, but does Subversion really have a command 'scp'? That would conflict
> with the ubiquitous scp from ssh.

No. I just mistype `svn cp' as `scp' pretty often.

> > Tagging is done the same way as branching, except you copy to the tags
> > directory, not the branhes directory, and you never checkin anything on
> > a tag.
> 
> Can you slide a tag if you need to?

What do you mean?

-- 
gram

Re: [fetchmail-devel] quick overview of branching and tagging in SVN [was: Re: r3948 - trunk]

[Brian C. <B.C...@po...>]

On Fri, Nov 12, 2004 at 12:12:37PM -0600, Graham Wilson wrote:
>   $ scp https://decoy.wox.org/svn/fetchmail/trunk \
>         https://decoy.wox.org/svn/fetchmail/branches/debian \
>         -m "Create a Debian branch of fetchmail."

OT, but does Subversion really have a command 'scp'? That would conflict
with the ubiquitous scp from ssh.

> Tagging is done the same way as branching, except you copy to the tags
> directory, not the branhes directory, and you never checkin anything on
> a tag.

Can you slide a tag if you need to?

Regards,

Brian.

[fetchmail-devel] Re: r4000 - trunk

[Graham W. <gr...@mk...>]

On Fri, Nov 12, 2004 at 12:13:09PM -0600, Graham Wilson wrote:
> On Wed, Nov 10, 2004 at 02:38:11PM -0600, sv...@de... wrote:
> [...]
> 
> Why did you switch to strcat (which doesn't check bounds) instead of
> snprintf? I would think we should just change that sprintf call to
> snprintf.
> 
> [...]
> 
> These should be changed to snprintf as well I assume?

Alright, I see now that these things shouldn't ever overflow, so I guess
it is a moot point whether to use snprintf or not.

-- 
gram

[fetchmail-devel] Re: r4000 - trunk

[Graham W. <gr...@mk...>]

On Wed, Nov 10, 2004 at 02:38:11PM -0600, sv...@de... wrote:
> Modified: trunk/lock.c
> ===================================================================
> --- trunk/lock.c	2004-11-10 20:14:18 UTC (rev 3999)
> +++ trunk/lock.c	2004-11-10 20:38:06 UTC (rev 4000)
> @@ -32,7 +32,9 @@
>      if (getuid() == ROOT_UID) {
>  	lockfile = (char *)xmalloc(
>  		sizeof(PID_DIR) + sizeof(FETCHMAIL_PIDFILE) + 1);
> -	sprintf(lockfile, "%s/%s", PID_DIR, FETCHMAIL_PIDFILE);
> +	strcpy(lockfile, PID_DIR);
> +	strcat(lockfile, "/");
> +	strcat(lockfile, FETCHMAIL_PIDFILE);
>      } else {
>  	lockfile = (char *)xmalloc(strlen(fmhome)+sizeof(FETCHMAIL_PIDFILE)+2);
>  	strcpy(lockfile, fmhome);

Why did you switch to strcat (which doesn't check bounds) instead of
snprintf? I would think we should just change that sprintf call to
snprintf.

> Modified: trunk/unmime.c
> ===================================================================
> --- trunk/unmime.c	2004-11-10 20:14:18 UTC (rev 3999)
> +++ trunk/unmime.c	2004-11-10 20:38:06 UTC (rev 4000)
> @@ -669,9 +669,9 @@
>    char fnam[100];
>  
>    pid = getpid();
> -  sprintf(fnam, "/tmp/i_unmime.%x", pid);
> +  sprintf(fnam, "/tmp/i_unmime.%lx", (long)pid);
>    fd_orig = fopen(fnam, "w");
> -  sprintf(fnam, "/tmp/o_unmime.%x", pid);
> +  sprintf(fnam, "/tmp/o_unmime.%lx", (long)pid);
>    fd_conv = fopen(fnam, "w");
>  #endif

These should be changed to snprintf as well I assume?

-- 
gram

[fetchmail-devel] quick overview of branching and tagging in SVN [was: Re: r3948 - trunk]

[Graham W. <gr...@mk...>]

On Sun, Oct 24, 2004 at 01:38:34PM +0200, Matthias Andree wrote:
> OK, I will figure how to branch and merge in Subversion and to that next
> time for "sweeping" changes that aren't self-contained in a single
> patch-set. It's only that I am not particularly fond of branches as most
> of my development efforts are still CVS-based, and CVS's branch handling
> is known to be inferior to SVN.

Branching and tagging is done by the same operation in Subversion. For
example, if I wanted to create Debian branch for fetchmail, I could do
the following (this doesn't modify your working copy):

  $ scp https://decoy.wox.org/svn/fetchmail/trunk \
        https://decoy.wox.org/svn/fetchmail/branches/debian \
        -m "Create a Debian branch of fetchmail."

You can then switch your working copy of fetchmail to the Debian branch
by doing the following:

  $ cd /path/to/my/wc
  $ svn switch https://decoy.wox.org/svn/fetchmail/branches/debian

Switching back to the trunk is just as easy:

  $ cd /path/to/my/wc
  $ svn switch https://decoy.wox.org/svn/fetchmail/branches/debian

To see what branch your working on current, use the info subcommand in
the toplevel of your of your working copy:

  $ pwd
  /path/to/my/wc
  $ svn info
  Path: .
  URL: https://decoy.wox.org/svn/fetchmail/trunk
  Repository UUID: 6bd12b38-53dc-0310-98db-d94f1ca4f90c
  Revision: 4001
  Node Kind: directory
  Schedule: normal
  Last Changed Author: m-a
  Last Changed Rev: 4001
  Last Changed Date: 2004-11-10 16:57:00 -0600 (Wed, 10 Nov 2004)
  Properties Last Updated: 2004-08-08 03:22:17 -0500 (Sun, 08 Aug 2004)

You can make checkins on a branch the same way you would on the trunk,
as long as the info subcommand shows the branch, not the trunk.

Tagging is done the same way as branching, except you copy to the tags
directory, not the branhes directory, and you never checkin anything on
a tag.

The other important operation besides branching is merging. To merge the
changes from the branch (make sure you are on the trunk, and not a
branch):

  $ cd /path/to/my/wc
  $ svn merge https://decoy.wox.org/svn/fetchmail/trunk \
              https://decoy.wox.org/svn/fetchmail/branches/debian

(Note that this wouldn't make sense for the Debian branch, but this is
just an example.)

Check the output for any lines that start with C, which means that there
was a conflict in the merge. Open the file, and search for the conflict
markers, and resolve the conflict. Then do:

  $ svn resolved conflict.c

Then you have to checkin the merged changes the same way you would
normally checkin changes.

To see what would be merged before doing the merge operation:

  $ svn diff https://decoy.wox.org/svn/fetchmail/trunk \
             https://decoy.wox.org/svn/fetchmail/branches/debian

The diff and merge subcommands are pretty similar, except the diff
subcommand outputs the differences, while the merge subcommands applies
them to your working copy.

I'd be happy to answer any questions anyone has (assuming I can, of
course :).

-- 
gram

[fetchmail-devel] Re: r3995 - trunk

[Graham W. <gr...@mk...>]

On Wed, Nov 10, 2004 at 09:14:37PM +0100, Matthias Andree wrote:
> Graham Wilson <gr...@mk...> writes:
> > What is this and why do we need it?
> 
> This is the best GPL-compatible snprintf/sscanf replacement (including
> varargs variants) that I've been able to find as a separate project.

Why do we want it as a separate project?

> The idea is to get rid of insecure and ugly coding practices such as
> using [v]sprintf or strcat on older systems that lack [v]snprintf, and
> the way we'd seen this integrated in the code was messy:
> 
> [...]

I agree that it is a good idea to get rid of sprintf throughout the
code. Thanks for spearheading the effort.

> I'm not fixed on Trio, if you know something better, we can flush Trio
> and use something else,

I would have gone with a single file implementation of snprintf instead
of using the whole Trio. I don't see why we need to add 54 files when we
could just add one. For example, mutt is known to have a good snprintf
implmentation.

What would you think about using that?

> but I'm not willing to allow the ugly old structure back in.

Agreed.

-- 
gram

Re: [fetchmail-devel] Re: r3995 - trunk

[Matthias A. <ma...@dt...>]

Graham Wilson <gr...@mk...> writes:

> On Wed, Nov 10, 2004 at 01:04:34PM -0600, sv...@de... wrote:
>> Added:
>>    trunk/trio/
>> Log:
>> Import Trio 1.10 into fetchmail's trunk.
>
> What is this and why do we need it?

This is the best GPL-compatible snprintf/sscanf replacement (including
varargs variants) that I've been able to find as a separate project.

The idea is to get rid of insecure and ugly coding practices such as
using [v]sprintf or strcat on older systems that lack [v]snprintf, and
the way we'd seen this integrated in the code was messy:

#ifdef HAVE_SNPRINTF
  snprintf(buf, sizeof buf,     /* safer */
#else
  sprintf(buf,                  /* unsafe */
#endif
     rest, of, arguments);

The diffstat looks like this:

 Makefile.am    |   18 ++++++++++++--
 configure.ac   |   52 ++++++++++++++++++++++++++++++++++++++++
 cram.c         |    4 ---
 driver.c       |   30 +++--------------------
 fetchmail.h    |    5 +++
 imap.c         |    6 ----
 interface.c    |    7 -----
 ipv6-connect.c |   23 +++--------------
 report.c       |   46 -----------------------------------
 sink.c         |   59 +++++-----------------------------------------
 smtp.c         |   34 ++++----------------------
 socket.c       |   15 -----------
 transact.c     |   73 ++++-----------------------------------------------------
 13 files changed, 103 insertions(+), 269 deletions(-)

Not counting the first two files, we are now down by over 200 lines of
half-baked C code.

I'm not fixed on Trio, if you know something better, we can flush Trio
and use something else, but I'm not willing to allow the ugly old
structure back in.

-- 
Matthias Andree

Re: [fetchmail-devel] Re: r3993 - in vendor: . sourceforge sourceforge/trio sourceforge/trio/current sourceforge/trio/current/doc sourceforge/trio/current/html

[Matthias A. <ma...@dt...>]

Graham Wilson <gr...@mk...> writes:

>>    vendor/sourceforge/trio/current/libtrio.a
>> [...]
>> Added: vendor/sourceforge/trio/current/libtrio.a
>> ===================================================================
>> (Binary files differ)
>> 
>> 
>> Property changes on: vendor/sourceforge/trio/current/libtrio.a
>> ___________________________________________________________________
>> Name: svn:mime-type
>>    + application/octet-stream
>
> Are you sure that we want this?

I am sure we don't, this was committed by accident.
Removed now.

-- 
Matthias Andree

[fetchmail-devel] Re: r3993 - in vendor: . sourceforge sourceforge/trio sourceforge/trio/current sourceforge/trio/current/doc sourceforge/trio/current/html

[Graham W. <gr...@mk...>]

On Wed, Nov 10, 2004 at 12:58:22PM -0600, sv...@de... wrote:
> Author: m-a
> Date: 2004-11-10 12:58:13 -0600 (Wed, 10 Nov 2004)
> New Revision: 3993
> [...]
>    vendor/sourceforge/trio/current/libtrio.a
> [...]
> Added: vendor/sourceforge/trio/current/libtrio.a
> ===================================================================
> (Binary files differ)
> 
> 
> Property changes on: vendor/sourceforge/trio/current/libtrio.a
> ___________________________________________________________________
> Name: svn:mime-type
>    + application/octet-stream

Are you sure that we want this?

-- 
gram

[fetchmail-devel] Re: r3995 - trunk

[Graham W. <gr...@mk...>]

On Wed, Nov 10, 2004 at 01:04:34PM -0600, sv...@de... wrote:
> Added:
>    trunk/trio/
> Log:
> Import Trio 1.10 into fetchmail's trunk.

What is this and why do we need it?

-- 
gram

Re: [fetchmail-devel] Assorted minor bugs

[Matthias A. <ma...@dt...>]

Brian Candler <B.C...@po...> writes:

>> A second step (longer-term than the next release), i. e. after the next
>> official release, should then make strict checking the default and offer
>> the user options to relax checking for the case when the configuration
>> (client or server) cannot be fixed on short notice.
>
> I agree, except that if you specify an explicit fingerprint that should also
> make the certificate checking non-strict.

Right. We aren't currently doing that as I can see:

$ LANG=C fetchmail -d0 --sslcertck --sslcertpath /dev/null -v \
  --sslfingerprint 99:A9:55:D9:F5:51:F9:40:CC:A4:C6:26:A2:8E:46:14 XXXXXXX

fetchmail: 6.2.6 querying XXXXXXX (protocol POP3) at Wed Nov 10 01:41:02 2004: poll started
fetchmail: Issuer Organization: YYYYY
fetchmail: Issuer CommonName: Matthias Andree
fetchmail: Server CommonName: XXXXXXX
fetchmail: XXXXXXX key fingerprint: 99:A9:55:D9:F5:51:F9:40:CC:A4:C6:26:A2:8E:46:14
fetchmail: XXXXXXX fingerprints match.
fetchmail: Server certificate verification error: unable to get local issuer certificate
12402:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:842:
fetchmail: SSL connection failed.

> That is, if you *know* the public key of the end-point you're talking to,
> then you don't care if it has been signed or by whom or when. With
> --sslfingerprint you're effectively using the ssh model, rather than the ssl
> model, for preventing man-in-the-middle attacks.

Yup.

-- 
Matthias Andree

Re: [fetchmail-devel] Assorted minor bugs

[Matthias A. <ma...@dt...>]

Brian Candler <B.C...@po...> writes:

> I've fixed this by not displaying the same error message twice in
> succession. I've also used the _depth0ck variable to make sure that the
> once-off checking of CN and fingerprint really is done only once.

Thanks a lot, your patch will be part of fetchmail 6.2.6. I tested it,
found it worked for me and then merged it. While I was at it, I found
that --sslfingerprint and --sslcertpath were missing from --help and
added that.

-- 
Matthias Andree

[fetchmail-devel] Re: Log timestamp patch

[Graham W. <gr...@mk...>]

On Tue, Nov 09, 2004 at 07:01:31AM -0600, Paul Keusemann wrote:
> Here's a patch to add configurable log timestamping.  I found this
> very helpful in debugging problems with the IDLE feature a while
> back.

I think it probably makes more sense to add this as a run time option,
and to wait until 6.2.6 is out the door. I'll try to post an updated
patch, and see about applying it once we release.

-- 
gram

[fetchmail-devel] Log timestamp patch

[Paul K. <pk...@ho...>]

Here's a patch to add configurable log timestamping.  I found this
very helpful in debugging problems with the IDLE feature a while
back.

This patch is against fetchmail 6.2.5.
-- 
Paul Keusemann
Senior Continuation Engineer
Jacada, Inc.
4266 Joppa Court
Savage, MN 55378
952-882-6396
www.jacada.com

Re: [fetchmail-devel] Assorted minor bugs

[Brian C. <B.C...@po...>]

> A second step (longer-term than the next release), i. e. after the next
> official release, should then make strict checking the default and offer
> the user options to relax checking for the case when the configuration
> (client or server) cannot be fixed on short notice.

I agree, except that if you specify an explicit fingerprint that should also
make the certificate checking non-strict.

That is, if you *know* the public key of the end-point you're talking to,
then you don't care if it has been signed or by whom or when. With
--sslfingerprint you're effectively using the ssh model, rather than the ssl
model, for preventing man-in-the-middle attacks.

Regards,

Brian.

Re: [fetchmail-devel] Assorted minor bugs

[Brian C. <B.C...@po...>]

> May I ask you to come up with a small patch that fixes _all_ violations
> of the trust model in a first round, so that we _unconditionally_ print
> all warnings, self-signed certificates, common name mismatches and so
> on. These _are_ important warnings, if they are shown only in verbose
> mode, that is a serious bug.

OK, that turns out to be pretty straightforward.

Note that when sslcertck is not set, our verify callback always returns 1
(OK) even if it given 0 (verify error). That's necessary to stop the SSL
connection being dropped, but it can result in the callback being called
multiple times, and and the same SSL error being displayed more than once.
For example, before fixing this, with a self-signed certificate I got:

fetchmail: Server certificate verification error: self signed certificate
fetchmail: Server certificate verification error: self signed certificate

I've fixed this by not displaying the same error message twice in
succession. I've also used the _depth0ck variable to make sure that the
once-off checking of CN and fingerprint really is done only once.

fetchmail -v still displays additional information from the certificate, as
it did before, but all errors should now be displayed even without -v.

Regards,

Brian.

Re: [fetchmail-devel] Assorted minor bugs

[Matthias A. <ma...@dt...>]

Brian Candler <B.C...@po...> writes:

> There's some more detailled output at
> http://lists.ccil.org/pipermail/fetchmail-friends/2004-April/008516.html
>
> Basically, each verify callback operation causes this warning to be shown,
> and with fetchmail -v you get this in addition to the other verification
> warning associated with that callback. So with fetchmail -v I get (snipped a
> little):
>
> fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
> fetchmail: Warning: server certificate verification: unable to get local issuer certificate
> fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
> fetchmail: Warning: server certificate verification: certificate not trusted
> fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
> fetchmail: Warning: server certificate verification: unable to verify the first certificate
>
> That's with 6.2.5, I've not tried your snapshot yet.
>
> Now, if I run fetchmail without -v, then the intervening verification errors
> are not shown, so I just see the CN mismatch errors three times. Perhaps you
> only see them once because you have root certs installed in the correct
> places, or maybe it's a difference in our versions of openssl.
>
>> Anyways, I would not want to limit this warning to verbose
>> or strict mode or similar, it's an important information and needs to be
>> printed unconditionally.
>
> Well, I disagree that this information is any more important than
> "certificate not trusted" or "unable to verify signature" or the various
> other errors that only fetchmail -v or fetchmail sslcertck will show.
>
> In particular: fetchmail (without -v) will not generate any warning for a
> self-signed certificate where the CN is correct. However, if you have a
> valid signed certificate from a known CA, but the hostname does not match,
> you get the warning (three times in my case).
>
> Both are violations of the SSL trust model. In the latter case, you know
> that the server admin did at least manage to persuade a known and trusted CA
> to sign a certificate, albeit for a different hostname. Whereas, in the
> first case you could be the subject of a man-in-the-middle attack, and you
> get no warning at all.
>
> That's why my preferred solution was to silence this message without -v or
> sslcertck: because more serious messages are already silenced.

I see you have some understanding of the SSL certificate/trust model and
verification process.

May I ask you to come up with a small patch that fixes _all_ violations
of the trust model in a first round, so that we _unconditionally_ print
all warnings, self-signed certificates, common name mismatches and so
on. These _are_ important warnings, if they are shown only in verbose
mode, that is a serious bug. For this first round, all problems should
always print a warning regardless of verbosity or logging
settings. sslcertck should make any validation failure an error that
aborts the connection to that server and skips to the next.

A second step (longer-term than the next release), i. e. after the next
official release, should then make strict checking the default and offer
the user options to relax checking for the case when the configuration
(client or server) cannot be fixed on short notice.

The whole point of SSL is avoiding the credentials to be revealed to
anything but the "real" server, and lax checks that do not prevent MITM
attacks defeat the whole purpose of SSL. I'd think creating a false
sense of security is worse than not offering security.

-- 
Matthias Andree

Re: [fetchmail-devel] Assorted minor bugs

[Brian C. <B.C...@po...>]

> *Shrug* I don't see how it's printed three times. It's printed once on
> my computer.

There's some more detailled output at
http://lists.ccil.org/pipermail/fetchmail-friends/2004-April/008516.html

Basically, each verify callback operation causes this warning to be shown,
and with fetchmail -v you get this in addition to the other verification
warning associated with that callback. So with fetchmail -v I get (snipped a
little):

fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
fetchmail: Warning: server certificate verification: unable to get local issuer certificate
fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
fetchmail: Warning: server certificate verification: certificate not trusted
fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
fetchmail: Warning: server certificate verification: unable to verify the first certificate

That's with 6.2.5, I've not tried your snapshot yet.

Now, if I run fetchmail without -v, then the intervening verification errors
are not shown, so I just see the CN mismatch errors three times. Perhaps you
only see them once because you have root certs installed in the correct
places, or maybe it's a difference in our versions of openssl.

> Anyways, I would not want to limit this warning to verbose
> or strict mode or similar, it's an important information and needs to be
> printed unconditionally.

Well, I disagree that this information is any more important than
"certificate not trusted" or "unable to verify signature" or the various
other errors that only fetchmail -v or fetchmail sslcertck will show.

In particular: fetchmail (without -v) will not generate any warning for a
self-signed certificate where the CN is correct. However, if you have a
valid signed certificate from a known CA, but the hostname does not match,
you get the warning (three times in my case).

Both are violations of the SSL trust model. In the latter case, you know
that the server admin did at least manage to persuade a known and trusted CA
to sign a certificate, albeit for a different hostname. Whereas, in the
first case you could be the subject of a man-in-the-middle attack, and you
get no warning at all.

That's why my preferred solution was to silence this message without -v or
sslcertck: because more serious messages are already silenced.

Regards,

Brian.

Re: [fetchmail-devel] Assorted minor bugs

[Matthias A. <ma...@dt...>]

Brian Candler <B.C...@po...> writes:

> On Mon, Nov 08, 2004 at 01:01:31AM +0100, Matthias Andree wrote:
>> Can you try the tarball from
>> http://home.pages.de/~mandree/tmp/fetchmail-6.2.6.tar.bz2
>
> Thanks for making this interim release.

It's a snapshot, not a release. I deliberately let a tarball escape...

> The bugs were described more fully on fetchmail-friends, but in summary:
>
> (1) There is a completely unnecessary sleep(3) after logging in. I cannot
> see any justification for this; the comment in the code talks about mailbox
> locking and tempfiles, but when the POP3 server has replied "+OK" to a
> login, then it is by its own admission locked and ready to receive commands.
>
> I am guessing this was a workaround for some ancient and broken server, but
> I think it should be removed as it just wastes time and resources.

We'll see what happens. I've removed the sleep for now, it's been
annoying myself for years so much I patched it away, with no ill effect
on common servers.

> (2a) When talking to an SSL server, where the certificate name does not
> match, then annoyingly a 'certificate name mismatch' error is given three
> times. The patch changes it so that this warning is only given if you select
> verbose or sslcertck, to be the same as the other certificate
> warnings/errors.

*Shrug* I don't see how it's printed three times. It's printed once on
my computer. Anyways, I would not want to limit this warning to verbose
or strict mode or similar, it's an important information and needs to be
printed unconditionally. If it annoys the user, tough luck, fix the
configuration or let him complain to the server's admin.

> (2b) When talking to an SSL server, honour the sslcertpath option even if
> sslcertck is not set (currently it is ignored); this allows you to use
> fetchmail -v to get useful information on the certificate chain, even if
> it's not being strictly enforced using sslcertck.

Merged.

> (3) There is a bug where 'showdots' fails to work if there are two 'poll'
> entries in .fetchmailrc; I spent a while chasing this down, and it turns out
> to be an option parsing bug. Full description here:
> http://lists.ccil.org/pipermail/fetchmail-friends/2004-April/008518.html

Merged. Thanks for your efforts in analyzing and fixing this.

Thank you!

-- 
Matthias Andree

[fetchmail-devel] Assorted minor bugs

[Brian C. <B.C...@po...>]

On Mon, Nov 08, 2004 at 01:01:31AM +0100, Matthias Andree wrote:
> Can you try the tarball from
> http://home.pages.de/~mandree/tmp/fetchmail-6.2.6.tar.bz2

Thanks for making this interim release.

I reported some problems with 6.2.5 and posted patches to the old
fetchmail-friends list in April, but none appear to have been incorporated
into 6.2.6. The small patchset I keep is attached, and still applies cleanly
to 6.2.6.

The bugs were described more fully on fetchmail-friends, but in summary:

(1) There is a completely unnecessary sleep(3) after logging in. I cannot
see any justification for this; the comment in the code talks about mailbox
locking and tempfiles, but when the POP3 server has replied "+OK" to a
login, then it is by its own admission locked and ready to receive commands.

I am guessing this was a workaround for some ancient and broken server, but
I think it should be removed as it just wastes time and resources.

(2a) When talking to an SSL server, where the certificate name does not
match, then annoyingly a 'certificate name mismatch' error is given three
times. The patch changes it so that this warning is only given if you select
verbose or sslcertck, to be the same as the other certificate
warnings/errors.

(2b) When talking to an SSL server, honour the sslcertpath option even if
sslcertck is not set (currently it is ignored); this allows you to use
fetchmail -v to get useful information on the certificate chain, even if
it's not being strictly enforced using sslcertck.

(3) There is a bug where 'showdots' fails to work if there are two 'poll'
entries in .fetchmailrc; I spent a while chasing this down, and it turns out
to be an option parsing bug. Full description here:
http://lists.ccil.org/pipermail/fetchmail-friends/2004-April/008518.html

This URL also contains separately the patches which are combined in the
attached bundle.

You might want to change my fix for (1) though: instead of #ifdef BOLLOCKS
then just remove the sleep and the (incorrect) comment associated with it
:-)

Regards,

Brian.

Re: [fetchmail-devel] [BUG] fetchmail hangs during pop3 pull after a mail with a null char

[Matthias A. <ma...@dt...>]

David Greaves <da...@dg...> writes:

> Summary : fetchmail hangs during pop3 pull after a mail with a null
> char.

Can you try the tarball from
http://home.pages.de/~mandree/tmp/fetchmail-6.2.6.tar.bz2 and see if the
problem persists? There have been several bugfixes since 6.2.5, the
noteworthy documented at http://decoy.wox.org/svn/fetchmail/trunk/NEWS -
just to make sure we aren't chasing a bug that's already fixed?

NOTE the tarball there isn't the final 6.2.6 release tarball but a
preliminary snapshot and may see further changes before being released
as 6.2.6.

Thanks in advance.

-- 
Matthias Andree

[fetchmail-devel] warning message charset fix: progress indicator 3/3

[Matthias A. <ma...@dt...>]

Matthias Andree <ma...@dt...> writes:

>> 3/3. figure if nl_langinfo(CODESET) always specifies IANA-conformant
>>      character sets or if we need to map these and possibly quench the
>>      translation for those that aren't OK'd by IANA.
>>      Reference: http://www.iana.org/assignments/character-sets
>
> Still open.

Fixed now.

-- 
Matthias Andree

Re: [fetchmail-devel] issues pending before 6.2.6 -- IANA vs. UNIX character/coding set

[David G. <da...@dg...>]

Since you ask :)

I submitted a bug report on 13/10/04:
[fetchmail-devel] [BUG] fetchmail hangs during pop3 pull after a mail 
with a null char
(I assume you'll have a copy - yell if I should resend it)

I'd previously submitted it to fetchmail-friends where Rob MacGregor 
suggested I send it here.

This problem is still occuring and I now have expunge 1 all the time :(

I'd like to help fix it if I could.

David


Matthias Andree wrote:

>Greetings!
>
>What is our current TODO list WRT a 6.2.6 release other than
>
>1. potentially mapping local character sets onto IANA character sets for
>warning mails that we send out [*]
>
>2. Rob setting up and running the regression tests?
>
>It seems there hasn't been a fetchmail release in over a year now, and
>I'd think it's about time that we get 6.2.6 out, even if not all pending
>issues are fixed, as long as the pending issues aren't avoidable or
>easily fixable regressions since 6.2.0 or 6.2.5.
>
>[*] I'll probably just copy in
>http://www.cl.cam.ac.uk/~mgk25/ucs/langinfo.c
>http://www.cl.cam.ac.uk/~mgk25/ucs/norm_charmap.c
>
>Further reading:
>http://mail-index.netbsd.org/tech-userlevel/2003/01/24/0006.html
>http://mail.nl.linux.org/linux-utf8/2000-05/msg00041.html
>http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/registry?rev=HEAD&root=xorg
>
>  
>

[fetchmail-devel] issues pending before 6.2.6 -- IANA vs. UNIX character/coding set

[Matthias A. <ma...@dt...>]

Greetings!

What is our current TODO list WRT a 6.2.6 release other than

1. potentially mapping local character sets onto IANA character sets for
warning mails that we send out [*]

2. Rob setting up and running the regression tests?

It seems there hasn't been a fetchmail release in over a year now, and
I'd think it's about time that we get 6.2.6 out, even if not all pending
issues are fixed, as long as the pending issues aren't avoidable or
easily fixable regressions since 6.2.0 or 6.2.5.

[*] I'll probably just copy in
http://www.cl.cam.ac.uk/~mgk25/ucs/langinfo.c
http://www.cl.cam.ac.uk/~mgk25/ucs/norm_charmap.c

Further reading:
http://mail-index.netbsd.org/tech-userlevel/2003/01/24/0006.html
http://mail.nl.linux.org/linux-utf8/2000-05/msg00041.html
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/registry?rev=HEAD&root=xorg

-- 
Matthias Andree