Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We are retiring our bug bounty program

turso.tech

Post reply on HN
Print view View original

261–270 of 303 posts

Re: We are retiring our bug bounty program

#261

Post by pengaru »

Philip-J-Fry wrote: post #108
hnthrow0287345 wrote: post #101

Earlier quoted context omitted.

I have seen precisely zero consequences for these people because they usually leave after not too long and go somewhere else, sometimes for higher pay. The slower folks end up getting the worse code and no raises in exchange for comradery. But also I have no idea how that situation arises unless the slower folks are just auto-approving PRs. You kind of did that to yourself if you let the new person get away with it.

I can tell you how that situation comes about. You start by rejecting those PRs, saying "write more maintainable code, not quick hacks". Management starts pressuring the original developer "why is it not merged yet, I thought you had it working". That developer hits back with "well, it failed code review, they want me to refactor it". Management goes back to the reviewer, "why did you fail this? It meets coding stand…

wow, that's a charitable take

IME the manager just approves the PR themself to "bias for action", someone else will pick up the pieces

Re: We are retiring our bug bounty program

#262

Post by autoexec »

wiether wrote: post #248
hunterpayne wrote: post #154

Earlier quoted context omitted.

My experience is exactly the opposite. The TT ends up being the last engineer standing a lot of the time. The people who want to have better refactoring and more maintainable code are usually the ones who move on. The TT often stays in the same place for 25 years. Often correcting mistakes they themselves made in the past. I knew one engineer who came in every Sunday night to process missed orders from an e-com syste…

The profile you describe is not a Tactical Tornado to me. A tornado is something big and temporary. Someone who makes a mess but stays to fix it cannot be described as a tornado. I worked with actual TT and with people fitting the profile of your guy. To me they are quite different and have a different impact on the teams they work "with". I would say your guy is more a Sisyphus. The ones I met where thought as hard…

> If your guy works extra on Sunday for free, they're working hard in my books.

Working hard on the wrong thing: endlessly manually processing things the software should be taking care of. Investing that time in fixing the code would be better. Working hard only matters when the effort is well spent.

Re: We are retiring our bug bounty program

#263

Post by toraway »

nottorp wrote: post #210
mackeye wrote: post #82

Earlier quoted context omitted.

:D https://github.com/UnsafeLabs/Bounty-Hunters

Is there a description of this project on any other site? They clearly can't post it's bot bait on the git repo, and maybe not on the leaderboards site because it's linked from the repo. But there must be some announcement about the project somewhere? I'd like to get that to pass it around.

The disclosure about being a honeypot is in the CONTRIBUTING.md:

  Warning

  Heads up: This is a research project — bounties listed here are symbolic and   part of an academic study on open-source contribution patterns. PRs are reviewed for research purposes only and will not be merged into production. If you're looking for paid bounty work, this is not the right repo.
Which makes it slightly surprising those bots with system prompts to find "high value bug bounty targets" or similar aren't deterred by that when they pull the repo.

I guess a sort of task blindness where once they've gone as far as to git clone they've already switched gears from searching Github for qualifying bounties into a find bug->fix bug->open slop PR mindset to close the loop and end the turn? By that point an incidental warning they ingest in passing while looking for the Solana contract vulnerability they already committed to working on in a comment might not even register as relevant to the current task at hand.

Re: We are retiring our bug bounty program

#264

Post by autoexec »

pkulak wrote: post #234
weinzierl wrote: post #181

Earlier quoted context omitted.

My whole career I yearned for green field projects but somehow predominantly worked on existing grown code bases and legacy projects. That naturally meant reading and understanding more code than writing. Sometimes my LOC count was even negative, and I was proud of that accomplishment. Now with AI I write even less and I've given up on the dream to gain fulfillment that way. The ability to quickly understand large am…

Personally, and this is just my wild guess; I think almost no one is _really_ going to learn to code again. That's not a slight on the next generation or anything; I wouldn't know how to code right now if LLMs existed 25 years ago. I love coding, but it's the _result_ that's the real accomplishment. The journey a bit... but having the result always just sitting there, ready to grab with no effort, is too much temptat…

> And as this goes on, folks who can run an LLM _and_ understand/criticize/rework/re-prompt are just going to get more and more scarce.

