Unicode security

[Paul Koning]

> On Jan 10, 2022, at 4:07 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Mon, 10 Jan 2022, Reini Urban via Binutils wrote:
> 
>> So sooner or later some ELF/COFF/bla header field will be needed to state
>> the obvious:
>> name is UTF-8.
> 
> I think that's a matter for the ELF gABI document, where it describes the 
> *C binding to ELF* (where it says "External C symbols have the same names 
> in C and object files' symbol tables." - which says nothing about 
> encoding, since the point of that statement in its historical context was 
> probably to imply "no leading underscores added"). 

One complication is that "the same name" has a trivially obvious meaning with ASCII (identical byte strings) but not with Unicode, where a given string can be encoded several ways.  This is why "normalization" exists in Unicode, as a way to convert valid Unicode strings into a single representation so they can be easily compared as byte strings.  But to make matters somewhat complicated, there are several normalizations.  A standard that needs to handle Unicode and have a definition of "equal strings" will want to refer to a particular normalization.  For example, the IETF iSCSI standard does this; in that particular case the normalization used is one that folds case, but there are also non-folding normalizations.

As an example of a string where this matters, "é" can be encoded either as the "precomposed" character "lowercase e with acute accent" or "lowercase e" followed by "combining acute accent".  Both represent the same string.  

	paul