18 releases 22 tags

RSS feed

• v1.6.10-ew-1 446f4a63bc

  Compare

  Release v1.6.10-ew-1 Stable

  engel75 released this 2026-08-14 17:45:55 +02:00 | 0 commits to 1.6.10-ew1 since this release

  Release v1.6.10-ew-1

  Port of the EW fork to upstream transports/v1.6.10.

  Base: transports/v1.6.10 (40 upstream commits since v1.6.9).
  33 commits cherry-picked from 1.6.9-ew1, 1 conflict (migrations.go).

  Upstream v1.6.10 notable changes:

  • Quarterly budget reset (add_budget_reset_config_column migration)
  • Per-model budget support
  • Reasoning bugfixes
  • ResolveChatFileURLs in HandleOpenAIChatCompletion (benign for EW, signatures unchanged)

  Conflict resolution:

  • migrations.go: upstream add_budget_reset_config_column placed before EW's
    add_ew_key_config_columns + add_ew_allowed_requests_column (EW migrations remain last)

  EW fork features carried forward (Specs 01-06, 09):

  • 01: EW provider (SGLang/OpenAI-compatible)
  • 02: Per-key API toggles (allowed_requests)
  • 03: OpenAI error envelope
  • 04: Whitelisted inference routes
  • 05: Docker / Forgejo CI
  • 06: Migration strategy (EW migrations always last)
  • 09: EW image-edit passthrough

  Verification:

  • go vet: clean
  • 4 test suites: all green (TestAuth, integrations, EW, configstore)
  • Docker: 112 EW symbols, 102 Spec 09 symbols, version v1.6.10-ew-1
  • Migration order: add_budget_reset_config_column before EW migrations (last 2)
  • No Go version bump

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.6.9-ew-1 39526582d5

  Compare

  v1.6.9-ew-1 Stable

  engel75 released this 2026-08-08 15:20:29 +02:00 | -2278 commits to 1.4.23-ew since this release

  Port to upstream transports/v1.6.9

  Base: transports/v1.6.9 (55 upstream commits since v1.6.8)
  32 commits cherry-picked from 1.6.8-ew1 — zero conflicts (all auto-merged)

  Upstream v1.6.9 notable changes

  • Encrypted-reasoning fail-soft in executeRequestWithRetries — no overlap with our EW code
  • BifrostContextKeyBaseProviderType + ResolveBaseProvider for custom provider family resolution
  • Budget/RateLimit usage carry-forward (prevents config.json force-sync from zeroing live accounting)
  • OpenAIChatAssistantMessage: ReasoningAlias + ReasoningDetails (inbound-only)
  • TracingMiddleware: W3C traceparent header fix
  • tracer_test.go:42:15 vet error fixed upstream
  • No new migrations

  EW fork features carried forward

  Spec	Feature
  01	EW provider (SGLang/OpenAI-compatible)
  02	Per-key API toggles
  03	OpenAI-conformant error envelope
  04	WhitelistedRoutes inference bypass
  05	Docker / Forgejo CI
  06	Migration strategy (idempotent, last in sequence)
  09	EW image-edit parameter passthrough + ExtraParams + dual mask

  Verification

  • ✅ Build OK, vet completely clean (upstream fixed pre-existing tracer_test.go error)
  • ✅ 4 test suites green + Spec 09 image-edit tests green
  • ✅ Docker smoke: 112 symbol matches, 102 Spec-09 symbols, version v1.6.9-ew1-test correct
  • ✅ Migration order verified (no new upstream migrations)

  Follow-ups

  None.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.6.8-ew-1 0787a10e43

  Compare

  v1.6.8-ew-1 Stable

  engel75 released this 2026-08-08 15:03:22 +02:00 | -2222 commits to 1.4.23-ew since this release

  Port to upstream transports/v1.6.8

  Base: transports/v1.6.8 (48 upstream commits since v1.6.7)
  31 commits cherry-picked from 1.6.7-ew2 — zero conflicts (all auto-merged)

  Upstream v1.6.8 notable changes

  • SSE heartbeat in handleStreamingResponse (lib.StartSSEHeartbeat) — no overlap with our Gate 2
  • 3 new migrations (budget_override_anchor, live_models_sync_interval, pricing_override_user_id) — all before our 2 EW migrations
  • Router heartbeat + anthropic integration test additions

  EW fork features carried forward

  Spec	Feature
  01	EW provider (SGLang/OpenAI-compatible)
  02	Per-key API toggles
  03	OpenAI-conformant error envelope
  04	WhitelistedRoutes inference bypass
  05	Docker / Forgejo CI
  06	Migration strategy (idempotent, last in sequence)
  09	EW image-edit parameter passthrough + ExtraParams + dual mask

  Verification

  • ✅ Build OK, vet clean (only pre-existing upstream tracer_test.go:42:15)
  • ✅ 4 test suites green + Spec 09 image-edit tests green
  • ✅ Docker smoke: 112 symbol matches, 101 Spec-09 symbols, version v1.6.8-ew1-test correct
  • ✅ Migration order verified (3 new upstream migrations before 2 EW migrations)

  Follow-ups

  None.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.6.7-ew-2 8486869f28

  Compare

  v1.6.7-ew-2 Stable

  engel75 released this 2026-08-07 10:26:02 +02:00 | 1 commits to 1.6.7-ew2 since this release

  EW Image Edit Parameter Passthrough (Spec 09)

  Builds on 1.6.7-ew1 (upstream transports/v1.6.7).
  1 commit: EW /v1/images/edits full SGLang + vllm-omni compatibility.

  Problem

  parseImageEditFormDataBodyFromRequest silently dropped 4 fields (type, negative_prompt, num_inference_steps, seed) and ignored ExtraParams entirely. The transport layer blocked url-only input and truncated multi-value form fields to their first value.

  Fix

  Two independent EW-only gates (providerName == schemas.EW in images.go, provider == schemas.EW in inference.go). Non-EW path is byte-identical (0 deletions in images.go diff, regression guard test unchanged).

  Changes

  • images.go: Gate 1 — 4 fields + sorted ExtraParams + dual mask (mask + mask_image for SGLang/vllm-omni compatibility)
  • inference.go: Gate 2 — url-only input relaxation + ExtraParams []string sweep + mask_image inbound fallback + context leak fix
  • Tests: EW 25-element field-order test, OpenAI ExtraParams-ignored regression guard, prepareImageEditRequest EW + non-EW tests
  • Harness: EW Postman environment, capability block, image edit entries
  • Docs: specs/09-ew-image-edit-passthrough.md, AGENTS.md Gotcha #20

  Verification

  Build OK, vet clean, 4 test suites green. 3 oracle reviewers APPROVE (plan compliance, code quality, scope fidelity).

  Full diff: git log 1.6.7-ew1..1.6.7-ew2

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.6.4-ew-1 ceea7e2dd0

  Compare

  v1.6.4-ew-1: EW fork on bifrost v1.6.4 Stable

  engel75 released this 2026-07-15 14:47:11 +02:00 | -1844 commits to 1.4.23-ew since this release

  EW fork release based on upstream bifrost transports/v1.6.4.

  Upstream v1.6.4 brachte 144 Commits / 395 geänderte Dateien — siehe Spec 08 port log für Details.

  What's new vs v1.6.3-ew-2

  Bug fix: /v1/models filtert nach EWKeyConfig.ModelName (bereits in v1.6.3-ew-2, hier enthalten)

  /v1/models liefert pro EW-Key nur noch das konfigurierte Modell statt aller Backend-Modelle.

  v1.6.4 OpenAI Handler Signaturen

  v1.6.4 fügte einen neuen authHeaders map[string]string Parameter zu 7 HandleOpenAI*-Funktionen hinzu. EW ruft 4 davon auf (Speech, Transcription, ImageGeneration, ImageEdit) — nil wird übergeben (keine Azure Auth Headers).

  v1.6.4 mergeUpdatedKey Refactoring

  v1.6.4 refactorte mergeUpdatedKey: oldRedactedKey entfernt, preserve() Helper eingeführt. EW's URL-Preservation folgt dem VLLM-Pattern mit preserve().

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models mit EWKeyConfig.ModelName-Filter
  02	Per-key API toggles (EWKeyConfig.AllowedRequests)
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes
  04	WhitelistedRoutes config bypasses governance VK-required gate
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows

  Container image

  forge.engelmann.me/engel75/bifrost:v1.6.4-ew-1
  

  Verification

  • Alle 4 Test-Suites grün (handlers TestAuth, integrations, EW, configstore)
  • make build LOCAL=1 clean
  • Docker-Build: 112 Symbol-Matches, Version exakt v1.6.4-ew1-test
  • Migration-Order: add_bedrock_project_id_columns → add_ew_key_config_columns → add_ew_allowed_requests_column
  • Diff-Parity: identische File-Set wie v1.6.3-Port
  • 0 pre-existing Test-Failures

  See Spec 08 — Version Port Log für die volle Historie.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.6.3-ew-2 067c5e95d3

  Compare

  v1.6.3-ew-2: fix /v1/models to filter by EWKeyConfig.ModelName Stable

  engel75 released this 2026-07-13 14:51:14 +02:00 | -1697 commits to 1.4.23-ew since this release

  EW fork release based on upstream bifrost transports/v1.6.3.

  What's new vs v1.6.3-ew-1

  Bug fix: /v1/models filtert jetzt nach EWKeyConfig.ModelName

  Bisher lieferte /v1/models für den EW-Provider alle Modelle, die das SGLang-Backend meldete — auch solche, die gar nicht über den jeweiligen Key routbar sind. Ursache: EWKeyConfig.ModelName wurde nur für Request-Routing (Key-Selection) genutzt, nicht für ListModels.

  listModelsByKey (core/providers/ew/ew.go) filtert jetzt die Response pro Key: wenn EWKeyConfig.ModelName gesetzt ist, werden nur noch Modelle behalten, deren Backend-Model-ID mit ModelName übereinstimmt (case-insensitive). Bei Multi-Key-Setups liefert jeder Key nur noch sein konfiguriertes Modell.

  Vorher: 5 EW-Keys → 35 Modelle (Union aller Backend-Modelle × 5 Backends)
  Nachher: 5 EW-Keys → 5 Modelle (je 1 pro Key)

  Edge-Cases: ModelName == "" oder EWKeyConfig == nil → kein Filter (rückwärtskompatibel). request.Unfiltered == true → kein Filter (internes Flag für Model-Catalog-Sync).

  Container image

  forge.engelmann.me/engel75/bifrost:v1.6.3-ew-2
  

  Full changelog since v1.6.3-ew-1

  • 067c5e95d fix(ew): filter /v1/models by EWKeyConfig.ModelName

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    0 downloads
• v1.6.3-ew-1 9e48583d45

  Compare

  v1.6.3-ew-1: EW fork on bifrost v1.6.3 Stable

  engel75 released this 2026-07-08 09:46:41 +02:00 | -1696 commits to 1.4.23-ew since this release

  EW fork release based on upstream bifrost transports/v1.6.3.

  Upstream v1.6.3 brachte 162 Commits / 531 geänderte Dateien — siehe Spec 08 port log für Details.

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config bypasses governance VK-required gate for inference routes
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Port-Notes (was sich gegenueber v1.6.2 aenderte)

  In der Fork: 1 Follow-up-Commit fuer API-Drift. Upstream zwischen v1.6.2 und v1.6.3:

  1. OpenAI Handler Signaturen geaendert: openai.HandleOpenAI*-Funktionen haben jetzt authHeader map[string]string statt key schemas.Key (fuer TextCompletion/ChatCompletion/Embedding, via openai.BearerAuthHeader(key)) und einen neuen BodySigner-Parameter fuer ChatCompletion/ChatCompletionStreaming. Andere Handler (Speech, Transcription, Image*) nehmen weiterhin key schemas.Key. Follow-up ec5eaa78a adaptiert den EW-Provider analog zum SGL-Provider.

  2. Neue Provider: BedrockMantle + DeepSeek: Upstream fuegte zwei neue Provider hinzu. Beim Cherry-Pick von Spec 01 gab es 9 mechanische Konflikte ("beide Seiten fuegen verschiedene Felder am selben Ort ein") — alle als "beide behalten" geloest. EW-Felder koexistieren mit den neuen upstream-Feldern.

  3. NewEnvVar → NewSecretVar in middlewares_test.go (Spec 04 Test-Code, vom v1.6.2 SecretVar-Follow-up uebersehen).

  4. Keine neuen Plugins: v1.6.3 hat keine neuen plugins/-Verzeichnisse — die printf-go.work-Liste ist identisch mit v1.6.2 (11 Plugins).

  5. Go-Version bleibt 1.26.4: Kein Dockerfile-printf-Bump noetig. Die 2 historischen Go-Version-Bump-Commits waren empty und wurden skipped.

  Alle 21 Cherry-Picks abgeschlossen (19 angewandt, 2 empty skipped), plus 1 Follow-up.

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.6.3-ew-1
  

  Identical runtime semantics to upstream transports/v1.6.3 plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root, healthcheck on /health. Build-Stage nutzt Go 1.26.4 alpine image.

  Branches

  Branch 1.6.3-ew1 tracks this release. Cherry-pick-Pfad fuer die naechste upstream Version: Spec 07 — Port Runbook.

  Upgrade notes

  • Von v1.6.2-ew1-rc1: in-place safe. Alle v1.6.3 upstream Migrationen + 2 EW Migrationen laufen automatisch ueber migrator_meta.
  • Von v1.5.16-ew-1: in-place safe. Groesserer Sprung (v1.6.0–v1.6.3), aber alle Migrationen idempotent.
  • Von aelteren X.Y.Z-ew1 Versionen: in-place safe. Alle akkumulierten upstream Migrationen + 2 EW Migrationen laufen automatisch.
  • Von upstream transports/v1.6.3 (kein EW bislang): beim ersten Boot werden die EW-Spalten in config_keys angelegt. Existierende Keys bleiben unangetastet.

  Verification

  • Alle relevanten Go test suites gruen (handlers TestAuth, core/providers/ew, framework/configstore -short, integrations, SecretVar).
  • make build LOCAL=1 clean.
  • go vet: nur pre-existing tracer_test.go lock-copy warning.
  • Docker-Build: 112 Symbol-Matches, Version exakt v1.6.3-ew1-test.
  • Migration-Order: add_virtual_key_expires_at_column → add_ew_key_config_columns → add_ew_allowed_requests_column.
  • Plugin-Liste: 11 Plugins, identisch mit v1.6.3.
  • 0 pre-existing Test-Failures (im Gegensatz zu v1.6.2 mit 4 integrations-Failures).

  See Spec 08 — Version Port Log fuer die volle per-Version Historie.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.5.16-ew-1 fcf188e9db

  Compare

  v1.5.16-ew-1: EW fork on bifrost v1.5.16 Stable

  engel75 released this 2026-06-23 08:43:10 +02:00 | 0 commits to 1.5.16-ew1 since this release

  EW fork release based on upstream bifrost transports/v1.5.16.

  Größter Versionssprung bisher (290 substantielle upstream Commits, v1.5.12 bis v1.5.15 übersprungen) mit zwei breaking refactors die unseren Footprint direkt getroffen haben — siehe Spec 08 port log für Details.

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config bypasses governance VK-required gate for inference routes (HTTP inference auth is now pass-through in upstream v1.5.16 — bypass shifted entirely to governance plugin)
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Port-Notes (was sich gegenüber v1.5.11 änderte)

  In der Fork: nur kleine Anpassungen an upstream refactors. Upstream zwischen v1.5.11 und v1.5.16:

  1. Migration framework rebuild: Statt sequentieller triggerMigrations() body gibt es jetzt ein configstoreMigrationSteps []migrationStep array, das von runMigrationSteps() durchlaufen wird. Jede Migration‑Funktion bekommt ein zusätzliches logger schemas.Logger Argument. Unsere zwei EW Migrationen wurden auf die neue 3‑arg Signatur portiert (mit Start/Finish Logging) und als Steps am Ende des Arrays eingefügt. Migrations‑IDs unverändert — backwards‑compatible auch für DBs die bereits frühere ew_* Migrationen liefen.

  2. InferenceMiddleware pass‑through: HTTP Inference Auth ist jetzt komplett pass‑through, alle Auth‑Entscheidungen für /v1/... Routes laufen über die Governance Plugin. Unsere Spec 04 funktioniert weiterhin, aber der WhitelistedRoute Bypass läuft nur noch über die Governance Plugin (die unseren Bypass‑Code seit der ersten Spec‑04 Implementation hat). Operator‑sichtbares Verhalten unverändert.

  3. DisableAuthOnInference AuthConfig entfernt — ein Test musste entsprechend angepasst werden (separater Follow‑up commit).

  4. Keine neuen API drifts — v1.5.10 Provider Interface Adaptations (ConfigureDialer 2‑arg, Compaction stub) sind dauerhaft Teil der Fork und propagieren automatisch.

  5. Keine Go‑Bumps — go.mod blieb auf 1.26.4.

  Alle 16 Cherry‑Picks abgeschlossen (12 clean, 4 mit Konfliktauflösung), plus 1 Follow‑up Test‑Fix.

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.5.16-ew-1
  

  Identical runtime semantics to upstream transports/v1.5.16 plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root, healthcheck on /health. Build-Stage nutzt Go 1.26.4 alpine image.

  Branches

  Branch 1.5.16-ew1 tracks this release. Frühere ew1 releases (1.5.3-ew1 bis 1.5.11-ew1) bleiben verfügbar. Cherry-pick-Pfad für die nächste upstream Version: Spec 07 — Port Runbook.

  Upgrade notes

  • Von v1.5.11-ew-1: in-place safe. Beachte den größeren Sprung — upstream hat zwischen v1.5.11 und v1.5.16 alle neue DB‑Migrationen die idempotent durchlaufen sobald die ew1‑Migrationen umgesetzt werden. Die EW Migrations‑IDs sind unverändert, also bereits gelaufene EW Migrationen werden skipped.
  • Von v1.5.10-ew-2: empfohlenes Upgrade, schließt alle v1.5.11+v1.5.12+...+v1.5.16 upstream Features ein, gleichzeitig private network fix bleibt aktiv.
  • Von älteren X.Y.Z-ew1 Versionen: in-place safe. Alle akkumulierten upstream Migrationen + 2 EW Migrationen laufen automatisch über migrator_meta.
  • Von upstream transports/v1.5.16 (kein EW bislang): beim ersten Boot werden die EW-Spalten in config_keys angelegt. Existierende Keys bleiben unangetastet.

  Verification

  • Alle relevanten Go test suites grün (handlers TestAuth, core/providers/ew, framework/configstore -short).
  • ⚠ Ein integrations‑test (TestCreateHandler_AnthropicRouteClears_UseRawRequestBody_WhenCatalogSelectsBedrock) fällt fehl — verifiziert dass es ein pre‑existing upstream bug ist (auch auf reinem transports/v1.5.16 ohne EW changes rot). Nicht release‑blocker.
  • docker build clean.
  • Symbol-Check: 109 matches im Binary (alle 5 Specs detektiert).
  • Version string in /app/main ist exakt v1.5.16-ew-1.

  See Spec 08 — Version Port Log für die volle per-Version Historie.

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download
• v1.5.11-ew-2 9e762af0fd

  Compare

  v1.5.11-ew-2: private network fix Stable

  engel75 released this 2026-06-09 10:03:19 +02:00 | 0 commits to 1.5.11-ew1 since this release

  Patch release auf top von v1.5.11-ew-1 mit demselben Production‑Bug‑Fix wie v1.5.10-ew-2.

  Was wurde gefixt

  fix(ew): always allow private network connections (9e762af0f)

  Beim ersten Production‑Deployment der ew-1 Branches bemerkt: alle list_models Calls gegen SGLang Server auf privaten Netzen (LAN, k8s, VPC) schlugen fehl mit failed to execute HTTP request to provider API.

  Root cause: der v1.5.10 Provider‑Interface‑Follow‑up reichte config.NetworkConfig.AllowPrivateNetwork durch upstream's neue ConfigureDialer(client, bool) Signatur. Default false aktiviert die upstream SSRF‑Defense, die alle RFC 1918 IPs blockiert (10.x, 172.16‑31.x, 192.168.x) — genau das Netz auf dem EW‑Backends laufen. Der Bug propagierte unverändert von v1.5.10 nach v1.5.11.

  Fix: true hartkodiert im EW Provider Init. EW ist per Spec 01 explizit für "locally hosted models" — der upstream Default macht für Cloud‑Provider (OpenAI, Anthropic, …) Sinn, nicht für EW. Operatoren mit public‑only EW Backends sind aktuell nicht unterstützt.

  Siehe Spec 01 "Network policy" und Spec 08 Nachtrag für den vollen Hintergrund.

  Container image

  forge.engelmann.me/engel75/bifrost:v1.5.11-ew-2
  

  Funktional identisch zu v1.5.11-ew-1, nur mit dem Dialer‑Fix. Empfohlene Produktions‑Version.

  Upgrade notes

  • Von v1.5.11-ew-1: trivialer Drop‑in. Keine Schema‑Änderung, keine neue Migration. Container neu pullen, Container neu starten — fertig.
  • Von v1.5.10-ew-2: Upstream v1.5.10 → v1.5.11 + 0 fork‑seitige Änderungen. Wenn du sowieso auf v1.5.11 upstream willst, wechsel direkt hierher.
  • Aus älteren Versionen (v1.5.7-ew-1, v1.5.8-ew-1): diese Releases haben den Bug nicht (der allowPrivateNetwork‑Parameter existierte upstream noch nicht). Wenn du sie aktuell nutzt: kein Handlungsbedarf, oder direkt auf v1.5.11-ew-2 upgraden.

  Andere ew-1 Branches

  Der gleiche Fix wurde auch auf 1.5.10-ew1 cherry‑picked und als v1.5.10-ew-2 released. Ältere Branches (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1, 1.5.8-ew1) brauchen den Fix nicht.

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download
• v1.5.10-ew-2 165758b1d7

  Compare

  v1.5.10-ew-2: private network fix Stable

  engel75 released this 2026-06-09 09:58:05 +02:00 | 0 commits to 1.5.10-ew1 since this release

  Patch release auf top von v1.5.10-ew-1 mit einem Production‑Bug‑Fix.

  Was wurde gefixt

  fix(ew): always allow private network connections (165758b1d)

  Beim ersten Production‑Deployment der ew-1 Branches bemerkt: alle list_models Calls gegen SGLang Server auf privaten Netzen (LAN, k8s, VPC) schlugen fehl mit failed to execute HTTP request to provider API.

  Root cause: der v1.5.10 Provider‑Interface‑Follow‑up reichte config.NetworkConfig.AllowPrivateNetwork durch upstream's neue ConfigureDialer(client, bool) Signatur. Default false aktiviert die upstream SSRF‑Defense, die alle RFC 1918 IPs blockiert (10.x, 172.16‑31.x, 192.168.x) — genau das Netz auf dem EW‑Backends laufen.

  Fix: true hartkodiert im EW Provider Init. EW ist per Spec 01 explizit für "locally hosted models" — der upstream Default macht für Cloud‑Provider (OpenAI, Anthropic, …) Sinn, nicht für EW. Operatoren mit public‑only EW Backends sind aktuell nicht unterstützt.

  Siehe Spec 01 "Network policy" und Spec 08 Nachtrag für den vollen Hintergrund.

  Container image

  forge.engelmann.me/engel75/bifrost:v1.5.10-ew-2
  

  Funktional identisch zu v1.5.10-ew-1, nur mit dem Dialer‑Fix.

  Upgrade notes

  • Von v1.5.10-ew-1: trivialer Drop‑in. Keine Schema‑Änderung, keine neue Migration. Container neu pullen, Container neu starten — fertig.
  • Aus älteren Versionen (v1.5.7-ew-1, v1.5.8-ew-1): diese Releases haben den Bug nicht (der allowPrivateNetwork‑Parameter existierte upstream noch nicht). Wenn du sie aktuell nutzt: kein Handlungsbedarf, oder direkt auf v1.5.11-ew-2 upgraden falls du die v1.5.10/v1.5.11 upstream features brauchst.

  Andere ew-1 Branches

  Der Fix wurde auch auf 1.5.11-ew1 cherry‑picked und als v1.5.11-ew-2 released. Ältere Branches (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1, 1.5.8-ew1) brauchen den Fix nicht.

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download