Gentoo Logo
Gentoo Logo Side
Gentoo Spaceship

. Aaron W. Swenson
. Agostino Sarubbo
. Alexey Shvetsov
. Alexis Ballier
. Alexys Jacob
. Alice Ferrazzi
. Andreas K. Hüttel
. Anthony Basile
. Arun Raghavan
. Bernard Cafarelli
. Brian Harring
. Christian Ruppert
. Chí-Thanh Christopher Nguyễn
. Denis Dupeyron
. Detlev Casanova
. Diego E. Pettenò
. Domen Kožar
. Doug Goldstein
. Eray Aslan
. Fabio Erculiani
. Gentoo Haskell Herd
. Gentoo Miniconf 2016
. Gentoo Monthly Newsletter
. Gentoo News
. Gilles Dartiguelongue
. Greg KH
. Göktürk Yüksek
. Hanno Böck
. Hans de Graaff
. Ian Whyman
. Jan Kundrát
. Jason A. Donenfeld
. Jeffrey Gardner
. Joachim Bartosik
. Johannes Huber
. Jonathan Callen
. Jorge Manuel B. S. Vicetto
. Kristian Fiskerstrand
. Lance Albertson
. Liam McLoughlin
. Luca Barbato
. Marek Szuba
. Mart Raudsepp
. Matt Turner
. Matthew Thode
. Michael Palimaka
. Michal Hrusecky
. Michał Górny
. Mike Doty
. Mike Gilbert
. Mike Pagano
. Nathan Zachary
. Pacho Ramos
. Patrick Kursawe
. Patrick Lauer
. Patrick McLean
. Paweł Hajdan, Jr.
. Petteri Räty
. Piotr Jaroszyński
. Rafael G. Martins
. Remi Cardona
. Richard Freeman
. Robin Johnson
. Ryan Hill
. Sean Amoss
. Sebastian Pipping
. Steev Klimaszewski
. Stratos Psomadakis
. Sven Vermeulen
. Sven Wegener
. Tom Wijsman
. Tomáš Chvátal
. Yury German
. Zack Medico

Last updated:
March 26, 2017, 10:04 UTC

Views expressed in the content published here do not necessarily represent the views of Gentoo Linux or the Gentoo Foundation.

Bugs? Comments? Suggestions? Contact us!

Powered by:
Planet Venus

Welcome to Gentoo Universe, an aggregation of weblog articles on all topics written by Gentoo developers. For a more refined aggregation of Gentoo-related topics only, you might be interested in Planet Gentoo.

March 25, 2017
Andreas K. Hüttel a.k.a. dilfridge (homepage, bugs)

We want to stabilize Perl 5.24 on Gentoo pretty soon (meaning in a few weeks), and do actually not expect any big surprises there. If you are running a stable installation, are willing to do some testing, and are familiar with our Gentoo bugzilla and with filing bug reports, then you might just be the right volunteer to give it a try in advance!

Here's what to do:

Step 1: Update app-admin/perl-cleaner to current ~arch.
I'm deliberately not supplying any version number here, since I might do another release, but you should at least have perl-cleaner-2.25.

Step 2: Make sure your system is uptodate (emerge -uDNav world) and do a depclean step (emerge --depclean --ask).

Step 3: Download the current stabilization list from bug 604602 and place it into your /etc/portage/package.keywords or /etc/portage/package.accept_keywords.

Step 4: Update your world (emerge -uDNav world), which triggers the perl update and the module rebuild.

Step 5: Run "perl-cleaner --all"  (you might also want to try "perl-cleaner --all --delete-leftovers").

... and make sure you file bugs for any problems you encounter, during the update and afterwards! Feedback is also appreciated if all goes fine; then you best leave a comment here on the blog post.

March 21, 2017
Jason A. Donenfeld a.k.a. zx2c4 (homepage, bugs)
WireGuard in Google Summer of Code (March 21, 2017, 18:52 UTC)

WireGuard is participating in Google Summer of Code 2017. If you're a student who would like to be funded this summer for writing interesting kernel code, studying cryptography, building networks, or working on a wide variety of interesting problems, then this might be appealing. The program opened to students on March 20th. If you're applying for WireGuard, choose "Linux Foundation" and state in your proposal that you'd like to work on WireGuard with "Jason Donenfeld" as your mentor.

March 20, 2017

libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed an invalid memory read. Upstream says that this bug is fixed by one of the previous commit. However I’m providing as usual the stacktrace and the reproducer, so if you are not running the latest upstream release, like happen on debian/rhel based distros, you may want to check better the status of this bug.

The complete ASan output:

# pcretest -32 -d $FILE
==27914==ERROR: AddressSanitizer: SEGV on unknown address 0x7f3f580efe04 (pc 0x7f3f577b8048 bp 0x7ffcb035b390 sp 0x7ffcb035b320 T0)
==27914==The signal is caused by a READ memory access.
    #0 0x7f3f577b8047 in _pcre32_xclass /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_xclass.c:135:30
    #1 0x7f3f576137ca in match /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:3203:16
    #2 0x7f3f575e7226 in pcre32_exec /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:6936:8
    #3 0x527d6c in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5218:9
    #4 0x7f3f565b478f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #5 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_xclass.c:135:30 in _pcre32_xclass

Affected version:

Fixed version:
8.41 (not released atm)

Commit fix:

This bug was discovered by Agostino Sarubbo of Gentoo.



2017-02-24: bug discovered and reported to upstream
2017-03-20: blog post about the issue
2017-03-23: CVE assigned

This bug was found with American Fuzzy Lop.


libpcre: invalid memory read in _pcre32_xclass (pcre_xclass.c)

libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed an heap overflow in the utility itself. Will follow a feedback from upstream.

I am not going to do anything about this one. (a) It is concerned with a feature of pcretest that has been dropped from pcre2test, and (b) the input contains binary zeros, which are not supported in pcretest input. This is documented for pcre2test but not, I see for pcretest. I have added a paragraph to the documentation.

However, it does not cost much for me inform the community that this bug exists.
In any case, if you have a web application that calls directly the pcretest utility to parse untrusted data, then you are affected.
Also, it is important share the details because some distros/packagers may want to patch this issue instead of follow the upstream’s way.

The complete ASan output:

# pcretest -16 -d $FILE
==30352==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60b00000b000 at pc 0x00000053cef0 bp 0x7ffd02dccb90 sp 0x7ffd02dccb88
READ of size 2 at 0x60b00000b000 thread T0
    #0 0x53ceef in regexflip8_or_16 /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2552:24
    #1 0x53ceef in regexflip /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2792
    #2 0x53ceef in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:4425
    #3 0x7fb6693d678f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

0x60b00000b000 is located 0 bytes to the right of 112-byte region [0x60b00000af90,0x60b00000b000)
allocated by thread T0 here:
    #0 0x4d41f8 in malloc /tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/
    #1 0x53e883 in new_malloc /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2372:15
    #2 0x7fb66a9473a1 in pcre16_compile2 /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_compile.c:9393:19
    #3 0x5335d9 in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:4034:5
    #4 0x7fb6693d678f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2552:24 in regexflip8_or_16

Affected version:

Commit fix:

Fixed version:

This bug was discovered by Agostino Sarubbo of Gentoo.


2017-02-22: bug discovered and reported to upstream
2017-03-20: blog post about the issue

This bug was found with American Fuzzy Lop.


libpcre: heap-based bufffer overflow in regexflip8_or_16 (pcretest.c)

libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed two stack overflow write. Upstream says that these bugs are fixed by one of the previous commit. However I’m providing as usual the stacktrace and the reproducer, so if you are not running the latest upstream release, like happen on debian/rhel based distros, you may want to check better the status of this bug.

The complete ASan output:

# pcretest -32 -d $FILE
==29686==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f58f32026a0 at pc 0x7f58f6f90a24 bp 0x7ffea3aa3b30 sp 0x7ffea3aa3b28
WRITE of size 4 at 0x7f58f32026a0 thread T0
    #0 0x7f58f6f90a23 in pcre32_copy_substring /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_get.c:358:15
    #1 0x528220 in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5333:13
    #2 0x7f58f5ea778f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #3 0x41b438 in _init (/usr/bin/pcretest+0x41b438)


# pcretest -32 -d $FILE
==21399==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f83734026a0 at pc 0x0000004bd2ac bp 0x7ffdda673b30 sp 0x7ffdda6732e0
WRITE of size 268 at 0x7f83734026a0 thread T0
    #0 0x4bd2ab in __asan_memcpy /tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/
    #1 0x7f8377118925 in pcre32_copy_substring /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_get.c:357:1
    #2 0x528220 in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5333:13
    #3 0x7f837602f78f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x41b438 in _init (/usr/bin/pcretest+0x41b438)


Affected version:

Fixed version:
8.41 (not released atm)

Commit fix:

This bug was discovered by Agostino Sarubbo of Gentoo.

2017-02-24: bug discovered and reported to upstream
2017-03-20: blog post about the issue

This bug was found with American Fuzzy Lop.


libpcre: two stack-based buffer overflow write in pcre32_copy_substring (pcre_get.c)

March 17, 2017
Michał Górny a.k.a. mgorny (homepage, bugs)

You should know already that you are not supposed to rely on Portage internals in ebuilds — all variables, functions and helpers that are not defined by the PMS. You probably know that you are not supposed to touch various configuration files, vdb and other Portage files as well. What most people don’t seem to understand, you are not supposed to make any assumptions about the ebuild repository either. In this post, I will expand on this and try to explain why.

What PMS specifies, what you can rely on

I think the first confusing point is that PMS actually defines the repository format pretty thoroughly. However, it does not specify that you can rely on that format being visible from within ebuild environment. It just defines a few interfaces that you can reliably use, some of them in fact quite consistent with the repository layout.

You should really look as the PMS-defined repository format as an input specification. This is the format that the developers are supposed to use when writing ebuilds, and that all basic tools are supposed to support. However, it does not prevent the package managers from defining and using other package formats, as long as they provide the environment compliant with the PMS.

In fact, this is how binary packages are implemented in Gentoo. The PMS does not define any specific format for them. It only defines a few basic rules and facilities, and both Portage and Paludis implement their own binary package formats. The package managers expose APIs required by the PMS, and can use them to run the necessary pkg_* phases.

However, the problem is not limited to two currently used binary package formats. This is a generic goal of being able to define any new package format in the future, and make it work out of the box with existing ebuilds. Imagine just a few possibilities: more compact repository formats (i.e. not requiring hundreds of unpacked files), fetching only needed ebuild files…

Sadly, none of this can even start being implemented if developers continuosly insist to rely on specific repository layout.

The *DIR variables

Let’s get into the details and iterate over the few relevant variables here.

First of all, FILESDIR. This is the directory where ebuild support files are provided throughout src_* phases. However, there is no guarantee that this will be exactly the directory you created in the ebuild repository. The package manager just needs to provide the files in some directory, and this directory may not actually exist before the first src_* phase. This implies that the support files may not even exist at all when installing from a binary package, and may be created (copied, unpacked) later when doing a source build.

The next variable listed by the PMS is DISTDIR. While this variable is somewhat similar to the previous one, some developers are actually eager to make the opposite assumption. Once again, the package manager may provide the path to any directory that contains the downloaded files. This may be a ‘shadow’ directory containing only files for this package, or it can be any system downloads directory containing lots of other files. Once again, you can’t assume that DISTDIR will exist before src_*, and that it will exist at all (and contain necessary files) when the build is performed using a binary package.

The two remaining variables I would like to discuss are PORTDIR and ECLASSDIR. Those two are a cause of real mayhem: they are completely unsuited for a multi-repository layout modern package managers use and they enforce a particular source repository layout (they are not available outside src_* phases). They pretty much block any effort on improvement, and sadly their removal is continuously blocked by a few short-sighted developers. Nevertheless, work on removing them is in progress.

Environment saving

While we’re discussing those matters, a short note on environment saving is worth being written. By environment saving we usually mean the magic that causes the variables set in one phase function to be carried to a phase function following it, possibly over a disjoint sequence of actions (i.e. install followed by uninstall).

A common misunderstanding is to assume the Portage model of environment saving — i.e. basically dumping a whole ebuild environment including functions into a file. However, this is not sanctioned by the PMS. The rules require the package manager to save only variables, and only those that are not defined in global scope. If phase functions define functions, there is no guarantee that those functions will be preserved or restored. If phases redefine global variables, there is no guarantee that the redefinition will be preserved.

In fact, the specific wording used in the PMS allows a completely different implementation to be used. The package manager may just snapshot defined functions after processing the global scope, or even not snapshot them at all and instead re-read the ebuild (and re-inherit eclasses) every time the execution continues. In this case, any functions defined during phase function are lost.

Is there a future in this?

I hope this clears up all the misunderstandings on how to write ebuilds so that they will work reliably, both for source and binary builds. If those rules are followed, our users can finally start expecting some fun features to come. However, before that happens we need to fix the few existing violations — and for that to happen, we need a few developers to stop thinking only of their own convenience.

Marek Szuba a.k.a. marecki (homepage, bugs)
Gentoo Linux in a Docker container (March 17, 2017, 14:31 UTC)

I have been using Docker for ebuild development for quite a while and absolutely love it, mostly because how easy it is to manipulate filesystem state with it. Work on several separate ebuilds in parallel? Just spin up several containers. Clean up once I’m done? Happens automatically when I close the container. Come back to something later? One docker commit invocation and I’m done. I could of course do something similar with virtual machines (and indeed I have to for cross-platform work) – but for native amd64 is is extremely convenient.

There is, however, one catch. By default processes running in a Docker container are fairly restricted privilege-wise and the Gentoo sandbox uses ptrace(). Result? By default, certain ebuilds (sys-libs/glibc and dev-libs/gobject-introspection , to name just two) will fail to emerge. One can of course set FEATURES=”-sandbox -usersandbox” for such ebuilds but it is an absolute no-no for both new ebuilds and any stabilisation work.

In the past working around this issue required messing with Docker security policies, which at least I found rather awkward. Fortunately since version 1.13.0 there has been a considerably easier way – simply pass


to docker-run. Done! Sandbox can now use ptrace() to its heart’s content.

Big Fat Warning: The reason why by default Docker restricts CAP_SYS_PTRACE is that a malicious program can use ptrace() to break out of the container it runs in. Do not grant this capability to containers unless you know what you are doing. Seriously.

Unfortunately the above is not the end of the story because at least as of version 1.13.0, Docker does not allow to enhance the capabilities of a docker-build job. Why is this a problem? For my own work I use a custom image which extends somewhat the official gentoo/stage3-amd64-hardened . One of the things my Dockerfile does is rsync the Portage tree and update @world so that my image contains a fully up-to-date stage3 even when the official base image does not. You can guess what happens when Docker tries to emerge an ebuild requiring the sandbox to use ptrace()… and remember, one of the packages containing such ebuilds is sys-libs/glibc . To my current knowledge the only way around this is to spin up a ptrace-enabled container using the latest good intermediate image left behind by docker-build and execute the remaining build steps manually. Not fun… Hope they will fix this some day.


Possibly the simplest way of changing the passhprase protecting a SSH key imported into gpg-agent is to use the Assuan passwd command:

echo passwd foo | gpg-connect-agent

where foo is the keygrip of your SSH key, which one can obtain from the file $GNUPGHOME/sshcontrol [1]. So far so good – but how does one know which of the keys listed in that file is the right one, especially if your sshcontrol list is fairly long? Here are the options I am aware of at this point:

Use the key comment. If you remember the contents of the comment field of the SSH key in question you can simply grep for it in all the files stored in $GNUPGHOME/private-keys-v1.d/ . Take the name of the file that matches, strip .key from the end and you’re set! Note that these are binary files so make sure your grep variant does not skip over them.

Use the MD5 fingerprint and the key comment. If for some reason you would rather not do the above you can take advantage of the fact that for SSH keys imported into gpg-agent the normal way, each keygrip line in sshcontrol is preceded by comment lines containing, among other things, the MD5 fingerprint of the imported key. Just tell ssh-add to print MD5 fingerprints for keys known to the agent instead of the default SHA256 ones:

ssh-add -E md5 -l

locate the fingerprint corresponding to the relevant key comment, then find the corresponding keygrip in sshcontrol .

Use the MD5 fingerprint and the public key. A slightly more complex variant of the above can be used if your SSH key pair in question has no comment but you still have the public key lying around. Start by running

ssh-add -L

and note the number of the line in which the public key in question shows up. The output of ssh-add -L and ssh-add -l is in the same order so you should have no trouble locating the corresponding MD5 fingerprint.

Bottom line: use meaningful comments for your SSH keys. It can really simplify key management in the long run.


