Merge the “develop” branch into “master” for 6.7 Release#11647
Conversation
Error correction: the flex stack options are not available for the app or config images, only for the base image!
Eliminated a redundant "Supported Image Tags" heading for improved clarity and readability in the documentation.
Summarized enhancements including versioned tags, workflow reorganization, backport support, base image migration to Ubuntu, and improved documentation for better lifecycle management and operational clarity.
Switched references from `alpha` to `latest` tags in demo compose file and documentation for Dataverse and ConfigBaker images. Adjusted related explanations to reflect this change and provided guidance on using specific version tags for consistency.
…age workflows Ensured required permissions for `contents` and `packages` in `application-image` and `configbaker-image` workflows to align with best practices and enhance security.
…ewlines in error handling blocks
Ensure password-related commands properly handle failures and print warnings if changes cannot be applied. Backported changes to v6.4, v6.5, and v6.6.
…with ro rootfs Added a note about incompatibility with read-only root filesystems when modifying `/etc/shadow`.
This reverts commit 952617e.
…tation processor #11487 Before JDK 23, the annotation processor for Auto Service was picked up automatically. With newer JDKs, the META-INF/services files were not generated, which made it impossible for the PID Factories to be picked up by the ServiceLoader at runtime. Following the documentation, we seem to have missed adding the annotation processor to the Maven Build Plugin. Adding this missing bit re-enables the auto-generation on newer JDKs. See also: https://github.com/google/auto/blob/bb4d48e4ca0bda0e75b3b67f6ff4f464db9304e4/service/README.md
…91-displayOnCreate-with-template Addition to IQSS/11391 display on create with template
Fix password script in base container image
Fix @autoservice classes not being loaded at runtime when using JDK23+ for compilation
…terUpdates Filter Improvements
Removed temporary testing condition for `gdcc/wip-base-image` and reinstated the `if` condition to restrict workflow runs to the upstream `IQSS` repository.
Introduced documentation detailing the structure, purpose, and usage of the `src/backports` directory to support consistent patch management across multiple Dataverse release versions.
Co-authored-by: Omer Fahim <mfahim11427@gmail.com>
bump to 6.7 and update base.image.version
6.7 release notes
| } catch (Exception e) { | ||
| alr.setActionResult(ActionLogRecord.Result.InternalError); | ||
| alr.setInfo(alr.getInfo() + "// " + e.getMessage()); | ||
| return error(Response.Status.INTERNAL_SERVER_ERROR, e.getMessage()); |
Check warning
Code scanning / CodeQL
Information exposure through an error message Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI about 1 year ago
To fix the issue, replace instances of e.getMessage() being sent to the client with a generic error message. Log the detailed exception message on the server for debugging purposes. This ensures that sensitive information is not exposed to users while still retaining the ability to debug issues internally.
In the specific case of line 1031, replace the call to error(Response.Status.INTERNAL_SERVER_ERROR, e.getMessage()) with a generic error message such as "An error occurred while processing your request.". Add a Logger instance to log the full exception details.
| @@ -1028,7 +1028,8 @@ | ||
| } catch (Exception e) { | ||
| alr.setActionResult(ActionLogRecord.Result.InternalError); | ||
| alr.setInfo(alr.getInfo() + "// " + e.getMessage()); | ||
| return error(Response.Status.INTERNAL_SERVER_ERROR, e.getMessage()); | ||
| Logger.getLogger(Admin.class.getName()).log(Level.SEVERE, "Error updating builtin role", e); | ||
| return error(Response.Status.INTERNAL_SERVER_ERROR, "An error occurred while processing your request."); | ||
| } finally { | ||
| actionLogSvc.log(alr); | ||
| } |
| logger.log(Level.WARNING, "Dataset metadata update: exception while parsing JSON: {0}", ex); | ||
| return error(BAD_REQUEST, BundleUtil.getStringFromBundle("file.addreplace.error.parsing")); | ||
| } catch (DataFileTagException de) { | ||
| return error(BAD_REQUEST, de.getMessage()); |
Check warning
Code scanning / CodeQL
Information exposure through an error message Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI about 1 year ago
To fix the issue, the code should avoid exposing exception details in the response. Instead:
- Log the exception details (including the message) on the server for debugging.
- Return a generic error message to the user that does not reveal internal details.
Specifically, replace de.getMessage() in the response with a neutral, user-friendly message (e.g., "Error updating file metadata tags"). Log the detailed exception message using the logger.
| @@ -4889,7 +4889,8 @@ | ||
| logger.log(Level.WARNING, "Dataset metadata update: exception while parsing JSON: {0}", ex); | ||
| return error(BAD_REQUEST, BundleUtil.getStringFromBundle("file.addreplace.error.parsing")); | ||
| } catch (DataFileTagException de) { | ||
| return error(BAD_REQUEST, de.getMessage()); | ||
| logger.log(Level.WARNING, "Dataset metadata update: DataFileTagException occurred: {0}", de.getMessage()); | ||
| return error(BAD_REQUEST, "Error updating file metadata tags."); | ||
| }catch (Exception e) { | ||
| logger.log(Level.WARNING, "Dataset metadata update: exception while processing:{0}", e); | ||
| return error(Response.Status.INTERNAL_SERVER_ERROR, "Error updating metadata for DataFiles: " + e); |
Check warning
Code scanning / CodeQL
Information exposure through an error message Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI about 1 year ago
The fix involves replacing the usage of ex.getMessage() in error responses with a generic error message for external users. Detailed exception information should be logged on the server for debugging purposes. This approach ensures that sensitive information is not leaked to users while still allowing developers to diagnose issues.
- Replace
ex.getMessage()in theBAD_REQUESTresponse on line 5904 with a generic error message, such as "File deletes failed due to an internal error." - Log the exception details (
ex.getMessage()orex.printStackTrace()) on the server for debugging purposes.
| @@ -5900,11 +5900,11 @@ | ||
| } catch (PermissionException ex) { | ||
| return error(FORBIDDEN, "You do not have permission to delete files ont this dataset."); | ||
| } catch (CommandException ex) { | ||
| return error(BAD_REQUEST, | ||
| "File deletes failed for dataset ID " + id + " (CommandException): " + ex.getMessage()); | ||
| logger.log(Level.SEVERE, "File deletes failed for dataset ID " + id + " (CommandException): ", ex); | ||
| return error(BAD_REQUEST, "File deletes failed due to an internal error."); | ||
| } catch (EJBException ex) { | ||
| return error(jakarta.ws.rs.core.Response.Status.INTERNAL_SERVER_ERROR, | ||
| "File deletes failed for dataset ID " + id + "(EJBException): " + ex.getMessage()); | ||
| logger.log(Level.SEVERE, "File deletes failed for dataset ID " + id + " (EJBException): ", ex); | ||
| return error(jakarta.ws.rs.core.Response.Status.INTERNAL_SERVER_ERROR, "File deletes failed due to an internal error."); | ||
| } | ||
| return ok(fileIds.size() + " files deleted successfully"); | ||
|
|
| @AuthRequired | ||
| public Response addExternalTool(@Context ContainerRequestContext crc, String manifest) { | ||
| Response notAuthorized = authorize(crc); | ||
| return notAuthorized == null ? externalTools.addExternalTool(manifest) : notAuthorized; |
Check warning
Code scanning / CodeQL
Information exposure through an error message Medium
Copilot Autofix
AI about 1 year ago
Copilot could not generate an autofix suggestion
Copilot could not generate an autofix suggestion for this alert. Try pushing a new commit or if the problem persists contact support.
| } catch (WrappedResponse resp) { | ||
| return resp.getResponse(); | ||
| } catch (JsonException je) { | ||
| return error(Response.Status.BAD_REQUEST, "Invalid JSON; error message: " + je.getMessage()); |
Check warning
Code scanning / CodeQL
Information exposure through an error message Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI about 1 year ago
To address the issue, the code should replace the detailed error message containing je.getMessage() with a generic message such as "Invalid JSON input." This ensures that no sensitive information is exposed to external users. The detailed exception information should instead be logged on the server for debugging purposes.
The changes required are:
- Replace the
je.getMessage()inclusion in theResponse.Status.BAD_REQUESTerror message with a generic error message. - Log the detailed
je.getMessage()locally on the server using the existinglogger.
| @@ -90,7 +90,8 @@ | ||
| } catch (WrappedResponse resp) { | ||
| return resp.getResponse(); | ||
| } catch (JsonException je) { | ||
| return error(Response.Status.BAD_REQUEST, "Invalid JSON; error message: " + je.getMessage()); | ||
| logger.severe("Invalid JSON input: " + je.getMessage()); | ||
| return error(Response.Status.BAD_REQUEST, "Invalid JSON input."); | ||
| } | ||
| } | ||
|
|
| } | ||
| private String sanitizeBody (String body) throws WrappedResponse { | ||
| // remove malicious html | ||
| String sanitizedBody = body == null ? "" : body.replaceAll("\\<.*?>", ""); |
Check failure
Code scanning / CodeQL
Polynomial regular expression used on uncontrolled data High
|
For the record, this pull request originally had lots of merge conflicts: We discussed in Slack and developed a whole plan to fix the master branch (we force-pushed from v6.5 and brought it up to v6.6 with #11649) and re-do the v6.6 release. Now that all that's done, the merge conflicts in the PR are gone! 🎉 |
|
merging! |
Merge the “develop” branch into “master” for 6.7 Release