NO.

Mga5 is EOL since 31.12.2017, so stop wasting time on it

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX
CC: (none) => tmb

It's not a waste of time.  I'm still using it, as are many others.  Our infra is still using it, and this would be one that should probably still be fixed there too.  This is the easiest way to do that, as the work's all being done for you rather than all of it falling on the sysadmin team (which means falling by the wayside if we're being honest).  I'm limiting work on Mageia 5 to core packages that would impact infra or most users.  The QA team even was OK with still doing some work on it (for example, https://bugs.mageia.org/show_bug.cgi?id=22328#c10 ) which was even a surprise to me.  Fixes that require little effort don't hurt anything.  Also the QA team was already expecting a few select updates such as Firefox.  If you want to shut it down after the current batch gets through then fine, but it's not gonna hurt anything to do a few more that are queued up already.

Also note that when we initially agreed to extend the EOL, we also said we'd try to fix two important bugs (besides the important security issues that we could).  One was the KDM issue, which I fixed on December 31st.  The other was the applet upgrade issue, which we have still not fixed, Martin is still working on, and is one of the reasons we never turned the upgrade applet back on and one of the reasons we have still delayed the EOL announcement.

Well if QA thinks they dont have enough to do... I wont hold them back... I've re-opened mga5

Thanks Thomas.  Remember that one of the reasons I was doing this was to help you with the infrastructure.  :o)  I'll start a new thread on the QA list about how we will wind down Mageia 5.

Status: RESOLVED => REOPENED
Resolution: WONTFIX => (none)

Advisory:
========================

Updated glibc packages fix security vulnerabilities:

An issue in the code handling RPATHs was fixed that could have been
exploited by an attacker to execute code loaded from arbitrary
libraries (CVE-2017-16997).

A privilege escalation bug in the realpath() function when the getcwd()
system call doesn't return a valid absolute pathname (CVE-2018-1000001).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16997
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10000001
https://lists.opensuse.org/opensuse-updates/2018-01/msg00033.html
========================

Updated packages in core/updates_testing:
========================
glibc-2.20-27.mga5
glibc-devel-2.20-27.mga5
glibc-static-devel-2.20-27.mga5
glibc-profile-2.20-27.mga5
nscd-2.20-27.mga5
glibc-utils-2.20-27.mga5
glibc-i18ndata-2.20-27.mga5
glibc-doc-2.20-27.mga5

from glibc-2.20-27.mga5.src.rpm

Assignee: sysadmin-bugs => qa-bugs

Making a start on this for Mageia 5 :: x86_64.

Checking the CVEs before updating - gllibc seems important enough to warrant this.
Test for CVE-2017-16997
https://sourceware.org/bugzilla/show_bug.cgi?id=22625
The one-line command returned various errors which effectively aborted the test.
It looked like it needed to be run as root.
# ln -snf /dev/null libc.so.6 && rm -rf d && mkdir -m0700 d && cd d && echo 'int main(){}' |gcc -xc - -Wl,-rpath,'$ORIGIN' && chgrp -h apache a.out && chmod 02710 a.out && cd .. && d/a.out

Before update, should return:
d/a.out: error while loading shared libraries: libc.so.6: file too short

In fact the attempt to link libc to /dev/null failed - it was treated as an attempt to remove the library.  Found a way to run it by pasting it to a file and then setting the setuid bit on it.  No doubt there is a better way.
# chmod 02710 glibc_16997
# ll glibc*
-rwx--s--- 1 lcl lcl 186 Jan 22 02:09 glibc_16997*
# ./glibc_16997
d/a.out: error while loading shared libraries: libc.so.6: file too short

That is relatively simple but following the CVE trail turns up some very complex discussions so this is raincheck time.  An example can be found starting at https://www.suse.com/security/cve/CVE-2017-1000366/ leading to some kind of reproducer: https://bugzilla.suse.com/show_bug.cgi?id=1071319

To be continued...

CC: (none) => tarazed25

Ran the glibc updates, rebooted and tried the CVE 16997 test.

# ln -snf /dev/null libc.so.6 && rm -rf d && mkdir -m0700 d && cd d && echo 'int main(){}' |gcc -xc - -Wl,-rpath,'$ORIGIN' && chgrp -h apache a.out && chmod 02710 a.out && cd .. && d/a.out
#
which looks good, I think, since the program does nothing.

This is a clean update but how to test glibc?  Just run the compiler on something complex like a local build?  glibc-utils provides memusage, mtrace and xtrace.
Started a virtualbox session and 
$ memusage --progname=/usr/lib64/virtualbox/VirtualBox
No program name given
Tried the example from the man pages - source attached;
$ memusage --data=memusage.dat ./memorex
malloc: 400
realloc: 440
realloc: 1040
......................
Memory usage summary: heap total: 45200, heap peak: 6440, stack peak: 208
         total calls   total memory   failed calls
 malloc|          1            400              0
realloc|         40          44800              0  (nomove:40, dec:19, free:0)
 calloc|          0              0              0
   free|          1            440
Histogram for block sizes:
  192-207             1   2% ================
  400-415             3   7% ==================================================
................................................
6432-6447             1   2% ================

Soliciting comments on further tests....

Created attachment 9919 [details]
memusage example from man pages

$ gcc -o memorex memorex.c

Following M5/64

AFTER update only:
 glibc-2.20-27.mga5
 glibc-devel-2.20-27.mga5
 glibc-utils-2.20-27.mga5
and these are the utils programs:
- memusage - profile memory usage of a program (has man page)       
- memusagestat - generate graphic from memory profiling data (has man page)
Len has already persued these two OK; also the PoC.

- mtrace - interpret the malloc trace log (has man page)    [Forget].
- pcprofiledump - Dump information generated by PC profiling ?
- xtrace - Usage: xtrace [OPTION]... PROGRAM [PROGRAMOPTION]
All my attempts to use this:
 $ or # <program>
failed: "executable `<program>' not found"
Better was:
 $ xtrace /usr/bin/ls
Function              File                                                  Line
--------------------------------------------------------------------------------
Failed to parse arguments: Opsiwn anhysbys -c
^C
= unknown option -c ; for any program.

I shall use the system & only report back *if* problem noted. Default is OK.

CC: (none) => lewyssmith

I think we can pass this one along and watch for any reported regressions from other users.

Whiteboard: (none) => MGA5-64-OK

I had this update running for most of today on mga5-64 and, in a VM, on mga5-32.

I didn't use it a lot, but I did test a number of commonly used applications, including firefox and LO. 

I saw no problems on either arch.

CC: (none) => jim

Installed this into a 32-bit mga5 KDE4 system on real hardware. 

I did not attempt to test the CVE, but I did run several apps after the update, and saw no issues. 

I considered adding the 32-bit OK, but glibc is important enough that it should probably see more tests on other systems.

CC: (none) => andrewsfarm

@Thomas Andrews re comment 13 and James Kerr comment 12.  Thanks for doing those 32-bit tests.  And yes, glibc is pretty fundamental.
$ urpmq --whatrequires-recursive glibc | sort -u | wc -l    
31778

I would guess that variety of hardware is not important but a spread of software may be.  It has been pointed out that Cauldron has given it a fair hammering so if nobody comes up with a problem in the next couple of days I am going to validate it.

M5/64
Having lived briefly with this update, it is OK for me. Second the x64 OK.

CC: lewyssmith => (none)

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0098.html

Resolution: (none) => FIXED
Status: REOPENED => RESOLVED