TechPulseTechPulse
Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

50% Positive

Analyzed from 1156 words in the discussion.

Trending Topics

#bugs#software#fix#exploit#security#fixes#process#bug#rclone#those

Discussion (26 Comments)Read Original on HackerNews

nickcw•about 2 hours ago
This describes my life as an open source maintainer at the moment!

In the first 10 years of the rclone project we received about 20 security disclosures through GitHub. We had to deal with over 40 in the last month! That has taken a huge amount of my time, even using AI tools to triage and come up with fixes for review.

The hit rate for those security disclosures is pretty good - about 75% of them have a nugget of something which needs looking at. The configurations for rclone have got increasingly unlikely so I'm hoping they will dry up eventually.

I was considering just merging the fixes straight to master just to make my life easier rather than holding a dozen independent security fixes on branches and merging them at the point release and hoping not to have too many conflicts to fix up. I've decided to stick with the process for the moment.

GitHub assigns CVEs for the advisories. Before the AI apocalypse they took 2-3 days for an assignment but now it they are running at 3-4 weeks so I have to send the point releases out with CVE-PENDING in the changelog which isn't ideal.

Not sure what the solution is, but it is definitely a problem for us.

dannyw•about 1 hour ago
Thank you for making and maintaining rclone. It is truly a blessing.
caminanteblanco•13 minutes ago
Thank you so much for maintaining rclone! That project is literally the only thing that makes Google Drive an acceptable experience on Linux.
Kubuxu•about 1 hour ago
As long as you are not running a paid bounty program. Otherwise now you are getting 40 per day.
zmgsabst•about 1 hour ago
I can’t comment on if it applies to your workflow, but one process I’ve used is to aggregate and land ~10 security patches at a time. Eg,

- grab a group of (related) bugs/defects/vulns

- fix them on a branch like bug-batch-XXX

- run that group through the verification, landing in main, CI/CD flow to amortize process cost

- repeat as needed to process backlog

My experience is that process often has irreducible time (eg, two days due to reviews by various parties); but that time slot can be shared between several bugs in a single PR — especially if you have several related to the same feature.

dataviz1000•about 1 hour ago
> even using AI tools to triage

Can you discuss this? I might be able to help.

godelski•about 1 hour ago
It's easier to find bugs, fix them, yet there's less will than ever. My bosses just want speed and will give me a 30 minute lecture on why I don't need to solve a bug that Claude solved in 5 minutes, I've verified, and it's already in an open PR. All the while we're pushing out bugs faster and faster.

No matter how good AI gets at fixing bugs we'll never fix them when there's no will to fix things. Software will never be good if there's no will to make good software. The problem has always been about will. To many better products. It's insane that in a time where we can do better on speed and quality we still choose speed and tell ourselves it's velocity

novia•6 minutes ago
!!! You described my experience in the workforce to a t! So frustrating that tech managers look at tech debt as a thing to be maintained at a certain level instead of allowing us to achieve perfection
ryandrake•about 1 hour ago
Most places I've worked have been infuriatingly uninterested in fixing bugs, and would release software with major known bugs and a vague plan to fix them later. Of course, when "later" came, there were more features to cram. No time to fix those bugs.

I'm hoping one of the unintended side effect of it being essentially free to find and exploit (and fix) software bugs is that companies become less cavalier about shipping bugs in their software. Unlike most of the industry I don't believe "bugs are inevitable." Bugs are a choice developers make when they're rushing and careless and when all of their incentives are to ship quickly. You can ship bug-free software but it takes (or used to take) a really long time and a lot of care, care that commercial software developers just don't ever seem to muster.

Maybe when their software is getting 0wned over and over and 30 security issues are published a day, they'll start caring and taking their time.

vasco•about 1 hour ago
If your boss asks for X feature and you split it into 4 PRs, 3 that implement X and a 4th that fixes a security bug, how would they know? Someone that uses those 30mins like that isn't reviewing your PRs themselves. Just fix it and be done with it. You only needed to argue with the boss when you needed to make time for it which would delay something else. If it just appears done they'll just react with clap emoji later when you announced you also fixed this extra thing.
supriyo-biswas•27 minutes ago
You haven't worked at conservative software shops I guess. The last place I worked at had this huge song and dance with you trying to raise a PR that looked irrelevant to the task at hand would lead to meeting with your lead dev, your manager and your skip level as you tried to explain why the bug needs fixing...
tough•less than a minute ago
holy shit that sounds like a nightmar-ish work environment
johnbarron•about 1 hour ago
You will see, they will change both laws and expectations, to say its normal for software to always have terrible bugs. You can always solve a problem by lowering your expectations. :-)
flanked-evergl•about 1 hour ago
What law says software may not have bugs?!
odo1242•20 minutes ago
Not explicitly laws, but like contracts, regulatory requirements, SLAs all indirectly enforce that
yieldcrv•about 1 hour ago
My boss is a big yapper too

Very low signal information, preemptively trying to cover every rebuttal despite nobody ever planning on making one, in the few times someone does he plays devils advocate endlessly

Like bro just let us babysit these agents, everything’s going to happen

bri3d•about 2 hours ago
I don't think this is new with LLMs (finding an exploit based on a few words offhand has always been a fun part of exploit development), but it's scaled and democratized to mass exploitation of low value targets. Backing exploit PoCs out of patches, commit messages, and random overheard or over-read sentences is a practice as old as vulnerability research. The difference with LLMs is that an explosion in actors "skilled enough" (human or not) has enabled sloppy / low-skill "exploit the whole Internet" actors in a way they weren't previously enabled.

I do agree with the author's ideas, though; most of these are things that should have been done much sooner, and I suppose it's good in a sense that there is a forcing factor now.

happyopossum•about 1 hour ago
> Backing exploit PoCs out of patches, commit messages, and random overheard or over-read sentences is a practice as old as vulnerability research

True, but it used to take days or weeks of research, testing, and RE to get those PoCs.

Today the entire chain - reading commits, RE patch binaries, building exploit, scripting exploit scan, $profit - can be fully automated and happen in minutes or hours.

saghm•25 minutes ago
Sounds like the next step is to start rumors about vulnerabilities so that someone else will find them and you have plausible deniability. "Hey, did you hear? Someone told me <competitor company> might be leaking their logs from a publicly accessible endpoint..."
loeg•about 1 hour ago
No mention of memory safe languages? Sure, it does not help existing projects, and sure, of course you can still have logic bugs (or memory bugs using escape hatches like unsafe). But they do help significantly in reducing the number of exploitable bugs.
avsm•39 minutes ago
OCaml (the language I use in the post) is an extremely memory safe language, but there are plenty of higher level logic issues that spring up.

LLMs are extremely good at finding corner-case vulnerabilities in C bindings even within a memory safe language; see for example the fixes in an OCaml crypto library here: https://discuss.ocaml.org/t/the-series-of-mirage-crypto-rele...

Tomte•34 minutes ago
So we have automated Thomas Pornin?
zingababba•39 minutes ago
Transferring ideas in their abstract form is entirely possible now. What this blog post describes I believe even undersells the current reality. I've had success with finding crits by pasting in extremely high level or abstract concepts. I recently went from a talk abstract (3-4 sentences) to crits lol (finding that vuln type).
petesergeant•30 minutes ago
Even that sounds too involved, just tell the agent that one exists, even if it doesn’t…

https://sgnt.ai/p/terrible-mistake/

zb3•about 2 hours ago
Dario Amodei would not be happy about this.. listen, you're not the choosen one! You can't find vulnerabilities, even in your own code, you must politely apply for permission, but if it's not granted, you must accept your fate and stop developing software.

This is the only way forward, open weight models must be illegal. Thanks for understanding.

skybrian•about 2 hours ago
They were not happy about it and loudly warned everyone it was coming, but instead of listening a lot of people said LoL MaRkEtInG.