Skip to content

Allow administrators to provide public security contact information

Nick Malcolm requested to merge 433210-security-txt into master

What does this MR do and why?

Allow administrators to provide public security contact information

Organizations can facilitate the responsible disclosure of security issues by providing public contact information. The standard way to do this is by using a security.txt file.

This MR introduces this feature by adding:

  • a new application setting (text, max 2048 chars)
  • updated admin UI to configure this instance-level setting
  • updated application setting API to configure the setting
  • a new controller to render the content when present
  • updated documentation describing the feature and how to use it

When present, the content will be available at https://YOUR_INSTANCE/.well-known/security.txt. Authentication is not required to view this file.

When the content is not present it will return a redirect for unauthenticated users, and a 404 for authenticated users. This maintains the behaviour of master to avoid introducing a new method for fingerprint a GitLab instance's deployed version.

Resolves Add support for security.txt (#433210 - closed)

Changelog: added

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Scenario Before After
Signed out HTTP/2 302
location: https://gdk.test:3443/users/sign_in
HTTP/2 302
location: https://gdk.test:3443/users/sign_in
Signed out with content N/A Screenshot_2023-11-30_at_16.55.49
Signed in with no/blank content HTTP/2 404 HTTP/2 404
Signed in with content N/A Screenshot_2023-11-30_at_16.55.49
Signed in as admin Screenshot_2023-11-302-04_at_17.09.206.28.32 Screenshot_2023-12-04_at_16.59.35

How to set up and validate locally

Observe the current behavior:

  1. Go to https://YOUR_INSTANCE/.well-known/security.txt and see that a 302 Redirect is returned (master behaviour)
  2. Log in as any user / an admin
  3. Go to https://YOUR_INSTANCE/.well-known/security.txt and see that a 404 Not Found is returned (master behaviour)

Check out 433210-security-txt and restart GDK.

  1. Log in as an admin
  2. On the left sidebar, select Search or go to.
  3. Select Admin Area.
  4. Select Settings > General.
  5. Expand the Add security contact information section
  6. Enter your content in the text area
  7. Select "Save changes"
  8. Go to https://YOUR_INSTANCE/.well-known/security.txt and see that the content is returned (new behavior)
  9. Log out
  10. Go to https://YOUR_INSTANCE/.well-known/security.txt and see that the content is still returned (new behavior)
  11. Log in again as admin
  12. Delete the security contact information
  13. Go to https://YOUR_INSTANCE/.well-known/security.txt and see that a 404 Not Found is returned (maintains master behaviour)
  14. Log out
  15. Go to https://YOUR_INSTANCE/.well-known/security.txt and see that a 302 Redirect is returned (maintains master behaviour)
  16. Modify the setting via the Application Settings API (see below), and observe the changes at https://YOUR_INSTANCE/.well-known/security.txt
curl -X PUT -H "PRIVATE-TOKEN: $GDK_ADMIN_PAT" "https://gdk.test:3443/api/v4/application/settings?security_txt_content=Contact:%20mailto:security@acme.co%0AExpires:%202024-12-31T23:59Z"

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

  • I have evaluated the MR acceptance checklist for this MR.
    • You have considered the technical aspects of this change’s impact on GitLab.com hosted customers and self-managed customers.
      • There should be zero impact; it's opt in and disabled by default. The current behaviour (a 302 or 404 depending on authentication) is maintained.
      • We already use the /.well-known/* path for other features, so it won't conflict with a namespace
    • You have tested this MR in all supported browsers, or determined that this testing is not needed.
      • I don't believe it is warranted. I copy-pasted from sibling templates so there shouldn't be any browser-based difference that doesn't already exist in the other templates
    • This MR is FOSS only
    • The UX is copying an existing pattern, so I'm comfortable leaving off a ~ux label. I am happy with its position in the sidebar; the "Security & Compliance" menu item only appears for EE deployments and this feature is for everyone.
    • I am not confident about the performance impact during migration, as this is my first db-touching MR. So I will "ask a reviewer to help assess the performance impact."
      • I did follow the guidance for new text columns though 👍
    • I have not added any observability to this feature. It simply renders plaintext if present. Existing rails logging will capture standard logs.
    • I added changelog: added
    • I added documentation for this feature
    • A security review is not needed for this, although it is a security related feature
    • I have decided not to use a feature flag because I don't see why it would be warranted. Happy to take on feedback.

Related to #433210 (closed)

Edited by Nick Malcolm

Merge request reports