Draft: Protected npm package in package registry [POC]
requested to merge gitlab-community/gitlab:413641-feature-protected-packages-add-project-settings into master
What does this MR do and why?
This MR will not be merged. The intention is to discuss and document design decision and implemenation details.
This MR wants to provide a POC implementation for the Identify packages as protected to prevent accid... (&5574).
What do we want to achieve with this POC?
- Better understanding of implementation approach and complexity
- Better estimate of implementation plan
- Discuss the data model
What do we not want to achieve with this POC?
- Discuss necessary ux / ui changes in regards to the project settings
- Investigate the implemenation of dependency types other than
npm
Proposal for data model
- We want to maintain the current permissions for interacting with the package registry => therefore, the idea of
Packages::PackageProtectionPolicy
is to define additional permissions => hence, we do not need to migrate the existing data model - When a pacakge-specific
Packages::PackageProtectionPolicy
exists then this policy is enforced, - When no package-specific
Packages::PackageProtectionPolicy
exists then the default package permissions are applied => this ensures backward compatibility - The field
publish_protected_up_to_access_level
represent the maximum access level required to allow publishing of a package, e.g. maintainer, owner,Gitlab::ACCESS::NO_ACCESS
, etc. - The field
matching_package_name
has a uniqueness contraint scoped toproject_id
andnamespace_id
=> could be extended to the fieldsmatching_package_type
andmatching_package_version
as well
classDiagram
class `Packages::PackageProtectionPolicy`{
id bigint,
matching_package_name string
matching_package_type string
matching_package_version string
publish_protected_up_to_access_level Gitlab::Access
unpublish_protected_up_to_access_level Gitlab::Access
project_id bigint
namespace_id bigint
}
`Packages::PackageProtectionPolicy` --> `Project`
`Project` --> `Group (Namespace)`
Here is an example of the
project_id |
namespace_id |
matching_package_name . |
publish_protected_up_to_access_level |
Meaning |
---|---|---|---|---|
7 | 33 | "@flightjs/test-npm-package" | 0 (= Gitlab::Access::NO_ACCESS ) |
New package version for @flightjs/test-npm-package cannot be published because this PackageProtectionPolicy forbids this. |
7 | 33 | "@flightjs/test-npm-package-2 " | 40 (= Gitlab::Access::MAINTAINER ) |
New package version for @flightjs/test-npm-package cannot be published by a MAINTAINER or lower. OWNER would be able to publish a new package version. |
Open Questions
- Should we allow wildcard for
matching_package_name
?
How to set up and validate locally
rails db:migrate
rails r 'Packages::PackageProtectionPolicy.create(project: Project.find(7), namespace: Project.find(7).namespace, matching_package_name: "@flightjs/test-npm-package", publish_protected_up_to_access_level: Gitlab::Access::NO_ACCESS, unpublish_protected_up_to_access_level: Gitlab::Access::NO_ACCESS)'
- Create a dummy project for npm package for testing publishing, i.e.
npm init
- Publish npm test package, i.e.
NPM_TOKEN=ypCa3Dzb23o5nvsixwPA npm publish
=> will be blocked byPackageProtectionPolicy
TODO
-
Document data proposal in &5574 -
Document implementation plan in &5574 -
Add matching_package_type
toPackageProtectionPolicy
MR acceptance checklist
This MR will not be merged. The intention is to discuss and document design decision and implemenation details.
Related to Identify packages as protected to prevent accid... (&5574) and.
Edited by Gerardo Navarro