Draft to extract release json #9210
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,64 @@ | ||
| { | ||
| "channel-version": "7.0", | ||
| "last-updated": "2024-02-28", | ||
| "glibc": [ | ||
| { | ||
| "name": "CentOS", | ||
| "supported-cycles": [ | ||
| { | ||
| "cycle": "7", | ||
| "architectures": ["x64"], | ||
| "required-version": "2.17" | ||
|
There was a problem hiding this comment. I prefer There was a problem hiding this comment. We also have a C++ standard library dependency. We should add that, too. I don't think we've ever documented that since it doesn't come up much. If you are able to satisfy libc, then the standard C++ library will probably be satisfied, too. However, being transparent for both is a good plan (now that we're rethinking all of this). There was a problem hiding this comment. I like There was a problem hiding this comment. Here: #9210 (comment) In that case, writing |
||
| } | ||
| ], | ||
| "last-updated": "2024-03-21" | ||
| }, | ||
| { | ||
| "name": "Ubuntu", | ||
| "supported-cycles": [ | ||
| { | ||
| "cycle": "16.04", | ||
| "architectures": ["arm64"], | ||
| "required-version": "2.23" | ||
| }, | ||
| { | ||
| "cycle": "18.04", | ||
| "architectures": ["arm"], | ||
| "required-version": "2.27" | ||
| } | ||
| ], | ||
| "last-updated": "2024-03-21" | ||
| } | ||
| ], | ||
| "musl": [ | ||
| { | ||
| "name": "Alpine", | ||
| "supported-cycles": [ | ||
| { | ||
| "cycle": "3.15", | ||
| "architectures": ["x64", "arm64"], | ||
| "required-version": "1.2.2" | ||
| } | ||
| ], | ||
| "last-updated": "2024-03-21" | ||
| } | ||
| ], | ||
| "operating-systems" : [ | ||
| { | ||
| "name": "Ubuntu", | ||
| "lifecycle-policy": "https://wiki.ubuntu.com/Releases", | ||
| "architectures": ["x64", "arm64", "arm"], | ||
| "supported-cycles": ["20.04", "22.04", "23.10", "24.04"], | ||
| "unsupported-cycles": ["16.04", "18.04", "22.10", "23.04"], | ||
| "last-updated": "2023-02-21" | ||
| }, | ||
| { | ||
| "name": "iOS", | ||
| "lifecycle-policy": "https://support.apple.com/ios", | ||
| "architectures": ["x64", "arm64", "arm"], | ||
| "supported-cycles": ["15", "16", "17"], | ||
| "unsupported-cycles": ["10", "11", "12", "13", "14"], | ||
| "last-updated": "2023-02-28" | ||
| } | ||
| ] | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| { | ||
|
There was a problem hiding this comment. This is a bit bare. I think we should include a date and .NET version. Many folks will probably follow the links to this file and then use this content for the actual deserialization step and want a bit more data than just the CVEs. Certainly, there are other ways to do it, but this approach could be very convenient. There was a problem hiding this comment. Yep, only the existing data so far. It's one of the points that I wanted to discuss what data could make sense in here. Since we want to generate those, the data this would be generated from would (in my view) also have more information, as this is duplicated per version it was fixed in. There was a problem hiding this comment. IMO, "duplication" isn't really the right metric to use. People are going to deserialize these objects. What data will they want? Imagine adding those objects to a dictionary and/or using LINQ on them. Having a bit more information would make that flow super nice. There was a problem hiding this comment. I added the date and .NET version to them. I think we still have an open discussion on what other information might be useful. In my opinion, having the affected version in there might be valuable. There is also the discussion about having a monthly set of those centrally (over all channels) that's not in the draft yet as I wanted to wait for what data we want to have. There was a problem hiding this comment. We need a date in the front matter. If you follow the links from cve-index.json, there are no dates. You'd have to also read releases-index.json to get the dates. I think that's the only addition we need for CVEs. I don't think we need "also applies to" unless we get asked for that. That is calculatable by looking at all the cve.json files for that date for supported versions. |
||
| "cve-list": [ | ||
| { | ||
| "cve-id": "CVE-2023-36049", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36049" | ||
| }, | ||
| { | ||
| "cve-id": "CVE-2023-36558", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36558" | ||
| }, | ||
| { | ||
|
There was a problem hiding this comment. How about this: {
"cve-id": "CVE-2023-36038",
"cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36038",
"ms-url": "https://github.com/dotnet/announcements/issues/286",
"affected-os" : ["windows"],
"affected-repos": [
{
"repo" : "https://github.com/dotnet/aspnetcore"
}
]
}The We could do something similar with operating system so that we could add architecture. I don't think that's worth it. There will always be some aspect we cannot represent. For example, this CVE only applies to IIS. There was a problem hiding this comment. Is there a similar concept like "affected-components" or "affected-products", so then it'd be "aspnetcore-runtime", "windowsdesktop", "sdk"? Trying to articulate something (badly) that's like a distributable unit that's more fine-grained than (or untied to) a specific GitHub repo. There was a problem hiding this comment. That's a great point. {
"cve-id": "CVE-2023-36038",
"cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36038",
"ms-url": "https://github.com/dotnet/announcements/issues/286",
"affected-os" : ["windows"],
"affected-components": [
{
"component": "Microsoft.AspNetCore.App",
"versions" : "<8.0.0",
"repo" : "https://github.com/dotnet/aspnetcore"
}
]
} |
||
| "cve-id": "CVE-2023-36038", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36038" | ||
| } | ||
| ] | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| { | ||
| "cve-list": [ | ||
| { | ||
| "cve-id": "CVE-2024-0056", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-0056" | ||
| }, | ||
| { | ||
| "cve-id": "CVE-2024-0057", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-0057" | ||
| }, | ||
| { | ||
| "cve-id": "CVE-2024-21319", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21319" | ||
| } | ||
| ] | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| { | ||
| "cve-list": [ | ||
| { | ||
| "cve-id": "CVE-2024-21386", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21386" | ||
| }, | ||
| { | ||
| "cve-id": "CVE-2024-21404", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21404" | ||
| } | ||
| ] | ||
| } |
|
There was a problem hiding this comment. Not sure if we want to only have a index file for all security fixes (similar to the |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| { | ||
| "channel-version": "8.0", | ||
| "last-updated": "2024-02-28", | ||
| "cve-list": [ | ||
| { | ||
| "release-version": "8.0.2", | ||
| "cve.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/8.0.2/cve.json" | ||
| }, | ||
| { | ||
| "release-version": "8.0.1", | ||
| "cve.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/8.0.1/cve.json" | ||
| }, | ||
| { | ||
| "release-version": "8.0.0", | ||
| "cve.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/8.0.0/cve.json" | ||
| }, | ||
| { | ||
| "release-version": "8.0.0-rc.2", | ||
| "cve.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/preview/8.0.0-rc.2.cve.json" | ||
| }, | ||
| { | ||
| "release-version": "8.0.0-rc.1", | ||
| "cve.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/preview/8.0.0-rc.1.cve.json" | ||
| } | ||
| ] | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| { | ||
| "cve-list": [ | ||
| { | ||
| "cve-id": "CVE-2023-36799", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36799" | ||
| }, | ||
| { | ||
| "cve-id": "CVE-2023-36796", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36796" | ||
| }, | ||
| { | ||
| "cve-id": "CVE-2023-36792", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36792" | ||
| }, | ||
| { | ||
| "cve-id": "CVE-2023-36794", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36794" | ||
| }, | ||
| { | ||
| "cve-id": "CVE-2023-36793", | ||
| "cve-url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36793" | ||
| } | ||
| ] | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to make sense from https://github.com/Falco20019/core/blob/extract-release-json/release-notes/7.0/supported-os.md#libc-compatibility but am not completely sure I got it right.
CentOS 7only supportx64, so that sounds plausibleUbuntu 18.04supportsx64,arm64andarm, but onlyarmis listed forUbuntu 18.04whereasarm64is the only listed forUbuntu 16.04`arm64seems to have a higher min-version for.NET 7.0.3 and earlier(which OS does this affect?)Alpine 3.15only supportsx64andarm64throughmusl, but thre is alsoarmsupport listed above@richlander Is
glibcandmuslrequired version tightly linked to the OS and architecture and is the OS cycle the min version including all following if not defined otherwise? In that case, I would renamecycletomin-cycleor changecycleto an array like withsupported-cycles.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think musl vs glibc makes sense as a top-level notion. I don't think it makes sense to list the OSes we use in our build system in this file. That's an implementation detail. The contract is the min versions that result from those choices. That does make sense to list, same as we do in the md file.
I think a
libcproperty could make sense for Linux distros, however, it doesn't add much since we currently only support one muslc distro and I don't see that changing soon.For .NET 6 and 7, the glibc support differed for Arm64 and x64. That changed with .NET 8+, where we were able to unify the two. They should stay unified going forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can make a proposal on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proposal for that section. I skipped the OS content for brevity. Ideally, the OS content would come first. Most readers won't care/need this information and serializers can (at least in theory) skip it.
{ "channel-version": "6.0", "last-updated": "2024-02-28", "glibc": [ { "architecture" : "x64", "version": "2.17", "source": "CentOS 7" }, { "architecture" : "arm64", "version": "2.23", "source": "Ubuntu 16.04" }, { "architecture" : "arm32", "version": "2.23", "source": "Ubuntu 16.04" } ], "musl" : [ { "architecture" : "x64", "version": "1.2.2", "source": "Alpine 3.13" }, { "architecture" : "arm64", "version": "1.2.2", "source": "Alpine 3.13" }, { "architecture" : "arm32", "version": "1.2.2", "source": "Alpine 3.13" } ] }There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using strings as
sourcemight make it harder to work with in a parsable form (compared to having it split up into os-name and os-cycle). I also find it strange to duplicate full items in themuslcase, as it might introduce the need for users to compare and join those manually.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The strings are solely there to enable printing the following text.
https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md#libc-compatibility
I don't have another use case in mind where the "source" values would be needed. Do you? There is no user action to take as a result of that information (other than not running .NET 6 on Alpine 3.12, for example).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The duplication is unfortunate, however, I'm not sure how to solve that w/o adding more complexity to the format. This is effectively 1NF in database schema. It works. As demonstrated, the
glibcbuilds require this approach. It' possible that we'll never need this per-architecture description again, but that's not a great bet to make.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do this:
{ "channel-version": "6.0", "last-updated": "2024-02-28", "glibc": [ { "architecture" : "x64", "version": "2.17", "source": "CentOS 7" }, { "architecture" : "arm64", "version": "2.23", "source": "Ubuntu 16.04" }, { "architecture" : "arm32", "version": "2.23", "source": "Ubuntu 16.04" } ], "musl" : [ { "architectures": ["arm32", "arm64", "x64"], "version": "1.2.2", "source": "Alpine 3.13" } ] }