组织

任何允许创建项目的包存储库（例如非镜像）可以提供组织概念[6]。组织是拥有项目并拥有与其关联的各种用户的实体。

组织可以保留一个或多个命名空间。此类保留既不授予现有项目所有权，也不授予其特殊权限。

命名

命名空间必须是有效的项目名称，并进行内部规范化，例如 foo.bar 将变为 foo-bar。

语义

命名空间授权赋予以下所有权：

1. 与命名空间本身匹配的项目，例如占位符包 microsoft。
2. 以命名空间后跟连字符开头的项目。例如，命名空间 foo 将匹配规范化的项目名称 foo-bar，但不匹配项目名称 foobar。

包名称匹配作用于规范化命名空间。

命名空间是针对每个包存储库的，不得在存储库之间共享。例如，如果 PyPI 有一个由微软公司拥有的命名空间 microsoft，那么来自其他非 PyPI 镜像存储库的以 microsoft- 开头的包不享有同等程度的信任。

授权不得重叠。例如，如果已存在 foo-bar 的授权，则禁止为 foo 授予新授权。重叠的判断方法是，将提议的规范化命名空间与每个现有根授权的规范化命名空间进行比较。每次比较都必须在提议的和现有命名空间的末尾添加一个连字符。当任何现有命名空间以提议的命名空间开头时，即检测到重叠。

上传

如果要上传的包的名称与保留的命名空间匹配，并且以下任一条件为真：

• 该项目尚不存在。
• 该项目不归拥有该命名空间的有效授权的组织所有。

则上传必须以 403 HTTP 状态码失败。

开放命名空间

授权所有者可以选择允许其他人发布带有相关命名空间的新项目。这样做必须允许任何用户为匹配该命名空间的新项目进行上传。

命名空间的所有者可以将其设为开放，并允许其他组织使用该授权。在这种情况下，被授权的组织没有特殊权限，与没有所有权的开放授权等效。

隐藏授权

存储库可以创建不向公众可见的隐藏授权，以防止其命名空间被他人占用。此类授权不得是开放的，并且不应在API中公开。

隐藏授权对于希望强制执行上传限制而无需向公众公开命名空间的存储库非常有用。

存储库元数据

JSON API 版本将从 1.2 增加到 1.3。支持此PEP的存储库必须实现以下API更改。不支持此PEP的存储库不得实现这些更改，以便API消费者能够确定存储库是否支持此PEP。

授权移除

当保留的命名空间变为未声明时，存储库必须在API中将 namespace 键设置为 null。

以前已被声明但现在未被声明的命名空间应有资格被任何组织再次声明。

授予用户保留权

由于包存储库是扁平命名空间，允许任何用户保留命名空间是不可行的，不仅因为存在有限资源的争夺，还因为没有存储库有足够的人力操作员来管理任意数量用户的审查。

工件级命名空间关联

本PEP的早期版本曾提议在发布时将元数据与单个工件关联。此提案被拒绝，因为它可能导致用户困惑，用户可能会根据当前的授权而非发布时间，期望命名空间授权保证在项目级别。

组织范围划分

本PEP的主要动机是减少依赖混淆攻击，而NPM风格的作用域与允许遗留扁平命名空间会增加风险。如果文档指示用户在命名空间 foo 中安装 bar，则用户必须小心安装 @foo/bar 而不是 foo-bar，反之亦然。Python包生态系统有名称规范化规则，以最大限度地提高通信便利性，而这将是一种倒退。

Python的运行时环境也不利于作用域。虽然同一JavaScript包的多个版本可以共存，但Python只允许一个全局命名空间。除非对语言本身进行重大更改，否则这几乎不可能改变。此外，用户已经习惯了包名通常与他们导入的名称相同，取消扁平命名空间将废除这一惯例。

作用域将特别受到随着时间推移必然发生的组织变更的影响。一个组织可能会因为内部重组、收购或任何其他原因而更改其名称。每当发生这种情况时，他们拥有的每个项目实际上都会被重命名，这会给用户带来不必要的混乱，而且经常发生。