March 15, 2017
Hanno Böck a.k.a. hanno (homepage, bugs)
Zero Days and Cargo Cult Science (March 15, 2017, 12:25 UTC)

I've complained in the past about the lack of rigorous science in large parts of IT security. However there's no lack of reports and publications that claim to provide data about this space.

Recently RAND Corporation, a US-based think tank, published a report about zero day vulnerabilities. Many people praised it, an article on Motherboard quotes people saying that we finally have “cold hard data” and quoting people from the zero day business who came to the conclusion that this report clearly confirms what they already believed.

I read the report. I wasn't very impressed. The data is so weak that I think the conclusions are almost entirely meaningless.

The story that is spun around this report needs some context: There's a market for secret security vulnerabilities, often called zero days or 0days. These are vulnerabilities in IT products that some actors (government entities, criminals or just hackers who privately collect them) don't share with the vendor of that product or the public, so the vendor doesn't know about them and can't provide a fix.

One potential problem of this are bug collisions. Actor A may find or buy a security bug and choose to not disclose it and use it for its own purposes. If actor B finds the same bug then he might use it to attack actor A or attack someone else. If A had disclosed that bug to the vendor of the software it could've been fixed and B couldn't have used it, at least not against people who regularly update their software. Depending on who A and B are (more or less democratic nation states, nation states in conflict with each other or simply criminals) one can argue how problematic that is.

One question that arises here is how common that is. If you found a bug – how likely is it that someone else will find the same bug? The argument goes that if this rate is low then stockpiling vulnerabilities is less problematic. This is how the RAND report is framed. It tries to answer that question and comes to the conclusion that bug collisions are relatively rare. Thus many people now use it to justify that zero day stockpiling isn't so bad.

The data is hardly trustworthy

The basis of the whole report is an analysis of 207 bugs by an entity that shared this data with the authors of the report. It is incredibly vague about that source. They name their source with the hypothetical name BUSBY.

We can learn that it's a company in the zero day business and indirectly we can learn how many people work there on exploit development. Furthermore we learn: “Some BUSBY researchers have worked for nation-states (so
their skill level and methodology rival that of nation-state teams), and many of BUSBY’s products are used by nation-states.” That's about it. To summarize: We don't know where the data came from.

The authors of the study believe that this is a representative data set. But it is not really explained why they believe so. There are numerous problems with this data:

  • We don't know in which way this data has been filtered. The report states that 20-30 bugs “were removed due to operational sensitivity”. How was that done? Based on what criteria? They won't tell you. Were the 207 bugs plus the 20-30 bugs all the bugs the company had found or was this already pre-filtered? They won't tell you.
  • It is plausible to assume that a certain company focuses on specific bugs, has certain skills, tools or methods that all can affect the selection of bugs and create biases.
  • Oh by the way, did you expect to see the data? Like a table of all the bugs analyzed with the at least the little pieces of information BUSBY was willing to share? Because you were promised to see cold hard data? Of course not. That would mean others could reanalyze the data, and that would be unfortunate. The only thing you get are charts and tables summarizing the data.
  • We don't know the conditions under which this data was shared. Did BUSBY have any influence on the report? Were they allowed to read it and comment on it before publication? Did they have veto rights to the publication? The report doesn't tell us.

Naturally BUSBY has an interest in a certain outcome and interpretation of that data. This creates a huge conflict of interest. It is entirely possible that they only chose to share that data because they expected a certain outcome. And obviously the reverse is also true: Other companies may have decided not to share such data to avoid a certain outcome. It creates an ideal setup for publication bias, where only the data supporting a certain outcome is shared.

It is inexcusable that the problem of conflict of interest isn't even mentioned or discussed anywhere in the whole report.

A main outcome is based on a very dubious assumption

The report emphasizes two main findings. One is that the lifetime of a vulnerability is roughly seven years. With the caveat that the data is likely biased, this claim can be derived from the data available. It can reasonably be claimed that this lifetime estimate is true for the 207 analyzed bugs.

The second claim is about the bug collision rate and is much more problematic:
“For a given stockpile of zero-day vulnerabilities, after a year, approximately 5.7 percent have been discovered by an outside entity.”

Now think about this for a moment. It is absolutely impossible to know that based on the data available. This would only be possible if they had access to all the zero days discovered by all actors in that space in a certain time frame. It might be possible to extrapolate this if you'd know how many bugs there are in total on the market - but you don't.

So how does this report solve this? Well, let it speak for itself:

Ideally, we would want similar data on Red (i.e., adversaries of Blue, or other private-use groups), to examine the overlap between Blue and Red, but we could not obtain that data. Instead, we focus on the overlap between Blue and the public (i.e., the teal section in the figures above) to infer what might be a baseline for what Red has. We do this based on the assumption that what happens in the public groups is somewhat similar to what happens in other groups. We acknowledge that this is a weak assumption, given that the composition, focus, motivation, and sophistication of the public and private groups can be fairly different, but these are the only data available at this time. (page 12)

Okay, weak assumption may be the understatement of the year. Let's summarize this: They acknowledge that they can't answer the question they want to answer. So they just answer an entirely different question (bug collision rate between the 207 bugs they have data about and what is known in public) and then claim that's about the same. To their credit they recognize that this is a weak assumption, but you have to read the report to learn that. Neither the summary nor the press release nor any of the favorable blog posts and media reports mention that.

If you wonder what the Red and Blue here means, that's also quite interesting, because it gives some insights about the mode of thinking of the authors. Blue stands for the “own team”, a company or government or anyone else who has knowledge of zero day bugs. Red is “the adversary” and then there is the public. This is of course a gross oversimplification. It's like a world where there are two nation states fighting each other and no other actors that have any interest in hacking IT systems. In reality there are multiple Red, Blue and in-between actors, with various adversarial and cooperative relations between them.

Sometimes the best answer is: We don't know

The line of reasoning here is roughly: If we don't have good data to answer a question, we'll just replace it with bad data.

I can fully understand the call for making decisions based on data. That is usually a good thing. However, it may simply be that this is a scenario where getting reliable data is incredibly hard or simply impossible. In such a situation the best thing one can do is admit that and live with it. I don't think it's helpful to rely on data that's so weak that it's basically meaningless.

The core of the problem is that we're talking about an industry that wants to be secret. This secrecy is in a certain sense in direct conflict with good scientific practice. Transparency and data sharing are cornerstones of good science.

I should mention here that shortly afterwards another study was published by Trey Herr and Bruce Schneier which also tries to answer the question of bug collisions. I haven't read it yet, from a brief look it seems less bad than the RAND report. However I have my doubts about it as well. It is only based on public bug findings, which is at least something that has a chance of being verifiable by others. It has the same problem that one can hardly draw conclusions about the non-public space based on that. (My personal tie in to that is that I had a call with Trey Herr a while ago where he asked me about some of my bug findings. I told him my doubts about this.)

The bigger picture: We need better science

IT security isn't a field that's rich of rigorous scientific data.

There's a lively debate right now going on in many fields of science about the integrity of their methods. Psychologists had to learn that many theories they believed for decades were based on bad statistics and poor methodology and are likely false. Whenever someone tries to replicate other studies the replication rates are abysmal. Smart people claim that the majority scientific outcomes are not true.

I don't see this debate happening in computer science. It's certainly not happening in IT security. Almost nobody is doing replications. Meta analyses, trials registrations or registered reports are mostly unheard of.

Instead we have cargo cult science like this RAND report thrown around as “cold hard data” we should rely upon. This is ridiculous.

I obviously have my own thoughts on the zero days debate. But my opinion on the matter here isn't what this is about. What I do think is this: We need good, rigorous science to improve the state of things. We largely don't have that right now. And bad science is a poor replacement for good science.

March 14, 2017
Andreas K. Hüttel a.k.a. dilfridge (homepage, bugs)

As nearly every year we'll present a poster on Lab::Measurement at the spring meeting of the German Physical Society again. This time the conference is in Dresden - so visit us on upcoming 23 March 2017, 15:00-19:00, poster session TT75, poster TT75.7!

libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed an invalid read in the library. For who is interested in a detailed description of the bug, will follow a feedback from upstream:

This was a genuine bug in the 32-bit library. Thanks for finding it. The crash was caused by trying to find a Unicode property for a code value greater than 0x10ffff, the Unicode maximum, when running in non-UTF mode (where character values can be up to 0xffffffff). The bug was in both PCRE1 and PCRE2. I have fixed both of them.

The complete ASan output:

# pcretest -32 -d $FILE
==14788==ERROR: AddressSanitizer: SEGV on unknown address 0x7f1bbffed4df (pc 0x7f1bbee3fe6b bp 0x7fff8b50d8c0 sp 0x7fff8b50d3a0 T0)
==14788==The signal is caused by a READ memory access.
    #0 0x7f1bbee3fe6a in match /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:5473:18
    #1 0x7f1bbee09226 in pcre32_exec /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:6936:8
    #2 0x527d6c in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5218:9
    #3 0x7f1bbddd678f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:5473:18 in match

Affected version:
8.40 and 10.23

Fixed version:
8.41 and 10.24 (not released atm)

Commit fix for libpcre1:

Commit fix for libpcre2:

This bug was discovered by Agostino Sarubbo of Gentoo.



2017-02-23: bug discovered and reported to upstream
2017-02-24: upstream released a patch
2017-03-14: blog post about the issue
2017-03-19: CVE assigned

This bug was found with American Fuzzy Lop.


libpcre: invalid memory read in match (pcre_exec.c)

libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed a null pointer dereference in the utility itself. For the nature of the crash, it is not security relevant because the library is not affected but if you have a web application that calls directly the pcretest utility to parse untrusted data, then you are affected.
Also, it is important share the details because some distros/packagers may want to take the patch in their repository.

The complete ASan output:

# pcretest -16 -d $FILE
==26399==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000052db1c bp 0x7ffc7de68070 sp 0x7ffc7de67ba0 T0)                                                                                                                                            
==26399==The signal is caused by a READ memory access.                                                                                                                                                                                                                         
==26399==Hint: address points to the zero page.                                                                                                                                                                                                                                
    #0 0x52db1b in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5083:25                                                                                                                                                                                   
    #1 0x7f70603bc78f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289                                                                                                                                                     
    #2 0x41b438 in _init (/usr/bin/pcretest+0x41b438) 

Affected version:

Fixed version:
8.41 (not released atm)

Commit fix:

This bug was discovered by Agostino Sarubbo of Gentoo.



2017-02-22: bug discovered and reported to upstream
2017-02-23: upstream released a patch
2017-03-14: blog post about the issue

This bug was found with American Fuzzy Lop.


libpcre: NULL pointer dereference in main (pcretest.c)

libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed an invalid read in the utility itself. For the nature of the crash, it is not security relevant because the library is not affected but if you have a web application that calls directly the pcretest utility to parse untrusted data, then you are affected.
Also, it is important share the details because some distros/packagers may want to take the patch in their repository.

The complete ASan output:

# pcretest -16 -d $FILE
==28444==ERROR: AddressSanitizer: SEGV on unknown address 0x7f3c2de3e2dd (pc 0x0000005409dd bp 0x7fff0423db40 sp 0x7fff0423dac0 T0)
==28444==The signal is caused by a READ memory access.
    #0 0x5409dc in pchar /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:1986:5
    #1 0x54006f in pchars16 /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2115:12
    #2 0x52e3e1 in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5092:15
    #3 0x7f3c2dc3878f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

Affected version:

Fixed version:
8.41 (not released atm)

Commit fix:

This bug was discovered by Agostino Sarubbo of Gentoo.



2017-02-22: bug discovered and reported to upstream
2017-02-22: upstream released a patch
2017-03-14: blog post about the issue

This bug was found with American Fuzzy Lop.


libpcre: invalid memory read in phar (pcretest.c)

March 13, 2017
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Vodafone R205: opening it up (March 13, 2017, 00:03 UTC)

I have posted about using an R205 without a Vodafone blessed network, and I wrote a quick software inspection of the device. This time I’m writing some notes about the hardware itself.

I have originally expected to just destroy the device to try to gain access to it, but it turns out it’s actually simpler than expected to open: the back of the device is fastened through four Torx T5 screws, and then just a bit of pressure to tear the back apart from the front. No screws behind the label under the battery. I have managed to open and re-close the device without it looking much different, just a bit weathered down.

Unfortunately the first thing that becomes obvious is that the device is not designed to turn on without the battery plugged in. If you try to turn it on with just the USB connected – I tried that before disassembly, of course – the device only displays “BATTERY ERROR” and refuses to boot. This appears to be one of the errors coming from the bootloader of the board, as I can find it next to “TEMP INVALID” in the firmware strings.

Keeping the battery connected while the device is open is not possible by design. Particularly when you consider that all the interesting-looking pads are underneath the battery itself. The answer is thus to just go and solder some cables on the board and connect them to the battery — I care about my life enough not to intend to solder on the battery, that one can be connected with physical placement and tape. This is the time I had to make a call and sacrifice the device. Luckily, the answer was easy: I already have a backup device, another Vodafone Pocket WiFi, this time a R208, that my sister dismissed. Plus if I really wanted, I could get myself a newer 4G version as that’s what my SIM card supports.

There are two sets of pads that appear promising, and so I took a look at them with a simple multimeter. The first group is a 5-pads group, in which one of them correspond to ground, two appear to idle around 3V, and one appears to idle around 4V. This is not exactly your usual configuration of a serial port, but I have not managed to get more details yet. The other group is a 10-pad group with two grounds, and a number of idling pads at 1.85V, which is significantly more consistent with JTAG, but again I have not managed to inspect it yet.

Annotated image of the E586 board.

So I decided to get myself some solid core wires, and try to solder them on the five-pad configuration I saw on the board. Unfortunately the end result has been destructive, and so I had to discard the idea of getting any useful data from that board. Bummer. But, then I thought to myself that this device has to be fairly common, since Vodafone sold it anywhere from Ireland, to Italy to Australia at least. And indeed a quick look at eBay showed me a seller having, not the R205, but the Huawei E586 available for cheap. Indeed, a lot of four devices was being sold for $10 (plus €20 for postage and customs, sigh!). These were fully Huawei-branded E586 devices, with a quite different chassis and a Wind logo on them. Despite coming from New York State, this particular Wind-branded company was Canadian (now goes by Freedom Mobile); I’m not sure on the compatibility of the GSM network, but the package looked promising: four devices, but only one “complete” (battery and back cover). I bought it and it arrived just the other day.

An aside, it’s fun to note that I found just recently that Wind was used as a brand in Canada. The original brand comes from Italy, and I have been a customer of theirs for a number of years there. Indeed, my current Italian phone number is subscribed with Wind. The whole structure of co-owned brands seems to be falling apart though, with the Canadian brand gone, and with the Italian original company having been merged with Tre (Three Italy). I’m not sure on who owns what of that, but they appear to still advertise the Veon app, which matches the new name of the Russian company who owned them until now so who knows.

Opening the Wind devices is also significantly easier as it does not require as much force and does not have as many moving parts. Indeed, the whole chassis is mostly one plastic block, while the front comes away entirely. So indeed after I got home with them I opened one and looked into it, comparing it with the one I had already broken:

If you compare the two boards, you can see that on the top-right (front-facing) there is a small RF connector, which could be a Hirose U.FL or an otherwise similar connector; on the R205, this connector is on the back, making it not reachable by the user. The pad for both RF connectors are visible on as not used in the opposite board.

Next to the connector there is also a switch that is not present in the R205, which on the chassis is marked as reset. On the R205 the reset switch is towards the bottom, and there is nothing on the top side. The lower switch is marked as WPS on the chassis on the Wind device, which makes me think these are programmable somehow. I guess if I look at this deeply enough I’ll find out that these are just GPIOs for the CPU and they are just mapped differently in the firmware.

I have not managed to turn them up yet, also because I do not trust them that much. They appear to have at least the same bootloader since the BATTERY ERROR message appears on them just the same. On the other hand this gives me at least a secondary objective I can look into: if I can figure out how to extract the firmware from the resources of the update binary provided by Vodafone, and how the firmware upgrade process works, I should be able to flash a copy of the Vodafone firmware onto the Wind device as well, since they have the same board. And that would be a good starting point for it.

Having already ruined one of the boards also allows me to open up the RF shielding that is omnipresent on those boards and is hiding every detail, and it would be an interesting thing to document, and would allow to figure out if there is any chance of using OpenWRT or LEDE on it. I guess I’ll follow up with more details of the pictures, and more details of the software.

March 11, 2017
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Let's have a talk about TOTP (March 11, 2017, 01:03 UTC)

You probably noticed that I’m a firm believer in 2FA, and in particular on the usefulness of U2F against phishing. Unfortunately not all the services out there have upgraded to U2F to protect their users, though at least some of them managed to bring a modicum of extra safety against other threats by implementing TOTP 2FA/2SV (2-steps verification). Which is good, at least.

