fix(deps): update module github.com/go-webauthn/webauthn to v0.18.0 - #2988
Conversation
ℹ️ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
renovate
Bot
changed the title
renovate
Bot
changed the title
d5a2587 to
39bdc10
Compare
renovate
Bot
changed the title
renovate
Bot
changed the title
39bdc10 to
2b34b4c
Compare
renovate
Bot
changed the title
renovate
Bot
changed the title
2b34b4c to
209432a
Compare
pikachuren
left a comment
pikachuren
left a comment
There was a problem hiding this comment.
🙏 感谢 @renovate 提交！
🤖 AI 自动审核声明：本评审报告由 AI 自动生成，当前使用 Claude Opus 5 模型进行分析。
🎯 结论
建议合并（Approve），但请维护者在合并前等待 CI 转绿并留意一处存量数据兼容性说明。
这是本批次中跨度最大、也最值得关注的一次依赖升级（跨 5 个 minor 版本）。经核查，升级方向是正面的：它同时带来了安全修复和停维护依赖的替换。存量 passkey 凭证的兼容性问题上游已妥善处理，本项目的读取路径恰好能命中该迁移逻辑。
📖 概要
将 github.com/go-webauthn/webauthn 从 v0.13.4 升级到 v0.18.0，并连带升级其依赖链：go-webauthn/x v0.1.23→v0.3.0、fxamacker/cbor/v2 v2.9.0→v2.9.3、google/go-tpm v0.9.5→v0.9.8，同时新增 go-viper/mapstructure/v2、tinylib/msgp、philhofer/fwd 三个间接依赖。
webauthn 是本项目 Passkey 登录功能的核心库，涉及 internal/authn/authn.go、server/handles/webauthn.go、internal/model/user.go、internal/db/user.go 等鉴权关键路径，因此本次评审对兼容性做了较为细致的核查。
🧭 整体方案
Renovate 自动升级，仅改动 go.mod 与 go.sum，未同步调整业务代码。这里的隐含前提是「上游未引入影响本项目调用点的破坏性变更」——下文对这一前提做了逐项验证。
📊 变更统计
- 文件：2 个（
go.mod、go.sum） - 行数：+21 / -4
- 涉及模块：1 个直接依赖升级 + 5 个间接依赖变动（3 新增、3 升级、1 替换）
| 维度 | 评分 | 说明 |
|---|---|---|
| 功能 | ⭐⭐⭐⭐⭐ | 含 CBOR 解码 panic 修复，鉴权路径安全性提升 |
| 最小改动 | ⭐⭐⭐⭐⭐ | 仅依赖清单，无业务代码噪音 |
| 前向兼容 | ⭐⭐⭐⭐ | 本项目调用点均兼容；存量凭证依赖上游迁移逻辑，已验证可命中 |
| 方案设计 | ⭐⭐⭐⭐ | 方向正确，唯跨度较大，建议合并前等 CI |
🚨 关键问题
P0 阻塞问题
无。
P1 建议修复
1）合并前请等待 CI 转绿
评审时该 PR 的 CI 仍处于 pending 状态（同批次其他三个依赖 PR 均已 pass）。考虑到本次跨越 5 个 minor 版本，编译验证的意义比补丁级升级大得多。请问是否可以等全平台构建通过后再合并呢？
P2 可选优化
2）（非本 PR 引入）凭证反序列化的错误吞没
在核查兼容性时顺带注意到 internal/model/user.go 中一处既有实现：
func (u *User) WebAuthnCredentials() []webauthn.Credential {
var res []webauthn.Credential
err := json.Unmarshal([]byte(u.Authn), &res)
if err != nil {
fmt.Println(err)
}
return res
}这里用 fmt.Println 打印错误后仍返回空切片，一旦解析失败，表现是「用户的 passkey 静默消失」而非明确报错，排查起来会比较困难。这不是本 PR 引入的问题，也不影响本次合并，只是恰好在这次依赖升级的语境下显得更值得关注（依赖升级正是最可能触发反序列化异常的场景）。请问是否考虑后续单独提一个小 PR，改用 utils.Log.Errorf 并向上返回错误呢？例如：
func (u *User) WebAuthnCredentials() ([]webauthn.Credential, error) {
var res []webauthn.Credential
if err := json.Unmarshal([]byte(u.Authn), &res); err != nil {
return nil, errors.WithMessage(err, "failed to parse webauthn credentials")
}
return res, nil
}🔐 依赖安全审查
结论：未发现供应链投毒迹象，且本次升级实为安全性净提升。
1. 新增间接依赖的来源核查
三个新增依赖并非凭空出现，全部可追溯到上游 go.mod 的正常演进：
| 新增依赖 | 来源 | 判定 |
|---|---|---|
go-viper/mapstructure/v2 v2.5.0 |
上游用它替换了已归档的 mitchellh/mapstructure v1.5.0 |
✅ 正向变化 |
tinylib/msgp v1.6.4 |
上游新增 msgpack 序列化支持所引入 | ✅ 功能性引入 |
philhofer/fwd v1.2.0 |
tinylib/msgp 的自身依赖（缓冲 IO） |
✅ 传递依赖 |
其中 mitchellh/mapstructure 已停止维护，迁移到社区接管的 go-viper/mapstructure/v2 是生态内的标准做法，对本项目而言是减少了一个无人维护的依赖。
上游 go.mod 的对应 diff 佐证了这一点：
- github.com/mitchellh/mapstructure v1.5.0
+ github.com/go-viper/mapstructure/v2 v2.5.0
+ github.com/tinylib/msgp v1.6.42. 安全修复确认
fxamacker/cbor/v2 v2.9.0→v2.9.3 包含实质性安全加固，这一点尤其值得强调：
- v2.9.3：修复了从 CBOR byte string / map / array 解码到
time.Time时的潜在 panic； - v2.9.2：加固流式编码器，对不定长 CBOR 数据增加严格校验；
- v2.9.1：
keyasint相关缺陷修复与防御性检查。
这条链路的重要性在于：CBOR 正是 WebAuthn 用来解析来自客户端的 attestation 数据的格式，属于典型的「解析不可信输入」场景。一个可被触发的解码 panic 在这里等价于远程 DoS。因此本次升级不只是版本保鲜，而是修复了鉴权入口上的一个健壮性风险。
3. 恶意模式扫描
对 v0.13.4...v0.18.0 的上游 diff 新增行扫描了 exec.Command、os/exec、http.Post(、http.Get(、net.Dial、InsecureSkipVerify、.onion、unsafe.Pointer 等模式。命中项全部集中在测试文件中的 base64 编解码，例如：
Nonce: base64.StdEncoding.EncodeToString(nonceHash[:]),
header: map[string]any{stmtX5C: []any{base64.StdEncoding.EncodeToString(forgedDER)}},这些是构造伪造证书 / 错误 nonce 的负向测试用例，属于安全测试覆盖增强的正面信号。生产代码路径中未发现命令执行、未发现非预期外连、未发现 TLS 校验降级。
4. 模块归属
go-webauthn/webauthn 与 go-webauthn/x 均仍在 go-webauthn 组织下，无仓库迁移、无 fork 替换、无域名变更。
5. Go 版本要求核对
上游将最低 Go 版本提升了：
-go 1.23.0
-toolchain go1.24.5
+go 1.25.0
+toolchain go1.27.0已核对本项目 go.mod 为 go 1.25.0 / toolchain go1.27.0，CI（.github/workflows/build.yml）使用 go-version: "1.27.0"，完全满足要求，不会因此构建失败。
6. ⭐ 存量 Passkey 凭证兼容性（本次核查的重点）
本项目通过 model.User.Authn（gorm:"type:text"）以 JSON 形式持久化 []webauthn.Credential。跨 5 个 minor 版本升级时，最大的风险是结构体变更导致数据库中已存的 passkey 凭证解析失败，用户无法登录。因此对 Credential 结构体做了逐字段比对：
新版本存在一处语义变更——旧版本的 AttestationType 字段实际错误地存储了 attestation format，新版本纠正了语义并拆出独立的 AttestationFormat 字段：
// v0.18.0
AttestationType string `json:"attestationType,omitempty" msg:"atttype,omitempty"`
AttestationFormat string `json:"attestationFormat,omitempty" msg:"attfmt,omitempty"`好消息是上游已经提供了自动迁移：
func (c *Credential) UnmarshalJSON(data []byte) error {
type credentialAlias Credential
var tmp credentialAlias
if err := json.Unmarshal(data, &tmp); err != nil {
return err
}
*c = Credential(tmp)
if c.AttestationFormat == "" && protocol.IsAttestationFormatString(c.AttestationType) {
c.AttestationFormat = c.AttestationType
c.AttestationType = ""
}
return nil
}而本项目的读取路径是：
err := json.Unmarshal([]byte(u.Authn), &res) // res 为 []webauthn.Credentialjson.Unmarshal 会为切片元素调用自定义的 (*Credential).UnmarshalJSON，因此上述迁移逻辑会被自动命中。结论是：存量用户的 passkey 不会失效，无需编写数据迁移脚本。
此外新增的 Extensions、CredProtect、HMACSecret、PRFEnabled 等字段均带 omitempty/omitzero，旧数据中缺失这些字段时会安全地取零值。
7. API 兼容性
核对了本项目实际调用的 webauthn API：
webauthn.New(&webauthn.Config{...})
authnInstance.BeginLogin(user) / FinishLogin(user, sessionData, c.Request)
authnInstance.BeginDiscoverableLogin() / FinishDiscoverableLogin(...)
authnInstance.BeginRegistration(...) / FinishRegistration(...)
webauthn.WithResidentKeyRequirement(protocol.ResidentKeyRequirementRequired)
protocol.CredentialAssertion / webauthn.SessionData这些都是上游长期稳定的核心 API，跨版本签名未变。最终仍以 CI 编译结果为准（见 P1）。
📂 逐文件分析
go.mod
改动意图：升级 webauthn 主库及其依赖链。
代码逻辑：
- github.com/go-webauthn/webauthn v0.13.4
+ github.com/go-webauthn/webauthn v0.18.0
...
- github.com/fxamacker/cbor/v2 v2.9.0 // indirect
+ github.com/fxamacker/cbor/v2 v2.9.3 // indirect
- github.com/go-webauthn/x v0.1.23 // indirect
+ github.com/go-webauthn/x v0.3.0 // indirect
- github.com/google/go-tpm v0.9.5 // indirect
+ github.com/google/go-tpm v0.9.8 // indirect
+ github.com/go-viper/mapstructure/v2 v2.5.0 // indirect
+ github.com/philhofer/fwd v1.2.0 // indirect
+ github.com/tinylib/msgp v1.6.4 // indirect问题分析：直接依赖与间接依赖的分区标注均正确，新增项都放在 // indirect 区块，符合 go mod tidy 的输出规范。
详细建议：无需改动。
go.sum
改动意图：登记新版本模块哈希。
代码逻辑：为上述 6 个模块新增 h1: 与 /go.mod h1: 条目。
问题分析：无。哈希条目完整成对，未出现只有 /go.mod 而缺少模块内容哈希的异常情况。
详细建议：无需改动。
✅ 待处理清单
- （P1）等待 CI 全平台构建转绿后再合并（评审时仍为 pending）
- （P2，可后续单独处理）
WebAuthnCredentials()的错误吞没改为向上返回 - 上游 diff 供应链核查
- 新增间接依赖来源溯源
- 恶意模式扫描
- Go 最低版本要求核对
- 存量 passkey 凭证反序列化兼容性验证
- 本项目 webauthn API 调用点兼容性核对
🎯 结论：建议合并（等 CI 转绿后）。本次升级不仅是版本保鲜，还修复了鉴权入口 CBOR 解码的 panic 风险，并替换掉了已停维护的 mitchellh/mapstructure，是一次质量不错的依赖治理。存量 passkey 的兼容性也已确认无虞。感谢维护！
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
pikachuren
left a comment
pikachuren
left a comment
There was a problem hiding this comment.
经 AI 评审与上游供应链核查确认无异常，CI 全绿，批准合并。详见此前评审报告。
2 participants
This PR contains the following updates:
v0.13.4→v0.18.0Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
go-webauthn/webauthn (github.com/go-webauthn/webauthn)
v0.18.0Compare Source
This release is a fairly major milestone in the development of this library. It has quite a few breaking changes but has
added support for most if not all of the extension requirements natively, and adds formal support for Post-Quantum
Cryptography with support for ML-DSA-44, ML-DSA-65, and ML-DSA-87 when used with go 1.27.
Details on the migration requirements for this version can be found int MIGRATION.md as they are substantial between
ths version and prior versions.
Bug Fixes
Features
BREAKING CHANGES
rejected, so a Config carrying one now fails validation.
longer substitutes SHA-256 for an unregistered algorithm. Callers must
handle the second value.
other than -8 or -19 no longer parses, failing the assertion rather than
verifying with
Ed25519.RegistrationOptionandLoginOptionnow return an error, so any option implemented outside this module must be adjusted, andWithExtensionsandWithAssertionExtensionsaccept extension options in place of a map.protocol.AuthenticationExtensionsandprotocol.AuthenticationExtensionsClientOutputsare structs rather thanmap[string]any,protocol.Extensionsis removed, andParsedPublicKeyCredential.GetAppIDtakes aprotocol.SessionExtensions.SessionData.Extensionschanges both its type and its encoded representation, so a session persisted by an earlier version cannot be decoded by this one, and a client extension output the Relying Party did not request now fails the ceremony unlessConfig.ExtensionsUnsolicitedOutputPolicysays otherwise.set of acceptable current statuses rather than a set which must all appear
somewhere in the report history.
v0.17.4Compare Source
Dependency Updates
This release just contains updates to dependencies.
v0.17.3Compare Source
Dependency Updates
This release just contains updates to dependencies.
v0.17.2Compare Source
Bug Fixes
v0.17.1Compare Source
Bug Fixes
v0.17.0Compare Source
Bug Fixes
Features
BREAKING CHANGES
A bug with the Credential Record which was
introduced early in the libraries lifecycle has resulted in a
breaking change to the Credential struct. If you are manually
serializing this struct instead of using encoding/json you
will be required to make manual changes; though Integrators
should consider these notes regardless.
protocol.CredentialTypeFIDOU2F has been removed;
replace uses with protocol.AttestationFormatFIDOUniversalSecondFactor
(cast to string where the destination field is a plain string).
The semantics of the AttestationType field on webauthn.Credential
and protocol.CredentialDescriptor have changed. Integrators that
inspect this field to detect a format (typically checking for
"fido-u2f") must switch to the new AttestationFormat field; the
FIDO-U2F AppID and AppIDExclude extension helpers now key on
AttestationFormat, so a descriptor literal constructed with
AttestationType: "fido-u2f" will no longer trigger them.
Stored Credential JSON records are migrated transparently by the
new UnmarshalJSON, but re-marshaled records will carry
attestationFormat rather than a format string in attestationType;
downstream consumers that parsed the legacy shape directly should
be updated.
The Credential.Verify method has been updated and may fail in
previous scenarios where it passed previously. It will also update
the AttestationType value as a side-effect when used.
The Cross-Origin verification semantics have changed
significantly due to the stabilization of the WebAuthn Level 3
specification. It is no longer possible to disable verification, and
Cross-Origin ceremonies must explicitly be allowed in this release.
protocol.TopOriginIgnoreVerificationMode has been removed. Code that
referenced it must switch to one of the other constants as there is
no longer a mode which disables the Top Origin verification such as:
(recommended, and the new coerced default)
RPTopOrigins and RPOrigins
webauthn.Config.validate now rewrites a zero-valued
RPTopOriginVerificationMode to TopOriginExplicitVerificationMode.
Integrators that left the field unset previously got ignore-mode
semantics (any Top Origin accepted); they now get strict matching
against RPTopOrigins and must populate that list, or explicitly
select a different mode; for Cross-Origin flows to succeed.
Cross-Origin ceremonies (those where the authenticator reports
crossOrigin = true in the ClientData) are rejected by default.
Integrators that rely on iframe-embedded or other Cross-Origin WebAuthn
flows must set webauthn.Config.RPAllowCrossOrigin = true. The library
continues to enforce Top Origin verification on accepted Cross-Origin
ceremonies per the configured mode.
protocol.CollectedClientData.Verify no longer accepts
TopOriginIgnoreVerificationMode; callers that pass an unknown mode
receive ErrNotImplemented with detail "unknown Top Origin
verification mode".
v0.16.5Compare Source
Bug Fixes
Features
BREAKING CHANGES
A bug with the Credential Record which was
introduced early in the libraries lifecycle has resulted in a
breaking change to the Credential struct. If you are manually
serializing this struct instead of using encoding/json you
will be required to make manual changes; though Integrators
should consider these notes regardless.
protocol.CredentialTypeFIDOU2F has been removed;
replace uses with protocol.AttestationFormatFIDOUniversalSecondFactor
(cast to string where the destination field is a plain string).
The semantics of the AttestationType field on webauthn.Credential
and protocol.CredentialDescriptor have changed. Integrators that
inspect this field to detect a format (typically checking for
"fido-u2f") must switch to the new AttestationFormat field; the
FIDO-U2F AppID and AppIDExclude extension helpers now key on
AttestationFormat, so a descriptor literal constructed with
AttestationType: "fido-u2f" will no longer trigger them.
Stored Credential JSON records are migrated transparently by the
new UnmarshalJSON, but re-marshaled records will carry
attestationFormat rather than a format string in attestationType;
downstream consumers that parsed the legacy shape directly should
be updated.
The Credential.Verify method has been updated and may fail in
previous scenarios where it passed previously. It will also update
the AttestationType value as a side-effect when used.
The Cross-Origin verification semantics have changed
significantly due to the stabilization of the WebAuthn Level 3
specification. It is no longer possible to disable verification, and
Cross-Origin ceremonies must explicitly be allowed in this release.
protocol.TopOriginIgnoreVerificationMode has been removed. Code that
referenced it must switch to one of the other constants as there is
no longer a mode which disables the Top Origin verification such as:
(recommended, and the new coerced default)
RPTopOrigins and RPOrigins
webauthn.Config.validate now rewrites a zero-valued
RPTopOriginVerificationMode to TopOriginExplicitVerificationMode.
Integrators that left the field unset previously got ignore-mode
semantics (any Top Origin accepted); they now get strict matching
against RPTopOrigins and must populate that list, or explicitly
select a different mode; for Cross-Origin flows to succeed.
Cross-Origin ceremonies (those where the authenticator reports
crossOrigin = true in the ClientData) are rejected by default.
Integrators that rely on iframe-embedded or other Cross-Origin WebAuthn
flows must set webauthn.Config.RPAllowCrossOrigin = true. The library
continues to enforce Top Origin verification on accepted Cross-Origin
ceremonies per the configured mode.
protocol.CollectedClientData.Verify no longer accepts
TopOriginIgnoreVerificationMode; callers that pass an unknown mode
receive ErrNotImplemented with detail "unknown Top Origin
verification mode".
0.16.5 (2026-04-19)
Bug Fixes
0.16.4 (2026-04-09)
0.16.3 (2026-04-05)
Bug Fixes
Features
0.16.2 (2026-03-30)
Bug Fixes
Features
0.16.1 (2026-03-12)
Bug Fixes
v0.16.4Compare Source
Bug Fixes
Features
BREAKING CHANGES
A bug with the Credential Record which was
introduced early in the libraries lifecycle has resulted in a
breaking change to the Credential struct. If you are manually
serializing this struct instead of using encoding/json you
will be required to make manual changes; though Integrators
should consider these notes regardless.
protocol.CredentialTypeFIDOU2F has been removed;
replace uses with protocol.AttestationFormatFIDOUniversalSecondFactor
(cast to string where the destination field is a plain string).
The semantics of the AttestationType field on webauthn.Credential
and protocol.CredentialDescriptor have changed. Integrators that
inspect this field to detect a format (typically checking for
"fido-u2f") must switch to the new AttestationFormat field; the
FIDO-U2F AppID and AppIDExclude extension helpers now key on
AttestationFormat, so a descriptor literal constructed with
AttestationType: "fido-u2f" will no longer trigger them.
Stored Credential JSON records are migrated transparently by the
new UnmarshalJSON, but re-marshaled records will carry
attestationFormat rather than a format string in attestationType;
downstream consumers that parsed the legacy shape directly should
be updated.
The Credential.Verify method has been updated and may fail in
previous scenarios where it passed previously. It will also update
the AttestationType value as a side-effect when used.
The Cross-Origin verification semantics have changed
significantly due to the stabilization of the WebAuthn Level 3
specification. It is no longer possible to disable verification, and
Cross-Origin ceremonies must explicitly be allowed in this release.
protocol.TopOriginIgnoreVerificationMode has been removed. Code that
referenced it must switch to one of the other constants as there is
no longer a mode which disables the Top Origin verification such as:
(recommended, and the new coerced default)
RPTopOrigins and RPOrigins
webauthn.Config.validate now rewrites a zero-valued
RPTopOriginVerificationMode to TopOriginExplicitVerificationMode.
Integrators that left the field unset previously got ignore-mode
semantics (any Top Origin accepted); they now get strict matching
against RPTopOrigins and must populate that list, or explicitly
select a different mode; for Cross-Origin flows to succeed.
Cross-Origin ceremonies (those where the authenticator reports
crossOrigin = true in the ClientData) are rejected by default.
Integrators that rely on iframe-embedded or other Cross-Origin WebAuthn
flows must set webauthn.Config.RPAllowCrossOrigin = true. The library
continues to enforce Top Origin verification on accepted Cross-Origin
ceremonies per the configured mode.
protocol.CollectedClientData.Verify no longer accepts
TopOriginIgnoreVerificationMode; callers that pass an unknown mode
receive ErrNotImplemented with detail "unknown Top Origin
verification mode".
0.16.5 (2026-04-19)
Bug Fixes
0.16.4 (2026-04-09)
0.16.3 (2026-04-05)
Bug Fixes
Features
0.16.2 (2026-03-30)
Bug Fixes
Features
0.16.1 (2026-03-12)
Bug Fixes
v0.16.3Compare Source
Bug Fixes
Features
BREAKING CHANGES
A bug with the Credential Record which was
introduced early in the libraries lifecycle has resulted in a
breaking change to the Credential struct. If you are manually
serializing this struct instead of using encoding/json you
will be required to make manual changes; though Integrators
should consider these notes regardless.
protocol.CredentialTypeFIDOU2F has been removed;
replace uses with protocol.AttestationFormatFIDOUniversalSecondFactor
(cast to string where the destination field is a plain string).
The semantics of the AttestationType field on webauthn.Credential
and protocol.CredentialDescriptor have changed. Integrators that
inspect this field to detect a format (typically checking for
"fido-u2f") must switch to the new AttestationFormat field; the
FIDO-U2F AppID and AppIDExclude extension helpers now key on
AttestationFormat, so a descriptor literal constructed with
AttestationType: "fido-u2f" will no longer trigger them.
Stored Credential JSON records are migrated transparently by the
new UnmarshalJSON, but re-marshaled records will carry
attestationFormat rather than a format string in attestationType;
downstream consumers that parsed the legacy shape directly should
be updated.
The Credential.Verify method has been updated and may fail in
previous scenarios where it passed previously. It will also update
the AttestationType value as a side-effect when used.
The Cross-Origin verification semantics have changed
significantly due to the stabilization of the WebAuthn Level 3
specification. It is no longer possible to disable verification, and
Cross-Origin ceremonies must explicitly be allowed in this release.
protocol.TopOriginIgnoreVerificationMode has been removed. Code that
referenced it must switch to one of the other constants as there is
no longer a mode which disables the Top Origin verification such as:
(recommended, and the new coerced default)
RPTopOrigins and RPOrigins
webauthn.Config.validate now rewrites a zero-valued
RPTopOriginVerificationMode to TopOriginExplicitVerificationMode.
Integrators that left the field unset previously got ignore-mode
semantics (any Top Origin accepted); they now get strict matching
against RPTopOrigins and must populate that list, or explicitly
select a different mode; for Cross-Origin flows to succeed.
Cross-Origin ceremonies (those where the authenticator reports
crossOrigin = true in the ClientData) are rejected by default.
Integrators that rely on iframe-embedded or other Cross-Origin WebAuthn
flows must set webauthn.Config.RPAllowCrossOrigin = true. The library
continues to enforce Top Origin verification on accepted Cross-Origin
ceremonies per the configured mode.
protocol.CollectedClientData.Verify no longer accepts
TopOriginIgnoreVerificationMode; callers that pass an unknown mode
receive ErrNotImplemented with detail "unknown Top Origin
verification mode".
0.16.5 (2026-04-19)
Bug Fixes
0.16.4 (2026-04-09)
0.16.3 (2026-04-05)
Bug Fixes
Features
0.16.2 (2026-03-30)
Bug Fixes
Features
0.16.1 (2026-03-12)
Bug Fixes
v0.16.2Compare Source
Bug Fixes
Features
BREAKING CHANGES
A bug with the Credential Record which was
introduced early in the libraries lifecycle has resulted in a
breaking change to the Credential struct. If you are manually
serializing this struct instead of using encoding/json you
will be required to make manual changes; though Integrators
should consider these notes regardless.
protocol.CredentialTypeFIDOU2F has been removed;
replace uses with protocol.AttestationFormatFIDOUniversalSecondFactor
(cast to string where the destination field is a plain string).
The semantics of the AttestationType field on webauthn.Credential
and protocol.CredentialDescriptor have changed. Integrators that
inspect this field to detect a format (typically checking for
"fido-u2f") must switch to the new AttestationFormat field; the
FIDO-U2F AppID and AppIDExclude extension helpers now key on
AttestationFormat, so a descriptor literal constructed with
AttestationType: "fido-u2f" will no longer trigger them.
Stored Credential JSON records are migrated transparently by the
new UnmarshalJSON, but re-marshaled records will carry
attestationFormat rather than a format string in attestationType;
downstream consumers that parsed the legacy shape directly should
be updated.
The Credential.Verify method has been updated and may fail in
previous scenarios where it passed previously. It will also update
the AttestationType value as a side-effect when used.
The Cross-Origin verification semantics have changed
significantly due to the stabilization of the WebAuthn Level 3
specification. It is no longer possible to disable verification, and
Cross-Origin ceremonies must explicitly be allowed in this release.
protocol.TopOriginIgnoreVerificationMode has been removed. Code that
referenced it must switch to one of the other constants as there is
no longer a mode which disables the Top Origin verification such as:
(recommended, and the new coerced default)
RPTopOrigins and RPOrigins
webauthn.Config.validate now rewrites a zero-valued
RPTopOriginVerificationMode to TopOriginExplicitVerificationMode.
Integrators that left the field unset previously got ignore-mode
semantics (any Top Origin accepted); they now get strict matching
against RPTopOrigins and must populate that list, or explicitly
select a different mode; for Cross-Origin flows to succeed.
Cross-Origin ceremonies (those where the authenticator reports
crossOrigin = true in the ClientData) are rejected by default.
Integrators that rely on iframe-embedded or other Cross-Origin WebAuthn
flows must set webauthn.Config.RPAllowCrossOrigin = true. The library
continues to enforce Top Origin verification on accepted Cross-Origin
ceremonies per the configured mode.
protocol.CollectedClientData.Verify no longer accepts
TopOriginIgnoreVerificationMode; callers that pass an unknown mode
receive ErrNotImplemented with detail "unknown Top Origin
verification mode".
0.16.5 (2026-04-19)
Bug Fixes
0.16.4 (2026-04-09)
0.16.3 (2026-04-05)
Bug Fixes
Features
0.16.2 (2026-03-30)
Bug Fixes
Features
0.16.1 (2026-03-12)
Bug Fixes
v0.16.1Compare Source
Bug Fixes
Features
BREAKING CHANGES
A bug with the Credential Record which was
introduced early in the libraries lifecycle has resulted in a
breaking change to the Credential struct. If you are manually
serializing this struct instead of using encoding/json you
will be required to make manual changes; though Integrators
should consider these notes regardless.
protocol.CredentialTypeFIDOU2F has been removed;
replace uses with protocol.AttestationFormatFIDOUniversalSecondFactor
(cast to string where the destination field is a plain string).
The semantics of the AttestationType field on webauthn.Credential
and protocol.CredentialDescriptor have changed. Integrators that
inspect this field to detect a format (typically checking for
"fido-u2f") must switch to the new AttestationFormat field; the
FIDO-U2F AppID and AppIDExclude extension helpers now key on
AttestationFormat, so a descriptor literal constructed with
AttestationType: "fido-u2f" will no longer trigger them.
Stored Credential JSON records are migrated transparently by the
new UnmarshalJSON, but re-marshaled records will carry
attestationFormat rather than a format string in attestationType;
downstream consumers that parsed the legacy shape directly should
be updated.
The Credential.Verify method has been updated and may fail in
previous scenarios where it passed previously. It will also update
the AttestationType value as a side-effect when used.
The Cross-Origin verification semantics have changed
significantly due to the stabilization of the WebAuthn Level 3
specification. It is no longer possible to disable verification, and
Cross-Origin ceremonies must explicitly be allowed in this release.
protocol.TopOriginIgnoreVerificationMode has been removed. Code that
referenced it must switch to one of the other constants as there is
no longer a mode which disables the Top Origin verification such as:
(recommended, and the new coerced default)
RPTopOrigins and RPOrigins
webauthn.Config.validate now rewrites a zero-valued
RPTopOriginVerificationMode to TopOriginExplicitVerificationMode.
Integrators that left the field unset previously got ignore-mode
semantics (any Top Origin accepted); they now get strict matching
against RPTopOrigins and must populate that list, or explicitly
select a different mode; for Cross-Origin flows to succeed.
Cross-Origin ceremonies (those where the authenticator reports
crossOrigin = true in the ClientData) are rejected by default.
Integrators that rely on iframe-embedded or other Cross-Origin WebAuthn
flows must set webauthn.Config.RPAllowCrossOrigin = true. The library
continues to enforce Top Origin verification on accepted Cross-Origin
ceremonies per the configured mode.
protocol.CollectedClientData.Verify no longer accepts
TopOriginIgnoreVerificationMode; callers that pass an unknown mode
receive ErrNotImplemented with detail "unknown Top Origin
verification mode".
0.16.5 (2026-04-19)
Bug Fixes
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.