As long as LLMs keep constantly making mistakes and introducing bugs and humans keep having to verify their output and clean up after them it should mean plenty of work for the few humans alive who can actually understand the code. Future AI models being trained on an increasingly large body of vibe coded bug-filled slop will only make the problem worse.

A small number of people with skills that are in demand will tend to make good money, and jobs that make good money will attract more people into learning how to code.

Re: We are retiring our bug bounty program

#265

Post by Neywiny »

triceratops wrote: post #96
stronglikedan wrote: post #56

Earlier quoted context omitted.

> almost every single thing we were doing had to use the library function instead of the one we wrote

Why not proceed file-by-file or directory by directory?

It was all in one giant multi thousand line file for one language and another for another. Which is also kinda an issue

Re: We are retiring our bug bounty program

#266

Post by mort96 »

rvz wrote: post #256
mort96 wrote: post #244

Earlier quoted context omitted.

Didn't people realize that those automated pegging algorithms don't really work after the last round of stablecoin collapses

Except not all stablecoins are the same.

They essentially are to me, because I don't know how to differentiate them. Before the collapse, I would not have been able to look at the ones which collapsed and the ones which didn't and predict the outcome.

Re: We are retiring our bug bounty program

#267

Post by singpolyma3 »

kccqzy wrote: post #170
singpolyma3 wrote: post #66

It's a bit odd that this comes today after so many other projects reverse this finding.

Reverse what? Let’s take curl as an example. Daniel Stenberg wrote about how he had to stop curl’s bug bounty program due to prevalent AI slop[0]. He also wrote about how he eventually restarted security bug reports without a bounty[1]. It turns out that without a bounty, the reports are higher quality. It almost seems like by removing the monetary incentive, it attracts people who are reporting bugs due to genuine a…

curl's posts never imply that the money is the main factor. But it may indeed be a factor that's been missed.

Re: We are retiring our bug bounty program

#268

Post by [deleted] »

jquery wrote: post #19
ToucanLoucan wrote: post #7

Oh look it's more of exactly what AI skeptics said would happen: low effort bullshit generated at scale making life hell for people actually trying to make things. That's wild. Edit: it is genuinely wild, I don't know of another product category that selects so perfectly for the WORST type of person to be it's enthusiast. Just every single person I see hyped about AI is fucking insufferable on at least one and usuall…

I think people would be more interested in listening to "AI skeptics" if they offered realistic solutions to the problems they predict. Pandora's box has been opened, let's deal with the consequences now instead of trying to shut the box which cannot be shut.

[deleted]

Re: We are retiring our bug bounty program

#269

Post by toraway »

ffsm8 wrote: post #102
wg0 wrote: post #86

Earlier quoted context omitted.

This is profound and beautiful description. Thank you for sharing. Totally can relate to that. Been there, seen that.

Do people like that exist? Totally. But seriously, I guarantee you the opposite is more common- the incompetent devs which can't manage shipping anything, keep trying to do "surgical and small edits" after 1 week of thinking about them and then have them blow up in prod for someone else to fix quickly because if it's up to them, it'll take 2-3 sprints 10 years ago I was a lot closer to what y'all talking about. After…

From the excerpt it sounds like the author is just describing one specific archetype from within a list of others included in the book and doesn't make any claims about it being a uniquely common type within every org, or the most common type of bad engineer in general.

In fact it gives the opposite impression by specifying "at least one", which implies the category is supposed to be distributed widely enough to be recognizable in an org of sufficient size, but not dominating the ranks of software developers in droves. That seems more like a strawman you're arguing against.

Re: We are retiring our bug bounty program

#270

Post by HeyLaughingBoy »

chapinb wrote: post #17
wg0 wrote: post #8

Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. We all had that one "productive" engineer in our teams who would write huge PRs that would have large swaths of refactoring whether warranted or not and that was way before anyone even could imagine in their wildest dreams that neural networks could generate that huge amounts of code. The net effect of such…

Sounds a like a tactical tornado, made me think of this paragraph: “Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the…

When I was being trained in Team Software Process (https://en.wikipedia.org/wiki/Team_software_process) our TSP coach mentioned someone on an adjacent team that Management loved because he stayed late, worked weekends and was generally seen as a hero by them.

The problem, as the coach pointed out, was that that kind of behavior was pathological and showed poor planning and bad project management. Cheering on someone, even someone with the best of intentions, who was working like that was sending exactly the wrong message and reinforcing the wrong behavior.

But we already knew that!

Post reply on HN