Unfortunately this can become a pain. In a previous post I have complained about the problems of SMS-based 2FA/2SV. In this post I’m complaining about the other kind: TOTP. Unlike the SMS, I find this is an implementation issue rather than a systemic one, but let’s see what’s going on.

I have changed my mobile phone this week, as I upgrade my work phone to one whose battery lasts more than half a day, which is important since my job requires me to be oncall and available during shifts. And as usual when this happens, I need to transfer my authenticator apps to the new phone.

Some of the apps are actually very friendly to this: Facebook and Twitter use a shared secret that, once login is confirmed, is passed onto their main app, which means you just need any logged in app to log in again and get a new copy. Neat.

Blizzard was even better. I have effectively copied my whole device config and data across with the Android transfer tool. The authenticator copied over the shared key and didn’t require me to do anything at all to keep working. I like things that are magic!

The rest of the apps was not as nice though.

Amazon and allow you to add at any time a new app using the same shared key. The latter has an explicit option to re-key the 2FA to disable all older apps. Amazon does not tell you anything about it, and does not let you re-key explicitly — my guess is that it re-keys if you disable authentication apps altogether and re-enable it.

WordPress, EA/Origin, Patreon and TunnelBroker don’t allow you to change the app, or get the previously shared key. Instead you have to disable 2FA, then re-enable it. Leaving you “vulnerable” for a (hopefully) limited time. Of these, EA allows you to receive the 2SV code by email, so I decided I’ll take that over having to remember to port this authenticator over every time.

If you remember in the previous post I complained about the separate Authenticator apps that kept piling up for me. I realized that I don’t need as many: the login approval feature, which effectively Microsoft and LastPass provide, is neat and handy, but it’s not worth having two more separate apps for it, so I downgraded them to just use normal TOTP on the Google Authenticator app, which gets me the Android Wear support to see the code straight on my watch. I have particularly failed to remember when I last logged into a Microsoft product except for setting up the security parameters.

Steam on the other hand, was probably the most complete disaster of trying to migrate. Their app, similarly to the one, is just a specially formatted TOTP with a shared key you’re not meant to see. Unfortunately to be able to move the Authenticator to a new phone, you need to disable it first — and you disable it from the logged-in app that has it enabled. Then you can re-enable it on a new phone. I assume there is some specific way to get recovery if that does not work, too. But I don’t count on it.

What does this all mean? TOTP is difficult, it’s hard for users, and it’s risky. Not having an obvious way to de-authenticate the app is bad. If you were at ENIGMA, you could have listened to a talk that was not recorded, on ground of the risky situations there described. The talk title was «Privacy and Security Practices of Individuals Coping with Intimate Partner Abuse». Among various topic that the talk touched upon, there was an important note on the power of 2FA/2SV for people being spied upon to gain certainty that somebody else is not logging in on their account. Not being able to de-authenticate TOTP apps goes against this certainty. Having to disable your 2FA to be able to change it to a new device makes it risky.

Then there are the features that become a compromise between usability and paranoia. As I said I love the Android Wear integration for the Authenticator app. But since the watch is not lockable, it means that anybody who could have access to my watch while I’m not attentive could have access to my TOTP. It’s okay for my use case, but it may not be for all. The Google Authenticator app also does not allow you to set a passcode and encrypt the shared keys, which means if you have enabled developer mode, run your phone unencrypted, or have a phone that is known vulnerable, your TOTP shared keys can be exposed.

What does this all mean? That there is no such thing as the perfect 100% solution that covers you against all possible threat models out there, but some solutions are better than others (U2F) and then compromises depend on what you’re defending against: a relative, or nation-states? If you remember I already went over this four years ago, and again the following year, and the one after talking about threat models. It’s a topic that I’m interested in, if it was not clear.

And a very similar concept was expressed by Zeynep Tufekci when talking about “low-profile activists”, wanting to protect their personal life, rather than the activism. This talk was recorded and is worth watching.

March 08, 2017
Marek Szuba a.k.a. marecki (homepage, bugs)
Hello world! (March 08, 2017, 02:12 UTC)

Welcome to Gentoo Blogs. This is your first post. Edit or delete it, then start blogging!

March 06, 2017
Sven Vermeulen a.k.a. swift (homepage, bugs)
Handling certificates in Gentoo Linux (March 06, 2017, 21:20 UTC)

I recently created a new article on the Gentoo Wiki titled Certificates which talks about how to handle certificate stores on Gentoo Linux. The write-up of the article (which might still change name later, because it does not handle everything about certificates, mostly how to handle certificate stores) was inspired by the observation that I had to adjust the certificate stores of both Chromium and Firefox separately, even though they both use NSS.


