-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Draft to extract release json #9210
Changes from all commits
feceb78
8fb2912
23c2697
18393f0
2b34076
c557fd9
9f3bb26
3c4edb7
7ab6792
860c39e
96c507d
6f86483
6f4eccd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I prefer There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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" | ||
} | ||
] | ||
} |
Large diffs are not rendered by default.
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" | ||
} | ||
] | ||
} |
Large diffs are not rendered by default.
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" | ||
} | ||
] | ||
} |
Large diffs are not rendered by default.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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" | ||
} | ||
] | ||
} |
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
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 7
only supportx64
, so that sounds plausibleUbuntu 18.04
supportsx64,
arm64and
arm, but only
armis listed for
Ubuntu 18.04whereas
arm64is the only listed for
Ubuntu 16.04`arm64
seems to have a higher min-version for.NET 7.0.3 and earlier
(which OS does this affect?)Alpine 3.15
only supportsx64
andarm64
throughmusl
, but thre is alsoarm
support listed above@richlander Is
glibc
andmusl
required 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 renamecycle
tomin-cycle
or changecycle
to 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
libc
property 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.
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
source
might 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 themusl
case, 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
glibc
builds 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: