44 ms·

From my experience, these issues are only relevant if you allow the execution of untrusted stylesheets which nobody would ever do. The only exception are browse

From my experience, these issues are only relevant if you allow the execution of untrusted stylesheets which nobody would ever do. The only exception are browser vendors. A couple of years ago, I had the idea of funding libxslt development with Google Chrome bug bounties. This was cut short after reporting two or three issues. Google refused to pay bounties for valid reports because I was a contributor to libxslt, regardless of whether these bugs were 20 years old. I must admit that I feel a bit of schadenfreude. On the other hand, it still makes me sad that these companies care so little about upstream projects and OSS in general.

Wowfunhappy 1y ago
> Google refused to pay bounties for valid reports because I was a contributor to libxslt Huh?
- Cyykratahk 1y ago
  I'm guessing Google is avoiding the scenario where a contributor "accidentally" commits code with a bug, then later reports the bug they "found".
  - Wowfunhappy 1y ago
    I can understand if it's code the reporting person actually wrote, but if it's just someone else on the project that seems pretty ridiculous.
    - motorest 1y ago
      Not ridiculous. It's a clear conflict of interests, and represents a perverse incentive.
      - baq 1y ago
        And it’s easy to fix - sponsor a contributor. It’d be cheaper than the many meetings that were needed to make the removal decision.
        motorest 1y ago
        > And it’s easy to fix - sponsor a contributor. It’d be cheaper than the many meetings that were needed to make the removal decision. I don't think that's how it works. I mean, how many problems did you ever fixed by dictating how others should spend their own money? Also, apparently some of these issues exist for over a decade. That alone tells you how serious the problem is, and how urgent it needs fixing.
        baq 1y ago
        I'm just saying they've got a bug bounty program but not a bug prevention bounty program, or even a fix a known bug bounty program. The security team has a budget for the realized risks but predictably not for managing unrealized risk in the open source community which they depend on.
        x0x0 1y ago
        > a bug prevention bounty program Particularly for a dep they've chosen to ship in their browser.
        hmcq6 1y ago
        > Also, apparently some of these issues exist for over a decade. That alone tells you how serious the problem is The "serious problem" is that they've known about bugs for 20 years and not committed resources to fix it. The problem is the money.
        motorest 1y ago
        > The "serious problem" is that they've known about bugs for 20 years and not committed resources to fix it. The problem is the money. Who is "they"? Project maintainers? Project users? You? > The problem is the money. So this is a project that didn't require any funding for decades in order to exist. Explain exactly why you believe money is an issue.
    - layer8 1y ago
      People could fix each other’s intentionally introduced bugs and make a living that way. The argument is less convincing when the bugs are a couple years old. There could be an exemption for that, but it’s also more work to verify (Git histories can be fabricated).
      - Wowfunhappy 1y ago
        They could anyway, one person intentionally introduced bugs and the other reports them. The reporter just avoids ever contributing code themself. But doing any of this repeatedly without getting caught seems hard.
      - deleted 1y ago
        [deleted]
  - netsharc 1y ago
    But, what about my minivan? https://devhumor.com/content/uploads/images/October2015/paid-debugging-animation.gif https://devhumor.com/content/uploads/images/October2015/paid...
- bryanrasmussen 1y ago
  it seems reasonable, if you report bugs in things you contribute to and this was allowed there would be a perverse incentive to inject bugs to have something to report on, furthermore if you are a contributor to a project that is the source of the bugs you have potentially an unfair advantage compared to every other potential reporter of bugs. on edit: because obviously you probably become aware of bugs in your own projects before other people do.
  - whizzter 1y ago
    That this would even become a thing for established and widely depended on projects shows how broken our model currently is. In cases like this though, if it involves code from before 2005-2010 the author shouldn't matter since people put very little thought into security back then.
  - justinclift 1y ago
    > an unfair advantage compared to every other potential reporter of bugs. Where is the "unfair" in knowing about more bugs to get fixed? "Fair" (or unfair) isn't a concept which is relevant to this.
  - tsimionescu 1y ago
    Unfairness is completely irrelevant here, there is 0 reason anyone would want a fair playing field for bug bounties, this isn't a competition. The other arguments do make sense, though.
  - alt187 1y ago
    As an end-user, I care very little about "unfair" advantages and a whole lot about actually solving bugs. Plus, pushing intentionally buggy commits in a way that's subtle enough to be noticed, but not so subtle that it seems intentional (once the bug is revealed to be fixed) doesn't sound like the easiest way to make money. Especially on repeat. Wouldn't this be a little suspicious the third time around?
  - guappa 1y ago
    What's unreasonable is that they don't sponsor an important library they use.
- jimbokun 1y ago
  https://devhumor.com/media/dilbert-s-team-writes-a-minivan https://devhumor.com/media/dilbert-s-team-writes-a-minivan
securesaml 1y ago
Google has a program where you can submit patches to OSS projects (including libxslt) https://bughunters.google.com/about/rules/open-source/4928084514701312/patch-rewards-program-rules https://bughunters.google.com/about/rules/open-source/492808... The patches need to fix a systemtic design flaw (which seems like you are trying to do). You are eligible even if you are a contributor: > Q: I'm a core developer working on one of the in-scope projects. Do my own patches qualify? > A: They most certainly do. Additionally, github has: https://resources.github.com/github-secure-open-source-fund/ https://resources.github.com/github-secure-open-source-fund/ Companies have changed after seeing the log4j incident and are open to funding open source security (but we still need more)
- nwellnhof 1y ago
  I'm aware of the Patch Rewards program. The problem is that you have to complete the work first and then hope that you'll be rewarded. They also had a Security Subsidies program with upfront payments but this was discontinued in December 2024. Github's program is restricted to Github repos, making it useless for many projects.
