headers
Russ Allbery | 2 Jul 2005 09:58
Picon
Favicon
Gravatar

INN snapshots working again

INN snapshots should be working again.  You can get them as before from:

    <ftp://ftp.isc.org/isc/inn/snapshots/≥

or from:

    <http://inn.eyrie.org/snapshots/>

Different than before, the source tree is compiled (with make warnings for
CURRENT) and run through make test and make check-manifest, and no new
snapshot is generated if any of those things fail.  Instead, I'm notified
in e-mail so that I can go fix it.

I'm going to be working on more infrastructure stuff this weekend, as well
as going back to doing more work on INN 2.4, now that I'm back from
travelling and have some time to do other things.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
Permalink | Reply | 0 comments |
headers
Chris Caputo | 2 Jul 2005 16:32

PATCH: inn-2.4.2:art.c:ARTxrefslave() bug causes ARTpost() segfault

Repro:

   0) xrefslave be true
   1) active file reload (such as by startup or newgroup message)
   2) multi-group cancel control message received prior to any other
      multi-group message with a higher number of groups.

Crash due to segmentation fault at 2.4.2's art.c line 2296:

     ngp->PostCount = 0;

I believe fix to ARTxrefslave() is as follows.

Thanks,
Chris

--- inn-2.4.2-stock/innd/art.c  2004-12-22 04:21:19.000000000 +0000
+++ inn-2.4.2/innd/art.c        2005-07-02 14:25:32.000000000 +0000
 <at>  <at>  -1525,6 +1525,7  <at>  <at>  ARTxrefslave(ARTDATA *data)
      GroupPointers[i++] = ngp;
      nogroup = false;
    }
+  GroupPointers[i] = NULL;
    if (nogroup)
      return false;
    return true;
Permalink | Reply | 1 comment |
headers
Russ Allbery | 3 Jul 2005 01:46
Picon
Favicon
Gravatar

Re: PATCH: inn-2.4.2:art.c:ARTxrefslave() bug causes ARTpost() segfault

Chris Caputo <ccaputo <at> alt.net> writes:

> Repro:

>    0) xrefslave be true
>    1) active file reload (such as by startup or newgroup message)
>    2) multi-group cancel control message received prior to any other
>       multi-group message with a higher number of groups.

> Crash due to segmentation fault at 2.4.2's art.c line 2296:

>      ngp->PostCount = 0;

> I believe fix to ARTxrefslave() is as follows.

Thanks, applied.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
Permalink | Reply | 0 comments |
headers
Russ Allbery | 3 Jul 2005 03:09
Picon
Favicon
Gravatar

Re: gnupg & pgpverify trouble

Christoph Biedl <cbiedl <at> gmx.de> writes:
> Russ Allbery wrote...

>>   * pgpverify will now correctly verify signatures generated by GnuPG and
>>     better supports GnuPG as the PGP implementation.

> Upgrading my system (Debian sarge) I and others found pgpverify fails if
> using gpg for verification of signed control messages. The reason for
> this is appearently gpg which now looks for ~/.gnupg/trustedkeys.gpg
> instead of ~/.gnupg/pubring.gpg. However, gpg was not changed so I
> assume a different gpgv invocation in the new pgpverify version.

> Copying or linking the two key files is at least a workaround, but: Has
> this been documented anywhere?

I've released a new upstream version of pgpverify that falls back on
pubring.gpg if trustedkeys.gpg is empty or non-existent.  This isn't the
ideal behavior, but given the situation and the backward compatibility
concerns, I think it makes the most sense.

This will be in the next release of INN.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
Permalink | Reply | 0 comments |
headers
Russ Allbery | 3 Jul 2005 03:17
Picon
Favicon
Gravatar

Re: Idea: Add a way to use pgp/gpg keyid in control.ctl

Sebastian Wiesinger <inn <at> tracker.fire-world.de> writes:

