docs: Security policy #838
No reviewers
nex
Aranjedeath
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/MSC
Matrix/Media
Meta
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: continuwuation/continuwuity#838
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "jade/security-policy"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
mostly looks good, some requests/notes regarding clarity
@ -0,0 +8,4 @@| Version | Supported || -------------- |:----------------:|| Latest release | ✅ |We should have a grace period for new releases where we still support the previous release, to give people time to migrate over and whatnot. If this is implicit, it is not clear
Do we have the resources to backport to N versons, and is there a reason why people wouldn't upgrade?
Issuing patches for security vulns isn't usually too big of a task. Sometimes people don't upgrade because they're either unaware or simply haven't had the time to (hell, one of my own servers is still running old conduwuit main 😅)
Backporting to the last release is rarely an issue, but if you don't think it's worth it then we don't need to bother. We'll just have to be extra careful to make sure upgrades go smoothly
@ -0,0 +18,4 @@We appreciate the efforts of security researchers and the community in identifying and reporting vulnerabilities. To ensure that potential vulnerabilities are addressed properly, please follow these guidelines:1. **Email the security team** directly at [security@continuwuity.org](mailto:security@continuwuity.org)Is there PGP enabled on this inbox? If not, I don't think an unencrypted channel should be prioritized for security issues over encrypted ones
This just forwards to all of our continuwuity emails, so not sure PGP supports multi-recipent encryption. We could have a shared key?
But yeah, I agree that we can probably move it down in the list.
pgp does support it, but not in this way. I think the ideal would just be moving the email down the list then
@ -0,0 +22,4 @@2. Contact members of the team over E2EE private message.- [@jade:ellis.link](https://matrix.to/#/@jade:ellis.link)- [@nex:nexy7574.co.uk](https://matrix.to/#/@nex:nexy7574.co.uk) <!-- ? -->3. **Do not disclose the vulnerability publicly** until it has been addressedPeople sometimes accidentally disclose vulnerabilities as they discover them, perhaps a mention that concerns regarding security should go to private channels in case there's any doubt? Means people won't go "hmm I wonder if this is a security- OH NO this is a security issue" in a public channel
Good idea