Wednesday, 15 October 2014

new security vulnerability called POODLE

There Is a New Security Vulnerability Named POODLE, and It Is Not Cute:

POODLE affects SSLv3 or version 3 of the Secure Sockets Layer protocol, which is used to encrypt traffic between a browser and a web site or between a user’s email client and mail server. It’s not as serious as the recent Heartbleed and Shellshock vulnerabilities, but POODLE could allow an attacker to hijack and decrypt the session cookie that identifies you to a service like Twitter or Google, and then take over your accounts without needing your password.

According to the team's Bodo Möller: "This vulnerability allows the plaintext of secure connections to be calculated by a network attacker."

This is a client security hole. This is a vulnerability in the old SSLv3 (relaying in 80's code), but even if you have all set for using TLS, in many applications the server can trick you to downgrade to SSL and then it can stole you some security cookies.

This vulnerability is a risk in public wifi but not at home or work.


Mozilla says that it is making Firefox 34 safe from POODLE by disabling SSL 3.0 by default. The code which does this is already baked into the Nightly channel, and will make its way to the Aurora and Beta channels also "in the next few weeks".

MicroSoft Advisory and Workarounds:
This workaround involves Group Policy Editor. For those using versions of Windows that don't include GPE simply go to Control Panel/Internet Options/Advanced/Security and uncheck the box for SSL 3.0 (SSL 2.0 should already be unchecked).

Thursday, 7 August 2014

Ubuntu 14.04 new Ibus is interfering with default emacs keybinding control-space

In emacs you select text marking a starting selection point with control-space. This is a fundamental key binding in emacs. Now in the new version of Ubuntu (14.04) the default service for controlling multilingual input in linux has been changed to Ibus. The issue is that Ibus default key binding to control-space.

If you want to use emacs you probably should change this to something else. Go to a terminal and write 'ibus-setup' and at the right of the input method line you will find three dots '...' click there and change your key binding to Ibus pressing in the three dots in the key code line and then clik in disable. The text will change to 'new accelerator', press your combination of keys and you are done. I have changed mine to super-alt-space (super is the windows key).

Thursday, 27 February 2014

perl gzip libraries (probably zlib issue) does not play well with bgzip files.

In bioinformatcis, bgzip files are important for random access to big files . Bgzip is a program modified from gzip program that uses block compression and is fully backwards compatible with gzip. But I have issues when using bgzip compressed vcf files with Perl scripts that uses IO::Uncompress::Gunzip (that I believe it uses zlib under the hood). A similar problem happen to my recently with snpeff program (Java). In both cases the data is decompressed but truncated after a few hundred lines aprox. I could be totally wrong but I was wondering if zlib (or whatever gzip compatible library they are using) is getting confused with the bgzip bloks and only processing one or a few of them leaving the output incomplete. perl code that does not work:

#!/usr/bin/env perl
use strict;
use IO::Uncompress::Gunzip qw(gunzip $GunzipError) ;

my $infile = shift;
my $infh = IO::Uncompress::Gunzip->new( $infile ) 
         or die "IO::Uncompress::Gunzip failed: $GunzipError\n";
my $line_count = 0;
while (my $line=<$infh>){

print "total lines read = $line_count\n";
This gives 419 lines
    $ perl /home/pmg/tmp/ varsit.vcf.gz
    total lines read = 419
but using open with gzip pipe works:
    #!/usr/bin/env perl
    use strict;
    # I can use bgzip intead gzip
    my $infile = shift;

    open(my $infh , 'gzip -dc '.$infile.' |'); 
    my $line_count = 0;
    while (my $line=<$infh>){

    print "total lines read = $line_count\n"; 
Gives the expected number of lines
    $ perl /home/pmg/tmp/ varsit.vcf.gz
    total lines read = 652829
I googled about and I was unable to find quickly any relevant entry, but this is something that I am sure other people would have already faced. Do someone have a clue about why is this happening? I am using ubuntu 12.04.4 with perl 5.16

[UPDATE 2014-02-28]: finally a clue come from biostars where Heng Li remind me a footnote in the SAM specs about a java library for gzip that only sees first block of bgzip when decompressing. Seems that Perl gzip implementations had the same problem.

Monday, 24 February 2014

automatic encrypting decrypting with emacs

I have been for long time wondering if there was a way to automatically encrypt and decrypt files when accessing them, not leaving an unencrypted file around.

Today I have an epiphany: "let's see if emacs can do that". As an emacs power user I felt as an idiot. Emacs has in the core this ability since emacs 23!! and I never realized about it :-(.

Emacs has incorporated the EasyPG code into its core.

 Things can not be more easy. Put in your .emacs

(require 'epa-file)

;; as it is annoying to be asked if I want passphrase or publick/private key
;; I set passphrase as default
(setq epa-file-select-keys nil)

I also would like to have a gpg agent cache. In ubuntu 12.04 the package is called gnupg-agent

sudo apt-get install gnupg-agent
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  libassuan0 pinentry-gtk2
Suggested packages:
The following NEW packages will be installed:
  gnupg-agent libassuan0 pinentry-gtk2
0 upgraded, 3 newly installed, 0 to remove and 1 not upgraded.  

Now you only need to open a file ended with .gpg and automatically emacs would ask you for the pasword for decryption and again for saving. No unencrypted temporary files are stored, or at least I am not aware of them.