4 ms·

> but wildly misguided Why? Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and f

> but wildly misguided Why? Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs. I'm full in favour of removing such insecure features that barely anyone uses. I think if the XSLT people really wanted to save it the best thing to do would have been to write a replacement in Rust. But good luck with that.

rhdunn 1y ago
libxslt != XSLT. It's like removing JPEG support because libjpg is insecure!
- jeltz 1y ago
  Which would be a totally sensible thing you do. Especially if jpeg was a rarely used image format with few libraries supporting it, the main one being unmaintained.
  - nflekkhnnn 1y ago
    Google is on a trajectory to replace jpeg with webp, haven’t you noticed?
- TingPing 1y ago
  If this were true you could fix this today with the other library. That library is the only implementation used and it’s features are relied upon.
  - chrismorgan 1y ago
    Firefox doesn’t use libxslt. I presume IE didn’t either. It’s only WebKit-heritage browsers that use libxslt.
    - TingPing 1y ago
      TIL about Firefox. They have their own in-tree solution. Very interesting but not trivial to use for external projects.
Klonoar 1y ago
The easier thing might have been if Chrome & co opted to include any number of polyfills in JS bundled with the browser instead of making an odd situation where things just break. I think you can recognize that the burden of maintaining a proven security nightmare is annoying while simultaneously getting annoyed for them over-grabbing on this.
panny 1y ago
>Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs. Being this is HN, did anyone suggest rewriting it in rust? :)
- OakNinja 1y ago
  Yes: https://news.ycombinator.com/context?id=45874002 https://news.ycombinator.com/context?id=45874002
gucci-on-fleek 1y ago
> Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs. Sure, I agree with you there, but removing XSLT support entirely doesn't seem like a very good solution. The Chrome developer who proposed removing XSLT developed a browser extension that embeds libxslt [0], so my preferred solution would be to bundle that by default with the browser. This would: 1. Fix any libxslt security issues immediately, instead of leaving it enabled for 18 months until it's fully deprecated. 2. Solve any backwards compatibility concerns, since it's using the exact same library as before. This would avoid needing to get "consensus" from other browser makers, since they wouldn't be removing any features. 3. Be easy and straightforward to implement and maintain, since the extension is already written and browsers already bundle some extensions by default. Writing a replacement in Rust/another memory-safe language is certainly a good idea, but this solution requires far less effort. This option was proposed to the Chrome developers, but was rejected for vague and uncompelling reasons [1]. > I think if the XSLT people really wanted to save it the best thing to do would have been to write a replacement in Rust. That's already been done [2], but maintaining that and integrating it into the browsers is still lots of work, and the browser makers clearly don't have enough time/interest to bother with it. [0]: https://github.com/mfreed7/xslt_extension https://github.com/mfreed7/xslt_extension [1]: https://github.com/whatwg/html/issues/11523#issuecomment-3151429594 https://github.com/whatwg/html/issues/11523#issuecomment-315... [2]: https://gitlab.gnome.org/World/Rust/markup-rs/xrust https://gitlab.gnome.org/World/Rust/markup-rs/xrust
- chrismorgan 1y ago
  From your [1] “rejected for vague and uncompelling reasons”: >>> To see how difficult it would be, I wrote a WASM-based polyfill that attempts to allow existing code to continue functioning, while not using native XSLT features from the browser. >> Could Chrome ship a package like this instead of using native XSLT code, to address some of the security concerns? (I'm thinking about how Firefox renders PDFs without native code using PDF.js.) > This is definitely something we have been thinking about. However, our current feeling is that since the web has mostly moved on from XSLT, and there are external libraries that have kept current with XSLT 3.0, it would be better to remove 1.0 from browsers, rather than keep an old version around with even more wrappers around them. The bit that bothers me is that Google continue to primarily say they’re removing it for security reasons, although they have literally made a browser extension which is a drop-in replacement and removes 100% of the security concerns. The people that are writing about the reasons know this (one of them is the guy that wrote it), which makes the claim a blatant lie. I want people to call Google specifically out on this (and Apple and Mozilla if they ever express it that way, which they may have done but I don’t know): that their “security” argument is deceit, trickery, dishonest, grossly misleading, a bald-faced lie. If they said they want to remove it because barely anyone uses it and it will shrink their distribution by one megabyte, I would still disagree because I value the ability to apply XSLT on feeds and other XML documents (my Atom and RSS feed stylesheets are the most comprehensive I know of), but I would at least listen to such honest arguments. But falsely hiding behind “security”? I impugn their honour. (If their extension is not, as their descriptions have implied, a complete, drop-in replacement with no caveats, I invite correction and may amend my expressed opinion.)
righthand 1y ago
There is already a replacement in rust but people like you and the Google engineers have ignored that fact. “Good luck” they all say turning their nose away from reality so they can kill it. Thanks for your support.

rhdunn 1y ago

libxslt != XSLT. It's like removing JPEG support because libjpg is insecure!

jeltz 1y ago
Which would be a totally sensible thing you do. Especially if jpeg was a rarely used image format with few libraries supporting it, the main one being unmaintained.
- nflekkhnnn 1y ago
  Google is on a trajectory to replace jpeg with webp, haven’t you noticed?
TingPing 1y ago
If this were true you could fix this today with the other library. That library is the only implementation used and it’s features are relied upon.
- chrismorgan 1y ago
  Firefox doesn’t use libxslt. I presume IE didn’t either. It’s only WebKit-heritage browsers that use libxslt.
  - TingPing 1y ago
    TIL about Firefox. They have their own in-tree solution. Very interesting but not trivial to use for external projects.

Klonoar 1y ago

The easier thing might have been if Chrome & co opted to include any number of polyfills in JS bundled with the browser instead of making an odd situation where things just break. I think you can recognize that the burden of maintaining a proven security nightmare is annoying while simultaneously getting annoyed for them over-grabbing on this.

panny 1y ago

>Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs. Being this is HN, did anyone suggest rewriting it in rust? :)

