Hi,

I'm writing to note, out loud, that we've recently made changes to the 
development team's security policy.  Like basically any open source project, we 
offer no warranty, guarantee of suitability for a given purpose, or a promise 
of support.  But again, like many projects, we document the way we tend to 
behave, and what you can probably expect us to do.  In the past, our policy was 
fairly vague, and was sometimes contradictory across sources.  I believe it is 
now clear and consistent — if you find a contradictory claim in the /dev site, 
tell me and I'll fix it!

*How we address security bugs:*

Lots of bugs can affect the security of a system in lots of ways.  Some bugs 
are dramatic, severe, and easy to exploit.  Others are tiny, subtle, and 
seemingly harmless flaws that can be put together to create a severe exploit.  
Treating all of these as equally dangerous *does* protect against both kinds of 
bug, but only if the handling of bugs doesn't affect the overall sustainability 
of development.  With LLMs creating a drastically reduced cost to find tiny 
bugs, the cost of embargoed, coordinated disclosure for every bug is not 
sustainable.

Instead, we test bugs this way:
 • can the bug be exploited on its own, not in combination with a second 
theoretical defect?
 • does the bug occur in a configuration that a reasonable administrator would 
deploy?
 • does the bug rely only on non-experimental features?
 • does the bug create lasting harm?  that's corruption or exfiltration of 
data, SSRF, and others; it is *not* a crash or temporary DoS
If *all* of these conditions are true, expect us to embargo the fix and perform 
coordinated disclosure.

Otherwise, we are likely to fix the bug on master and backport it in an 
upcoming point release to whatever version we're patching right now.

You can read the full classification policy 
<https://www.cyrusimap.org/dev/support/security-classification.html> on the 
project website.

*The version we're patching right now:*
 • security bugs get patched on the master branch, when master is affected
 • and the most recent stable branch, when it is affected
Right now, the most recent stable branch is cyrus-imapd-3.12.  We don't plan to 
make new releases of v3.10 or v3.8.  It's possible, when some future v3.14 
launches, that we'll patch v3.12 for a while, too.  But it's not what we've 
documented, and you shouldn't expect it.

As we work more on improving the structure of the code and performing more 
significant retrofitting of systems, the cost of backporting across multiple 
releases goes up.  We want to focus on moving forward.

This policy is covered in the project's SECURITY.md 
<https://github.com/cyrusimap/cyrus-imapd/blob/master/SECURITY.md>.

-- 
rjbs

------------------------------------------
Cyrus: Info
Permalink: 
https://cyrus.topicbox.com/groups/info/Tc0496b28fbcb4994-M51bab2c9f0a24286aeaffef1
Delivery options: https://cyrus.topicbox.com/groups/info/subscription

Reply via email to