From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Kai Tetzlaff Newsgroups: gmane.emacs.bugs Subject: bug#54154: 29.0.50; [PATCH] `sieve-manage-getscript' fails if script contains multibyte characters Date: Fri, 25 Feb 2022 17:00:36 +0100 Message-ID: <87ilt33pi3.fsf@tetzco.de> References: <87wnhj5nbk.fsf@tetzco.de> <878rtzxhnc.fsf@gnus.org> <875yp3w0pr.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11208"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 54154@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 25 18:51:37 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nNeki-0002iZ-Fk for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Feb 2022 18:51:36 +0100 Original-Received: from localhost ([::1]:37542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nNekg-0006Cl-Fx for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Feb 2022 12:51:35 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41710) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nNeMy-0003N7-3e for bug-gnu-emacs@gnu.org; Fri, 25 Feb 2022 12:27:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59741) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nNeMx-0004St-QU for bug-gnu-emacs@gnu.org; Fri, 25 Feb 2022 12:27:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nNeMx-0007VE-Oa for bug-gnu-emacs@gnu.org; Fri, 25 Feb 2022 12:27:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Kai Tetzlaff Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Feb 2022 17:27:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54154 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 54154-submit@debbugs.gnu.org id=B54154.164581001528782 (code B ref 54154); Fri, 25 Feb 2022 17:27:03 +0000 Original-Received: (at 54154) by debbugs.gnu.org; 25 Feb 2022 17:26:55 +0000 Original-Received: from localhost ([127.0.0.1]:53630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nNeMn-0007U7-HO for submit@debbugs.gnu.org; Fri, 25 Feb 2022 12:26:54 -0500 Original-Received: from mout-p-102.mailbox.org ([80.241.56.152]:45712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nNd1g-0002k1-46 for 54154@debbugs.gnu.org; Fri, 25 Feb 2022 11:01:01 -0500 Original-Received: from smtp102.mailbox.org (smtp102.mailbox.org [80.241.60.233]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4K4vdK5N1Mz9sV4; Fri, 25 Feb 2022 17:00:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tetzlaff.eu; s=20210624; t=1645804839; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MFS0aNH9Y2gV4HS794o0V2/dUOOHjpqxcDPZmgIli+c=; b=UyzA2i4c3QWsqHKtduWsiarraWWw2b/lz34MmSCzkVAEC0Mj/myG3syER59QKd+9n+1W1z zaDmAXBhWKZcUQOxb3ClUlxOWz5DnETJOskDCf+aFe+BpvO0XC5KvbcIjMfvXwi0DohOdA apMLYTSLdDQEr/KGjO4Ie26ZkoGHSjxBahr8AF59v2KHZ16rxPve233tMg/W5xI/fhSrvG W7DwFJDSieBNMu7IOI0sGah898vdyHDTB7yujjYedMFffIidA9LTt3z8v4cLPK9m25M/eb O7jtek7/+UnEmYGW8RrSQdpxh/sBHTPVxUSrTsX1OFo1MHzf0WwDnNjFkpQjVQGIuSyPOw bRWkBnbLn9hqlUW6pP7JIrWvzUHJPNyYx1yTUiveo8+Lur/33AOEVELXpfwVawooUop6N8 yQ1wkBvN9unxqKvb/mw5wQRuzSbbMiOcGkwEsFBen67wM5nzwCxqy9nHrwGf7Nu2JahOPd IJTgYqVngXXJPWq+gf6Byiwd+XPt76H+Jj62o+UDeQIhh32m9DcWZ+zJ9FMxiY DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tetzlaff.eu; s=MBO0001; t=1645804852; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MFS0aNH9Y2gV4HS794o0V2/dUOOHjpqxcDPZmgIli+c=; b=il7c/x5sqvcl0hxJsj90tFWhv2knOcAx5399E7Nn4ze/n+4ikwJ/eOp8sXsQgRQX5K+Ee3 fVl/QV5G3eLn79CkwQVwr2QkOy7pOcQFJn5Z1bfBKnwMQn9xrSpYCuSf2r8ScBCfIVSL2p PLJ7x/Hre9MS2aRMO1edjh/NgN0T+n0aCQFOwV0x36UAGkEKruQ+FHNdHK2QiHm/bkR1bj OUm6yExUnBwPTcpk8euW+reoLBuVIfCivlyV5Is+bUaLkC3k2+slAX8A1JjmXnsI2NWFXj kosDAz7oV6nqgLG2HdCIhQCLsUqg0JVf04YAPvg8hDV5lkGHHLGiHS0m9ONZCQ== In-Reply-To: <875yp3w0pr.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 25 Feb 2022 14:10:56 +0100") X-Rspamd-Queue-Id: 1D20B6C00B7 X-Spamd-Result: default: False [-6.79 / 30.00]; BAYES_HAM(-3.00)[99.99%]; NEURAL_HAM(-3.00)[-1.000]; GENERIC_REPUTATION(-0.69)[-0.68619817412468]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DKIM_SIGNED(0.00)[tetzlaff.eu:s=20210624]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2] X-Rspamd-Server: rakaposhi X-Mailman-Approved-At: Fri, 25 Feb 2022 12:26:50 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:227639 Archived-At: Lars Ingebrigtsen writes: > The mail bounced with: > > kai.tetzlaff@t-online.de > host mx03.t-online.de [194.25.134.73] > SMTP error from remote mail server after initial connection: > 554 IP=95.216.78.240 - A problem occurred. (Ask your postmaster for help or to contact tosa@rx.t-online.de to clarify.) Sorry, not sure what is happening there. Using a different From: address, now (hopefully - using the t-online address was accidental anyway). >>> (with-current-buffer (or buffer (current-buffer)) >>> (sieve-manage-send (format "GETSCRIPT \"%s\"" name)) >>> + (set-buffer-multibyte nil) >>> (let ((script (sieve-manage-parse-string))) >>> + (set-buffer-multibyte t) >> >> Changing multibyteness in a buffer like this is (virtually) never the >> right thing to do -- it usually leads to obscure breakages. >> >>> In general, it is also not clear to me why the response (or process) >>> buffer needs to be multibyte enabled at all as it should only be used >>> for the line/byte oriented protocol data. But the commit message of >>> 8e16fb987df9b which introduced the multibyte handling states: >>> >>> commit 8e16fb987df9b80b8328e9dbf80351a5f9d85bbb >>> Author: Albert Krewinkel >>> Date: 2013-06-11 07:32:25 +0000 >>> ... >>> * Enable Multibyte for SieveManage buffers: The parser won't properly >>> handle umlauts and line endings unless multibyte is turned on in the >>> process buffer. >>> ... >>> >>> so this was obviously done on purpose. I contacted Albert about this but >>> he couldn't remember the details (it's been nearly 10 years). >> >> I don't see why this buffer should be multibyte, either. The >> communication with the server is done using bytes, not characters. When >> we need to have characters, we should decode the data and put it in a >> multibyte buffer. >> >> So can you try to back out that commit and see whether it fixes the >> problem instead? Most of the referenced commit was about changes related to STARTTLS handling. Here's the full commit message: lisp/gnus/sievel-manage.el: fully support STARTTLS, fix bit rot * Make sieve-manage-open work with STARTTLS: shorten stream managing functions by using open-protocol-stream to do most of the work. Has the nice benefit of enabling STARTTLS. * Remove unneeded functions and options: the following functions and options are neither in the API, nor called by any other function, so they are deleted: - sieve-manage-network-p - sieve-manage-network-open - sieve-manage-starttls-p - sieve-manage-starttls-open - sieve-manage-forward - sieve-manage-streams - sieve-manage-stream-alist The options could not be applied in a meaningful way anymore; they didn't happen to have much effect before. * Cosmetic changes and code clean-up * Enable Multibyte for SieveManage buffers: The parser won't properly handle umlauts and line endings unless multibyte is turned on in the process buffer. * Wait for capabilities after STARTTLS: following RFC5804, the server sends new capabilities after successfully establishing a TLS connection with the client. The client should update the cached list of capabilities, but we just ignore the answer for now. So just reverting it won't work. I will try to undo the parts relevant to this issue. For clarification: The original code before Alberts change was using this macro (which seemingly contains an error in the doc string): (defmacro sieve-manage-disable-multibyte () "Enable multibyte in the current buffer." (unless (featurep 'xemacs) '(set-buffer-multibyte nil))) to *disable* multibyte handling in the response/protocol buffer. If using `set-buffer-multibyte' is not the right thing, what should be used instead?