From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Unicode confusables and reordering characters considered harmful Date: Wed, 03 Nov 2021 07:18:36 +1100 Message-ID: <87y2665mqf.fsf@gmail.com> References: <875ytag0hb.fsf@yahoo.com> <87zgqmd5np.fsf@mat.ucm.es> <83wnlqk3rn.fsf@gnu.org> <72dd5c2a-42c7-b12e-05ed-e93adbd89727@gmail.com> <83ilxajyhw.fsf@gnu.org> <83fssejxf8.fsf@gnu.org> <835ytajsv2.fsf@gnu.org> <831r3yjqo9.fsf@gnu.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="3000"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.4; emacs 28.0.60 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 02 21:26:57 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mi0Mz-0000ah-1b for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Nov 2021 21:26:57 +0100 Original-Received: from localhost ([::1]:48784 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mi0Mx-00061F-SC for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Nov 2021 16:26:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mi0Lc-0005JQ-Qd for emacs-devel@gnu.org; Tue, 02 Nov 2021 16:25:32 -0400 Original-Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]:33409) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mi0LN-0004JL-V7 for emacs-devel@gnu.org; Tue, 02 Nov 2021 16:25:32 -0400 Original-Received: by mail-pg1-x531.google.com with SMTP id r28so463264pga.0 for ; Tue, 02 Nov 2021 13:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=awC/i/Ol6uYG7grxNouBClprv6N4bCghqfE3HF5JFeQ=; b=HJ3rcfsjJ58eO4ebJcw6dqhvjIAXPpXkNhMxy1UIu/ovXOHN271eOJjSr8WG1Jluj5 QpP38mxUooGdEF5YDudxuffDTg8jgDdrye/XoHEcM2/5qG2F8HLus4miZUDJRPA//KnM BgPFotJMmtOPMjH6I6WmKSvtyjb5CyDuMVtA1HehbLzYWLOkrWrzecQiqmLT6cXjOkEe 91oYRhg2CuEhcbnu/EZkqRCrNvQ+BrtaLZaCO35OhZArxmysemSwrpw+F50vhBzxoMlh QVJgjTTuK3RufLfPe8xGCo056r4r6n2FPeV64FMArdhB8MoRUFCW0R/OhUUInZBzL0vR AW0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version; bh=awC/i/Ol6uYG7grxNouBClprv6N4bCghqfE3HF5JFeQ=; b=3QaxLSkH0k3fA4TY/g8/zS8Y8hKfpGSBhcEib5c0DyrHQNSseWjtH/WUlGnachSefW Tbf93QXf7NNMbfexHCJ2w0T42PLLXPkJ1upH4be6CFdN/JWQo5ZRnf9MwKzqbZT2/2zh 5sEaAAo6KNOap2lP0D2T8hhmODxQy974zwMJCGPlYtKu0zIunhPlAI0BkTPhbCgWjAXm yZV0N+rBqdzly38ubpaz3C7DyRPdjUkQR0Xh2sl3m1A5gIvke/6xRwGxqyYtOJRLAHW2 xMzcCA+97QEpVNqxhcP+oK7ruQHlfNn2PxS7IRbw56Mqugn4hTRk3wi/WVLewPnjcs8E MvyA== X-Gm-Message-State: AOAM532u1GHb5FVJyn+bqNXOnmLZlVOuZpsZ+kB8U0LEqnTDxjYQ1gFv LuFxWfunIKVGVxX4Y3WKvLlHJaDqVG4= X-Google-Smtp-Source: ABdhPJxJ4Vmx/H2b5+ijIxw1INfjuu5UzdDUfpUZnRq55r69RTfIwMkLkRiFDsjZUe0NjARuVPB7mQ== X-Received: by 2002:a65:4942:: with SMTP id q2mr26843168pgs.405.1635884716026; Tue, 02 Nov 2021 13:25:16 -0700 (PDT) Original-Received: from dingbat (2001-44b8-31f2-bb00-748c-ba10-246a-b2e5.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:748c:ba10:246a:b2e5]) by smtp.gmail.com with ESMTPSA id z2sm25747pfh.135.2021.11.02.13.25.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Nov 2021 13:25:15 -0700 (PDT) In-reply-to: <831r3yjqo9.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::531; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x531.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:278536 Archived-At: Eli Zaretskii writes: >> From: Stefan Monnier >> Cc: Stefan Kangas , cpitclaudel@gmail.com, >> emacs-devel@gnu.org >> Date: Tue, 02 Nov 2021 15:12:56 -0400 >> >> > You cannot see those characters on a screenshot, for the same reason >> > you cannot see any whitespace characters on a screenshot: they are >> > only discernible when you move cursor through them. Which is why I >> > asked how are you looking for them. If you are looking for them in a >> > screenshot, you will never see them. >> >> But that's the core of the vulnerability: if you just look at the screen >> (and just scroll through it) you will have an incorrect understanding of >> what the code does. > > If you want a more prominent display, customize > glyphless-char-display-control to show format-control characters as > acronyms, say, or as hex-code. > > And anyway, my point was that Emacs deviates from Unicode here, which > says not to show these controls at all, and by deviating it gives the > user some defense against these problems. I did say originally the > defense was "weak", so if you want to point out that this is a weak > defense, you are preaching to the choir. > >> It's good that such bidi override chars are displayed as a thin space, >> but it's mostly useful to make it possible to edit them (or to `C-x =` >> on them), but I don't think it makes a significant different in terms of >> the security issues introduced by the presence of those chars in the code. > > In most cases, there's no need to make these controls stand out, > because situations where this presents security risks are extremely > rare, to put it mildly, and OTOH having them stand out more by default > will make it harder to read text with completely legitimate uses of > these controls (example: TUTORIAL.he). Therefore, IMNSHO it's okay to > have this off by default (and have a way of turning that on in case of > increased paranoia). Moreover, I think adding features that detect > the suspicious uses of this functionality will better serve our users > than just showing the controls more prominently, because it will have > a much lower probability of false positives, and will avoid getting in > the way of reading legitimate text which uses these controls for valid > reasons. Totally agree. There is no point having additional visual clues for a security issue which is not well understood by most users. It will just cause user frustration and as pointed out, in some cases make legitimate uses look worse. On the other hand, having features which warn the user of suspicious instances is likely to be more useful and informative, even to those who are not terribly aware of the issue (I'm assuming such feature would provide some sort of warning and a reference to where to find more detailed explanation).