Verifizierte Connectors (Drittanbieter)
Diese Seite ist das kuratierte Verzeichnis von Drittanbieter-Connectors. Sie ist das externe Pendant zum First-Party-Connector-Katalog: First-Party-Connectors werden mit dem Produkt ausgeliefert; die hier aufgeführten Connectors werden von ihren Herausgebern mit dem öffentlichen Connector-SDK gebaut, veröffentlicht und gepflegt.
Was “verifiziert” bedeutet
Abschnitt betitelt „Was “verifiziert” bedeutet“Ein gelistetes Release wurde von den Maintainern manuell erneut anhand dieser Checkliste verifiziert:
- Lizenzgrenze — der Connector baut außerhalb des Baums (out-of-tree) und
verlinkt nichts aus der AGPL-Engine (
go list -depszeigt keingithub.com/olivaresai/olivares/core); er importiert nur das Apache-2.0-SDK. - Signatur & Provenienz — das veröffentlichte Sigstore-Attestation-Bundle verifiziert gegen die angegebene Identität oder den öffentlichen Schlüssel des Herausgebers, und sein Subject-Digest stimmt mit dem freigegebenen Binary überein.
- Vertragskonformität —
Descriptor.Nameist mit Punkten notiert und anbieter-namespaced, die deklariertenConfigFieldsentsprechen dem, wasOpenliest, Secrets sind alsSecret: truedeklariert und werden per Referenz übergeben. - Minimal Data — der Connector emittiert Referenzen und Metadaten, niemals Payloads, Prompts oder Secret-Werte (stichprobenartige Prüfung der Emit-Pfade).
Was es nicht bedeutet: Verifizierung ist kein Sicherheitsaudit des
Herausgebers oder des beobachteten Systems, keine Empfehlung und kein Trust
Root — ein Operator, der einen verifizierten Connector verdrahtet, pinnt
weiterhin den Schlüssel oder die Identität des Herausgebers in connector_trust
und den Release-Digest im plugin-Block der Quelle. Die Zulassung am Host bleibt
in jedem Fall deny-closed.
Ein privater Connector muss hier nicht gelistet sein, um governed zu sein. Wenn ein
Operator seinen Digest und Trust Anchor in connector_trust pinnt, wendet die Engine
dieselbe deny-closed Admission und Runtime-Governance an. Dieser Index ist ein
Zertifizierungsnachweis für Auffindbarkeit und erneute Verifizierung, kein Trust Root.
Verzeichnis
Abschnitt betitelt „Verzeichnis“Noch sind keine Drittanbieter-Connectors gelistet — das Programm startet mit diesem Release. First-Party-Connectors finden Sie im Connector-Katalog.
Connector (Descriptor.Name) | Herausgeber | Art | Verifiziertes Release | Signatur | Quelle |
|---|---|---|---|---|---|
| noch keine |
Einen Connector einreichen
Abschnitt betitelt „Einen Connector einreichen“Öffnen Sie einen Pull Request gegen diese Seite, der eine Tabellenzeile hinzufügt und Folgendes verlinkt:
- das Quell-Repository und das Release (Binary +
sha256+ Sigstore-Bundle); - die Identität, gegen die verifiziert werden soll (OIDC-Identität + Issuer für keyless, oder den öffentlichen Schlüssel);
- die Ausgabe von
./scripts/check-boundary.shund den Testlauf in Ihrer CI.
Die Maintainer reproduzieren die obige Checkliste anhand der exakten Release-Artefakte. Ein neues Release eines gelisteten Connectors erfordert eine Aktualisierung der Zeile (die Re-Verifizierung erfolgt pro Release, weil das Urteil an den Digest gebunden ist). Veraltete oder zurückgezogene Releases werden entfernt.
Verwandt
Abschnitt betitelt „Verwandt“- Einen Connector bauen und ausliefern — der komplette Lebenszyklus
- Modul XIV — interner Katalog & Marketplace — Zertifizierung im Produkt (Connector-Einträge + signierte Zulassung)
- API-Stabilität — der SDK-Stabilitätsvertrag
- Ein Release verifizieren — dieselbe Lieferketten-Disziplin für die eigenen Artefakte des Produkts