go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
43.85k stars 5.38k forks source link

Can't publish private npm package #31581

Open UchihaYuki opened 1 month ago

UchihaYuki commented 1 month ago

Description

I published with npm publish --access=restricted. But it's still public. Everybody can download it, even if they are not logged in.

Gitea Version

Gitea version 1.22.0 built with GNU Make 4.4.1, go1.22.3 : bindata, timetzdata, sqlite, sqlite_unlock_notify

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

git version 2.31.1.windows.1

Operating System

Windows 10

How are you running Gitea?

docker

Database

MSSQL

UchihaYuki commented 1 month ago

The package I published:

npm notice Publishing to https://demo.gitea.com/api/packages/uchihayuki/npm/ with tag latest and restricted access       
+ @uchihayuki/test-gitea@0.1.0
KN4CK3R commented 1 month ago

Package permissions are inherited from the owner visibility and can't be set with npm publish --access=restricted.

UchihaYuki commented 1 month ago

Can this be a feature request? It's pretty useful, people always want both public and private npm packages.

KN4CK3R commented 1 month ago

Sure, but I don't think this will happen because it requires a new permission system.

mlhynfield commented 1 month ago

I'd just like to jump in and second this as a nice feature, not just for npm packages but for packages in general. For example, I just ran into this issue myself with some container images I pushed to the container registry, where, as a relatively new user, I had expected to find controls to modify the container image visibility but instead found that I needed to change the owning organization's visibility. I think it would be really great to have a bit more control over package visibility at some point so you don't have to have a separate user/organization for public and private packages.