Skip to content

Proposing nagvis full version backport if someone is interested

Not personally interested in pursuing this (since I have no capacity to test nagvis), but reporting here as suggested in case anyone is interested (and for others to comment if they agree that a full version backport is reasonable). The background is that I've today spent some time to look into backporting individual patches and came to the conclusion that cherry-picking is probably not worthwhile.

Filling out below form to my best ability, please edit as you see fit.

Metadata

  • package: nagvis
  • releases: (bookworm), bullseye, ...
  • status in ELTS releases

Current State

There are several CVE's that need addressing for bullseye (and also some for bookworm).

The upstream releases seems to be more or less full of security fixes, apart from version bumps, .gitignore additions and ChangeLog text file additions. (Please verify exactly which changes would not be considered security-relevant. This is just from my overall glancing through git log.)

Obstacles Preventing Single Patch Backporting

Backporting individual patches is likely possible, but the main problem is that it is unclear which commit fixes a specific CVE (since there are several commits on the same topic in different parts of the code fixing things that sounds to all address what is described in the security disclosures). Also why only fix some XSS and not others? Why not take fixes for problems that has no CVE?

In other words, what's the point of creating something which deviates and has less testing and potentially introduces breakage and leaves resolved security problems open (only because they don't yet have a CVE id)?

Alternative Courses of Action

(Describe what alternative courses of action have been considered.)

Is it possible to ignore a certain number of CVEs and continue doing single patch backports? Please give details about why a particular alternative is or is not feasible/preferred.)

Potential Impacts

It needs to be verified that the new upstream release does not (unintentionally?) break compatibility with external components it the targeted distribution (eg. PHP version in bullseye).

Impacts of taking no action

  • Popcon is below 100 and peaked at 180, which I consider low.
  • Hopefully users run this together with nagios on systems that are not exposed to untrusted network access, since it's a monitoring tool (IMHO for internal usage).

Impacts of alternative course(s) of action

(Describe the impacts of the alternative courses of action which have been proposed or which have been considered and ruled out.)

Additional impacts

(Describe possible impacts which may reach beyond this specific package, such as with dependencies, reverse dependencies, third party applications, applications which users may have developed or deployed against this package, etc.)

Backport checklist

  • The backport successfully builds on all the supported architectures.
  • The backport has been fully tested. Please describe how.
  • It has been possible to verify the addressed vulnerabilities are exploitable in the current version.
  • It has been possible to verify the addressed vulnerabilities are fixed by the backport. - [ ] The reverse dependencies work well with the proposed backport. Please list the reverse dependencies that you have tested.

Source debdiff against the version being backported

(Please provide the debdiff between the original and the backported versions. In general, this means the version in the newer release and the backport being proposed for the target release.)

Binary debdiff against the current package in the target release

(Please provide the binary debdiff between the current and the backported package in the target release.)