Them not disclosing doesn't make you safer. The people that want to abuse this could be actively exploiting it shortly after the commit went live. Waiting more time before the blog / marketing release is NOT the help you think it will be.

This is a very, very, old debate in the security community, just read the rest of this thread and you'll see plenty of explanation as to why.

How recursive should their notifications be? Just the tip three distros? The top dozen? Every embedded Linux router company? How about every hosting provider?

They did what they're supposed to without being paid for it. The only other good source of funding for security research besides marketing budgets for security companies will NOT result in a disclosure timeline you'd be happier with. ;-)

External security research happens for one of only a few reasons typically:

1) hobbyists who are learning or just like to do it for fun 2) bug bounties (good luck with those in most open source) 3) marketing for security companies 4) non-public research going to CNO/CNE

If you want to kill 3, the output of 1 will not come close to 4 and the public is NOT better off with fewer public bugs.

Anything else inevitably has worse for the public good.

Having spent that entire time and then some on both offensive and defensive teams, I assure you longer delays after notification do NOT decrease the overall risk to the public.

There's a reason we've landed where we have as a security community.

We have actually been more inspired by Jetbrains lately than VS Code. Take that for what you will.

We do try to pick simple sane defaults while still allowing enough customization to adapt to different workflows.

Actually working on a startup wizard for first time users if they want to more closely replicate the feel of other RE tools since muscle memory is hard to break.

I share your apprehension regarding the current AI landscape changing so quickly it causes whiplash but I don't think a mindset of "it's been fine for 50 years" is going to survive the pace of development possible by better LLM integration.

https://defcon.org/html/links/dc-news.html

First, I literally saw them do shots during a talk yesterday for some first-time presenters. Secondly that WASN'T the "old defcon" either! Drinking is a relatively new tradition in the history of the con. I've spoken twice. Once at DC 17 (no shot offered) and once at DC 23 (shots were offered). There's video proof:

No drinking, DC 17: https://www.youtube.com/watch?v=okPWY0FeUoU Asked to drink, opted for a coin instead (we were asked beforehand): https://youtu.be/6dmvtbrM6hs?feature=shared&t=1153

As recently as last week we had some horrible performance problems but it looks like the queue (https://dogbolt.org/queue) is mostly still fine! Other than the long pole of a few of the decompilers being backed up, things are humming along quite smoothly! Josh + Glenn have done some great work on it! (https://github.com/decompiler-explorer/decompiler-explorer/c...)

And it's no conspiracy theory or intentional sandbagging, you can see the implementation: https://github.com/decompiler-explorer/decompiler-explorer

and if anyone can improve the other tools performance we'd be happy to accept it. We reached out to the Ghidra devs: https://github.com/NationalSecurityAgency/ghidra/issues/5228 but they didn't have any silver bullets for us either.

As far as I know, BNIL (https://docs.binary.ninja/dev/bnil-overview.html) is the only one that is designed to be readable and it still wouldn't make sense to include it in an IL comparison such as the one done here for decompilation in my opinion.

https://github.com/decompiler-explorer/decompiler-explorer/

That said, you're right. It's unlikely we'd ship our entire binaries plus code to live in-browser though the amount wasm stuff people are doing lately is fascinating.