Struct PluginCatalog

Source

pub struct PluginCatalog { /* private fields */ }

Expand description

Parsed plugin selections kept separate from the Rust linking entries. 与 Rust 链接入口分离的插件选择记录。

Implementations§

Source §

impl PluginCatalog

Source

pub fn parse(lock: &str) -> Result<PluginCatalog, PluginLockError>

Parse a plugin lock, refusing unknown schemas and malformed or duplicate lines. 解析插件锁；未知 schema、格式错误或重复的记录一律拒绝。

Source

pub fn records(&self) -> &[PluginRecord]

The parsed records, in lock order. 解析出的记录，按锁文件中的顺序排列。

Source

pub fn contains(&self, candidate: &PluginRecord) -> bool

Whether an identical record is already in the catalog. 目录中是否已存在一条完全相同的记录。

Source

pub fn contains_manifest(&self, manifest: PluginManifest) -> bool

Check an embedded manifest against the lock record for its source. 将嵌入注册面的 manifest 与对应来源锁文件中的记录比对。

The seven identity fields must match exactly. The three provenance fields the parser accepts as an extension — signature, key fingerprint, and revocation-list snapshot — are expectations: a record that carries one pins it, and a record written without it (the seven-field form, which is what a host’s own plugin UI writes) leaves it to the signature check. Comparing them for equality instead made the seven-field official record unsatisfiable in the only direction that matters: it can equal a manifest with no signature, and an official manifest with no signature is refused by every trust policy that has a trust root, so an official plugin could not be admitted end to end through a lock the host itself wrote. 七个身份字段必须完全一致。解析器作为扩展接受的三个来源字段——签名、密钥指纹与撤销列表快照——是期望：记录携带某个值就把它钉住，记录没写（七字段形式，宿主自己的插件界面写下的就是这种）就交给签名校验。此前用相等比较它们，会让七字段的官方记录在唯一要紧的方向上无法满足：它只能等于一个没有签名的 manifest，而没有签名的官方 manifest 会被任何配置了信任根的策略拒绝——于是官方插件根本无法经宿主自己写下的锁端到端准入。