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

Memory safety for web fonts

developer.chrome.com

Post reply on HN
Print view View original

111–120 of 230 posts

Re: Memory safety for web fonts

#111

Post by twic »

cbdumas wrote: post #30
jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

Despite mounting evidence this perspective remains shockingly common. There seems to be some effect where one might convince oneself that while others are constantly introducing high severity bugs related to memory un-safety, I always follow best practices and use good tooling so I don't have that issue. Of course evidence continues to build that no tooling or coding practice eliminates the risk here. I think what's…

There's also a sort of dead sea effect at work. People who worry about introducing safety bugs use safe languages to protect themselves from that. Which means that the only people using C are people who don't worry about introducing safety bugs.

Re: Memory safety for web fonts

#112

Post by [deleted] »

Keyb0ardWarri0r wrote: post #15

This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project. You don't have to do the Big Rewrite™, you can simply migrate components one by one instead.

[deleted]

Re: Memory safety for web fonts

#113

Post by zozbot234 »

SquareWheel wrote: post #25

I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…

Sub-pixel anti-aliasing requires outputing a pixel-perfect image to the screen, which is a challenge when you're also doing rendering on the GPU. You generally can't rely on any non-trivial part of the standard 3D-rendering pipeline (except for simple blitting/compositing) and have to use the GPU's compute stack instead to address those requirements. This adds quite a bit of complexity.

Re: Memory safety for web fonts

#114

Post by tptacek »

shadowgovt wrote: post #81
jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

Google's overall approach to Rust right now is based on a philosophy that sees two categories of bugs: 1. bugs in new code 2. bugs in old code that have survived years of scrutiny Their conclusion from this is that they're generally greenlighting Rust for new projects but not requiring a rewrite for old projects because they believe rewrites are likely to introduce new category-1 bugs (regardless of the target langua…

Was going to jump in to say this. We interviewed Jeff Vander Stoep about this a couple months ago; it was pretty interesting: https://securitycryptographywhatever.com/2024/10/15/a-little...

It's always better to get new memory-safe code in to replace old memory-unsafe code, when you can, but the prioritization here is a little more complex.

Re: Memory safety for web fonts

#115

Post by kevin_thibedeau »

da_chicken wrote: post #106
grishka wrote: post #93

Earlier quoted context omitted.

> because there are no Macs with non-HiDPI displays any more That is not true. Apple still sells Macs that don't come with a screen, namely Mac Mini, Mac Studio, and Mac Pro. People use these with non-HiDPI monitors they already own all the time.

That's not really the most charitable reading of GP's comment. I think they very clearly mean that Apple does not sell Macs with non-HiDPI displays anymore . It's not a configuration they sell, so they don't need to support those features anymore in their current offerings. You're right that there's nothing stopping someone from hooking up an HDMI-to-VGA adapter for their 22" Trinitron from 2001, but that doesn't mea…

The Trinitron will blur itself at 1600x1200. The problem is the legions of low PPI 1080p LCDs in business settings.

Re: Memory safety for web fonts

#116

Post by Ono-Sendai »

TheRealPomax wrote: post #44
Ono-Sendai wrote: post #31

FreeType is a dinosaur that should be replaced regardless of Rust or not.

The best libraries are libraries that have a clearly defined goal, hit that goal, and then don't change until the goalposts get moved. Something that happens only very slowly in font land. Its age is completely irrelevant other than as demonstration that it did what it set out to do, and still performs that job as intended for people who actually work on, and with fonts.

I don't think you understand how backwards it is. My patch that makes SDF rendering 4x faster was not accepted, presumably because floating point-maths is some strange new-fangled technology. Freetype uses antiquated fixed-point integer maths everywhere. See https://gitlab.freedesktop.org/freetype/freetype/-/merge_req...

Re: Memory safety for web fonts

#117

Post by pjmlp »

dpe82 wrote: post #77
jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

C and modern C++ are so different that lumping them together in a blanket assertion doesn't really carry much meaning.

If only didn't exist so many folks that insist in using C types, and C headers, in modern C++ code.

Re: Memory safety for web fonts

#118

Post by kmoser »

hombre_fatal wrote: post #76
graemep wrote: post #67

Earlier quoted context omitted.

There would be far fewer bugs if people actually stick to writing code like that. I once had to reverse engineer (extract the spec from the code) a C++ function that was hundreds of lines long. I have had to fix a Python function over a thousand lines long. I am sure the people who wrote that code will find ways to make life difficult with Rust too, but I cannot regret having one less sharp knife in their hands.

On the other hand, parceling a large function into smaller functions can create indirection that is even harder to follow and harder to verify as bug-free.

Also, the act of breaking it into smaller functions itself may introduce more bugs.

Re: Memory safety for web fonts

#119

Post by [deleted] »

jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

[deleted]

Re: Memory safety for web fonts

#120

Post by [deleted] »

fresh_broccoli wrote: post #28

It's very annoying that Google's websites, including this blog, are automatically translated to my browser's preferred language. Sillicon Valley devs clearly believe that machine translation is a magical technology that completely solved internationalization, like in Star Trek. No, it's far from it. Ever since internet has been flooded with automatically translated garbage, the experience of international users, at l…

[deleted]
Post reply on HN