Concelier Connector Disposition

This ledger records connectors that have been removed, folded into another source, or otherwise retired, together with the rationale and date. It is the authoritative answer to “why is there no <x> connector / source in the tree?” so future agents do not re-add a dead or duplicate source.

For the live connector roster see docs/modules/concelier/connectors.mdand the runtime bundle inventory at src/Concelier/__Libraries/StellaOps.Concelier.Core/RuntimePluginBundleInventory.cs.

Removal details — azure

What was deleted

• Project: src/Concelier/__Libraries/StellaOps.Concelier.Connector.Cloud.Azure/ (entire directory).
• Solution: StellaOps.Connector.Cloud.Azure project declaration, GlobalSection build-config rows, and nesting entry removed from src/StellaOps.sln.
• Shared test project StellaOps.Concelier.Connector.CloudHardwareAliases.Tests: removed the Azure ProjectReference and the azure row from the CloudAliases theory data. The test project itself is retained — it also covers AWS, GCP, and the Intel/AMD/Siemens hardware connectors.
• Packaging: cloud-azure plugin entry removed from devops/build/package-runtime-plugins.ps1.
• Runtime inventory: cloud-azure OptionalConnector(...) row removed from src/Concelier/__Libraries/StellaOps.Concelier.Core/RuntimePluginBundleInventory.cs.
• Built bundle artifacts removed from disk (devops/plugins/concelier/recommended/cloud-azure/, devops/plugins/_publish/concelier/StellaOps.Concelier.Connector.Cloud.Azure/). These are git-ignored build outputs; the authoritative bundle definition lives in the packaging script + inventory above.

What was intentionally NOT touched

• The seeded DB catalog row ('azure', ...) in src/Concelier/__Libraries/StellaOps.Concelier.Persistence/Migrations/001_v1_concelier_baseline.sql is left in place. It is enabled=false, so it ingests nothing and is harmless. Migration policy is forward-only (ADR-004); editing the baseline insert would not affect already-migrated databases anyway. If an operator wants the orphaned row gone, a future forward migration can DELETE FROM vuln.sources WHERE key = 'azure'.
• Historical packaging run reports under devops/plugins/_reports/*.json (git-ignored, timestamped) still mention cloud-azure; these are immutable build logs and are left as-is.

Coverage proof

Azure advisories continue to flow through MSRC (source 'microsoft'). No advisory coverage is lost by this removal because the azure connector never produced any advisories in the first place.

Verification (2026-06-25)

• dotnet build src/Concelier/StellaOps.Concelier.WebService/...csproj — Build succeeded, 0 errors (host no longer references the Azure project).
• dotnet build of StellaOps.Concelier.Connector.CloudHardwareAliases.Tests — 0 errors / 0 warnings.
• MTP exe run of that test suite — 13 tests, 0 errors; the single failure is the pre-existing Alias_Count_Matches_Seed_Migrations hardware-count assertion (asserts 4 hardware aliases, HardwareAliases lists only 3 — ARM not wired), which was already red at HEAD before this change and is tracked separately. The cloud-count portion of that test (Assert.Equal(2, CloudAliases.Count())) passes, and all AWS/GCP/hardware behavioral cases pass.

Removal details — auscert / ACSC

Why removed (data-availability, not a code defect)

The ACSC connector (source key 'auscert') is removed from the active deployed plugin set because this deployment has no working data path into it:

1. Lab fixture is a stub, not data. The fixture-mode override points the connector at http://advisory-fixture.stella-ops.local/cert/auscert/ (devops/compose/docker-compose.fixture-mode.yml), but in this deployment that path returns a generic 49-byte health stub, not real ACSC RSS. ParseAsync therefore has no valid feed to ingest.
2. Real upstream is bot-blocked from DC egress. www.cyber.gov.au sits behind Akamai Bot Manager, which frequently terminates datacenter-ASN HTTP/2 streams. The realfeeds override already documents this as best-effort / SCRAPER / REGION_CERT (devops/compose/docker-compose.realfeeds-full.override.yml, the Concelier__Sources__Auscert__BaseEndpoint=https://www.cyber.gov.au/ line).
3. No relay configured. There is no RelayEndpoint wired to proxy the fetch from a residential / allowed egress, so neither (1) nor (2) yields data.

With the fixture dead and the live feed unreachable and no relay, the connector can only fail or no-op. Keeping it mounted produces failing/empty jobs and operator confusion, so it is dropped from the recommended runtime bundle set until a viable data path exists.

What was changed

• Packaging: acsc plugin entry removed from the $recommendedProjects list in devops/build/package-runtime-plugins.ps1 (replaced with a comment explaining why and how to re-add it).
• Runtime inventory: acsc OptionalConnector(...) row removed from src/Concelier/__Libraries/StellaOps.Concelier.Core/RuntimePluginBundleInventory.cs (replaced with an explanatory comment).
• Built bundle artifacts removed from disk (devops/plugins/concelier/recommended/acsc/, devops/plugins/_publish/concelier/StellaOps.Concelier.Connector.Acsc/). These are git-ignored build outputs; the authoritative bundle definition lives in the packaging script + inventory above. Removing the directory from the recommended profile means it will not be bind-mounted into the live Concelier service on the next deploy (the service mounts ../plugins/concelier/recommended:/app/plugins/concelier/recommended:ro).

What was intentionally NOT touched

• The connector source project is retained in full (src/Concelier/__Libraries/StellaOps.Concelier.Connector.Acsc/). This is a data-availability disposition, not a code-quality removal — the connector parses ACSC RSS correctly.
• The connector test project is retained (src/Concelier/__Tests/StellaOps.Concelier.Connector.Acsc.Tests/) and stays green (32/32).
• Compose fixtures and the Concelier__Sources__Auscert__* env wiring in the fixture-mode / realfeeds overrides are left as-is — they document the (currently non-viable) feed shape and are the re-enable point once a relay exists.
• Any seeded DB catalog row for auscert and historical git-ignored packaging run reports under devops/plugins/_reports/*.json are left as-is (forward-only migration policy; immutable build logs).

Re-enable path

When a relay or real-data path becomes available, re-add the acsc entry to both package-runtime-plugins.ps1 ($recommendedProjects) and RuntimePluginBundleInventory.cs (OptionalConnector("acsc", "auscert", ...)), re-run package-runtime-plugins.ps1 to regenerate the devops/plugins/concelier/recommended/acsc/ bundle, point Concelier__Sources__Auscert__BaseEndpoint (and a RelayEndpoint) at the working source, then redeploy Concelier and re-run source:auscert:fetch.

Verification (2026-06-25)

• dotnet build src/Concelier/__Libraries/StellaOps.Concelier.Core/...csproj — Build succeeded, 0 errors (inventory edit compiles; 2 pre-existing STELLA0100 analyzer warnings unrelated to this change).
• dotnet build src/Concelier/StellaOps.Concelier.WebService/...csproj — Build succeeded, 0 errors (Concelier host still compiles after the removal).
• dotnet build of StellaOps.Concelier.Connector.Acsc.Tests — 0 errors / 0 warnings (retained connector + tests still compile).
• MTP exe run of StellaOps.Concelier.Connector.Acsc.Tests.exe — Total: 32, Errors: 0, Failed: 0, Skipped: 0 — confirming the connector code is sound and the removal is purely a data-availability decision.

Fix details — adobe

Root cause (fixture-date-aging, not a code defect)

AdobeConnector.LoadIndexAsync derives its fetch window from wall-clock time (src/Concelier/__Libraries/StellaOps.Concelier.Connector.Vndr.Adobe/AdobeConnector.cs:297-304):

var now           = _timeProvider.GetUtcNow();       // real clock in prod
var backfillStart = now - _options.InitialBackfill;  // InitialBackfill default = 90 days
var windowStart   = cursor.LastPublished.HasValue
    ? cursor.LastPublished.Value - _options.WindowOverlap
    : backfillStart;
if (windowStart < backfillStart) windowStart = backfillStart;

and then drops any index entry older than the window as droppedOldByWindow (AdobeConnector.cs:379: if (entry.PublishedUtc < windowStart) ...).

The committed offline fixture (devops/compose/fixtures/integration-fixtures/advisory/data/vendor/adobe/adobe-index.html) lists two bulletins published September 8–9, 2025:

• APSB25-85 — Adobe Acrobat Reader — “September 9, 2025”
• APSB25-87 — Adobe Premiere Pro — “09/08/2025”

With the default 90-day InitialBackfill, backfillStart is ~90 days before the current wall clock (now far past Sep 2025), so both fixture entries fall before windowStart and are dropped. The connector therefore ingests 0 advisories from the fixture — even though the code path is correct.

Why the fixture is not the fix

devops/compose/fixtures/.../adobe/_PROVENANCE.md (frozen at sprint 20260504_004, criterion FIXTURE-002) requires the fixture to remain byte-identical to its upstream test-fixture source so the connector’s date-anchored AdobeConnectorFetchTests (which pin a FakeTimeProvider to 2025-09-10) stay deterministic. Re-dating the fixture HTML would break that contract. The fix instead widens the runtime window so the frozen dates stay in-range.

What was changed

• New override file devops/compose/docker-compose.adobe-fixture.override.yml sets Concelier__Sources__Adobe__InitialBackfill=36500.00:00:00 (~100 years). This is the same approach as docker-compose.nvd-real.override.yml (Concelier__Sources__Nvd__InitialBackfill) and docker-compose.osv-real.override.yml (Concelier__Sources__Osv__InitialBackfill=36500.00:00:00), both of which set InitialBackfill for the identical frozen-date reason.
• The env-var key maps to the canonical config section concelier:sources:adobe, which AdobeDependencyInjectionRoutine.Register binds last (highest precedence, AdobeDependencyInjectionRoutine.cs:35).

What was intentionally NOT touched

• The connector source and tests (src/Concelier/__Libraries/StellaOps.Concelier.Connector.Vndr.Adobe/, src/Concelier/__Tests/StellaOps.Concelier.Connector.Vndr.Adobe.Tests/) — the code is correct.
• The byte-identical fixture under devops/compose/fixtures/integration-fixtures/advisory/data/vendor/adobe/ and the test Fixtures/ corpus — preserves _PROVENANCE.md / FIXTURE-002 determinism.
• The Adobe wiring in docker-compose.fixture-mode.yml / docker-compose.realfeeds-full.override.yml — left as-is.

Deploy path (post-drains, coordinated — NOT done in this change)

Append docker-compose.adobe-fixture.override.yml to the compose chain after the base files so it wins, recreate/redeploy Concelier with the existing fixture-mode chain, then re-run source:vndr-adobe:fetch → :parse → :map. No image rebuild and no egress are required — the data already lives in the in-repo fixture.

Verification (2026-06-25)

• dotnet build of StellaOps.Concelier.Connector.Vndr.Adobe.csproj — Build succeeded, 0 errors (2 pre-existing STELLA0100 canonicalization warnings in unrelated Concelier.Core / StellaOps.Plugin files).
• dotnet build of StellaOps.Concelier.Connector.Vndr.Adobe.Tests.csproj — 0 errors / 0 warnings.
• MTP exe run of StellaOps.Concelier.Connector.Vndr.Adobe.Tests.exe — Total: 17, Errors: 0, Failed: 0, Skipped: 0 (Postgres testcontainer) — confirming the connector code is sound and the issue is purely fixture-date aging, addressed by the runtime override.

Fix details — distro-arch

Root cause (missing capability — offline-snapshot-only, no live-fetch)

The Arch connector shipped with FetchAsync reading ASA JSON files from a local snapshot directory only (src/Concelier/__Libraries/StellaOps.Concelier.Connector.Distro.Arch/ArchConnector.cs, old FetchAsync → ArchSnapshotReader.Read). Its default snapshot path (ArchOptions.DefaultSnapshotRelativePath = "src/__Tests/__Datasets/os/arch-asa-snapshot") is a test dataset that is not present in the runtime image, so on a stock deployment the directory does not exist → the connector logs a warning and no-ops, ingesting 0 advisories. ArchOptions.BaseUri existed in the options class but was never read by any code path, no IHttpClientFactory client was registered for the source, and nothing performed a network fetch. The connector was therefore inert in production unless an operator manually provisioned a snapshot directory.

What was changed (live-fetch path against the Arch Security Tracker)

• ArchOptions— BaseUri now defaults to https://security.archlinux.org/ (live-first); added LiveFeedPath (default json), FallbackToSnapshotOnLiveFailure (default true), and ResolveLiveFeedUri(). Operators force snapshot-only / air-gap mode by setting Concelier__Sources__Arch__BaseUri to empty.
• Internal/ArchTrackerFeedParser.cs(new) — parses the live feed, which is a JSON array of AVG (Arch Vulnerability Group) objects (a different shape from the per-advisory ASA object the snapshot pipeline reads), and projects each group onto the existing ArchAsaDto. A group’s canonical name is its first published ASA id (falling back to the AVG id) so live and snapshot ingestion key advisories identically; groups with no affected packages or no CVE ids are dropped.
• ArchConnector.FetchAsync— split into FetchLiveAsync (HTTP GET of the resolved feed URI via the concelier.arch named client, fan-out into per-group documents tagged source.kind=live) and the prior snapshot path (FetchSnapshotAsync, now tagged source.kind=snapshot). Live is attempted first when BaseUri + an IHttpClientFactory are present; on failure it falls back to the snapshot (unless FallbackToSnapshotOnLiveFailure=false, which surfaces the failure and marks the source failed). Each group is re-serialized into canonical ASA JSON via the new SerializeAsaDto so the unchanged ParseAsync/MapAsync pipeline (and ArchAsaParser/ArchMapper) produces the same pkg:alpm/arch advisories.
• ArchServiceCollectionExtensions— registers the concelier.arch source HTTP client (AddSourceHttpClient) with the tracker host allowlisted; the connector treats the factory as optional, so this registration is what lights up the live path.
• Latent fetch→parse bug fixed in both paths — documents are now persisted with their raw Payload and the raw-storage blob id is the document id, so ParseAsync recovers the bytes via the document store even after a worker scope reset (the Postgres document store stamps PayloadId = row.Id on read). Without this, the previously-untested fetch→parse hop failed with Blob ... not found on a real Postgres deployment.

What was intentionally NOT touched

• The offline snapshot dataset (src/__Tests/__Datasets/os/arch-asa-snapshot/) and the existing parser/mapper/snapshot-reader/DTO — they remain the air-gap data path and are unchanged in behaviour.
• Job schedules / DI routine cron wiring (ArchDependencyInjectionRoutine).

Tests (new, in StellaOps.Concelier.Connector.Distro.Arch.Tests)

• Fixtures/arch-tracker-feed.json — a representative in-repo fixture reflecting the documented tracker feed shape (AVG groups with packages/status/ severity/affected/fixed/issues/advisories). No external egress was performed authoring it (AGENTS.md §2.8).
• ArchTrackerFeedParserTests — projection, serialize↔parse round-trip, parse→map producing pkg:alpm/arch advisories, and a malformed-payload guard (no DB).
• ArchConnectorLiveFetchTests — the live-fetch forcing function: drives FetchAsync against a canned HTTP response serving the fixture, asserts the GET hit the resolved feed URI, per-group source.kind=live documents persisted, and the full parse+map landed canonical advisories (bash 5.2.026-1 fixed, curl unfixed→affected). A second case proves live-failure → snapshot fallback. Uses the shared Postgres testcontainer; skips when Docker is unavailable.

Deploy path (post-drains, coordinated — NOT done in this change)

To make this live, the Concelier deployment needs egress to security.archlinux.org(the code already in a rebuilt image, or this change shipped in the next image build), then re-run source:distro-arch:fetch → :parse → :map. For an air-gapped deployment, instead provision an ASA snapshot directory and point Concelier__Sources__Arch__SnapshotPath at it (and optionally clear Concelier__Sources__Arch__BaseUri to skip the live attempt). No compose override is required for the default live behaviour.

Verification (2026-06-25)

• dotnet build of StellaOps.Concelier.Connector.Distro.Arch.csproj — Build succeeded, 0 errors (2 pre-existing STELLA0100 canonicalization warnings in unrelated Concelier.Core / StellaOps.Plugin files; TreatWarningsAsErrors is on for the connector project and it is clean).
• dotnet build of the test project — 0 errors / 0 warnings.
• MTP exe run of StellaOps.Concelier.Connector.Distro.Arch.Tests.exe — Total: 23, Errors: 0, Failed: 0, Skipped: 0 (Postgres testcontainer), including the new parser tests and the live-fetch forcing-function tests.

Fix details — distro-gentoo

Root cause (missing capability — offline snapshot loader, no live fetcher)

The Gentoo GLSA connector (src/Concelier/__Libraries/StellaOps.Concelier.Connector.Distro.Gentoo/) shipped with FetchAsync reading glsa-*.xml files from a local snapshot directory only. The previous GentooGlsaConnector facade and the connector AGENTS.md both stated the live IFeedConnector HTTP path was intentionally deferred (“does not use SourceFetchService and does not perform live HTTP”). The default snapshot path (GentooGlsaOptions.DefaultSnapshotRelativePath = "src/__Tests/__Datasets/os/gentoo-glsa-snapshot") is a test dataset that is not present in the runtime image, so on a stock deployment the directory does not exist → the connector logs a warning and no-ops, ingesting 0 advisories. No IHttpClientFactory client was registered for the source and nothing performed a network fetch.

What was changed (live-fetch path against security.gentoo.org)

• GentooGlsaOptions— BaseUri now defaults to https://security.gentoo.org/glsa/ (live-first); added IndexPath (default glsa-index.txt), AdvisoryPathFormat (default glsa-{0}.xml), FallbackToSnapshotOnLiveFailure (default true), FetchTimeout, UserAgent, HttpClientName (concelier.gentoo), and ResolveIndexUri() / ResolveAdvisoryUri(id). Operators force snapshot-only / air-gap mode by setting Concelier__Sources__Gentoo__BaseUri to empty.
• Internal/GlsaIndexParser.cs(new) — parses the GLSA plaintext listing index into canonical GLSA ids (YYYYNN-NN). Permissive about line shape (glsa-202401-01.xml, bare 202401-01, # comments and blank lines ignored); output is ordinal-sorted and de-duplicated so the fan-out fetch order is deterministic and independent of upstream ordering.
• GentooGlsaFeedConnector.FetchAsync— split into FetchLiveAsync (HTTP GET of the resolved index URI via the concelier.gentoo named client, then a GET of each referenced glsa-{id}.xml, persisting per-advisory documents tagged source.kind=live) and the prior snapshot path (FetchSnapshotAsync, tagged source.kind=snapshot). Live is attempted first when BaseUri + an IHttpClientFactory are present; on failure it falls back to the snapshot (unless FallbackToSnapshotOnLiveFailure=false, which surfaces the failure and marks the source failed via MarkFailureAsync). Parse and Map are unchanged — both live and snapshot documents are GLSA XML consumed by the existing GlsaXmlParser, producing the same pkg:gentoo/<cat>/<name> advisories.
• GentooGlsaServiceCollectionExtensions— registers the concelier.gentoo source HTTP client (AddSourceHttpClient) with the Gentoo host allowlisted; the connector treats the factory as optional, so this registration is what lights up the live path. GentooGlsaFeedConnector gained an optional IHttpClientFactory? constructor parameter (mirrors Distro.Arch).
• GentooGlsaRuntimeOverlay / GentooGlsaConfigurationContributor— surface baseUri, indexPath, advisoryPathFormat, and fallbackToSnapshotOnLiveFailure as persisted/overlayable source settings.
• Latent fetch→parse bug fixed in the new live path — documents are persisted with their raw Payload and the raw-storage blob id is the document id, so ParseAsync recovers the bytes via the document store even after a worker scope reset (the Postgres document store stamps PayloadId = row.Id on read). The first test run reproduced this exactly as Blob ... not found on a real Postgres deployment; the fix is identical to the distro-arch fix.

What was intentionally NOT touched

• The offline snapshot data path (GlsaSnapshotLoader, GentooGlsaConnector static facade) and the existing parser/mapper/DTO — they remain the air-gap data path and are unchanged in behaviour. The snapshot FetchSnapshotAsync body is the prior FetchAsync body verbatim (still uses the 5-arg UploadAsync without persisting Payload); the latent fetch→parse hop on the snapshot path was left as-is to stay strictly scoped to the live-fetch task.
• Job schedules / DI routine cron wiring (GentooGlsaDependencyInjectionRoutine).
• Other connectors and the running Concelier service (a backfill drain was in progress; no redeploy/restart/image rebuild was performed).

Tests (new, in StellaOps.Concelier.Connector.Distro.Gentoo.Tests)

• Fixtures/live/glsa-index.txt — a representative in-repo GLSA listing index reflecting the documented feed shape (one glsa-*.xml per line, # comments). No external egress was performed authoring it (AGENTS.md §2.8); the per-advisory documents reuse the existing Fixtures/glsa-*.xml corpus.
• GlsaIndexParserTests — pure unit (no DB), always runs: canonical-id extraction, comment/blank-line skipping, bare-id lines, dedup + ordinal sort, non-GLSA line rejection, empty input.
• GentooGlsaLiveFetchTests — the live-fetch forcing function: drives FetchAsync against canned HTTP responses serving the index + glsa XML fixtures, asserts the GET hit the resolved index and per-advisory URIs, per-advisory source.kind=live documents persisted (with gentoo.glsa.id / source.indexUri metadata), and the full parse+map landed canonical pkg:gentoo/app-shells/bash and pkg:gentoo/sys-libs/glibc advisories. A second case proves live-failure → snapshot fallback; a third proves BaseUri=null stays snapshot-only with zero HTTP requests issued. Uses the shared Postgres testcontainer; skips when Docker is unavailable (the index-parser proof still runs).

Deploy path (post-drains, coordinated — NOT done in this change)

To make this live, the Concelier deployment needs the new code in a rebuilt image (this is a source change, not just a config flip) and egress to security.gentoo.org, then re-run source:distro-gentoo-glsa:fetch → :parse → :map. For an air-gapped deployment, instead provision a GLSA snapshot directory and point Concelier__Sources__Gentoo__SnapshotPath at it (and optionally clear Concelier__Sources__Gentoo__BaseUri to skip the live attempt). No compose override is required for the default live behaviour. Snapshot provisioning alternative: mirror the data/glsa.git glsa-*.xml set (and a glsa-index.txt listing) into an offline-kit directory mounted at the configured SnapshotPath — the connector ingests it identically to the live path.

Verification (2026-06-25)

• dotnet build of StellaOps.Concelier.Connector.Distro.Gentoo.csproj — Build succeeded, 0 errors (2 pre-existing STELLA0100 canonicalization warnings in unrelated Concelier.Core / StellaOps.Plugin files; TreatWarningsAsErrors is on for the connector project and it is clean).
• dotnet build of the test project — 0 errors / 0 warnings.
• MTP exe run of StellaOps.Concelier.Connector.Distro.Gentoo.Tests.exe — Total: 31, Errors: 0, Failed: 0, Skipped: 0 (Postgres testcontainer), including the 6 new GlsaIndexParserTests and the 3 new GentooGlsaLiveFetchTests live-fetch forcing-function cases. The first run surfaced (then the fix resolved) the real Blob ... not found fetch→parse bug.