YJL

About a few days ago:

~ $ glsa-check -d 201203-19 | head -12
            GLSA 201203-19: 
Chromium: Multiple vulnerabilities             
============================================================================
Synopsis:          Multiple vulnerabilities have been reported in Chromium,
                   some of which may allow execution of arbitrary code.
Announced on:      March 25, 2012
Last revised on:   March 25, 2012 : 01

Affected package:  www-client/chromium
Affected archs:    All
Vulnerable:        <17.0.963.83
Unaffected:        >=17.0.963.83

I noticed this GLSA issue, but I held up until I finally decided to upgrade Chromium, I don't really use Chromium (or V8).

~ $ sudo genlop -lu | egrep '(chromium|v8)' | tail -4
     Wed Mar 28 03:17:23 2012 <<< dev-lang/v8-3.7.12.20
     Wed Mar 28 03:17:24 2012 >>> dev-lang/v8-3.7.12.29
     Wed Mar 28 05:10:52 2012 <<< www-client/chromium-17.0.963.56
     Wed Mar 28 05:12:07 2012 >>> www-client/chromium-17.0.963.83

Just right now:

~ $ glsa-check -d 201203-24 | head -18
          GLSA 201203-24: 
Chromium, V8: Multiple vulnerabilities           
============================================================================
Synopsis:          Multiple vulnerabilities have been reported in Chromium
                   and V8, some of which may allow execution of arbitrary
                   code.
Announced on:      March 30, 2012
Last revised on:   March 30, 2012 : 01

Affected package:  dev-lang/v8
Affected archs:    All
Vulnerable:        <3.8.9.16
Unaffected:        >=3.8.9.16

Affected package:  www-client/chromium
Affected archs:    All
Vulnerable:        <18.0.1025.142
Unaffected:        >=18.0.1025.142

I said "Oh, come on!"

~ $ sudo genlop -t -S '(chromium|v8)' | tail -6
     Wed Mar 28 03:17:24 2012 >>> dev-lang/v8v8
       merge time: 4 minutes and 44 seconds.

     Wed Mar 28 05:12:07 2012 >>> www-client/chromiumchromium
       merge time: 1 hour, 54 minutes and 43 seconds.

(I think I found a bug with -S in genlop, see the repeating package name?)

Only Chromium uses v8 and I don't run JavaScript scripts outside of browsers. I think I am going to unmerge Chromium.

If you primarily are a Chromium user, enjoy the merging! ;p

My first and extremely silly Chrome Extension, Keep Last Two Tabs, has 1,007 users!



Even though I don't use Chromium anymore, I still feel happy about it. It was firstly released on 2009-12-19, eight months later, it finally passed the 1,000 milestone.

I am using Firefox 64-bit beta 5 prerelease nightly build, it works well on my Gentoo. And Vimperator also works, well, from the repository, of course. I have to edit the install.rdf because it only sets up up to beta 4. I bumped the version and built the xpi, it works great!

Almost all addons are not compatible with beta 5, AdBlock is the only one has an update for beta 5 prerelease, but I disabled it later. The reason I don’t want to use AdBlock is same as I have with Chrome. The speed has been improved, though it is still slower than Chrome.

I think I should get some numbers, so I tested it with first website I could find from search.

Before I show you the results, I must tell you that I just wanted to get a rough idea about how fast they could execute JavaScript, I didn’t try to make sure my system is all ready for the benchmark test to run. I had some programs running behind but they were not heavy tasks. Firefox 3.6.8 (8 addons) and Chromium (2 extensions) have some addons installed, but I don’t think it would make big difference if I disable them.

Now, here is the chart and numbers:

Browser	Total
Chromium 6.0.490.1	0447.4ms +/- 12.3%
Opera 10.61	0480.8ms +/- 01.4%
Firefox 4.0b5pre	0719.4ms +/- 01.9%
Firefox 3.6.8	1255.8ms +/- 01.2%

From the results, Fireforx 4.0b5pre is about 60.8% slower, but a benchmark is an intense test in different special cases. The real use might not result in such difference. When I just fired it up, I immediately felt the performance improved and I couldn’t real tell if it’s faster or slower than Chromium. The memory usage also seems improved, though I haven’t used it thoroughly.

Vimperator is always something very important addon for me, I even tried to create a similar way to open bookmark in Chromium. Since it’s already in beta stage and stable enough for me, so I think I should probably go back to Firefox and Vimperator. Hope the future release could have more performance improvement. UI improvement is really useless to me since I use Vimperator.

