GNU bug report logs - #51733
27.1; Detect impossible email addresses better

Previous Next

Packages: gnus, emacs;

Reported by: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>

Date: Wed, 10 Nov 2021 00:29:01 UTC

Severity: wishlist

Found in version 27.1

Fixed in version 29.1

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

Bug is archived. No further changes may be made.

Full log


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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51733 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#51733: 27.1; Detect impossible email addresses better
Date: Mon, 17 Jan 2022 15:54:58 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

> Yes, I understand the general concern, but I'm asking how serious is
> this in practice.  Can you tell?

I don't know how to quantity that.  We're talking about security
mechanisms, and they should be reliable.

(But, yes, the differences are massive, especially in the Asian parts of
the data.)

>> In addition, that table assumes that each character belongs to a single
>> script, which is also wrong.  So I'm making a new table based on
>> Scripts.txt and ScriptExtensions.txt.
>
> It is confusing to have 2 separate properties of a character that are
> subtly incompatible, and for such obscure properties at that.  It will
> be source of many problems.  So I think we should avoid that if it's
> feasible.  Can we plrase discuss any real problems that would be
> xaused by using the existing char-table?

It's impossible to implement the Unicode security recommendations based
on the Blocks.txt data -- it's that simple.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




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

Previous Next


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