fix(oracle-oval): Support multiple ELSAs per CVE #221

bpfoster · 2022-06-06T16:28:36Z

This is notably important for when there are additional FIPS and ksplice package patches available.

Adjust persisted advisory details object to be more like the RedHat object - each CVE key contains an array of Entries - each entry contains the fix version and associated ELSAs for different package flavors.
We keep the FixedVersion field at the top of the object to preserve backwards compatibility with older clients.

Since ELSA title and description can be different between the two, do not specify those in the vulnerability details, failing back to the defaults.

Inspecting the database for something like Oracle Linux 8 / gnutls, you can see it now changes from:

CVE-2019-3829 - {
  "FixedVersion":"3.6.8-8.el8"
}
CVE-2019-3836 - {
  "FixedVersion":"3.6.8-8.el8"
}
CVE-2020-11501 - {
  "FixedVersion":"3.6.8-10.el8_2"
}
CVE-2020-13777 - {
  "FixedVersion":"3.6.8-11.el8_2"
}
CVE-2020-24659 - {
  "FixedVersion":"3.6.14-7.el8_3"
}
CVE-2021-20231 - {
  "FixedVersion":"10:3.6.16-4.0.1.el8_fips"     // incorrect - this results in reported vulnerabilities on a patched normal package
}
CVE-2021-20232 - {
  "FixedVersion":"10:3.6.16-4.0.1.el8_fips"     // incorrect - this results in reported vulnerabilities on a patched normal package
}
CVE-2021-20305 - {
  "FixedVersion":"3.6.14-8.el8_3"
}
CVE-2021-3580 - {
  "FixedVersion":"10:3.6.16-4.0.1.el8_fips"     // incorrect - this results in reported vulnerabilities on a patched normal package
}

to:

CVE-2019-3829 - {
  "FixedVersion":"3.6.8-8.el8",
  "Entries": [
    {
      "FixedVersion": "3.6.8-8.el8",
      "VendorIDs": [
        "ELSA-2019-3600"
      ]
    }
  ]
}
CVE-2019-3836 - {
  "FixedVersion":"3.6.8-8.el8",
  "Entries": [
    {
      "FixedVersion": "3.6.8-8.el8",
      "VendorIDs": [
        "ELSA-2019-3600"
      ]
    }
  ]
}
CVE-2020-11501 - {
  "FixedVersion":"3.6.8-10.el8_2",
  "Entries": [
    {
      "FixedVersion": "3.6.8-10.el8_2",
      "VendorIDs": [
        "ELSA-2020-1998"
      ]
    }
  ]
}
CVE-2020-13777 - {
  "FixedVersion":"3.6.8-11.el8_2",
  "Entries": [
    {
      "FixedVersion": "3.6.8-11.el8_2",
      "VendorIDs": [
        "ELSA-2020-2637"
      ]
    }
  ]
}
CVE-2020-24659 - {
  "FixedVersion":"3.6.14-7.el8_3",
  "Entries": [
    {
      "FixedVersion": "3.6.14-7.el8_3",
      "VendorIDs": [
        "ELSA-2020-5483"
      ]
    }
  ]
}
CVE-2021-20231 - {
  "FixedVersion":"3.6.16-4.el8",
  "Entries": [
    {
      "FixedVersion": "3.6.16-4.el8",
      "VendorIDs": [
        "ELSA-2021-4451"
      ]
    },
    {
      "FixedVersion": "10:3.6.16-4.0.1.el8_fips",
      "VendorIDs": [
        "ELSA-2022-9221"
      ]
    }
  ]
}
CVE-2021-20232 - {
  "FixedVersion":"3.6.16-4.el8",
  "Entries": [
    {
      "FixedVersion": "3.6.16-4.el8",
      "VendorIDs": [
        "ELSA-2021-4451"
      ]
    },
    {
      "FixedVersion": "10:3.6.16-4.0.1.el8_fips",
      "VendorIDs": [
        "ELSA-2022-9221"
      ]
    }
  ]
}
CVE-2021-20305 - {
  "FixedVersion":"3.6.14-8.el8_3",
  "Entries": [
    {
      "FixedVersion": "3.6.14-8.el8_3",
      "VendorIDs": [
        "ELSA-2021-1206"
      ]
    }
  ]
}
CVE-2021-3580 - {
  "FixedVersion":"3.6.16-4.el8",
  "Entries": [
    {
      "FixedVersion": "3.6.16-4.el8",
      "VendorIDs": [
        "ELSA-2021-4451"
      ]
    },
    {
      "FixedVersion": "10:3.6.16-4.0.1.el8_fips",
      "VendorIDs": [
        "ELSA-2022-9221"
      ]
    }
  ]
}

