Create SECURITY.md

[raman-m]

Please enable Dependabot! Visual Studio reports multiple vulnerabilities due to an outdated target framework. Dependabot will assist in monitoring and managing vulnerabilities of referenced libraries and frameworks. An example can be found in Ocelot repository.

Warnings in VS

Outdated Target Frameworks

Additionally, KubeClient/2.5.12 is currently targeted to the netstandard2.0 framework, which is outdated. It would be more appropriate to target netstandard2.1. However, have concerns regarding netstandard2.1, as ideally, should target net6.0, net7.0, and net8.0. Furthermore, net9.0 has been released this month.
Why do you not adhere to the standard End-of-Support periods for each .NET version?
Please consider changing the targeting frameworks!
I recommend releasing a library with targets for net8.0 and net9.0 only, as net6.0 and net7.0 are no longer supported by Microsoft.

[tintoy]

Hi - thank you for reminding me; I’ve been working on this issue (on and off) for a while now, and am hoping to have some time over the next couple of weeks to complete it (I’ve also been trying to write a code generator for resource models and the associated clients).

It’s a little more challenging than it first appeared on the surface, both because of netstandard weirdness, as well as more high-level design issues arising from fundamental changes in the underlying APIs (e.g. integration with the new IHttpClientFactory, logging, and other DI functionality).

It’s further complicated by the need to port the HTTP templating library (HTTPlease) as well, which also involves the same types of issues as dotnet-kube-client. HTTPlease was built in the ASP.NET WebAPI era and, as such, much (although not all) of the functionality it provides is now also supplied by the “built-in” framework types and packages. It also needs some modernisation to support System.Text.JSON at some point but that certainly doesn’t need to hold up the upgrade.

As for supporting netstandard2.1 (or, indeed, netstandard at all) - again, I think it’s mainly because of the landscape at the time that both libraries were first written (when it wasn’t quite as clear which platforms would support which subset of features). Personally, I’d love to drop netstandard support; you have to give up a lot of features (including language features) to make it work. Another part of the problem is that I’ve never been sure I have a good handle on who our user base is (and was worried that droppingnetstandard support would break some weird but not uncommon platform edge-case); I know there is a PowerShell module that uses the client, and a couple of others that I can’t remember offhand, but support v6-8 should be fine (9 doesn’t add much I’d care enough to use that would justify all the #ifs it would need).

All of the above is the main reason I haven’t enabled dependabot yet; much of what it asks for couldn’t be done without first completing the above work and I’m a little sensitive to interruptions by automated notifications. But, yes, you’re absolutely right it does need to be done. I’ve not had a SECURITY.md file in any of my projects so I don’t know much about how that’s supposed to work, but I’ll take a look at the PR changes when I next get to a computer (and maybe take a look at Ocelot’s for inspiration) and we can take it from there.

[tintoy]

It’s also worth noting that a large part of the reason the upgrade is proving to be painful is self-inflicted; it’s mainly because I’ve left it for far too long before upgrading but, you know, life gets in the way sometimes 🙂

[raman-m]

It’s further complicated by the need to port the HTTP templating library (HTTPlease) as well, which also involves the same types of issues as dotnet-kube-client. HTTPlease was built in the ASP.NET WebAPI era and, as such, much (although not all) of the functionality it provides is now also supplied by the “built-in” framework types and packages. It also needs some modernisation to support System.Text.JSON at some point but that certainly doesn’t need to hold up the upgrade.

OK I see now. HTTPlease is your library. Do you support the lib?

An HTTP client library designed around immutable templates with lazily-resolved parameters.

What is the primary benefit of the library? Why is it not possible to dereference from the HTTPlease package and develop this package using standard .NET functionality related to System.Net and/or System.Net.Http? Subsequently, you could mark the HTTPlease repository as a public archive, right?

[tintoy]

Yes, I could do that (although it would be a breaking change for consumers who have written their own resource clients or other extensions for KubeClient).

The immutable stuff is neither here nor there, but there are some aspects of making an API client that can be tricky to get right (e.g. handling differing response payloads depending on HTTP status code, surfacing error responses as meaningful exceptions, consistently constructing request URIs with correct escaping, consistently supporting multiple authentication methods, etc).

I would like to extract a subset of the most important functionality that’s tricky to get right (e.g. URI templates and response/error-response body handling) and create a simplified version in KubeClient.

[tintoy]

I actually use HTTPlease in a couple of other projects (some of which are still in use) so I probably wouldn’t go as far as archiving it; I’d rather modernise it although it would still be good to remove the dependency from KubeClient.

[raman-m]

Well... Adam, I find the design and implementation complexity of KubeClient and its referenced HTTPlease, which targets netstandard1.3 to be quite challenging❗ This framework is outdated❗ While I acknowledge that migration to .NET 8 and .NET 9 is currently feasible, I recommend targeting the latest .NET Standard version. Why not consider migrating to netstandard2.1? This version supports all .NET Core frameworks and platforms: 3.0, 3.1, 5, 6, 7, 8, and 9. I believe this would be a reasonable compromise in updating the design of the HTTPlease and KubeClient libraries.

[tintoy]

Thanks - I’ll give that a try this weekend (will set up multi-targeting and see what - if anything - breaks for various platforms).

And for what it’s worth I agree with you - while, at the time, the complexity felt justified given the existing landscape, things have moved on and it’s a good time to clean out some of that complexity and replace it (where practical) with implementations that I don’t have to maintain!

[tintoy]

Possible (partial) replacement (of implementation) for HTTPlease URI-template functionality:

https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.extensions.urihelper?view=aspnetcore-6.0
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.extensions.querybuilder?view=aspnetcore-6.0

[tintoy]

Alternative (and one of the most popular) implementations of URI templates:

https://github.com/tavis-software/Tavis.UriTemplates

[tintoy]

Moving HTTPlease-removal work to #166.

[raman-m]

Possible (partial) replacement (of implementation) for HTTPlease URI-template functionality:

https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.extensions.urihelper?view=aspnetcore-6.0 https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.extensions.querybuilder?view=aspnetcore-6.0

Indeed, .NET offers an abundance of useful functionalities. I believe, it is feasible to transition to native Microsoft libraries and packages.

[raman-m]

Alternative (and one of the most popular) implementations of URI templates:

https://github.com/tavis-software/Tavis.UriTemplates

I don't recommend to reference to the next external lib. But it is up to you!

[tintoy]

Only problem is the library from ASP.NET core is only available as a FrameworkReference (which, as a library , we probably don’t want to take as a dependency).

[tintoy]

Moving multi-targeting work to #167.