Add glibc advisories

glibc has started publishing its own advisories:

https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;h=a0872e990274aee4d881508dad1bce3ea49d4d07;hb=HEAD

@ziadhany

May I work on this issue I have gotten a rough Idea about how advisories are being imported.
Please see @ziadhany and @TG1999

@harsh098

@harsh098 re:

May I work on this issue I have gotten a rough Idea about how advisories are being imported.

sure, please do: do not hesitate to ask questions as you go.

@harsh098

@harsh098 See this commit by @siddhesh for some details:
https://sourceware.org/git/?p=glibc.git;a=commit;h=60c57b8467f11e334e7c7fd07d588c248e93d952

Move CVE information into advisories directory

One of the requirements to becoming a CVE Numbering Authority (CNA) is
to publish advisories. Do this by maintaining a file for each CVE fixed
in the advisories directory in the source tree. Links to the advisories
can then be shared as:

https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-YYYY-NNNN

The file format at the moment is rudimentary and derives from the git
commit format, i.e. a subject line and a potentially multi-paragraph
description and then tags to describe some meta information. This is a
loose format at the moment and could change as we evolve this.

Also add a script process-fixed-cves.sh that processes these advisories
and generates a list to add to NEWS at release time.

An example of the format is: https://sourceware.org/git/?p=glibc.git;a=blob;f=advisories/GLIBC-SA-2023-0003;h=0950dc0792d94b28703837dce353a8ca5be0d96b;hb=HEAD

@siddhesh just a FYI, we will start consuming these, which means writing a parser for these... If you like, we could help you with adopting some format that makes it easy to consume your advisories!

@pombredanne

Sure @pombredanne I'll be asking wherever I get stuck

@siddhesh

@siddhesh just a FYI, we will start consuming these, which means writing a parser for these... If you like, we could help you with adopting some format that makes it easy to consume your advisories!

Thanks, I'd love to hear feedback. We started to but then stayed away from format discussions because we agreed on getting the information right first. Whatever feedback you give should help us clean up on both fronts, format as well as data, based on what you typically publish for advisories.

@pombredanne

Hi @pombredanne ,
I had problem figuring out the purl for glibc from glibc.
I had a look at
https://github.com/package-url/purl-spec
I came up with
pkg:generic/glibc@version?commit=commit-id
may I proceed with it ?

@siddhesh

@siddhesh and @pombredanne
I wrote a sample parser to parse advisories at https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;h=a0872e990274aee4d881508dad1bce3ea49d4d07;hb=HEAD

Please check the format, this will be adapted to AdvisoryData in final importer

def parse_advisory(file):
    """
        THE Given Function Scrapes the following data from the given advisory files at
        https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories

            1. CVE_ID
                    DataType: str

            2. Vulnerable Versions 
                    Schema :
                        "version": "None if no Vulnerable-Backport Exists else report Commit_ID of Vulnerable-Backport"
            
            3. Fixed Versions
                    Schema :
                        "version": "Commit_ID that implements the fix"

            4. Title of CVE
                    DataType: str
            
            5. Summary of CVE
                    DataType: str

        
        The function returns the following data
                title: str #Title of CVE
                date: str  # Date Reported
                summary: str #Description of Advisory
                cve_desc: List[str]   # CVE_ID determined
                vuln_versions: Dict[str,str] #List of Vulnerable Versions
                fixed_versions: Dict[str,str] #List of Fixed Versions
                    
    """
    with open(file) as f:
        lines = f.readlines()
        title = lines[0]
        date: str
        cve_desc: str
        vuln_versions = dict()
        fixed_versions = dict()
        summary=""
        for i in range(1, len(lines)):
            if lines[i]=='\n':
                continue
            if "CVE-Id:" in lines[i]:
                cve_desc = lines[i].split(":")[1].strip()
            elif "Public-Date" in lines[i]:
                date = lines[i].split(":")[1].strip()
            elif "Vulnerable-Commit" in lines[i]:
                vulnerable_version = lines[i].split(":")[1].strip().split("(")[1].split(")")[0].strip()
                commit = lines[i].split(":")[1].strip().split("(")[0].strip()
                vuln_versions[vulnerable_version] = commit
            elif "Vulnerable-Backport" in lines[i]:
                vulnerable_version = lines[i].split(":")[1].strip().split("(")[1].split(")")[0].strip()
                commit = lines[i].split(":")[1].strip().split("(")[0].strip()
                vuln_versions[vulnerable_version] = commit
            elif "Fix-Commit" in lines[i] or "Fix-Backport" in lines[i]:
                fixed_version = lines[i].split(":")[1].strip().split("(")[1].split(")")[0].strip()
                commit = lines[i].split(":")[1].strip().split("(")[0].strip()
                if fixed_version not in vuln_versions:
                    vuln_versions[fixed_version]=None
                fixed_versions[fixed_version] = commit
            else: 
                summary+=lines[i].strip()+" "
        
        return title, date, summary, cve_desc, vuln_versions, fixed_versions



if __name__ == '__main__' :
    for field in parse_advisory("GLIBC-SA-2023-0005"):
        print(field)

Please suggest any edge cases I'm missing out on.

Also @pombredanne please help me with purl for the glibc official sources as asked above.
Also, please let me know if a version can be specified as pre-2.39 in purl.
As, this advisory https://sourceware.org/git/?p=glibc.git;a=blob;f=advisories/GLIBC-SA-2023-0005;h=a518af803a7121038e912fae7fdcf4fe7260d362;hb=HEAD
reports a version as pre-2.39

@harsh098

@harsh098 re:

I wrote a sample parser to parse advisories at https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;h=a0872e990274aee4d881508dad1bce3ea49d4d07;hb=HEAD

Can you push this in a branch with some tests?
Since there is a small number of advisories for now, you should be able to parse them all in the tests. It will be simpler to post comments on the code in a PR.

As for the code, my knee jerk reaction is that you should avoid using indexes for lines as this makes things hard to read and understand.... But please write the unit tests first!

Also I wonder if the format is not something more or less like a Debian/RFC822 format or vaguely YAML'ish. If Debian like, we have a robust parser for Debian control files in https://github.com/nexB/debian-inspector/blob/main/src/debian_inspector/deb822.py and https://github.com/nexB/debian-inspector/blob/main/src/debian_inspector/

@siddhesh

@siddhesh re:

Hi @pombredanne ,
I had problem figuring out the purl for glibc from glibc.
I had a look at
https://github.com/package-url/purl-spec
I came up with
pkg:generic/glibc@version?commit=commit-id
may I proceed with it ?

There are multiple ways to handle this:

A generic PURL like you suggested but this will need a download_url qualifier
A new PURL type for glibc ... which IMHO makes the most sense since this is now a CNA and is a rather important package ;) ... we can start using it here and then submit a PR to the purl-spec to add this as a supported type.
Another option is to instead create a sourceware type and have glibc as a name under this. sourceware is "forge-like" with https://sourceware.org/glibc/ as a homepage URL as https://www.gnu.org/software/libc/ as a secondary (or the otherway around), http://ftp.gnu.org/gnu/glibc/ as the root for the downloads, the git repo https://sourceware.org/git/?p=glibc.git for the code and advisories. There is not much structured metadata otherwise, but this a super popular package so it does not matter, this is well known enough.
yet another option is to have a gnu type and a libc as a name.

I think I would like to go with 3. sourceware but since this would be the way glibc may start to be referenced in the many many tools and specs that use PURL, it would be great to have @siddhesh and some glibc community input. pkg:gnu/libc@<someversion> vs. pkg:sourceware/glibc@<someversion> and we can use glibc or libc as a name???

@harsh098

@harsh098 re:

I wrote a sample parser to parse advisories at https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;h=a0872e990274aee4d881508dad1bce3ea49d4d07;hb=HEAD

Can you push this in a branch with some tests? Since there is a small number of advisories for now, you should be able to parse them all in the tests. It will be simpler to post comments on the code in a PR.

As for the code, my knee jerk reaction is that you should avoid using indexes for lines as this makes things hard to read and understand.... But please write the unit tests first!

Also I wonder if the format is not something more or less like a Debian/RFC822 format or vaguely YAML'ish. If Debian like, we have a robust parser for Debian control files in https://github.com/nexB/debian-inspector/blob/main/src/debian_inspector/deb822.py and https://github.com/nexB/debian-inspector/blob/main/src/debian_inspector/

I haven't started work on the importer yet. My first goal is to get the parser right.
So, may I write these advisories and tests in a separate repo and add you(@pombredanne ) and @siddhesh as contributor.
My Goal is to first get the parser to cover all edge cases.

The format is not vary YAML ish and is much more like Debian/RFC822.
But the grammar for the format used by GLIBC is not very well defined unlike RFC822 and the fields are entirely different.
That calls for a parser of its own.

A few recommendations would be to get the versioning in the advisories standardised instead of using versioning like pre-2.39 use concrete versions or use <= better would be to refer to version tags

@pombredanne

Also, I wanted to ask @pombredanne how do you fetch the tags in the VCSResponse class as this would be very valuable in determining affected versions for versions like pre-2.39 and so on ?

@harsh098

@harsh098 Please start a PR early, even if this is only for the parser. We cannot review code otherwise. That's the FOSS way!
If anything that will help us understand any issues with the format.

And wrt. the Git tags and in general the glibc versions there are two ways to get versions:

Parse http://ftp.gnu.org/gnu/glibc/ as HTML. We have code in PurlDB to do this in https://github.com/search?q=repo%3AnexB%2Fpurldb href&type=code way too many places... we should have a shared function instead. An example is this https://github.com/nexB/purldb/blob/e1a20006b513a0379e69a69624da4e614a4f27dd/etc/scripts/utils_thirdparty.py#L1739 or OpenSSL releases https://github.com/nexB/purldb/blob/e1a20006b513a0379e69a69624da4e614a4f27dd/minecode/visitors/openssl.py#L38
Collect Git tags either from a clone. There is code in FetchCode for this. And also in PurlDB https://github.com/nexB/purldb/blob/e1a20006b513a0379e69a69624da4e614a4f27dd/packagedb/find_source_repo.py#L427 We should have only one way in FetchCode instead. It boils down to running https://git-scm.com/docs/git-ls-remote.html (or similar through a library call)

@keshav-space @TG1999 do you have some hints on which function/code to call for this?

Note that ideally glibc would expose a simple way to list ALL the relevant released versions. There is a long tail of legacy release tags from CVS, Fedora tags, various heads and more that we should likely exclude, going back 30 years and to the CVS days. See https://sourceware.org/git/?p=glibc.git;a=tags

@siddhesh

@siddhesh The meaning of these two tags is obvious:

Vulnerable-Commit: 973fe93a5675c42798b2161c6f29c01b0e243994 (pre-2.39)
Fix-Commit: ec6b95c3303c700eb89eebeda2d7264cc184a796 (2.39)

What about these other two?

Vulnerable-Backport: e09ee267c03e3150c2c9ba28625ab130705a485e (2.34)
Fix-Backport: 8006457ab7e1cd556b919f477348a96fe88f2e49 (2.34)

A search either leads to the glibc advisories or -- in a funny tautological way -- to this issue ;)

@harsh098

@harsh098 Please start a PR early, even if this is only for the parser. We cannot review code otherwise. That's the FOSS way! If anything that will help us understand any issues with the format.

And wrt. the Git tags and in general the glibc versions there are two ways to get versions:

Parse http://ftp.gnu.org/gnu/glibc/ as HTML. We have code in PurlDB to do this in https://github.com/search?q=repo%3AnexB%2Fpurldb href&type=code way too many places... we should have a shared function instead. An example is this https://github.com/nexB/purldb/blob/e1a20006b513a0379e69a69624da4e614a4f27dd/etc/scripts/utils_thirdparty.py#L1739 or OpenSSL releases https://github.com/nexB/purldb/blob/e1a20006b513a0379e69a69624da4e614a4f27dd/minecode/visitors/openssl.py#L38

Collect Git tags either from a clone. There is code in FetchCode for this. And also in PurlDB https://github.com/nexB/purldb/blob/e1a20006b513a0379e69a69624da4e614a4f27dd/packagedb/find_source_repo.py#L427 We should have only one way in FetchCode instead. It boils down to running https://git-scm.com/docs/git-ls-remote.html (or similar through a library call)

@keshav-space @TG1999 do you have some hints on which function/code to call for this?

Note that ideally glibc would expose a simple way to list ALL the relevant released versions. There is a long tail of legacy release tags from CVS, Fedora tags, various heads and more that we should likely exclude, going back 30 years and to the CVS days. See https://sourceware.org/git/?p=glibc.git;a=tags

@pombredanne
Turns out I need the output of
git describe --tags <commit-id>
to find the first tag that contains the commit

@harsh098

@harsh098 here is a simpler and more expressive snippet to parse the advisories in their current format:

glibc_advisory = """tunables: local privilege escalation through buffer overflow

If a tunable of the form NAME=NAME=VAL is passed in the environment of a
setuid program and NAME is valid, it may result in a buffer overflow,
which could be exploited to achieve escalated privileges.  This flaw was
introduced in glibc 2.34.

CVE-Id: CVE-2023-4911
Public-Date: 2023-10-03
Vulnerable-Commit: 2ed18c5b534d9e92fc006202a5af0df6b72e7aca (2.34)
Fix-Commit: 1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa (2.39)
Fix-Backport: dcc367f148bc92e7f3778a125f7a416b093964d9 (2.34)
Fix-Backport: c84018a05aec80f5ee6f682db0da1130b0196aef (2.35)
Fix-Backport: 22955ad85186ee05834e47e665056148ca07699c (2.36)
Fix-Backport: b4e23c75aea756b4bddc4abcf27a1c6dca8b6bd3 (2.37)
Fix-Backport: 750a45a783906a19591fb8ff6b7841470f1f5701 (2.38)
"""


in_description = True
description = ""
parsed = []

for line in glibc_advisory.splitlines(True):
    if line.startswith("CVE-Id:"):
        in_description = False
    if in_description:
        description += line
    else:
        line = line.strip()
        name, _, value = line.partition(": ")
        value = value.strip()
        if name.endswith(("Commit", "Backport",)):
             commit, _ , version = value.partition(" ")
             version = version.strip(")(")
             parsed.append({"name": name, "commit": commit, "version": version})
        else:
             parsed.append({"name": name, "value": value})

parsed.insert(0, {"name": "description", "value": description.strip()})

import json
print(json.dumps(parsed, indent=2))

yields:

[
  {
    "name": "description",
    "value": "tunables: local privilege escalation through buffer overflow\n\nIf a tunable of the form NAME=NAME=VAL is passed in the environment of a\nsetuid program and NAME is valid, it may result in a buffer overflow,\nwhich could be exploited to achieve escalated privileges.  This flaw was\nintroduced in glibc 2.34."
  },
  {
    "name": "CVE-Id",
    "value": "CVE-2023-4911"
  },
  {
    "name": "Public-Date",
    "value": "2023-10-03"
  },
  {
    "name": "Vulnerable-Commit",
    "commit": "2ed18c5b534d9e92fc006202a5af0df6b72e7aca",
    "version": "2.34"
  },
  {
    "name": "Fix-Commit",
    "commit": "1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa",
    "version": "2.39"
  },
  {
    "name": "Fix-Backport",
    "commit": "dcc367f148bc92e7f3778a125f7a416b093964d9",
    "version": "2.34"
  },
  {
    "name": "Fix-Backport",
    "commit": "c84018a05aec80f5ee6f682db0da1130b0196aef",
    "version": "2.35"
  },
  {
    "name": "Fix-Backport",
    "commit": "22955ad85186ee05834e47e665056148ca07699c",
    "version": "2.36"
  },
  {
    "name": "Fix-Backport",
    "commit": "b4e23c75aea756b4bddc4abcf27a1c6dca8b6bd3",
    "version": "2.37"
  },
  {
    "name": "Fix-Backport",
    "commit": "750a45a783906a19591fb8ff6b7841470f1f5701",
    "version": "2.38"
  }
]

The output could be less verbose though.

Or even simpler:

summary, _, tail = glibc_advisory.partition("\n\n")
description, _, metadata = tail.partition("\n\n")

parsed = [
    {"name": "summary", "value": summary},
    {"name": "description", "value": description}
]

for line in metadata.splitlines():
    name, _, value = line.partition(": ")
    if name.endswith(("Commit", "Backport",)):
        commit, _ , version = value.partition(" ")
        parsed.append({"name": name, "commit": commit, "version": version.strip(")(")})
    else:
        parsed.append({"name": name, "value": value})

Still simpler as a clean and clear one liner with a small modification of the format to make it a valid email header/message:

glibc_advisory = """Subject: tunables: local privilege escalation through buffer overflow
Description: If a tunable of the form NAME=NAME=VAL is passed in the environment of a
 setuid program and NAME is valid, it may result in a buffer overflow,
 which could be exploited to achieve escalated privileges.  This flaw was
 introduced in glibc 2.34.
CVE-Id: CVE-2023-4911
Public-Date: 2023-10-03
Vulnerable-Commit: 2ed18c5b534d9e92fc006202a5af0df6b72e7aca (2.34)
Fix-Commit: 1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa (2.39)
Fix-Backport: dcc367f148bc92e7f3778a125f7a416b093964d9 (2.34)
Fix-Backport: c84018a05aec80f5ee6f682db0da1130b0196aef (2.35)
Fix-Backport: 22955ad85186ee05834e47e665056148ca07699c (2.36)
Fix-Backport: b4e23c75aea756b4bddc4abcf27a1c6dca8b6bd3 (2.37)
Fix-Backport: 750a45a783906a19591fb8ff6b7841470f1f5701 (2.38)
"""

import email
import json

print(json.dumps(list(email.message_from_string(glibc_advisory).items()), indent=2))

And this #1362 (comment) yields this :

[
  [
    "Subject",
    "tunables: local privilege escalation through buffer overflow"
  ],
  [
    "Description",
    "If a tunable of the form NAME=NAME=VAL is passed in the environment of a\n setuid program and NAME is valid, it may result in a buffer overflow,\n which could be exploited to achieve escalated privileges.  This flaw was\n introduced in glibc 2.34."
  ],
  [
    "CVE-Id",
    "CVE-2023-4911"
  ],
  [
    "Public-Date",
    "2023-10-03"
  ],
  [
    "Vulnerable-Commit",
    "2ed18c5b534d9e92fc006202a5af0df6b72e7aca (2.34)"
  ],
  [
    "Fix-Commit",
    "1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa (2.39)"
  ],
  [
    "Fix-Backport",
    "dcc367f148bc92e7f3778a125f7a416b093964d9 (2.34)"
  ],
  [
    "Fix-Backport",
    "c84018a05aec80f5ee6f682db0da1130b0196aef (2.35)"
  ],
  [
    "Fix-Backport",
    "22955ad85186ee05834e47e665056148ca07699c (2.36)"
  ],
  [
    "Fix-Backport",
    "b4e23c75aea756b4bddc4abcf27a1c6dca8b6bd3 (2.37)"
  ],
  [
    "Fix-Backport",
    "750a45a783906a19591fb8ff6b7841470f1f5701 (2.38)"
  ]
]

FYI, we've been discussing the tags in the advisories and are considering a few changes, mainly simplifications. I'll report back once we have upstream consensus.

@pombredanne

Thanks @pombredanne let me repurpose the parser you provided.
So, I'm going ahead with the purl pkg:gnu/glibc@<version>?commit=commit-id

We have consensus, and now we also have a README that is hopefully useful :)

https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/README;hb=HEAD

TL;DR; we've dropped the *-Backport tags and instead quote a proper release number indicating changes that are on a release branch, as opposed to in pristine tarballs.

@siddhesh

@siddhesh Thanks! Eventually, once we have worked out the parsing here, we could extract this and contribute it to glibc, if this makes sense for you?

Resumed work on this today after my exam.
I have figured out parsing here.I'm working on converting it to advisories.
Trying to make a PR by EOD

when adding the affected packages in the AdvisoryData should I use the SemverVersion from univers package

@pombredanne

@pombredanne @siddhesh

I am having issues figuring out the vers string for pkg:gnu/glibc@<version> for example I need to specify that I want to add 2.34 to 2.39 into AffectedPackage() as affected_version_range and I cannot find the correct methods in univers package to accomplish this. Do I need to implement a new VersionRange for packages of type gnu.

As @siddhesh mentioned the link to the new format in this comment I can infer that the glibc is following a SemverVersion like scheme.

I have successfully parsed the advisory according to the new format now I am trying to convert to AdvisoryData and for that I need to populate the affected_packages field with objects of type List[AffectedPackage]

Please help!

@harsh098

@harsh098 try to collect all the versions of glibc and commit a test to check with univers if all versions are effectively Semver Version

@pombredanne

Hi @pombredanne, @siddhesh, @ziadhany and @TG1999
Pushing the first draft for Glibc Importer
Turns out the univers package did not have support for package type pkg:gnu in vers scheme so I have written my own in the importer itself.
Checkout PR:- #1414
Once you approve these changes.
I will make a PR for the same in univers also.
Sorry for the delay,
I was stuck in a medical emergency in my family.
Have a great weekend ahead !
Regards,
Harsh

@harsh098

The glibc advisories importer have been merged. Thank you, @harsh098, for your help with this PR.

see:

Add support for glib importer #2118

the pipeline logs:

INFO 2026-05-14 21:45:30.452136 UTC Pipeline [GlibcImporterPipeline] starting
INFO 2026-05-14 21:45:30.452276 UTC Step [clone] starting
INFO 2026-05-14 21:45:30.452344 UTC Cloning `git+https://sourceware.org/git/glibc.git`
Importing data using glibc_importer_v2
INFO 2026-05-14 21:46:18.047346 UTC Step [clone] completed in 48 seconds
INFO 2026-05-14 21:46:18.047512 UTC Step [collect_and_store_advisories] starting
INFO 2026-05-14 21:46:18.047955 UTC Collecting 31 advisories
INFO 2026-05-14 21:46:18.120026 UTC Progress: 12% (4/31) ETA: 1 seconds
INFO 2026-05-14 21:46:18.134280 UTC Progress: 22% (7/31)
INFO 2026-05-14 21:46:18.150432 UTC Progress: 32% (10/31)
INFO 2026-05-14 21:46:18.160768 UTC Progress: 45% (14/31)
INFO 2026-05-14 21:46:18.170555 UTC Progress: 58% (18/31)
INFO 2026-05-14 21:46:18.182313 UTC Progress: 70% (22/31)
INFO 2026-05-14 21:46:18.190760 UTC Progress: 80% (25/31)
INFO 2026-05-14 21:46:18.199737 UTC Progress: 90% (28/31)
INFO 2026-05-14 21:46:18.206309 UTC Successfully collected 30 advisories
INFO 2026-05-14 21:46:18.206401 UTC Step [collect_and_store_advisories] completed in 0 seconds
INFO 2026-05-14 21:46:18.206432 UTC Step [clean_downloads] starting
INFO 2026-05-14 21:46:18.206451 UTC Removing cloned repository
INFO 2026-05-14 21:46:18.373296 UTC Step [clean_downloads] completed in 0 seconds
INFO 2026-05-14 21:46:18.373422 UTC Pipeline completed in 48 seconds

Navigation Menu

Repository navigation

Add glibc advisories #1362

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add glibc advisories #1362

Description

Activity

harsh098 commented on Jan 5, 2024

pombredanne commented on Jan 6, 2024

pombredanne commented on Jan 6, 2024

harsh098 commented on Jan 6, 2024

siddhesh commented on Jan 8, 2024

harsh098 commented on Jan 10, 2024

harsh098 commented on Jan 10, 2024

pombredanne commented on Jan 10, 2024

pombredanne commented on Jan 10, 2024

harsh098 commented on Jan 10, 2024

harsh098 commented on Jan 10, 2024

pombredanne commented on Jan 11, 2024

pombredanne commented on Jan 11, 2024

harsh098 commented on Jan 11, 2024

13 remaining items

pombredanne commented on Jan 12, 2024

pombredanne commented on Jan 12, 2024

pombredanne commented on Jan 12, 2024

pombredanne commented on Jan 13, 2024

siddhesh commented on Jan 19, 2024

harsh098 commented on Jan 24, 2024

siddhesh commented on Jan 30, 2024

pombredanne commented on Jan 31, 2024

harsh098 commented on Jan 31, 2024

harsh098 commented on Jan 31, 2024

harsh098 commented on Feb 1, 2024

TG1999 commented on Feb 6, 2024

harsh098 commented on Feb 25, 2024

ziadhany commented on May 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions