Minimize vulnerabilities by offering service which offers simple notifications when new SDK/Runtimes are released

[jstallm]

Currently, whenever a vulnerability is discovered in dotnet SDK/Runtime somewhere and a subsequent update is made and released, developers in the community are either -Not notified immediately -Notified by email (by subscribing/watching the announcements)

Its great that engineers can subscribe/watch the announcements to get this information, but in my opinion there is major room for improvements in order to minimize vulnerabilities globally.

For example: Imagine Microsoft dotnet core team offered a simple website which had a simple form: Two input parameters "Hey developers. Want to be notified immediately when new dotnet SDK/Runtimes are released? Tired of discovering vulnerabilities in SDK's days/weeks/months after they are found? Enter your email and phone number below to get immediate notifications when we make updates." Input: Email Input: Phone Number (SMS enabled)

SMS has open rates that are around 90%, and makes SMS a far superior communication channel than email. However, getting notifications on both is optimal since it decreases the average time it takes the average developer to discover these updates.

For example: Lets imagine that today, the average amount of time it takes any given developer to realize a new dotnet core SDK/Runtime was released is 15 days. AVGTimeToDiscovery = 15d

Now, if we were to implement an SMS notification to those interested in getting these updates real-time instead, its highly likely (and perhaps agreeable to many) that the AVGTimeToDiscovery for those that do subscribe to be less than 15d AVGTimeToDiscovery (considering engineer subscribes to SMS) < 15d

Would anyone dispute that having an SMS notification would have little to no impact?

To be completely honest, this is a service that I myself could build/engineer. However, its really worth offering and socializing this type of website/service in the instance Microsoft feels its worthwhile to offer/engineer.

Please let me know how I can minimize the amount of time it takes to get notifications. 1 issue I have with subscribing/watching announcements is that if we get emails with announcements for changes other than new SDK/Releases, those emails get noisy. Here, I am assuming that my goal is the same goal as many others: Minimize amount of time vulnerabilities exist on local development machines + app servers. 1 solution ( not the only certainly) is to allow engineers to get SMS updates only when new SDK/Runtimes are released. What is the thought on this? Thank you in advance for reading this concept. Ultimately, I hope to improve the speed for everyone, not just myself. I dont feel that I am alone in this goal.

[danmoseley]

@jamshedd I know your team has been thinking about this. Can you share thoughts? Also, is there a better repo for this?

[jamshedd]

@jstallm, have you looked at leveraging the release metadata json files for your purpose? Many customers are using this to get automatically notified when a new update or release for Core ships. Some of our own internal products and services like Azure DevOps have set up a watch on this file and when it changes a CI/CD flow picks up the update and deploys this automatically, no human needed. These json files are updated on the existing blob store each month when an update ships.

https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/3.1/releases.json

Additionally, we have install scripts (in both Bash and PS flavors) can that be used to get the latest update and deploy it, you can find more info here.

@danmosemsft, thanks for flagging for my attention, I will move this to the release repo.

[jamshedd]

Sorry I meant the dotnet/core repo.

[jstallm]

@jamshedd , this is great! Perfect I can simply monitor these JSON files and create the notifications as needed for myself. I imagined that others could have benefited from an SMS notification so thought it was worth asking. Thank you again for this insights. Ill be able to resolve the problem for myself individually. Thank you

[jstallm]

Uh oh, It looks like the JSON file is not actually a reliable way to check. I just retrieved the JSON this morning and it claims the latest sdk on channel 3.1. is 3.1.302, which is incorrect. Yesterday SDK 3.1.401 was released, so the JSON appears to be stale. What is the update cadence?

Here is partial JSON from https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json retrieved just now

        {
            "channel-version": "3.1",
            "latest-release": "3.1.6",
            "latest-release-date": "2020-07-14",
            "security": true,
            "latest-runtime": "3.1.6",
            "latest-sdk": "3.1.302",
            "product": ".NET Core",
            "support-phase": "lts",
            "eol-date": "2022-12-03",
            "releases.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/3.1/releases.json"
        },

[mairaw]

Would monitoring this file be a more effective way perhaps? https://github.com/dotnet/core/blob/master/release-notes/releases-index.json

Tagging @rbhanda as well

[rbhanda]

Looks like the file did not get replaced yesterday during our release activities I have updated the https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json

[jamshedd]

Would monitoring this file be a more effective way perhaps? https://github.com/dotnet/core/blob/master/release-notes/releases-index.json

Tagging @rbhanda as well

@jstallm, that file on the blog storage should have been in sync with the one on GH, we need to update it.

@rbhanda, weren't you looking at this recently?

[jstallm]

Would monitoring this file be a more effective way perhaps?

https://github.com/dotnet/core/blob/master/release-notes/releases-index.json

Tagging @rbhanda as well

Which of the two files would be best to treat as the single source of truth?

[jamshedd]

Which of the two files would be best to treat as the single source of truth?

The one in blob storage is not to be trusted at this point, until synchronization issues are permanently resolved the file in the Github repo is the source of truth.