Welcome to .NET Release News on GitHub Discussions! #9131
Replies: 7 comments 12 replies
-
|
Good choice, sounds great! Please make it so that it's easy to integrate/poll/query (using the Discussions API maybe), as currently it's easy to do on the official blog using RSS. |
Beta Was this translation helpful? Give feedback.
-
|
One idea is to maintain an RSS feed that matches what we post to dotnet/announcements, and to publish preview releases to both. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Thank you, that works. This is the direct link to stay on top of recent discussions in dotnet/core: |
Beta Was this translation helpful? Give feedback.
-
|
Very nice it is built in. Adding this in to the README: #9151 |
Beta Was this translation helpful? Give feedback.
-
|
+1 on having an official aggregated feed as RSS. I use Feedly all the time
to stay on top of the news. Thanks
…On Sat, 10 Feb 2024 at 08:54, Gabe Szabo ***@***.***> wrote:
Good choice, sounds great! Please make it so that it's easy to
integrate/poll/query (using the Discussions API maybe), as currently it's
easy to do on the official blog using RSS.
—
Reply to this email directly, view it on GitHub
<#9131 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE4QV5ENKFPHJB4LLUIGOLYS4YU7AVCNFSM6AAAAABC452MSOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DIMRWGEZDG>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Whilst I understand the motivation to move to GitHub, I think this ultimately hurts the SEO and discoverability of the (pretty awesome) content posted into these previews. Historically I have seen some remarks that were in preview posts that may not have been carried over to the final release. I hope the final release, and maybe RCs, remain as blog posts. I think putting these as GitHub Discussions hurts the discoverability of .NET, but I trust the .NET team has evaluated this. I would welcome some form of RSS or other aggregation tool to get this into feeds downstream. I am part of the C# discord which depends on the .NET Blog RSS feed to circulate information to an audience of well over 50,000 developers. |
Beta Was this translation helpful? Give feedback.
-
I'm glad you like the content. It requires a lot of effort. A big part of this is to focus on docs. Note that .NET 9 preview content is now in docs as of today. Take a test drive. What do you think? #9167
Final release, for sure. We'll make a decision on RCs when we get closer. The comments above describe how to get RSS content for discussions. |
Beta Was this translation helpful? Give feedback.
-
|
As a forum nerd that never found blogs interesting enough, I'm really glad that we can have discussions in a sort-of forum-like format. |
Beta Was this translation helpful? Give feedback.
-
|
The changes are understandable. However, I haven't found out whether the issues that used to aggregate preview changes will continue to serve that purpose, as they are now closed. For example, .NET 9: #9089 and so on. |
Beta Was this translation helpful? Give feedback.
-
|
I closed all those. We won't continue to use issues for that. The Preview 1 discussion and the release notes are replacing that. We see this as a better approach. |
Beta Was this translation helpful? Give feedback.
-
Could CVEs be announced and updated via CVE.org, nvd.nist.gov, and/or msrc.microsoft.com? Those are the locations that vulnerability scanners (and search engines!) direct you towards, but those locations don't seem to actually have anything but a placeholder notification, and don't link back to dotnet/announcements (and presumably wouldn't link back to discussions). For example: https://www.cve.org/CVERecord?id=CVE-2023-36049: The full description is ".NET, .NET Framework, and Visual Studio Elevation of Privilege Vulnerability", but no package/namespace is mentioned, nor explanation of what the vulnerability is. CPEs mention .NET runtimes. Links to https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36049. This provides no extra info, except "To exploit this vulnerability an attacker would have to inject arbitrary commands to the FTP server.". In the footnotes it links to... https://github.com/PowerShell/Announcements/issues/ 54 This finally mentions "An elevation of privilege vulnerability exists in .NET where untrusted URIs provided to System.Net.WebRequest.Create can be used to inject arbitrary commands to backend FTP servers." and links to... https://github.com/dotnet/runtime/issues/ 94725 which does not list the impacted packages, but at least lists the fix version. It also links to https://github.com/dotnet/announcements/issues/ 287 which is the actual primary source. The actual dll and version is only listed on GHSA-c3hf-8vgx-72rh which wasn't linked to from any of those I believe. |
Beta Was this translation helpful? Give feedback.
-
|
CVEs do get updated on NVD and I believe mitre pulls from there. MSRC controls that process, and the format and there's always a lag from when they hit publish on Patch Tuesday to when the content appears. Microsoft does not publish detailed information to NVD, for example, a Windows one from this month also only has a brief description. The same goes for the information posted on the MSRC site. None of this is within our control. When a package is shipped in the runtime, we won't list individual packages because you cannot update them manually. It would be confusing, but we end up putting them in the GitHub advisory so dependabot can flag them because dependabot has no concept of runtimes, but hopefully folks then go read the instructions which are "Update your runtime" So yes, it's a mess, the only thing .NET truely controls is our own announcements. |
Beta Was this translation helpful? Give feedback.
-
Ah, this is actually related to a bugbear of mine. Quite frequently there will be a CVE raised against "ASP.NET Core" or ".NET" but which actually only affects one library. Our vulnerability scanner flags practically all our services, as it will see references to things like In our case the scanner is BlackDuck but I don't think there's much they can do, given that so much stuff gets released/versioned under that same banner, and AFAICT the CVEs often don't list which packages actually have the vulnerability. |
Beta Was this translation helpful? Give feedback.
-
While we can't update them individually, if the full details of the issue and which library is impacted are listed in the CVE then people can at least assess the risk. You might say "Just update the runtime", however in highly regulated environments it's not that simple. Every update contains a lot of risk, and accidental breaking changes do come through in runtime patches (8.0.2 seems to have one). We need to be able to weigh the risk of the vulnerability in our environment against the risk to users.
Would it be possibly to attach the primary source (the announcement here or the security advisory page)? It seems that CVEs often end up with a lot of links attached https://nvd.nist.gov/vuln/detail/CVE-2017-5754 anyway. I have to admit I don't know the process: can anybody simply email NIST and ask them to add missing information? |
Beta Was this translation helpful? Give feedback.
-
|
We're discussing this and related topics at #9205. We're working on a proposal that we'll share soon that will hopefully get much closer to what you want. |
Beta Was this translation helpful? Give feedback.
-
|
I tried to look for Good First Issue or something similar but couldn't find any tag in the issues. Any possibility of adding Good First Issue or similar tags? |
Beta Was this translation helpful? Give feedback.
-
|
Here's an example query of just that on one of our repos: https://github.com/dotnet/runtime/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 |
Beta Was this translation helpful? Give feedback.
-
Hi! We've been using the .NET Blog and dotnet/core and dotnet/announcements repos to keep you up to date for several years now. That's been working well, but we think we can do better. Our friends at GitHub have made Discussions much more capable over the years. We plan to use Discussions as the primary way we share news.
Here's our plan:
Future plans:
The rationale for this change is simple. We can tell from blog readership that readers want more high-value posts about the current stable release of .NET than preview content. We also know that users want to see more focus on high quality content in docs. And finally, we want to have a centralized space on GitHub for developers to continue the conversation around previews. Our solution is to focus on those things. The preview content previously published to the .NET blog will still be available, but it will show up in docs and release notes. In fact, you can check out the first docs PR right now.
It is going to take us a few months to get this new system working well. We'll appreciate your feedback along the way. We want to deliver the information you want, when you want it, and where you want it. We're also looking forward to watching the discussion about new releases right here on GitHub Discussions.
Thanks to everyone that pays close attention to the preview releases, tries them out, and gives us feedback. It helps a lot, and we hope this new system increases the engagement around these early builds of the product. You can expect the same seven previews, two RCs, and a GA release that coincides with .NET Conf in November. Same show, different venue.
Beta Was this translation helpful? Give feedback.
All reactions