feature to block deleting the uploaded package

[woosuk-yang]

Is your feature request related to a problem? Please describe.

The issue is that currently, other users have the ability to delete uploaded packages in my Baget instance. Although the system prevents overwriting the same package version, some users are bypassing this by deleting the existing package version and then re-uploading it. This can lead to potential issues, such as unintended changes or inconsistencies in the package versions available.

Describe the solution you'd like

I would like a feature that blocks users from deleting uploaded packages unless they have specific permissions. This would prevent unauthorized deletion of packages and ensure the integrity of the packages stored in the system. Ideally, only admins or users with special permissions should be able to delete packages.

Describe alternatives you've considered

An alternative solution could be to limit the delete functionality based on API keys, allowing only users with certain API keys to delete packages. Another option could be implementing a feature where package deletion triggers a warning or requires approval from an administrator. Additionally, logging deletions and notifying all users who have access to the package could be considered to review any potential issues.

[Regenhardt]

This is not a feature currently planned, but there is currently a private feed implementation in review that is extensible enough to later enable this kind of customization.

Right now, you can set "PackageDeletionBehavior": "Unlist", preventing anyone from pushing a package that already exists. Or not give them the API key because if they don't understand NuGet, maybe they shouldn't be allowed to push packages.

Also you may talk to your team and make sure everybody is on the same page about the process: Either packages may be arbitrarily deleted and recreated with the same version, which is absolutely not meant to ever happen in NuGet, or your push new packages each time, which is the expected way of working with NuGet packages.
If you don't care about semantic versioning, you could introduce a linear versioning scheme instead, simply using the current timestamp as version. That way, every newly built package will have a new version. Could look like this:

  <Target Name="GenerateTimestampVersion">
    <PropertyGroup>
      <!-- Generate the version using the current UTC timestamp -->
      <UtcNow Condition="'$(UtcNow)' == ''">$(MSBuildThisFileLastWriteTime)</UtcNow>
      <UtcTimestamp>$([System.DateTime]::UtcNow.ToString("yyyyMMddHHmmss"))</UtcTimestamp>
      <Version>1.0.$(UtcTimestamp)</Version>
      <PackageVersion>1.0.$(UtcTimestamp)</PackageVersion>
      <AssemblyVersion>1.0.0.0</AssemblyVersion>
      <FileVersion>1.0.$(UtcTimestamp)</FileVersion>
    </PropertyGroup>
  </Target>

  <Target Name="BeforeBuild" BeforeTargets="BeforeBuild">
    <CallTarget Targets="GenerateTimestampVersion" />
  </Target>

Once #156 is in, you could start by giving everyone their own personal API key and in turn revoke specific API keys if misused. After that, we will think about extensions to that system.

[Regenhardt]

Possible design:

Each API key gets full permissions by default, as that is the most trivial case.
Additionally, each key could get an optional property like "Permissions" or "PermissionLevel" or something, accepting either an enum like "WriteOnly" vs. "Full", or flags like "Write|Delete|Full" where Full has the same value as Write|Delete, basically as a shorthand which is the default at the same time.
Another possibility: WriteOnly|DeleteOwn|DeleteAll|Full so a Write|DeleteOwn API key can only delete package versions pushed by that API key.
Then each API key has Full permissions by default, but when set, can be limited to WriteOnly.

Different direction: Add Scope to the API key that grants permission only to packages fitting the scope, like confirmed prefixes on nuget.org.
The trivial default would be "", permitting everything.
Options would be specific packages like "BaGetter.Core", or prefixes like "BaGetter.", creating a way of giving teams control over their own domain but not others'.

More design discussion needed.