Skip to content

Harden CAYWResource against XSS and other security issues - #15868

Merged
Siedlerchr merged 5 commits into
mainfrom
hardenXss
Jun 7, 2026
Merged

Siedlerchr merged 5 commits into
mainfrom
hardenXss

Conversation

@Siedlerchr

@Siedlerchr Siedlerchr commented May 31, 2026 •

Copy link
Copy Markdown
Member

Fixes some of the XSS security issues mentioned. https://github.com/JabRef/jabref/security
Harden security and show a user dialog (currently only valid until restart of jabref)
grafik

Related issues and pull requests

Closes _____

PR Description

Tip: re-read your description before opening the pull request, then delete this line.

Steps to test

CAYW tests

AI usage

GPT 5.3 coded helped me to analyze the security issues and to fix them. All code was reviewed by me


Checklist

  • I own the copyright of the code submitted and I license it under the MIT license
  • If AI tools were used, I disclosed them in the "AI usage" section and reviewed, understood, and take full ownership of all AI-generated code
  • I manually tested my changes in running JabRef (always required)
  • I added JUnit tests for changes (if applicable)
  • I added screenshots in the PR description (if change is visible to the user)
  • [/] I added a screenshot in the PR description showing a library with a single entry with me as author and as title the issue number
  • I described the change in CHANGELOG.md in a way that can be understood by the average user (if change is visible to the user)
  • [/] I checked the user documentation for up to dateness and submitted a pull request to our user documentation repository

@Siedlerchr
Siedlerchr requested review from koppor and palukku and removed request for koppor May 31, 2026 18:02
@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

Review Summary by Qodo

Harden CAYW against XSS and library path security issues

🐞 Bug fix ✨ Enhancement

Grey Divider

Walkthroughs

Description
• Harden CAYW browser extension against XSS attacks with security headers
• Validate and restrict library path access with user confirmation dialog
• Escape HTML content in EntryResource to prevent XSS vulnerabilities
• Add security-focused tests for library path validation
Diagram
flowchart LR
  A["CAYW Request"] --> B["Validate Library Path"]
  B --> C{Path Served or Allowed?}
  C -->|Yes| D["Load Library"]
  C -->|No| E["Show User Dialog"]
  E --> F{User Decision}
  F -->|Allow| D
  F -->|Block| G["Reject Request"]
  D --> H["Add Security Headers"]
  H --> I["Return Response"]
  G --> I

Loading

Grey Divider

File Changes

1. jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java Security hardening +147/-8

Implement library path validation and security headers

• Added security headers (Content-Security-Policy, X-Content-Type-Options) to all responses
• Implemented library path validation with normalization and served path checking
• Added user confirmation dialog for accessing non-served library paths with remember options
• Introduced trusted/blocked library path tracking with concurrent collections
• Added headless mode detection to reject path access in headless environments
• Escaped HTML content and added proper imports for security features

jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java


2. jabsrv/src/main/java/org/jabref/http/server/resources/EntryResource.java Xss prevention +17/-10

Add HTML escaping to prevent XSS in entry representation

• Added HTML escaping using Guava's HtmlEscapers for all entry fields in HTML representation
• Refactored HTML string concatenation to use text blocks with formatted method
• Prevents XSS attacks by escaping author, title, journal, volume, number, pages, and date fields

jabsrv/src/main/java/org/jabref/http/server/resources/EntryResource.java


3. jabsrv/src/test/java/org/jabref/http/server/TestBibFile.java 🧪 Tests +1/-0

Add XSS test resource file reference

• Added new test resource file XSS_SERVER_TEST for XSS security testing

jabsrv/src/test/java/org/jabref/http/server/TestBibFile.java


View more (3)
4. jabsrv/src/test/java/org/jabref/http/server/cayw/CAYWResourceTest.java 🧪 Tests +55/-1

Add security header and library path validation tests

• Added FilesToServe setup in setUp() method with test library paths
• Added assertions to verify security headers in responses
• Added test for served library path acceptance
• Added test for unknown library path rejection with 400 status
• Added test for null FilesToServe list handling

jabsrv/src/test/java/org/jabref/http/server/cayw/CAYWResourceTest.java


5. CHANGELOG.md 📝 Documentation +1/-0

Document CAYW security improvements

• Added entry documenting CAYW browser extension security hardening with library path validation and
 confirmation dialog

CHANGELOG.md


6. jablib/src/main/resources/l10n/JabRef_en.properties Localization +6/-0

Add localization strings for security dialog

• Added localization strings for security dialog: "Allow", "Allow all", "Disallow", "Security
 warning", "You are about to open a local file.", and "File: %0"

jablib/src/main/resources/l10n/JabRef_en.properties


Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 31, 2026 •

Copy link
Copy Markdown
Contributor

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0)

Grey Divider


Action required

1. Hardcoded INVALID_LIBRARY_PATH_ERROR 📘 Rule violation ⚙ Maintainability
Description
The new INVALID_LIBRARY_PATH_ERROR message is hardcoded and returned to clients via
BadRequestException, making it user-facing but not localizable. This violates the requirement to
route user-facing/validation strings through localization (with placeholder-based formatting when
needed).
Code

jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[79]

Evidence
Rule 16 and Pattern 2 require user-facing strings (including validation messages) to be localized.
The PR introduces a hardcoded English error string and throws it in BadRequestException, which
will surface it to the caller without localization.

AGENTS.md: Localization: localize all user-facing text; keep logs in English; do not edit translated properties; follow LocalizationConsistencyTest guidance: AGENTS.md: Localization: localize all user-facing text; keep logs in English; do not edit translated properties; follow LocalizationConsistencyTest guidance: AGENTS.md: Localization: localize all user-facing text; keep logs in English; do not edit translated properties; follow LocalizationConsistencyTest guidance: AGENTS.md: Localization: localize all user-facing text; keep logs in English; do not edit translated properties; follow LocalizationConsistencyTest guidance: AGENTS.md: Localization: localize all user-facing text; keep logs in English; do not edit translated properties; follow LocalizationConsistencyTest guidance: AGENTS.md: Localization: localize all user-facing text; keep logs in English; do not edit translated properties; follow LocalizationConsistencyTest guidance: AGENTS.md: Localization: localize all user-facing text; keep logs in English; do not edit translated properties; follow LocalizationConsistencyTest guidance: AGENTS.md: Localization: localize all user-facing text; keep logs in English; do not edit translated properties; follow LocalizationConsistencyTest guidance
jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[79-79]
jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[229-233]
jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[244-249]
Best Practice: Learned patterns

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A user-facing validation/error message for the `librarypath` parameter is introduced as a hardcoded English string (`INVALID_LIBRARY_PATH_ERROR`) and returned via HTTP `BadRequestException`, which bypasses JabRef localization.
## Issue Context
The compliance rules require all user-facing strings (including validation/integrity messages) to be localized.
## Fix Focus Areas
- jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[79-249]
- jablib/src/main/resources/l10n/JabRef_en.properties[200-208]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. CLI path check bypass ✓ Resolved 🐞 Bug ⛨ Security
Description
isLibraryPathAccessAllowed() returns true for JabRefSrvStateManager (stand-alone HTTP server),
which makes the new librarypath validation effectively a no-op in that mode. As a result, any
existing local file path can be opened via librarypath without being served or user-approved,
defeating the intended hardening.
Code

jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[R256-259]

Evidence
getBibDatabaseContext only rejects a librarypath when it is both not served and not allowed; the
new isLibraryPathAccessAllowed returns true immediately for the stand-alone server state
manager, so unserved paths are never rejected in that mode. The codebase explicitly documents that
JabRefSrvStateManager represents the stand-alone HTTP server, and ServerUtils treats the
opposite case as GUI mode.

jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[216-235]
jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[256-275]
jabsrv/src/main/java/org/jabref/http/JabRefSrvStateManager.java[21-29]
jabsrv/src/main/java/org/jabref/http/server/services/ServerUtils.java[55-90]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In `CAYWResource.isLibraryPathAccessAllowed`, stand-alone server mode (`srvStateManager instanceof JabRefSrvStateManager`) is currently treated as automatically allowed. This bypasses the new guard in `getBibDatabaseContext` and allows arbitrary `librarypath` access.
### Issue Context
`JabRefSrvStateManager` is the stand-alone HTTP server state manager (no GUI prompt possible). The new hardening should restrict `librarypath` to libraries that are already being served (via `FilesToServe` / open databases), otherwise reject.
### Fix Focus Areas
- jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[227-275]
- jabsrv/src/main/java/org/jabref/http/JabRefSrvStateManager.java[21-29]
- jabsrv/src/main/java/org/jabref/http/server/services/ServerUtils.java[55-90]
### Concrete fix guidance
- Change `isLibraryPathAccessAllowed` so that for `JabRefSrvStateManager` it returns `false` (or otherwise never grants access to unserved paths).
- Ensure the `GraphicsEnvironment.isHeadless()` rejection logic is actually reachable for headless/stand-alone mode.
- (Optional) Adjust `INVALID_LIBRARY_PATH_ERROR` text to reflect “not served / not permitted” if you keep a separate allow path in GUI mode.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Prompt blocks request thread 🐞 Bug ☼ Reliability
Description
promptForLibraryPathAccess blocks the request thread on future.get() with no timeout, so any
request requiring user confirmation can hang a server thread indefinitely. Exceptions inside the
Platform.runLater callback can also prevent completing the future, permanently stalling the
request.
Code

jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[R286-331]

Evidence
The request thread synchronously waits for the UI result (future.get()), and the only completion
path is inside a Platform.runLater runnable where exceptions aren’t handled. The server is started
via Grizzly, so blocked request threads reduce server capacity.

jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[277-332]
jabsrv/src/main/java/org/jabref/http/server/Server.java[139-171]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`promptForLibraryPathAccess` waits indefinitely (`future.get()`) for a JavaFX dialog result. This can exhaust the server thread pool and hang requests forever if the dialog never completes or the UI callback throws.
### Issue Context
CAYW requests are handled by the embedded Grizzly server; blocking the request thread until a user responds means remote callers can keep server threads occupied. Additionally, exceptions thrown inside the `runLater` callback won’t be caught by the surrounding try/catch and can leave the `CompletableFuture` uncompleted.
### Fix Focus Areas
- jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[277-332]
- jabsrv/src/main/java/org/jabref/http/server/Server.java[139-171]
### Concrete fix guidance
- Replace `future.get()` with a bounded wait (e.g., `future.get(timeout, TimeUnit.SECONDS)`), and treat timeout as “disallow”.
- Wrap the body of the `Platform.runLater` runnable in a `try/catch` and call `future.completeExceptionally(e)` on failure.
- Consider using `future.orTimeout(...)` (if available) to ensure the future cannot block indefinitely.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. Unhardened non-success responses 🐞 Bug ⛨ Security
Description
Only the final success response adds CSP and X-Content-Type-Options, while probe and bad-request
branches return without these headers and without an explicit Content-Type. With @Produces now
including application/json, error/probe branches can also be content-negotiated as JSON while
returning a non-JSON string body.
Code

jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[R98-102]

Evidence
The method now advertises both text/plain and application/json, but probe and invalid-command paths
return string bodies without a fixed type and without the new hardening headers. Only the success
path adds CSP/nosniff, and the global exception mapper returns responses without adding any of these
headers.

jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[98-115]
jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[174-178]
jabsrv/src/main/java/org/jabref/http/dto/GlobalExceptionMapper.java[15-22]
jabsrv/src/main/java/org/jabref/http/server/cayw/format/SimpleJsonFormatter.java[23-36]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
CAYW hardening headers (`Content-Security-Policy`, `X-Content-Type-Options`) are only applied on the main 200 response. Other branches (probe, 400 returns, 204, and exceptions) omit these headers, and some responses don’t set a concrete media type despite `@Produces` advertising JSON.
### Issue Context
- `@Produces({text/plain, application/json})` enables JSON content negotiation.
- Some branches return raw strings (`"ready"`, error messages) without explicitly setting `text/plain`, so clients preferring JSON can receive non-JSON payloads.
- Exceptions mapped via `GlobalExceptionMapper` do not add these security headers.
### Fix Focus Areas
- jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[98-179]
- jabsrv/src/main/java/org/jabref/http/dto/GlobalExceptionMapper.java[15-22]
- jabsrv/src/main/java/org/jabref/http/server/cayw/format/SimpleJsonFormatter.java[23-36]
### Concrete fix guidance
- Introduce a small helper that takes a `ResponseBuilder` and adds the CSP + nosniff headers, and apply it to *all* return paths (probe, bad request, no content, success).
- For string bodies that are not JSON, explicitly set `.type(MediaType.TEXT_PLAIN_TYPE)`.
- For thrown `BadRequestException` cases, consider returning a built `Response` with headers instead of throwing, or update the exception mapper/filtering to add the same security headers.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

private static final String CAYW_CONTENT_SECURITY_POLICY = "default-src 'none'; frame-ancestors 'none'; base-uri 'none'";
private static final String X_CONTENT_TYPE_OPTIONS = "X-Content-Type-Options";
private static final String NO_SNIFF = "nosniff";
private static final String INVALID_LIBRARY_PATH_ERROR = "The 'librarypath' parameter must reference a currently served library file.";

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Hardcoded invalid_library_path_error 📘 Rule violation ⚙ Maintainability

