GNU bug report logs - #72456
[PATCH] rcirc: Fix startup channels triggering flood protection

Previous Next

Package: emacs;

Reported by: Thuna <thuna.cing <at> gmail.com>

Date: Sun, 4 Aug 2024 00:01:02 UTC

Severity: normal

Tags: patch

To reply to this bug, email your comments to 72456 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to philipk <at> posteo.net, bug-gnu-emacs <at> gnu.org:
bug#72456; Package emacs. (Sun, 04 Aug 2024 00:01:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thuna <thuna.cing <at> gmail.com>:
New bug report received and forwarded. Copy sent to philipk <at> posteo.net, bug-gnu-emacs <at> gnu.org. (Sun, 04 Aug 2024 00:01:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thuna <thuna.cing <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] rcirc: Fix startup channels triggering flood protection
Date: Sun, 04 Aug 2024 02:00:11 +0200
[Message part 1 (text/plain, inline)]
If too many channels are set up to be joined on startup, all of their
JOIN messages are sent at once, possibly triggering the flood protection
of the server and causing the link to be forcefully severed.  (In libera
I hit this limit with 12 channels - not a lot, all things considered.)

This patch mitigates this by sending a single JOIN message with all the
channels joined with ",".

This has a flaw, which is mentioned in the patch in a FIXME, in that if
the total length of the channels exceeds the maximum length of a message
then the message will likely split and break.  While checking for it
while joining the channel names is a possibility, it's probably better
if we split command messages more elegantly in the first place.

[0001-WIP-rcirc-fix-startup-channels-flooding-the-server.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72456; Package emacs. (Sun, 04 Aug 2024 14:57:02 GMT) Full text and rfc822 format available.

Message #8 received at 72456 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Thuna <thuna.cing <at> gmail.com>
Cc: 72456 <at> debbugs.gnu.org
Subject: Re: bug#72456: [PATCH] rcirc: Fix startup channels triggering flood
 protection
Date: Sun, 04 Aug 2024 14:55:58 +0000
Thuna <thuna.cing <at> gmail.com> writes:

> If too many channels are set up to be joined on startup, all of their
> JOIN messages are sent at once, possibly triggering the flood protection
> of the server and causing the link to be forcefully severed.  (In libera
> I hit this limit with 12 channels - not a lot, all things considered.)
>
> This patch mitigates this by sending a single JOIN message with all the
> channels joined with ",".
>
> This has a flaw, which is mentioned in the patch in a FIXME, in that if
> the total length of the channels exceeds the maximum length of a message
> then the message will likely split and break.  While checking for it
> while joining the channel names is a possibility, it's probably better
> if we split command messages more elegantly in the first place.

I think we should fix that before applying the change, as I cannot
imagine that the error message in that case will be in any way helpful.

> From 9c205cfe46679f17f5e8cf8b4c2999e50eb97adb Mon Sep 17 00:00:00 2001
> From: Thuna <thuna.cing <at> gmail.com>
> Date: Fri, 22 Mar 2024 14:58:03 +0100
> Subject: [PATCH] [WIP] rcirc fix startup channels flooding the server
>
> ---
>  lisp/net/rcirc.el | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
> index 6e71085808a..a3912ac4047 100644
> --- a/lisp/net/rcirc.el
> +++ b/lisp/net/rcirc.el
> @@ -2265,9 +2265,9 @@ rcirc-join-channels
>    "Join CHANNELS.
>  PROCESS is the process object for the current connection."
>    (save-window-excursion
> -    (dolist (channel channels)
> -      (with-rcirc-process-buffer process
> -        (rcirc-cmd-join channel process)))))
> +    (with-rcirc-process-buffer process
> +      ;; FIXME: Handle the situation where the full message is too long
> +      (rcirc-cmd-join (string-join channels ",") process))))
>  
>  ;;; nick management
>  (defvar rcirc-nick-prefix-chars '(?~ ?& ?@ ?% ?+)

-- 
	Philip Kaludercic on peregrine




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72456; Package emacs. (Tue, 06 Aug 2024 18:26:01 GMT) Full text and rfc822 format available.

Message #11 received at 72456 <at> debbugs.gnu.org (full text, mbox):

From: Thuna <thuna.cing <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 72456 <at> debbugs.gnu.org
Subject: Re: bug#72456: [PATCH] rcirc: Fix startup channels triggering flood
 protection
Date: Tue, 06 Aug 2024 20:23:49 +0200
>> This has a flaw, which is mentioned in the patch in a FIXME, in that if
>> the total length of the channels exceeds the maximum length of a message
>> then the message will likely split and break.  While checking for it
>> while joining the channel names is a possibility, it's probably better
>> if we split command messages more elegantly in the first place.
>
> I think we should fix that before applying the change, as I cannot
> imagine that the error message in that case will be in any way helpful.

Actually, oddly enough, no matter how long I made my JOIN message I was
able to send it and have it actually work.

I did a hundred channels on tilde.chat which all joined with:
  (cl-loop initially (insert "/join ")
           for i from 0 to 100
           do (insert "#"
                      (apply #'string
                             (mapcar (lambda (c) (+ c (- ?a ?0)))
                                     (append (format "%04d" i) nil)))
                      ",")
           finally (delete-char -1))
and I did a
  /join #aaaaaaaaaa,#aaaaaaaaaa,...
in libera.chat with the full message more than 3400 characters long.
They both seemed to work as you would hope.

It would be nice if you could verify that this is the case and
furthermore that this is the case in other servers as well.  If this is
something that can be relied on then we might not need to be concerned
with the total message length after all.




This bug report was last modified 314 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.