See that previously, CVEs CVE-2021-20231, CVE-2021-20232 and CVE-2021-3580 only had fix versions for the FIPS package. We now have fix version for both the FIPS package and the normal one.

This also now supports multiple ELSAs per CVE, rolling up to the latest fixed version. For example:

Oracle Linux 8 / kernel-uek
CVE-2020-28374 - {
  "FixedVersion": "5.4.17-2102.202.5.el8uek",
  "Entries": [
    {
      "FixedVersion": "5.4.17-2102.202.5.el8uek",
      "VendorIDs": [
        "ELSA-2021-9006",
        "ELSA-2021-9037",
        "ELSA-2021-9306"
      ]
    }
  ]
}

Much like FIPS, Ksplice handling is also improved and accounted for:

Oracle Linux 8 / glibc
CVE-2021-3326 - {
  "FixedVersion": "2.28-151.0.1.el8"
  "Entries": [
    {
      "FixedVersion": "2.28-151.0.1.el8",
      "VendorIDs": [
        "ELSA-2021-1585"
      ]
    },
    {
      "FixedVersion": "2:2.28-151.0.1.ksplice2.el8",
      "VendorIDs": [
        "ELSA-2021-9280",
        "ELSA-2021-9344"
      ]
    }
  ]
}

fixes #220

This is notably important for when there are additional FIPS and ksplice package patches available

DmitriyLewen · 2022-06-07T05:31:35Z

Hello @bpfoster
I am working with this problem, too.

What do you think about ELSAs with different fixed versions(non fips or ksplice) for one CVE?
e.g.:
CVE-2021-23133:

Oracle Linux version 8 (kernel-uek)  ELSA-2021-9306  2021-06-15
Oracle Linux version 8 (kernel-uek)  ELSA-2021-9362  2021-07-16

from ELSA-2021-9306:

Oracle Linux 8 (aarch64)kernel-uek-5.4.17-2102.202.5.el8uek.src.rpm

from ELSA-2021-9362:

Oracle Linux 8 (aarch64)kernel-uek-5.4.17-2102.203.5.el8uek.src.rpm

bpfoster · 2022-06-07T17:34:50Z

@DmitriyLewen Ah yes, that is a good point.

What if we revert the change to the advisory-details key back to CVE ID, and instead change the structure of the value?

For example, the two cases we're talking about would then be:

Path: Oracle Linux 8 → gnutls → CVE-2021-20232
Key: CVE-2021-20232
Value:
{
  "Entries": [
    {
      "FixedVersion": "3.6.16-4.el8",
      "VendorIDs": [
        "ELSA-2021-4451"
      ]
    },
    {
      "FixedVersion": "10:3.6.16-4.0.1.el8_fips",
      "VendorIDs": [
        "ELSA-2022-9221"
      ]
    }
  ]
}

and

Path: Oracle Linux 8 → kernel-uek → CVE-2021-23133
Key: CVE-2021-23133
Value:
{
  "Entries": [
    {
      "FixedVersion": "5.4.17-2102.203.5.el8uek",
      "VendorIDs": [
        "ELSA-2021-9306",
        "ELSA-2021-9362"
      ]
    }
  ]
}

Collapsing CVE-2021-23133 into a single fixed version would require scanning and merging all the advisories ahead of saving them to the database, and could use version.NewVersion().Compare() to determine the latest one to use?

While we're here, we may also want to add architecture support as the ELSAs can contain information for multiple architectures? I'm not sure if the versions ever actually differ between the archs.

Pushed up another commit with changes as described above. Think this should work for these cases.

pkg/vulnsrc/oracle-oval/oracle-oval.go

- Simplify data structures - Reduce loops - Refactor out functions - Cleanup syntax

ksplice1 and ksplice2 are not different flavors. ksplice2 is a second revision to the userspace ksplice support code. X.ksplice2 > X.ksplice1

pkg/vulnsrc/oracle-oval/oracle-oval.go

knqyf263 · 2022-06-27T13:39:04Z

I'm so sorry to be late.

I was hopeful trivy/trivy-db had run into schema changes before and had a solution in hand already 🙃

We have it as Trivy DB is now version 2.

Rev the database version and maintain the 2 schemas/versions for some time. Not sure the infrastructure is in place to support this already.

As you said, we have to maintain multiple versions. We already maintain Trivy DB v1 and v2 and it is already hard. Adding v3 makes it harder. We should avoid it as much as possible.

What if we use ELSA-ID as a key? Did you already discuss it? I'm sorry if I missed it.

ELSA-2019-3600 - {
  "FixedVersion":"3.6.8-8.el8",
}
ELSA-2020-1998 - {
  "FixedVersion":"3.6.8-10.el8_2",
}

It increases the database size since we cannot reuse the CVE-ID detail in vulnerability-detail. We may want to have CveIDs.

ELSA-2019-3600 - {
  "FixedVersion":"3.6.8-8.el8",
  "CveIDs": []string{"CVE-2019-3829", "CVE-2019-3836"}.
}

But it doesn't work if there are several fixed versions in the same ELSA-ID.

bpfoster · 2022-06-28T15:19:38Z

What if we use ELSA-ID as a key? Did you already discuss it? I'm sorry if I missed it.

I did initially take that approach. There were some complications with it and I switched back to using CVE as the key. It is most likely feasible to use ELSA ID as the key, but I think we have come to a solution with CVE ID as the key that works for all identified cases and still preserves pretty good backwards compatibility. Is there something I have missed there that ELSA ID as the key solves?

I see a couple concerns with the schema you've proposed:

Unless I'm overlooking something, backwards compatibility is diminished - because ELSA ID is used as the key and not the CVE ID, older clients utilizing the database will not be able to resolve the CVE and will report results like the following:

┌────────────────────────┬────────────────┬──────────┬─────────────────────┬──────────────────────────┬─────────────────────────────────────────────────────┐
│        Library         │ Vulnerability  │ Severity │  Installed Version  │      Fixed Version       │                        Title                        │
├────────────────────────┼────────────────┼──────────┼─────────────────────┼──────────────────────────┼─────────────────────────────────────────────────────┤
│ cyrus-sasl-lib         │ ELSA-2022-0658 │ HIGH     │ 2.1.27-5.el8        │ 2.1.27-6.el8_5           │ https://linux.oracle.com/errata/ELSA-2022-0658.html │
├────────────────────────┼────────────────┤          ├─────────────────────┼──────────────────────────┼─────────────────────────────────────────────────────┤
│ expat                  │ ELSA-2022-0951 │          │ 2.2.5-4.el8         │ 2.2.5-4.el8_5.3          │ https://linux.oracle.com/errata/ELSA-2022-0951.html │
│                        ├────────────────┤          │                     ├──────────────────────────┼─────────────────────────────────────────────────────┤
│                        │ ELSA-2022-9232 │          │                     │ 2.2.5-4.0.1.el8_5.3      │ https://linux.oracle.com/errata/ELSA-2022-9232.html │
├────────────────────────┼────────────────┼──────────┼─────────────────────┼──────────────────────────┼─────────────────────────────────────────────────────┤

Keeping CVE ID as the key yields more familiar results on an older client:

┌────────────────────────┬────────────────┬──────────┬─────────────────────┬──────────────────────┬──────────────────────────────────────────────────────────────┐
│        Library         │ Vulnerability  │ Severity │  Installed Version  │    Fixed Version     │                            Title                             │
├────────────────────────┼────────────────┼──────────┼─────────────────────┼──────────────────────┼──────────────────────────────────────────────────────────────┤
│ cyrus-sasl-lib         │ CVE-2022-24407 │ HIGH     │ 2.1.27-5.el8        │ 2.1.27-6.el8_5       │ cyrus-sasl: failure to properly escape SQL input allows an   │
│                        │                │          │                     │                      │ attacker to execute...                                       │
│                        │                │          │                     │                      │ https://avd.aquasec.com/nvd/cve-2022-24407                   │
├────────────────────────┼────────────────┼──────────┼─────────────────────┼──────────────────────┼──────────────────────────────────────────────────────────────┤
│ expat                  │ CVE-2022-25235 │ CRITICAL │ 2.2.5-4.el8         │ 2.2.5-4.el8_5.3      │ expat: Malformed 2- and 3-byte UTF-8 sequences can lead to   │
│                        │                │          │                     │                      │ arbitrary code...                                            │
│                        │                │          │                     │                      │ https://avd.aquasec.com/nvd/cve-2022-25235                   │
│                        ├────────────────┤          │                     │                      ├──────────────────────────────────────────────────────────────┤
│                        │ CVE-2022-25236 │          │                     │                      │ expat: Namespace-separator characters in "xmlns[:prefix]"    │
│                        │                │          │                     │                      │ attribute values can lead to arbitrary code...               │
│                        │                │          │                     │                      │ https://avd.aquasec.com/nvd/cve-2022-25236                   │
├────────────────────────┼────────────────┼──────────┼─────────────────────┼──────────────────────┼──────────────────────────────────────────────────────────────┤

It is not as flexible as the Entries approach. Trivy does not currently support it for Oracle Linux, but once the dust settles on this I would propose adding support for architectures on the entry. To your point of "if there are several fixed versions in the same ELSA-ID" - There are cases where an ELSA only applies to 1 architecture (ELSA-2022-9496 for example), and there are cases where an ELSA has different versions for different architectures (ELSA-2022-4803 for example). Introducing an Arches field to Entry would be a non-breaking change.

All that said, if you have suggestions on how to improve this, I'm happy to make them so we can move this forward.

bpfoster · 2022-07-07T20:48:43Z

@knqyf263 @DmitriyLewen I apologize if my last reply was too strong. I'd be happy to make some changes here if there's something you'd like done.

bpfoster · 2022-08-16T12:34:23Z

@knqyf263 @DmitriyLewen checking in... anything needed here? Thanks!

…sions-fix

CLAassistant · 2022-08-29T12:13:52Z

All committers have signed the CLA.

DmitriyLewen · 2022-08-30T10:49:35Z

@knqyf263 if i remember correctly - if we use ELSAs we still need to change db structure. Because ELSA can include multiple versions (e.g. default, fips and ksplice) and we can't save them in FixedVersion field. We need to use a different field for this, ut old Trivy uses this field to get version.
uses this field to get the version.
Then we need to store the versions in 2 fields.

@bpfoster am i right?

bpfoster · 2022-08-31T12:34:11Z

@DmitriyLewen I don't think there's anything technically restricting ELSAs from including multiple flavors (default, fips, and ksplice), but it looks like it's Oracle's practice to split them into separate ELSAs. All the one's I've looked at are specific to the flavor.

While out of scope of this change, I would like to point out that the ELSAs support multiple architectures, and there are cases that a single ELSA has different versions for different architectures. See ELSA-2022-4803 for example, which has rsyslog-8.24.0-57.0.4.el7_9.3 for aarch64 and rsyslog-8.24.0-57.0.1.el7_9.3 for x86_64.

Trivy does not currently support architectures for Oracle Linux, but does for RedHat. If we change the key to ELSA ID and leave the database schema as-is with just a FixedVersion, you could not support this in the future. If however we change the schema to what you and I had discussed earlier with a list of Entries (similar to the way RedHat is handled), then we could easily add architecture to the entries (also similar to how the RedHat sources are handeled).

If the changes in this PR are merged in and you have interest in it, I would be happy to submit a change request to add architecture support in the future. If you'd rather fix it all at once, I'd be happy to incorporate that into this PR as well.

From that standpoint, we could use ELSA ID as the key, and use the modified value schema to support this, if there is benefit in using ELSA ID as the key instead of CVE ID.

It is unfortunate that we duplicate the version of the default package in the value, but I'm not sure there's an alternative that both provides the flexibility to solve all these issues and maintains backwards compatibility.

I did have one concern with using ELSA ID as the key, regardless of the structure of the value.
Since we've been emphasizing backwards compatibility - I believe, but could very well be mistaken, that this would provide a degraded report for older clients. This is not a huge issue, but worth mentioning.

Because the existing oracle vulnsrc does not translate the DB vulnerability ID to CVE ID like the redhat one does, the report on an older client will show the ELSA ID as the vulnerability ID instead of CVE ID, and won't include the vulnerability information:

┌────────────────────────┬────────────────┬──────────┬─────────────────────┬──────────────────────────┬─────────────────────────────────────────────────────┐
│        Library         │ Vulnerability  │ Severity │  Installed Version  │      Fixed Version       │                        Title                        │
├────────────────────────┼────────────────┼──────────┼─────────────────────┼──────────────────────────┼─────────────────────────────────────────────────────┤
│ cyrus-sasl-lib         │ ELSA-2022-0658 │ HIGH     │ 2.1.27-5.el8        │ 2.1.27-6.el8_5           │ https://linux.oracle.com/errata/ELSA-2022-0658.html │
├────────────────────────┼────────────────┤          ├─────────────────────┼──────────────────────────┼─────────────────────────────────────────────────────┤
│ expat                  │ ELSA-2022-0951 │          │ 2.2.5-4.el8         │ 2.2.5-4.el8_5.3          │ https://linux.oracle.com/errata/ELSA-2022-0951.html │
│                        ├────────────────┤          │                     ├──────────────────────────┼─────────────────────────────────────────────────────┤
│                        │ ELSA-2022-9232 │          │                     │ 2.2.5-4.0.1.el8_5.3      │ https://linux.oracle.com/errata/ELSA-2022-9232.html │
├────────────────────────┼────────────────┼──────────┼─────────────────────┼──────────────────────────┼─────────────────────────────────────────────────────┤

I hope that clears up my earlier comments. If I'm wrong on any analysis, please feel free to correct me, and I'm happy to make any changes requested. Looking forward to getting this resolved so I can stop getting false positives on FIPS versions 😄 .

DmitriyLewen

research on the choice of structure and dimensions of the various options can be seen here - #452

DmitriyLewen · 2024-11-02T06:29:44Z

pkg/vulnsrc/oracle-oval/oracle-oval.go

+	versions := lo.Values(fixedVers)
+	slices.Sort(versions)
+
+	fixedVersion := fixedVers[NormalPackageFlavor]


I'm not sure about this case.
Should we use fips or ksplice version here?

example - https://linux.oracle.com/errata/ELSA-2016-3515.html

DmitriyLewen · 2024-11-02T10:15:33Z

pkg/vulnsrc/oracle-oval/oracle-oval.go

+	Ksplice1PackageFlavor PkgFlavor = "ksplice1"
+	Ksplice2PackageFlavor PkgFlavor = "ksplice2"


We don't use ksplice1 flavor for ksplice2 (and vice versa) in Trivy:
https://github.com/aquasecurity/trivy/blob/dd0a64a1cf0cd76e6f81e3ff55fa6ccb95ce3c3d/pkg/detector/ospkg/oracle/oracle.go#L72-L77

So i separated ksplice1 and ksplice2.
After these changes db size increased to 0.9MB:

➜ du -sh ./assets-with-flavors 539M ./assets-with-flavors ➜ du -sh ./assets 540M ./assets

It's been long enough that I've lost track of all the details on this, but I did want to pass along some information I got from @tvierling (from the Oracle Linux support/development group) when I was working though this. I won't quote his email directly without his permission, but the gist of it is that ksplice is the flavor, and the number after ksplice is just a revision / build number (which should be considered.. x.y.z.ksplice2 > x.y.z.ksplice1). So I don't think you want to separate out as different flavors.

Hello @bpfoster
I'm glad you're still here and helping with this task.
Sorry we're working on this after so long...

Also, I want to thank you for your work! Our work with you helped me remember the details and update this PR.

but the gist of it is that ksplice is the flavor, and the number after ksplice is just a revision / build number (which should be considered.. x.y.z.ksplice2 > x.y.z.ksplice1). So I don't think you want to separate out as different flavors.

I originally used your PackageFlavor function.
But I was confused that we separate ksplice1 and ksplice2 in Trivy and i updated PR.

But since the person from Oracle Linux says that we shouldn't divide them, then there is a mistake in our logic Trivy.

Thanks! I will revert last commit.

done - a135499

This reverts commit ed3cdbf.

knqyf263 · 2024-11-07T10:31:59Z

@santhosh1729 Can you also please review this PR?

bpfoster added 2 commits June 6, 2022 12:15

fix(oracle-oval): Support multiple ELSAs per CVE

aa6ed6d

This is notably important for when there are additional FIPS and ksplice package patches available

Ensure advisory datasource is populated

1dbc8c6

bpfoster mentioned this pull request Jun 6, 2022

fix(oracle): Improve handling and reporting of vulnerabilities between normal, FIPS, and ksplice package variants aquasecurity/trivy#2273

Closed

6 tasks

Fix case of multiple ELSAs for the same flavor package

9059075

DmitriyLewen reviewed Jun 9, 2022

View reviewed changes

bpfoster added 2 commits June 9, 2022 14:17

PR review feedback

f4bb50a

- Simplify data structures - Reduce loops - Refactor out functions - Cleanup syntax

Fix ksplice handling

63e4055

ksplice1 and ksplice2 are not different flavors. ksplice2 is a second revision to the userspace ksplice support code. X.ksplice2 > X.ksplice1

bpfoster commented Jun 9, 2022

View reviewed changes

pkg/vulnsrc/oracle-oval/oracle-oval.go Outdated Show resolved Hide resolved

bpfoster commented Jun 9, 2022

View reviewed changes

pkg/vulnsrc/oracle-oval/oracle-oval.go Outdated Show resolved Hide resolved

bpfoster commented Jun 9, 2022

View reviewed changes

pkg/vulnsrc/oracle-oval/oracle-oval.go Outdated Show resolved Hide resolved

DmitriyLewen reviewed Jun 10, 2022

View reviewed changes

pkg/vulnsrc/oracle-oval/oracle-oval.go Outdated Show resolved Hide resolved

bpfoster added 2 commits June 10, 2022 07:32

Return advisory from loop rather than breaking

3c13c83

Save normal version in FixedVersion for backwards compatibility

c46983e

Merge remote-tracking branch 'origin/main' into oracle-oval-multi-ver…

57dbc86

…sions-fix

DmitriyLewen mentioned this pull request Mar 31, 2023

CVE-2021-40528 is reported as High severity when it is Medium severity aquasecurity/trivy#3925

Closed

DmitriyLewen mentioned this pull request Jun 22, 2023

fix(rocky): add multi-arch support #321

Merged

DmitriyLewen mentioned this pull request Oct 15, 2024

fix(oracle): split version flavors #452

Closed

DmitriyLewen added 4 commits October 31, 2024 17:27

Merge branch 'master' into 'oracle-oval-multi-versions-fix'

7cdb661

refactor: fix issues after rebase + use types.Advisories

54b2c0b

test: fix tests

377b227

refactor:

d6c0edd

DmitriyLewen added 3 commits November 2, 2024 15:31

fix: update Get function

695da90

test: update/add tests

cd98708

refactor: split ksplice1 and ksplice2

ed3cdbf

DmitriyLewen reviewed Nov 2, 2024

View reviewed changes

DmitriyLewen mentioned this pull request Nov 2, 2024

feat(oracle): add flavors support aquasecurity/trivy#7858

Draft

7 tasks

Revert "refactor: split ksplice1 and ksplice2"

a135499

This reverts commit ed3cdbf.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(oracle-oval): Support multiple ELSAs per CVE #221

fix(oracle-oval): Support multiple ELSAs per CVE #221

bpfoster commented Jun 6, 2022 •

edited

Loading

DmitriyLewen commented Jun 7, 2022 •

edited

Loading

bpfoster commented Jun 7, 2022 •

edited

Loading

knqyf263 commented Jun 27, 2022

bpfoster commented Jun 28, 2022 •

edited

Loading

bpfoster commented Jul 7, 2022

bpfoster commented Aug 16, 2022

CLAassistant commented Aug 29, 2022 •

edited

Loading

DmitriyLewen commented Aug 30, 2022 •

edited

Loading

bpfoster commented Aug 31, 2022

DmitriyLewen left a comment

DmitriyLewen Nov 2, 2024

DmitriyLewen Nov 2, 2024

bpfoster Nov 3, 2024

DmitriyLewen Nov 5, 2024 •

edited

Loading

DmitriyLewen Nov 5, 2024

knqyf263 commented Nov 7, 2024

		Ksplice1PackageFlavor PkgFlavor = "ksplice1"
		Ksplice2PackageFlavor PkgFlavor = "ksplice2"

fix(oracle-oval): Support multiple ELSAs per CVE #221

Are you sure you want to change the base?

fix(oracle-oval): Support multiple ELSAs per CVE #221

Conversation

bpfoster commented Jun 6, 2022 • edited Loading

DmitriyLewen commented Jun 7, 2022 • edited Loading

bpfoster commented Jun 7, 2022 • edited Loading

knqyf263 commented Jun 27, 2022

bpfoster commented Jun 28, 2022 • edited Loading

bpfoster commented Jul 7, 2022

bpfoster commented Aug 16, 2022

CLAassistant commented Aug 29, 2022 • edited Loading

DmitriyLewen commented Aug 30, 2022 • edited Loading

bpfoster commented Aug 31, 2022

DmitriyLewen left a comment

Choose a reason for hiding this comment

DmitriyLewen Nov 2, 2024

Choose a reason for hiding this comment

DmitriyLewen Nov 2, 2024

Choose a reason for hiding this comment

bpfoster Nov 3, 2024

Choose a reason for hiding this comment

DmitriyLewen Nov 5, 2024 • edited Loading

Choose a reason for hiding this comment

DmitriyLewen Nov 5, 2024

Choose a reason for hiding this comment

knqyf263 commented Nov 7, 2024

bpfoster commented Jun 6, 2022 •

edited

Loading

DmitriyLewen commented Jun 7, 2022 •

edited

Loading

bpfoster commented Jun 7, 2022 •

edited

Loading

bpfoster commented Jun 28, 2022 •

edited

Loading

CLAassistant commented Aug 29, 2022 •

edited

Loading

DmitriyLewen commented Aug 30, 2022 •

edited

Loading

DmitriyLewen Nov 5, 2024 •

edited

Loading