handyfloss

I have just read a rather interesting article in Science about the economics of information security (R. Anderson and T. Moore, Science, 2006, 314, 610), and I would like to comment some quotes of it:

There has been a vigorous debate between software vendors and security researchers over whether actively seeking and disclosing vulnerabilities is socially desirable. Rescorla has argued that for software with many latent vulnerabilities (e.g. Windows), removing one bug makes little difference to the likelihood of an attacker finding another one later[1].

Quite interesting! First, even a paper on Science not only regards Windows as a piece of software with a virtually endless reservoir of internal errors, but it even uses it as a paradigmatic example of such a case. Second, it deems such software as not worth patching, and bugs not worth being disclosed (security through obscurity), because they are so many.

[…] [Rescorla] argued against disclosure and frequent patching unless the same vulnerabilities are likely to be rediscovered later. Ozment found that for FreeBSD[2] […] vulnerabilities are indeed likely to be rediscovered[3]. Ozment and Schecher also found that the rate at which unique vulnerabilities were disclosed for the core and unchanged FreeBSD operating system has decreased over a 6-year period[4]. These findings suggest that vulnerability disclosure can improve system security over the long term.

I have read [1] and [3] very briefly, and Ozment seems very critical of Rescorla’s results. However, the comparison between Windows and FreeBSD (I think they mean OpenBSD), which is FLOSS, is quite nice. Windows is so buggy that patching it is hopeless. FreeBSD has seen a decline in the number of disclosed bugs (remember that, being FLOSS, all the bugs found by developers, mantainers and users are disclosed), related to the fact that each bug fixed actually means a reduced probability of finding new bugs (because the total is not endless).

The bottom line is that, for a good piece of software (one that is not so bug-ridden that crackers never “rediscover” an old bug, because there are sooo many new ones to discover), disclosing the bugs is better. It is so because it speeds the patching rate, which in turn reduces the amount of exploitable bugs, which in turn improves the security. The connection between patching bugs and reducing significantly the amount of exploitable bugs can be made when the amount of bugs is small enough that new crackers are likely to rediscover old bugs, and then it would have paid to patch those bugs. Notice also that this is an auto-catalytic (self-accelerated) process: the more bugs disclosed, and more bugs patched, the less bugs remain, so the more it pays to further disclose and patch the remaining bugs, because the less bugs, the relatively more it pays to patch.

Vulnerability disclosure also helps to give vendors an incentive to fix bugs in subsequent product releases[5]. Arora et al. have shown through quantitative analysis that public disclosure made vendors respond with fixes more quickly; the number of attacks increased, but the number of reported vulnerabilities declined over time[6]

Good point! Not only disclosing the bugs is good for the consumers because it directly increases its quality, but also because it helps enforce a better behavior of the vendors. This is a key idea in the article, which delves in the fact that security policies are best when the one enforcing them is the one suffering from their errors. However, nowadays there is little pressure on the vendors to produce more secure software, because the buyer has little knowledge to judge this aspect of the quality, and ends up favoring a product for its looks or the alleged features, regardless of stability or security. Disclosing the bugs helps the buyer to assess the security of a program, thus making a better-balanced choice when buying. This, in return, leads to a more secure software in general, because vendors will have a big incentive to make their products more secure (which they don’t really have now).

[1] E. Rescorla, paper presented in the Third Workshop on the Economics of Information Security, Minneapolis, 13 to 14 May 2004 (PDF)
[2] I suspect the authors are mistaking OpenBSD for FreeBSD
[3] A. Ozment, paper presented at the Fourth Workshop on the Economics of Information Security, Cambridge, MA, 2 to 3 June 2005 (PDF)
[4] A. Ozment, S.E. Schechter, paper presented at the 15th USENIX Security Symposium, Vancouver, 31 July to 4 August 2006 (HTML).
[5] A. Arora, R. Telang, H. Xu, paper presented at the Third Workshop on the Economics of Information Security, Minneapolis, 13 to 14 May 2004 (PDF)
[6] A. Arora, R. Krishnan, A. Nandkumar, R. Telang, Y. Yang, paper presented at the Third Workshop on the Economics of Information Security, Minneapolis, 13 to 14 May 2004 (PDF)

I have watched Children of Men (FilmAffinity|IMDb), and I liked it very much.

The sinopsis is simple: in a near future (year 2027) the humankind has long lost the hability to procreate, so that the youngest persons on Earth are over 18. All nations have crashed, except Great Britain, were an oppressive social setup, close to a fascist regime, remains as the last stronghold of “civilization”. Needless to say, inmigration presure is brutal, as are counter-inmigration measures.

