eyalitki

You literally just said your company released an exploit demo before disclosing some of these vulnerabilities to the vendor.

As for your suggestion, I was an infosec researcher, I worked for 3 years with vendors to help them patch before I can even tweet anything about my research. I even flew to their HQ to assist in patching when needed. After Covid I transitioned to a development role, and now I'm on the other end, handling security reports from researchers.

Based on this dual point of view, let me tell you that for a security engineer in Apple that will learn from your video about vuln your company did not even disclose yet, this karma harvesting is as far from "coordinated disclosure" as possible. Their managers will be fuming, and the stress they will be in given the media frenzy will be off the charts.

What is the value of revealing anything at this time point, when no patch is out? What use is it for the public?

Just last Black hat there was a "glimpse disclosure" that was later followed with proper fixes and details. I gave my AI agent the details that were supposed to be "useless", before the patch was out, and it found the vulnerability in less than an hour.

We shouldn't even enter this game. And with the track record of this specific group, I didn't exactly get the impression that their incentive is to help fix things, but rather to promote their brand while others be damned.

Aside from bragging how cool they are, what value is there for demonstrating a yet-to-be-patched vulnerability? I don't understand why old-guard infosec stars from Calif can do as they want, responsible disclosure be damned.

Just as a reminder for some folks here: During their WeWorm research in July–September 2026, Calif didn't stop at proving RCE to Tencent—they spent an extra week using AI to build a fully functional, self-propagating zero-click worm across three live phones, triggering temporary account bans from Tencent during testing.

I gave the model my usual question of "I got a raise from X to Y, please explain what is the impact on my net salary". Answer was detailed and nailed all payroll edge cases, only to miserably fail in basic math at the end. It tried to calculate 430 minus 60 and got 410.

It didn't compress the data. It understood it is an artificial sound file, reverse engineered it, and then encoded the source if it instead of compressing the output

Comparison was done in the scope of coderabbit AI code review tool, which sadly makes it practically irrelevant.

My personal experience as a software engineer, and a former security researcher who did manual code audit, is that this code review tool has such poor results that it isn't worth the "noise" and friction it causes developers during C/I code review

OpenAI has released the specifications of the Multipath Reliable Connection (MRC) protocol, and they are now publicly available as part of Open Compute Project (OCP) foundation.

MRC, which is already being used by OAI in production for training their models, aims to provide robust network utilization, allowing improved bandwidth while also efficiently handling network failures automatically at routing level.

Dup of: https://news.ycombinator.com/item?id=47952181

The presented LPE vulnerability was gradually introduced to the Linux Kernel through refactors and optimizations, each commit making sense on its own. The vulnerability itself was exploitable since 2017 (!) and also doubles as a container escape.

The employer doesn't "allow" them to take "time off" to fight as part of the IDF as reservists. This is the law in Israel, and has nothing to do with any employer whatsoever. During this time, Israel's National Insurance is reimbursing the employer for the salary of absent employees.

OK, now I understood the gap. There is a technical limitation for relocation resolution when the relocation is against a different section. This means that for function sections we de-facto have no relocation finalization, only conversion of symbols from "global" to "local".

Hence, for a "file-sections" flag, we would only resolve relocations within a given file, but will leave intact relocations that cross the file boundary. Accordingly, this means that "function-sections" is identical to generating a static bundle object per original object file, and bundling them all together inside a .a archive.

Correct me if i'm wrong, but wouldn't "file-sections" be identical to generating a static bundle object per original object file, and wrapping them all inside a .a archive?

Thanks, appreciate your feedback. Crossing my fingers that my PR for GNU ld will go as planned.

> Regarding --whole-archive, is it correct that it would be the default and you could opt-out of it with the function-sections/gc-sections combination?

This is the current intention, as implemented in the up-to-date draft: https://github.com/bminor/binutils-gdb/commit/99aef6ba8db670.... Please note however that one would no longer need to specify the "--whole-archive" flag, hence resolving issues with potential duplicate placement of the static library in the linker's CLI.

> Are there cases in which function-sections doesn't work (GCs too much) but a hypothetical "file-sections" does? For example cases in which the code relies on side effects of global constructors, but those would be left out by function-sections?

Good question. In the first article in this series I discussed issues with global constructors and was pretty much waved away, being told that code should not be written this way. One of the members of the ELF committee did suggest an alternative for handling it yet pretty much mentioned that there are still missing pieces that require handling for their proposal to work (https://groups.google.com/g/generic-abi/c/sT25-xfX9yc/m/NRo0...).

There is nothing magical in resolving the local relocations. It is just that current static libraries (static archives of plain .o files) are produced directly using "ar" and don't even go through the linker... The changes to the linker so to apply the relocation finalization are less than 50 lines of code on top of the existing "ld -r" that creates a relocatable object (which despite its name, does not handle relocations).

The key point in the proposal for a static-bundle-object is to properly handle static libraries as linked objects, instead of as a bunch of plain .o files.

OP here, it was also my opinion that the handling of static libraries should significantly be improved, and ld should have a "--static-lib" flag to properly handle it. Sadly, the ELF committee prefers a more subtle approach, hence even the proposed build of the static bundle object is done on top of the existing "ld -r", and the output is still wrapped inside a .a archive for compatibility.

I hope that once integrated to linkers the adoption of this new format will help convince that it deserves significantly better tooling.

The article is a follow up for an earlier thread of mine that was published here a few months ago: https://news.ycombinator.com/item?id=44613791.

While the previous article presented the problem domain (multiple issues with using .a archives of plain object-code files for static libraries), this article presents the technical white paper that formally proposes an alternative format (accompanied by a POC on top of GNU's ld), as well as the gist of the ELF committee's discussion about the proposal.

Given the decision of the ELF committee, the format will be judged by adoption in practice and the feedback it receives from users. In other words, your opinion is more than welcome.

In the world we have more than just bugs. We also have features, and refactoring and whatnot. Prioritization should be done across all tasks, so a bug could be "medium" but the team might not even work on bugs this week unless they are a show stopper.

Isn't this policy overruling the judgement of the team/product lead and focuses too much "only" on the bugs?

It would be interesting to know how many of bugs are triaged and declared as "won't fix" in order to comply with the zero bugs policy.

Aside from that, while it might seem like an ideal engineering culture, I find it a bit extreme. The harsh SLA leaves little room for prioritization. Sometime the team is in fact working on a tough integration deadline, and medium-level bugs can wait for it to finish.

Going over my current list of bugs, some are minor and can wait to the last mile of the release and some will be resolved by new features we have in planning. I do aim to minimize the list of bugs and even my email inbox is based on a "zero inbox" policy. Still "zero" in this case is some small epsilon that is under control, and will go down to zero if no new bugs/emails arrive in the meantime. Call it a sliding window of epsilon width, but it almost never really reaches zero.

Not sure what is the measurable metric here, and what will be considered a success in this trial period.

Propagating the fix downstream depends on the release cycles of all downward vendors. Giving them a heads up will help planning, but I doubt it will significantly impact the patching timeline.

It is highly more likely that companies will get stressed that the public knows they have a vulnerability, while they are still working to fix it. The pressure from these companies will probably shut this policy change down.

Also, will this policy apply also to Google's own products?

If someone needs a wrapper for a technology, that modifies the output it provides (like meson and bazel do), maybe there is an issue with said technology.

If pkg-config was never meant to be consumed directly, and was always meant to be post processed, then we are missing this post processing tool. Reinventing it in every compilation technology again and again is suboptimal, and at least Make and CMake do not have this post processing support.

Yeah, but when the product is an SDK, and customers develop on top of it (using their own toolchains) there isn't a lot left for me to play with.

1. "Advanced" compilation environments (meson) probably limit this ability to some extent. 2. Package managers (rpmbuild for instance) mandate build with debug symbols and they do the strip on their own so to create the debug packages. This limits our control of these steps.

Agree, there should be a prefix. But if 2 of my dependencies didn't use a prefix, why is it my fault when I fail to link against them?

Also, some managers object to a prefix within non-api functions, and frankly I can understand them.

RHEL tried that in that past with 64KB on AARCH64, it led to MANY bugs all across the software stack, and they eventually reverted it - https://news.ycombinator.com/item?id=27513209.

I'm impressed by the effort on Google's side, yet I'll be surprised if this effort will pay off.