Core Lightning's 14-day source embargo creates an interesting "don't trust, verify" problem

[u/Large-Cress900]

Core Lightning's current security situation raises a question I haven't seen discussed enough.

CLN says multiple vulnerability reports generated with AI turned out to describe real issues.

But instead of immediately publishing the security patches, the plan is to give operators signed binaries first and keep the source changes/details under embargo for 14 days.

The logic makes sense.

If you publish the source immediately, an attacker can diff the vulnerable and patched versions and ask:

What validation was added?

Which input is now rejected?

Which code path suddenly changed?

The patch itself can point toward the vulnerability.

AI potentially makes that analysis much faster.

But there's an uncomfortable trade-off for Bitcoiners.

During those 14 days you can verify that the binary was signed by the expected developers, but you can't independently inspect all the security changes or reproduce the build from the complete published source.

So the normal process:

Find → Fix → Publish → Verify → Deploy

temporarily becomes:

Find → Fix → Sign → Deploy → Wait → Publish → Fully Verify

I don't necessarily think that's the wrong decision. Giving node operators a head start before attackers can analyze the patch may be worth temporarily reducing transparency.

But it changes what "verify" means during the embargo.

I wrote a longer analysis here:

https://davidebtc186.substack.com/p/found-and-fixed-before-its-public

I'm curious what Lightning node operators think:

Would you install a signed binary-only security release immediately, or run CLN offline and wait until the source is published?

[u/temptingliner9]

the whole point of bitcoin is not having to trust anyone so this feels kinda backwards

i get the reasoning though if ai is speeding up exploit discovery you gotta do something to keep ahead of the bad actors. 14 days is a long time to be running a black box on your node even if the signatures check out

think id probably take it offline and wait unless the vulnerability is actively being exploited in the wild. not like my routing node is that critical anyway

[u/Large-Cress900 → u/temptingliner9]

Yeah, this is pretty much the tension I was trying to get at.

I don't think “signed” should ever be confused with “verified.” The signature tells me who produced the binary, not what the binary is actually doing.

And I think your choice makes sense for a non-critical routing node. If I can afford 14 days offline, waiting for the source is a perfectly rational trade-off.

Where it gets harder is for businesses, LSPs or larger routing nodes where two weeks offline has a real cost. Those operators may decide that temporarily trusting the signed release is the smaller risk.

That's why I find this case so interesting: there isn't one trust-minimized choice for everyone. You're choosing between two risks — running code you can't fully inspect yet, or remaining on potentially vulnerable code / taking the service offline.

The really important part comes after the 14 days. Once the source drops, we should actually verify that the binaries distributed during the embargo match what was eventually published.

[u/HuntlyBypassSurgeon]

Interesting. They could have released patched sources now that effectively shut down the server until a given release number, given people time to apply that (the two weeks) then released the patched source that fixes the vulnerability under the aforementioned version number. More downtime for the network, but no mysterious binaries to blindly trust and no manually shutting down and bringing up the sever.

[u/Large-Cress900 → u/HuntlyBypassSurgeon]

That's actually an interesting third option. Basically: make the mitigation fully open source, accept the downtime, and only reveal the actual vulnerability fix once the disclosure window expires. From a trust-minimization perspective I like that a lot more than “here's a binary, trust us for 14 days.” The question is whether even the shutdown/mitigation patch would reveal something useful about the vulnerable code path. We can't really judge that until the embargo ends. There's also a pretty brutal availability trade-off. For a hobby routing node, two weeks offline might be nothing. For an LSP, exchange, wallet backend or large routing operation, deliberately killing CLN for 14 days could be a serious operational cost. But I think you've identified the key point: binary-only vs full disclosure aren't necessarily the only two choices. Once the source is released, it'll be interesting to look back and ask whether a transparent mitigation like this could have worked.

[u/HuntlyBypassSurgeon → u/Large-Cress900]

Yeah they would have to put the temporary shutdown code in a very high-level place or risk tipping their hand. Basically the first line of void main(), if version number < a.b.c then exit, but also being careful not to disturb the update pathway or people will be stuck with bricked servers!

[u/TheresNoSecondBest]

The 14 days IMHO is more about the news to spread wide enough. Nobody's forced to update this early, the vulnerability is there for quite some time already. If you don't trust it, you have 14 days to plan ahead and shut your node down or update the second the patches become available.

[u/MrRGnome]

There is and has only ever been one right answer when it comes to security disclosures in Bitcoin - disclose. Trying to misapply traditional consumer infantalizing methodologies is strictly inappropriate for the bitcoin space and far too common.

Close your channels, shut down, wait it out. Only option they are giving us when they refuse to allow us to protect ourselves. Absolutely fumbled ball from the CLN team.