A security issue in libosinfo has been announced on July 8: https://www.openwall.com/lists/oss-security/2019/07/08/3 https://bugzilla.redhat.com/show_bug.cgi?id=1727766 I'm not sure how far back it's affected, but the package does also exist in Mageia 6. There's already a fix in Cauldron.
RedHat has issued an advisory for this on November 5: https://access.redhat.com/errata/RHSA-2019:3387
SUSE has issued an advisory for this on September 3: http://lists.suse.com/pipermail/sle-security-updates/2019-September/005876.html
RedHat has issued an advisory for this today (March 31): https://access.redhat.com/errata/RHSA-2020:1051 So that's libosinfo 1.1.0 and 1.5.0 they've patched and we have 1.4.0.
updated to version 1.5.0 libosinfo-1.5.0-1.mga7
Assignee: thierry.vignaud => qa-bugsCC: (none) => mageia
1.5.0 doesn't fix the issue. You can see RedHat's patches here: https://git.centos.org/rpms/libosinfo/tree/c8
Assignee: qa-bugs => mageiaCC: (none) => qa-bugs
i know :) but 0008-CVE-2019-13313.patch is on the rpm ;)
Assignee: mageia => qa-bugs
Ahh, silently added in December. It corresponds to RedHat's last two patches. We should at least add their first two (null dereference and accessing freed memory) if not the first three.
CC: qa-bugs => (none)
When I try to install I get:Sorry, the following package cannot be selected: - libosinfo-1.5.0-1.mga7.x86_64 (due to unsatisfied libosinfo-1.0.so.0(LIBOSINFO_1.5.0)(64bit))
CC: (none) => herman.viaene
rebuild + install locally OK src: - libosinfo-1.5.0-1.mga7
(In reply to David Walser from comment #7) > Ahh, silently added in December. It corresponds to RedHat's last two > patches. We should at least add their first two (null dereference and > accessing freed memory) if not the first three. How about this?
Assignee: qa-bugs => mageia
i see that distributions like fedora have updated stable to at least 1.7.1. Maybe we can do as the major is the same ( no rebuild needed ). I propose to update like in mga8 to 1.9.0
Updated to 1.8.0: libosinfo-1.8.0-1.mga7 libosinfo1.0_0-1.8.0-1.mga7 libosinfo1.0-devel-1.8.0-1.mga7 libosinfo-vala-1.8.0-1.mga7 libosinfo-gir1.0-1.8.0-1.mga7 from libosinfo-1.8.0-1.mga7.src.rpm References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13313 https://access.redhat.com/errata/RHSA-2019:3387 https://access.redhat.com/errata/RHBA-2020:4758
Assignee: mageia => qa-bugsCC: qa-bugs => (none)
Advisory: ======================== Updated libosinfo packages fix security vulnerability: A flaw was found in libosinfo, version 1.5.0, where the script for automated guest installations, 'osinfo-install-script', accepts user and admin passwords via command line arguments. This could allow guest passwords to leak to other system users via a process listing (CVE-2019-13313). The libosinfo package has been updated to version 1.8.0, fixing this issue and other bugs. References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13313 https://access.redhat.com/errata/RHSA-2019:3387 https://access.redhat.com/errata/RHBA-2020:4758
MGA7-64 Plasma on Lenovo B50 No installation issues. At CLI # osinfo-detect Usage: osinfo-detect [OPTION…] - Detect if media is bootable and the relevant OS and distribution. Help Options: -h, --help Show help options Application Options: -f, --format=plain. Output format. Default: plain -t, --type=media|tree. The type to be used. Default: media I cann't get my head around with this all is for or really means. If the higher powers esteem thsi can be released on clean install, then go ahead.
Best test is to try something that uses this library, like gnome-boxes or tracker-miners. Testing binaries shipped with a library is usually not a valid test.
When the library has been upgraded, I mean. If it's just patched then that's also valid.
Hmmmm, tracker-miners seems to be a set of 4 services, not sure what to expect. installed gnome-boxes which draws in 92 other packages, and then when I launch it, it gives: Oops, something went wrong, gnome-boxes cannot access the virtualization background. I give up.
Oops indeed! Maybe try virt-v2v, which says it can convert between different VM types.
And if you can't get that to work, then yes just pass it on a clean upgrade. It should be fine.
I don't have virtual machines on this laptop, too meager for that, so clean install it is.
Whiteboard: (none) => MGA7-64-OK
A valiant effort, Herman. Validating. Advisory in Comment 13.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0325.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED