Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Harden Azure Key Vault trusted endpoint matching

未关闭
  • 哪里不对？
#4,802 1 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 2 天内回复

@apoorvdeshmukh 已经在做这个了。

开始于 2026年10月13日。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
azure, csharp
领域
backend, security

调研方向

Start by locating SqlColumnEncryptionAzureKeyVaultProvider and reading its trusted-endpoint validation and constructor behavior, then inspect the related tests. Add coverage for the listed DNS, scheme, port, normalization, and input-mutation cases; done means endpoint validation follows the requested structured rules while preserving the described compatibility path.

由索引模型根据 Issue 内容生成。

描述

Area\AKV Provider
Is your feature request related to a problem? Please describe.

SqlColumnEncryptionAzureKeyVaultProvider validates an Azure Key Vault key URI by checking whether Uri.Host ends with one of its trusted endpoint strings. Raw suffix matching does not require a DNS-label boundary, so a hostname can match a trusted suffix without being that domain or one of its subdomains.

The trusted-endpoint representation also does not express whether an entry is an exact host, a DNS suffix, or a complete origin. This makes it difficult to apply clear scheme and port rules to application-supplied endpoints while preserving compatibility with custom Azure environments and development endpoints.

Describe the solution you'd like

Harden and clarify trusted endpoint validation:

  • Match built-in domain suffixes only when the host is exactly the suffix or ends with "." + suffix, using ordinal case-insensitive comparison.
  • Normalize DNS hosts consistently, including IDN and terminal-dot handling.
  • Require HTTPS for built-in Azure Key Vault and Managed HSM endpoints.
  • Validate and normalize application-supplied trusted endpoints when the provider is constructed.
  • Provide structured semantics for custom endpoints, distinguishing exact origins from entries that intentionally include DNS subdomains.
  • Defensively copy trusted endpoint collections so validation policy cannot be changed by mutating the constructor input.
  • Preserve reasonable compatibility for existing custom endpoints, with diagnostics and an explicit migration path for ambiguous legacy entries.

Add tests covering:

  • Valid exact hosts and subdomains.
  • Lookalike suffixes that do not share a DNS-label boundary.
  • Hosts that append another DNS suffix after a trusted name.
  • Mixed-case, IDN, and terminal-dot hostnames.
  • HTTP, HTTPS, default ports, and explicit custom ports.
  • Mutation of the input trusted-endpoint array after construction.
Describe alternatives you've considered
  • Keep raw EndsWith matching. This retains ambiguous behavior and does not accurately model DNS domain membership.
  • Require exact host matching for every entry. This would not work for the built-in Azure Key Vault domains, where each vault has its own subdomain.
  • Immediately reject every legacy custom endpoint format. This would provide simpler rules but could unnecessarily disrupt applications using private clouds, proxies, or development services. A compatibility-conscious migration to structured endpoint rules is preferable.
Additional context

The current built-in list covers Azure Key Vault and Managed HSM domains in public and sovereign clouds. DNS-label-boundary matching should preserve valid hostnames beneath those domains while making the allowlist behavior precise.

主要语言
C#
星标
996
派生
348
平均合并
5 天 15 小时
30 天内合并 PR
54

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

dotnet/SqlClient 的其他 Issue

查看 dotnet/SqlClient 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。