GNU bug report logs - #49926
[PATCH] Fix NNIMAP search command in the gnus

Previous Next

Package: emacs;

Reported by: Jan Stranik <jan <at> stranik.org>

Date: Sat, 7 Aug 2021 13:49:01 UTC

Severity: normal

Tags: moreinfo, patch

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Jan Stranik <jan <at> stranik.org>
Cc: 49926 <at> debbugs.gnu.org
Subject: Re: bug#49926: [PATCH] Fix NNIMAP search command in the gnus
Date: Sun, 08 Aug 2021 12:26:28 -0700
On 08/08/21 14:29 PM, Jan Stranik wrote:
> On 08/07/21 16:06 PM, Eric Abrahamsen wrote:
>> Jan Stranik via "Bug reports for GNU Emacs, the Swiss army knife of text
>> editors" <bug-gnu-emacs <at> gnu.org> writes:
>>
>>> In the version 27.2 of emacs, the nnimap search commands stopped
>>> working in gnus.
>>>
>>> Good example is a command AT to find a referred
>>> thread in the summary buffer. The observed behaviour was that the
>>> search command returned no error.
>>>
>>> The problem turned out to be in the way how imap query is sent to the
>>> server. The function nnimap-make-thread-query used a format function
>>> with foramt specifier %S. For string values with formatting the string
>>> returned is in the format #("string" ....). The result was tha the
>>> query sent to the server looked like:
>>>   23:52:00 [stranik.org] 1980 UID SEARCH (OR HEADER REFERENCES
>>> #("<87pmurac3u.fsf <at> stranik.org>" 0 28 (ws-butler-chg chg)) HEADER
>>> Message-Id #("<87pmurac3u.fsf <at> stranik.org>" 0 28 (ws-butler-chg
>>> chg)))
>>>
>>> which is an invalid query.
>>>
>>> The change formats the string with %s specifier which discards text
>>> properties.
>>
>> But that also removes the quoting around the message ids -- are we sure
>> that's still valid?

(Putting debbugs back in the cc)

> You're right. Per the specification, the strings are expected to be
> either in literal or quotes syntax
> (https://datatracker.ietf.org/doc/html/rfc3501#section-4.3).
>
> Adding quotes back to make the strings to be in quoted syntax.
>
> Interestingly, dovecot seems to accept the strings without quotes as
> well.

I've found dovecot to be generally pretty permissive, though obviously
we want to stick closely to the RFCs here.

> New patch attached.

This seems fine, but just thinking out loud: is there anything else the
%S could potentially get us, here? Extra quoting of special characters?

Our other option would be to explicitly remove properties from the
strings beforehand; I'm just wondering if one approach is preferable
over another.

Eric




This bug report was last modified 3 years and 257 days ago.

Previous Next


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