Publish size limits and scanning size limits can drift out of sync #2302

Problem

Since #2287 added configurable extension size limits (runtime-adjustable default via SettingsService.getMaxExtensionSize(), plus per-namespace/per-extension ExtensionSizeOverride rows, resolved by ExtensionSizeLimitService), the size of a package openvsx will accept for publishing is independently configured from the size limits that govern scanning it:

• Publish side (dynamic, admin-adjustable at runtime, no restart needed):

  • ovsx.publishing.max-content-size (PublishingConfig.java) — global default, 512 MiB out of the box.
  • SettingsService.getMaxExtensionSize() — admin-dashboard-adjustable override of that default, falls back to the config value.
  • ExtensionSizeOverride (extension_size_override table) — per-namespace or per-extension override, can exceed the global default.
  • ExtensionSizeLimitService.getCeiling() = max(default, highest override) — the actual stream-time cap enforced in LocalRegistryService.doPublish (ceiling first, then the package's specific resolved limit once the namespace is known).

• Scanning side (static, @Value-bound, requires an app restart to change):

  • ovsx.scanning.max-archive-size-bytes (ExtensionScanConfig.java, default 512 MiB) and ovsx.scanning.max-single-file-bytes (default 256 MiB) — govern the in-process checks (secret-detection, blocklist, etc.).
  • These silently skip files/archives that exceed them rather than failing the scan closed — so oversized content isn't flagged as a scan failure, it's just not inspected.

No code path reads one of these from the other, and nothing cross-validates them at startup or on an admin settings/override change. Concretely: an admin can raise a namespace's override (or the global default) above ovsx.scanning.max-archive-size-bytes and openvsx will happily accept and publish a package that its own scanning step only partially inspects (or doesn't inspect at all, past the archive-size ceiling), with no indication anywhere that this happened.

(Out of scope here, but related: the external clamav-rest/yara-rest scanner sidecars have their own independent MAX_UPLOAD_SIZE_MB/MAX_SINGLE_FILE_MB env vars set entirely in the deployment repo's Helm values — invisible to this codebase and not something an in-repo fix can validate directly.)

Options under consideration

Undecided yet which of these (or both) is the right fix:

1. Log a warning at startup (and/or whenever an admin changes the default or adds/edits an override) when a configured or resolved publish-size limit exceeds ovsx.scanning.max-archive-size-bytes — visibility without changing behavior.
2. Clamp scanning's effective limits to the publish ceiling (or the reverse — clamp what publish will accept to what scanning can actually inspect) so the two can't diverge in the direction that creates an inspection gap.

Scope

• server/src/main/java/org/eclipse/openvsx/settings/ExtensionSizeLimitService.java
• server/src/main/java/org/eclipse/openvsx/publish/PublishingConfig.java
• server/src/main/java/org/eclipse/openvsx/scanning/ExtensionScanConfig.java
• Wherever the chosen fix hooks in: app startup, ExtensionSizeOverride create/update, and/or the admin settings update path (SettingsService.updateFromJson).

🤖 Generated with Claude Code