> Today I discovered a glitch with pgpverify. The control key for the at.*
> hierarchie has the uid:

> pub  1024R/AE548CCD 1997-04-10 austrian usenet coordinator <control <at> usenet.backbone.at>

> which, when parsed with pgpverify, will return different uids after
> parsing:

> When using pgp, pgpverify returns control <at> usenet.backbone.at as uid.

> When using gpg, pgpverify return austrian as uid.

> Because of this, the default control.ctl wouldn't recognize a valid
> at.* control when checked with gpg.

Yeah, there is some discussion of this problem at:

    <http://www.eyrie.org/~eagle/faqs/usenet-hier.html#S3>

Basically, you don't want any UIDs on Usenet control message signing keys
other than simple e-mail addresses or they won't work at a lot of sites.

> This led to another thought: If someone made a key with the same uid as
> a key in the control.ctl file and uploads that key to the keyservers, it
> could be possible that some users download the wrong key from the
> keyserver when they search for the uid, and in the worst case could
> automatically execute faked controls.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 3 Jul 2005 04:25
Picon
Favicon
Gravatar

Re: 2.4.2 issue still (ctlinnd and "message too long")

To recap, this is the problem where ctlinnd name and some similar commands
fail because the data that innd is sending back to ctlinnd is too long and
it gets EMSGSIZE.  I'm sorry for how long it too me to take a closer look
at this; I've been really distracted by other things.

I'm afraid I don't have good news, though.

Tuc <tuc <at> ttsg.com> writes:

> news.err:Jan  1 03:38:26 hermod innd: SERVER cant sendto CCreader bytes 2676 Message too long
> news.err:Jan  1 13:32:56 hermod innd: SERVER cant sendto CCreader bytes 7 Connection refused
> news.err:Jan  1 13:50:38 hermod innd: SERVER cant sendto CCreader bytes 2552 Message too long
> news.err:Jan  1 15:10:32 hermod innd: SERVER cant sendto CCreader bytes 2749 Message too long
> news.notice:Jan  1 03:38:26 hermod innd: SERVER cant sendto CCreader bytes 2676 Message too long
> news.notice:Jan  1 13:32:56 hermod innd: SERVER cant sendto CCreader bytes 7 Connection refused
> news.notice:Jan  1 13:50:38 hermod innd: SERVER cant sendto CCreader bytes 2552 Message too long
> news.notice:Jan  1 15:10:32 hermod innd: SERVER cant sendto CCreader bytes 2749 Message too long

I wrote a little test program to try sending a packet over a Unix datagram
socket.  The test program is included below.  I ran it on:

    Debian GNU/Linux (2.4 kernel)
    Solaris 8
    IRIX 6.5
    Tru64 4.0F
    AIX 5.2
    FreeBSD 5.4

All of them handled 8KB packet sizes without any trouble except for Tru64
and FreeBSD, which can't handle a byte over 2KB.  So I'm afraid that INN
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russ Allbery | 3 Jul 2005 06:32
Picon
Favicon
Gravatar

Re: Possible reason for "rnews: cant unspool"?

Paul Marques Mota <mota <at> april.org> writes:
> On Mon, Jun 06, 2005 at 11:08:53PM -0700, Russ Allbery wrote:
>> Felix E Klee <felix.klee <at> inka.de> writes:
>> > Paul Marques Mota wrote:
>> 
>> >> You missed news.notice:
>> 
>> >> Apr  7 22:32:29 genba rnews: unknown_reply after article 400 loadav
>> >> [innwatch:load] 1977 gt 1500

> Raising the severity of this message in the rnews code so that it ends
> up in news.crit or news.err, and then in the nighly report would be a
> nice work-around for now...

>> > I still wonder what is the origin of the problem.  Surely load was high,
>> > but that's no reason for messages to end up in "incoming/bad".
>> 
>> rnews really should just defer the articles if INN is throttled, but
>> right now it doesn't have a great way to do that.  I wonder if rnews
>> should try to query the local control socket to get INN's status before
>> trying to post messages, at least in -U mode.

