From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 1252F6DE102D for ; Mon, 25 Mar 2019 05:54:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.016 X-Spam-Level: X-Spam-Status: No, score=-0.016 tagged_above=-999 required=5 tests=[AWL=-0.015, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCPLtue19mvP for ; Mon, 25 Mar 2019 05:54:08 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id E58A46DE0F40 for ; Mon, 25 Mar 2019 05:54:07 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.89) (envelope-from ) id 1h8P75-0007ue-Ew; Mon, 25 Mar 2019 08:54:03 -0400 Received: (nullmailer pid 27608 invoked by uid 1000); Mon, 25 Mar 2019 12:54:02 -0000 From: David Bremner To: Gregor Zattler , notmuch@notmuchmail.org Subject: Re: [bug?][notmuch-emacs] X11: renders Headers with face attributes In-Reply-To: <87k1gsd67j.fsf@len.workgroup> References: <87k1gsd67j.fsf@len.workgroup> Date: Mon, 25 Mar 2019 09:54:02 -0300 Message-ID: <875zs7cdxx.fsf@tethera.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 12:54:09 -0000 Gregor Zattler writes: > > Is this a bug? Should untrusted senders be allowed to influence > how headers are displayed? I don't think so. For me this case > should be handled as a homograph attack > (https://en.wikipedia.org/wiki/IDN_homograph_attack). I'm not sure about the threat to the user here, but I agree that it might make sense to normalize the subject at indexing time. > > I do know there is character folding for searches but emacs would > need to use the reverse for displaying characters and only > characters which deviate in a way that is recognized as a font > attribute. I'm guessing this would be better handled at the notmuch CLI / library level, where we have access to utf8 conversion facilities e.g. from glib. It turns out that these kind of problems (related to locales) are harder than one might expect.