This scenario, and the story that is told, feels at first a bit unrealistic. There are a lot of details that make little sense, or one would think that can not happen. However, as the movie advances, one gets the scary feeling that it could happen. Suddenly, interpersonal relationships, politics, economics… don’t seem a bit “sci-fi”, but rather, one starts to fear them, for their realism.

I would not like a future like that, but the most frightening thing is that it is one of the most verisimilar cataclismic futures in science fiction movies I’ve seen.

Except for one thing: nowadays (much less in 20 years’ time) it is not to fear an eventual extintion of mankind just because men and/or women are infertile, since artificial procreation means are available, even clonation if need be. There would be hard times, and humankind would not be the same… but it would surely survive.

Yesterday I watched a CSI: Miami chapter where Erik Delko was accused of smoking marijuana.

South Beach, Miami. Full of marijuana smokers as Delko, most surely. Taken from Wikimedia Commons

What I want to comment on is the short interview of an Internal Affairs officer to Delko’s workmate Ryan Wolfe. The aim of the interview was to find evidence of Delko’s drug comsumption, and it went like this (loosely transcripted):

Officer: – Have you seen Delko consuming marijuana, or any other drug?
Wolfe: – No.
O: – Have you seen Delko in posession of marijuana, or any other drug?
W: – No.
O: – Did you see Delko with any drug-related paraphernalia?
W: – Nothing illegal…
O: – Then, what?
W: – Only cigarrette-paper.
O: – What do you think the paper was for?
W: – Maybe smoking tobacco.
O: – Have you ever seen Delko smoking tobacco?
W: – Never.
O: – Then, the paper was not for smoking tobacco! (clearly implying that it was for smoking marijuana)

Wow! Amazing this guy’s logic!

First, he makes use of a loaded question: asks about Delko smoking tobacco, making the negative answer (that he expects) sound like the assumption that he does smoke marijuana.

Second, he makes an argument from ignorance: since Wolfe has not seen Delko smoking tobacco, Delko does not smoke tobacco.

Third, in doing this he commits false dichotomy: the only uses of cigarrette-paper are not smoking either tobacco or marijuana, and the denial of one option does not make the other true. Inferring that, because we don’t know any other use for that paper, there must be only those two uses would be another argument from ignorance.

Fourth, and most prominently, he is delivering an outrageous non sequitur: he implies that Wolfe not having seen Delko smoking tobacco is a proof of him not smoking tobacco, but Wolfe not having seen Delko smoking marijuana is not a proof of him not smoking marijuana.

Bruce Lee, on Windows (based on his Be water, my friend speech):

Empty your hard disk.

Don’t be pointless, hopeless… like Windows.

You put Windows in a bottle… it’s still a bottle,
you put it in a computer… it becomes a teapot!

Windows can crawl, or it can crash

Quit Windows, my friend.

¿Te gusta reiniciar?

I am working out a Wiki page for a small sized group of users of a supercomputer at the UPV/EHU.

You might find this comparison useful.

My impressions so far:

[[MoinMoin]]

See more comprehensive HowTo at this more recent post

To install it, create a directory for it (e.g., in your /home), then copy some files to it (after installing the python-moinmoin and moinmoin-common packages, in Debian):

mkdir my_moinmoin_dir
cp /usr/share/moin/config/wikiconfig.py my_moinmoin_dir
cp /usr/share/moin/server/moin.py my_moinmoin_dir
cp /etc/moin/mywiki.py my_moinmoin_dir

Then, edit the files (mainly wikiconfig.py, and run my_moinmoin_dir/moin.py to start up the server.

If you want to make a single Wiki (not a “farm”), then remove (or better, just rename) the file /etc/moin/farmconfig.py (so that it is not read).

This one was easy to install, but has a “small” drawback: the CamelCase internal links. How freaking silly is that? First off, it makes writing CamelCase words that are not links impossible. Second, how can one make a link that displays a text X, but points to page Y?. If only CamelCase generates links, ThisText will link to the page called ThisText. This means that there is no way to put a custom string as link, pointing to a custom page. This is frustrating at the very least. Third, how does one make a one-word link?

These three concerns are taken care of, fortunately. A custom string (not CamelCase) can be used as link like that:

["Custom string here"] (links to page called Custom string here”)

The text of the link can differ from the title of the refered page like this:

[:The Refered:The Text] (displays “The Text”, while pointing to page “The Refered”)

I found out about this workaround after I started to write this page, so sue me for complaining.

It is also problematic (for a dumbass like me) to make the Wiki accesible to machines other than localhost. That is, over the Intra- or Internet. I’m working on in.

DidiWiki

Pros: it is very simple. It is a breeze to install and run. Under Debian, just aptitude install didiwiki, then run didiwiki -p 8080, open a web browser, and put http://localhost:8080 at the location bar. The default port is 8000 (if you run just didiwiki), but for me it fails. The -p can be used to attach DidiWiki to any port.

Contras: it is very simple. Editing is very easy, but… there is no preview! Is there a way to hack a preview into it? I do not know, and the project having made no progress since 2004 smells like there will never be such an upgrade.

More important: there is no “history” of the edits into a page. You can see a list of “recently edited pages”, but no such a list for each single page, or a diff between to arbitrary versions, or reversion capabilities.

On the brigth side, it is immediate to access the Wiki from any other computer… I just don’t know if this is a feature or a security hole :^)

