I have made new packages for the chromium browser and its widevine plugin. Chromium version 44 was released a bit earlier this week, and it took me a while to compile, because the new OpenJDK 7u85 and LibreOffice 5.0.0.rc3 packages were ahead of it in the build queue. Guess what… now that I am writing this blog article after uploading the packages for chromium-44.0.2403.89, I notice that there was a second release of Chromium 44 Stable… today. Which makes me wonder if there was a regression in the earlier source release.
That updated version 44.0.2403.107 may have to wait, because I will be unable to do a lot of Slackware related stuff until august; real life is catching up with me. If there are real useability issues with 44.0.2403.89, let me know and I will see if I can shift priorities or make the older 43.x packages available again. My initial (not exhaustive) testing showed no weirdness at least.
Regardless, it took a few iterations before I got the Widevine CDM adapter to compile properly. I had to look at my chromium-dev package’s history to remember what had changed in version 44. Once I applied that knowledge to the stable sources, it all began to come together. Netflix still works 🙂 … well, after you’ve installed/upgraded my chromium-widevine-plugin package of course. which contains the proprietary Content Decryption Module.
The new chromium source I compiled into a package, comes with several security fixes, and here are the CVE’s:
[$3000] High CVE-2015-1271: Heap-buffer-overflow in pdfium. Credit to cloudfuzzer.
[$2000] High CVE-2015-1284: Use-after-free in blink. Credit to Atte Kettunen of OUSPG.
[$1337] Medium CVE-2015-1287: SOP bypass with CSS. Credit to filedescriptor.
[$1000] Medium CVE-2015-1270: Uninitialized memory read in ICU. Credit to Atte Kettunen of OUSPG.
[$500] Low CVE-2015-1288: Spell checking dictionaries fetched over HTTP. Credit to firstname.lastname@example.org
 CVE-2015-1289: Various fixes from internal audits, fuzzing and other initiatives.
