From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Bitcoin Core security policy update
Date: Thu, 22 Oct 2026 18:07:17 +0000 [thread overview]
Message-ID: <1ehBdwhbU-1cUjU5SjRxn75XNUBvIfNbkfqPCJRFPlOfsBu5gHWotmNRNxcMirTl1baT2H-zBfJMeWM6rl-XJG8zV6gHf8vQ9b_TRB9vnIk=@antoinep.com> (raw)
Hi,
We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered. This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes.
Any security policy is going to make a tradeoff between two goals that are in tension: transparency and giving users sufficient time to upgrade. Transparency helps level the playing field between attackers and defenders, but can also make vulnerabilities public before users have upgraded.
Because of the nature of our project, coupled with a slow upgrade culture, our security policy favours a longer embargo period. This generally means security fixes can't be backported, and only become available with users along with the next major release.
For these issues that are easy to find, this is the wrong tradeoff. The embargo period achieves little but it delays the availability of a fixed release. We are therefore updating our policy disclosure to accommodate those.
During triage we may flag a vulnerability as easy to discover. In practice, we expect those to be issues that can be found with a simple prompt to an LLM, but the classification is not restricted to those. For such issues, we will backport a fix to all currently maintained releases, and cut a relase as soon as possible. We will publish some details in a security advisory along with the fixed releases.
Our updated security policy is available at https://bitcoincore.org/en/security-advisories
Antoine Poinsot
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1ehBdwhbU-1cUjU5SjRxn75XNUBvIfNbkfqPCJRFPlOfsBu5gHWotmNRNxcMirTl1baT2H-zBfJMeWM6rl-XJG8zV6gHf8vQ9b_TRB9vnIk%3D%40antoinep.com.
reply other threads:[~2026-10-22 18:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='1ehBdwhbU-1cUjU5SjRxn75XNUBvIfNbkfqPCJRFPlOfsBu5gHWotmNRNxcMirTl1baT2H-zBfJMeWM6rl-XJG8zV6gHf8vQ9b_TRB9vnIk=@antoinep.com' \
--to=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox