Release a new version with an update ref to 'Azure.Identity'

[SimonCropp]

'Azure.Identity' 1.11.3 has a known moderate severity vulnerability, GHSA-m5vv-6r4h-3vj9

can you release a version that updates this reference

[dauinsight]

We'll look to have this scheduled for our next release

[SimonCropp]

this is a poor experience for consumers. for anyone who has CVE scanning turned on it breaks builds. and they need to explicitly add an azure reference to work around it. so for us it means doing a temporary hack on approx 40 projects just to build again. note that we dont even use azure.

if the sqlclient wants force a transitive azure ref on non azure users, then you should pro-actively release cve related fixes for azure.

[PureKrome]

if the sqlclient wants force a transitive azure ref on non azure users

or a version (stripped down?) without this nuget and whatever it offers? or how about the default version doesn't have this at all and a 2nd version has this so people who want to use Azure.Identity with their SqlClient can use that version. For the 99% rest of us, we don't need to worry about this transitive dep anymore/then.

[jnm2]

One reason of many to want #1108.

[ErikEJ]

@jnm2 Sure, but a better solution is to have a short timeline for release of s patch.

[jnm2]

For this individual occurrence, yes, but I'm also thinking of the future ones.

[CamiloTerevinto]

@jnm2 Sure, but a better solution is to have a short timeline for release of s patch.

Why is a better solution to have a shorter timeline on a dependency that many people don't even need? It would be one thing if SQL Server was Azure only, but there are the obvious cases of people hosting on-prem, on AWS and elsewhere - even on an Azure VM.

[ErikEJ]

@CamiloTerevinto if you are on premises I guess the vulnerability would not affect you, but Azure users would want a patch as soon as possible?

[CamiloTerevinto]

@ErikEJ it affects everyone that treats package vulnerability warnings as errors and those that use SCA as well.

[ErikEJ]

@CamiloTerevinto Exactly, so "a short timeline for release of a patch" would solve it for everyone! 😄

[JRahnama]

@CamiloTerevinto Exactly, so "a short timeline for release of a patch" would solve it for everyone! 😄

During last two months, Azure.Identity has released 5 consecutive version which four of them are deprecated now. Your suggestion indicates we should have had almost 3 patch releases per month.

An automated process could be created to check Azure.Identity latest version for deprecation notice each day and if there is any, hotfix release pipeline could be triggered to release a new version....

Let me discuss this internally with other team members and get back to you.

[ErikEJ]

@JRahnama yeah, it is a lot of updates, but would make all your consumers happy, and potentially avoid/obliviate the requirement to split the package.

[ErikEJ]

@JRahnama If you do this, consider that Azure.Identity depends on Microsoft.Identity.Client, so you should really not have an explicit dependcy on Micrsoft.Identity.Client, like you do today:

https://www.nuget.org/packages/Azure.Identity#dependencies-body-tab

    <AzureIdentityVersion>1.11.3</AzureIdentityVersion>
    <MicrosoftIdentityClientVersion>4.60.3</MicrosoftIdentityClientVersion>

[CamiloTerevinto]

@JRahnama yeah, it is a lot of updates, but would make all your consumers happy, and potentially avoid/obliviate the requirement to split the package.

@ErikEJ I don't understand this position to be honest. Why do you think that having dependencies that aren't needed for some clients but that are kept up to date somehow better than just not having the dependencies at all?
Even if you updated Azure.Identity and other dependencies quickly for security vulnerabilities, that's only meant for customers that are using Azure SQL - for the rest, you're making them see the release notes for this package to see how the release affects them.
You are also hoping that users will update this package quickly enough with the security vulnerability warning, and I have seen people ignore these on VS even.

@JRahnama If Azure.Identity is your dependency, to me, it doesn't matter how many security hotfix releases they do, it should be a high priority to get this package updated with the dependency patched. Otherwise, you are saying to users of this package that you don't care about their security.

[ErikEJ]

@CamiloTerevinto Because I seriously doubt the package split will ever happen, and given that, this would be the desired outcome that pleases most users expect the ones concerned about a few more MB payload.

[PureKrome]

Because I seriously doubt the package split will ever happen, and given that, this would be the desired outcome that pleases most users expect the ones concerned about a few more MB payload.

