Earlier quoted context omitted.
It really is. There are very few proper use-cases for eval.
For a long time the standard way of loading JSON was using eval.
For IE7 support, yes... https://caniuse.com/mdn-javascript_builtins_json_parse
Glassworm is back: A new wave of invisible Unicode attacks hits repositories
101–110 of 201 posts
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#102Earlier quoted context omitted.
For a long time the standard way of loading JSON was using eval.
Not that long, browsers implemented JSON.parse() back in 2009. JSON was only invented back in 2001 and took a while to become popular. It was a very short window more than a decade ago when eval made sense here. Eval for json also lead to other security issues like XSSI.
Problem is, it took until around 2016 for IE6 to be fully dead, so people continued to justify these hacks for a long time. Horrifying times.
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#103I use non-Unicode mode in the terminal emulator (and text editors, etc), I use a non-Unicode locale, and will always use ASCII for most kind of source code files (mainly C) (in some cases, other character sets will be used such as PC character set, but usually it will be ASCII). Doing this will mitigate many of this when maintaining your own software. I am apparently not the only one; I have seen others suggest simil…
> ... and will always use ASCII for most kind of source code files
Same. And I enforce it. I've got scripts and hooks that enforces source files to only ever be a subset of ASCII (not even all ASCII codes have their place in source code).
Unicode chars strings are perfectly fine in resource files. You can build perfectly i18n/l10n apps and webapps without ever using a single Unicode character in a source file. And if you really do need one, there's indeed ASCII escaping available in many languages.
Some shall complan that their name as "Author: ..." in comments cannot be written properly in ASCII. If I wanted to be facetious I'd say that soon we'll see:
# Author: Claude Opus 27.2
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#104It baffles me that any maintainer would merge code like the one highlighted in the issue, without knowing what it does. That’s regardless of being or not being able to see the “invisible” characters. There’s a transforming function here and an eval() call. The mere fact that a software maintainer would merge code without knowing what it does says more about the terrible state of software.
> It baffles me that any maintainer would merge code like the one highlighted in the issue, without knowing what it does.
I don't know if it is relevant in any specific case that is being discussed here, but if the exploit route is via gaining access to the accounts of previously trusted submitters (or otherwise being able to impersonate them) it could be a case of teams with a pile of PRs to review (many of which are the sloppy unverified LLM output that is causing a problem for some popular projects) lets through an update from a trusted source that has been compromised.
It could correctly be argued that this is a problem caused by laziness and corner cutting, but it is still understandable because projects that are essentially run by a volunteer workforce have limited time resources available.
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#105Earlier quoted context omitted.
I'll grant that a space and a newline are necessary. The rest, nope.
You're talking about a subset of ASCII then. Unicode is supposed to support different languages and advanced typography, for which those characters are necessary. You can't write e.g. Arabic or Hebrew without those "unnecessary" invisible characters.
Please explain why an invisible zero width "character" is necessary.
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#106Earlier quoted context omitted.
Another dum dum Unicode idea is having multiple code points with identical glyphs. Rule of thumb: two Unicode sequences that look identical when printed should consist of the same code points.
As far as I know, glyphs are determined by the font and rendering engine. They're not in the Unicode standard.
Fraktur (font) and italic (rendering) are in the Unicode standard, although Hackernews will not render them. (I suspect that the Hackernews software filters out the nuttier Unicode stuff.)
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#107Earlier quoted context omitted.
That's a very narrow view of the world. One example: In the past I have handled bilingual english-arabic files with switches within the same line and Arabic is written from left to right. There are also languages that are written from to to bottom. Unicode is not exclusively for coding, to the contrary, pretty sure it's only a small fraction of how Unicode is used. > Somehow people didn't need invisible characters wh…
> That's a very narrow view of the world. But not one that would surprise anyone familiar with WalterBright's antics on this website…
At least my antics do not include insulting people.
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#108Earlier quoted context omitted.
> So you think that the letters in the Greek and Cyrillic alphabets which are printed identically to the Latin A should not exist? Yes. Unicode should not be about semantic meaning, it should be about the visual. Like text in a book. > And, for example, Greek words containing this letter should be encoded with a mix of Latin and Greek characters? Yup. Consider a printed book. How can you tell if a letter is a Greek l…
>Yup. Consider a printed book. How can you tell if a letter is a Greek letter or a Latin letter? I can absolutely tell Cyrillic k from the lating к and latin u from the Cyrillic и. >should not be about semantic meaning, It's always better to be able to preserve more information in a text and not less.
> I can absolutely tell Cyrillic k from the lating к and latin u from the Cyrillic и.
They look visually distinct to me. I don't get your point.
> It's always better to be able to preserve more information in a text and not less.
Text should not lose information by printing it and then OCR'ing it.
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#109Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#110Earlier quoted context omitted.
So you think that the letters in the Greek and Cyrillic alphabets which are printed identically to the Latin A should not exist? And, for example, Greek words containing this letter should be encoded with a mix of Latin and Greek characters?
What about numbers? Would they be assigned to arabic only? I guess someone will be offended by that. While at it we could also unify I, | and l. It's too confusing sometimes.
> While at it we could also unify I, | and l. It's too confusing sometimes.
They render differently, so it's not a problem.