More information about this security flaw is available in the following bug: http://bugzilla.redhat.com/show_bug.cgi?id=2242803 Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
Use the following template to for the 'fedpkg update' request to submit an update for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. ===== # bugfix, security, enhancement, newpackage (required) type=security # low, medium, high, urgent (required) severity=high # testing, stable request=testing # Bug numbers: 1234,9876 bugs=2242803,2243250 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False ====== Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new
To the best of my knowledge, Google has not commented on whether or not grpc is affected by CVE-2023-44487. The entry https://nvd.nist.gov/vuln/detail/CVE-2023-44487 has a link to https://github.com/grpc/grpc-go/pull/6703, but that upstream corresponds to the golang-google-grpc package in Fedora, not to the grpc package against which this bug is filed. I will follow up in this bug if I learn anything else about whether it is valid.
If this bug was filed based purely on the existence of a golang implementation of grpc, it should be reassigned to the golang-google-grpc component.
It looks like there were changes in grpc related to this CVE in https://github.com/grpc/grpc/pull/34763, planned for release in 1.59.2. As for bug 2214466, bug 2214474, and bug 2231222, upgrading to versions of grpc after 1.48.x is blocked by the need to transition system-wide to protobuf v4 (releases 22.x, 23.x, etc.). Quite a bit of work has been done, but very many dependent packages are affected, and so far nobody has had time to drive that update to completion, including all the necessary work to make dependent packages compatible[2]. In short, I’m happy to fix this by upgrading grpc, but I will not be able to do that in stable releases, and I will not be able to do it in development releases until the protobuf 4 work is done – which I have been helping with when I have a chance, but do not have time to drive to timely completion. Furthermore, the changes required look too nontrivial, and the modified code has diverged too much from the currently-packaged release, for a backport to be practical.