dwaite 1y ago
Infrastructure-wise, XML digital signature implementations have to do transforms to convert the XML to the signed octet stream, and commonly use XSLT engines to do so. There was a fun early bug where one of the transforms that Xerces had was that you could include base64 encoded data, and it would load that as a java class against the transformer interface and execute it.

Wowfunhappy 1y ago

> Google refused to pay bounties for valid reports because I was a contributor to libxslt Huh?

Cyykratahk 1y ago
I'm guessing Google is avoiding the scenario where a contributor "accidentally" commits code with a bug, then later reports the bug they "found".
- Wowfunhappy 1y ago
  I can understand if it's code the reporting person actually wrote, but if it's just someone else on the project that seems pretty ridiculous.
  - motorest 1y ago
    Not ridiculous. It's a clear conflict of interests, and represents a perverse incentive.
    - baq 1y ago
      And it’s easy to fix - sponsor a contributor. It’d be cheaper than the many meetings that were needed to make the removal decision.
      - motorest 1y ago
        > And it’s easy to fix - sponsor a contributor. It’d be cheaper than the many meetings that were needed to make the removal decision. I don't think that's how it works. I mean, how many problems did you ever fixed by dictating how others should spend their own money? Also, apparently some of these issues exist for over a decade. That alone tells you how serious the problem is, and how urgent it needs fixing.
        baq 1y ago
        I'm just saying they've got a bug bounty program but not a bug prevention bounty program, or even a fix a known bug bounty program. The security team has a budget for the realized risks but predictably not for managing unrealized risk in the open source community which they depend on.
        x0x0 1y ago
        > a bug prevention bounty program Particularly for a dep they've chosen to ship in their browser.
        hmcq6 1y ago
        > Also, apparently some of these issues exist for over a decade. That alone tells you how serious the problem is The "serious problem" is that they've known about bugs for 20 years and not committed resources to fix it. The problem is the money.
        motorest 1y ago
        > The "serious problem" is that they've known about bugs for 20 years and not committed resources to fix it. The problem is the money. Who is "they"? Project maintainers? Project users? You? > The problem is the money. So this is a project that didn't require any funding for decades in order to exist. Explain exactly why you believe money is an issue.
  - layer8 1y ago
    People could fix each other’s intentionally introduced bugs and make a living that way. The argument is less convincing when the bugs are a couple years old. There could be an exemption for that, but it’s also more work to verify (Git histories can be fabricated).
    - Wowfunhappy 1y ago
      They could anyway, one person intentionally introduced bugs and the other reports them. The reporter just avoids ever contributing code themself. But doing any of this repeatedly without getting caught seems hard.
    - deleted 1y ago
      [deleted]
- netsharc 1y ago
  But, what about my minivan? https://devhumor.com/content/uploads/images/October2015/paid-debugging-animation.gif https://devhumor.com/content/uploads/images/October2015/paid...
bryanrasmussen 1y ago
it seems reasonable, if you report bugs in things you contribute to and this was allowed there would be a perverse incentive to inject bugs to have something to report on, furthermore if you are a contributor to a project that is the source of the bugs you have potentially an unfair advantage compared to every other potential reporter of bugs. on edit: because obviously you probably become aware of bugs in your own projects before other people do.
- whizzter 1y ago
  That this would even become a thing for established and widely depended on projects shows how broken our model currently is. In cases like this though, if it involves code from before 2005-2010 the author shouldn't matter since people put very little thought into security back then.
- justinclift 1y ago
  > an unfair advantage compared to every other potential reporter of bugs. Where is the "unfair" in knowing about more bugs to get fixed? "Fair" (or unfair) isn't a concept which is relevant to this.
- tsimionescu 1y ago
  Unfairness is completely irrelevant here, there is 0 reason anyone would want a fair playing field for bug bounties, this isn't a competition. The other arguments do make sense, though.
- alt187 1y ago
  As an end-user, I care very little about "unfair" advantages and a whole lot about actually solving bugs. Plus, pushing intentionally buggy commits in a way that's subtle enough to be noticed, but not so subtle that it seems intentional (once the bug is revealed to be fixed) doesn't sound like the easiest way to make money. Especially on repeat. Wouldn't this be a little suspicious the third time around?
- guappa 1y ago
  What's unreasonable is that they don't sponsor an important library they use.
jimbokun 1y ago
https://devhumor.com/media/dilbert-s-team-writes-a-minivan https://devhumor.com/media/dilbert-s-team-writes-a-minivan

securesaml 1y ago

Google has a program where you can submit patches to OSS projects (including libxslt) https://bughunters.google.com/about/rules/open-source/4928084514701312/patch-rewards-program-rules https://bughunters.google.com/about/rules/open-source/492808... The patches need to fix a systemtic design flaw (which seems like you are trying to do). You are eligible even if you are a contributor: > Q: I'm a core developer working on one of the in-scope projects. Do my own patches qualify? > A: They most certainly do. Additionally, github has: https://resources.github.com/github-secure-open-source-fund/ https://resources.github.com/github-secure-open-source-fund/ Companies have changed after seeing the log4j incident and are open to funding open source security (but we still need more)

nwellnhof 1y ago
I'm aware of the Patch Rewards program. The problem is that you have to complete the work first and then hope that you'll be rewarded. They also had a Security Subsidies program with upfront payments but this was discontinued in December 2024. Github's program is restricted to Github repos, making it useless for many projects.

dwaite 1y ago

Infrastructure-wise, XML digital signature implementations have to do transforms to convert the XML to the signed octet stream, and commonly use XSLT engines to do so. There was a fun early bug where one of the transforms that Xerces had was that you could include base64 encoded data, and it would load that as a java class against the transformer interface and execute it.