I studied this some more and realized that the rnews code had all the
pieces required to handle this properly and just wasn't.  I've now
committed a patch that will leave articles in the incoming directory if
unspooling them fails due to a deferral or a 400 error, rather than
shunting them off into the bad directory.  I managed to convince myself
that that's the right thing to do.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 4 Jul 2005 01:49
Picon
Favicon
Gravatar

Re: Possible bugs in rnews (inn 2.4.1)

Russ Allbery <rra <at> stanford.edu> writes:

> I think rnews needs to be studied a little for nul handling; it looks
> like at least the wire format conversion doesn't work properly when the
> article contains a nul character.  I haven't made any more fixes to this
> at the moment, though.

This should now be fixed.

>> 2) rnews stops processing the newsbatch when it gets to an article that
>>    does have an empty Subject (/^Subject: $/). It logs the message
>>    "rnews: bad_article missing Subject", but then doesn't process the
>>    rest of the newsbatch.

> I'm a little confused how this is supposed to work.  rnews *does* have a
> way of rejecting one message and then continuing on to process the rest
> of the batch, and intentionally doesn't use it for this case.  I'm not
> sure why that is... it seems to me that for this, and also for
> unterminated message ID headers, only the one article should be rejected
> rather than pushing aside the whole batch.

I've made this change in CURRENT and STABLE.

> It really shouldn't be putting it in bad either; it looks like rnews -U
> behaves slightly differently than regular rnews, which is odd.

This has also now been fixed.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 4 Jul 2005 23:08
Picon
Favicon
Gravatar

Re: innfeed 'discover' and wish list

Todd Olson <tco2 <at> cornell.edu> writes:

> 2) changing the bindaddress and SIGHUP-ing innfeed does NOT cause
> innfeed to switch interfaces.  The only way to switch interfaces seems
> to be to stop and restart innfeed.  The innfeed man page seems to claim
> the contrary
>         "If innfeed gets a SIGHUP signal, then  it  will  reread  the
>          config   file.   All  values  at  global  scope  except  for
>          ``backlog-directory'' can be  changed. [...]"

I looked over this code, and I'm pretty sure that the re-read
configuration file will indeed change the bind address for any *new*
connections.  It doesn't, however, cause existing connections to be closed
and re-opened.

> b) I wish that bindaddress worked on a per 'peer' basis because:

I've added this to TODO, but don't have the time to work on implementing
this change just at the moment.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
Permalink | Reply | 3 comments |
headers
Russ Allbery | 5 Jul 2005 02:43
Picon
Favicon
Gravatar

Re: assertion -- cxn->writeBlockedTimerId == 0 is back

Russ Allbery <rra <at> stanford.edu> writes:

> I looked at this for a little while, and I see that in various places we
> check to see if a write is pending as well as seeing if the queue is
> empty before calling cxnIdle with a comment that some hosts return
> responses before we're done sending data, but in other places we don't
> do this.

> I wonder if making this uniform so that every place where we send an
> article to a peer, we check for a pending write before marking the
> connection idle would fix this problem.  It at least appears to be a
> harmless fix.  I'm going to go ahead and make that fix and see if it
> helps.

I went back and took another comprehensive look at this, and as a result,
I applied the following patch.  Here's the commit message:

| In all of the response handlers that idle the connection if there's
| nothing left in the queue, don't idle if there are writes pending.  The
| cases where this could possibly trigger are obscure and involve the
| remote peer doing evil things, but the rest of the code handles it
| correctly and we were still seeing assertion failures, indicating that
| evil may be happening.
| 
| In issueStreamingCommands, make certain that there are no pending writes
| before idling the connection.
| 
| Add the code to ihaveBodyDone that was already in commandWriteDone to
| idle the connection if the queue is empty in case we'd had to defer the
| idle in the response handler due to an unfinished write.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane