GNU logs - #72456, boring messages

Message sent to philipk@HIDDEN, bug-gnu-emacs@HIDDEN:

Subject: bug#72456: [PATCH] rcirc: Fix startup channels triggering flood protection
Resent-From: Thuna <thuna.cing@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: philipk@HIDDEN, bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 04 Aug 2024 00:01:02 +0000
Resent-Message-ID: <handler.72456.B.172272964926641 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 72456 <at> debbugs.gnu.org
Cc: philipk@HIDDEN
From: Thuna <thuna.cing@HIDDEN>
Date: Sun, 04 Aug 2024 02:00:11 +0200
Message-ID: <87y15dkvhw.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=2a00:1450:4864:20::435;
 envelope-from=thuna.cing@HIDDEN; helo=mail-wr1-x435.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--=-=-=
Content-Type: text/plain

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.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
 filename=0001-WIP-rcirc-fix-startup-channels-flooding-the-server.patch
Content-Description: text/x-patch

From 9c205cfe46679f17f5e8cf8b4c2999e50eb97adb Mon Sep 17 00:00:00 2001
From: Thuna <thuna.cing@HIDDEN>
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 '(?~ ?& ?@ ?% ?+)
-- 
2.44.2


--=-=-=--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Thuna <thuna.cing@HIDDEN>
Subject: bug#72456: Acknowledgement ([PATCH] rcirc: Fix startup channels
 triggering flood protection)
Message-ID: <handler.72456.B.172272964926641.ack <at> debbugs.gnu.org>
References: <87y15dkvhw.fsf@HIDDEN>
X-Gnu-PR-Message: ack 72456
X-Gnu-PR-Package: emacs
X-Gnu-PR-Keywords: patch
Reply-To: 72456 <at> debbugs.gnu.org
Date: Sun, 04 Aug 2024 00:01:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  philipk@HIDDEN
(after having been given a bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 72456 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
72456: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D72456
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72456: [PATCH] rcirc: Fix startup channels triggering flood protection
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 04 Aug 2024 14:57:02 +0000
Resent-Message-ID: <handler.72456.B72456.17227833908791 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Thuna <thuna.cing@HIDDEN>
Cc: 72456 <at> debbugs.gnu.org
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87y15dkvhw.fsf@HIDDEN> (Thuna's message of "Sun, 04 Aug 2024
 02:00:11 +0200")
References: <87y15dkvhw.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; keydata=
 mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI
 BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0
 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB
 BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE
 Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK
 NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof
 z4oM
OpenPGP: id=philipk@HIDDEN;
 url="https://keys.openpgp.org/vks/v1/by-email/philipk@HIDDEN";
 preference=signencrypt
Date: Sun, 04 Aug 2024 14:55:58 +0000
Message-ID: <877ccwz69t.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Thuna <thuna.cing@HIDDEN> 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@HIDDEN>
> 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

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72456: [PATCH] rcirc: Fix startup channels triggering flood protection
Resent-From: Thuna <thuna.cing@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 06 Aug 2024 18:26:01 +0000
Resent-Message-ID: <handler.72456.B72456.172296872522989 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Philip Kaludercic <philipk@HIDDEN>
Cc: 72456 <at> debbugs.gnu.org
From: Thuna <thuna.cing@HIDDEN>
In-Reply-To: <877ccwz69t.fsf@HIDDEN>
References: <87y15dkvhw.fsf@HIDDEN> <877ccwz69t.fsf@HIDDEN>
Date: Tue, 06 Aug 2024 20:23:49 +0200
Message-ID: <87wmkty0ga.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

>> 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.

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

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