Is the same true for non-Microsoft implementations of nuget? Are Artifactory or Nexus Repo both case-insensitive with nuget packages.

I found something interesting. It appears that even if the package name is case insensitive, the purl subpath will be case sensitive according to https://learn.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks

Do we know if Nuget 1 and 2 APIs stated that they were case insensitive, or is this specific to nuget 3?

For V3, since the client is required to convert to lowercase, it shouldn't matter what server implementation is being used. They all must be case insensitive or else only lowercase packages would be downloadable, and most packages contain at least one uppercase character.

V3 is the first officially documented API. For V2, the unofficial docs say the package ID is case insensitive. However, since the V2 API is OData instead of just files in case-sensitive buckets, the client can send the mixed case package names and I guess it's possible that somebody could make a weird server that has case sensitive package IDs. It'd cause compatibility issues.

The documentation for package authoring has said that package IDs are case insensitive since 2016. Before this it said nothing about case sensitivity.

The modern NuGet client code has considered two packages to be the same if their case insensitive IDs match since 2014.

In the old NuGet repository, I found code from the initial commit in August 2010 to skip installing a package if another package having the same case-insensitive package ID and satisfying the version requirement is already installed. The first preview release was announced over a month later.

I think it's safe to say that the names have always been case insensitive.

We found that lower casing Nuget packages in the sbom broke several tools, open-source and commercial. So, cdxgen retains the original case from the manifest in the sbom but lower cases only when using the NuGet API.

https://github.com/CycloneDX/cdxgen/blob/master/utils.js#L4432

Having interoperability issues seems possible if software was written against the old spec and performs case sensitive ID comparisons against some other source. However, the capitalization needs to be fixed because software that is incorrectly treating the ID as case sensitive will have the same problems when package names are received in with different capitalization. In old .Net, because the complete transitive dependency graph needed to be stored in packages.config and development was almost always done in Visual Studio, developers rarely typed the names of dependencies so it was a pretty safe bet that the package ID would always been seen with the same capitalization. However, in modern .Net, it's not that uncommon for somebody to open their .csproj file in a text editor and type in a new <PackageReference Include="Newtonsoft.JSON" Version="13.0.3" /> or something, in which case tools that process the csproj file must be prepared to accept packages with different capitalization or they will treat Newtonsoft.JSON as a distinct package from Newtonsoft.Json.

@prabhu Unrelated to this issue: it looks like that cdxgen code makes a few mistakes with the way NuGet is handled. NuGet packages do not come in groups (namespaces?), and the prefix cannot be used to determine the license. cdxgen assumes if the ID starts with "microsoft" that it will be licensed under a .NET library license, but this seems unlikely since years ago when Microsoft started open sourcing almost every general .Net library they publish to NuGet. For example, Microsoft.Extensions.Primitives is licensed MIT. Other Microsoft libraries are licensed differently, eg Microsoft.CrmSdk.Workflow is licensed under a Microsoft Power Apps SDK license. The same is true for System, where System.Data.SQLite is public domain, and not published by Microsoft. It looks like the caching is also wrong because it's caching based on the first two name segments, and, unlike NPM, name segments don't really mean anything in NuGet. For example, Serilog.Enrichers.Span Serilog.Enrichers.Context are published by different people and have different licenses.

Thanks @matt-phylum. Let me check and fix these issues.