Skip to content

v3.8.5

Choose a tag to compare

@placerda placerda released this 22 Sep 02:01
6937b61

Changed

  • Replace the deploy-only RUN_FROM_JUMPBOX declaration gate with shared,
    credential-free private connectivity prerequisites
    (#703). Use operating-system DNS
    resolution, including Windows NRPT, and require 1-16 addresses, all RFC1918
    IPv4; reject public, loopback, mixed, or IPv6 answers before connecting.
    Pin each resolved IP on TCP 443 and perform TLS with normal certificate
    verification and hostname SNI, with a 10-second DNS timeout within a
    20-second per-hostname budget. The checks send no HTTP requests,
    credentials, or tokens and do not use proxies.
  • Apply prerequisites at the relevant stage: App Configuration during
    post-provision; App Configuration and, for hosted deployment, Foundry during
    pre-deploy; ACR only when a hosted image build actually runs. Prebuilt or
    reusable immutable digests that avoid building do not require an ACR build
    probe. Public deployment paths do not run these private probes.
  • When RUN_FROM_JUMPBOX is unset, perform checks without prompting or
    automatically skipping in noninteractive execution, unless
    AZURE_SKIP_NETWORK_ISOLATION_WARNING=true explicitly defers post-provision.
    Explicit RUN_FROM_JUMPBOX=false|0|no|skip also defers post-provision with
    an incomplete-configuration warning. Truthy jumpbox values take precedence
    over the warning flag but cannot bypass checks. Pre-deploy and actual
    hosted builds ignore both deferral flags.
  • Reject failed, empty, or malformed selected azd environment reads. Root
    pre-deploy uses one validated snapshot for its check and deployment;
    explicit empty values clear inherited process values, while absent keys
    retain existing process inheritance.
  • Coordinate deployment, VPN, configuration, and troubleshooting guidance
    through #702, merged on the
    docs branch. Release-status wording is coordinated separately at
    publication.
  • Keep runtime components, AI Landing Zone pins, and topology defaults
    unchanged. The hosted runtime permission bootstrap remains the fix already
    shipped in v3.8.4; no broadened grants, document-access, native Blob, or
    infrastructure changes are included.

Component versions

Component Version
gpt-rag-ui v2.6.2
gpt-rag-orchestrator v4.1.1
gpt-rag-ingestion v2.7.3
infra / AI Landing Zone v2.5.1

Validation

  • Python 3.12 offline suite:
    python -B -m pytest -q tests config -p no:cacheprovider --tb=short:
    472 passed, 480 subtests passed, 4 optional CLI cases skipped.
    Focused private-network and release-pin contracts passed
    34 tests and 108 subtests. Network and Azure command boundaries were
    mocked, including execution of both hook variants with fake CLIs.
  • All 4 optional installed-CLI parser/serialization cases passed separately
    with their socket and command-handler guards. PowerShell parsing and Bash
    syntax checks passed for both changed hook pairs. The agent-assets validator
    passed for 3 agents and 14 skills, plus scoped instructions.
  • After verifying the Windows test harness supplied an empty core.fsmonitor
    override, tests used process-local GIT_CONFIG_VALUE_2=false so
    environment-clearing tests retained a valid override. No repository/global
    Git configuration or test expectations were changed.
  • Release metadata, manifest-derived tables, unchanged component and
    infrastructure pins, historical changelog preservation, and privacy checks
    passed. Runtime source matches the reviewed feature in
    #703; the unchanged component
    matrix is restated above rather than repinned.
  • A separate source-bound current-host probe rejected non-RFC1918 DNS for
    three configured endpoints. This is negative-only evidence, not positive
    VPN/private-TLS readiness or a fresh-install acceptance result.
  • Host prerequisites establish DNS/TCP/TLS only. Endpoint ownership,
    VNet/route mapping, RBAC, API health, build-pool egress, other service/data
    endpoints, and runtime-to-service connectivity require separate evidence.
  • No fresh automated deployment, role apply, model greeting, document
    authorization, scanning, or cold-start validation was performed for this
    candidate. Release preparation made no Azure mutations, image builds,
    or model calls.