最后，对社区的破坏将是巨大的，因为它需要每个包管理器、安全扫描器、IDE等进行更新。以作用域发布的新包将与旧工具不兼容，并会给用户带来困惑，同时维护者也不得不处理这些投诉而感到沮丧。

鼓励专用包存储库

至关重要的是，这给项目带来了维护自身基础设施的负担。对于绝大多数公司来说，这是一个不切实际的期望，对于社区项目来说更是完全无法接受。

这在大多数情况下没有帮助，因为大多数包管理器的默认行为是使用 PyPI，所以尝试执行简单 pip install 的用户已经容易受到恶意包的攻击。

在这个理论化的未来中，每个项目都必须记录如何将其存储库添加到依赖解析中，这对于每个包管理器都会有所不同。很少有包管理器能够从特定存储库下载特定依赖项，并且在常见情况下会要求用户使用冗长的配置。

不支持此功能的将改为通过存储库的有序枚举来查找给定包，从而导致依赖混淆。例如，假设用户需要来自两个自定义存储库 X 和 Y 的两个包。如果每个存储库都包含这两个包，但其中一个在 X 上是恶意的，另一个在 Y 上是恶意的，那么用户将无法在不遇到恶意包的情况下满足其需求。

独家依赖来源断言

这里的想法[5]是设计一种通用方法，让客户端能够进行来源断言，以验证依赖项的某些属性，每个属性都有自定义语法。一些示例：

• 该包由特定的组织或用户名上传，例如 pip install "azure-loganalytics from microsoft"
• 该包由特定域名所有者上传，例如 pip install "google-cloud-compute from cloud.google.com"
• 该包由具有特定电子邮件地址的用户上传，例如 pip install "aws-cdk-lib from contact@amazon.com"
• 匹配命名空间的包由授权方上传（本PEP）

一个根本的缺点是它与多个存储库的协作不佳。例如，假设用户需要 azure-loganalytics 包，并希望确保它来自名为 microsoft 的组织。如果微软在 PyPI 上的组织名称是 microsoft，那么默认使用 PyPI 的包管理器可以接受 azure-loganalytics from microsoft。但是，如果依赖解析使用了多个存储库，那么用户就必须将存储库指定为定义的一部分，这对于断言包所有者名称的专门章节中所述的原因来说是不切实际的。

这种方法的另一个普遍弱点是，用户尝试执行不带特殊语法的简单 pip install（这是最常见的场景）时，已经容易受到恶意包的攻击。为了克服这一点，必须有某种默认的信任机制，在所有情况下，这都会给每个工具强加特定的用户体验或解析器逻辑。

例如，可以更改包管理器，以便在第一次安装包时，用户会收到一个确认提示，显示来源详细信息。这会非常令人困惑和嘈杂，特别是对于新用户，并且对于现有用户来说，这将是一个破坏性的用户体验更改。许多安装方法在此场景下都无法工作，例如在CI中运行或从requirements文件中安装，用户可能会收到数百个提示。

一种使这种方式对用户干扰较小的解决方案是手动维护一份可信赖详细信息（组织/用户名称、域名、电子邮件地址等）的列表。这可以通过提供入口点的包来发现，包管理器可以学习检测这些入口点，并且企业环境可以默认安装。这有一个主要缺点，即无法提供自动保证，这将限制其对更容易受影响的普通用户的有用性。

有两种想法可以提供自动保护，它们可以基于PEP 740证明或利用托管元数据的第三方API的新机制。

首先，每个存储库都可以提供一项服务，根据他们认为适当的任何标准来验证包的所有者。验证后，存储库会将详细信息添加到默认安装的专用包中。

这将需要专门的维护，这对于大多数存储库（即使是当前的 PyPI）来说都是不现实的。目前尚不清楚如何支持没有域名等资源的社区项目。至关重要的是，在存在多个存储库的情况下，此解决方案将给用户带来额外的困惑，因为每个存储库都可能有自己的验证过程、证明标准和包含已验证详细信息的默认包。让每个包管理器都了解每个存储库选择的验证包并在依赖解析之前默认安装它，这将是一项挑战，难以获得社区的认可。

