YJL

I just realized I hadn't had iptables for real for four days and four hours. It happened after I updated iptables to the newest stable version 1.4.16.3 on Gentoo, officially released on 10/18/2012):

$ sudo genlop -lu | grep iptables | tail -3
     Tue May  8 08:51:55 2012 >>> net-firewall/iptables-1.4.13
     Mon Nov 26 01:46:33 2012 <<< net-firewall/iptables-1.4.13
     Mon Nov 26 01:46:39 2012 >>> net-firewall/iptables-1.4.16.3

Yesterday, I noticed there was an error or warning during booting, but I just assumed that's some net device was about to be brought up, didn't read the exact message. Today, I read it:

$ sudo /etc/init.d/iptables start
 * Loading iptables state and starting firewall ...
WARNING: The state match is obsolete. Use conntrack instead.
iptables-restore v1.4.16.3: state: option "--state" must be specified

Error occurred at line: 26
Try `iptables-restore -h' or 'iptables-restore --help' for more information.                                    [ !! ]
 * ERROR: iptables failed to start

Four days, four boots, should've paid more attention.

The problem line was like:

[52:3148] -A INPUT -s ###.###.###.### -p tcp -m state -m tcp --dport ### -j ACCEPT

After I remove six lines with -m state, the rules /var/lib/iptables/rules-save were loaded successfully. Don't know why I had those and didn't use to match state actually.

If you used state match, then you need to change it to be

-m conntrack --ctstate [STATELIST]

with kernel configuration NETFILTER_XT_MATCH_CONNTRACK. See man 8 iptables-extensions.

A couple of days ago, I started to see few threads about bluish issue on Arch Linux forums with Adobe Flash 11.2. I was still using 11.1 at the time. Earlier, 11.2 was marked as stable because of security vulnerability. So I deiced to upgrade and ignored potential the bluish issue. (I didn't read any threads on Arch Linux)

After upgraded and I had watched few videos, I have forgot those bluish issues, it didn't happen to me. Now, there is a first thread on Gentoo Fourms, now I know my computer isn't affected due to my ATI card, it seems about nVidia card and its vdpau. (By the way, I don't feel any H/W accelerated, my card is probably too old.)

If you google, you will see this bluish issue is happening over all distros, Fedora, Ubuntu, Arch Linux, etc. I read a few threads and I am not sure whose bug is, and I don't really care. Who would I?

Anyway, if you are nVidia user, then wait for update for driver or Xorg or Adobe, one of them should deliver the fix or already done.

Don't downgrade to 11.1 since this 11.2 contains security patch.

Meanwhile enjoy your free Blue Map Group performance. Wait, it's not even April 1st. Adobe you released it too quick. It's not an Intel ads, the Blue Map Group, you dumb xxx! xD

Sorry for you guys use nVidia card, I just can't help myself. Please don't hit me! ;p

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

Assuming this referrer is truly from Scansafe.


I don't know how this Scansafe works, are they trying (or their client) or have they blocked that page for some reason? If so, for what? And I can't find a way to check up on their website. By the way, their website has a big chuck Flash.

Because it is a referrer, therefore someone must be viewing that page and its URL is that looooooooooooooong. Only a few days ago, I posted about not so good URLs, Google Search's is long, but this Scansafe's is a real champion.

I have to mask portions of the screenshot, I didn't try to decrypt it, but someone maybe want to and they maybe own malicious websites, which certainly will be qualified dangerous website and whoever uses Scansafe will check out. It is like reverse-honeypot.

That cryptic long text may contain encrypted sensitive information or not, but I will guess it does not. You hardly will see URL mis-include sensitive information nowadays.

There is one more thing is strange, that is HTTP. I think HTTPS will not be sent in referrer header. I am not sure about this, never thought about this part, have to check the spec. or something. Anyway, Scansafe is a security product, then how come it is only a HTTP connection when a client needs to be ensured with the maximal security while they are using Scansafe website?

Of course, the stuff above is assuming the referrer is legitimate. What if it is not, it is bogus? Then the question is who sent that and why.

If it was sent by Scansafe for whatever testing or checking purpose, then they become bad bots; if it was sent by someone else, then what's the purpose to impersonate Scansafe? Which I don't have an answer for that.

Off-topic: What is a good way to block by specific Referrer on Blogger? Seems that JavaScript is the only way. But it is not real blocking, but masking content when certain referrer is matched.

The time has only passed 20% of March and GLSA has already had more issues than last month:


Sync your Portage tree and check with glsa-check -l to see if your system have holes. If it does, what are you waiting for? Update now and don't forget to subscribe to the feed of GLSA.

I just wanted to find a weather forecast information in plain text format, so I googled US navy for that. Then, I saw this:

So, there is no DoD certificate included in Gentoos ca-certificates package which is from Debians package. I checked those certificates (/usr/share/ca-certificates). I saw brasil.gov.br, gouv.fr, and Taiwan GRCA. Maybe some I could not recognize. Well, so, how would those get included but no US government? I am not sure if US government has own issuer, I tried White House, but the certificate is issued to Akaimai hence I got a wrong site warning message. I went to NSA, they has a valid certificate issued by Entrust. If you go to CIA through unsecured connection, you will be redirected to secured one, the certificate is issued by VeriSign.

I am just curious.

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 its time to get rid of it once for all.

Its fairly simple. Firstly, you need certutil tool from NSS package, if you dont 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.

I just read this security bulletin, it affects all systems:

Critical vulnerabilities have been identified in Adobe Flash Player version 10.0.32.18 and earlier. These vulnerabilities could cause the application to crash and could potentially allow an attacker to take control of the affected system.

It is classified as critical, so you don't need to think twice go upgrade right now.

PS. Including AIR.