DokuWiki

To install under Debian, do aptitude install dokuwiki, answer the questions it makes, then run dpkg-reconfigure dokuwiki to see if it asks for some more options (e.g. if Wiki will be accesible from localhost, a subnet, or the whole Internet, or what directory to put it under). Then, restart the web server (if you are running Apache2: /etc/inid.d/apache2 restart), and you are done! Now, simply point your broser to http://localhost/dokuwiki/, and you can start using it (replace dokuwiki/ with whatever dir you chose when configuring, if you changed the default).

At first sight is looks good. However, it keeps giving me errors when saving a page. The page gets full of the following:

Warning: preg_match() [function.preg-match]: Compilation failed: repeated subpattern is too long at offset 17093 in /usr/share/dokuwiki/inc/common.php on line 391

It actually saves the page… but the error is annoying at least, dangerous at worst. I suppose I could try to read the source code and fix it (it is PHP, and I have spotted the line with the error… hehehe, line 391, that is), but I do not have the programing skills, I fear.

I’ll give it a try…

Okay, I might have corrected the first bug of a FLOSS program in my life: the 391th line giving an error reads:

if( preg_match('#('.join('|',$re).')#si',$TEXT, $match=array()) ) {

I read the PHP manual for preg_match, and found out that this function chokes for long strings. They say that you can use substr instead, if you are only using the function to find out if some substring exists inside some string (substr is faster and more efficient than preg_match). So I commented out the line above, and wrote instead:

/*if( preg_match('#('.join('|',$re).')#si',$TEXT, $match=array()) ) {*/
if( strpos('#('.join('|',$re).')#si',$TEXT, $match=array()) ) {

Now it works (or pretend it does) like a charm!! UPDATE: the above is rubbish :^( Find a better solution at the DokuWiki bugtracker.

Appart from that, DokuWiki seems to have a decent page edit history, and you can compare different versions with the current one. Pity it doesn’t seem to be possible to compare different old edits between them, as it is with MediaWiki (the engine behind Wikipedia). DokuWiki also looks a bit ugly, but I guess one can correct that with CSS, skins or whatever.

It also looks more difficult to configure than MoinMoin, for example I do not see an easy way to create users. Probably I should just RTFM, as there must be an easy explanation for all that… but I’m too lazy, and MoinMoin is more intuitive on this account (and looks prettier).

ErfurtWiki

It goes under the name ewiki, as a Debian package. However, when I tried to install it, it requested PHP4 (I have PHP5 installed), so I refused to downgrade my PHP and ewiki would not install.

Kwiki

It needs to run as a Perl cgi module. After installing, add the following to your /etc/apache2/apache2.conf:

ScriptAlias /kwiki/ /var/www/kwiki/

Options +ExecCGI

The ScriptAlias makes the browser go to /var/www/kwiki/ when pointed to /kwiki. The Directory block lets Apache execute scripts in that dir.

One then needs to install modules, from CPAN.

All in all, not too easy, a bit annoying, and a bit buggy. Didn’t work well for me.

MediaWiki

Time to give the engine behind Wikipedia itself a try. Probably it is a big overkill for my needs, but what the heck…

First: it is a breeze to install under Debian. First, aptitude install mediawiki, which will automatically install mediawiki1.7, php5-cli and php5-mysql, plus PHP5 and MySQL, if you don’t have them installed. It is also suggested to install memcached.

After aptitude installation, steer your browser to http://localhost/mediawiki/config/index.php (as the README.Debian.gz file says), and fill the required data. After everything is correctly set, copy the Settings file to its final location (also said in the README):

cp /var/lib/mediawiki1.7/config/LocalSettings.php /etc/mediawiki1.7/

URL beautification HowTo

Following instructions at the WikiMedia site.

The default MediaWiki URL is:

http://mywiki.site.tld/wiki/wiki/index.php?title=Article_name

This could be rewriten as:

http://mywiki.site.tld/wiki/Article_name

To achieve that, add the following to /etc/apache2/httpd.conf:

AcceptPathInfo On

#These must come last, and in this order!
Alias /wiki /usr/share/mediawiki1.7/index.php
Alias /index.php /usr/share/mediawiki1.7/index.php

Then the following to /var/lib/mediawiki1.7/LocalSettings.php:

$wgScriptPath = "/mediawiki";
$wgArticlePath = "/wiki/$1";

Then enable the rewrite PHP module, and reload Apache:

ln -s /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/rewrite.load
/etc/init.d/apache2 reload

Now just point your broser to http://localhost/wiki/, and you are done.

Last saturday, Iberdrola suspended the electrical power suply for a couple of hours. The only good thing is that they warned beforehand. The bad part is that they said that they’d cut it on tuesday, which they didn’t, for no apparent reason. Then, they actually cut it on saturday.

Here goes the updated list of blackouts I have been able to compile, with comments if any:

1. 2005-Dec-13
2. 2005-Dec-21
3. 2006-May-26 (The card-based automated access to the Faculty broke down)
4. 2006-Jun-04
5. 2006-Jun-08
6. 2006-Jun-13
7. 2006-Jun-16
8. 2006-Jul-04 (Orpheus didn’t fall)
9. 2006-Sep-14 (Orpheus fell, the DNSs fell, the DHCP servers fell)
10. 2006-Oct-21 (they warned beforehand)

Summary: 10 blackouts in 311 days, or 31.1 dpb (days per blackout). 37 days since last blackout. Average dpb went up by 0.7.

First post in the series: here

This week I have watched Running Scared (“La prueba del crimen”) (IMDb|FilmAffinity[es]).

It is a good action movie, albeit a bit too violent at moments. The photography has some Tony Scott-like moments of choppy and fuzzy scenes, but much less pronounced than in, e.g., Domino.

The plot is well drafted, and the story is absorbing. Too bad the end is confusing, violent and Hollywoodesque. There are some plot twists that add to the value of the movie, but others are mere concessions at “all ends well”. However, it is much more dark and bitter than your average cops/mob movie, where nothing really bad ever happens.

All in all, I would say this movie is not bad, and deserves to be watched.

Being a fan of Jamendo and CC music in general, the discographic lobby might have tagged me as a disruption vector. After all, I am worse than a “pirate”: I do not buy commercial CDs but the music I listen to has been legally acquired.

Well, this is not strictly true. I do buy CDs, from time to time. Just yesterday, I spent 69.40 eur in CDs!! However, I never (seldom) buy trendy music, for the simple reason that CDs over 9.00 eur are almost invisible for me.

The list of what I bought:

• El infierno es demasiado dulce (Eskorbuto) – 8.25 eur
• En tránsito (J.M. Serrat) – 10.65 eur
• Loco por incordiar (Rosendo) – 8.30 eur
• Física y Química (J. Sabina) – 8.75 eur
• Bolsillos (Pedro Guerra) – 2.25 eur
• Valle de Lágrimas and Aparejo de Fortuna (Javier Krahe) – 10.75 eur both
• Versiones Originales (Pérez Prado) – 5.75 eur 2CDs
• Pájaros en la cabeza (Amaral) – 5.95 eur
• Planeta Eskoria (SKA-P) – 8.75 eur

Total: 11 CDs at 6.40 eur each avg.

The three times god-forsaken Ghostscript (I use the Debian package gs-afpl) suite is shipped worldwide with the US letter default paper size. So, when you use it (e.g. to convert PS to PDF), and if the source file does not specify a paper size, the output file will have a letter size, instead of the more sane A4.

You can specify A4 size at runtime, with the -sPAPERSIZE=a4 flag:

ps2pdf -sPAPERSIZE=a4 input.ps

However, if you want to always use A4 as default, you can change the gs_init.ps file (locate gs_init.ps), and uncomment the following line (remove the leading ‘%‘):

% /DEFAULTPAPERSIZE (a4) def

Beware that in Debian you will have to change it to (because the name of the variable is different):

/DEFPAPERSIZE (a4) def

You will only need to edit the gs_init.ps file (as root), make the changes and save the file. Subsequent gs uses (e.g. ps2pdf), will default to A4 page size.

I am currently doing some link disambiguation work for the Wikipedia, and as such, I have to find and replace the same strings many times, in many articles. The on-line Wikipedia edition is in general fine, but one would love to be able to use vim, for a task such as the one I’m taking. To do so, one can make use of mvs.

The mvs program allows us to download a Wikipedia article, save it as a file, then upload it again, after manipulating the file the way we want.

To log in to our Wikipedia account:

mvs login -d wikipedia.org -u username -p password

To download article “X” (beware the .wiki extension):

mvs update X.wiki

We can then edit X.wiki:

vim X.wiki

Then check it:

mvs preview X.wiki
firefox preview.html

And finally upload it:

mvs commit -m 'Your comment goes here' X.wiki

For more info, read the Wikipedia text editor support page