Nugetgallery: Better protection for verified packages.

Created on 5 Mar 2018  Â·  11Comments  Â·  Source: NuGet/NuGetGallery

At present there is no protection at all for verified packages other than the blue tick. We need better protection.

I am one of the owners of SixLabors. A registered company made up of OSS developers who have spent the last 3+ years building a cross platform 2D Graphics API for .NET Core. We have reserved our namespace in a vain attempt to protect end users from unsanctioned uploads using our branding on Nuget.

https://www.nuget.org/profiles/sixlabors

This user has uploaded every single one of our pre-release packages, easily bypassing any namespace reservation validation by simply adding their own prefix to our namespace.

https://www.nuget.org/profiles/intheloop

SixLabors.ImageSharp becomes Loop.SixLabors.ImageSharp

They:

  • Use our logos
  • Point to our Github repository for support
  • Have changed version numbers removing any pre-release tags.

This means that there are now potentially dangerous, pre-release packages on Nuget that contain our name and show up in the default search.

I will be reporting them for copyright violation but I have yet to successfully remove a project that violates our copyright from Nuget having previously reported the below listed projects for doing similar (logo, repo-link). The apathetic responses from support have been very disappointing.

https://www.nuget.org/packages/RevStackCore-ImageSharp/
https://www.nuget.org/packages/RevStackCore-ImageSharp.Drawing/

Can we add at least do the following?

  • If a verified project want a clone removed, actually do it.
  • Add better namespace protection - i.e don't allow it to feature anywhere in an non-validated name.
  • Prevent unverified packages linking back to a verified packages repository for logos
  • Prevent unverified packages linking back to a verified packages repository for support
Feature

Most helpful comment

Ahh, good spot! Just goes to show how hard it can be to spot these things!

All 11 comments

+1

I'd go so far as to add a few extra requirements:

  • Any package that can be shown to be repackaged, should not be allowed to include unrelated dependencies (e.g. https://www.nuget.org/packages/IonicZip/1.9.1.8)
  • Any package that can be shown to be repackaged, should be flagged "Unofficial" in their package title.
  • Any package that can be shown to be repackaged, should ideally be forced to use the "Unofficial" root namespace as a matter of policy.

The reporting process needs to change also.

At present all the work has to be done by the verified package owner.

To get a package violating our copyright removed I have to:

  • Contact the owner of the offending package by email
  • Forward a copy of that email to [email protected]
  • Fill in the copyright violation form on Nuget
  • Hope for the best.

I strongly believe that the emphasis should be on the accused to prove that they have not violated the copyright of the verified package and that a soft removal should be immediate with a hard removal occurring if the accused cannot prove that they're package does not violate copyright.

We are verified after all?

@jimbobsquarepants I'd argue that, unless there was an instance of the verified namespace within the package namespace at the very least.

Otherwise you might start issuing takedowns for your competitors.

We don't want this to become another ContentID farce like YouTube, where a few big players spoil out for everyone.

We don't want this to become another ContentID farce like YouTube, where a few big players spoil out for everyone.

@dolkensp Definitely not. And with the aforementioned protection regarding logos and repository links in place it should boil down to namespace violation.

If someone can prove they are not violating copyright. Great! What I want to avoid is the compounding of already stressful situations with policy that does not actively protect the verified user.

Here's an example where Microsoft's own official package has less downloads than the Unofficial clone...

Scary...

image

@dolkensp None of them are official ;) We have had issues where anybody could have used a Microsoft. prefix for packages. We have since then fixed the issue with Prefix ID Reservation but existing packages remain.

Ahh, good spot! Just goes to show how hard it can be to spot these things!

Thanks for reporting this. Can you please report them using the ‘Report’ option on the packages?
This may seem like a redundant step but it is required to take down any package citing copyright or trademark violation. Do select the right option in the drop down.

Already have.

Was this page helpful?
0 / 5 - 0 ratings