GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Vendored JVM fetches upstream artifacts and checksums only from Maven Central, ignoring the build's mirrors and repositories · Issue #1069 · SocketDev/socket-patch

Vendored JVM fetches upstream artifacts and checksums only from Maven Central, ignoring the build's mirrors and repositories #1069

New issue
Copy link
New issue
Copy link
Open
Open
Vendored JVM fetches upstream artifacts and checksums only from Maven Central, ignoring the build's mirrors and repositories#1069
Copy link
Labels
agent:triagedarch-auditFiled by a scheduled architecture audit routine (see the architecture review discussion)Filed by a scheduled architecture audit routine (see the architecture review discussion)bugSomething isn't workingSomething isn't workingpm:mavenMavenMavenpriority:p3

Description

@mikolalysenko
Mikola Lysenko (mikolalysenko)
opened on Oct 7, 2026
Issue body actions

[agent] Filed by the October 7 architecture audit campaign (ecosystems). Register: arch-audit register.

Kind: bug. Source: audit B63 (new finding), register E86.

Problem: maven_registry_base() returns SOCKET_MAVEN_REGISTRY or Maven Central, and it is the only remote base for acquire_classifier, verify_jvm_upstream, acquire_jvm_artifact, acquire_upstream_pom and agent-mode jvm_jar.rs. settings.xml <mirrors>, pom <repositories>, Gradle repositories {} and sbt resolvers are never read. An online vendor always fetches .sha512/.sha1 from that base, even when the bytes came from a local cache, and refuses with vendor_jvm_upstream_unavailable on any fetch error.

Impact: on a network that reaches Central only through a corporate mirror, every online JVM vendor fails closed; the process-global env var is the only workaround. No silent unpatched build. Low priority per the maintainer's ecosystem triage.

Proposed change: resolve the upstream base per build (the effective settings.xml mirror for central, the Gradle repositories, or the sbt/Coursier resolution URL already in the gate evidence) and fall back to Central with a named warning. Land it in vendor::jvm::layout::registry_base (#1032).

Acceptance criteria:

  • A Maven project with a mirrorOf central mirror vendors online against the mirror.
  • A warning names the fallback when no build repository is usable.

Dependencies: after #1032. Related: E43, #263.


Generated by Claude Code

Activity

  1. Mikola Lysenko (mikolalysenko)
    added
    bugSomething isn't workingSomething isn't working
    pm:mavenMavenMaven
    arch-auditFiled by a scheduled architecture audit routine (see the architecture review discussion)Filed by a scheduled architecture audit routine (see the architecture review discussion)
    on Oct 7, 2026
  2. Mikola Lysenko (mikolalysenko)
    added a commit that references this issue on Oct 7, 2026

    Reconcile the ledger with the October 7 audit

    d7d3d90
  3. mikolalysenko commented on Oct 7, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 7, 2026
    CollaboratorAuthor
    More actions

    [agent] Triage: priority:p3 (Maven/JVM). Not a duplicate; depends on #1032 per the issue. No open PR references it.


    Generated by Claude Code

  4. Mikola Lysenko (mikolalysenko)
    added
    agent:triaged
    priority:p3
    on Oct 7, 2026
  5. mikolalysenko commented on Oct 9, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 9, 2026
    CollaboratorAuthor
    More actions

    [agent] Re-checked against main @ a80b89e by the ecosystems and formats architecture audit. The finding still holds, and the code has not moved: vendor/jvm/layout.rs#L60-L69 still picks the upstream base only from SOCKET_MAVEN_REGISTRY, falling back to repo1.maven.org. The base is used by layout::registry_url and patch/jvm_jar.rs#L654. Since #1036, single-module poms also go through the jvm/ planner, so they now fetch through this one base as well.


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent:triagedarch-auditFiled by a scheduled architecture audit routine (see the architecture review discussion)Filed by a scheduled architecture audit routine (see the architecture review discussion)bugSomething isn't workingSomething isn't workingpm:mavenMavenMavenpriority:p3

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402520 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.