From e46216916479ab1e36fdc73d1ba4bfda82e34da8 Mon Sep 17 00:00:00 2001 From: Dominic Couture Date: Tue, 16 Mar 2021 23:06:25 +0000 Subject: [PATCH 1/2] Add note about feature flags --- general/security/developer.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/general/security/developer.md b/general/security/developer.md index 9dc0a172..249f3ebf 100644 --- a/general/security/developer.md +++ b/general/security/developer.md @@ -142,6 +142,17 @@ versions. It also helps to reduce the possibility of having unwanted side effect as the fix will be focused on the issue. Improvements can be done publicly after the security release is done. +#### Feature flags + +Security issues normally aren't implemented behind feature flags, even if the flag defaults to enabled. +The reason for that is that we don't want to introduce any "make my GitLab instance vulnerable" options. + +There is one exception to that guideline and it is for security fixes that change the original intended +design of a feature. If we had overseen a certain security aspect of a feature while designing it and we +introduce a breaking change to it, we can add a feature flag that defaults to enabled for maximum security +and mention the breaking change in the security release blog post with a note about how to roll back to the +old behavior and the consequences of doing so. The feature flag should be removed in the next major version. + ### Backports Because all security fixes go into [at least three monthly releases], three additional branches -- GitLab From 005b1075025265484a68a4e4bab7c254b8ec7cef Mon Sep 17 00:00:00 2001 From: Dominic Couture Date: Wed, 17 Mar 2021 01:45:46 +0000 Subject: [PATCH 2/2] Update developer.md --- general/security/developer.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/general/security/developer.md b/general/security/developer.md index 249f3ebf..bbf2ff13 100644 --- a/general/security/developer.md +++ b/general/security/developer.md @@ -144,13 +144,14 @@ the security release is done. #### Feature flags -Security issues normally aren't implemented behind feature flags, even if the flag defaults to enabled. -The reason for that is that we don't want to introduce any "make my GitLab instance vulnerable" options. +Security issues normally aren't implemented behind feature flags, even if the flag defaults to the secure +configuration. The reason for this is that we don't want to introduce any "make the GitLab instance vulnerable" +option in the product. -There is one exception to that guideline and it is for security fixes that change the original intended +There is one exception to the guideline above and it is for security fixes that change the original intended design of a feature. If we had overseen a certain security aspect of a feature while designing it and we -introduce a breaking change to it, we can add a feature flag that defaults to enabled for maximum security -and mention the breaking change in the security release blog post with a note about how to roll back to the +introduce a breaking change to it as a fix, we can add a feature flag that defaults to the secure configuration. +The breaking change should be mentioned in the security release blog post with a note about how to change to the old behavior and the consequences of doing so. The feature flag should be removed in the next major version. ### Backports -- GitLab