[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26634: 26.0.50; The network security manager doesn't understand IDNA
bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains
Fri, 13 Apr 2018 17:03:37 +0200
Lars Ingebrigtsen <address@hidden> writes:
> Lars Ingebrigtsen <address@hidden> writes:
>> Lars Ingebrigtsen <address@hidden> writes:
>>> If you type `M-x eww RET https://аррӏе.com RET', the NSM will then say:
>>> "certificate host doesn't match hostname"
>> Hm... Now Emacs refuses to load that URL completely...
> OK; I've now fixed recent breakages so that we can access
> https://аррӏе.com again.
> Now the question is... what do we do about this in the network security
> If you go to that domain in Firefox, for instance, it won't say that
> there's anything wrong with it... because it isn't. It's a totally
> normal domain name consisting of ASCII characters and a CYRILLIC SMALL
> LETTER PALOCHKA instead of the L.
Thatʼs not what you have there. The first component of your FQDN is
100% cyrillic. Did you mean <https://appӏe.com> ? (FWIW, chrome is
supposed to detect the 100% cyrillic case, but doesnʼt as far as I can
> `puny-highly-restrictive-domain-p' is not triggered for the domain, so
> eww doesn't signal anything wrong with it, either.
> So... Do we say "fine, this is all fine" or do we ... do something?
> :-) Opinions welcome.
In emacs-26, when I try eww on https://appӏe.com, I get
which is already an indication that something fishy is going on.