OakNinja 1y ago
Yes: https://news.ycombinator.com/context?id=45874002 https://news.ycombinator.com/context?id=45874002

gucci-on-fleek 1y ago

> Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs. Sure, I agree with you there, but removing XSLT support entirely doesn't seem like a very good solution. The Chrome developer who proposed removing XSLT developed a browser extension that embeds libxslt [0], so my preferred solution would be to bundle that by default with the browser. This would: 1. Fix any libxslt security issues immediately, instead of leaving it enabled for 18 months until it's fully deprecated. 2. Solve any backwards compatibility concerns, since it's using the exact same library as before. This would avoid needing to get "consensus" from other browser makers, since they wouldn't be removing any features. 3. Be easy and straightforward to implement and maintain, since the extension is already written and browsers already bundle some extensions by default. Writing a replacement in Rust/another memory-safe language is certainly a good idea, but this solution requires far less effort. This option was proposed to the Chrome developers, but was rejected for vague and uncompelling reasons [1]. > I think if the XSLT people really wanted to save it the best thing to do would have been to write a replacement in Rust. That's already been done [2], but maintaining that and integrating it into the browsers is still lots of work, and the browser makers clearly don't have enough time/interest to bother with it. [0]: https://github.com/mfreed7/xslt_extension https://github.com/mfreed7/xslt_extension [1]: https://github.com/whatwg/html/issues/11523#issuecomment-3151429594 https://github.com/whatwg/html/issues/11523#issuecomment-315... [2]: https://gitlab.gnome.org/World/Rust/markup-rs/xrust https://gitlab.gnome.org/World/Rust/markup-rs/xrust

chrismorgan 1y ago
From your [1] “rejected for vague and uncompelling reasons”: >>> To see how difficult it would be, I wrote a WASM-based polyfill that attempts to allow existing code to continue functioning, while not using native XSLT features from the browser. >> Could Chrome ship a package like this instead of using native XSLT code, to address some of the security concerns? (I'm thinking about how Firefox renders PDFs without native code using PDF.js.) > This is definitely something we have been thinking about. However, our current feeling is that since the web has mostly moved on from XSLT, and there are external libraries that have kept current with XSLT 3.0, it would be better to remove 1.0 from browsers, rather than keep an old version around with even more wrappers around them. The bit that bothers me is that Google continue to primarily say they’re removing it for security reasons, although they have literally made a browser extension which is a drop-in replacement and removes 100% of the security concerns. The people that are writing about the reasons know this (one of them is the guy that wrote it), which makes the claim a blatant lie. I want people to call Google specifically out on this (and Apple and Mozilla if they ever express it that way, which they may have done but I don’t know): that their “security” argument is deceit, trickery, dishonest, grossly misleading, a bald-faced lie. If they said they want to remove it because barely anyone uses it and it will shrink their distribution by one megabyte, I would still disagree because I value the ability to apply XSLT on feeds and other XML documents (my Atom and RSS feed stylesheets are the most comprehensive I know of), but I would at least listen to such honest arguments. But falsely hiding behind “security”? I impugn their honour. (If their extension is not, as their descriptions have implied, a complete, drop-in replacement with no caveats, I invite correction and may amend my expressed opinion.)

righthand 1y ago

There is already a replacement in rust but people like you and the Google engineers have ignored that fact. “Good luck” they all say turning their nose away from reality so they can kill it. Thanks for your support.