<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>124477</bug_id>
          
          <creation_ts>2006-02-28 18:10 0000</creation_ts>
          <short_desc>newly emerged fetchmail-6.2.5.2-r1 segfaults after reading .netrc</short_desc>
          <delta_ts>2006-03-01 14:54:42 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Applications</component>
          <version>2006.0</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>thompson@pobox.com</reporter>
          <assigned_to>net-mail@gentoo.org</assigned_to>
          <cc>jakub@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>thompson@pobox.com</who>
            <bug_when>2006-02-28 18:10:23 0000</bug_when>
            <thetext>I dont recall what version this replaced, but this appears to be a known
bug as revealed by googling &apos;.netrc fetchmail segfault&apos;. The problem
appears to be fetchmail trying to clear the passwords it read in .netrc
from memory before freeing it.

According to http://www.mhonarc.org/archive/html/fetchmail-friends/2006-01/msg00053.html
This bug is also present in fetchmail 6.3.2

That link also points to the patch to fix it. My temporary work around is
to rename .netrc, so it doesnt get read.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-02-28 22:33:43 0000</bug_when>
            <thetext>*** Bug 124486 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>ticho@gentoo.org</who>
            <bug_when>2006-03-01 02:44:09 0000</bug_when>
            <thetext>Thanks for heads-up! 6.3.2-r2 ebuild is in CVS now, with the mentioned patch applied. Please give it a try.

As for 6.2.* fetchmail, I&apos;m not sure if we want to support them anymore. Users are encouraged to move to 6.3.*, and (at least from my experience), it&apos;s a painless transition.

I&apos;ll have a look at fixing this in our 6.2.* fetchmail in the evening, I&apos;m heading to work now. If you (or anyone) have time, feel free to post such patch here.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-03-01 04:43:41 0000</bug_when>
            <thetext>(In reply to comment #2)
&gt; Thanks for heads-up! 6.3.2-r2 ebuild is in CVS now, with the mentioned patch
&gt; applied. Please give it a try.

It&apos;s actually -r1. Can we stabilize it on x86 and sparc (or rather the stable keywords from 6.3.2 should just have been kept, IMHO). Having a segfaulting version stable isn&apos;t good. :)

&gt; As for 6.2.* fetchmail, I&apos;m not sure if we want to support them anymore. Users
&gt; are encouraged to move to 6.3.*, and (at least from my experience), it&apos;s a
&gt; painless transition.

Indeed.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>thompson@pobox.com</who>
            <bug_when>2006-03-01 13:57:46 0000</bug_when>
            <thetext>Ok. I have tested 6.3.2-r1, and it does not segfault when reading .netrc.

But now I have to confess that I screwed up this bug report by claiming
that 6.2.4.2-r1 was segfaulting. I took that version number from cached
data, that did not reflect my current setup.

So, to review, I upgraded *from* 6.2.4.2-r1, which I have just tested
and verified working, to 6.3.2, which broke, and now 6.3.2-r1 has
fixed the situation. My thanks for your quick response on this, and I
apologise if my mistakes caused you any unneed work.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>ticho@gentoo.org</who>
            <bug_when>2006-03-01 14:54:42 0000</bug_when>
            <thetext>(In reply to comment #4)
&gt; So, to review, I upgraded *from* 6.2.4.2-r1, which I have just tested
&gt; and verified working, to 6.3.2, which broke, and now 6.3.2-r1 has
&gt; fixed the situation. My thanks for your quick response on this, and I
&gt; apologise if my mistakes caused you any unneed work.
&gt; 

No problem, Paul, I just came back from work, so I didn&apos;t investigate this for 6.2.* fetchmail yet. It&apos;s good to know that I don&apos;t have to, though. :)

I&apos;m closing this bug, thanks again for caring!</thetext>
          </long_desc>
      
    </bug>

</bugzilla>