A few hours ago, Gmail announced a new video and chat plugin for Linux users. I am a 64-bit user, pure one, there is no 32-bit library on my system. I wasn’t going to try because 1) I am not into online IM chatting not to mention this voice and video chatting and 2) I don’t believe that Google would release a 64-bit stuff.

But you know curiosity killed the cat, so I went to download, just to file to find out if they are 64-bit build or just 32-bit as my expectation. I ran

ar -x google-talkplugin_current_amd64.deb
tar xf data.tar.gz
cd opt/google/talkplugin

Now, it’s about to see the truth:

% file * */*
GoogleTalkPlugin:         ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
cron:                     directory
lib:                      directory
libnpgoogletalk64.so:     ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
libnpgtpo3dautoplugin.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
cron/google-talkplugin:   POSIX shell script text executable
lib/libCg.so:             ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
lib/libCgGL.so:           ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped</pre>

(Side note: you can see there is a cron, Google installs a cron job to update .deb package, so this plugin would never get outdated. I really can not agree with this automatic method. (I assume that it’s automatic, I didn’t read that script))

I was shocked, twice! First shock was there did have 64-bit shared library and the second shock was why the hell this GoogleTalkPlugin is a 32-bit build? I couldn’t understand. As far as I know, the browser plugin uses shared library, so that 32-bit stuff shouldn’t be a problem, it must be some kind of desktop manager for the plugin, it’s worth trying. (I was wrong. :()

So, I tried to install it:

chmod +x *.so lib/*.so
cp *.so ~/.mozilla/plugins/
sudo cp lib/* /usr/lib64/

I installed them in Mozilla’s (Firefox’s) plugin directory, so Chromium can also use it. After restarted browser, I got a good sign from Chromium and Firefox.

So, I recompiled my kernel with required modules. Rebooted, got into Gmail in Chromium, went to setting. Nothing!? Switched to Firefox, still nothing.

Then, I ran Chromium from command-line, I got this log:

[000:017] Warning(clientchannel.cc:583): Unreadable or no port file.  Could not initiate GoogleTalkPlugin connection
[000:022] Warning(clientchannel.cc:439): Could not initiate GoogleTalkPlugin connection
[000:022] Warning(optionsfile.cc:22): Load: Could not open file
[000:022] Warning(clientchannel.cc:553): Failed to get GoogleTalkPlugin path. Trying default.
[000:025] Started GoogleTalkPlugin, path=/opt/google/talkplugin/GoogleTalkPlugin
[000:025] Waiting for GoogleTalkPlugin to start...
[001:098] Warning(clientchannel.cc:583): Unreadable or no port file.  Could not initiate GoogleTalkPlugin connection
[001:099] Warning(clientchannel.cc:439): Could not initiate GoogleTalkPlugin connection
[001:099] Waiting for GoogleTalkPlugin to start...
[002:190] Warning(clientchannel.cc:583): Unreadable or no port file.  Could not initiate GoogleTalkPlugin connection
[002:191] Warning(clientchannel.cc:439): Could not initiate GoogleTalkPlugin connection
[002:191] Waiting for GoogleTalkPlugin to start...

I could only say “!@#$%^, Google!”

If your system is multilib, I think you have good chance to get it running, just move that 32-bit stuff to /opt/google/talkplugin/GoogleTalkPlugin.

Google, please re-build GoogleTalkPlugin for 64-bit! Pretty please?

Few days ago (2010-07-16), Arch Linux Forums started to redirect unencrypted connection to encrypted connection, in other words, it is now SSL connection only.

My current web browser is Chromium and it told me CAcert.org is not trusted, the certificate issuer that Arch Linux Forums uses. It only takes one click for a browsing session to get rid of that message. Before this, I sometimes stumbled upon Gentoo Bugs redirected via Gentoo Packages.

I am not actually a reader of Arch Linux Forums, but I read it regularly. So it’s time to get rid of it once for all.

It’s fairly simple. Firstly, you need certutil tool from NSS package, if you don’t have then add the following line to your /etc/portage/packages.use:

dev-libs/nss utils

Re-emerge NSS. Next step is to add the root certificate:

certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n cacert -i /etc/ssl/certs/cacert.org.pem

Then check if we add successfully with:

% certutil -d sql:$HOME/.pki/nssdb -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

cacert                                                       C,,

Restart browser and say hello to that little green lock.

The steps are actually from this Chromium wiki page

Note that the root certificate /etc/ssl/certs/cacert.org.pem is a symbolic link to /usr/share/ca-certificates/cacert.org/cacert.org.crt, which is a file part of ca-certificates package and your Gentoo system should already have it because OpenSSL depends on it and openssl is unlikely not installed.