Get my chromium packages in one of the usual locations:
- http://slackware.com/~alien/slackbuilds/chromium/ (primary server)
- http://taper.alienbase.nl/mirrors/people/alien/slackbuilds/chromium/ (my own US mirror)
- http://alien.slackbook.org/slackbuilds/chromium/ (US)
- http://slackware.org.uk/people/alien/slackbuilds/chromium/ (UK)
Change the URL a bit to get the chromium-widevine-plugin package.
Have fun! Eric
Is this why they had the second release?
Since upgrading to Chromium 44.0.2403.89 I can’t load any Web page, not even chrome://settings; all I get is “Aw, snap”. Every other update until now has gone well. I tried reinstalling, to no avail. Any ideas? Thanks.
Ryan, well, the Chromium developers apparently tried to make the world a bit more secure by forcing HTTPS where possible. That article you link to, shows an “Update 4: The problem appears to lie more with faulty plugin coding than anything else”, so it’s more like a two-way issue.
When I tested the new package against my own WordPress blog, I did not have any issues.
Nevertheless, I am temporarily re-adding the older v43 chromium package for those who need it.
Richard, no idea.
Pingback: Links 25/7/2015: Plasma Mobile, Linux Mint 17.2 OEM | Techrights
I have uploaded packages for the new Chromium version 44.0.2403.107 now.
Thanks, Eric. Downgrading to version 43.0.2357.132 makes Chromium functional for me. I’ll start troubleshooting with 44.0.2403.107. BTW, I’m running Slackware 14.1 stable.
Thanks for your work Eric.
In both 44 versions I think there are bugs in displaying the status of an SSL certificate that the website is using. For example, on https://slack.com I see the HTTPS part crossed and in red, but I can navigate the website (usually this situation would raise an exception leading the user to go back to a safer place). I don’t know if I’m the only one with this issue.
Other things are totally ok, instead.
I confirm the issue, same certificates on Windows (same version of Chrome) are totally right.
I wonder why you use number of NUMJOBS= because ninja already reads sets up jobs. That’s one of the wonderful things about ninja. Unless you want it to do less jobs.
Just wondering. I have tested this on my 8 core and 4 core machines. Ninja will except the -j flag but the wonderful thing about the small build system it reads your resources and set things up that way.
Anyway keep up the great work Eric love your work.
Indeed I can remove that NUMJOBS statement.
The last two versions of Chromium you have posted have returned the following error,
[2897:2897:0823/183243:ERROR:shared_memory_posix.cc(255)] Creating shared memory in /dev/shm/.org.chromium.Chromium.o7ZPSv failed: Permission denied
[2897:2897:0823/183243:ERROR:shared_memory_posix.cc(258)] Unable to access(W_OK|X_OK) /dev/shm: Permission denied
[2897:2897:0823/183243:FATAL:shared_memory_posix.cc(260)] This is frequently caused by incorrect permissions on /dev/shm. Try ‘sudo chmod 1777 /dev/shm’ to fix.
bash-4.3$ libva info: VA-API version 0.37.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: va_openDriver() returns -1
[2931:2931:0823/183243:FATAL:sandbox_seccomp_bpf_linux.cc(203)] Check failed: policy->PreSandboxHook().”
I’ve done as direct, that is change the permissions, and then it works, but when I’ve finished the session,
that is, close the browser, I cannot disconnect from ISP.
Regardless, I only use it to view Netflix, as I prefer not to install anything from google on my computer.
cwizardone, your box is fundamentally not healthy, looking back at all those reports in the past.
Does your fstab have this line:
tmpfs /dev/shm tmpfs defaults 0 0
And does your shared memory device look like this:
# ls -al /dev/ |grep shm
drwxrwxrwt 2 root root 40 Aug 21 03:47 shm/
It is a fresh install as of 8 August and up to date with the latest -current.
As to the fstab, no, it does not have the tmpfs line.
and, ls -al /dev/ |grep shm
drwxr-xr-x 2 root root 40 Aug 23 22:40 shm/
cwizardone, so try what happens if you re-add the missing tmpfs line and reboot.
That did it. Thanks!
It’s been a while… I finally found that I can run Chromium 45.0.2454.93 by starting it with –disable-seccomp-filter-sandbox, or simply –disable-sandbox. I can also run it if I compile the kernel with CONFIG_COMPAT_VDSO=n, but that prevents me from running KDE with OpenGL support, which disables all of the eye candy. Otherwise, it’s all “Aw, snap!”.
I submitted the following bug report to http://www.chromium.org but it probably should be entered here too.
Thanks and I hope you’ve had a Merry Christmas.
Summary: Chromium 47.0.2526.73 Install Starts but with Stack Dump
Chrome Version : Slackware64 package chromium-47.0.2526.73-x86_64-1alien.txz
URLs (if applicable) : N/A
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
What steps will reproduce the problem?
1. sbopkg install chromium
What is the expected result?
Chrome browser start without errors
What happens instead?
Three package installs were successful, resulting in:
Package chromium-47.0.2526.73-x86_64-1alien.txz installed.
Package chromium-pepperflash-plugin-188.8.131.52-x86_64-1alien.txz installed.
Package chromium-widevine-plugin-47.0.2526.73-x86_64-1alien.txz installed.
The browser starts, and appears to be functional, but with the following stack dump:
[22727:22727:1226/143203:FATAL:sandbox_seccomp_bpf_linux.cc(203)] Check failed: policy->PreSandboxHook().
#10 0x7fe418c59d05 __libc_start_main
Received signal 6
#3 0x7fe418c6e979 __GI_raise
#4 0x7fe418c70088 __GI_abort
#15 0x7fe418c59d05 __libc_start_main
r8: 6637783020313123 r9: 3661363230323465 r10: 0000000000000008 r11: 0000000000000202
r12: 00007fff8f272368 r13: 0000000000000000 r14: 00007fff8f271f00 r15: 000000000000005d
di: 00000000000058c7 si: 00000000000058c7 bp: 00007fe41981b3e0 bx: 00007fff8f272360
dx: 0000000000000006 ax: 0000000000000000 cx: ffffffffffffffff sp: 00007fff8f271b78
ip: 00007fe418c6e979 efl: 0000000000000202 cgf: 0000000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Please provide any additional information below. Attach a screenshot if
A search for ‘Chromium stack dump’ in existing issues did not report any pertinent hits.
Looking at a similar bug reported for the Debian package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803319 perhaps the conclusion should be that I have to stop applying the hardware rendering support (vaapi) patch, just like debian has done starting with their 47.0.2526.80-1 package.
I was looking at new packages for chromium and chromium-dev anyway, so what I will probably do is keep my “chromium_vaapi.patch” patch available in the source directory but without applying it.
I just had this problem again (last time I just reinstalled a fresh custom), and reading some threads on LQ, the conclusion is, I have to uninstall udev, if you are using current, udev wasn’t uninstalled, and it has to be uninstalled after eudev was installed (or before)
I’ll just leave this comment for future references.
PD. this comment,is about the /dev/shm and having to give the 1777 permission everytime after booting.
Good remark, p431i7o.
Thanks for the post. I hope others realize that information like this and resolutions of ‘cold cases’ actually can be the missing link to a long standing problem or rapid help for newbies. So many times google searches turn up ruminations of a problem with no solution.