-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Function.deps.json references .NET 6 instead of .NET 8, causing security vulnerabilities to be flagged #2759
Comments
The presence of I observed that you are using an older version of the Feel free to reach out if you encounter any further issues with the .NET Isolated model. We're here to help! |
Unfortunately, upgrading the SDK to 1.17.2 hasn't solved it. However, it looks like our issue might be to do with the If I remove this package from the solution, it doesn't bring in old packages to the .azurefunctions folder and passes our security scans. We've tried the 1.2 release candidate of this package, which also solves the issue. Is there any information on when this is expected to be released? |
@davidmrdavid can you comment on the release plans for Durable? Is there an issue @tomings can follow to track this? Thank you! |
Just transferred this to the DF Extension repo, as these dependencies are being pulled due to our package. @tomings: We've been notified of these security warnings and are working to update them. I'm looking to start a hotfix deployment as early as next Monday. As soon as the deployment officially starts, we'll be able to provide you with a GitHub issue you can track to track the release progress. We'll keep you posted. |
@davidmrdavid thank you for the update! |
Just saw this PR: Thanks for all the updates! |
Yep, that PR was just merged :) . We should be able to kickstart a release next week, though I have yet to create the tracking issue. We have some known CI failures we have to tackle (just some dropped Azure DevOps tasks we need to work around), so I'm hoping those don't delay us much, if at all. |
@davidmrdavid Not sure if this will be addressed by your fix, but we're also getting a security vulnerability flagged for the Strangely, this DLL doesn't appear anywhere in the bin or .azurefunctions folder. I can only see it referenced in the function.deps.json file. However, if we remove any refernces to the DurableTask package, the vulnerability isn't flagged. |
As a quick aside, our release tracking ticket is here: #2765 . I need to update the checklist there still, we're much further ahead than what the checklist suggest, and not all steps are needed.
Noted. I'm hoping it's addressed by our current payload but if it isn't, there's no reason another patch couldn't be released shortly after. |
Thanks for the link and the quick reply! |
The new .NET isolated extension package is out: https://www.nuget.org/packages/Microsoft.Azure.Functions.Worker.Extensions.DurableTask/1.1.2 which contains a reference to the WebJobs extension, which contained the outdated @tomings - can you please let me know if this addressed your vulnerability warnings? |
@davidmrdavid It seems to have fixed the |
Thanks @tomings - I did a quick search on NuGet to reverse engineer where the dependency is coming from (if anyone has a better way to find these nested transitive dependencies, I'd love to learn it :-) ), and it's likely a result of our Kesterl dependency set to "Microsoft.AspNetCore.Server.Kestrel (>= 2.2.0)", which in turn brings this "Http.Features" package at version I'll need to triple check if it's safe to update this dependency. I'll follow up. |
Hey @tomings, can you tell me a bit more about the security software that's flagging this package? It's not a call to |
@davidmrdavid I'm not sure what goes on under the hood, but we're using Veracode as a static scanning tool. I'm not at work right now to double check, but this looks like the same issue we're seeing: Azure/azure-sdk-for-net#36411 |
@davidmrdavid Just wondering if there are any updates on this? |
Veracode is flagging the function.deps.json file reference, and updating the NuGet packages does not update the references in the file. I also have no further reference to the Durable extensions, but problem persists. |
Hi @unionthugface, @tomings - If the issue being flagged is Kestrel, then that should be only a static dependency. At runtime, the Durable Functions extension runs in the same process as the Azure Functions host, which loads up to date AspNetCore dependencies. You should be able to validate this at runtime by looking at the DLLs that get loaded in the Host process. Unfortunately, those old dependencies cannot be removed without a major breaking change. The good news is that we're preparing a new major release right now that removes many such old dependencies: #2864 . So, until that release, and assuming we're talking about the Kestrel static dependency, we will need to flag it as a false alarm. |
Hi, I am also facing the same issue with Azure.Identity and Microsoft.Identity.Client. I found out the root cause is coming from the Microsoft.Azure.Functions.Worker.Extensions.EventHubs library. I am on version 6.3.1 and this version is having a dependency of Microsoft.Extensions.Azure v1.7.3 and the Microsoft.Extensions.Azure is having a dependency on Azure.Identity v1.11.0 (which is flagged as vulnerable) and the Azure.Identity is also having a dependency on Microsoft.Identity.Client v4.60.1 (which also flagged as vulnerable). |
Yes, this is my exact same issue ^^ Don't think it's related to Kestrel per se @davidmrdavid |
Problem still persists with "Microsoft.AspNetCore.Http.Features". It is still referencing old version 2.2.0 even after updating Microsoft.Azure.Functions.Worker.Extensions.DurableTask to 1.1.7 version |
We've got an isolated Azure function written in .NET 8, and some packages in the .azurefunctions folder are being flagged by some security software we use, specifically Azure.Identity and Microsoft.AspNetCore.Http.Features.
I've noticed that in the function.deps.json file, it references .NET 6 instead of .NET 8 and wondered if this could be the issue. How can we change this to reference .NET 8?
The text was updated successfully, but these errors were encountered: