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

71–80 of 201 posts

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

#71

Post by Yokohiii »

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…

Unicode is about semantics not appearance. If you don't need semantics then use something different.

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

#72

Post by godelski »

kordlessagain wrote: post #9
minus7 wrote: post #7

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

No it’s not.

The parent didn't say "there's no legitimate uses of eval", they said "using eval should make people pay more attention." A red flag is a warning. An alert. Not a signal saying "this is 100% no doubt malicious code."

Yes, it's a red flag. Yes, there's legitimate uses. Yes, you should always interrogate evals more closely. All these are true

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

#73

Post by zzo38computer »

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…

I think a "force visible ASCII for files whose names match a specific pattern" mode would be a simple thing to help. (You might be able to use the "encoding" command in the .gitattributes file for this, although I don't know if this would cause errors or warnings to be reported, and it might depend on the implementation.)

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

#74

Post by jmusall »

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]

The fact is that there were so many character sets in use before Unicode because all these things were needed or at least wanted by a lot of people. Here's a great blog post by Nikita Prokopov about it: https://tonsky.me/blog/unicode/

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

#75

Post by godelski »

tapland wrote: post #63
godelski wrote: post #62

Earlier quoted context omitted.

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!

I hope I left the lead as the lead.

But I also think we've had a culture shift that's hurting our field. Where engineers are arguing about if we should implement certain features based on the monetary value (which are all fictional anyways). But that's not our job. At best, it's the job of the engineering manager to convince the business people that it has not only utility value, but monetary.

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

#76

Post by NoMoreNicksLeft »

Why can't code editors have a default-on feature where they show any invisible character (other than newlines)? I seem to remember Sublime doing this at least in some cases... the characters were rendered as a lozenge shape with the hex value of the character.

Is there ever a circumstance where the invisible characters are both legitimate and you as a software developer wouldn't want to see them in the source code?

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

#78

Post by eviks »

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.

So you'd remove space and tab from Unicode?

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

#79

Post by estebank »

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.

If anything, Unicode should have had more disambiguated characters. Han unification was a mistake, and lower case dotted Turkish i and upper case dotless Turkish I should exist so that toUpper and toLower didn't need to know/guess at a locale to work correctly.

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

#80

Post by tetha »

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.

That ship has sailed, but I consider Unicode a good thing, yet I consider it problematic to support Unicode in every domain.

I should be able to use Ü as a cursed smiley in text, and many more writing systems supported by Unicode support even more funny things. That's a good thing.

On the other hand, if technical and display file names (to GUI users) were separate, my need for crazy characters in file names, code bases and such are very limited. Lower ASCII for actual file names consumed by technical people is sufficient to me.

Post reply on HN