The new INVALID_LIBRARY_PATH_ERROR message is hardcoded and returned to clients via
BadRequestException, making it user-facing but not localizable. This violates the requirement to
route user-facing/validation strings through localization (with placeholder-based formatting when
needed).
Agent Prompt
## Issue description
A user-facing validation/error message for the `librarypath` parameter is introduced as a hardcoded English string (`INVALID_LIBRARY_PATH_ERROR`) and returned via HTTP `BadRequestException`, which bypasses JabRef localization.

## Issue Context
The compliance rules require all user-facing strings (including validation/integrity messages) to be localized.

## Fix Focus Areas
- jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[79-249]
- jablib/src/main/resources/l10n/JabRef_en.properties[200-208]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java Outdated
Comment on lines +286 to +331
CompletableFuture<LibraryPathAccessPromptResult> future = new CompletableFuture<>();
try {
Platform.runLater(() -> {
Alert alert = new Alert(Alert.AlertType.CONFIRMATION);
alert.setTitle(Localization.lang("Security warning"));
alert.setHeaderText(Localization.lang("You are about to open a local file."));
Label fileLabel = new Label(Localization.lang("File: %0", requestedLibraryPath));
CheckBox dontAskAgain = new CheckBox(Localization.lang("Do not ask again"));
alert.getDialogPane().setContent(new VBox(10, fileLabel, dontAskAgain));

ButtonType allowButton = new ButtonType(Localization.lang("Allow"), ButtonBar.ButtonData.YES);
ButtonType allowAllButton = new ButtonType(Localization.lang("Allow all"), ButtonBar.ButtonData.APPLY);
ButtonType disallowButton = new ButtonType(Localization.lang("Disallow"), ButtonBar.ButtonData.NO);
alert.getButtonTypes().setAll(allowButton, allowAllButton, disallowButton);

ButtonType selectedButton = alert.showAndWait().orElse(disallowButton);
future.complete(new LibraryPathAccessPromptResult(selectedButton, dontAskAgain.isSelected()));
});
} catch (IllegalStateException exception) {
LOGGER.warn("JavaFX toolkit not initialized for CAYW security prompt.", exception);
return false;
}

try {
LibraryPathAccessPromptResult promptResult = future.get();
if (promptResult.selectedButton().getButtonData() == ButtonBar.ButtonData.APPLY) {
allowAllLibraryPaths = true;
return true;
}

boolean shouldAllow = promptResult.selectedButton().getButtonData() == ButtonBar.ButtonData.YES;
if (promptResult.dontAskAgain()) {
if (shouldAllow) {
TRUSTED_LIBRARY_PATHS.add(requestedLibraryPath);
} else {
BLOCKED_LIBRARY_PATHS.add(requestedLibraryPath);
}
}
return shouldAllow;
} catch (InterruptedException exception) {
Thread.currentThread().interrupt();
LOGGER.warn("Interrupted while waiting for CAYW security prompt.", exception);
} catch (ExecutionException exception) {
LOGGER.warn("Failed to evaluate CAYW security prompt.", exception);
}
return false;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

3. Prompt blocks request thread 🐞 Bug ☼ Reliability

promptForLibraryPathAccess blocks the request thread on future.get() with no timeout, so any
request requiring user confirmation can hang a server thread indefinitely. Exceptions inside the
Platform.runLater callback can also prevent completing the future, permanently stalling the
request.
Agent Prompt
### Issue description
`promptForLibraryPathAccess` waits indefinitely (`future.get()`) for a JavaFX dialog result. This can exhaust the server thread pool and hang requests forever if the dialog never completes or the UI callback throws.

### Issue Context
CAYW requests are handled by the embedded Grizzly server; blocking the request thread until a user responds means remote callers can keep server threads occupied. Additionally, exceptions thrown inside the `runLater` callback won’t be caught by the surrounding try/catch and can leave the `CompletableFuture` uncompleted.

### Fix Focus Areas
- jabsrv/src/main/java/org/jabref/http/server/cayw/CAYWResource.java[277-332]
- jabsrv/src/main/java/org/jabref/http/server/Server.java[139-171]

### Concrete fix guidance
- Replace `future.get()` with a bounded wait (e.g., `future.get(timeout, TimeUnit.SECONDS)`), and treat timeout as “disallow”.
- Wrap the body of the `Platform.runLater` runnable in a `try/catch` and call `future.completeExceptionally(e)` on failure.
- Consider using `future.orTimeout(...)` (if available) to ensure the future cannot block indefinitely.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@NullMarked
@AllowedToUseAwt("Requires java.awt.datatransfer.Clipboard")
@Path("better-bibtex/cayw")
@jakarta.ws.rs.Path("better-bibtex/cayw")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qualified class name?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it clashes otherwise with nio Path

