1.12.17 pushed in core/updates_testing

Status: NEW => ASSIGNED
Assignee: bruno => qa-bugs

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

Updated golang packages fix security vulnerability:

An integer overflow vulnerability was found in the Go crypto/x509 and
golang.org/x/crypto/cryptobyte libraries on 32-bit architectures. A remote
attacker could exploit this by supplying a crafted x.509 certificate, or other
ASN.1 structure, as either a client or server to crash vulnerable Go
applications (CVE-2020-7919).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7919
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/S43VLYRURELDWX4D5RFOYBNFGO6CGBBC/
========================

Updated packages in core/updates_testing:
========================
golang-1.12.17-1.mga7
golang-docs-1.12.17-1.mga7
golang-misc-1.12.17-1.mga7
golang-tests-1.12.17-1.mga7
golang-src-1.12.17-1.mga7
golang-bin-1.12.17-1.mga7
golang-shared-1.12.17-1.mga7

from golang-1.12.17-1.mga7.src.rpm

Status comment: Fixed upstream in 1.12.16 => (none)
CC: (none) => bruno

mga7, x86_64

The vulnerability is reported for 32-bit architectures but there are no real 32-bit hardware systems here or any VMs.  No PoC available either.

Going ahead with 64-bits.
Updated the seven packages.
Decided to forego the HelloWorld compilation and perform a local build of docker which has always been recommended in the past.

$ rm -rf docker
$ mgarepo co -d 7 docker
$ cd docker
$ bm -ls
$ ls
BUILD/  BUILDROOT/  RPMS/  SOURCES/  SPECS/  SRPMS/
$ sudo urpmi --buildrequires SPECS/docker.spec
warning: Macro expanded in comment on line 40: %{shortcommit}

In order to satisfy the 'go-md2man' dependency, one of the following packages is needed:
 1- go-md2man-1.0.8-1.mga7.x86_64: Transform md into man pages (to install)
 2- golang-github-cpuguy83-go-md2man-1.0.8-1.mga7.x86_64: Process markdown into manpages (to install)
What is your choice? (1-2) 1
[...]
$ bm -l
[...]
+ exit 0
succeeded!

That should be enough for updates.  Hopefully somebody can do the same for 32-bits.  Using a VM should be OK as long as it has sufficient resources.
$ du -hs docker
520M	docker

CC: (none) => tarazed25
Whiteboard: (none) => MGA7-64-OK

Well, I tried. I fired up the steam boiler for Foolishness, my Dell Inspiron 5100 with the 32-bit P4, running a more or less stock Xfce, and gave it a shot.

I installed the seven packages and dependencies, and updated the seven. That much went fine. 

Then I had to install mgarepo and 61 dependencies, and try to use that. It seems I was absent the day we covered that material in class. I should have known there would be a test on it one day. It failed, of course, because I have no idea of how to configure it to work properly. Something about denied permissions(public key), and something else about SSH. All a mystery to me. I looked at the wiki, and just became more confused.

But, at least I got as far as a clean install of the packages in question on 32-bits. If that's enough, let me know. If not, please give me some guidance on how to proceed. I know we don't have much pure 32-bit hardware in QA, so I'll do what I can.

CC: (none) => andrewsfarm

Ah, sorry TJ, I forgot about the access business - thought that anybody with a Mageia id could do that.  I remember vaguely now that I had to copy the public key into one of the fields in the id page but there was something else as well involving a sysadmin - something about being given permission to do that.  That was at least two years ago so it is prehistory to me, beyond the event horizon.

:-((

You can switch it to anonymous SVN access in the mgarepo configuration file.

Thanks for the reminder David.  Had just discovered that when trying mgarepo on another workstation.
@TJ: That is /etc/mgarepo.conf, about seven lines down.

Thank you, Gentlemen. 

It's morning here right now, but I will look into it later today, once my brother and I have finished with our solitary family holiday festivities.

Progress, I suppose. I was able to get the source files, and cd to docker, but now I'm being told that the command "bm" is not being found. Doesn't matter if I'm using it as root or as a user. 

I must be missing yet another development package, or ten.

BTW, I performed the other commands as root, because I haven't activated "sudo" on this, or any, of my systems. Now that I think of it, most likely when I got to the command that uses it I could have just skipped it and I would have been asked for the password. Oh, well.

I should have known. The package I need to get the "bm" command is, of course, "bm."

Sigh.

So, after what seemed like an exceptionally long time, and lots of verbiage, I saw this:

Succeeded!

If that was good enough for a 64-bit OK, then it's good enough for 32-bits.

Validating. Advisory in Comment 2.

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: MGA7-64-OK => MGA7-64-OK MGA7-32-OK

Well done TJ.  Thanks for taking the trouble to follow this up.  I run this all as a user, not root, apart from installing the buildrequires stuff.  And I can imagine it might take a while on your equipment but it is good to see that steam-power can still cut it.  ;-)

$ du -hs *
356M	BUILD
4.0K	BUILDROOT
127M	RPMS
18M	SOURCES
2.9M	SPECS
18M	SRPMS

Hey, Foolishness and I were just doing our jobs.

Rest assured, I wouldn't have attempted this, especially as root, on one of my production systems, because for me it is uncharted territory. But the reason I rescued Foolishness from a church rummage sale was to act as a test machine, with there always being the risk of messing up the whole system. 

So, I am mentally prepared to do a complete re-install if needed, and I never, ever put something on its hard drive that I can't afford to lose. And as far as I can tell, Foolishness is OK with that. I think it appreciates the new lease on life.

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

https://advisories.mageia.org/MGASA-2020-0173.html

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