Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Glassworm is back: A new wave of invisible Unicode attacks hits repositories

aikido.dev

Post reply on HN
Print view View original

61–70 of 201 posts

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#61

Post by wcoenen »

WalterBright wrote: post #27
WalterBright wrote: post #21

Unicode should be for visible characters. Invisible characters are an abomination. So are ways to hide text by using Unicode so-called "characters" to cause the cursor to go backwards. Things that vanish on a printout should not be in Unicode. Remove them from Unicode.

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.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#62

Post by godelski »

andrewflnr wrote: post #15
btown wrote: post #8

IMO while the bar is high to say "it's the responsibility of the repository operator itself to guard against a certain class of attack" - I think this qualifies. The same way GitHub provides Secret Scanning [0], it should alert upon spans of zero-width characters that are not used in a linguistically standard way (don't need an LLM for this, just n-tuples). Sure, third-party services like the OP can provide bots that…

Regardless of the thorny question of whether it's Github's responsibility , it sure would be a good thing for them to do ASAP.

Here's the big reason GitHub should do it:

  It makes the product better
I know people love to talk money and costs and "value", but HN is a space for developers, not the business people. Our primary concern, as developers, is to make the product better. The business people need us to make the product better, keep the company growing, and beat out the competition. We need them to keep us from fixating on things that are useful but low priority and ensuring we keep having money. The contention between us is good, it keeps balance. It even ensures things keep getting better even if an effective monopoly forms as they still need us, the developers, to make the company continue growing (look at monopolies people aren't angry at and how they're different). And they need us more than we need them.

So I'd argue it's the responsibility of the developers, hired by GitHub, to create this feature because it makes the product better. Because that's the thing you've been hired for: to make the product better. Your concern isn't about the money, your concern is about the product. That's what you're hired for.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#63

Post by tapland »

godelski wrote: post #62
andrewflnr wrote: post #15

Earlier quoted context omitted.

Regardless of the thorny question of whether it's Github's responsibility , it sure would be a good thing for them to do ASAP.

Here's the big reason GitHub should do it: It makes the product better I know people love to talk money and costs and "value", but HN is a space for developers, not the business people. Our primary concern, as developers, is to make the product better . The business people need us to make the product better, keep the company growing, and beat out the competition. We need them to keep us from fixating on things that a…

Tldr: Yeah it would make it better!

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#64

Post by chongli »

WalterBright wrote: post #49
pvillano wrote: post #35

Earlier quoted context omitted.

Unicode is "designed to support the use of text in all of the world's writing systems that can be digitized" Unicode needs tab, space, form feed, and carriage return. Unicode needs U+200E LEFT-TO-RIGHT MARK and U+200F RIGHT-TO-LEFT MARK to switch between left-to-right and right-to-left languages. Unicode needs U+115F HANGUL CHOSEONG FILLER and U+1160 HANGUL JUNGSEONG FILLER to typeset Korean. Unicode needs U+200C ZER…

[flagged]

Unicode is for human beings, not machines.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#65

Post by Muromec »

WalterBright wrote: post #51
nswango wrote: post #36

Earlier 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?

> 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.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#66

Post by Yokohiii »

nswango wrote: post #36
WalterBright wrote: post #27

Earlier 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.

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.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#67

Post by abujazar »

WalterBright wrote: post #54
abujazar wrote: post #22

Earlier quoted context omitted.

Invisible characters are there for visible characters to be printed correctly...

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.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#68

Post by zzo38computer »

I 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 similar things. (If you need non-ASCII text (e.g. for documentation) you might store them in separate files instead. If you only need a small number of them in a few string literals, then you might use the \x escapes; add comments if necessary to explain it.)

The article is about in JavaScript, although it can apply to other programming languages as well. However, even in JavaScript, you can use \u escapes in place of the non-ASCII characters. (One of my ideas in a programming language design intended to be better instead of C, is that it forces visible ASCII (and a few control characters, with some restrictions on their use), unless you specify by a directive or switch that you want to allow non-ASCII bytes.)

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#69

Post by godelski »

minus7 wrote: post #7

The `eval` alone should be enough of a red flag

I'm not a JS person, but taking the line at face value shouldn't it to nothing? Which, if I understand correctly, should never be merged. Why would you merge no-ops?
Post reply on HN