@calixtus

calixtus commented Jun 1, 2026

Copy link
Copy Markdown
Member

Except removing import of path looks okish for me, but im no expert for this

Comment thread CHANGELOG.md Outdated
### Fixed

- EndNote and Refer importers now respect the citation key preferences for unwanted characters. [#15743](https://github.com/JabRef/jabref/pull/15743)
- We hardened CAYW browser extension communication by validating custom `librarypath` access and adding an allow/disallow confirmation dialog for opening local files. [#15295](https://github.com/JabRef/jabref/issues/15295)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a Browser extension, it is just an endpoint to call from different applications, such as vscode, texmaker and others

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reformulated

Comment on lines +257 to +259
if (srvStateManager instanceof JabRefSrvStateManager) {
return true;
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we want to always allow access when running in standalone and therefore not prompt the user?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@Siedlerchr

Siedlerchr commented Jun 1, 2026 via email

Copy link
Copy Markdown
Member Author

@palukku

palukku commented Jun 1, 2026

Copy link
Copy Markdown
Member

No gui mode?

But if the cayw endpoint is called, there will be a gui for selection of the entries, so we can also show the prompt. For the cayw to work, there has to be gui no matter if it runs along jabgui or standalone

@Siedlerchr

Copy link
Copy Markdown
Member Author

Okay, got it, I thought in cli mode we don't have a gui

@Siedlerchr
Siedlerchr enabled auto-merge June 4, 2026 09:42
@Siedlerchr Siedlerchr added the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Jun 4, 2026
@Siedlerchr
Siedlerchr requested a review from calixtus June 4, 2026 09:42
@calixtus
calixtus requested a review from palukku June 5, 2026 08:14
@Siedlerchr

Copy link
Copy Markdown
Member Author

@palukku can you approve?

@palukku palukku left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works in CLI as well as GUI mode. (No dark mode in both, but does not bother me, can be fixed later).

@Siedlerchr
Siedlerchr added this pull request to the merge queue Jun 7, 2026
@github-actions github-actions Bot added the status: to-be-merged PRs which are accepted and should go into the merge-queue. label Jun 7, 2026
Merged via the queue into main with commit c3559d6 Jun 7, 2026
64 of 65 checks passed
@Siedlerchr
Siedlerchr deleted the hardenXss branch June 7, 2026 20:49
Siedlerchr added a commit that referenced this pull request Jun 8, 2026
* upstream/main: (22 commits)
  Chore(deps): Bump com.github.andygoossens:gradle-modernizer-plugin from 1.13.0 to 1.14.0 in /build-logic (#15922)
  Chore(deps): Bump jablib/src/main/resources/csl-styles from `5bb8c99` to `e98c9e1` (#15900)
  Add ability to view citation previews on hover in 'Citations' tab (#15914)
  Chore(deps): Bump dev.langchain4j:langchain4j-bom in /versions (#15925)
  Chore(deps): Bump org.glassfish.grizzly:grizzly-bom in /versions (#15923)
  Chore(deps): Bump com.uber.nullaway:nullaway in /versions (#15924)
  SLR : Added performRawSearchQuery to Search Based Fetcher interface (#15916)
  Fix typos in .jbang/JabKitLauncher.java (#15919)
  Fix permission (#15918)
  New Crowdin updates (#15912)
  Harden CAYWResource against XSS and other security issues (#15868)
  Fix Cleanup, LastOpenedFiles and XMP reset and import (#15874)
  Add guard blocking PowerShell here-strings in Bash git commits (#15898)
  Fix ImporterPreferences reset and import (#15908)
  Chore(deps): Bump com.uber.nullaway:nullaway in /versions (#15906)
  Fix: Preserve field focus when navigating entries with keyboard shortcuts (#14943) (#15732)
  Localization consitency for some of the keys (#15824)
  chore(deps): update dependency org.glassfish.grizzly:grizzly-http-server to v5.0.2 (#15911)
  chore(deps): update dependency org.glassfish.grizzly:grizzly-framework to v5.0.2 (#15910)
  Chore(deps): Bump net.ltgt.nullaway from 3.0.0 to 3.1.0 in /jablib (#15905)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers status: to-be-merged PRs which are accepted and should go into the merge-queue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants