Re: [fetchmail-devel] fetchmail 6.3.20-pre1 release candidate should fix STARTTLS hangs

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

Am 24.05.2011 17:22, schrieb Thomas Jarosch:

> On Monday, 23. May 2011 21:00:27 Matthias Andree wrote:
>> DOWNLOAD this beta software from:
>> <http://home.pages.de/~mandree/fetchmail/>
> 
> Small side note: I had trouble downloading the .tar.bz2 version,
> the tar.xz version downloaded just fine.

Hi Thomas,

just tried downloading the .tar.bz2 from a different computer, no
troubles here.  What were the symptoms of the problem?

>> # SECURITY FIXES
>> * Fetchmail's socket timeout handling was incomplete.  Network outages in
>> the wrong phase of a communication, combined with unlucky operating
>> systems and their defaults, could cause fetchmail to hang for extended
>> amounts of time. Freezes for beyond a week were reported by Thomas
>> Jarosch. Fetchmail sets UNIX- and Internet-domain socket send and
>> receive timeouts now. This fixes a hang during STARTTLS negotiation
>> reported by Thomas Jarosch.
> 
> The timeout works fine, I've tested every step of the POP3 protocol 
> communication until we triggered the bug the last time.

Thanks.

> I think I've seen a kind of unrelated bug: If you let the TLS negotation 
> time out on the "server side", fetchmail will proceed to send the user name 
> before shutting down: "USER xyz". Bug in the state machine?

Probably.  I suspect now that we get socket-level errors in a few
places, we're ferreting up such protocol bugs that used to be concealed
behind a freeze or possibly an alarm timer followed by siglongjmp.

I've now started wondering, considering Jonathan's trouble that the
setsockopt() isn't working on his kernel, if the fixes in 6.3.20-pre1
are heading the right way, or if I need to use setitimer()-based
timeouts (providing that OpenSSL doesn't mask SIGALRM), and possibly
avoid set_timeout(0) (which in itself may open up yet another can of worms).

>> # CHANGES
>> * fetchmail now supports an environment variable to suppress marking
> 
> Out of curiosity, why is this an environment variable
> instead of a configuration option?

It was sort-of experimental and is much less effort that way -- and
turned out to be non-functional.  Perhaps I should remove it (or at
least the documentation).

First-class options need changes in half a dozen places, among them the
lexer and parser (rcfile*.l and .y), the command-line parser, help
output, manual page, fetchmailconf -- whereas the environment option
just needs changes to the code in one place and to the man page.

Thanks for the test and reports.  Time to get back to the drawing board
for me.

Best regards,

-- 
Matthias Andree