Hacker Newsnew | past | comments | ask | show | jobs | submit | om2's commentslogin

That article doesn’t explain why acupuncture works, just gives a hint of a possible mechanism. It also doesn’t contain any evidence that acupuncture works at all (other than as a placebo).

- and + operators have the same precedence. And a similar bug is possible if the operators were the same (both -). So I’m not sure it’s right to blame this on operator precedence or mixed operators. It’s just that, ultimately, the “consume” needs to be subtracted, not added.


Non-mixed always goes strictly left to right, regardless of the operator, which I haven't seen anywhere near as much struggling with.

But yes, I personally parenthesize `a-b-c` explicitly, because it's not worth it for me to read and wonder if parenthesizing order matters later. Costs less than a second to write, saves a second or ten each time I read it - that's an excellent tradeoff imo, and is a trivial pattern to follow.

(Associative operators are fine, obviously)


I agree with explicit parentheses but please be careful about assuming associativity! The risk when handling floating-point arithmetic in particular is that associativity breaks, and suddenly a + (b + c) does NOT equal (a + b) + c. Not only can these lead to unexpected and hard-to-trace failure patterns, but depending on the details, they also can introduce memory overflow/underflow vulnerabilities.


If you're going for bit-for-bit equivalence of float values, then even with a single operation you're relying on compiler flags, architecture, the phase of the moon... I'm hard-pressed to think of any memory safety issues though.


Yea, you're in a fairly special niche of programming if you're somewhere that truly matters, and you can't accept any valid order's output. In most general code, if that kind of precision matters, float is the wrong choice: use a bignum object and be exactly correct regardless of how you organized your code.

Which is a niche that exists, obviously. So it is absolutely true for some cases. But I would hope that any code that requires this is extremely clear about requiring it.


Didn't you just suffer from the same trap the parent was trying to avoid?


> They also have the option to not spend resources finding the bugs in the first place.

The Copenhagen interpretation of security bugs: if you don’t look for it, it doesn’t exist and is not a problem.


The codec is compiled in, enabled by default, and auto detected through file magic, so the fact that it is an obscure 1990s hobby codec does not in any way make the vulnerability less exploitable. At this point I think FFmpeg is being intentionally deceptive by constantly mentioning only the ancient obscure hobby status and not the fact that it’s on by default and autodetected. They have also rejected suggestions to turn obscure hobby codecs off by default, giving more priority to their goal of playing every media format ever than to security.


Yeah, ffmpeg's responses is really giving me a disingenuous vibe as their argument is completely misleading (and it seems to be working on a decent amount of people who don't try to read further into it). IMO it really damages their reputation in my eyes. If they handled it maturely I think I would have had a bit more respect for them.

As a user this is making me wary of running it tbh.


Nation-states are a very relevant part of the threat model.


In this world and the alternate universe both, attackers can also use _un_published vulnerabilities because they have high incentive to do research. Keeping a bug secret does not prevent it from existing or from being exploited.


It doesn’t scale well to content that changes dynamically on the client side very well. Dynamic manipulation of the post transform XSL-FO is confusing and difficult, retransforming the whole document from source is too slow and loses state. This is a big part of why CSS won.


What the hell are you talking about

CSS and XSL-FO are entirely different concepts


Take it up with the parent of my comment, who compared them directly.


Fetch API is a pretty recent addition to the web platform. Back in the day, you could absolutely embed images of stylesheets from ftp: URLs. You could even use it with XMLHttpRequest (predecessor of Fetch). Even further back, gopher: was integrated with the web. URL schemes were invented for the web with the idea that http: is not the only one. These other protocols were really part of the web until they weren’t.


XSLT is also a really problematic feature from an implementation perspective (albeit in a different way than showModalDialog or MutationObservers).

I’m not a Chrome dev but I think they have decent reasons for going this way.


1.1 is not that complex to implement


Implementing it without tons of security bugs is apparently pretty hard.


We have contributed a number of upstream fixes

  $ cd gnome-libxml2.git
  $ git log --oneline --author=@apple.com | wc -l
      43
The main reason we have a fork at all is that upstream libxml2 has broken source and binary compatibility in various ways, and we can't take those changes because libxml2 is public API on our platforms. We do make an effort to upstream all security fixes, though we sometimes get to it only after we ship.


I do appreciate you showing up and clarifying that effort to upstream fixes are made! But is your fork developed in the open?

I think the root issue here is that Apple takes from the commons and then (at best) throws the leftovers over the fence.

If there is a poster child for why BSD/MIT licenses lead to less desirable outcomes, it's BSD being endlessly forked.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: