Needs testing - gnome-rr.c: Migrate from g_memdup() go g_memdup2()

[ItzSwirlz]

Virtually no difference between the functions except for
byte_size becoming a gsize.

This is a measure to mitigate integer overflows.

See:
https://docs.gtk.org/glib/func.memdup2.html
https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-now/5538

---

I still need to test this, don't accept yet

[Fantu]

this need also dump version of libglib2.0-dev in d/control: libglib2.0-dev (>= 2.68)
but I suppose this change will be accepted only after lmde6 because bullseye have 2.66.8
there was a security issue related to g_memdup (CVE 2021-27219), have it solved but not don't have g_memdup2 in symbols so seems this function was not backported in older version

[ItzSwirlz]

Yeah. That's why LMDE is failing. We can do a version check (for a few lines is pointless) or backport libglib. Personally I would leave this aside and, @Fantu should we put this patch in Debian?

[Fantu]

the security issue (https://security-tracker.debian.org/tracker/CVE-2021-27219) is already solved in debian so is not urgent apply this FWIK and we can wait do be applied upstream first
remember to add the missed glib version dump in d/control and meson.build in this PR

edit:
from note I saw:
Fix backport in 2.66.7 adds 'g_memdup2' for internal use but does not allow fixing reverse-dependencies using vulnerable 'g_memdup'
so seems that glib security fix solved only internal use, I did another fast search but I not understand how is urgent replace it in software using g_memdup
complete the patch and probably we will apply it to the next 5.4 build for debian experimental

about other components cjs resolved it in latest rebase, muffin big rebase was on older version from Focal and still use g_memdup, mutter replaced it 1 year ago https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1708
other components need to be checked

[clefebvre]

Hi,

We no longer need to support LMDE 5.

On our side it's OK to depend on libglib2.0-dev (>= 2.68).