Promise of getting more money is not a justification for selling exploits to the criminals. Even if Apple had no bug bounty program, reporting it responsibly is the moral thing to do.
That's easy to say when you're not a security researcher whose income depends on getting paid for finding vulnerabilities—a career that wouldn't exist if Apple hadn't created the bounty program in the first place. It's really bad when you do good work that a third party goes back on their promise to pay you for: it's not always possible to accept the L and move on without pay.
I'm a security researcher, but it's true that my income doesn't depend on getting paid for security vulnerabilities[1]. On the other hand, I'm old enough to remember when bug bounties didn't exist and yet (most) people did the right thing and disclosed their finds responsibly.
If the bug from OP falls under Apple's bug bounty and yet Apple refuses to pay, it's a very shitty behaviour and I hope they're forced to pay by the backlash and the researcher is made right. But if not, the reasonable response is to stop doing security research for free for Apple, not doing research with a goal of using it immorally due to a kneejerk reaction. If Apple stops their bug bounty program today this is still not a justification to look for vulnerabilities in their products and sell them on the black market.
[1] I'm mostly dealing with the people abusing the vulnerabilities, so that may influence my worldview.
It's pretty undeniable that there exists a significant cohort of folks whose sole reason for getting into security is to find vulnerabilities to collect bounties. Beg bounties are that taken to an extreme.
> But if not, the reasonable response is to stop doing security research for free for Apple, not doing research with a goal of using it immorally due to a kneejerk reaction.
I'm sure lots of people will! But that won't necessarily stop folks from saying "I've discovered a vulnerability that would yield me an amount of money that would substantially improve my near-to-medium-term quality of life" and doing what's necessary to profit from that. Apple's program _necessarily_ inflates the amount of money a vulnerability sells for through immoral channels regardless of whether anyone is participating in it.
> If Apple stops their bug bounty program today this is still not a justification to look for vulnerabilities in their products and sell them on the black market.
This might be true for you, but that doesn't mean it's true for even a majority of other people.
I was disappointed by its architecture too. You must write intermediary files, you must call qbe as a separate binary, and you must write the resultant objects to disk.
If I recall correctly, the author has no interest in re-architecturing qbe like this.
The way I handled interviews during my short stint as a manager was to just ask questions related to the task the person was going to do. No general "coding questions", no need for that, the specific topic they'll be working on.
"Have you heard of X? How would you deal with Y in situation Z? Your CV says you worked on A, have you also looked into B? Any guess why we went with B instead of A for C?"
They didn't need to give the exact answer we wanted, the questions they asked in response often told us more than the straight answers.
Everyone I hired is still at the company and one of them sped up our tool by an order of magnitude. No coding challenges needed.
Really cool tool, sadly the code editor is glitched out for me (I can't select all the text, using Edge if it helps). Some bugfixing and you have a really good tool on your hands.
I don't really have much use for it though as the websites I tend to work on are either fine with a slightly customized prebuilt template or are more full-on web-apps in nature.
I recently implemented a compacting garbage collected arena in C, was surprised at how simple it was to make (though I need to still improve some things). I wonder why it's not used more? Just keep the really huge non-temp data buffers in a different datastructure so they don't need to be compacted, otherwise you can go wild with allocations and never have a use-after-free.
C API is the big one. Unless your language is officially supported by Qt (meaning C++ or Python) you're basically screwed.
Secondly would be the license, while they're both LGPL these days, that wasn't always the case, and the current Qt company is highly hostile to open source.
Tying slots to shadow DOM was a huge mistake. There are better solutions for style encapsulation. Sadly a lousy standard that holds web components back.
Precisely this, the moment they announced they wanted to break backwards compatibility with new GTK versions every 6 months or whatever it was they made it very clear it is exclusively a Gnome API for OSS projects and nothing else.
They backtracked a bit on that but they'll still replace GTK4 with GTK5 at some point, probably deprecating context menus or whatever else this time. Clowns.
The first release of GTK3 that could be considered stable was 3.20. Either way, I'm talking about GTK4, where the original plan was 6 months of breaking releases, stabilization in version 4.6, followed by starting work on the incompatible GTK5, to be released 2 years after the first GTK4 release.
The backlash was so big they at least changed the versioning scheme, but the "break shit every 2 years" is still in full force.
GTK3 did not break its C API. The CSS you could inject was arbitrary and undocumented. They stabilized and documented that in 3.20, yes. I think its very dishonest to say the toolkit was breaking, the vast majority of GTK3 apps didn’t have regressions IME.
reply