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.

▲

securesaml 6 days ago | parent | next [-]

Google has a program where you can submit patches to OSS projects (including libxslt) 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/

Companies have changed after seeing the log4j incident and are open to funding open source security (but we still need more)

	▲	nwellnhof 5 days ago \| parent [-]
		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 5 days ago | parent | prev | next [-]

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 6 days ago | parent | prev [-]

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

Huh?

▲

Cyykratahk 6 days ago | parent | next [-]

I'm guessing Google is avoiding the scenario where a contributor "accidentally" commits code with a bug, then later reports the bug they "found".

▲

netsharc 5 days ago | parent | next [-]

But, what about my minivan? https://devhumor.com/content/uploads/images/October2015/paid...

▲

Wowfunhappy 6 days ago | parent | prev [-]

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.

▲

layer8 6 days ago | parent | next [-]

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).

	▲	6 days ago \| parent \| next [-]
		[deleted]
	▲	Wowfunhappy 6 days ago \| parent \| prev [-]
		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.

▲

motorest 6 days ago | parent | prev [-]

Not ridiculous. It's a clear conflict of interests, and represents a perverse incentive.

▲

baq 6 days ago | parent [-]

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 6 days ago | parent [-]

> 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.

▲

hmcq6 5 days ago | parent | next [-]

> 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 5 days ago | parent [-]

> 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.

	▲	hmcq6 5 days ago \| parent [-]
		I misunderstood and thought this was a google sponsored project and not an open bug bounty. Even still, you're responding in a thread about someone who is trying to do legitimate work on this project and google is not honoring the bug bounty system. A problem google could fix if they just assigned someone to manually review the case, it would take like 15 minutes.

▲

baq 6 days ago | parent | prev [-]

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 6 days ago \| parent [-]
		> a bug prevention bounty program Particularly for a dep they've chosen to ship in their browser.

▲

bryanrasmussen 6 days ago | parent | prev | next [-]

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.

▲

alt187 6 days ago | parent | next [-]

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?

▲

whizzter 6 days ago | parent | prev | next [-]

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 6 days ago | parent | prev | next [-]

> 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.

▲

guappa 6 days ago | parent | prev | next [-]

What's unreasonable is that they don't sponsor an important library they use.

▲

overfeed 5 days ago | parent [-]

How many libraries do you support monetarily?

	▲	guappa a day ago \| parent [-]
		I donate more than I receive (which is 0, despite household names using my software). Do you have more hot takes?

▲

tsimionescu 6 days ago | parent | prev | next [-]

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.

▲

bryanrasmussen 6 days ago | parent | prev [-]

I see I need to clarify what I think about the unfairness aspect.

It is my experience that even much smaller companies than Google would have a Lawyer or multiple lawyers go over the details of how such a program would work.

The lawyers would of course talk to the developers and the project managers and interested parties and define risks. The risk of someone pushing in bugs to then report really seems like a programmer defined risk, but the unfairness thing is a lawyer defined risk. The first you conceive of thinking like a programmer, the second thinking like a lawyer.

But the risk I would assume a lawyer would see is - determining the severity of bugs is somewhat up to the developers and managers at our company, therefore we may encounter a situation in which a person reporting a bug thinks their bug is very severe but we think it is less severe, furthermore there may even be similar bugs in the past that we have paid out large amounts for but in this case we pay out a smaller amount, this will create an appearance of unfairness. The people pursuing the bug bounty have put in work to get the money, we of course will structure our contracts about bug bounty work etc. so that they cannot expect the process to be fair and that this is not a form of employment therefore the payout is not guaranteed, but that only goes so far, and if things look unfair then the shield our contracts offer may be blown apart.

The ability of someone to work on a project, and find bugs in that project quicker than other people gives them an advantage in reporting bugs therefore they need to invest less time to get a potential reward, they can report more bugs quicker etc.

Depending on jurisdiction, and we cover the damn world, this might be a problem because hey can someone who is not part of a project able to sue someone who is part of a problem somewhere because that person got more payoffs based on their access to the codebase of a project. Can our communications be requested to see if we evaluated things in any way unfairly?

What about if we have people on the same project as the guy that is reporting bugs for that project, can it be argued that we favor someone we "potentially" work with? This is another aspect of unfairness. Will they be able to sue and get access to communications regarding bug bounties in any case regarding unfairness - will our contract hold up against this?

For safety's sake let's just disallow these potential pieces of unfairness in the rules of the bug bounty, thus keeping from having any conflict of interest. Oh the developers said maybe someone could put in bugs in projects and then report it, seems legit also good reason we don't allow it. But yes, seems like a nasty can of worms all over, let's not open it.

The point of worrying about the unfairness is not that one thinks even that one would lose the case, but to avoid the case altogether, To have a contract that says essentially you can't do anything about it because we don't have to be fair, but then also remove anything that might look unfair.

▲

jimbokun 6 days ago | parent | prev [-]

https://devhumor.com/media/dilbert-s-team-writes-a-minivan