Hotfixes release v2025.08.14

[bjester]

Summary

PR	Issues	Category	QA Focus
#5083	#5063	Enhancement	Trigger data export from Account settings
#5088	#5057, #5058, #5088	Enhancement	Interact and provide feedback on Search recommendations
#5097	#5124	Enhancement	(skip)
#5103	#4878	Enhancement	Publish a channel
#5106	#5093	Enhancement	Visual check of modal headers
#5125	#5111	Enhancement	Change folder language before using import modal for importing search recommendations
#5126	#5116	Enhancement	Browse search recommendations
#5128	#5042	Enhancement	Edit a channel and resources with grade levels
#5144	#5115	Enhancement	(skip)
#5149	N/A	Enhancement	Preview a resource
#5155	#5131, #5146, #2178	Enhancement	(skip)
#5248	#5069	Enhancement	Deploy staged channel
#5253	#5211, #4086	Enhancement	Review selected resources in import modal
#5255	N/A	Enhancement	Review selected resources in import modal
#5261	N/A	Enhancement	Browse search recommendations
#5040	N/A	Bug fix	N/A
#5104	#4073	Bug fix	View channel details
#5147	#5065	Bug fix	N/A
#5102	#5068	Tech Debt	N/A
#4902	N/A	DevOps	N/A
#5105	N/A	DevOps	N/A
#5134	N/A	DevOps	N/A
#5143	N/A	DevOps	N/A
#5177	N/A	DevOps	N/A
#5190	N/A	DevOps	N/A
#5196	N/A	DevOps	N/A
#5197	N/A	DevOps	N/A
#5254	N/A	DevOps	N/A
#5293	N/A	DevOps	N/A

Dependency PRs

PR	Category
#5076	Dependency
#5084	Dependency
#5085	Dependency
#5086	Dependency
#5096	Dependency
#5098	Dependency
#5099	Dependency
#5108	Dependency
#5113	Dependency
#5117	Dependency
#5119	Dependency
#5120	Dependency
#5121	Dependency
#5136	Dependency
#5137	Dependency
#5139	Dependency
#5141	Dependency
#5148	Dependency
#5152	Dependency
#5154	Dependency
#5164	Dependency
#5179	Dependency
#5181	Dependency
#5182	Dependency
#5198	Dependency
#5199	Dependency
#5200	Dependency
#5201	Dependency
#5202	Dependency
#5203	Dependency
#5204	Dependency
#5205	Dependency
#5207	Dependency
#5210	Dependency
#5223	Dependency
#5224	Dependency
#5226	Dependency
#5238	Dependency
#5239	Dependency
#5256	Dependency

[github-advanced-security]

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

To fix the problem, we should avoid logging the password in clear text. The best approach is to remove the password from the printed message entirely. If it's necessary to inform the user about the credentials, only the email (username) should be shown, and the password can be omitted or replaced with a placeholder (e.g., "[hidden]"). This change should be made in the print statement on lines 195–197 in contentcuration/contentcuration/management/commands/setup.py. No additional imports or methods are needed.

---

To fix the problem, replace the use of MD5 in generate_task_signature with a strong cryptographic hash function, such as SHA-256. This involves changing the instantiation of the hash object from hashlib.md5() to hashlib.sha256(), and updating the docstring to reflect the new hash algorithm. Only the code in contentcuration/contentcuration/utils/celery/tasks.py needs to be changed, specifically the generate_task_signature function (lines 82-96). No other code changes are required, as the function's output format (hexdigest()) remains the same.

---

To fix the problem, we should ensure that only valid, expected language codes are used to set the cookie. The best way is to check that lang_code is in the set of allowed language codes defined in Django's settings (settings.LANGUAGES). This is stricter than relying on check_for_language, which may allow any language code that Django can process, including custom or unexpected values. The fix should be applied in the set_language view, specifically before setting the cookie. We need to import settings.LANGUAGES if not already available, and add a check that lang_code is in the allowed set before calling set_cookie. If not, we should fall back to a default language or avoid setting the cookie.

---

To avoid revealing potentially sensitive internal information, the handler for KeyError in the api_create_channel_endpoint function should not return the string representation of the exception object as part of the HTTP error response. Instead, it should return a generic error message (e.g., "Required attribute missing from data"), optionally logging the actual exception server-side for debugging. This involves editing lines 224–227 to remove str(e) from the response message, and possibly adding a server-side logging call for the exception.

• Change the return value of the except KeyError as e: block to a generic message: "Required attribute missing from data".
• Optionally, log the error (using logging.exception or similar).
• Do not include the missing key name or stringified exception in the HTTP response body.

To fix the problem, the function should return a generic error message to the client when a KeyError is caught, rather than interpolating the exception message which can leak information about internal variable names or input data structure. The actual error details (including the exception message) should be recorded in logs and/or sent to Sentry for developer diagnostics.

Detailed steps:

• Replace the except KeyError as e: block such that it logs or reports the error (using the existing handle_server_error or report_exception methods, as appropriate).
• The HTTP response should return a generic error message like "Required attribute missing from data" without any dynamic content (i.e., do not interpolate str(e) into the message).

Files/lines to change:

• Only make changes inside contentcuration/contentcuration/views/internal.py within the api_commit_channel function and do not alter code that is not shown.
• Add logging/reporting of the actual exception for admin/developer reference.

---

The best fix is to replace the HttpResponseBadRequest in the except KeyError as e: block so that it does not return the exception detail (str(e)) to the user. Instead, it should return a generic "Required attribute missing from request data" message. The detail can be logged server-side using the Python logging module or sent to Sentry if available.

Specifically:

• In api_add_nodes_to_tree (lines ~354-357), replace the return statement so the user response does not include str(e).
• Optionally, add a call to logging.error() (or use the existing Sentry report facility as imported) to capture the original exception detail for diagnostics.
• No additional dependencies are needed, as logging is already imported and Sentry reporting appears available.
• No changes outside this block are required.

---

[rtibbles]

Let's hotfix this!