如果选择数字证明作为机制，一个缺点是，在自定义包存储库中实现这将需要大量工作。对于 PyPI 而言，可信发布的先决工作以及PEP 740 自身的实现花费了一名全职工程师一年时间，其时间由企业赞助商支付。其他组织不太可能实施类似的工作，因为更简单的机制使得实现可重现构建成为可能。当一切都在内部管理时，证明的用处也不大。社区项目不太可能承担这项工作，因为它们可能缺乏维护必要基础设施的资源，而且鼓励专用包存储库存在重大缺点。

另一个想法是将来源断言托管在外部，并将更多逻辑推送到客户端。一种可能的实现是指定一个来源API，该API可以托管在指定的相对路径（例如 /provenance）下。然后，每个存储库上的项目可以配置为指向特定域名，此信息将在安装期间传递给客户端。

虽然这种分布式方法对存储库的基础设施负担较小，但它有可能带来安全风险。如果外部来源API受到威胁，可能会导致恶意软件包被安装。如果外部API宕机，则可能导致软件包安装失败，或者软件包管理器可能只会发出警告，在这种情况下，就没有安全优势。

此外，这对没有资源维护此类 API 的社区项目不利。他们可以使用免费托管解决方案，就像许多文档所做的那样，但他们没有从技术上拥有基础设施，如果慷慨的服务受到限制，他们就会受到损害。

最后，尽管这两种理论方法都尚未具有规定性，但它们暗示了工件级别的断言，而这已经是一个被拒绝的想法。

断言包所有者名称

这是关于断言包来自特定的组织或用户名称。它与组织作用域划分的想法非常相似，只是以扁平命名空间为基本假设。

这将需要修改每个受支持存储库的JSON API，可以通过公开额外元数据或作为适当的来源断言来实现。

与组织作用域划分的想法一样，需要一种新的语法，例如 microsoft::azure-loganalytics，其中 microsoft 是组织，azure-loganalytics 是包。尽管与现有的扁平命名空间配合良好，但它保留了对社区造成破坏的关键缺点，因为需要进行大量更改。

一个独特的缺点是名称是存储库的实现细节。在PyPI上，组织的名称与用户名称是分开的，因此存在冲突的可能性。在多个存储库的情况下，用户可能会遇到类似于鼓励专用包存储库被拒绝的想法末尾所描述的依赖混淆情况。

为了缓解这个问题，有人建议将语法扩展，以包含预期的存储库URL，例如 microsoft@pypi.org::azure-loganalytics。这种语法或类似的东西过于冗长，可能导致用户困惑，更糟糕的是，如果它在那些能够维护专用基础设施的人群中获得更多采用，将导致沮丧（社区项目将无法受益）。

扩展语法试图在依赖说明符中标准化解析器行为和配置。这不仅会强制规定工具的用户体验，而且在具有或不具有包存储库概念的语言生态系统的包管理器中也缺乏先例。在这种情况下，解析器配置与依赖定义是分开的。

使用固定前缀

这里的想法是有一个或多个顶级固定前缀用于命名空间保留。

• com-: 为企业组织保留。
• org-: 为社区组织保留。

组织随后将申请以其组织类型为前缀的命名空间。

这将造成永久性的混乱，因为项目启动时，不知道用户群是否足够大以保证命名空间保留。每当发生这种情况时，项目都必须重命名，这将给项目维护者带来高昂的维护负担，并给不得不学习新的引用项目包方式的用户造成困惑。这很可能会阻止项目保留命名空间。

这种方法的另一个问题是项目通常考虑到品牌形象（示例），并且不愿更改其包名称。

期望每个公司和项目都自愿更改其现有和未来的包名称是不现实的。

使用DNS

这里的想法是在API中为项目添加一个名为 domain-authority 的新元数据字段。存储库将支持一个用于通过HTTPS验证域的新端点。然后客户端将支持允许某些域的选项。

这并未解决目标受众的问题，因为他们不检查其包的来源，而更多是关于检查上传的完整性，这已通过PEP 740以更安全的方式得到支持。

大多数项目没有域名，无法从中受益，这不公平地偏袒了有财力获取域名的组织。