Well, when a secure communication is established from a browser to a site (or any other interaction that uses SSL/TLS, but let's stay with the browser example for now) part of the exchange is to ensure that the target site is actually the site it claims to be. Don't want someone else to trick you into giving your e-mail credentials do you?

To establish this, the certificate presented by the remote site is validated (alongside other handshake steps). A certificate contains a public key, as well as information about what the certificate can be used for, and who (or what) the certificate represents. In case of a site, the identification is (or should be) tied to the fully qualified domain name.

Of course, everyone could create a certificate for and try to trick you into leaving your credentials. So, part of the validation of a certificate is to verify that it is signed by a third party that you trust to only sign certificates that are trustworthy. And to validate this signature, you hence need the certificate of this third party as well.

So, what about this certificate? Well, turns out, this one is also often signed by another certificate, and so on, until you reach the "top" of the certificate tree. This top certificate is called the "root certificate". And because we still have to establish that this certificate is trustworthy, we need another way to accomplish this.

Enter certificate stores

The root certificates of these trusted third parties (well, let us call them "Certificate Authorities" from now onward, because they sometimes will lose your trust) need to be reachable by the browser. The location where they are stored in is (often) called the truststore (a naming that I came across when dealing with Java and which stuck).

So, what I wanted to accomplish was to remove a particular CA certificate from the certificate store. I assumed that, because Chromium and Firefox both use NSS as the library to support their cryptographic uses, they would also both use the store location at ~/.pki/nssdb. That was wrong.

Another assumption I had was that NSS also uses the /etc/pki/nssdb location as a system-wide one. Wrong again (not that NSS doesn't allow this, but it seems that it is very much up to, and often ignored by, the NSS-implementing applications).

Oh, and I also assumed that there wouldn't be a hard-coded list in the application. Yup. Wrong again.

How NSS tracks root CA

Basically, NSS has a hard-coded root CA list inside the file. On Gentoo, this file is provided by the dev-libs/nss package. Because it is hard-coded, it seemed like there was little I could do to remove it, yet still through the user interfaces offered by Firefox and Chromium I was able to remove the trust bits from the certificate.

Turns out that Firefox (inside ~/.mozilla/firefox/*.default) and Chromium (inside ~/.pki/nssdb) store the (modified) trust bits for those locations, so that the hardcoded list does not need to be altered if all I want to do was revoke the trust on a specific CA. And it isn't that this hard-coded list is a bad list: Mozilla has a CA Certificate Program which controls the CAs that are accepted inside this store.

Still, I find it sad that the system-wide location (at /etc/pki/nssdb) is not by default used as well (or I have something wrong on my system that makes it so). On a multi-user system, administrators who want to have some control over the certificate stores might need to either use login scripts to manipulate the user certificate stores, or adapt the user files directly currently.

March 03, 2017

potrace is a utility that transforms bitmaps into vector graphics.

A fuzz on 1.14 showed that an overflow previously reported as CVE-2016-8698 was not really fixed. Since there isn’t a public git repository, I uploaded the patch on my ‘poc’ repository on github. The patch was sent from the upstream maintainer, Mr. Peter Selinger.

The complete ASan output:

# potrace $FILE
==7325==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000efd0 at pc 0x00000051dc51 bp 0x7ffc766b1a30 sp 0x7ffc766b1a28
READ of size 8 at 0x60200000efd0 thread T0
    #0 0x51dc50 in bm_readbody_bmp /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:754:4
    #1 0x51dc50 in bm_read /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:138
    #2 0x510a45 in process_file /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/main.c:1058:9
    #3 0x50dd56 in main /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/main.c:1214:7
    #4 0x7f6c7333e78f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #5 0x419b68 in getenv (/usr/bin/potrace+0x419b68)

0x60200000efd1 is located 0 bytes to the right of 1-byte region [0x60200000efd0,0x60200000efd1)
allocated by thread T0 here:
    #0 0x4d2b25 in calloc /tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/
    #1 0x519776 in bm_new /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap.h:121:30
    #2 0x519776 in bm_readbody_bmp /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:574
    #3 0x519776 in bm_read /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:138
    #4 0x510a45 in process_file /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/main.c:1058:9
    #5 0x50dd56 in main /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/main.c:1214:7
    #6 0x7f6c7333e78f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:754:4 in bm_readbody_bmp
Shadow bytes around the buggy address:
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9df0: fa fa fa fa fa fa fa fa fa fa[01]fa fa fa 04 fa
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb

Affected version:

Fixed version:

Commit fix:

This bug was discovered by Agostino Sarubbo of Gentoo.



2017-02-26: bug discovered and reported to upstream
2017-02-28: upstream released a patch
2017-03-03: blog post about the issue

This bug was found with American Fuzzy Lop.


Nathan Zachary a.k.a. nathanzachary (homepage, bugs)

Overall, I’ve been quite happy with my 2017 Honda Civic EX-T. However, there are some cosmetic changes that I personally think make a world of difference. One of them is debadging it (or removing the “Civic” emblem from the back). Another area for improvement is to swap out the side markers, which by default (and according to law in most of the United States), is amber in colour. As it is the only area on the car that is that gross yellow/orange colour, I thought that it could be vastly improved by swapping it to either clear or some smoked black look. Initially, I ordered the ASEAN market OEM Honda clear side markers on eBay. However, I decided that on my White Orchid Pearl Civic, “smoked black” may look better, so I ordered them instead. Here’s a before-and-after of it:

2017 Honda Civic side marker changed to smoked or clear

Following the great instructions provided by a CivicX forum member, I got started. Though his instructions are spot-on, the procedure for swapping to the non-OEM smoked markers was actually a little easier. Basically, step 4 (cutting the tabs on the socket) was unnecessary. So, a simplified and concise list of the steps required for my particular swap is:

  • Turn the wheels inward to give you more room to access the wheel liner
  • Remove the three screws holding the wheel liner
  • Press on the side marker clip that holds it to the body, whilst simultaneously pushing the marker itself outward away from the body
  • Use a very small flat head screwdriver to depress the tab holding the bulb socket to the harness
  • Swap in a new bulb (if you have one, and I can recommend the Philips 194/T10 white LED bulbs, but realise that since they are white, they will not be “street legal” in many municipalities)
  • Test the polarity once you have inserted the bulb by simply turning on your headlights
  • Place the harness/new bulb/socket into the new side marker (noting that one notch is larger than the rest, which may require rotation of the side marker)
  • Align the new side marker accordingly, and make sure that it snaps into place

The only caveat I found is that the marker on the passenger’s side did not seem to want to snap into place as easily as did the one on the driver’s side. It took a little wiggling, and ultimately required me to press more firmly on the marker itself in order to get it to stay put.

For a process that only took approximately 30 minutes, though, I think that the swap made a world of difference to the overall appearance of the car. I also am happy with my choice to use the white LED bulb, as it shows quite nicely through the smoked lens:

2017 Honda Civic side marker changed to smoked or clear with white LED bulb


March 02, 2017

podofo is a C++ library to work with the PDF file format.

A fuzz on it discovered a null pointer dereference. The upstream project denies me to open a new ticket. So, I just will forward this on the -users mailing list.

The complete ASan output:

# podofocolor dummy $FILE foo
==5815==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f025d243787 bp 0x7ffe33517c50 sp 0x7ffe33517be0 T0)
==5815==The signal is caused by a READ memory access.
==5815==Hint: address points to the zero page.
    #0 0x7f025d243786 in PoDoFo::PdfColorGray::~PdfColorGray() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfColor.cpp:435:1
    #1 0x52c9b2 in GraphicsStack::TGraphicsStackElement::~TGraphicsStackElement() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/graphicsstack.h:29:11
    #2 0x52c9b2 in __gnu_cxx::new_allocator::destroy(GraphicsStack::TGraphicsStackElement*) /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/ext/new_allocator.h:133
    #3 0x52c9b2 in std::deque<GraphicsStack::TGraphicsStackElement, std::allocator >::_M_pop_back_aux() /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/bits/deque.tcc:515
    #4 0x52c9b2 in std::deque<GraphicsStack::TGraphicsStackElement, std::allocator >::pop_back() /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/bits/stl_deque.h:1459
    #5 0x52c9b2 in std::stack<GraphicsStack::TGraphicsStackElement, std::deque<GraphicsStack::TGraphicsStackElement, std::allocator > >::pop() /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/bits/stl_stack.h:218
    #6 0x52c9b2 in GraphicsStack::Pop() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/graphicsstack.cpp:48
    #7 0x522031 in ColorChanger::ReplaceColorsInPage(PoDoFo::PdfCanvas*) /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/colorchanger.cpp:190:35
    #8 0x51ed8e in ColorChanger::start() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/colorchanger.cpp:120:15
    #9 0x51c06d in main /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/podofocolor.cpp:116:12
    #10 0x7f025bd2e61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #11 0x428718 in _start (/usr/bin/podofocolor+0x428718)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfColor.cpp:435:1 in PoDoFo::PdfColorGray::~PdfColorGray()

Affected version:

Fixed version:

Commit fix:

This bug was discovered by Agostino Sarubbo of Gentoo.



2017-02-13: bug discovered
2017-03-02: bug reported to upstream
2017-03-02: blog post about the issue
2017-03-12: CVE assigned

This bug was found with American Fuzzy Lop.


podofo: NULL pointer dereference in PoDoFo::PdfColorGray::~PdfColorGray (PdfColor.cpp)

podofo is a C++ library to work with the PDF file format.

A fuzz on it discovered a null pointer dereference. The upstream project denies me to open a new ticket. So, I just will forward this on the -users mailing list.

The complete ASan output:

# podofocolor dummy $FILE foo
==21036==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fc5cfd94743 bp 0x7ffc1eaffe50 sp 0x7ffc1eaffd40 T0)
==21036==The signal is caused by a READ memory access.
==21036==Hint: address points to the zero page.
    #0 0x7fc5cfd94742 in PoDoFo::PdfXObject::PdfXObject(PoDoFo::PdfObject*) /tmp/portage/app-text/podofo-0.9.5/work/podofo-0.9.5/src/doc/PdfXObject.cpp:264:74
    #1 0x529308 in ColorChanger::start() /tmp/portage/app-text/podofo-0.9.5/work/podofo-0.9.5/tools/podofocolor/colorchanger.cpp:137:28
    #2 0x523b8d in main /tmp/portage/app-text/podofo-0.9.5/work/podofo-0.9.5/tools/podofocolor/podofocolor.cpp:116:12
    #3 0x7fc5cd8d178f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x4300e8 in _start (/usr/bin/podofocolor+0x4300e8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/app-text/podofo-0.9.5/work/podofo-0.9.5/src/doc/PdfXObject.cpp:264:74 in PoDoFo::PdfXObject::PdfXObject(PoDoFo::PdfObject*)

Affected version:

Fixed version:

Commit fix:

This bug was discovered by Agostino Sarubbo of Gentoo.



2017-03-01: bug discovered
2017-03-02: bug reported upstream
2017-03-02: blog post about the issue
2017-03-12: CVE assigned

This bug was found with American Fuzzy Lop.


podofo: NULL pointer dereference in PoDoFo::PdfXObject::PdfXObject (PdfXObject.cpp)

podofo is a C++ library to work with the PDF file format.

A fuzz on it discovered a null pointer dereference. The upstream project denies me to open a new ticket. So, I just will forward this on the -users mailing list.

The complete ASan output:

# podofocolor dummy $FILE foo
==5768==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000018 (pc 0x7f6504f1742c bp 0x7fffc41a0df0 sp 0x7fffc41a0d00 T0)
==5768==The signal is caused by a READ memory access.
==5768==Hint: address points to the zero page.
    #0 0x7f6504f1742b in PoDoFo::PdfVariant::DelayedLoad() const /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfVariant.h:545:10
    #1 0x7f6504f1742b in PoDoFo::PdfVariant::GetArray() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfVariant.h:795
    #2 0x7f6504f1742b in PoDoFo::PdfXObject::PdfXObject(PoDoFo::PdfObject*) /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/doc/PdfXObject.cpp:264
    #3 0x51ff55 in ColorChanger::start() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/colorchanger.cpp:137:28
    #4 0x51c06d in main /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/podofocolor.cpp:116:12
    #5 0x7f650358c61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #6 0x428718 in _start (/usr/bin/podofocolor+0x428718)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfVariant.h:545:10 in PoDoFo::PdfVariant::DelayedLoad() const

Affected version:

Fixed version:

Commit fix:

This bug was discovered by Agostino Sarubbo of Gentoo.



2017-02-13: bug discovered
2017-03-02: bug reported to upstream
2017-03-02: blog post about the issue
2017-03-12: CVE assigned

This bug was found with American Fuzzy Lop.


podofo: NULL pointer dereference in PoDoFo::PdfVariant::DelayedLoad (PdfVariant.h)

Sven Vermeulen a.k.a. swift (homepage, bugs)
cvechecker 3.7 released (March 02, 2017, 09:00 UTC)

After a long time of getting too little attention from me, I decided to make a new cvechecker release. There are few changes in it, but I am planning on making a new release soon with lots of clean-ups.

February 28, 2017
Denis Dupeyron a.k.a. calchan (homepage, bugs)
Gentoo is accepted to GSoC 2017 (February 28, 2017, 00:07 UTC)

There was good news in my mailbox today. The Gentoo Foundation was accepted to be a mentor organization for Google Summer of Code 2017!

What this means is we need you as a mentor, backup mentor or expert mentor. Whether you are a Gentoo developer and have done GSoC before does not matter at this point.

A mentor is somebody who will help during the selection of students, and will mentor a student during the summer. This should take at most one hour of your time on weekdays when student actually work on their project. What’s in it for you, you ask? A pretty exclusive Google T-shirt, a minion who does things you wouldn’t have the time or energy to do, but most importantly gratification and a lot of fun.

Backup mentors are for when the primary mentor of a student becomes unavailable for an extended period, typically for medical or family reasons. It rarely happens but it does happen. But a backup mentor can also be an experienced mentor (i.e., have done it at least once) who assists a primary mentor who is doing it for the first time.

Expert mentors have a very specific knowledge and are contacted on an as-needed basis to help with technical decisions.

You can be any combination of all that. However, our immediate need in the coming weeks is for people (again, not necessarily mentors or devs) who will help us evaluate student proposals.

If you’re a student, it’s the right time now to start thinking about what project idea you would want to work on during the summer. You can find ideas on our dedicated page, or you can come up with yours (these are the best!). One note though: you are going to be working on this full-time (i.e., 8 hours a day, we don’t allow for another even part-time job next to GSoC, although we do accommodate students who have a limited amount of classes or exams) for 3 months, so make sure your idea can keep you busy for this long. Whether you pick one of our ideas or come up with yours, it is strongly recommended to start discussing it with us on IRC.

As usual, we’d love to chat with you or answer your questions in #gentoo-soc on Freenode IRC. Make sure you stay long enough in the channel and give us enough time to respond to you. We are all volunteers and can’t maintain a 24/7 presence. It can take up to a few hours for one of us to see your request.

February 27, 2017
Thoughts on Mr Gates' Robot tax (February 27, 2017, 20:54 UTC)

In an article in QARTS Bill Gates, co-founder of Microsoft, propose that "The robot that takes your job should pay taxes". The issue also got a practical discussion outside of newspapers as the European Parliament rejected a similar proposal on February 16th, 2017 The debate is, however, an interesting one and in many ways an … Continue reading "Thoughts on Mr Gates' Robot tax"

Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Reverse Engineering Notes: Accu-Chek Mobile (February 27, 2017, 09:04 UTC)

A couple of years ago, upon suggestion by a reader of this blog, I switched my glucometer to an Accu-Chek Mobile by Roche. I have not even looked into reverse engineering it at the time, as the killer application of that meter was not needing software at all. Indeed all the data is made available over a USB Mass Storage interface as CSV and graphs.

While there is a secondary interface available on the device to connect to software on PC, you had to order a copy of the download software online and receive it physically to be able to download the data to a computer, which I still find kind of silly for a device that is designed to have a standard USB connector.

Things changed recently, as Roche joined Abbott (and probably more to come) on the bandwagon of “show us yours”: upload your blood glucose reading to their cloud systems, and they will help you managing diabetes. I guess this is what happens when people are not waiting. I’m not particularly fond of uploading my health information to the cloud, but signing up for this service also meant being able to grab a proper chatter of the protocol over USB.

The software I’m using right now for snooping over the USB connection is USBlyzer which is proprietary and closed source — I’m not proud, but it gets its job done. I have been thinking of switching of a hardware snooping solution, and I bought a BeagleBone Black to use for that, but I have not started working on that due to time.

So instead, I have collected over time a set of libraries and utilities that operate on the CSV files that the software export (particularly as with version 2.2 they are actually quite well written, the older version was messier to post-process). I should look into publishing this collection, and I promise I’ll give it a try to publish before end of this year.

One of the tools I have prints out the “chatter”, coded hexdumps with include direction information to make it easier for me to read the stream. The first run of it was a bit noisy, but a quick check told me that what I’m interested in is bulk transfers (rather than control transfers, which are the most basic), so I filtered for those only, and then the first thing became obvious very quickly.

The maximum length of the bulk transfers in the trace is 64 bytes, which corresponds to the maximum size of bulk transfers for full speed endpoints. But the chatter shows the device sending multiple packets back from a single command, which is not unusual, as you can’t fit much blood sugar data in 64 bytes. And as usual when there is fragmentation, the actual data transfer size is coded somewhere at the beginning of the message.

0023 >>>> 00000000: E3 00 00 2C 00 03 50 79  00 26 80 00 00 00 80 00  ...,..Py.&......
0023 >>>> 00000010: 80 00 00 00 00 00 00 00  80 00 00 00 00 08 00 60  ...............`
0023 >>>> 00000020: 19 00 01 08 00 00 00 00  00 01 01 01 00 00 00 00  ................

0025 <<<< 00000000: E7 00 01 0A 01 08 00 00  01 01 01 02 00 00 FF FF  ................
0025 <<<< 00000010: FF FF 0D 1C 00 F8 50 00  00 05 00 F2 00 06 00 01  ......P.........
0025 <<<< 00000020: 00 04 00 24 09 2F 00 04  00 02 71 BC 0A 46 00 02  ...$./....q..F..
0025 <<<< 00000030: F0 40 09 96 00 02 08 52  0A 55 00 0C 00 02 00 08  .@.....R.U......
0025 <<<< 00000040: 09 90 00 08 0A 4C 00 02  00 06 00 02 00 04 00 24  .....L.........$
0025 <<<< 00000050: 09 2F 00 04 00 02 71 D0  0A 46 00 02 F0 40 09 96  ./....q..F...@..
0025 <<<< 00000060: 00 02 08 52 0A 55 00 0C  00 02 00 08 09 90 00 08  ...R.U..........
0025 <<<< 00000070: 0A 4C 00 02 00 05 00 03  00 03 00 1E 09 2F 00 04  .L.........../..
0025 <<<< 00000080: 00 80 71 D8 0A 46 00 02  F0 40 0A 55 00 0C 00 02  ..q..F...@.U....
0025 <<<< 00000090: 00 08 09 90 00 08 0A 66  00 02 00 05 00 04 00 03  .......f........
0025 <<<< 000000A0: 00 1E 09 2F 00 04 00 80  72 48 0A 46 00 02 F0 48  .../....rH.F...H
0025 <<<< 000000B0: 0A 55 00 0C 00 02 00 08  09 90 00 08 0A 49 00 02  .U...........I..
0025 <<<< 000000C0: 00 3D 00 05 00 08 00 46  0A 4D 00 02 98 20 09 43  .=.....F.M... .C
0025 <<<< 000000D0: 00 02 00 00 09 41 00 04  00 00 17 70 09 44 00 04  .....A.....p.D..
0025 <<<< 000000E0: 00 00 01 E5 09 53 00 02  00 00 0A 57 00 12 00 10  .....S.....W....
0025 <<<< 000000F0: 50 61 74 69 65 6E 74 20  52 65 73 75 6C 74 73 00  Patient Results.
0025 <<<< 00000100: 09 51 00 02 00 04 0A 63  00 04 00 00 5D C0        .Q.....c....].

0047 >>>> 00000000: E7 00 00 0E 00 0C 00 01  01 03 00 06 00 00 00 00  ................
0047 >>>> 00000010: 00 00                                             ..

0049 <<<< 00000000: E7 00 00 F6 00 F4 00 01  02 03 00 EE 00 00 00 08  ................
0049 <<<< 00000010: 00 E8 09 28 00 0E 00 06  52 6F 63 68 65 00 00 04  ...(....Roche...
0049 <<<< 00000020: 31 32 30 35 09 84 00 0A  00 08 00 60 19 04 B5 1B  1205.......`....
0049 <<<< 00000030: DF 5C 0A 44 00 02 40 00  09 2D 00 78 00 04 00 74  .\.D..@..-.x...t
0049 <<<< 00000040: 00 01 00 00 00 18 73 65  72 69 61 6C 2D 6E 75 6D  ......serial-num
0049 <<<< 00000050: 62 65 72 3A 20 30 30 31  38 32 36 36 35 32 00 04  ber: 001826652..
0049 <<<< 00000060: 00 00 00 14 73 77 2D 72  65 76 20 4D 45 3A 20 56  ....sw-rev ME: V
0049 <<<< 00000070: 30 33 2E 31 33 20 20 20  00 05 00 00 00 16 66 77  03.13   ......fw
0049 <<<< 00000080: 2D 72 65 76 69 73 69 6F  6E 3A 20 56 30 33 2E 39  -revision: V03.9
0049 <<<< 00000090: 30 20 20 20 00 06 00 00  00 1A 70 72 6F 74 6F 63  0   ......protoc
0049 <<<< 000000A0: 6F 6C 2D 72 65 76 69 73  69 6F 6E 3A 20 52 50 43  ol-revision: RPC
0049 <<<< 000000B0: 20 31 2E 30 09 87 00 08  20 17 02 24 21 07 00 00   1.0.... ..$!...
0049 <<<< 000000C0: 0A 45 00 10 C0 00 1F 00  FF FF FF FF 00 64 00 00  .E...........d..
0049 <<<< 000000D0: 00 00 00 00 0A 4B 00 16  00 02 00 12 02 01 00 08  .....K..........
0049 <<<< 000000E0: 01 05 00 01 00 02 20 11  02 02 00 02 00 00 0A 5A  ...... ........Z
0049 <<<< 000000F0: 00 08 00 01 00 04 10 11  00 01                    ..........

As you can see in this particular exchange, bytes at offset 2-3 represent a (big-endian) length for the whole transfer. You just keep reading until that is complete.

While I have not (yet at the time of writing) figured out what the command and response actually convey, one thing that is kind of obvious is that there is some kind of (type-)length-value encoding at play, although in a bit of a funny way.

All records with type 0xE700 appear to have two-level lengths, as you can see on the two responses and the second command: in red it’s the length of the packet, in magenta the same length minus two (which matches the size of the length itself). There are also a number of strings, some zero terminated (Roche\0) and some not (1205), but still encoded with a 16-bit length in front of them.

The next thing to figure out in these cases is whether there is a checksum or not. For effectively all the meters I have reverse engineered up to now, except for maybe the cheap Korean one, include a checksum somewhere. I checked the chatter and found that there are a number of packets that appear to include the same information, but adding a checksum to the packet showed them different.

Once I dumped the (recomposed) packets to binary files, I noticed a number of packets with the same sizes. hexdump, wdiff and colordiff make it very easy to tell what changed between them. It didn’t quite look like a cryptographic checksum, as changing one byte would replace it with a very different number, but it didn’t quite match up with a “dumb” checksum of all the bytes values.

A couple of diff later, it become obvious.

[flameeyes@saladin Accu-Chek]$ wdiff <(hexdump -C 0039-0034-in) <(hexdump -C 0049-0046-in) | colordiff
00000000  e7 00 00 f6 00 f4 00 [-2d-] {+01+}  02 03 00 ee 00 00 00 08  [-|.......-........|-]  {+|................|+}
00000010  00 e8 09 28 00 0e 00 06  52 6f 63 68 65 00 00 04  |...(....Roche...|
00000020  31 32 30 35 09 84 00 0a  00 08 00 60 19 04 b5 1b  |1205.......`....|
00000030  df 5c 0a 44 00 02 40 00  09 2d 00 78 00 04 00 74  |.\.D..@..-.x...t|
00000040  00 01 00 00 00 18 73 65  72 69 61 6c 2d 6e 75 6d  |......serial-num|
00000050  62 65 72 3a 20 30 30 31  38 32 36 36 35 32 00 04  |ber: 001826652..|
00000060  00 00 00 14 73 77 2d 72  65 76 20 4d 45 3a 20 56  |....sw-rev ME: V|
00000070  30 33 2e 31 33 20 20 20  00 05 00 00 00 16 66 77  |03.13   ......fw|
00000080  2d 72 65 76 69 73 69 6f  6e 3a 20 56 30 33 2e 39  |-revision: V03.9|
00000090  30 20 20 20 00 06 00 00  00 1a 70 72 6f 74 6f 63  |0   ......protoc|
000000a0  6f 6c 2d 72 65 76 69 73  69 6f 6e 3a 20 52 50 43  |ol-revision: RPC|
000000b0  20 31 2e 30 09 87 00 08  20 17 02 24 21 [-06 53-] {+07 00+} 00  | 1.0.... [-..$!.S.|-] {+..$!...|+}
000000c0  0a 45 00 10 c0 00 1f 00  ff ff ff ff 00 64 00 00  |.E...........d..|
000000d0  00 00 00 00 0a 4b 00 16  00 02 00 12 02 01 00 08  |.....K..........|
000000e0  01 05 00 01 00 02 20 11  02 02 00 02 00 00 0a 5a  |...... ........Z|
000000f0  00 08 00 01 00 04 10 11  00 01                    |..........|
[flameeyes@saladin Accu-Chek]$ wdiff <(hexdump -C 0039-0034-in) <(hexdump -C 0073-0068-in) | colordiff
00000000  e7 00 00 f6 00 f4 00 [-2d-] {+02+}  02 03 00 ee 00 00 00 08  [-|.......-........|-]  {+|................|+}
00000010  00 e8 09 28 00 0e 00 06  52 6f 63 68 65 00 00 04  |...(....Roche...|
00000020  31 32 30 35 09 84 00 0a  00 08 00 60 19 04 b5 1b  |1205.......`....|
00000030  df 5c 0a 44 00 02 40 00  09 2d 00 78 00 04 00 74  |.\.D..@..-.x...t|
00000040  00 01 00 00 00 18 73 65  72 69 61 6c 2d 6e 75 6d  |......serial-num|
00000050  62 65 72 3a 20 30 30 31  38 32 36 36 35 32 00 04  |ber: 001826652..|
00000060  00 00 00 14 73 77 2d 72  65 76 20 4d 45 3a 20 56  |....sw-rev ME: V|
00000070  30 33 2e 31 33 20 20 20  00 05 00 00 00 16 66 77  |03.13   ......fw|
00000080  2d 72 65 76 69 73 69 6f  6e 3a 20 56 30 33 2e 39  |-revision: V03.9|
00000090  30 20 20 20 00 06 00 00  00 1a 70 72 6f 74 6f 63  |0   ......protoc|
000000a0  6f 6c 2d 72 65 76 69 73  69 6f 6e 3a 20 52 50 43  |ol-revision: RPC|
000000b0  20 31 2e 30 09 87 00 08  20 17 02 24 21 [-06 53-] {+07 02+} 00  | 1.0.... [-..$!.S.|-] {+..$!...|+}
000000c0  0a 45 00 10 c0 00 1f 00  ff ff ff ff 00 64 00 00  |.E...........d..|
000000d0  00 00 00 00 0a 4b 00 16  00 02 00 12 02 01 00 08  |.....K..........|
000000e0  01 05 00 01 00 02 20 11  02 02 00 02 00 00 0a 5a  |...... ........Z|
000000f0  00 08 00 01 00 04 10 11  00 01                    |..........|
[flameeyes@saladin Accu-Chek]$ wdiff <(hexdump -C 0039-0034-in) <(hexdump -C 0087-0084-in) | colordiff
00000000  e7 00 00 f6 00 f4 00 [-2d-] {+04+}  02 03 00 ee 00 00 00 08  [-|.......-........|-]  {+|................|+}
00000010  00 e8 09 28 00 0e 00 06  52 6f 63 68 65 00 00 04  |...(....Roche...|
00000020  31 32 30 35 09 84 00 0a  00 08 00 60 19 04 b5 1b  |1205.......`....|
00000030  df 5c 0a 44 00 02 40 00  09 2d 00 78 00 04 00 74  |.\.D..@..-.x...t|
00000040  00 01 00 00 00 18 73 65  72 69 61 6c 2d 6e 75 6d  |......serial-num|
00000050  62 65 72 3a 20 30 30 31  38 32 36 36 35 32 00 04  |ber: 001826652..|
00000060  00 00 00 14 73 77 2d 72  65 76 20 4d 45 3a 20 56  |....sw-rev ME: V|
00000070  30 33 2e 31 33 20 20 20  00 05 00 00 00 16 66 77  |03.13   ......fw|
00000080  2d 72 65 76 69 73 69 6f  6e 3a 20 56 30 33 2e 39  |-revision: V03.9|
00000090  30 20 20 20 00 06 00 00  00 1a 70 72 6f 74 6f 63  |0   ......protoc|
000000a0  6f 6c 2d 72 65 76 69 73  69 6f 6e 3a 20 52 50 43  |ol-revision: RPC|
000000b0  20 31 2e 30 09 87 00 08  20 17 02 24 [-21 06 53-] {+20 55 15+} 00  | 1.0.... [-..$!.S.|-] {+..$ U..|+}
000000c0  0a 45 00 10 c0 00 1f 00  ff ff ff ff 00 64 00 00  |.E...........d..|
000000d0  00 00 00 00 0a 4b 00 16  00 02 00 12 02 01 00 08  |.....K..........|
000000e0  01 05 00 01 00 02 20 11  02 02 00 02 00 00 0a 5a  |...... ........Z|
000000f0  00 08 00 01 00 04 10 11  00 01                    |..........|

It may become much clearer if you go back at the first dump and observe the part highlighted in blue: it’s 8 bytes that represent 20 17 02 24 21 07 00 00. To help understanding this, you should know that I was looking at this around 9pm on February 24th, 2017. Indeed, these bytes effectively represent the date and time in binary-coded decimal, which is not something I was expecting to see, but make sense.

Once you know this, it’s easy to tell that there is no checksum in the messages, and that is one less problem to worry about. Indeed, when looking for the “big” packets, I could find the telltale representation of fixed-size records with what looked like (and I confirmed being) glucometer readings (in mg/dL, even though the device is mmol/l based).

If you’re wondering why the peculiar change in time on the last part of the diff, the reason is quite simple: the software noted that the time on the device didn’t match the time on the computer, and asked me to sync it. Which means I also know the command to set the time now.

Looking at the commands, there are a few more things that are interesting to see:

0037 >>>> 00000000: E7 00 00 0E 00 0C 00 2D  01 03 00 06 00 00 00 00  .......-........
0037 >>>> 00000010: 00 00                                             ..

0047 >>>> 00000000: E7 00 00 0E 00 0C 00 01  01 03 00 06 00 00 00 00  ................
0047 >>>> 00000010: 00 00                                             ..

0071 >>>> 00000000: E7 00 00 0E 00 0C 00 02  01 03 00 06 00 00 00 00  ................
0071 >>>> 00000010: 00 00                                             ..

0081 >>>> 00000000: E7 00 00 1A 00 18 00 03  01 07 00 12 00 00 0C 17  ................
0081 >>>> 00000010: 00 0C 20 17 02 24 20 54  57 00 00 00 00 00        .. ..$ TW.....

0085 >>>> 00000000: E7 00 00 0E 00 0C 00 04  01 03 00 06 00 00 00 00  ................
0085 >>>> 00000010: 00 00                                             ..

0095 >>>> 00000000: E7 00 00 14 00 12 00 05  01 07 00 0C 00 05 0C 0D  ................
0095 >>>> 00000010: 00 06 00 01 00 02 00 00                           ........

The time change command is 0081 (and I highlighted in green the new time, also provided as BCD). The remaining commands appear to be querying some information about the device. Commands 0037, 0047, 0071 and 0085 are exactly the same, except as I found out initially, no packet was identical. In blue I highlighted what appears to be a packet counter of sorts. I’m not sure why it starts at 0x2D, but after that it appears to increment normally, although only after 0xE7 commands (there appear to be a handful more).

Unfortunately this does not cover enough of the protocol yet, but it’s a good starting point for a few hours spent trying to prod things around on a Friday night (what an exciting life I live). I also managed to find how the device is reporting the readings, in blocks of less than 1KB records, but I have not figure out how the software knows when to stop asking for them. In this case it definitely is handy that I have so many readings on the device — this is probably the glucometer I used the most, and I still think is the best blood-reading glucometer, for handiness and results.

Stay tuned for more details, and hopefully to see a spec for the protocol soon, too.

Steev Klimaszewski a.k.a. steev (homepage, bugs)
And we’re back (February 27, 2017, 08:14 UTC)

Not entirely sure what happened, but hey, back online and such. Everything is gone from the old site (sorry all you old referrers 🙁 ) But hey, maybe now I’ll actually update more often and post more often.

Hello world! (February 27, 2017, 01:47 UTC)

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

February 24, 2017
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Password Managers and U2F (February 24, 2017, 00:04 UTC)

Yet another blog post that starts with a tweet, or two. Even though I’m not by either trade or training clearly a security person, I have a vested interest in security as many of you know, and I have written (or ranted) a lot about passwords and security in the past. I have in particular argued for LastPass as a password manager, and at the same time for U2F security keys for additional security (as you can notice in this post as I added an Amazon link to one).

The other week, a side-by-side of the real PayPal login window and a phishing one that looked way too similar was posted, and I quoted the tweet asking PayPal why do they still not support U2F — technically PayPal does support 2-factors authentication, but that as far as I know that is only for US customers, and it is based on a physical OTP token.

After I tweeted that, someone who I would have expected to understand the problem better, argued that password managers and random passwords completely solve the phishing problem. I absolutely disagree and I started arguing it on Twitter, but the 140 characters limit makes it very difficult to provide good information, and particularly to refer to it later on. So here is the post.

The argument: you can’t phish a password you don’t know, and using password managers, you don’t have to (or have a way to) know that password. Works well in theory, but let’s see how that does not actually work.

Password managers allow you to generate a random, complex password (well, as long as the websites allow you to), and thanks to features such as autofill, you never actually get to see the password. This is good.

Unfortunately, there are plenty of cases in which you need to either see, read, or copy to clipboard the password. Even LastPass, which has, in my opinion, a well defined way to deal with “equivalent domains”, is not perfect: not all Amazon websites are grouped together, for instance. While they do provide an easy way to add more domains to the list of equivalency, it does mean I have about 30 of them customised for my own account right now.

What this means is that users are actually trained to the idea that sometimes the autofill won’t work because the domain is just not in the right list. And even when it is, sometimes the form has changed, and autofill just does not work. I have seen plenty of those situations myself. And so, even though you may not know the password, phishing works if it convinces you that the reason why autofill is not working is not because the site is malicious, but just because the password manager is broken/not working as intended/whatever else.

This becomes even more likely when you’re using one of the more “open” password managers. Many think LastPass is bad, not just because they store your password server-side (encrypted) but also because it interacts directly with the browser. After all, the whole point of the LostPass vulnerability was that UI is hard. So the replacements for geeks who want to be even more secure usually is a separate app that requires you to copy-paste your password from it to the browser. And in that case, you may not know the password, but you can still be phished.

If you want to make the situation even more ridiculous, go back to read my musings on bank security. My current bank (and one of my former ones) explicitly disallow you from using either autofill or copy-paste. Worse they ask you to fill in parts of your password, e.g. “the 2nd, 4th, 12th character of your password” — so you either end up having to use a mnemonic password or you have to look at your password manager and count. And that is very easily phisable. Should I point out that they insist that this is done to reduce chances of phishing?

I have proposed some time ago a more secure way to handle equivalent domains, in which websites can feed back information to the password managers on who’s what. There is some support for things like this on iOS at least, where I think the website can declare which apps are allowed to take over links to themselves. But as far as I know, even now that SmartLock is a thing, Chrome/Android do not support anything like that. Nor does LastPass. I’m sad.

Let me have even more fun about password managers, U2F, and feel okay with having a huge Amazon link at the top of this post:

Edit: full report is available for those who just don’t believe the infographic.

This is not news, I have written about this over two years ago after U2F keys were announced publicly — I have been using one before that, that is not mystery clearly. Indeed, unlike autofill and copy-paste, U2F identification does not involve interaction with the user-person, but is rather tied to the website’s own identification, which means it can’t be phished.

Phishing, as described in the NilePhish case above, applies just as equally to SMS, Authenticator apps and push-notifications, because what the user may perceive is just a little bit more delay. It’s not impossible, though a bit complicated, for a “sophisticated” (or well-motivated) attacker to just render the same exact page as the original site, defeating all those security theatre measure such as login-request IDs, custom avatars and custom phrases — or systems that ask you the 4th, 9th and 15th characters of your password.

User certificates, whether as a file enrolled in the operating system or on a smartcard, are of course an even stronger protection than U2F, but having used them, they are not really that friendly. That’s a topic for another day, though.

February 20, 2017
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
The geeks' wet dreams (February 20, 2017, 18:04 UTC)

As a follow up to my previous rant about FOSDEM I thought I would talk to what I define the “geeks’ wet dream”: IPv6 and public IPv4.

During the whole Twitter storm I had regarding IPv6 and FOSDEM, I said out loud that I think users should not care about IPv6 to begin with, and that IPv4 is not a legacy protocol but a current one. I stand by my description here: you can live your life on the Internet without access to IPv6 but you can’t do that without access to IPv4, at the very least you need a proxy or NAT64 to reach a wide variety of the network.

Having IPv6 everywhere is, for geeks, something important. But at the same time, it’s not really something consumers care about, because of what I just said. Be it for my mother, my brother-in-law or my doctor, having IPv6 access does not give them any new feature they would otherwise not have access to. So while I can also wish for IPv6 to be more readily available, I don’t really have any better excuse for it than making my personal geek life easier by allowing me to SSH to my hosts directly, or being able to access my Transmission UI from somewhere else.

Yes, there is a theoretical advantage for speed and performance, because NAT is not involved, but to be honest for most people that is not what they care about: a 36036 Mbit connection is plenty fast enough even when doing double-NAT, and even Ultra HD, 4K, HDR resolution is well provided by that. You could argue that an even lower latency network may enable more technologies to be available, but that not only sounds to me like a bit of a stretch, it also misses the point once again.

I already liked to Todd’s post, and I don’t need to repeat it here, but if it’s about the technologies that can be enabled, it should be something the service providers should care about. Which by the way is what is happening already: indeed the IPv6 forerunners are the big player companies that effectively are looking for a way to enable better technology. But at the same time, a number of other plans were executed so that better performance can be gained without gating it to the usage of a new protocol that, as we said, really brings nothing to the table.

Indeed, if you look at protocols such as QUIC or HTTP/2, you can notice how these reduce the amount of ports that need to be opened, and that has a lot to do with the double-NAT scenario that is more and more common in homes. Right now I’m technically writing under a three-layers NAT: the carrier-grade NAT used by my ISP for deploying DS-Lite, the NAT issued by my provider-supplied router, and the last NAT which is set up by my own router, running LEDE. I don’t even have a working IPv6 right now for various reasons, and know what? The bottleneck is not the NATs but rather the WiFi.

As I said before, I’m not doing a full Todd and thinking that ignoring IPv6 is a good idea, or that we should not spend any time fixing things that break with it. I just think that we should get a sense of proportion and figuring out what the relative importance of IPv6 is in this world. As I said in the other post, there are plenty of newcomers that do not need to be told to screw themselves if their systems don’t support IPv6.

And honestly the most likely scenario to test for is a dual-stack network in which some of the applications or services don’t work correctly because they misunderstand the system. Like OVH did. So I would have kept the default network dual-stack, and provided a single-stack, NAT64 network as a “perk”, for those who actually do care to test and improve apps and services — and possibly also have a clue not to go and ping a years old bug that was fixed but not fully released.

But there are more reasons why I call these dreams. A lot of the reasoning behind IPv6 appears to be grounded into the idea that geeks want something, and that has to be good for everybody even when they don’t know about it: IPv6, publicly-routed IPv4, static addresses and unfiltered network access. But that is not always the case.

Indeed, if you look even just at IPv6 addressing, and in particular to how stateless addressing works, you can see how there has been at least three different choices at different times for generating them:

  • Modified EUI-64 was the original addressing option, and for a while the only one supported; it uses the MAC address of the network card that receives the IPv6, and that is quite the privacy risk, as it means you can extract an unique identifier of a given machine and identify every single request coming from said machine even when it moves around different IPv6 prefixes.
  • RFC4941 privacy extensions were introduced to address that point. These are usually enabled at some point, but these are not stable: Wikipedia correctly calls these temporary addresses, and are usually fine to provide unique identifiers when connecting to an external service. This makes passive detection of the same machine across network not possible — actually, it makes it impossible to detect a given machine even in the same network, because the address changes over time. This is good on one side, but it means that you do need session cookies to maintain login section active, as you can’t (and you shouldn’t) rely on the persistence of an IPv6 address. It also allows active detection, at least of the presence of a given host within a network, as it does not by default disable the EUI-64 address, just not use it to connect to services.
  • RFC7217 adds another alternative for address selection: it provides a stable-within-a-network address, making it possible to keep long-running connections alive, and at the same time ensuring that at least a simple active probing does not give up the presence of a known machine in the network. For more details, refer to Lubomir Rintel’s post as he went in more details than me on the topic.

Those of you fastest on the uptake will probably notice the connection with all these problems: it all starts by designing the addressing assuming that the most important addressing option is stable and predictable. Which makes perfect sense for servers, and for the geeks who want to run their own home server. But for the average person, these are all additional risks that do not provide any desired additional feature!

There is one more extension to this: static IPv4 addresses suffer from the same problem. If your connection is always coming from the same IPv4 address, it does not matter how private your browser may be, your connections will be very easy to track across servers — passively, even. What is the remaining advantage of a static IP address? Certainly not authentication, as in 2017 you can’t claim ignorance of source address spoofing.

And by the way this is the same reason why providers started issuing dynamic IPv6 prefixes: you don’t want a household (if not a person strictly) to be tied to the same address forever, otherwise passive tracking is effectively a no-op. And yes, this is a pain for the geek in me, but it makes sense.

Static, publicly-routable IP addresses make accessing services running at home much easier, but at the same time puts you at risk. We all have been making about the “Internet of Things”, but at the same time it appears everybody wants to be able to set their own devices to be accessible from the outside, somehow. Even when that is likely the most obvious way for external attackers to access one’s unprotected internal network.

There are of course ways around this that do not require such a publicly routable address, and they are usually more secure. On the other hand, they are not quite a panacea of course. Indeed they effectively require a central call-back server to exist and be accessible, and usually that is tied to a single company, with customise protocols. As far as I know, no open-source such call-back system appears to exist, and that still surprises me.

Conclusions? IPv6, just like static and publicly routable IP addresses, are interesting tools that are very useful to technologists, and it is true that if you consider the original intentions behind the Internet these are pretty basic necessities, but if you think that the world, and thus requirements and importance of features, have not changed, then I’m afraid you may be out of touch.

February 18, 2017
Sebastian Pipping a.k.a. sping (homepage, bugs)


Just a quick tip on how to easily create a Fedora chroot environment from (even a non-Fedora) Linux distribution.

I am going to show the process on Debian stretch but it’s not be much different elsewhere.

Since I am going to leverage pip/PyPI, I need it available — that and a few non-Python widespread dependencies:

# apt install python-pip db-util lsb-release rpm yum
# pip install image-bootstrap pychroot

Now for the actual chroot creation, process and usage is very close to debootstrap of Debian:

# directory-bootstrap fedora --release 25 /var/lib/fedora_25_chroot

Done. Now let’s prove we have actual Fedora 25 in there. For lsb_release we need package redhat-lsb here, but the chroot was is functional before that already.

# pychroot /var/lib/fedora_25_chroot dnf -y install redhat-lsb
# pychroot /var/lib/fedora_25_chroot lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:[..]:printing-4.1-noarch
Distributor ID: Fedora
Description:    Fedora release 25 (Twenty Five)
Release:        25
Codename:       TwentyFive

Note the use of pychroot which does bind mounts of /dev and friends out of the box, mainly.

directory-bootstrap is part of image-bootstrap and, besides Fedora, also supports creation of chroots for Arch Linux and Gentoo.

See you 🙂

Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Reverse Engineering is just the first step (February 18, 2017, 13:03 UTC)

Last year I said that reverse engineering obsolete systems is useful giving as an example adding Coreboot support for very old motherboards that are simpler and whose components are more likely to have been described somewhere already. One thing that I realized I didn’t make very clear in that post is that there is an important step on reverse engineering: documenting. As you can imagine from this blog, I think that documenting the reverse engineering processes and results are important, but I found out that this is definitely not the case for everybody.

On the particularly good side, going to 33c3 had a positive impression on me. Talks such as The Ultimate GameBoy Talk were excellent: Michael Steil did an awesome job at describing a lot of the unknown details of Nintendo’s most popular handheld. He also did a great job at showing practical matters, such as which tricks did various games use to implement things that at first sight would look impossible. And this is only one of his talks, he has a series that is going on year after year, I’ve watched his talk about the Commodore 64, and the only reason why it’s less enjoyable to watch is that the recording quality suffers from the ages.

In other posts I already referenced Micah’s videos. These have also been extremely nice to start watching, as she does a great job at explaining complex concepts, and even the “stream of consciousness” streams are very interesting and a good time to learn new tricks. What attracted me to her content, though, is the following video:

I have been using Wacom tablets for years, and I had no idea how they really worked behind the scene. Not only she does a great explanation of the technology in general, but the teardown of the mouse was also awesome with full schematics and explanation of the small components. No wonder I have signed up for her Patreon right away: she deserve to be better known and have a bigger following. And if funding her means spreading more knowledge around, well, then I’m happy to do my bit.

For the free software, open source and hacking community, reverse engineering is only half the process. The endgame is not for one person to know exactly how something works, but rather for the collectivity to gain more insight on things, so that more people have access to the information and can even improve on it. The community needs not only to help with that but also to prioritise projects that share information. And that does not just mean writing blogs about things. I said this before: blogs don’t replace documentation. You can see blogs as Micah’s shop-streaming videos, while documentation is more like her video about the tablets: they synthesize documentation in actually usable form, rather than just throwing information around.

I have a similar problem of course: my blog posts are not usually a bit of a stream of consciousness and they do not serve an useful purpose to capture the factual state of information. Take for example my post about reverse engineering the OneTouch Verio and its rambling on, then compare it with the proper protocol documentation. The latter is the actual important product, compared to my ramblings, and that is the one I can be proud of. I would also argue that documenting these things in a easily consumable form is more important than writing tools implementing them as those only cover part of the protocol and in particular can only leverage my skills, that do not involve statistical, pharmaceutical or data visualisation skills.

Unfortunately there are obstacles to these idea of course. Sometimes, reverse engineering documentation is attacked by manufacturer even more than code implementing the same information. So for instance while I have some information I still haven’t posted about a certain gaming mouse, I already know that the libratbag people do not want documentation of the protocols in their repository or wiki, because it causes them more headaches than the code. And then of course there is the problem of hosting this documentation somewhere.

I have been pushing my documentation on GitHub, hoping nobody causes a stink, but the good thing about using git rather than Wiki or similar tools is exactly that you can just move it around without losing information. This is not always the case: a lot of documentation is still nowadays only available either as part of code itself, or on various people’s homepages. And there are at least two things that can happen with that, the first is the most obvious and morbid one: the author of the documentation dies, and the documentation disappears once their domain registration expires, or whatever else, or if the homepage is at a given university or other academic endeavour, it may very well be that the homepage gets to disappear before the person anyway.

I know a few other alternatives to store this kind of data have been suggested, including common wiki akin to Wikipedia, but allowing for original research, but I am still uncertain that is going to be very helpful. The most obvious thing I can think of, is making sure these information can actually be published in books. And I think that at least No Starch Press has been doing a lot for this, publishing extremely interesting books including Designing BSD Rootkits and more recently Rootkits and Bootkits which is still in Early Access. A big kudos to Bill for this.

From my side, I promise I’ll try to organize my findings of anything I’ll work on in the best of my ability, and possibly organize it in a different form than just a blog, because the community deserves better.

February 14, 2017
Alice Ferrazzi a.k.a. alicef (homepage, bugs)
2017-02-14 Blog moved to Gentoo blog (February 14, 2017, 10:36 UTC)

The blog as been moved ? here:

Still not sure if the move will be temporary or not.
So for now I will keep both the Blog.

Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
GnuPG and CCID support (February 14, 2017, 00:04 UTC)

As many of you probably know already, I use GnuPG with OpenPGP cards not only for encryption but also for SSH access. As some or others probably noticed on Twitter, I recently decided to restore to life my old Dell Latitude laptop, but since it’s a fairly old system I decided to try running something else rather than Gentoo on it, for the first time in many years. I settled on Antergos, which is a more user friendly install option for Arch Linux. Since I know a number of current or past Arch Linux developers, it seemed fitting.

Beside the obvious problems of Arch not being Gentoo, the first biggest problem I found was being unable to use the smartcard reader in the Dell laptop. The problem is that the BCM5880 device that this laptop comes from, is not quite the most friendly CCID device out there. Actually, it might have a better firmware available but I need to figure out how to install it, since it requires a Windows install and I don’t have one on this laptop.

But why did this work fine with Gentoo and not fine with Arch? Well the answer is that the default install of GnuPG from pacman enables the GnuPG own CCID driver. In my original drawing on the matter I did not capture the fact that GnuPG has its own CCID driver — although I did capture that in a follow-up diagram. This driver is fairly minimal. The idea is that for simple devices, where they implement the standard pretty closely, the driver works fine, and it reduces the amount of dependencies needed to get a smartcard or token working. Unfortunately the number of devices that appear to implement the CCID standard correctly is fairly low in my experience, and the end result is that you still end up having to use pcsc-lite to get this to work as intended.

Luckily, Arch Linux wiki has the answer and you do not need to rebuild GnuPG for this to work. Yay.

It may be easy to say “fix GnuPG” but the list of devices that are not CCID compliant is big, and Ludovic already has workarounds for most of them in the CCID driver. So why should that list of broken devices be repeated somewhere else? There really is no need. if anything, you may ask why the CCID driver is not an interface-independent library that GnuPG can just access directly, and there are actually a few good reasons why this is not the case. The first of which is that it would be pointless to depend on the small driver but not the pcsclite package that implements the otherwise more widely available interface.

As it turns out, though, the particular Gemalto device I use as my primary card card nowadays is actually pretty much CCID compliant, so it could be used with the GnuPG’s own CCID driver, sparing me the need to install and maintain pcsclite and ccid on my other laptop. Which would also mean I could avoid maintaining the packages in Gentoo even. But here is one of the biggest catches: the devices are not by default accessible to the console user. Indeed even when I made it easier to use pcscd and ccid a whopping six years ago, I only set up the udev rules when the CCID driver was installed.

You could expect systemd to just install by default a rule that allows CCID standard devices to be accessible to the console user, and that would make it possible to use GnuPG and its CCID driver with whichever common standard-compliant devices are available. Which I hope (but I have not tested) include the YubiKey 4 (don’t care aobut the NEO, since then you need to make sure to also have the right firmware, as the older ones have a nasty PIN bypass vulnerability.

But then again, I wonder if there are any security issue I don’t really expect that may be impeding a plan like this. Also, given the much wider compatibility of pcsclite with the devices, not only for CCID but for other non-standard protocols too, I would rather be interested to know if you could run pcscd as a user directly, maybe with proper systemd integration — because if there is one good thing about systemd is the ability to run proper per-user services, in a standardised fashion rather than having to fake it the way KDE and GNOME have done for so many years.

As for maintaining the packages on Gentoo, it is not bad at all. The releases are usually good, and very rarely problems came up during packaging. Ludovic’s handling fo the one security issue with pcsc-lite in the past few years has been a bit so-so, as he did not qualify the importance of the security issue in the changelog of the new release that fixed it, but except for that it was punctual and worked fine. The main problem that I have with those tools is having to deal with Alioth, which has this silly idea of adding an unique numeric ID to each file download, and then providing you with the file with whichever name you provide it when you download. Which effectively means you need to update the ID from the Alioth website every time a new release comes up, which is actually annoying.

February 11, 2017
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)

I started drafting this post just before I left Ireland for ENIGMA. While at ENIGMA I realized how important it is to write about this because it is too damn easy to forget about it altogether.

How secure and reliable are our personal infrastructure services, such as our ISPs? My educated guess is, not much.

The start of this story I already talked about: my card got cloned and I had to get it replaced. Among the various services that I needed it replaced in, there were providers in both Italy and Ireland: Wind and Vodafone in Italy, 3 IE in Ireland. As to why I had to use an Irish credit card in Italy, it is because SEPA Direct Debit does not actually work, so my Italian services cannot debit my Irish account directly, as I would like, but they can charge (nearly) any VISA or MasterCard credit card.

Changing the card on Wind Italy was trivial, except that when (three weeks later) I went to restore to the original Tesco card, Chrome 56 reported the site as Not Secure because the login page is served on a non-secure connection by default (which means it can be hijacked by a MITM attack). I bookmarked the HTTPS copy (which load non-encrypted resources, which makes it still unsafe) and will keep using that for the near future.

Vodafone Italy proved more interesting in many ways. The main problem is that I could not actually set up the payment with the temporary card I intended to use (Ulster Bank Gold), the website would just error out on me providing a backend error message — after annoying Vodafone Italy over Twitter, I found out that the problem is in the BIN of the credit card, as the Tesco Bank one is whitelisted in their backend, but the Ulster Bank is not. But that is not all; all the pages of the “Do it yourself” have mixed-content requests, making it not completely secure. But this is not completely uncommon.

What was uncommon and scary was that while I was trying to force them into accepting the card I got to the point where Chrome would not auto-fill the form because not secure. Uh? Turned out that, unlike news outlets, Vodafone decided that their website with payment information, invoices, and call details does not need to be hardened against MITM, and instead allows stripping HTTPS just fine: non-secure cookies and all.

In particular what happened was that the left-side navigation link to “Payment methods” used an explicit http:// link, and the further “Edit payment method” link is a relative link… so it would bring up the form in a non-encrypted page. I brought it up on Twitter (together with the problems with changing the credit card on file), and they appear to have fixed that particular problem.

But almost a month later when I went out to replace the card with the new Tesco replacement card, I managed to find something else with a similar problem: when going through the “flow” to change the way I receive my bill (I wanted the PDF attached), the completion stage redirects me to an HTTP page. And from there, even though the iframes are then loaded over HTTPS, the security is lost.

Of course there are two other problems: the login pane is rendered on HTTP, which means that Chrome 56 and the latest Firefox consider it not secure, and since the downgrade from HTTPS to HTTP does not log me out, it means the cookies are not secure, and that makes it possible for an attacker to steal them with not much difficulty. Particularly as the site does not seem to send any HTTP headers to make the connection safe ( of Mozilla Observatory).

Okay so these two Italian providers have horrible security, but at least I have to say that they mostly worked fine when I was changing the credit cards — despite the very cryptic error that Vodafone decided to give me because my card was foreign. Let’s now see two other (related) providers: Three Ireland and UK — ironically enough, in-between me having to replace the card and writing this post, Wind Italy has completed the merge with Three Italy.

Both the Threes websites are actually fairly secure, as they have a SAML flow on a separate host for login, and then a separate host again for the account management. Even though they also get a bad grade on Mozilla Observatory.

What is more interesting with these two websites is their reliability, or lack thereof. For now almost a month, the Three Ireland website does not allow me to check my connected payment cards, or change them. Which means the automatic top-up does not work and I have to top-up manually. Whenever I try to get to the “Payment Cards” page, it starts loading and then decides to redirect me back to the homepage of the self-service area. It also appears to be using a way to do redirection that is not compatible with some Chrome policy as there is a complicated warning message on the console when that happens.

Three UK is slightly better but not by much. All of this frustrating experience happened just before I left for my trip to the USA for ENIGMA 2017. As I wrote previously I generally use 3 UK roaming there. To use the roaming I need to enable an add-on (after topping up the prepaid account of course), but the add-ons page kept throwing errors. And the documentation suggested to call the wrong number to enable the add-ons on the phone. They gave me the right one over Twitter, though.

Without going into more examples of failures from phone providers, the question for me would be, why is that all we hear about security and reliability comes from either big companies like Google and Facebook, or startups like Uber and AirBnb, but not from ISPs.

While ISPs stopped being the default provider of email for most people years and years ago, they are still the one conduit we need to connect to the rest of the Internet. And when they screw up, they screw up big. Why is it that they are not driving the reliability efforts?

Another obvious question would be whether the open source movement can actually improve the reliability of ISPs by building more tools for management and accounting, just as they used to be more useful to ISPs by building mail and news servers. Unfortunately, that would require admitting that some times you need to be able to restrict the “freedom” of your users, and that’s not something the open source movement has ever been able to accept.

February 09, 2017
Andreas K. Hüttel a.k.a. dilfridge (homepage, bugs)

So, FOSDEM 2017 is over, and as every year it was both fun and interesting. There will for sure be more blog posts, e.g., with photographs from talks by our developers, the booth, the annual Gentoo dinner, or (obviously) the beer event. The Gentoo booth, centrally located just opposite to KDE and Gnome and directly next to CoreOS, was quite popular; it's always great to hear from all the enthusiastic Gentoo fans. Many visitors also prepared, compiled, and installed their own Gentoo buttons at our button machine.
In addition we had a new Gentoo LiveDVD as handout - the "Crispy Belgian Waffle" FOSDEM 2017 edition. For those of you who couldn't make it to Brussels, you can still get it! Download the ISO here and burn it on a DVD or copy it on a USB stick - all done. Many thanks to Fernando Reyes (likewhoa) for all his work!
Finally, for those who are wondering, the "Gentoo Ecosystem" poster from our table can be downloaded as PDF here. It is based on work by Daniel Robbins and mitzip from Funtoo; the source files are available on Github. Of course this poster is continous work in progress, so tell me if you find something missing!

Matthew Thode a.k.a. prometheanfire (homepage, bugs)
Gentoo at Fosdem (February 09, 2017, 06:00 UTC)

At the stand

It was nice to meet everyone and hang out as well. There was an interview with Hacker Public Radio which you can find HERE as well.

Just a short one this time, but it was nice to meet everyone.

February 08, 2017
Bernard Cafarelli a.k.a. voyageur (homepage, bugs)
Tracking Service Function Chaining with Skydive (February 08, 2017, 11:43 UTC)

Skydive is “an open source real-time network topology and protocols analyzer”. It is a tool (with CLI and web interface) to help analyze and debug your network (OpenStack, OpenShift, containers, …). Dropped packets somewhere? MTU issues? Routing problems? These are some issues where running skydive whill help.

So as an update on my previous demo post (this time based on the Newton release), let’s see how we can trace SFC  with this analyzer!

devstack installation

Not a lot of changes here, check out devstack on the stable/newton branch, grab the local.conf file I prepared (configure to use skydive 0.9 release) and run “./”!

For the curious, the SFC/Skydive specific parts are:
enable_plugin networking-sfc stable/newton

# Skydive
enable_plugin skydive refs/tags/v0.9.0
enable_service skydive-agent skydive-analyzer

Skydive web interface and demo instances

Before running the script to configure the SFC demo instances, open the skydive web interface (it listens on port 8082, check your instance firewall if you cannot connect):


The login was configured with devstack, so if you did not change, use admin/pass123456.
Then add the demo instances as in the previous demo:
$ git clone -b sfc_newton_demo
$ ./openstack-scripts/

And watch as your cloud goes from “empty” to “more crowded”:

Skydive CLI, start traffic capture

Now let’s enable traffic capture on the integration bridge (br-int), and all tap interfaces (more details on the skydive CLI available in the documentation):
$ export SKYDIVE_USERNAME=admin
$ export SKYDIVE_PASSWORD=pass123456
$ /opt/stack/go/bin/skydive --conf /tmp/skydive.yaml client capture create --gremlin "G.V().Has('Name', 'br-int', 'Type', 'ovsbridge')"
$ /opt/stack/go/bin/skydive --conf /tmp/skydive.yaml client capture create --gremlin "G.V().Has('Name', Regex('^tap.*'))"

Note this can be done in the web interface too, but I wanted to show both interfaces.

Track a HTTP request diverted by SFC

Make a HTTP request from the source VM to the destination VM (see previous post for details). We will highlight the nodes where this request has been captured: in the GUI, click on the capture create button, select “Gremlin expression”, and use the query:

This expression reads as “on all captured flows matching IP address and port 80, show nodes”. With the CLI you would get a nice JSON output of these nodes, here in the GUI these nodes will turn yellow:

If you look at our tap interface nodes, you will see that two are not highlighted. If you check their IDs, you will find that they belong to the same service VM, the one in group 1 that did not get the traffic.

If you want to single out a request, in the skydive GUI, select one node where capture is active (for example br-int). In the flows table, select the request, scroll down to get its layer 3 tracking ID “L3TrackingID” and use it as Gremlin expression:

Going further

Now it’s your time to experiment! Modify the port chain, send a new HTTP request, get its L3TrackingID, and see its new path. I find the latest ID quickly with this CLI command (we will see how the skydive experts will react to this):
$ /opt/stack/go/bin/skydive --conf /tmp/skydive.yaml client topology query --gremlin "G.Flows().Has('Network','','Transport','80').Limit(1)" | jq ".[0].L3TrackingID"

You can also check each flow in turn, following the paths from a VM to another one, go further with SFC, or learn more about skydive:

February 07, 2017
Sven Vermeulen a.k.a. swift (homepage, bugs)
I missed FOSDEM (February 07, 2017, 16:06 UTC)

I sadly had to miss out on the FOSDEM event. The entire weekend was filled with me being apathetic, feverish and overall zombie-like. Yes, sickness can be cruel. It wasn't until today that I had the energy back to fire up my laptop.

Sorry for the crew that I promised to meet at FOSDEM. I'll make it up, somehow.

Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)

Last year I posted about FOSDEM and the IPv6-only network as a technical solution with no problem: nobody should be running IPv6-only consumer networks, because there is zero advantage to them and lots of disadvantages. This year, despite me being in California and missing FOSDEM, their IPv6-only experiment expanded into a full blown security incident (, and I heard about it over Twitter and Facebook.

I have criticized this entrenched decision of providing a default IPv6-only network, and last night (at the time of writing) I ended up on a full-blown Twitter rage against IPv6 in general. The FOSDEM twitter handler stepped in defending their choice, possibly not even reading correctly my article or understanding that the same @flameeyes they have been replying to is the same owner of, but that’s possibly beside the point:

Let me try to be clear: I do know that the dual-stack network is available. Last year it was FOSDEM-legacy, and this year is FOSDEM-ancient. How many people do you expect to connect to a network that is called ancient? Would you really expect that the ancient network is the only one running the dual-stack routing, rather than, say, a compatibility mode 2.4GHz 802.11b? Let’s get back to that later.

What did actually happen, since the FOSDEM page earlier doesn’t make it too clear: somebody decided that FOSDEM is just as good a place as BlackHat, DEFCON or Chaos Computer Congress to run a malicious hotspot on. So they decided to run a network called “FOSDEM FreeWifi by Google”, with a captive portal asking for your Google account address and password. It was clearly a a low-passion effort, as I noticed from the screenshots over twitter, and by what an unnamed source told me:

  • the login screen looked almost original, but asked for both username and password on the same form, Google never does that;
  • the page was obviously insecure;
  • the page was served over network.

But while these are clearly signs of phishing for a tech user, and would report “Non Secure” on modern Chrome and Firefox, that does not mean they wouldn’t get a non-expert user. Of course the obvious answer of what I will from now on refer to as geek supremacists is that it’s their own fault if they get owned. Which is effectively what FOSDEM said above, paraphrasing: we know nothing of what happened on that network, go and follow Google’s tips on Gmail security.

Well, let me at least point out to go and grab yourself a FIDO key because it would save your skin in cases like that.

But here is a possible way this can fall short of a nice conference experience: there’s a new person interested in Free Software, who has started using Linux or some other FLOSS software and decided to come to what is ostensibly the biggest FLOSS conference in Europe, and probably still the biggest free (as in gratis) open source conference in the world. They are new to this, new to tech, rather than just Linux, and “OpSec” is an unknown term to them.

They arrive at FOSDEM and they try to connect to the default network with their device, which connects and can browse the Internet, but for some reason half the apps don’t work. They ignored the “ancient” network, because their device is clearly not ancient – whether they missed the communication about what it was, or it used the term dual-stack that they had no understanding of – but they see this Google network, let’s do that, even though it requires login… and now someone has their password.

Now the person or people who have their password may be ethical, and contact HIBP to provide a dump of usernames involved and notify them that their passwords were exposed, but probably they won’t. With hope, they won’t use those passwords for anything nefarious either, but at the same time, there is no guarantee that the FreeWifi people are the only ones having a copy of those passwords, because the first unethical person who noticed this phishing going on would have started a WiFi capture to get the clear-text usernames and passwords, with the certainty that if they would use these, the FreeWifi operators would be the ones taking them blame, oops.

Did I say that all the FOSDEM networks are unencrypted? At least 33c3 tried providing an anonymous 802.1x protected/encrypted connection. But of course for the geek supremacists, it’s your fault if you use anything unencrypted and not use a VPN when connecting to public networks. Go and pay the price of not being a geek!

So let’s go back to our new enthusiastic person. If something does happen to the account, it get compromised, or whatever else, the reaction the operators are expecting is probably one of awe: “Oh! They owned me good! I should learn how not to fall for this again!” — except it is quite more likely that the reaction is going to be of distrust “What jerks! Why did I even go there? No kidding nobody uses Linux.” And now we would have alienated one more person that could have become an open source contributor.

Now I have no doubt that FOSDEM organizers didn’t intend for this malicious network to be set up. But at the same time, they allowed it to happen by being too full of themselves, that by making it difficult to users to use the network, they lead to improvement in apps that would otherwise not support IPv6. That’s what they said on twitter: “we are trying to annoy people”. Great, bug fixes via annoyance I’m sure they work great, in a world of network services, that are not in control of the people using them, even for open source projects! And it sure worked great with the Android bug that, fixed almost a year before, kept receiving “me too” and “why don’t you fix this right now?” because most vendors have not released a new version in time for the following FOSDEM (and now an extra year later, many have not moved on from Android 5 either).

Oh and by the way, the reason why it’s called “ancient” is also to annoy people and force them to re-connect to the non-default network. Because calling it FOSDEM-legacy2017 would have been too friendly and would make less of a statement than “ancient”: look at you, you peasant using an ancient network instead of being the coolest geek on the planet and relying on IPv6!

So yes, if something malicious were to happen, I would blame the FOSDEM organizers for allowing that to happen, and for not even providing a “mea culpa” and admitting that maybe they are stressing this point a bit too much.

To close it off, since I do not want to spend too much time on this post on the technical analysis of IPv6 (I did that last year), I would leave you to Todd Underwood’s words and yes, that is an 11 years old post, which I find still relevant. I’m not quite on the same page as Todd, given how I try hard to use IPv6 and use it for backend servers, but his point, if hyperbolic, should be taken into consideration.

Arun Raghavan a.k.a. ford_prefect (homepage, bugs)
Stricter JSON parsing with Haskell and Aeson (February 07, 2017, 05:10 UTC)

I’ve been having fun recently, writing a RESTful service using Haskell and Servant. I did run into a problem that I couldn’t easily find a solution to on the magical bounty of knowledge that is the Internet, so I thought I’d share my findings and solution.

While writing this service (and practically any Haskell code), step 1 is of course defining our core types. Our REST endpoint is basically a CRUD app which exchanges these with the outside world as JSON objects. Doing this is delightfully simple:

{-# LANGUAGE DeriveGeneric #-}

import Data.Aeson
import GHC.Generics

data Job = Job { jobInputUrl :: String
               , jobPriority :: Int
               , ...
               } deriving (Eq, Generic, Show)

instance ToJSON Job where
  toJSON = genericToJSON defaultOptions

instance FromJSON Job where
  parseJSON = genericParseJSON defaultOptions

That’s all it takes to get the basic type up with free serialization using Aeson and Haskell Generics. This is followed by a few more lines to hook up GET and POST handlers, we instantiate the server using warp, and we’re good to go. All standard stuff, right out of the Servant tutorial.

The POST request accepts a new object in the form of a JSON object, which is then used to create the corresponding object on the server. Standard operating procedure again, as far as RESTful APIs go.

The nice part about doing it like this is that the input is automatically validated based on types. So input like:

  "jobInputUrl": 123, // should have been a string
  "jobPriority": 123

will result in:

Error in $: expected String, encountered Number

However, as this nice tour of how Aeson works demonstrate, if the input has keys that we don’t recognise, no error will be raised:

  "jobInputUrl": "",
  "jobPriority": 100,
  "junkField": "junkValue"

This behaviour would not be undesirable in use-cases such as mine — if the client is sending fields we don’t understand, I’d like for the server to signal an error so the underlying problem can be caught early.

As it turns out, making the JSON parsing stricter and catch missing fields is just a little more involved. I didn’t find how this could be done in a single place on the Internet, so here’s the best I could do:

{-# LANGUAGE DeriveDataTypeable #-}
{-# LANGUAGE DeriveGeneric      #-}

import Data.Aeson
import Data.Data
import GHC.Generics

data Job = Job { jobInputUrl :: String
               , jobPriority :: Int
               , ...
               } deriving (Data, Eq, Generic, Show)

instance ToJSON Job where
  toJSON = genericToJSON defaultOptions

instance FromJSON Job where
  parseJSON json = do
    job <- genericParseJSON defaultOptions json
    if keysMatchRecords json job
      return job
      fail "extraneous keys in input"
      -- Make sure the set of JSON object keys is exactly the same as the fields in our object
      keysMatchRecords (Object o) d =
          objKeys   = sort . fmap unpack . keys
          recFields = sort . fmap (fieldLabelModifier defaultOptions) . constrFields . toConstr
          objKeys o == recFields d
      keysMatchRecords _ _          = False

The idea is quite straightforward, and likely very easy to make generic. The Data.Data module lets us extract the constructor for the Job type, and the list of fields in that constructor. We just make sure that’s an exact match for the list of keys in the JSON object we parsed, and that’s it.

Of course, I’m quite new to the Haskell world so it’s likely there are better ways to do this. Feel free to drop a comment with suggestions! In the mean time, maybe this will be useful to others facing a similar problem.

Update: I’ve fixed parseJSON to properly use fieldLabelModifier from the default options, so that comparison actually works when you’re not using Aeson‘s default options. Thanks to /u/tathougies for catching that.

I’m also hoping to rewrite this in generic form using Generics, so watch this space for more updates.

February 06, 2017
Bernard Cafarelli a.k.a. voyageur (homepage, bugs)

Tesseract is one of the best open-source OCR software available, and I recently took over ebuilds maintainership for it. Current development is still quite active, and since last stable release they added a new OCR engine based on LSTM neural networks. This engine is available in an alpha release, and initial numbers show a much faster OCR pass, with fewer errors.

Sounds interesting? If you want to try it, this alpha release is now in tree (along with a live ebuild). I insist on the alpha tag, this is for testing, not for production; so the ebuild masked by default, and you will have to add to your package.unmask file:
The ebuild also includes some additional changes, like current documentation generated with USE=doc (available in stable release too), and updated linguas.

Testing with paperwork

The initial reason I took over tesseract is that I also maintain paperwork ebuilds, a personal document manager, to handle scanned documents and PDFs (which is heavy tesseract user). It recently got a new 1.1 release, if you want to give it a try!

Denis Dupeyron a.k.a. calchan (homepage, bugs)
Google Summer of Code 2017 is starting! (February 06, 2017, 01:53 UTC)

(A previous version of this post recommended #gentoo-soc-mentors on Freenode as the preferred discussion channel for GSoC, please use #gentoo-soc instead as the former is invite-only or ask us to invite you to it)

It’s time to send us your GSoC ideas whether you can/want to mentor or not. We need as many good ideas as possible to make sure Google will select us as an organization again this year. Experience has shown us that we’re not automatically selected. You can submit them yourself on the wiki or let us do it. Don’t waste any time because some polishing typically needs to occur before the deadline (February 27th). You can discuss your ideas with us on Freenode in #gentoo-soc (preferred), or by email at

If you’re potentially interested in being a mentor, only want to help during the early phases of discussing and reviewing projects, or are just curious and want to see what goes on there, please let us know and we’ll add you to the mail alias. Everybody from last year was removed so don’t assume you’ll be on the alias because you were last year. Note that you do not have to be a Gentoo developer to be a mentor or help us with GSoC in any way.

Finally, if you’re a student it’s not quite time yet to ask us about projects. Please be patient, we’ll let you know.

Now go and submit that idea!

February 04, 2017
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)

One of the travel blogs I follow covered today the new EU directive on roaming charges, I complained quickly on Twitter, but as you can imagine, 140 characters are not enough to explain why I’m not actually happy about this particular change.

You can read the press release as reported by LoyaltyLobby, but here is where things get murky for me:

The draft rules will enable all European travellers using a SIM card of a Member State in which they reside or with which they have “stable links” to use their mobile device in any other EU country, just as they would at home.

Emphasis mine, of course.

This is effectively undermining the European common market of services: if you do not use a local provider, you’re now stuck to pay roaming just as before, or more likely even higher. Of course this makes perfect sense for those people who barely travel and so have only their local carrier, or those who never left a country and so never had to get a number in a different country while keeping the old one around. But for me, this sucks in two big and kind of separate ways.

The first problem is one of convenience, admittedly making use of a bit of a loophole. As I write this post I’m in the USA, but my phone is running a British SIM card, by Three UK. The reason is simple: with £10 I can get 1GB of mobile data (and an amount of call minutes and SMS, which I never use), and wit £20 I can get 12GB. This works both in th UK, and (as long as I visited in the previous 3 months) a number of other countries, including Ireland, Italy, USA, and Germany. So I use it when I’m in the USA and I used it when I went to 33c3 in Hamburg.

But I’m not a resident of the UK, and even though I do visit fairly often, I don’t really have “stable ties”.

It’s of course possible that Three UK will not stop their free roaming due to this. After all they include countries like the US and (not a country) Hong Kong in the areas of free roaming and they are not in Europe a all. Plus the UK may not be part of the EU that long anyway. But it also gives them leverage to raise the prices for non-residents.

The other use case I have is my Italian mobile phone number, which has been the same for about ten years or so, changing three separate mobile providers – although quite ironically, I changed from 3 ITA to Wind to get better USA roaming, and now 3 ITA bought Wind up, heh – but keeping the number as it is associated with a number of services, including my Italian bank.

Under the new rules I may be able to pull off a “stable links” indication thanks to being Italian, but that might require me to do paperwork in Italy, where I don’t go very often. If I don’t do that, I expect the roaming to become even more expensive than it is now.

Finally, there is another interesting part to this. In addition to UK, Irish and Italian numbers, I have a billpay subscription in France through — the reason is that I visit France fairly often, and it’s handy to have a local phone number when I visit. I have no roaming enabled on that contract though, so the directive has no effect on it anyway. That’s okay.

What is not okay in my opinion is that the directive says nothing about maintaining quality of service when roaming, it only impose prices. And indeed sent an update this past July that, due to a similar directive within France, their in-country roaming will have reduced speeds:

De ce fait, les débits théoriques maximums atteignables par abonné sur le réseau de l’opérateur partenaire en itinérance 2G/3G seront de 5 Mbit/s (débit descendant) et de 448 kbit/s (débit montant) à compter du 1er septembre 2016 jusqu’au 31 décembre 2016. En 2017 et 2018, ces débits seront de 1 Mbit/s (débit descendant) et 448 kbit/s (débit montant). Ensuite, ils seront de 768 kbit/s (débit descendant) et 384 kbit/s (débit montant) pour l’année 2019 et de 384 kbit/s (débit descendant) et 384 kbit/s (débit montant) pour l’année 2020.

So sure, you’ll get free roaming, but it’ll have a speed that will make it completely useless.

My opinion on this directive is that it targets a particular set of complaints by a vocal part of the population that got screwed sideways by horrible roaming tariffs of many European providers when on vacation, and at the same time provide a feel-good response for those consumers that do not actually care, as they barely, if ever, leave their country.

Indeed if you travel, say, a week a year in the summer outside of the border, probably these fixed limits are pretty good: you do not have to figure out which is the most advantageous provider for roaming in your country (which may not be advantageous in other circumstances) and you do not risk ending up with multiple hundreds of euros of bill from your vacation.

On the other hand if you, like me, travel a lot, and effectively spend a significant amount of the year outside of your residence country, and you even live outside of your native country, well, you’re now very likely worse off. Indeed, with the various 3 companies and their special roaming plans I was very happy not having to have a bunch of separate SIM cards: in Germany, USA, Austria I just used my usual SIM cards. In UK, France and Italy I had both a free-roaming card and a local one. And instead before that I ended up having Vodafone SIM cards for the Netherlands, Czech Republic, Portugal and very nearly Spain (in that case I used Wind’s roaming package instead).

Don’t get me wrong: I”m not complaining about European meddling into mobile providers. I used to have a tagline for my blog: “Proud to be European”, and I still am. I’m not happy about Brexit, because that actually put a stop to my plans of moving to London eventually. But at the same time I think this regulation is a gut reaction rather than a proper solution.

If I was asked what the solution should be, my suggestion would be to allow companies such as 3 and Vodafone to provide an European number option. Get a new international prefix for EU, allow the companies that have wide enough reach to set up their own agreements locally where they do not have network themselves (3 and Vodafone clearly have already a wide reach) by providing a framework for capping the cost as applied to providers. Then get me a SIM that just travels Europe with no additional costs, and with a phone number that can be called at local rates everywhere (you can do that by ensuring that the international prefix maps to a local one in all the countries). Even if such a contract is more expensive than a normal one, the frequent travellers would be pretty happy not to have to switch SIM cards, phone numbers, and have unknown costs appearing out of nowhere.

February 03, 2017
Nathan Zachary a.k.a. nathanzachary (homepage, bugs)


My tech articles—especially Linux ones—are some of the most-viewed on The Z-Issue. If this one has helped you, please consider a small donation to The Parker Fund by using the top widget at the right. Thanks!

Recently I was on a mission to make my audio experience on my main desktop more enjoyable. I had previously just used some older Bose AE2 headphones from 2010 plugged in directly to the 3.5mm audio output on the back of my desktop. The sound quality was mediocre at best, and I knew that a combination of a Digital-to-Analogue Converter (DAC) and some better headphones would certainly improve the experience. I also knew that the DAC would probably yield the most noticeable improvements, so I purchased the Big Ego USB DAC from one of my favourite audiophile-grade manufacturers, Emotiva. I have several of their monoblock amplifiers and use their amazing XMC1 for my preamp/processor in my home audio system, so I knew that the quality would be outstanding, especially for the price.

Emotiva Big Ego DAC and V-Moda Crossfade M-100 headphones

Now, the Big Ego FAQ on the Emotiva website indicates that it should work with all modern computing devices:

Q: What devices can I use the Ego DACs with?
A: The Ego DACs are basically designed to work with any modern “computer device” which can be used
with an external USB sound card, which includes:
1) All modern Apple computers
2) All modern Windows computers (Windows XP, Vista, 7, 8.0, 8.1, and Windows 10)
3) Many Linux computers (as long as they support USB Audio Class 1 or 2)
4) Some Android tablets and phones (as long as they support UAC1 or UAC2)
5) Apple iPhone 5 and iPhone 6 (with the lightning to USB camera adapter)

For many Linux users, the Big Ego probably works without any manual intervention. However, if it doesn’t, it shouldn’t be that difficult to get it working properly, and I hope that this guide helps if you are running into trouble.

Firstly, let’s get something out of the way, and that’s USB Audio Class 2 (UAC2) support within Linux. With all modern distributions (>=2.6 kernel), UAC2 is readily available. It can be validated by looking at the audio-v2.h file within the kernel source:

# grep 'From the USB Audio' /usr/src/linux/include/linux/usb/audio-v2.h
* From the USB Audio spec v2.0:

Feel free to look at the full file to see the references to the UAC2 specification.

Kernel support:

Secondly, and also speaking to the kernel, if your distribution doesn’t even show the device, you are likely lacking the one needed kernel driver. To see if your system recognises the Emotiva Big Ego, try the following command and look for similar output:

$ lsusb -v | grep 'Emotiva Big Ego'
iProduct 3 Emotiva Big Ego

The full identifier (Vendor ID and Product ID) from lsusb is 20ee:0021, even though it doesn’t have a description:

# grep -A 4 /var/log/messages
kernel: usb 9-1: New USB device found, idVendor=20ee, idProduct=0021
kernel: usb 9-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2
kernel: usb 9-1: Product: Emotiva Big Ego
kernel: usb 9-1: Manufacturer: Emotiva

$ lsusb | grep '20ee:0021'
Bus 009 Device 005: ID 20ee:0021

If you don’t get similar output, then you’re lacking kernel support for the Big Ego. The one driver in the kernel that you need is the “USB Audio/MIDI driver” which can be found in the make menuconfig hierarchy as:

Device Drivers --->
  <*> Sound card support --->
    <*> Advanced Linux Sound Architecture --->
      [*] USB sound devices --->
        <*> USB Audio/MIDI driver

You can also check your kernel .config for it, or if you have it as a module, load it:

$ grep -i snd_usb_audio /usr/src/linux/.config


# modprobe snd-usb-audio

Emotiva Big Ego DAC and V-Moda Crossfade M-100 headphones

ALSA configurations:

Thirdly, and now that you have the appropriate kernel support, let’s move on to configuring and using the Big Ego with ALSA. You can see a list of device names by using aplay -l, and it’s best to address the device by name instead of number (because the numbering could possibly change upon reboot). This one-liner should show you precisely how it is named (note that your output may be different based on the available sound output devices on your system):

$ aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq

With that information, you are ready to set the Big Ego as your default sound output device by editing either .asoundrc (in your home directory, for a per-user directive) or within the system-wide /etc/asound.conf (which is the one that I would recommend for most situations). I tried various configurations for my ALSA configuration, but would end up with various oddities. For instance, I ran into a problem where I had sound in applications like Audacious, mpv, and even ALSA’s own speaker-test, but had no sound in other terminal applications like ogg123 or, more importantly, web browsers like Firefox and Chromium. The only configuration that worked fully for me was:

$ cat /etc/asound.conf
defaults.pcm.!card Ego
defaults.pcm.!device 0
defaults.ctl.!card Ego
defaults.ctl.!device 0

After changing your ALSA configuration, you need to reload it, and the method for doing so varies based on your distribution and init system. For me, using Gentoo Linux with OpenRC, I just issued, (as root), /etc/init.d/alsasound restart and it reloaded. Worst case, just reboot your system to test the changes.

Now that you have it set as the default card, applications like alsamixer and such should automatically choose the Big Ego for your levels and mixing. One thing that I noticed with alsamixer is that there are two adjustable level sliders:

alsamixer with the Emotiva Big Ego USB DAC

What I am guessing is that, even though they are labelled “Emotiva Big Ego” and “Emotiva Big Ego 1”, they actually correspond to the output that you are using on the DAC. For instance, I am using the 3.5mm headphone jack on the front, and that corresponds to the “Emotiva Big Ego 1” slider, whereas if I were using the line out jack on the back of the DAC (those rhymes are fun 😛 ), I would adjust it using the slider for “Emotiva Big Ego”.

Additional configurations:

Now that we have configured ALSA to use our USB DAC as the default sound card, there are some additional things that I would like for my convenience. I prefer to not use a full desktop environment (DE), but instead favour a more minimalistic approach. I just use the Openbox window manager (WM). One of the things that I like about Openbox is the ability to set my own key bindings. In this case, I would like to be able to control the volume by using the designated keys on my keyboard, regardless of the application that is using the USB DAC. Here are my key bindings, which are added to ~/.config/openbox/rc.xml:

    <!-- Keybinding for increasing Emotiva Big Ego volume by 1 -->
    <keybind key="XF86AudioRaiseVolume">
      <action name="execute">
        <command>amixer set 'Emotiva Big Ego',1 1+</command>
    <!-- Keybinding for decreasing Emotiva Big Ego volume by 1 -->
    <keybind key="XF86AudioLowerVolume">
      <action name="execute">
        <command>amixer set 'Emotiva Big Ego',1 1-</command>
    <!-- Keybinding for muting/unmuting volume -->
    <keybind key="XF86AudioMute">
      <action name="execute">
        <command>amixer set 'Emotiva Big Ego',1 toggle</command>

Take note that the subdevice is ‘1’ (bold in the code above). That is because, like I showed in the alsamixer output, I’m using the headphone jack (so it corresponds to the secondary volume slider).

Further troubleshooting:

I hope that these instructions help you get your USB DAC working under Linux, but if they don’t, feel free to leave me a comment here. We’ll see what we can do to get it working for you. One last note is that I experienced some rather severe popping and other undesirable sounds when I had the Big Ego plugged into one of the USB2 ports on the back of my tower. Swapping it to its own non-shared USB3 port fixed that problem. So, if you have it plugged into a USB hub or something similar, try isolating it. Remember, it is a sensitive piece of audio equipment, and special considerations may need to be made. 🙂


February 02, 2017

FOSDEM 2017 logo

As FOSDEM 2017 approaches we are happy to announce there are a total of five Gentoo developers scheduled to give talks!

Developers and their talks include:

Only a few hours remain until the event kicks off. See you at FOSDEM!

January 27, 2017
Yury German a.k.a. blueknight (homepage, bugs)
WordPress Blogs Maintenance (January 27, 2017, 22:12 UTC)

Changes for

With the update of the WordPress to 4.7.1 a few plug-ins have created instability to the platform.

We have disabled the WordPress Mobile Site Plugin and the Picasa Album update.

  • WordPress Mobile Site is causing all sorts of issues and an update just came out today. We will push the update and enable it for some testing.  if you were one of the users that was using it please let us know so that you can test it when we update it.
  • The Picasa Album is not working and is disabled pending updates.
If you have any questions please feel free to contact me on irc @blueknight

Alexys Jacob a.k.a. ultrabug (homepage, bugs)
py3status v3.4 (January 27, 2017, 09:29 UTC)

Another community driven and incredible update of py3status has been released !

Our contributor star for this release is without doubt @lasers who is showing some amazing energy with challenging ideas and some impressive modules QA clean ups !

Thanks a lot as usual to @tobes who is basically leading the development of py3status now days with me being in a merge button mode most of the time.

By looking at the issues and pull requests I can already say that the 3.5 release will be grand !


  • support of python 3.6 thanks to @tobes
  • a major effort in modules standardization, almost all of them support the format parameter now thanks to @lasers
  • modules documentation has been cleaned up
  • new do_not_disturb module to toggle notifications, by @maximbaz
  • new rss_aggregator module to display your unread feed items, by @raspbeguy
  • whatsmyip module: added geolocation support using, by @vicyap with original code from @neutronst4r

See the full changelog here.

Thank you guys !

January 20, 2017
Michał Górny a.k.a. mgorny (homepage, bugs)
The Tale of Pythonia (January 20, 2017, 16:33 UTC)

Developers, gather round for I am about to tell thee a story. A story of a far away kingdom, great kings and their affairs. No dragons included.

With special dedication to William L. Thomson Jr.

Once upon a time, in a far away kingdom of Gentoo there was a small state called Pythonia. The state was widely known throughout the land for the manufacture of Python packages.

The state of Pythonia was ruled by Arfruvro the Magnificent. He was recognized as a great authority in the world of Python. Furthermore, he was doing a great deal of work himself, not leaving much to do for his fellow citizens. He had two weaknesses, though: he was an idealist, and he wanted Python packages to be perfect.

Arfruvro frequently changed the design of Python packages manufactured by his state to follow the best practices in the art. Frequently came to the neighbouring states edicts from Pythonia telling their citizens that the Python package design is changing and their own packages need to be changed in 6 or 12 months, or just new packages that broke everything. So did neighbouring states complain to Pythonia, yet Arfruvro did not heed their wishes.

One day, Arfruvro re-issued yet another broken set of Python packages. The uproar was so great that the King Flamessio of the Empowered State of Qualassia decided to invade Pythonia. He removed Arfruvro from the throne and caused him to flee the state. Then, he let the citizens of Pythonia elect a new king.

The new king was a fair and just ruler. However, he stayed in the shadow of his predecessor. The state was no longer able to keep up with the established standards, and the quality and quantity of Python packages decreased. When the progress demanded reforms, nobody in the whole kingdom was capable of doing them. In fact, nobody really knew how all the machinery worked.

At this point, you may think that the state of Pythonia would have surely fallen without Arfruvro. However, it eventually rose again. The old directions were abandoned and major reforms were done. Many have complained that the Python packages are changing again. However, today the state is shining once again. Many citizens are working together, and many of them have the knowledge to lead the state if necessary.

The moral of this story is: it does not matter how great deal of work you did if it is not self-sustainable. What matters is what you leave after you. Arfruvro did great deal of work but Pythonia fell into decay when he left. Today Pythonia is no longer dependent on a single person.

Disclaimer: the characters and events in this story are fictional. Any resemblance between the characters in this story and any persons is purely coincidental.

January 19, 2017
Arun Raghavan a.k.a. ford_prefect (homepage, bugs)

I’ve written a bit in my last two blog posts about the work I’ve been doing in inter-device synchronised playback using GStreamer. I introduced the library and then demonstrated its use in building video walls.

The important thing in synchronisation, of course, is how much in-sync are the streams? The video in my previous post gave a glimpse into that, and in this post I’ll expand on that with a more rigorous, quantifiable approach.

Before I start, a quick note: I am currently providing freelance consulting around GStreamer, PulseAudio and open source multimedia in general. If you’re looking for help with any of these, do get in touch.

The sync measurement setup

Quantifying what?

What is it that we are trying to measure? Let’s look at this in terms of the outcome — I have two computers, on a network. Using the gst-sync-server library, I play a stream on both of them. The ideal outcome is that the same video frame is displayed at exactly the same time, and the audio sample being played out of the respective speakers is also identical at any given instant.

As we saw previously, the video output is not a good way to measure what we want. This is because video displays are updated in sync with the display clock, over which consumer hardware generally does not have control. Besides, our eyes are not that sensitive to minor differences in timing unless images are side-by-side. After all, we’re fooling it with static pictures that change every 16.67ms or so.

Using audio, though, we should be able to do better. Digital audio streams for music/videos typically consist of 44100 or 48000 samples a second, so we have a much finer granularity than video provides us. The human ear is also fairly sensitive to timings with regards to sound. If it hears the same sound at an interval larger than 10 ms, you will hear two distinct sounds and the echo will annoy you to no end.

Measuring audio is also good enough because once you’ve got audio in sync, GStreamer will take care of A/V sync itself.


Okay, so now that we know what we want to measure, but how do we measure it? The setup is illustrated below:

Sync measurement setup illustrated

As before, I’ve set up my desktop PC and laptop to play the same stream in sync. The stream being played is a local audio file — I’m keeping the setup simple by not adding network streaming to the equation.

The audio itself is just a tick sound every second. The tick is a simple 440 Hz sine wave (A₄ for the musically inclined) that runs for for 1600 samples. It sounds something like this:

I’ve connected the 3.5mm audio output of both the computers to my faithful digital oscilloscope (a Tektronix TBS 1072B if you wanted to know). So now measuring synchronisation is really a question of seeing how far apart the leading edge of the sine wave on the tick is.

Of course, this assumes we’re not more than 1s out of sync (that’s the periodicity of the tick itself), and I’ve verified that by playing non-periodic sounds (any song or video) and making sure they’re in sync as well. You can trust me on this, or better yet, get the code and try it yourself! :)

The last piece to worry about — the network. How well we can sync the two streams depends on how well we can synchronise the clocks of the pipeline we’re running on each of the two devices. I’ll talk about how this works in a subsequent post, but my measurements are done on both a wired and wireless network.


Before we get into it, we should keep in mind that due to how we synchronise streams — using a network clock — how in-sync our streams are will vary over time depending on the quality of the network connection.

If this variation is small enough, it won’t be noticeable. If it is large (10s of milliseconds), then we may notice start to notice it as echo, or glitches when the pipeline tries to correct for the lack of sync.

In the first setup, my laptop and desktop are connected to each other directly via a LAN cable. The result looks something like this:

The first two images show the best case — we need to zoom in real close to see how out of sync the audio is, and it’s roughly 50µs.

The next two images show the “worst case”. This time, the zoomed out (5ms) version shows some out-of-sync-ness, and on zooming in, we see that it’s in the order of 500µs.

So even our bad case is actually quite good — sound travels at about 340 m/s, so 500µs is the equivalent of two speakers about 17cm apart.

Now let’s make things a little more interesting. With both my laptop and desktop connected to a wifi network:

On average, the sync can be quite okay. The first pair of images show sync to be within about 300µs.

However, the wifi on my desktop is flaky, so you can see it go off up to 2.5ms in the next pair. In my setup, it even goes off up to 10-20ms, before returning to the average case. The next two images show it go back and forth.

Why does this happen? Well, let’s take a quick look at what ping statistics from my desktop to my laptop look like:

Ping from desktop to laptop on wifi

That’s not good — you can see that the minimum, average and maximum RTT are very different. Our network clock logic probably needs some tuning to deal with this much jitter.


These measurements show that we can get some (in my opinion) pretty good synchronisation between devices using GStreamer. I wrote the gst-sync-server library to make it easy to build applications on top of this feature.

The obvious area to improve is how we cope with jittery networks. We’ve added some infrastructure to capture and replay clock synchronisation messages offline. What remains is to build a large enough body of good and bad cases, and then tune the sync algorithm to work as well as possible with all of these.

Also, Florent over at Ubicast pointed out a nice tool they’ve written to measure A/V sync on the same device. It would be interesting to modify this to allow for automated measurement of inter-device sync.

In a future post, I’ll write more about how we actually achieve synchronisation between devices, and how we can go about improving it.