Sadness. :(

Putting MB payload size and shorter timeframes, etc aside - the issue is really about RESPECT for the consumers here. I (and I feel like many others) find the poor solution design to bake in Azure in to the core product as message suggesting (assuming? or pushing from a sales perspective?) that users should be using SQL with SqlAzure. Not the other options/flavours.

A more respectful solution would be to split out the specific pieces of sql like SqlAzure, etc to their own nugets so people can use what is the bare necessity to them.

What we (the consumers) have to deal with now is the "dependency-hassle" of components/parts of SqlClient which we will never use. This hassle IS NOT about a payload size. sheesh!

And to hand wave this off as 'just deal with it/get over it/it's nothing', we feel is a bit rude :(

ESPECIALLY when this could potentially (I believe) be architected in way to split these concerns out.

If it's about (lack of) manpower - then say so.
If it's about (lack of) budget - then say so.
If it's about a strong design decision - then please educate us so we can understand the gap in understanding.
If it's just a low priority / can't be bothered - then also, please say so.
If you would accept a PR for this - also say as such.

[ErikEJ]

@PureKrome This has been discussed at very great length here: #2247

And based on the fact that this comment from @David-Engel is now 5 months old, I am considering alternative approaches

Also, I am not a Microsoft vendor, I am just an open source contributor from the .NET community.

[PureKrome]

Thanks heaps @ErikEJ - sincerely appreciate the links, comments and help 🤗 🍰

EDIT: Subscribed to #2247 👍🏻

[JRahnama]

@JRahnama If you do this, consider that Azure.Identity depends on Microsoft.Identity.Client, so you should really not have an explicit dependcy on Micrsoft.Identity.Client, like you do today:

https://www.nuget.org/packages/Azure.Identity#dependencies-body-tab

    <AzureIdentityVersion>1.11.3</AzureIdentityVersion>
    <MicrosoftIdentityClientVersion>4.60.3</MicrosoftIdentityClientVersion>

ActiveDirectoryAuthenticationProvider and some other classes is using Microsoft.Identity.Client for AAD authentication. There is a possibility to use Azure.Identity replacement for AAD, but that will limit the useage to Azure users. Can you add a bit more to clarify it?

[ErikEJ]

Can you add a bit more to clarify it?

@JRahnama
I just meant that you do not need an explicit reference and version spec to Microsoft.Identity.Client, it is already referenced via the use of Azure.Identity - I will create a PR to demonstrate

[JRahnama]

Can you add a bit more to clarify it?

@JRahnama I just meant that you do not need an explicit reference and version spec to Microsoft.Identity.Client, it is already referenced via the use of Azure.Identity - I will create a PR to demonstrate

Awesome, it will make it much easier to create an azure function to trigger build pipelines when a new version is released.

[ErikEJ]

@JRahnama Guess I should really backport the reference reduction change to 5.1 and 5.2 then?

[roji]

@JRahnama I'd highly recommend simply looking at enabling Dependabot for dependency changes, rather than building some custom mechanism you'd need to maintain (e.g. via Azure Functions). Dependabot is a built-in Github feature which automatically submits PRs to your repo whenever a dependency is released, and is specifically geared towards keeping your library secure in the face of security issues in its dependency graph (see docs). You basically wake up in the morning and get a PR bumping up e.g. the Azure.Identity version, and the automated CI checks tell you whether everything is OK.

Note that for Dependabot to function correctly, your project needs to follow some basic standard .NET patterns in how it represents the versions in csproj; I know SqlClient has a somewhat complicated build structure which may interfere with that. But i'd recommend looking into it, and cleaning up the SqlClient build system would ideally be a goal unto itself.

That takes care of bumping dependency versions - but when you actually release a new SqlClient version to your users is another question. I'd advise against trying to automatically release anything; not every patch version bump of Azure.Identity (or some other dependency) is something that merits immediately releasing a new SqlClient version - that would cause lots of churn to users that may not care (or even use Azure). I'd invest in being able to release very quickly for when a security issue (or other critical bug) is discovered, but otherwise keep the actual decision to release manual.

Finally, as discussed many times before, I'd keep the dependency management/releasing conversation distinct from whether SqlClient should depend on Azure.Identity at all - the two really are orthogonal (even if the dependency causes a lot of grief in terms of needing to release). I absolutely agree that SqlClient should not depend on Azure.Identity (#1108), but the dependency management/releasing question must be solved regardless of that. After all, even if the Azure.Identity dependency were split off to an external package (e.g. Microsoft.Data.SqlClient.Azure), the exact same problems would apply there.

[cremor]

@JRahnama Guess I should really backport the reference reduction change to 5.1 and 5.2 then?

Did this happen?

[ErikEJ]

@cremor No.

[dauinsight]

Hotfixes 5.1.6 and 5.2.2 have been released which address this issue! Appreciate everyone's patience

[dlatikaynen]

5.2.2 contains System.Text.Json 8.0.0 which gives:

NU1903: Warning As Error: Package 'System.Text.Json' 8.0.0 has a known high severity vulnerability, GHSA-8g4q-xg66-9fp4

so, the dependency tree of 5.2.2 still causes any solution/project which references it to fail the build in azure devops pipelines.

        ├─ Microsoft.Data.SqlClient (v5.2.2)
        │  └─ Azure.Identity (v1.11.4)
        │     ├─ Azure.Core (v1.38.0)
        │     │  ├─ System.ClientModel (v1.0.0)
        │     │  │  ├─ System.Memory.Data (v1.0.2)
        │     │  │  │  └─ System.Text.Json (v8.0.0)
        │     │  │  └─ System.Text.Json (v8.0.0)
        │     │  ├─ System.Memory.Data (v1.0.2)
        │     │  │  └─ System.Text.Json (v8.0.0)
        │     │  └─ System.Text.Json (v8.0.0)
        │     └─ System.Text.Json (v8.0.0)

and no, we will not turn off "Warning As Error", we're health care software providers with some of the highest security requirements that exist in the industry.

[roji]

@dlatikaynen there's no need to turn off "warning as error" - you can simply take a direct reference on a newer version System.Text.Json which doesn't have the CVE. That doesn't mean things shouldn't be updated on the SqlClient/Azure.Identity side, but you shouldn't be blocked by this.

[SimonCropp]

newer version System.Text.Json which doesn't have the CVE

@roji it seems a weird to suggest that every consumer of the SqlClient (i assume there a many at 348.6K downloads per day) apply a hack, instead of making one fix in this codebase and fix it for everyone.

for some context, across out various code bases, we currently have 48 direct reference to various MS packages to avoid CVEs. This is difficult to keep track of since there is no automated way to work out when those CVE hacks are redundant. we need to periodically go back and manually remove them to see if they are still required.

This could be greatly mitigated if MS was pro-active about releasing new nugets that do not have transitive CVEs

[phillip-haydon]

@dlatikaynen there's no need to turn off "warning as error" - you can simply take a direct reference on a newer version System.Text.Json which doesn't have the CVE. That doesn't mean things shouldn't be updated on the SqlClient/Azure.Identity side, but you shouldn't be blocked by this.

No sorry taking directly dependencies fundamentally goes against the entire purpose of transitive dependencies being introduced.

I have had to disable warnings as errors for vulnerabilities because I’ve got warnings from dependencies 3-4 levels deep. It’s the dumbest shit ever and frustrating as hell.

Microsoft needs to fix this at nuget level to take latest minor or build versions.

[MichelZ]

https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/

If you’re faced with the tradeoff between security and another priority, your answer is clear: Do security. -- Satya Nadella

[phillip-haydon]

https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/

If you’re faced with the tradeoff between security and another priority, your answer is clear: Do security. -- Satya Nadella

This is funny. So instead of doing security. Microsoft decided to add work arounds to prevent doing security.

[cremor]

you can simply take a direct reference on a newer version System.Text.Json which doesn't have the CVE

A better solution is to use central package management with transitive pinning and only add a <PackageVersion> element for the updated transitive dependency. That way it stays a transitive dependency instead of becoming a direct one.

But even if you do it that way you still have to manually check it all the time in the future because the tooling doesn't support that very well. See NuGet/Home#13646

I have had to disable warnings as errors for vulnerabilities because I’ve got warnings from dependencies 3-4 levels deep. It’s the dumbest shit ever and frustrating as hell.

I agree that Microsoft should release updated package versions for all their packages when a dependency is updated because of a security problem.
But if you want to ignore those warnings for now - which seems to be the case since you disabled warnings as errors - you can set <NuGetAuditMode>direct</NuGetAuditMode> to ignore security warnings from transitive dependencies. Documentation: https://learn.microsoft.com/en-us/nuget/concepts/auditing-packages#configuring-nuget-audit

[phillip-haydon]

But if you want to ignore those warnings for now - which seems to be the case since you disabled warnings as errors - you can set <NuGetAuditMode>direct</NuGetAuditMode> to ignore security warnings from transitive dependencies. Documentation: https://learn.microsoft.com/en-us/nuget/concepts/auditing-packages#configuring-nuget-audit

Thanks.
I’ll give it a go in the morning. I tried disabling for the advisory url but it didn’t work because the projects and SDK is .NET 8 but I have .NET 9 installed. It worked when I changed to NET 9 but I can’t roll out a NET 9 app yet. Just finishing off Framework 4.7.# to NET 8 and have to move to centralised package versioning to fix dependency mismatch on a 300 project solution.

[roji]

@SimonCropp

it seems a weird to suggest that every consumer of the SqlClient (i assume there a many at 348.6K downloads per day) apply a hack, instead of making one fix in this codebase and fix it for everyone.

First, I never said SqlClient shouldn't themselves update to a newer version that doesn't have a CVE - I believe they should. My answer was to @dlatikaynen's comment just above, that he'd consider turning off warnings-as-errors because of this: that's really unnecessary when one can simply make the problem go away by taking a direct dependency instead. The problem is that many users somehow miss the fact that they can take direct dependencies, and think that they're stuck until SqlClient (or whatever intermediate library) updates.

It's also important to make clear that there's no "hack" being suggested here: taking a direct dependency on a transitive dependency achieves exactly the same thing as SqlClient doing the update on their side. It's not ideal to have everyone do that, but it's a very reasonable workaround in the meantime.

[phillip-haydon]

The problem is that many users somehow miss the fact that they can take direct dependencies, and think that they're stuck until SqlClient (or whatever intermediate library) updates.

This is a hacky work-around. There is literally no point in Microsoft implementing transitive dependencies if we are required to take direct dependencies to fix CVE issues.

Microsoft is 100% at fault here for wasting time implementing features to ignore advisory urls, disable errors, etc, instead of having a default or a setting to automatically take the latest major/minor/build version of a transitive dependency instead of taking the lowest 100% of the time.

[roji]

@phillip-haydon not every library will be able to bump a dependency and release at the exact moment that one of its dependencies has a CVE published against it - every time that happens. It's fine to ask SqlClient to update (and they should), but it's also completely fine (and not at all a hack) for an application to temporarily reference a transitive dependency with a CVE.

instead of having a default or a setting to automatically take the latest major/minor/build version of a transitive dependency instead of taking the lowest 100% of the time.

You're basically talking about floating a dependency version, and that is a really bad idea for quite a few reasons.

[Haukinger]

@roji could you expand on why it should be easier for the consumer of a library to validate the library with a new version of a dependency of the library than it would be for the auther of the library?

What prevents a library author from bumping the dependency, if it is not validation of the new version? Even a one man team should be able to run the test suites and publish a new version withing hours, let alone a corporation the size of microsoft.

It's also important to make clear that there's no "hack" being suggested here: taking a direct dependency on a transitive dependency achieves exactly the same thing as SqlClient doing the update on their side. It's not ideal to have everyone do that, but it's a very reasonable workaround in the meantime.

Without validating the library with the new version of the dependency, this is the textbook definition of hack. Essentially, you're suggesting to potentially thousands of customers to take the direct dependency (completely fine) and gamble that that their applications don't crash because of the library being incompatible with the direct dependency (questionable at least).

[roji]

What prevents a library author from bumping the dependency, if it is not validation of the new version? Even a one man team should be able to run the test suites and publish a new version withing hours, let alone a corporation the size of microsoft.

That is absolutely not how things work, especially not in a large corporation. Releasing .NET, for example, is a long process with lots of process and verification - it simply isn't possible to "just release" within a few hours.

Without validating the library with the new version of the dependency, this is the textbook definition of hack.

It is not.

SqlClient is does not specify a single, specific version of its own dependencies; it could do that via nuget, saying that it will only work with a specific version, but instead it does the default thing of requiring only a minimum version. It is common and accepted for people to bump patch (but not major) versions of a transitive dependency, because e.g. a bug is fixed in that transitive dependency and a newer version of the direct dependency hasn't been released (remember, this isn't just about security). For example, with EF, it's fine for people to depend on a newer version of SqlClient than is specified by EF's SQL Server provider; the compatibility bar is generally very high.

And regardless, ultimate validation that everything works is your responsibility as the app developer. Even if SqlClient was tested to be compatible with a certain version of its own transitive dependency, upgrading to that transitive dependency may cause issues in your own application in various ways.

---

Stepping back... Everyone, this isn't the place to debate general .NET practices around transitive dependencies and CVEs. Nobody is saying that SqlClient shouldn't update its dependencies to avoid having CVEs in its transitive dependency graph; but this simply isn't something that can always happen immediately.

You certainly have the right to expect SqlClient (and any other maintained library) to bump its own dependency versions and release, so that there are no transitive CVEs. But you cannot expect that to happen 5 minutes after a CVE is published.