Renumber #15058 migration and move release notes to 3.1.x (#15108)

PR #15058 was branched from an older base: its migration was numbered
0270 (depending on 0269) and its upgrade notes targeted 3.2.x. On dev
this collided with the existing 0270_finding_visibility_perf_indexes /
0271_finding_perf_indexes migrations (two 0270 leaf nodes break the
migration graph), and dev is 3.1.0-dev, not 3.2.

- Rename 0270_reencrypt_tool_config_credentials_aes_gcm -> 0272 and
  depend on 0271_finding_perf_indexes, restoring a linear chain.
- Update the migration-name references in dojo/utils.py (0270 -> 0272).
- Merge the AES-256-GCM upgrade notes into 3.1.md (fixing the migration
  name and release-tag link) and delete 3.2.md.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: Maffooch

docs/content/releases/os_upgrading/3.1.md

@@ -2,7 +2,7 @@
 title: 'Upgrading to DefectDojo Version 3.1.x'
 toc_hide: true
 weight: -20260617
-description: Blank Finding components are now normalized to NULL so component-less findings group together; JIRA project configurations now support multiple comma-separated components.
+description: Blank Finding components are now normalized to NULL so component-less findings group together; JIRA project configurations now support multiple comma-separated components; Tool Configuration credentials are re-encrypted to AES-256-GCM.
 ---
 
 ## Blank Finding components normalized to NULL
@@ -22,3 +22,19 @@ The `Component` field on a JIRA project configuration now supports assigning mor
 ### What you need to do
 
 Nothing is required. Note that a component name that legitimately contains a comma will be split into separate components — component names rarely contain commas, so this is an accepted limitation.
+
+## Tool Configuration credentials upgraded to AES-256-GCM
+
+DefectDojo encrypts the credentials stored on Tool Configurations (the `password`, `ssh`, and `api_key` fields). Previously these values were encrypted with AES-256 in OFB mode (the `AES.1` stored format). This release introduces a modern `AES.2` format that uses AES-256-GCM, an authenticated encryption scheme that detects tampering with the stored ciphertext.
+
+New and updated credentials are written in the `AES.2` format automatically. The encryption key is unchanged — both formats derive their key from the same `DD_CREDENTIAL_AES_256_KEY`, so no key rotation or settings change is required.
+
+A data migration (`0272_reencrypt_tool_config_credentials_aes_gcm`) included in this release eagerly re-encrypts every existing `AES.1` credential to `AES.2` on upgrade. The legacy `AES.1` decryption path is retained for backward compatibility, so any value that has not yet been migrated continues to decrypt normally. The same migration also widens the `password`, `ssh`, and `api_key` columns by 50% so that credentials stored at the old maximum length still fit once the GCM nonce and authentication tag are added.
+
+This release also bumps `cryptography` to 49.0.0 and `pyopenssl` to 26.3.0.
+
+### What you need to do
+
+Nothing — the change is applied automatically by the database migration included in this release. Ensure your `DD_CREDENTIAL_AES_256_KEY` is unchanged from your prior deployment so the existing credentials can be decrypted and re-encrypted; a value that fails to decrypt (for example, because it was encrypted under a different key) is left untouched rather than overwritten.
+
+For more information, check the [Release Notes](https://github.com/DefectDojo/django-DefectDojo/releases/tag/3.1.0).

docs/content/releases/os_upgrading/3.2.md

@@ -85,7 +85,7 @@ def noop_reverse(apps, schema_editor):
 
 class Migration(migrations.Migration):
     dependencies = [
-        ("dojo", "0269_normalize_blank_finding_components"),
+        ("dojo", "0271_finding_perf_indexes"),
     ]
 
     operations = [

…crypt_tool_config_credentials_aes_gcm.py …crypt_tool_config_credentials_aes_gcm.pydojo/db_migrations/0270_reencrypt_tool_config_credentials_aes_gcm.py renamed to dojo/db_migrations/0272_reencrypt_tool_config_credentials_aes_gcm.py dojo/db_migrations/0270_reencrypt_tool_config_credentials_aes_gcm.py renamed to dojo/db_migrations/0272_reencrypt_tool_config_credentials_aes_gcm.py

@@ -978,7 +978,7 @@ def reopen_external_issue(finding_id, note, external_issue_provider, **kwargs):
 # time they are saved.
 #
 # REMOVAL TRACKING (legacy OFB path):
-# Migration 0270_reencrypt_tool_config_credentials_aes_gcm eagerly re-encrypts
+# Migration 0272_reencrypt_tool_config_credentials_aes_gcm eagerly re-encrypts
 # every stored Tool_Configuration credential to "AES.2", so after it has run in
 # every environment there should be no "AES.1" values left in the database.
 # Once that migration is squashed/baked into the release floor (i.e. no upgrade
@@ -1079,7 +1079,7 @@ def prepare_for_view(encrypted_value):
                     decrypted_value = AESGCM(key).decrypt(iv, binascii.a2b_hex(value), None).decode("utf-8")
                 else:
                     # Legacy "AES.1" (AES-256-OFB) read path. Removable once
-                    # migration 0270 is guaranteed to have run everywhere and no
+                    # migration 0272 is guaranteed to have run everywhere and no
                     # "AES.1" values remain -- see the REMOVAL TRACKING note on
                     # the encrypt()/decrypt() block above.
                     decrypted_value = decrypt(key, iv, value).decode("utf-8")