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 Faulhammer
. Christian Ruppert
. Christopher Harvey
. 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
. Jauhien Piatlicki
. Jeffrey Gardner
. Jeremy Olexa
. Joachim Bartosik
. Johannes Huber
. Jonathan Callen
. Jorge Manuel B. S. Vicetto
. Joseph Jezak
. Kenneth Prugh
. 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
. Theo Chatzimichos
. Thomas Kahle
. Tiziano Müller
. Tobias Heinlein
. Tobias Klausmann
. Tom Wijsman
. Tomáš Chvátal
. Victor Ostorga
. Vikraman Choudhury
. Zack Medico

Last updated:
June 07, 2014, 23:05 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 Planet Gentoo, an aggregation of Gentoo-related weblog articles written by Gentoo developers. For a broader range of topics, you might be interested in Gentoo Universe.

June 06, 2014
Remi Cardona a.k.a. remi (homepage, bugs)

A couple of days ago, like everyone using ~arch, I upgraded my Gnome desktop to 3.12. Though a few packages failed to build, the upgrade itself went pretty smooth. Hats off to the Gnome herders.

Overall, 3.12 feels like a solid and well put together release. There were a few disappointments. The biggest of which being the removal of changing tab titles in gnome-terminal. I’ll spare everyone a long rant but this is feature I have been using extensively for the better part of a decade and I’m very disappointed to see this useful features go away without much justification. Material for another blog post… maybe.

One thing I did notice really quickly is the new geolocation entry in the shell’s main top-right menu. Not being a fan of geolocation, I went out to see how I could turn it off by default system-wide as my system has more than one regular user.

Going through dconf-editor, I found the correct setting key: org.gnome.shell.location.max-accuracy-level. This key is an enum and the correct value (at least to my taste) is ‘off’. Setting this for each user is a matter of running “gsettings set”. However, to change the default value, a little elbow grease is required.

GLib’s GSettings is actually an API for various backends. The one we use on Linux is dconf. So this is what I’ll have to bang on. This https://wiki.gnome.org/action/show/Projects/dconf/SystemAdministrators basically has all the reasoning behind it all. I’ll just summarize what I did.

  1. Create a /etc/dconf/profile/user with the following content:
    user-db:user
    system-db:site
  2. Create a matching ‘site’ settings database (I could have called it anything really) in /etc/dconf/db/site.d/ containing my new default settings file ’00_settings’
    [org/gnome/shell/location]
    max-accuracy-level='off'
  3. Run ‘dconf-update’ which will translate the INI-like settings file into a binary dconf file ‘/etc/dconf/db/site’

Now, I assume GSettings did not pick up this new profile on its own, so I had to restart my session. But from there, all changes to the settings file followed by a ‘dconf update’ automatically propagates to running applications, gnome-shell included.

Overall, this was easier than I anticipated. Hope that helps anyone trying to do similar things.

Michael Palimaka a.k.a. kensington (homepage, bugs)
Reviving the tinderbox (June 06, 2014, 19:50 UTC)

tinderboxOne of the problems faced by the tinderbox of yesteryear is the picking information out of logs, as well as the reliance of one person to interpret the results. With this in mind, I’ve been doing some work to improve accessibility of this data and have produced a tinderbox interface.

A Portage bashrc (based on the original work by Diego Elio Pettenò) collects QA information about builds, and stores it in individual files to make it easier to operate on – eliminating a lot of the need to parse logs.

You’ll notice the interface lists all packages – not just those with a recent build. This allows for a central location to report static analysis information from tools such as repoman and pkgcore-checks. Other lesser-known tools are supported, with experimental reporting of sub-slot candidates and automated dependency checking.

What’s next? I’d like to add ways to find packages beyond the usual category breakdown – such as by maintainer or builds by architecture. There’s more build-time checks to add, and I’m sure there’s other static analysis tools out there too. I don’t personally have the resources to build packages at the scale seen previously, so last but of course not least, more building power is needed. Fortunately, it’s quite easy to collate the tinderbox data from multiple sources so we may be able to ‘crowd-source’ if necessary.

As always, comments/feedback/suggestions welcome.

Hello users,

TL;DR: x86 (32bit) support is going away soon, if you use Sabayon x86_64 (64bit), you can ignore this.

in an effort of decreasing our computing and human capacity requirements, I am going to start the process that deprecates Sabayon x86 (32bit) images, package repositories and their support.
x86_64 (or AMD64) has been introduced one decade ago. Yes, it was 2004, pretty much the same year I started messing with a binary Gentoo-based distro.

It’s time to move on, free up resources and focus on what matters. 32bit is not important anymore and modern computers come with tons of GB of RAM. At the same time, I don’t see x32 going anywhere. Instead, I see the need to standardize on one single x86 architecture. Some distributions have started doing the same, for instance, RHEL 7 will not see any 32bit version. Windows 8, well, yes, said goodbye to 32bit as well.

If you are still stuck with 32bit CPUs, there are 5 things you could do:

  1. Make sure that your CPU does not really support x86_64. You may be surprised to know that it might run x86_64 code just fine.
  2. Given our deprecation roadmap, migrate your stuff over a more recent system. eBay, Amazon, are your friends. A second-hand x86_64 system can cost you less than $100.
  3. Migrate to other distros and pray they won’t kill 32bit anytime soon (time is not in your favor).
  4. Migrate your Sabayon system to Gentoo/Portage, basically compiling your own stuff. Alternatively, setup your own Entropy repository in order to keep your system up-to-date.
  5. Burn your motherboard and CPU by doing insane overclocking and then, when they die, violently hit them with a hammer while screaming “You shall not compute!”.

Our deprecation roadmap is as follows:

  • June 2014: stop offering x86 images off our download pages, keep them on mirrors.
  • July/August 2014: stop building x86 images as part of our daily and monthly release rollout.
  • October 2014: stop offering x86 images from our mirrors.
  • November 2014: stop offering package updates, including security updates, for x86 images.
  • January 2015: stop offering packages from our mirrors.

After January 2015, you will not be able to install new packages as well. The only way to keep your system up-to-date is to use Portage (plus our overlays) or Entropy (by maintaining your own repository). Our x86_64 images are multilib, which means that you can run 32bit code on them just fine.


June 04, 2014
Alexys Jacob a.k.a. ultrabug (homepage, bugs)
Consul on Gentoo Linux (June 04, 2014, 21:10 UTC)

As a clustering and distributed architecture enthusiast, I’m naturally interested in software providing neat ways to coordinate any kind of state/configuration/you-name-it over a large number of machines.

My quest, as many of you I guess, were so far limited to tools like zookeeper (packaged on my overlay but with almost no echo) and doozerd (last commit nearly 6 months ago) which both cover some of the goals listed above with more or less flavors and elegance (sorry guys, JAVA is NOT elegant to me).

I recently heard about consul, a new attempt to solve some of those problems in an interesting way while providing some rich fuctionnalities so I went on giving it a try and naturally started packaging it so others can too.

WTF is consul ?

consul logo

Consul is a few months’ old project (and already available on Gentoo !) from the guys making Vagrant. I especially like its datacenter centric architecture, intuitive deployment and its DNS + HTTP API query mecanisms. This sounds promising so far !

This is a descripion taken from the Hashicorp’s blog :

Consul is a solution for service discovery and configuration. Consul is completely distributed, highly available, and scales to thousands of nodes and services across multiple datacenters.

Some concrete problems Consul solves: finding the services applications need (database, queue, mail server, etc.), configuring services with key/value information such as enabling maintenance mode for a web application, and health checking services so that unhealthy services aren’t used. These are just a handful of important problems Consul addresses.

Consul solves the problem of service discovery and configuration. Built on top of a foundation of rigorous academic research, Consul keeps your data safe and works with the largest of infrastructures. Consul embraces modern practices and is friendly to existing DevOps tooling.

app-admin/consul ?

This is a RFC and interest call about the packaging and availability of consul for Gentoo Linux.

The latest version and live ebuilds are present in my overlay so if you are interested, please tell me (here, IRC, email, whatever) and I’ll consider adding it to the portage tree.

I want to test it !

Now that would be helpful to get some feedback about the usability of the current packaging. So far the ebuild features what I think should cover a lot of use cases :

  • full build from sources
  • customizable consul agent init script with reload, telemetry and graceful stop support
  • web UI built from sources and installation for easy deployment
# layman -a ultrabug
# emerge -av consul

Hope this interests some of you folks !

June 03, 2014
Gentoo Monthly Newsletter - May 2014 (June 03, 2014, 02:02 UTC)

The May 2014 GMN issue is now available online.

This month on GMN:

  • Interview with Gentoo developer Brian Dolbec (dol-sen)
  • Samba 4, sys-power/upower updates, infrastructure hosting needs
  • Latest Gentoo news, tips, interesting stats and much more.

June 02, 2014
Gentoo Monthly Newsletter: May 2014 (June 02, 2014, 21:00 UTC)

Gentoo News

Interview with Brian Dolbec (dol-sen)

by David Abbott

1. Hi Brian, tell us about yourself.

I’m a wannabe scientist/inventor that never did take the full plunge into that career path.
I’m married with 28 and 14 year old daughters, four dogs, one cat, several aquariums of fish…
And despite what many readers or other developers may expect or think: I’m not in an IT career. I’m a journeyman refrigeration mechanic with a gas ticket. I install, repair furnaces, rooftop heating/cooling equipment, computer room cooling systems etc.

2. Bring us back to your start with electronics and computers.

I’ve been taking things apart, seeing how they are built, and work since I was 9 or 10 years old.
Things from really old tube radios, appliances, etc.When I was in 7th grade, my teachers wife worked taking care of people in a care home. One of her patients was an electronics teacher crippled with polio. He asked a classmate and myself if we would to help him with things from repairing, modifying his HAM and CB radio equipment, to modifying his home built 3 wheel vehicle that he steered with buttons under his elbows.
Computer work started years later, my first machine was a used Atari 400 with a cassette player drive. Programming in basic. I had an apple IIe compatible for a year or so, then while returning to college, taking science (physics, chemistry) and computer programming courses (mostly coded in pascal) on a VAX 11 and/or x86 pc’s, my next one was an Atari 520ST (first production run) which I still have today.

3. How did you get involved with open source?

After installing gentoo, I had soon started working on porthole which was a new project at that time. I was also new to python and had not done any coding in many years. It was primarily porthole that brought me to doing work in gentoolkit, layman, portage and other tools in gentoo.

4. What path did you take to become a Gentoo developer?

I had been working around portage for many years with porthole development. Which led me to begin working on gentoolkit in order to create working api’s for other tools to use. It was that and layman work that got me into helping mentor GSOC projects. I first became a staffer as I was a coder, not an ebuild developer. It was one year later I took the plunge and completed the developer quiz and became a full developer.

5. Tell us about your mentor and the process to become a developer?

There have been many people over the years that I’ve learned from.
But my most important mentor in developing my coding skills has been Brian Harring
His knowledge of how to do things in an efficient, fast way continues to amaze and inspire me.

6. What aspects of Gentoo do we need to keep and what could we get rid of?

hmm… Keep the good coding skills and efforts into improving Gentoo as a whole, get rid of the major bikeshedding over who’s right and who’s wrong…

7. Tell us about Porthole (The portage frontend) http://porthole.sourceforge.net/ and what skills you learned from it?

Python programming, knowledge of data acquisition using portage’s API’s, learning to do things with less code, more adaptable and robust with less long term maintenance required. I’ve rewritten areas of porthole’s code several times as it evolved and grew. Sadly, I’ve been neglecting porthole these past few years. I keep getting distracted with other projects in need of help, re-writes, updates, or even new projects like gentoo-keys which was spawned from dev-python/pyGPG which I created to handle gpg signed list verification for layman. Layman’s code also spawned a small new python lib (dev-python/ssl-fetch) that will be used in several tools soon. I split that code out of layman to re-use in mirrorselect for fetching files from api.gentoo.org.

8. You have become a proficient Python programmer, how did you do it?

Coding, making mistakes, fixing them. Learning better faster ways to accomplish something from others.
But, one of my key strong points is my ability to quickly see the big picture. The details you can figure out along the way with help from others as the need arises. Many new programmers get stuck focusing on the details without knowing how they should be put together. Hint, think of a jigsaw puzzle, when you get one, you have the finished picture on the box to use as a reference of what it should look like. This makes it easier to figure out where a piece might fit. The same holds true for any programming task. You need to know what the end goal is and how it might fit together. Adjustments are made along the way so that you end up with a completed code block, then you move along to the next one.

9. Walk me through the steps you do to write python code, test, and your editor of choice etc.

see above answer… Current preferred editor is Geany, 2nd is Scite which I used for many years and still do for some things.

10. Catalyst (the tool used for building Gentoo releases) is in the process of a major overhaul, what has been done, who is helping you and what needs to be completed?

I got started working on catalyst so that the default location for the portage tree (gentoo ebuild tree) can be relocated. The catalyst code base was in sad shape with paths hard-coded throughout the code. It even had paths used as both a variable name and value in places. Its code base still had (questionable to poor) code copied from early portage code which has long since been replaced. The code had also been modified by the releng team which (not being proficient in python) used bad examples to modify its operation. The bulk of the rewrite work has and is being done by Trevor King and myself. With others contributing to improvements, additions to portions of it. Currently I’m in the middle of migrating all the changes from a development branch (3.0) into the master branch of the repository. Once that is caught up, the rewrites will continue. There are still too many areas of code to improve or rewrite to list them here.

11. Tell us about your other projects you are currently working on?

Gentoo-keys – A gpg key management and verification tool. Designed to manage all aspects of Gentoo’s gpg keys, developer keys and verification of things like the release media, commits to Gentoo’s ebuild tree, layman’s repositories etc.

Mirrorselect – a mirror selection tool for Gentoo. I did the 2.2 re-write and some additional work adding more features in the 2.2.1 release.

Ssl-fetch – A breakout lib which wraps dev-python/requests code and does verified ssl fetching of files and handles use of headers and timestamps to prevent re-downloading of data which hasn’t been modified.

pyGPG – A universal gnupg wrapper lib that is capable of mining all data available from gpg calls and puts that info into python available data types.

Layman – overlay management tool.

Portage – I am the current (temporary) lead after Zac took an extended break from gentoo. I am spear-heading a new plugin-sync system for it which will make portage more versatile and ease future maintenance and make it expandable with third party installable sync modules. You can look forward to a possible squashfs sync module. Work is being done to have Gentoo’s infrastructure be able to supply sqaushfs tree images. So encourage Micheal Gorny and the Gentoo infra team to complete that work.

Elogviewer – I’m maintaining the package, did code review for recent updates. I have a recent version bump to do at time of this writing.

Gentoolkit – Various python based modules, enalyze, equery, eclean, the new python based revdep-rebuild rewrite (some final debugging, fixes)

Catalyst – Gentoo Stage building tool, major re-write

A new small python based breakout lib for easy compression/decompression handling. It comes from my work in the catalyst rewrite, but could be useful in other tools. I have yet to create and name it as a standalone project.

12. What open source software can you not live without at home and at work?

dev-vcs/gitg, dev-util/geany, dev-vcs/git, Hexchat, xfce4 desktop environment,…

13. Which open source programs would you like to see developed?

gtk+:2 branch of gitg. It has gone to a gnome 3 look now which IMHO is yuk. It also lost the git blame feature currently in its re-write.

14. Age old question for Gentoo, how can we get more help?

Reducing the bikeshedding and name calling type attitudes present in some mail lists. Continue being an innovative leading Linux distribution building system.

15. Describe your desktop setup (WM/DE)?

Intel core-2 quad core based system with a shiny new SSD drive (Thank you Alec)
2 – 24 inch widescreen monitors
Basic xfce4 desktop, 14 virtual desktops, is a mix of Mac like toolbars and retro theme.
A hexchat window, toolbars, etc. in the left monitor, right monitor for main working apps windows, terminals

16. Tell us about your boxes and home network setup?

Not much to tell really. There’s my main desktop, an old 11 year old laptop, several printers. I have an old x86 box that I setup for a small server and router, but need to work on it. A hard drive failed on it due to a power failure. I have a 24 port gigabit switch. I still haven’t wired up this new house yet with lan everywhere. My wife and kids have some ipads, an Acer netbook.

17. What would be your dream job?

Working on some inventions, ideas I have for energy efficiency, earth friendly, and just plain cool ot fun :)

18. What gives you the most enjoyment within the Gentoo community?

Doing (hopefully) great coding work and having users really like what I’ve done to ease their work or save their system.
Mentoring students into doing better coding, being a more versatile developer.

19. What gives you the most enjoyment outside the Gentoo community?

Family

Help with samba-4 packages needed!

by Lars Wendler

Currently Gentoo’s samba team is severely understaffed. This has slowed down development of samba packages and its direct dependencies to a level where we cannot foresee when it is convenient to finally remove the mask on samba-4 and give it a wider range of testing from our users. There are a couple of automagic dependencies that need attention. Unfortunately samba upstream does very little to resolve these issues so we need people knowing the new build system of samba-4 to write patches for us. Furthermore samba-4 requires app-crypt/heimdal as kerberos provider which leads to packages blocking each other because they require app-crypt/mit-krb5 which cannot be installed together with heimdal.

This is a call for help getting as many blocker bugs from [1] fixed as possible. Once all these blockers are solved, unmasking samba-4 is the next logical step.

[1] https://bugs.gentoo.org/489762

Council News

This month the council addressed two issues brought up by the community.

In the aftermath of Heartbleed many are questioning the default configuration of packages like OpenSSH/OpenSSL, etc. If we had not enabled tls-heartbeat by default then Gentoo would have been immune to the recent troubles.

The council took up discussion, but felt that trying to make a one-size-fits-all policy wasn’t going to be practical. Maintainers were encouraged to follow upstream (which in the case of Heartbleed would have meant being vulnerable), but decisions are going to remain in the hands of individual maintainers. Specific issues can still be escalated to Council.

The other matter which came up concerned pkg-config files. Everybody can agree that upstream should be providing these when applicable, but there was disagreement over what should be done with upstream drops the ball. The crux of the argument was that not including them makes life more difficult for packages using the libraries on Gentoo, while including them can cause developers working on Gentoo to make assumptions that will cause problems on other distributions. The council decided that the current policy in the devmanual was not adequate and struck it down. In general maintainers will be given discretion to create pkg-config files not provided by upstream, but there will be guidelines around when this is done. The guidelines themselves need to be written, approved, and published to the devmanual.

Finally it was noted that election season is coming up, and the next Council meeting will be the last one of this term. Stay tuned for further details from the election team.

sys-power/upower update

>=sys-power/upower-0.99.0 has entered ~arch and has deprecated support for sys-power/pm-utils and hibernate/suspend in favor of using sys-apps/systemd.
If you suddenly notice that your favorite package no longer has capability for hibernate/suspend and you want them back, we have created a compatibility package sys-power/upower-pm-utils which will give you the old UPower back.
For example, Xfce 4.11+ has support for UPower 0.99 and it has copied the sys-power/pm-utils code from before UPower dropped it, and therefore hibernate/suspend should work with both versions, but this is likely untrue for most of the other packages.
Check out this forum post for more information.

Infrastructure News

Hosting sponsors needed
The Gentoo Infrastructure team is currently searching for hosting sponsors in Europe. We ask that sponsors contribute to Gentoo in one of two ways:

  1. A donation of at least two physical machines including space, power and 10Mbits of bandwidth (burstable to 50Mbit). This is the most common option that organizations prefer. Sponsors typically have existing dedicated space for their business and host hardware for Gentoo in that space.
  2. Donation of at least 12U space, 15A, and 10Mbits of bandwidth (burstable to 50Mbits).

In the latter case, the Gentoo Foundation can provide the server hardware (but not power, bandwidth, or rackspace / a rack.) In both cases we prefer the sponsor to provide remote hands for the machines.

Sponsors will received ads on ads.gentoo.org (the ad sidebar to the main site), postings on the sponsors page, as well as news items posted to www.gentoo.org.

Interested parties should contact infra@gentoo.org.

Sponsors often ask to host official Gentoo mirrors. Note that the Gentoo mirror network is not currently seeking new mirror sponsors at this time.
The gentoo infrastructure team has had significant operational problems with virtual machines and Gentoo Hardened. We see this as a pretty significant preference for physical hardware over solutions like Xen or VMWare.

Gentoo Developer Moves

Summary

Gentoo is made up of 236 active developers, of which 30 are currently away.
Gentoo has recruited a total of 798 developers since its inception.

Changes

The following developers have recently changed roles:

  • Jauhien Piatlicki joined the emacs, physics, science, mathematics and lxqt teams
  • Yury German joined the security team
  • Yixun Lan joined the proxy-maintainers, ARM and cjk teams
  • Peter Wilmott joined the ruby team
  • Julian Ospald joined the multilib and sound teams
  • Vlastimil Babka joined the kernel team
  • Michael Palimaka joined the lxqt team
  • Manuel Rueger joined the ARM team
  • Agostino Sarubbo left the KDE team
  • Brian Evans joined the MySQL team
  • Mikle Kolyada joined the embedded and dev-embedded teams.

Additions

The following developers have recently joined the project:

Moves

The following developers recently left the Gentoo project:
None this month

Portage

This section summarizes the current state of the portage tree.

Architectures 45
Categories 162
Packages 17471
Ebuilds 37518
Architecture Stable Testing Total % of Packages
alpha 3591 538 4129 23.63%
amd64 10762 6209 16971 97.14%
amd64-fbsd 0 1576 1576 9.02%
arm 2634 1722 4356 24.93%
arm64 436 30 466 2.67%
hppa 3051 488 3539 20.26%
ia64 3176 595 3771 21.58%
m68k 575 93 668 3.82%
mips 4 2379 2383 13.64%
ppc 6809 2388 9197 52.64%
ppc64 4313 876 5189 29.70%
s390 1460 332 1792 10.26%
sh 1656 402 2058 11.78%
sparc 4119 899 5018 28.72%
sparc-fbsd 0 319 319 1.83%
x86 11418 5259 16677 95.46%
x86-fbsd 0 3236 3236 18.52%

gmn-portage-stats-2014-06

Security

The following GLSAs have been released by the Security Team

GLSA Package Description Bug
201405-28 x11-wm/xmonad-contrib xmonad-contrib: Arbitrary code execution 478288
201405-27 dev-libs/libyaml LibYAML: Arbitrary code execution 505948
201405-26 net-misc/x2goserver X2Go Server: Privilege Escalation 497260
201405-25 dev-php/symfony Symfony: Information disclosure 444696
201405-24 dev-libs/apr Apache Portable Runtime, APR Utility Library: Denial of Service 339527
201405-23 media-libs/lib3ds lib3ds: User-assisted execution of arbitrary code 308033
201405-22 net-im/pidgin Pidgin: Multiple vulnerabilities 457580
201405-21 net-irc/charybdis Charybdis,ShadowIRCd: Denial of Service 449544
201405-20 media-libs/jbigkit JBIG-KIT: Denial of Service 507254
201405-19 app-crypt/mcrypt MCrypt: User-assisted execution of arbitrary code 434112
201405-18 net-misc/openconnect OpenConnect: User-assisted execution of arbitrary code 457068
201405-17 net-analyzer/munin Munin: Multiple vulnerabilities 412881
201405-16 dev-lang/mono Mono: Denial of Service 433768
201405-15 sys-apps/util-linux util-linux: Multiple vulnerabilities 359759
201405-14 dev-ruby/ruby-openid Ruby OpenID: Denial of Service 460156
201405-13 x11-libs/pango Pango: Multiple vulnerabilities 268976
201405-12 net-analyzer/ettercap Ettercap: Multiple vulnerabilities 340897
201405-11 app-backup/bacula Bacula: Information disclosure 434878
201405-10 dev-ruby/rack Rack: Multiple vulnerabilities 451620
201405-09 media-gfx/imagemagick ImageMagick: Multiple vulnerabilities 409431
201405-08 app-antivirus/clamav ClamAV: Multiple vulnerabilities 462278
201405-07 x11-base/xorg-server X.Org X Server: Multiple vulnerabilities 466222
201405-06 net-misc/openssh OpenSSH: Multiple vulnerabilities 231292
201405-05 net-misc/asterisk Asterisk: Denial of Service 504180
201405-04 www-plugins/adobe-flash Adobe Flash Player: Multiple vulnerabilities 501960
201405-03 net-irc/weechat WeeChat: Multiple vulnerabilities 442600
201405-02 net-libs/libsrtp libSRTP: Denial of Service 472302
201405-01 sys-fs/udisks udisks: Arbitrary code execution 504100

Package Removals/Additions

Removals

Package Developer Date
sci-geosciences/gempak pacho 03 May 2014
gnome-extra/evolution-kolab pacho 03 May 2014
www-apache/mod_ruby pacho 03 May 2014
x11-misc/suxpanel pacho 03 May 2014
kde-base/kdeartwork-sounds johu 09 May 2014
kde-base/kdnssd johu 09 May 2014
kde-base/kwallet johu 09 May 2014
games-puzzle/krosswordpuzzle johu 10 May 2014
app-portage/udept pacho 11 May 2014
media-libs/libj2k pacho 11 May 2014
media-gfx/cfe pacho 11 May 2014
media-gfx/yablex pacho 11 May 2014
app-admin/osiris pacho 11 May 2014
sys-power/cpufreqd pacho 11 May 2014
net-irc/ctrlproxy pacho 11 May 2014
x11-misc/pogo pacho 11 May 2014
sci-geosciences/openstreetmap-icons pacho 11 May 2014
dev-python/telepathy-python pacho 11 May 2014
media-tv/huludesktop pacho 11 May 2014
app-admin/lcap pacho 11 May 2014
www-apache/mod_chroot pacho 11 May 2014
dev-util/dissy pacho 11 May 2014
dev-libs/clens ulm 12 May 2014
dev-java/randomguid ulm 12 May 2014

Additions

Package Developer Date
net-wireless/openggsn zx2c4 01 May 2014
x11-misc/urxvt-font-size radhermit 02 May 2014
kde-misc/baloo-kcmadv dilfridge 02 May 2014
dev-ruby/dotenv-deployment graaff 03 May 2014
dev-java/headius-options tomwij 03 May 2014
gnome-extra/gnome-commander hwoarang 03 May 2014
mate-extra/caja-extensions tomwij 04 May 2014
media-gfx/eom tomwij 04 May 2014
x11-misc/mozo tomwij 04 May 2014
dev-ruby/descendants_tracker graaff 05 May 2014
gnome-extra/cinnamon-desktop tetromino 06 May 2014
gnome-extra/cinnamon-settings-daemon tetromino 06 May 2014
gnome-extra/cinnamon-session tetromino 06 May 2014
app-i18n/tagainijisho calchan 06 May 2014
dev-ruby/nio4r mrueg 07 May 2014
gnome-extra/cjs tetromino 07 May 2014
gnome-extra/cinnamon-menus tetromino 07 May 2014
app-crypt/paperkey mrueg 07 May 2014
dev-ruby/rinku mrueg 07 May 2014
gnome-extra/cinnamon-control-center tetromino 08 May 2014
net-wireless/cinnamon-bluetooth tetromino 08 May 2014
dev-python/aniso8601 radhermit 08 May 2014
dev-python/flask-restful radhermit 08 May 2014
dev-python/polib tetromino 09 May 2014
dev-db/soci jauhien 09 May 2014
dev-db/cppdb jauhien 09 May 2014
dev-python/sexpdata jauhien 10 May 2014
gnome-extra/cinnamon-screensaver tetromino 10 May 2014
sys-block/zram-init jauhien 10 May 2014
sci-chemistry/propka jlec 11 May 2014
dev-python/oslo-vmware vadimk 11 May 2014
sys-boot/winusb yac 11 May 2014
app-arch/xarchiver ssuominen 11 May 2014
dev-util/android-studio jauhien 11 May 2014
dev-ruby/fssm vikraman 11 May 2014
dev-ruby/compass vikraman 11 May 2014
dev-python/rax-scheduled-images-python-novaclient-ext prometheanfire 12 May 2014
dev-python/os-virtual-interfacesv2-python-novaclient-ext prometheanfire 12 May 2014
kde-misc/milou johu 12 May 2014
net-wireless/btcrack zerochaos 12 May 2014
dev-python/pymysql grknight 13 May 2014
app-arch/defluff tomwij 14 May 2014
sci-biology/update-blastdb jlec 14 May 2014
x11-misc/calise tomwij 14 May 2014
dev-ruby/pdf-core mrueg 15 May 2014
dev-ruby/priorityqueue mrueg 15 May 2014
dev-ruby/expression_parser mrueg 15 May 2014
dev-ruby/ae p8952 15 May 2014
dev-ruby/ansi p8952 15 May 2014
dev-ruby/brass p8952 15 May 2014
dev-ruby/facets p8952 15 May 2014
dev-ruby/lemon p8952 15 May 2014
dev-ruby/qed p8952 15 May 2014
dev-ruby/rubytest p8952 15 May 2014
dev-ruby/rubytest-cli p8952 15 May 2014
dev-ruby/hashery p8952 15 May 2014
gnome-extra/cinnamon-translations tetromino 16 May 2014
net-libs/balde rafaelmartins 18 May 2014
dev-lang/rust jauhien 18 May 2014
sci-libs/libgeodecomp slis 19 May 2014
dev-java/netty-common tomwij 19 May 2014
dev-java/netty-buffer tomwij 19 May 2014
dev-ruby/rrdtool-bindings graaff 19 May 2014
app-leechcraft/lc-eleeminator maksbotan 20 May 2014
app-backup/snapper dlan 21 May 2014
dev-java/netty-transport tomwij 21 May 2014
games-strategy/0ad-data hasufell 21 May 2014
games-strategy/0ad hasufell 21 May 2014
www-servers/hiawatha hasufell 22 May 2014
www-apps/hiawatha-monitor hasufell 22 May 2014
media-fonts/ahem idella4 23 May 2014
x11-misc/sddm jauhien 24 May 2014
lxqt-base/liblxqt jauhien 25 May 2014
net-misc/lxqt-openssh-askpass jauhien 25 May 2014
lxqt-base/lxqt-qtplugin jauhien 25 May 2014
app-vim/gitgutter radhermit 25 May 2014

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 May 2014 and 31 May 2014. Not fixed means bugs that were resolved as NEEDINFO, WONTFIX, CANTFIX, INVALID or UPSTREAM.
gmn-activity-2014-05

Bug Activity Number
New 1388
Closed 977
Not fixed 259
Duplicates 158
Total 5734
Blocker 5
Critical 18
Major 66

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 Security 109
2 Gentoo Linux Gnome Desktop Team 44
3 Gentoo Games 31
4 Gentoo KDE team 29
5 Gentoo's Team for Core System packages 26
6 Multilib team 24
7 Gentoo X packagers 21
8 Qt Bug Alias 20
9 Retirement Admin 19
10 Others 653

gmn-closed-2014-05

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 Linux bug wranglers 158
2 Gentoo Linux Gnome Desktop Team 93
3 Gentoo Security 53
4 Gentoo KDE team 47
5 Multilib team 41
6 Python Gentoo Team 35
7 Gentoo's Team for Core System packages 35
8 Default Assignee for New Packages 25
9 Qt Bug Alias 24
10 Others 876

gmn-opened-2014-05

Tip of the month

Would you like to know why a particular package is masked?
You can create a simple shell function like this:

whymask() {
    find /usr/portage/profiles/ -name '*.mask' -exec \
        awk -vRS= "/${*/\//.}/ {
                print \" \" FILENAME \":\", \"\n\" \"\n\" \$0 \"\n\"
        }" {} + | less
}

You can do `whymask sys-kernel/gentoo-sources` to get reasons as to why
a particular package is masked; very handy to quickly check something
up, especially for USE flag masks which Portage doesn’t explain.

You can do `whymask Gnome 3.12` to get the entire GNOME 3.12 mask,
piping it to `grep -v mask: > /etc/portage/package.unmask/gnome3` then
allows you to quickly update your GNOME 3.12 unmask; if you want this to
happen on sync, you can put this line in /etc/portage/postsync.d/gnome3
and make it executable such that it’ll be ran after every sync.

The magic trick here is that awk -vRS= “/…/” matches paragraphs; as
the record separator is empty, it takes the blank lines.
by Tom Wijsman

Heard in the community

Send us your favorite Gentoo script or tip at gmn@gentoo.org

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.

Alexys Jacob a.k.a. ultrabug (homepage, bugs)
uWSGI v2.0.5.1 (June 02, 2014, 14:12 UTC)

This release is important to me (and my company) as it officially introduces a few features we developed for our needs and then contributed to uWSGI.

Special congratulations to my co-worker @btall for his first contribution and for those nice features to the metrics subsystem with many thanks as usual to @unbit for reviewing and merging them so quickly.

new features

  • graceful reload of mule processes (Credits: Paul Egan) : SIGHUP is now sent to mules instead of directly killing them, by default you have 60 seconds to react before a SIGKILL
  • –metrics-no-cores, –stats-no-cores, –stats-no-metrics : don’t calculate and process all those core related metrics (gevent anyone ?)
  • reset_after_push for metrics (Credits: Babacar Tall) : this metric attribute ensures that the metric value is reset to 0 or its hardcoded initial_value every time the metric is pushed to some external system (like carbon, or statsd)
  • new metric_set_max and metric_set_min helpers (Credits: Babacar Tall) : can be used to avoid having to call “metric_get“ when you need a metric to be set at a maximal or minimal value. Another simple use case is to use the “avg“ collector to calculate an average between some *max* and *min* set metrics. Available in C and python.

See the full changelog here, especially some interesting bugfixes.

June 01, 2014
Jauhien Piatlicki a.k.a. jauhien (homepage, bugs)
LXQt 0.7.0 is available in the tree (June 01, 2014, 19:28 UTC)

07 May of 2014 version 0.7.0 of LXQt was released. LXQt is a new Qt-based desktop environment -- the successor of LXDE and Razor-qt. This is a first release since the moment the developing was started.

Why another DE could you ask? Well, as I've mentioned it is not really the new one. Even more, it is the result of merging of two existing projects. The reason for LXDE team to switch to the new project was quite understandable: LXDE is based on GTK-2, and it is going to be deprecated and unmaintained. For many reasons Qt seemed to be much better alternative than GTK-3, hence LXDE-Qt project was started. Then people from Razor-qt joined it. The 0.5.2 release of Razor-qt is going to be the last one, the development of LXDE will be continued for a while, but the main forces of both teams are concentrated on LXQt now.

Now, switching to the Gentoo. I have imported ebuilds for LXQt-0.7.0 into the tree recently and ask you to test them and file bugs ). There is a meta package lxqt-base/lxqt-meta with USEs for optional dependencies and minimal USE flag for the case if you do not like openbox and want other window manager.

As display manager LXQt team suggests using of LightDM or SDDM, both available in the tree. The last one has an issue: it does not have ConsoleKit support, so if you want, you are welcome to add it. Upstream seems to be not interested in it, so we need to handle this downstream.

For me LXQt worked perfectly, it seems to be quite stable and usable already. I have encountered only one issue that affects me: LXQt-panel still lacks autohiding. But it should be added in the next release.

Currently ebuilds in the tree are tested under amd64, arm and x86 architectures on GNU/Linux. Upstream claims a FreeBSD support, so you are welcome to try it there. May be you'll need live ebuilds from the qt overlay to do so.

If you want to help with LXQt maintaining, you are welcome, just join recently created lxqt herd.

At the end I would like to say thanks to Harvey Mittens, Davide Pesavento, Manuel Rüger and other people who helped with getting LXQt into the tree.

P.S. For those who for some strange reason came to this post on LJ and are wondering what is this all about: posts with gentoo tag are syndicated to the Gentoo Planet and I'll use it to make announcements and just write random gentoo-related thoughts.

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

If you tried upgrading from stable amd64 to ~amd64 or otherwise done a big update of perl, you probably hit this weird perl-cleaner slot conflict:

# perl-cleaner --all
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/perl:0

  (dev-lang/perl-5.18.2:0/5.18::gentoo, installed) pulled in by
    =dev-lang/perl-5.18* required by (virtual/perl-IO-1.280.0:0/0::gentoo, ebuild scheduled for merge)
    ^              ^^^^^                                                                                                                                  
    dev-lang/perl:0/5.18=[-build(-)] required by (perl-core/version-0.990.800:0/0::gentoo, installed)
                 ^^^^^^^^                                                                                                              
    (and 7 more with the same problems)

  (dev-lang/perl-5.16.3:0/5.16::gentoo, ebuild scheduled for merge) pulled in by
    =dev-lang/perl-5.16* required by (virtual/perl-Package-Constants-0.20.0-r3:0/0::gentoo, installed)
    ^              ^^^^^                                                                                                                                  
    (and 6 more with the same problem)


This is bug #506616, and the solution is to run the following command:

perl-cleaner --all -- --backtrack=30

Read more »

May 24, 2014
Anthony Basile a.k.a. blueness (homepage, bugs)
Lilblue Linux: release 20140520 (May 24, 2014, 22:35 UTC)

A couple of days ago, I pushed out a new build of Lilblue Linux [1] which is my attempt to turn embedded Linux on its head and use uClibc [2] instead of glibc as the standard C library for a fully featured XFCE4 desktop for amd64. Its userland is built with Gentoo’s hardened toolchain, and the image ships with a kernel built using hardened-sources which include the Grsec/PaX patches for added security, but its main distinguishing feature from mainstream Gentoo is uClibc. Even though Lilblue is something of an experimental project which grew out of my attempt to get more and more packages to build against uClibc, the system works better than I’d originally expected and there are very few glitches which are uClibc specific. You get pretty much everything you’d expect in a desktop, including all your multimedia goodies, office software, games and browsers. mplayer2 works flawlessly!

But all is not well in the land of uClibc these days. It has been over two years since the last release, 0.9.33.2 on May 15, 2012, and there are about 80 commits sitting in the 0.9.33 branch, many of which address critical issues since 0.9.33.2. This causes problems for people building around uClibc, such as buildroot, and there has even been talk on the email lists of dropping uClibc as its main libc in favor of either glibc or musl [3]. Buildroot is maintaining about 50 backported patches, while Mike’s (aka vapier’s) latest patchset has 20. I seem to always have to insert a backported patch of my own here or there, or ask Mike to include it in his patchset.

For this release, I did something that I have mixed feelings about. Instead of 0.9.33.2 + backported patches, I used the latest HEAD of the 0.9.33 git branch. This saved me the trouble of getting more patches backported into a new revision of our 0.9.33.2 ebuild, or by “cheating” and putting the patches into /etc/portage/patches/sys-libs/uclibc, but it did expose a well known problem in uClibc, namely the problem of how its header files stack. A libc’s header files typically include one another to form a stack [4]. For example, on glibc, sched.h stacks as follows

    sched.h
        features.h
            sys/cdefs.h
                features.h
                bits/wordsize.h
            gnu/stubs.h
        bits/types.h
            features.h
            bits/wordsize.h
            bits/typesizes.h
        stddef.h
        time.h
            features.h
            stddef.h
            bits/time.h
                bits/types.h
                bits/timex.h
                    bits/types.h
            bits/types.h
            xlocale.h
        bits/sched.h

Here sched.h includes features.h, bits/types.h, stddef.h, time.h and bits/sched.h. In turn, features.h includes sys/cdefs.h and gnu/stubs.h, and so on. Each indentation indicates another level of inclusion. Circular inclusions are avoided by using #ifdef shields.

At least one reason for this structure is to abstract away differences in architectures and ABIs in an effort to present a hopefully POSIX compliant interface to the rest of userland. So, for example, glibc’s sys/syscall.h looks the same on amd64 as on mipsel, but it includes asm/unistd.h which is different on the two architectures. Each architecture’s asm/unistd.h have their own internal #ifdefs for the different ABIs proper to the architecture, and each #ifdef section in turn defines the values of the various syscalls appropriately for their ABI [5]. Another reason for this stacked inclusion is to make sure that certain definitions, macros or prototypes defined in one header are made available in another header in the same way as they are made available in a c file. This is the reason given, for instance, in the uClibc commit 2e2dc998 which I examine below.

Let’s see where uClibc’s header problems begin. Take a look at Gentoo’s bug #486782, where cdrtools-3.01_alpha17 fails to build against uClibc because its readcd/readcd.c defines “BOOL clone;” which collides with the definition of clone() in bits/sched.h [6]. Nowhere is sched.h included in readcd.c, instead bits/sched.h gets pulled in indirectly because stdio.h is included! Comment 7 reveals the stacking problem. stdio.h’s stacking is complex, but following just the bad chain, we see that stdio.h includes bits/uClibc_stdio.h which includes bits/uClibc_mutex.h which includes pthread.h which includes sched.h which includes bits/sched.h — wheh! If you’re wondering what stdio.h should have to do with sched.h, then you see the problem: too much information is being exposed here. Joerg’s comment on the bug pretty much sums it up: “The related include files (starting from what stdio.h includes) most likely expose the problem because they seem to expose implementation details that do not belong to the scope of visibility of the using code.”

Back to my bump from 0.9.33.2 to the HEAD of the 0.9.33 branch. This bump unexpectedly exposed bugs #510766 and #510770. Here we find that =media-libs/nas-1.9.4 and =app-text/texlive-core-2012-r1, both of which build just fine against 0.9.33.2, fail against HEAD 0.9.33 because of a name collision with abs(). Unlike the case with cdrtools, where the blame is squarely on uClibc, I think this is a case of enough blame to go around. Both of those packages define abs() as a macro even though it is supposed to be a function prototyped in stdlib.h, as per POSIX.1-2001 [7]. At least nas tries to check if abs() has been already defined as a macro, but its still not enough of a check to avoid the name collision. Unfortunately, given its archaic imake system, its not as easy as just adding AC_CHECK_FUNCS([abs]) to configure.ac. texlive-core at least uses GNU autotools, but its collection of utilities define abs() in several different places making a fix messy. On the other hand, why do we suddenly have stdlib.h being pulled in after those macros with HEAD 0.9.33 whereas we didn’t with release 0.9.33.2? It turns out to be uClibc’s tiny commit 2e2dc998 which I quote here:

	sched.h: include stdlib.h for malloc/free
	Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>

	diff --git a/libc/sysdeps/linux/common/bits/sched.h b/libc/sysdeps/linux/common/bits/sched.h
	index 7d6273f..878550d 100644
	--- a/libc/sysdeps/linux/common/bits/sched.h
	+++ b/libc/sysdeps/linux/common/bits/sched.h
	@@ -109,6 +109,7 @@ struct __sched_param
	 /* Size definition for CPU sets.  */
	 # define __CPU_SETSIZE	1024
	 # define __NCPUBITS	(8 * sizeof (__cpu_mask))
	+# include <stdlib.h>
	 
	 /* Type for array elements in 'cpu_set_t'.  */
	 typedef unsigned long int __cpu_mask;

Both packages pull in stdio.h after their macro definition of abs(). But now stdio.h, which pulls in bits/sched.h, further pulls in stdlib.h with the function prototype of abs() and … BOOM! … we get

/usr/include/stdlib.h:713:12: error: expected identifier or '(' before 'int'
/usr/include/stdlib.h:713:12: error: expected ')' before '>' token

Untangling the implementation details is a going to be a thorny problem. And, given uClibc’s faltering release schedule schedule, things are probably not going to get better soon. I have looked at the issue a bit, but not enough to start unraveling it. Its easier just to apply hacky patches to the odd package here and there than to rethink uClibc’s internal implementations. If we are going to start rethinking implementation, the musl [8] is much more exciting. uClibc is used in lots of embedded systems and the header issue is not going to be a show stopper for it or for Liblue, but it does make alternatives look like musl more attractive.

References:

[1] https://wiki.gentoo.org/wiki/Project:Hardened_uClibc/Lilblue

[2] http://www.uclibc.org

[3] See Petazzoni’s email to the uClibc community.

[4] I wrote a little python script to generate these stacks since creating them manually . You can download it from my dev space: header-stack.py. Note that the stacking is influenced by #ifdef’s throughout, eg #ifdef __USE_GNU, which the script ignores, but it does give a good starting place for how the stacking goes.

[5] As of glibc 2.17, on mips, asm/unistd.h defines the various __NR_* values in a flat file with three #ifdefs sections for _MIPS_SIM_ABI32, _MIPS_SIM_ABI64 and _MIPS_SIM_NABI32, respectively ABI=o32, n64 and n32. Using my script from [4], the stacking looks as follows:

    sys/syscall.h
        asm/unistd.h
            asm/sgidefs.h
        bits/syscall.h
            sgidefs.h

In contrast, on amd64, each ABI is broken out further into their own file, with asm/unistd_32.h, asm/unistd_x32.h or asm/unistd_64.h included into asm/unistd.h for __i386__, __ILP32__, or __ILP64__ respectively. Here the stacking is

    sys/syscall.h
        asm/unistd.h
            asm/unistd_32.h
            asm/unistd_x32.h
            asm/unistd_64.h
        bits/syscall.h

Remember, on both architectures, sys/syscall.h are identical, and that is the file you should include in your c programs, not any of the asm/* which often carry warnings not to include them directly.

[6] man 2 clone

[7] man 3 abs

[8] http://www.musl-libc.org/

May 23, 2014
Alexys Jacob a.k.a. ultrabug (homepage, bugs)
rsyslog v7.6.3 (May 23, 2014, 16:13 UTC)

This version bump was long overdue sorry and it has happened only thanks to the great work of Thomas D. aka @Whissi, thanks again mate.

Please read carefully because this version introduces major ebuild changes, you’ll probably have to adapt your current configuration !

ebuild changes

"/var/log/syslog" log file is now deprecated

   Beginning with rsyslog-7.6, the "/var/log/syslog" log file will no
   longer being written per default. We are considering this file as
   deprecated/obsolet for the typical user/system.
   The content from this log file is still availble through other
   (dedicated) log files, see

     - /var/log/cron.log
     - /var/log/daemon.log
     - /var/log/mail.log
     - /var/log/messages

   If you really need the old "/var/log/syslog" log file, all you have to
   do is uncommenting the corresponding configuration directive in
   "/etc/rsyslog.d/50-default.conf".

   If you do so, don't forget to re-enable log rotation in
   "/etc/logrotate.d/rsyslog", too.
  • An additional input socket in /var/empty/dev/log (default chroot
    location) will be created per default
  • brand new and modern init script

rsyslog-7.6.3

Coming from the rsyslog release announcement page, this is what happened with the 7.6 branch release :

With 7.6 being the successor of the 7.5 development branch, everything that has been added there has now found its way into the stable version.

The major additions consist of :
- imrelp/omrelp now support TLS & (zip) compression
- impstats is now emitting resource usage counters, can directly emit delta values and can now be bound to a ruleset
- mmpstrucdata is a new module to parse RFC5424 structured data into JSON message properties
- mmutf8fix is a new module to fix invalid UTF-8 sequences
- mmsequence is a new module that helps with action load balancing
- new defaults for main/ruleset queues to be more enterprise-like

Also the new stable version has undergone a lot of bug fixes, performance improvements and optimizations that make rsyslog 7.6 a lot more reliable and performing than before.

Anthony Basile a.k.a. blueness (homepage, bugs)

I hate being watched as much as the next person. Even the NSA loves its privacy otherwise it would be a transparent organization. What’s frightening and exciting about the technology we’re building today is that we are poised on a pivot point between extremes: deep invasion of our privacy and wide scale efforts to protect it. For those of you who don’t know the Tor Project [1] you really should look into it. Encrypted communication hides what you are saying from third party eavesdropping, but it does not hide who’s doing the talking, ie. it cannot hide the identity of one of the parties and so does not preserve your anonymity. If you decide to aim your browser at https://www.google.com/ then you can remain fairly certain that no one else is watching what you are googling for: you know, and google knows. But unfortunately, so does anyone google decides to tell! Given some of the exceptionally coercive methods governments use to make their demands [3], you might as well just announce your browsing habits publicly and be done with it.

Here’s where tor steps in. It doesn’t just encrypt your traffic, but also bounces it around the world via tor relays in such a way that even the nodes themselves can’t expose the origin of the traffic. Thus, tor provides its users with pretty good anonymity [4]. Now when google looks at its logs, it won’t see your ip address, but the ip address of one of the tor exit nodes. These are themselves publicly known [5], but the original ip from where the traffic is coming remains hidden. I’ve been using tor since about 2005. In July 2007, a tor operator in Germany [6] was arrested. Luckily his computers were not confiscated, but they could have been. The police wouldn’t have gotten much off of them, but there would have been the private keys and some other “evidence.” Running tor or any system of anonymity is not illegal, and it should never be illegal as it is in some countries, but today the line between what is legal and what powers governments will abuse has been blurred if not erased entirely. 2007 was also about the time the cloud computing was catching on, so I got the idea of creating a micro Linux distribution whose only purpose was to house a tor relay in an environment that maximizes security and privacy. The image boots from an ISO into ram, any keys or configs are scp-ed in, and upon power down … poof! … nothing to see here, move along. This was also about the time that I was getting involved with hardened Gentoo development and I met up with Magnus Granberg (zorry) who was working on migrating toolchain hardening from gcc-3 to gcc-4. I was teaching a course on embedded Linux, primarily building systems with uClibc and buildroot, and so tor-ramdisk was born [7]. I originally targeted only i686, but later added amd64 and mips32r2 for router boards like the Mikrotik RB450G.

So what goes into tor-ramdisk? You can read the build scripts [8] for details, but basically the kernel is Gentoo’s hardened-sources kernel with PaX and Grsec turned on full force. A minimal userland is provided by a crippled busybox with most of its applets turned off. You need openssl for tor itself as well as openssh which provides for scp-ing keys and config files in and out of the image. Tor critically depends on the time being right, so I used openntpd for synchronization. You also need a good source of entropy for key generation and encryption, which is always a problem on embedded systems [9], so haveged is used shore up the kernel’s /dev/random. Finally we need uClibc and libevent. I cheat a little and build on uClibc virtual machines, so I can just copy over the needed libraries rather than cross compiling them. Everything is built using Gentoo’s hardened toolchains and so all the ELFs binaries have SSP, PIE + ASLR, relro, bind_now and other security goodies [10]. For i686 and amd64, kernel and userland are bundled up in a bootable ISO image, while for mips I embed the initramfs in the bootlable Linux image which can be delivered via tftp. When the system boots, the user is presented with a menu driven system on tty1 to configure and start tor. The menu is a shell script spawned by init as “tty1::respawn:/bin/setup”. On tty2, tty3 amd tty3 we have, respectively, the output of nmeter (ascii based system usage meter provided by busybox), ntpd and haveged.

I don’t know why I haven’t blogged about tor-ramdisk before on Planet Gentoo, but it is a Gentoo “derivative.” It is also popular project, at least according to freecode.com. The i686 image is the most popular, followed by the amd64, with several hundred downloads per release. I’ve stopped producing the mips32r2 image because no one was using it, even though it was the most fun to build! There have been suggestions for new features but I’ve tended to resist because I like the ~6 MB image. If you can think of something I can add without growing that image much, send patches my way!

 

 

References:

[1] https://www.torproject.org/. The Gentoo package is net-misc/tor.

[2] “fairly certain” but not 100% certain as we recently learned from CVE-2014-0160, aka the “heartbleed” bug. See https://en.wikipedia.org/wiki/Heartbleed

[3] You can read the story of lavabit’s owner as told by him at http://www.theguardian.com/commentisfree/2014/may/20/why-did-lavabit-shut-down-snowden-email

[4] There are attacks against tor so it isn’t perfect, but it is by far the best anonymity software out there. See the wiki page on tor for its weaknesses: http://en.wikipedia.org/wiki/Tor_(anonymity_network)

[5] There are various lists of exit and relay nodes. For a live list, check out http://torstatus.blutmagie.de/

[6] http://www.cnet.com/news/tor-anonymity-server-admin-arrested/

[7] The main development site is http://opensource.dyc.edu/tor-ramdisk. I announce releases at https://freecode.com/projects/tor-ramdisk.

[8] https://gitweb.torproject.org/tor-ramdisk.git

[9] See Josh Ayers’ email to the tor-ramdisk list http://opensource.dyc.edu/pipermail/tor-ramdisk/2014-February/000119.html.

[10] You can read a little bit about these hardening techniques from the “Project Description” of a related project, Lilblue Linux: https://wiki.gentoo.org/wiki/Project:Hardened_uClibc/Lilblue

 

May 20, 2014
Michael Palimaka a.k.a. kensington (homepage, bugs)
Plasma Next on Gentoo (May 20, 2014, 18:12 UTC)

As you may have heard, the KDE release structure is evolving. The process is already well under way, with the second beta of the reusable KDE frameworks and first beta of the next-generation Plasma workspace already released.

Please note that while usable, Plasma Next is definitely not yet ready for production. For the adventurous, everything needed can be found in the KDE overlay.

If you do decide to try it out, feel free to file bugs, send pull requests, or just drop us a line on mail/irc with your feedback. It’s definitely appreciated, and numerous improvements have already been made thanks to efforts of our users.

Otherwise, enjoy the screenshot and stay tuned for the next release.

plasma-next

May 14, 2014
Alexys Jacob a.k.a. ultrabug (homepage, bugs)
mongoDB v2.6.1 (May 14, 2014, 09:17 UTC)

This is a great pleasure to announce the version bump of mongoDB to the brand new v2.6 stable branch !

This bump is not trivial and comes with a lot of changes, please read carefully as you will have to modify your mongodb configuration files !

ebuild changes

As a long time request and to be more in line with upstream’s recommendations (and systemd support) I moved the configuration of the mongoDB daemons to /etc so make sure to adapt to the new YAML format.

  • the mongodb configuration moved from /etc/conf.d/mongodb to the new YAML formatted /etc/mongodb.conf
  • the mongos configuration moved from /etc/conf.d/mongos to the new YAML formatted /etc/mongos.conf
  • the MMS agent configuration file has moved to /etc/mms-agent.conf

The init scripts also have been taken care of :

  • new and modern mongodb, mongos and mms-agent init scripts
  • their /etc/conf.d/ configuration files are only used to modify the init script’s behavior

highlights

The changelog is long and the goal of this post is not to give you an already well covered topic on the release notes but here are my favorite features :

  • MongoDB preserves the order of the document fields following write operations.
  • A new write protocol integrates write operations with write concerns. The protocol also provides improved support for bulk operations.
  • MongoDB can now use index intersection to fulfill queries supported by more than one index.
  • Index Filters to limit which indexes can become the winning plan for a query.
  • Background index build allowed on secondaries.
  • New cleanupOrphaned command to remove orphaned documents from a shard.
  • usePowerOf2Sizes is now the default allocation strategy for all new collections.
  • Removed upward limit of 20 000 connections for the maxIncomingConnections for mongod and mongos.
  • New cursor.maxTimeMS() and corresponding maxTimeMS option for commands to specify a time limit.

Make sure you follow the official upgrade plan to upgrade from a previous version, this release is not a simple drop-in replacement.

thanks

Special thanks go to Johan Bergström for his continuous efforts and responsiveness as well as Mike Limansky and Jason A. Donenfeld.

May 12, 2014
Luca Barbato a.k.a. lu_zero (homepage, bugs)
Libav 10.1 released (in Gentoo) (May 12, 2014, 22:08 UTC)

I just committed the ebuild in Portage and noticed that Homebrew already updated its Formula.

I spent some time in Berlin at LinuxTAG manning the VideoLAN booth and feeding people with VLC and Libav chocolate (many thanks to Borgodoro for providing me with their fine goods).

During the weekend we held the VideoLAN association meeting in the SoundCloud office, thanks a lot again for the wonderful venue.

Unmask in Gentoo

I’m slowly getting a tinderbox up with the help of Flameeyes so we can make sure nothing unexpected happens, the new refcounted API for Frames and Packets makes quite compelling updating from 9 even if we’ll keep updating both release branches for the next year and half.

You can help

There are a number of packets that depend on old 0.8 ffmpeg application and it won’t really work with the current avconv nor with the ffmpeg provided by the recent versions since the new option parsing code written by Anton ended up there as well. Most of those application are either fully orphaned or they have patches to work with avconv because the Debian and Ubuntu developers took care of it. Nikoli provided me with a list.

HWAccel 1.2

This week-end I eventually merged hwaccel1.2 and I hope to get the AVResample updates finalized by this week.

There had been some discussion regarding backporting the latter to release 10 since they simplify a bit porting to the new resampling library.

Rotation reporting API

Vittorio was working on a mean to export the rotation matrix from MOV and SEI NALs since a while. The devil is usually in the details and I guess it had been an hell of fun for him. Even more since he switched continent meanwhile.

After the Linus rant about not having the automagic support for rotation, we had some decent pressure applied to get it out so people will be able to enjoy it. Hopefully it will appear by the week end as well.

Sven Vermeulen a.k.a. swift (homepage, bugs)
Revamped our SELinux documentation (May 12, 2014, 20:15 UTC)

In the move to the Gentoo wiki, I have updated and revamped most of our SELinux documentation. The end result can be seen through the main SELinux page. Most of the content is below this page (as subpages).

We start with a new introduction to SELinux article which goes over a large set of SELinux’ features and concepts. Next, we cover the various concepts within SELinux. This is mostly SELinux features but explained more in-depth. Then we go on to the user guides. We start of course with the installation of SELinux on Gentoo and then cover the remainder of administrative topics within SELinux (user management, handling AVC denials, label management, booleans, etc.)

The above is most likely sufficient for the majority of SELinux users. A few more expert-specific documents are provided as well (some of them still work in progress, but I didn’t want to wait to get some feedback) and there is also a section specific for (Gentoo) developers.

Give it a review and tell me what you think.

May 09, 2014
Sven Vermeulen a.k.a. swift (homepage, bugs)
Dropping sesandbox support (May 09, 2014, 19:03 UTC)

A vulnerability in seunshare, part of policycoreutils, came to light recently (through bug 509896). The issue is within libcap-ng actually, but the specific situation in which the vulnerability can be exploited is only available in seunshare.

Now, seunshare is not built by default on Gentoo. You need to define USE="sesandbox", which I implemented as an optional build because I see no need for the seunshare command and the SELinux sandbox (sesandbox) support. Upstream (Fedora/RedHat) calls it sandbox, which Gentoo translates to sesandbox as it collides with the Gentoo sandbox support otherwise. But I digress.

The build of the SELinux sandbox support is optional, mostly because we do not have a direct reason to support it. There are no Gentoo users that I’m aware of that use it. It is used to start an application in a chroot-like environment, based on Linux namespaces and a specific SELinux policy called sandbox_t. The idea isn’t that bad, but I rather focus on proper application confinement and full system enforcement support (rather than specific services). The SELinux sandbox makes a bit more sense when the system supports unconfined domains (and users are in the unconfined_t domain), but Gentoo focuses on strict policy support.

Anyway, this isn’t the first vulnerability in seunshare. In 2011, another privilege escalation vulnerability was found in the application (see bug 374897).

But having a vulnerability in the application (or its interaction with libcap-ng) doesn’t mean an exploitable vulnerability. Most users will not even have seunshare, and those that do have it will not be able to call it if you are running with SELinux in strict or have USE="-unconfined" set for the other policies. If USE="unconfined" is set and you run mcs, targeted or mls (which isn’t default either, the default is strict) then if your users are still mapped to the regular user domains (user_t, staff_t or even sysadm_t) then seunshare doesn’t work as the SELinux policy prevents its behavior before the vulnerability is triggered.

Assuming you do have a targeted policy with users mapped to unconfined_t and you have built policycoreutils with USE="sesandbox" or you run in SELinux in permissive mode, then please tell me if you can trigger the exploit. On my systems, seunshare fails with the message that it can’t drop its privileges and thus exits (instead of executing the exploit code as it suggested by the reports).

Since I mentioned that most user don’t use SELinux sandbox, and because I can’t even get it to work (regardless of the vulnerability), I decided to drop support for it from the builds. That also allows me to more quickly introduce the new userspace utilities as I don’t need to refactor the code to switch from sandbox to sesandbox anymore.

So, policycoreutils-2.2.5-r4 and policycoreutils-2.3_rc1-r1 are now available which do not build seunshare anymore. And now I can focus on providing the full 2.3 userspace that has been announced today.

May 06, 2014
Denis Dupeyron a.k.a. calchan (homepage, bugs)
Tagaini Jisho (May 06, 2014, 18:30 UTC)

I haven’t been using Tagaini Jisho for long, but so far I’m impressed. Tagaini Jisho is a kanji dictionary and study tool. Here’s what the author has to say about it:

Tagaini Jisho is a free, open-source Japanese dictionary and kanji lookup tool that is available for Windows, MacOS X and Linux and aims at becoming your Japanese study assistant. It allows you to quickly search for entries and mark those that you wish to study, along with tags and personal notes. It also let you train entries you are studying and follows your progression in remembering them. Finally, it makes it easy to review entries you did not remember by listing them on screen or printing them on a small booklet.

Tagaini Jisho also features complete stroke order animations for more than 6000 kanji.

You can find the author’s website at http://www.tagaini.net/.

I have pushed version 1.0.2 to the tree. Note that there is a version of sqlite which is bundled with the source tarball. I tried to unbundle it but it wasn’t trivial (to me, at least), so I left it there for the time being. If you figure out how to properly unbundle sqlite, feel free to commit the changes yourself. As usual with my packages, don’t waste time asking if you can do it, just do it.

Alexys Jacob a.k.a. ultrabug (homepage, bugs)
uWSGI v2.0.4 (May 06, 2014, 07:58 UTC)

Quick post for an interesting version bump of uWSGI which brings an experimental loopengine for python3.4 asyncio (aka tulip) !

If you want to try it out, I added a python_asyncio USE flag. I’ve also made some cleanups on the ebuild wrt python versions and dropped older versions of uWSGI.

highlights

  • experimental asyncio loop engine (python 3.4 only)
  • httprouter advanced timeout management
  • purge LRU cache (v2) feature
  • allow duplicate headers in http parsers
  • faster on_demand Emperor management
  • fixed segfault for unnamed loggers

See the full changelog here.

May 04, 2014
Andreas K. Hüttel a.k.a. dilfridge (homepage, bugs)
KDE forums and Baloo discussion (May 04, 2014, 17:49 UTC)

In a recent blog post, I have criticized the events around the inclusion of Baloo in KDE 4.13.0. Since then, I have removed the blog post again, since a nice person convinced me it would not bring any good.

I would like to clarify two things.

First, I do not know of any forum threads that were locked in connection with this discussion or recent events, and I do not know of any similar, related actions on the KDE Forums. While I haven't directly stated this, I may have incorrectly insinuated that such an action took place, and for this I would like to offer my sincere apologies to the KDE Forums team.

Second, my post was interpreted the way that dissenting material had been removed in the KDE Forums. This was never my intention, and such an idea never even crossed my mind until I received feedback. I trust the integrity of the KDE Forum administrators and sincerely believe that such an action never happened and will never happen. I am sorry if you got a different impression from my words.

Please let us now get back to making KDE the best desktop environment ever.

Alexys Jacob a.k.a. ultrabug (homepage, bugs)
After vacation bug hunting (May 04, 2014, 16:53 UTC)

Two weeks vacations always seem short yet the 900+ mails waiting for sorting on my Gentoo Linux inbox was a reminder that our beloved distribution is well alive ! So I guess it was time for a little bug killing spree :)

rabbitMQ v3.3.0

This release improves performance in a variety of conditions, adds monitoring information to identify performance bottlenecks, adds dynamically manageable shovels, and allows Java-based clients to reconnect automatically after network failure.

This release also corrects a number of defects in the broker and plugins, as well as introducing a host of smaller features as you can see on the changelog. Be warned that the behavior of the guest user has been altered !

I also fixed a long awaiting bug to bump the rabbitMQ C client to v0.5.0

redis v2.8.9

Johan Bergström is as always doing a great and helpful job and is actively working on redis, thanks mate !

  • [NEW] The HyperLogLog data structure. You can read more about it  in this blog post
  • [NEW] The Sorted Set data type has now support for lexicographic range queries, check the new commands ZRANGEBYLEX, ZLEXCOUNT and ZREMRANGEBYLEX, which are documented at http://redis.io

py3status v1.5

  • fixes installation via pip
  • added a –version command line argument to get the currently installed version of py3status

upcoming bumps

You might be interested in what’s next on the todo list :

  • With the help of Thomas D. aka @Whissi, we’re working on bumping and enhancing rsyslog to v7.6.3. For this a series of its dependencies have been bumped today as well.
  • mongoDB v2.6.0 is also on track, as usual the guys @mongodb have broken the scons building so it’s taking more time than it should to fix this hell (all help appreciated).

May 03, 2014
Patrick Lauer a.k.a. bonsaikitten (homepage, bugs)

KDE 4.13 was released with a new indexer, named "Baloo". It mostly replaces the 'old' Akonadi indexer, which at first glance appears to be a good idea. It seems to work, so that's quite swell. There's only a problem. Or rather, some little problems, and upstream is one of them as they don't want to acknowledge that these issues exist. So let me try to explain ...

  • There are times when I just need the indexer to not run. For example when I'm watching a movie (IO activity -> stutter), doing a presentation (random lag?!) etc. And there are times (e.g. at night) when the indexer can run as much as it wants.
  • There are times when the indexer interferes with normal operation - e.g. when using firefox, the added IO activity causes the FF UI to lag severely, as if the machine was swapping. Partially also because the IO activity evacuates the filesystem cache, which is quite funny. And fsync plus lots of reads means the latency goes up to multiple seconds or even multiple tens of seconds for a single IO activity
  • The indexer claims to not interfere with normal operation. It limits itself to 10% CPU usage - which is the wrong metric, since I have lots of CPU and very little IO, relatively speaking. Thus it takes 100% of available IO bandwidth. Akonadi used up to 4 CPUs for longer amounts of time, but as it didn't hurt IO much I could just ignore it.
  • The indexer takes a LONG time. On boot it needs about 20 minutes walltime just to figure out if anything has changed. During that time service quality is severely degraded.
  • The indexer takes a long time. The initial scan of my home directory takes about, hmm, 36-48h I think, during which time service quality is severely degraded
  • The indexer isn't polite, it auto-respawns if you just kill the baloo_file_indexer process. You have to kill its parent too, otherwise it'll just respawn and bother you some more
  • [Fixed in next release] Removing a directory from the index causes an index cleaner to run, which is even more severe than the indexer itself
So, to summarize: As much as I like the indexer, it prevents me from working normally, so I have to insist that it has a simple "off" button. A lesson that akonadi learned, that gnome's tracker learned, is that you need to nice yourself down. It would be very much appreciated if baloo were to nice and ionice itself down to idle, which usually avoids the severe lag that foreground tasks may experience.

An extra bonus would be this: The indexer should do a microbenchmark on startup (or let the user provide a guesstimate) to figure out IO capacity in IO/s, and then limit itself to a configurable amount of that. If it takes 1/10th of my IO bandwidth (about 10-15 IO/s with a single SATA disk) it wouldn't even bother me more than, say, Firefox running in the background.

Another interesting glitch is that most indexers use inotify listeners to see if anything in a directory changes. This has the funny effect that it only works on small data sets - on my desktop I get random popups that an application wants to change system limits. Well, /proc/sys/fs/inotify/max_user_watches is already set to "262144" by default, and that's still not enough? This also takes memory, and it can't scale up. I "only" have a few million files, that's not even a lot.

So, to summarize:
Simple fixes:
  • Nice and ionice the indexer on startup
  • Provide users with a simple on/off mechanism
Advanced fixes:
  • Throttle on IO instead of CPU
  • Delay indexer startup for a little while on boot. Maybe 120sec grace period
  • Figure out system limits and fail gracefully instead of annoying users with popups
Well, dear upstream, don't accuse me of not being constructive ...
<DrEeevil> people complain about user-hostile behaviour, and you tell them to ... be nicer and not complain so loud?
<unormal> DrEeevil: To be honest. The only things I see from you in here since hours and days is hostile behaviour. I really would like to ask you to stop this and be constructive or otherwise leave <DrEeevil> unormal: well, if I didn't have to remove binaries and kill processes I'd be a lot happier
<DrEeevil> since upstream hasn't shown any understanding I'll rather escalate until the bugs are resolved
<DrEeevil> constructive: give me an off button so I can stop the indexer when it hurts me, give me a rate limit so I can run it while using the computer
<DrEeevil> (using 99% of available IO bandwidth for up to 72h is just not acceptable in normal use)
<DrEeevil> I don't want to remove the indexer, but I want to control how much resource usage it has
<DrEeevil> (bonus: ionice + nice it down to lowest/idle, then it doesn't bother that much)
<DrEeevil> it's not THAT hard to figure that out ...
<unormal> DrEeevil: Ok and now explicitely: Please do us a favor and leave the channel.
<DrEeevil> unormal: once I can have baloo installed and working as described above you'll never hear from me again
<DrEeevil> just every time I get a local DoS you get a complaint, so that you don't lose the motivation to fix the bugs
<unormal> That's not how you motivate people, please leave.
<DrEeevil> that's not how you write software, please fix
<DrEeevil> I'll be the stone in your shoe until you stop being the one in mine
<DrEeevil> heck, I'll even test patches once they are provided!
<krop> and ultimately, you'll roll on the floor crying until something happens ? how can gentoo accept immature people in their staff ?
--> seaLne (~seaLne@kde/kenny) has joined #kde-baloo
*** Mode #kde-baloo +o seaLne by ChanServ
<DrEeevil> krop: how can kde have releases with such serious regressions?
<DrEeevil> sorry, I don't deal with C++, in this case I'm just a QA tool
<krop> no, you just behave like a stubborn child
<DrEeevil> because I actually would like to USE kde
<DrEeevil> not sure how you see that, but it's kinda nice usually, except when someone staples in a DoS and then tells me that's all fine and dandy
<DrEeevil> maybe I should use git HEAD again to catch regressions earlier
*** Mode #kde-baloo +b DrEeevil!*@* by seaLne
*** Mode #kde-baloo +b not!*@* by seaLne
*** Mode #kde-baloo +b being!*@* by seaLne
*** Mode #kde-baloo +b constructive!*@* by seaLne
<DrEeevil> heh
<-* seaLne has kicked DrEeevil from #kde-baloo (DrEeevil)

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

KDE 4.13.0 has arrived for users of all distributions by now, and with it the new Baloo indexer. It may be well a fine-working piece of software for many use cases. However, it seems also many people have trouble with it, including myself. Let us google "baloo indexer". This is what I get as first search results (I'm dropping 2 related entries that clearly refer to a KDE Beta or RC):


  1. [kubuntu] How to disable baloo indexer - Ubuntu Forums

    ubuntuforums.org/showthread.php?t=2217434
    Apr 23, 2014 - 8 posts - ‎5 authors
    After the update to 14.04 Kubuntu I did notice an executable running constantly using up to 95% of my CPU time that I had never noticed before ...
  2. How to turn off baloo in KDE 4.13? - Ask Ubuntu

    askubuntu.com/questions/437635/how-to-turn-off-baloo-in-kde-4-13
    ... just installed the newest updates. Looking at the process list I see baloo indexer running. I could not find a checkbox in Baloo settings to turn off the indexing.
  3. Gentoo Forums :: View topic - KDE 4.13: How to disable baloo file ...

    https://forums.gentoo.org/viewtopic-t-986946.html?sid...
    Mar 22, 2014 - 25 posts - ‎12 authors
    So KDE 4.13 is looming, and it'll bring a new indexer 'baloo' while 'nepomuk'/'strigi' is still in the process of being phased out apparently.

  4. [SOLVED] KDE screw up: baloo-file indexer - how to shut it down ...

    https://www.kubuntuforums.net/showthread.php?...baloo...indexer...
    Apr 22, 2014 - 10 posts - ‎4 authors
    Just updated my last box - my main one - to KB 14.04. As I'm adjusting various things, I notice that something is seriously devouring CPU cycles ...
  5. KDE 4.13 Baloo sucking system resources. (Page 1) / Applications ...

    bbs.archlinux.org › ... › KDE 4.13 Baloo sucking system resources.
    Apr 19, 2014 - 25 posts - ‎13 authors
    Baloo only indexes files in /home/$user and doesn't not index any removable device by default. So that trick says to don't index anything.
The list goes on, including Kubuntu, Gentoo, Arch, and OpenSuSE users at least. Now, totally independent of the actual software details, this is for KDE a complete public relations disaster which no promotional press release can cure. Even if many many bugs are fixed until the next released version, the aftertaste will remain for a long time. [1]

Let's try to figure out what went wrong.

No software will ever be perfect, especially not in a first version. And most users are perfectly willing to try out something new and accept that it may be buggy in the beginning. (Seriously, why else would you run a KDE 4.X.0 release? :D [2,3]) However, they appreciate if this is a deliberate, and informed decision on their part, and if things go wrong they want to be able to switch them off.

What options are there to disable Baloo indexing?
  • The recommended one for files - add the home directory to the exclude list.
    Fairly unintuitive. Direct opposite of previous Nepomuk behaviour. Does not affect e-mail indexing. Only mentioned in "outside" documentation. In 4.13.0, if you dont do it immediately the resulting database cleaner process will pull your system down worse than the indexer ever did. (This is fixed in 4.13.1, I think.)
  • Do not install the Baloo package if your distribution allows that [4].
    Not an option for multi-user systems. Hey, maybe someone wants to try the cool new features and doesn't have a >100G home directory.
  • killall, sudo chmod, sudo rm, or fiddling in configuration files.
    What, seriously?
Here's the fairly official statement on why the Enable/Disable button is gone:
There is no explicit “Enable/Disable” button any more. We would like to promote the use of searching and feel that Baloo should never get in the users way. However, we are smart about it and IF you add your HOME directory to the list of “excluded folders”, Baloo will switch itself off since it no longer has anything to index.
OK, something about this statement is incongruent with reality. Found it? Right, the part about getting in the way. But please, this is a .0 release, so it's completely natural that the software can be buggy, and this was already foreseeable during RC and Beta releases. No problem, and we're happy to help getting the bugs fixed. However, this makes the decision to deliberately omit the big, clearly marked "OFF" button, hmm, slightly provocative. Maybe it would have been better to leave the button in for a while and get a bit less testing feedback in exchange.

Well, feedback. It is coming, as you can see all from the Google results. The response seems to be clearly divided into two groups. The large-number, loud one is the protesting users; many of them are getting angry, some get abusive. We're not talking about a few corner cases here. This went so far that on the kde-devel mailing list emergency moderation was turned on, and criticizing how the situation is handled seems to be the best way to get the KDE Community Code of Conduct cited to you by the second group, especially the "Be respectful" paragraph. However... switching the mailing list to moderated, kicking people from irc channels, or locking forum threads doesn't really solve any problem, and barely masks anything, it just helps you keep your personal bubble quiet. The unwanted side effect is to increase the general sense of frustration and shift annoyance and/or protest to other channels. Note that none of the links above is a KDE website? It's all distribution pages. Google finds them anyway.

Finally, what seems to be quietly dropped is that the KDE Community Code of Conduct contains two large sections "Be considerate" and "Be pragmatic". Quoting the former,
Your actions and work will affect and be used by other people and you in turn will depend on the work and actions of others. Any decision you take will affect other community members, and we expect you to take those consequences into account when making decisions.
In some other forum the question was asked, "Can you imagine a non-technical user wanting to temporarily disabling indexing?" I don't really have to imagine these users. They are pretty hard to miss, and they are people using baloo and being affected by its code. Please try to be aware that placing attitude over simple functionality add-ons hurts KDE as a whole.

So, how about a simple, immediately-acting, easy-to-find "off" button? Better late than never... and maybe backportable to 4.13.0? Or maybe, if that has already happened [5] and I only completely missed it, a clear statement of "We heard you"?



[1] No, rebranding to Rikki-Tikki-Tavi Community Edition won't help either.
[2] To be honest, the last .0 releases (4.10.0, 4.11.0, 4.12.0) were very unproblematic and smooth; that came as a pleasant surprise.
[3] Of course, not all the bugfixing in a new 4.X.Y release takes place upstream in the KDE git repositories. Having many willing users test 4.X.0 also leads to downstream fixes, be it packaging problems, reverts, or backports.
[4] Gentoo allows for an installation without any desktop search features, by disabling the semantic-desktop use flag. However, part of the relevant library code is, e.g., hard-required by kdepim (kmail, kontact, ...), which is why these programs require semantic-desktop to be switched on.
[5] Yes I know about the alternative configuration module by Lindsay Mathieson, I'm just testing it, and from the user interface I like it. I'll bring up in our next team meeting to have that installed as default. In the end, that's however just the distros doing the work for you... (and while users might be happier, everyone "upstream" will only rant about that impossible Gentoo again).

May 01, 2014
Gentoo Monthly Newsletter: April 2014 (May 01, 2014, 22:20 UTC)

Gentoo News

Interview with Chris Reffett (creffett)

1. Hi Chris, tell us about yourself.
I’m a Computer Science student studying at George Mason University in Fairfax, Virginia, USA, and I’m currently finishing my junior year. In my free time I read science fiction and play video games. I’m also a member of the student-run computing club and Linux user group on campus.

2. Bring us back to your start with electronics and computers.
Not all that much to say here; I’ve been playing with (and breaking) computers since I was about three years old. As my parents can attest, I managed to mess up my first computer within a few days of getting access to it, to the point of needing a complete reinstall.

3. How did you get involved with open source, and what path did you take to become a Gentoo developer?
I became involved in open source in high school; the school had a student-run Linux computer lab, and I joined the team in my second year. We used Gentoo heavily in the lab, and I ended up getting a lot of experience maintaining it there (and installing it—I made a point of grabbing any old odd-architecture hardware that came through the lab and putting Gentoo on it). I filed a few bugs and wrote a few in-lab ebuilds during my time there, but nothing too major.
Once I left and went to college, I decided I wanted to start actually contributing to Gentoo. The recruiters suggested a few different ways to contribute, and I ended up working with the KDE team, which put me on the road to becoming a dev.

4. Hows your programming skills and are they important in becoming a developer?
My programming skills aren’t anything special, enough to get through my classes and all that. I would say that the average developer needs to know enough programming to decipher error messages, do basic bash scripting, and understand how to read most code (to find and fix basic errors in packages). Entry-level knowledge, you don’t have to be a coding wizard.

5. Tell us about your mentor and the process to become a developer?
My mentor was tampakrap, the KDE team lead at the time, who has since ventured forth into the forbidden realms of the Infra team. After I had been contributing to the KDE team on bugzilla for a couple months, he asked if I was being recruited yet, and then if I wanted to become a dev. After that, I spent some time contributing to the KDE team repo, and was assigned tommy as my recruiter.

6. How can Gentoo improve?
One aspect of Gentoo that I think is both one of our biggest strengths and weaknesses is the very independent-minded culture among our developers. While this is not in itself a bad thing, it leads to a lot of instances where people refuse to cooperate or communicate, get very territorial about their packages, flamewars on gentoo-dev@, and so on. I think the project as a whole would be improved if developers were a little more civil and cooperative and a little less quick to shout at each other.

7. Tell us about some of the projects you are involved in.
I started out as a KDE team member, and am still a member (though recently I’m a lot less active there than I should be). Also, I am currently the sole developer in the theology team, though that isn’t so bad since it’s a small set of packages and the release schedules are pretty slow. I’m also one of the more recent inductees to the Security project (along with Pinkbyte and zlogene), a GLEP editor, and of course, I am a member of the QA team.

8. The QA project just made a overhaul, what does the project do, who is involved, where would you like to see it in 3 years?
The purpose of the Quality Assurance project is to help maintain consistency throughout the Portage tree and prevent things breaking. The project is also tasked with keeping documentation up to date. The current membership is available on the wiki, but every developer should be doing their part to minimize tree breakage (and this can be as simple as always running repoman when committing!).
Right now we are having a lot of growing pains, since we were handed a vague mandate of “maintain quality in the tree” (not particularly well defined in GLEP 48), had basically no notes or direction from the remains of the previous team, and as I’m sure you’ve noticed, have had our share of missteps as we figured everything out. I am listening to the complaints, though, and we will improve. In three years, I hope to see QA as a respected and reasonably non-controversial group of developers serving as the technical counterpart to the ComRel team. It’s a long way between where we are right now and that ideal role, though.

9. I see you as very organized and able to stay calm in flame wars, how do you do it?
Contrary to appearances, I am not all that calm when I’m in the middle of a flamewar, I just don’t show it. I do my venting outside of Gentoo channels, as several of my friends can attest, since I make a point of trying to be professional and calm when dealing with Gentoo matters. I also have gotten better at knowing when an argument is going nowhere and it’s most productive to just step away from the computer.

10. What are you learning from being a team lead?
Two things. First, that there are some decisions where no matter what you choose, somebody will be upset. Second, that people’s perception of you and your team is everything when you want people to cooperate.

11. What are your favorite programs?
Firefox for web browsing, Thunderbird for mail, Pidgin for IM/IRC.

12. Age old question for Gentoo, how can we get more help?
Proxy-maint is probably the first place I’d want to expand in order to get more help. My impression is that there are a lot of users out there who want their specific package in Portage and are willing to help out to that end, and so we should be welcoming them and helping them to maintain their ebuild (and hopefully, stepping up further and becoming devs).

13. Describe your desktop setup (WM/DE)?
KDE, of course, though for a long time now I’ve only really been using the WM and the terminal app, since most of the work I do is done on the command line.

14. Tell us about you boxes and home network setup?
Since I’m at college, there isn’t much of interest here. My main computer is a three-year-old laptop which dual-boots Windows (for games) and Linux. I also have a Pandaboard ES which I occasionally fiddle around with.

15. What gives you the most enjoyment within the Gentoo community?
Closing bugs. It’s always satisfying to be able to say that you’ve figured out an issue and fixed it.

16. What gives you the most enjoyment outside the Gentoo community?
Video games. I like games that involve building things, games that involve space, and strategy/tactics games.

17. What are your plans for the future, where do you see yourself 5 years from now?
I hope that in 5 years, I will still be doing Gentoo work. I also hope to be employed. That would be nice.

Google Summer of Code 2014

GSoC 2014 is going to start soon! We are right now in the middle of the community bonding period. Students and mentors are getting to know each others before projects start for real on May 20th. This is also the perfect time for them to review documentation and polish their plan for the entire project duration.

You are welcome to follow developments in the mailing list at gentoo-soc at gentoo.org or on Freenode in the #gentoo-soc channel. There you can interact with students, mentors, and offer suggestions.

We are excited about the four projects students will work on this year. Here they are:

netifrc on systemd
Student: Rabi Shanker Guha
Mentor: Robin Johnson
Short description: The goal of this project is to abstract away the tight dependence of netifrc on OpenRC and write a compatibility layer for netifrc to work with other init systems like Systemd

Gentoo Keys: Expansion and improvements
Student: Pavlos Ratis
Mentor: Brian Dolbec
Short description: I am interested in improving and expanding the capabilities of Gentoo Keys. Gentoo Keys is a Python based project that aims to manage the GPG keys used for validation on users and Gentoo’s infra servers. Gentoo Keys will be able to verify GPG keys used for Gentoo’s release media, such as installation CD’s, Live DVD’s, packages and other GPG signed documents. It will also be used by Gentoo infrastructure to achieve GPG signed git commits in the forthcoming git migration of the main CVS tree.

Layman Improvements
Student: Devan Franchini
Mentor: Matthew Summers
Short description: This project is aimed at adding python3 support to Layman while maintaining backwards compatibility with python2.7, as well as adding new features to the codebase.

Micro Gentoo
Student: Yiyong Chen
Mentor: Sébastien Fabbro
Short description: The Micro Gentoo project goal is to create an extremely minimal Gentoo VM and fetch compiled files on-demand. These files are initially on a remote server. Meanwhile, the project also considers the smooth-secure OS updates and remote repositories selection. I would comprehensively base my work on the technologies of uCernVM, Chromeos and CoreOS, and then adapt them to Gentoo. The deliverables include Micro-Gentoo building scripts, updaters, eselect module and patches to genkernel, etc.

See you in #gentoo-soc!

Council News

(by Andreas K. Huettel)

We’ve got to catch up one council meeting, so some things have accumulated by now and I’m summarizing a bit more than usual…

First of all, “GLEP 63: Gentoo GPG key policies” is finally finalized. Yay! You can find the approved text version here [1]. Most important part, if you want to follow the best practices you need a RSA (v4) 4096bit main key with expiry time of at most 3 years. Hard requirement for the main key is either DSA 2048bit or RSA (v4) >=2048bit and maximum 5 years expiry time. Anyway, this means we can actually start thinking about some marginally more advanced topics such as, say, even maybe sometime in the future signature verification!

Then… regarding the Filesystem Hierarchy Standard. Some debate had come up whether packages (i.e. udev, eudev, systemd) storing default config files in /usr/lib violate existing policies. End result of debate and motion was that this is OK and that no additional policy is required.

On the subject of base-2 (2^10) versus base-10 (10^3), kB versus KiB. Given that the council is heavily dominated by those SI-indoctrinated “scientists”, it didn’t really come as a big surprise that at least clear and unambiguous unit prefixes should be used. So here’s the adopted motion: “Whenever practical, developers are required to use unit prefixes defined in IEC 80000-13 (kB, KiB, etc) so that output is unambiguous. This does not require maintainers to patch upstream code to change its behavior, but they should be applied with code that originates in Gentoo.”

Next, we discussed some recent commits around virtual/libudev and the sequence of events that followed them. The feeling was that no additional policy is required at the moment, but that it would be useful to state the opinion of the council regarding these events. So, we wrote it up and sent an e-mail [2], please read it and keep it close to your heart.

Finally we would like to remind Petteri to upload the council meeting summary of June 2013! :)

[1] https://wiki.gentoo.org/wiki/GLEP:63
[2] http://thread.gmane.org/gmane.linux.gentoo.project/3549

Gentoo Developer Moves

Summary

Gentoo is made up of 232 active developers, of which 32 are currently away.
Gentoo has recruited a total of 794 developers since its inception.

Changes

The following developers have recently changed roles:

  • Jonathan Callen (jcallen) has joined the multilib project
  • Jason A. Donenfeld (zx2c4) has joined the radio herd
  • The entire mobile-phone herd has been removed due to lack of maintainers and interest

 Additions

No new developers have joined the project this month.

Moves

The following developers left the project (pending retirements since 2013)

  • Stephanie J. Lockwood-Childs (wormo)
  • Paul de Vrieze (pauldv)
  • Torsten Veller (tove)
  • Constanze Hausner (constanze)
  • Dane Smith (c1pher)
  • Robert Piasek (dagger)
  • Zhang Le (r0bertz)
  • Christian Parpart (trapni)
  • Rajiv Aaron Manglani (rajiv)
  • Mu Qiao (qiaomuf)
  • Lukasz Damentko (rane)
  • Olivier Crête (tester)
  • Tim Sammut (underling)
  • Serkan Kaba (serkan)
  • Benedikt Boehm (hollow)
  • Ron Gemeinhardt (timebandit)
  • Andrew Gaffney (agaffney)
  • Chris PeBenito (pebenito)
  • Michele Noberasco (s4t4n)

Help Wanted

The Ruby and Java projects are looking for help to keep jruby dev-java/jruby up to date and included in the portage tree. See this blog post and bug 442230 for more information. Moreover, proxy-maintainers are looking for new developers as well.

Portage

This section summarizes the current state of the portage tree.

Architectures 45
Categories 161
Packages 17380
Ebuilds 37123
Architecture Stable Testing Total % of Packages
alpha 3592 538 4130 23.76%
amd64 10707 6172 16879 97.12%
amd64-fbsd 0 1578 1578 9.08%
arm 2627 1656 4283 24.64%
arm64 436 29 465 2.68%
hppa 3041 489 3530 20.31%
ia64 3176 596 3772 21.70%
m68k 574 93 667 3.84%
mips 4 2375 2379 13.69%
ppc 6813 2397 9210 52.99%
ppc64 4310 878 5188 29.85%
s390 1476 312 1788 10.29%
sh 1673 384 2057 11.84%
sparc 4118 903 5021 28.89%
sparc-fbsd 0 319 319 1.84%
x86 11423 5196 16619 95.62%
x86-fbsd 0 3235 3235 18.61%

gmn-portage-stats-2014-04

Security

The following GLSAs have been released by the Security Team

GLSA Package Description Bug
201404-07 dev-libs/openssl OpenSSL: Information Disclosure 505278
201404-06 media-libs/mesa Mesa: Multiple vulnerabilities 432400
201404-05 net-fs/openafs OpenAFS: Multiple vulnerabilities 265538
201404-04 dev-ruby/crack Crack: Arbitrary code execution 460164
201404-03 media-gfx/optipng OptiPNG: User-assisted execution of arbitrary code 435340
201404-02 net-libs/libproxy libproxy: User-assisted execution of arbitrary code 438146
201404-01 net-print/cups CUPS: Arbitrary file read/write 442926

Package Removals/Additions

Removals

Package Developer Date
app-i18n/prime naota 02 Apr 2014
app-i18n/gtkimprime naota 02 Apr 2014
app-i18n/scim-prime naota 02 Apr 2014
app-emacs/prime-el naota 02 Apr 2014
dev-libs/suikyo naota 02 Apr 2014
app-emacs/mell ulm 02 Apr 2014
dev-ruby/locale_rails mrueg 05 Apr 2014
dev-ruby/parsetree mrueg 05 Apr 2014
dev-ruby/rubymail mrueg 05 Apr 2014
net-proxy/swiftiply mrueg 05 Apr 2014
www-servers/mongrel mrueg 05 Apr 2014
app-pda/libopensync-plugin-evolution2 ssuominen 06 Apr 2014
x11-themes/gdm-themes-livecd ulm 12 Apr 2014
net-ftp/pftpfxp ulm 14 Apr 2014
kde-misc/youtube-servicemenu johu 15 Apr 2014
sys-infiniband/libsdp alexxy 16 Apr 2014
dev-ruby/oniguruma mrueg 18 Apr 2014
dev-ruby/sary-ruby mrueg 18 Apr 2014
dev-ruby/rand mrueg 18 Apr 2014
dev-ruby/system_timer mrueg 18 Apr 2014
dev-ruby/fastercsv mrueg 18 Apr 2014
dev-ruby/ruby-taglib mrueg 19 Apr 2014
dev-ruby/rubytorrent mrueg 19 Apr 2014
dev-ruby/revolution mrueg 19 Apr 2014
app-misc/alexandria mrueg 19 Apr 2014
app-misc/bins zlogene 19 Apr 2014
dev-python/certifi floppym 20 Apr 2014
dev-python/mozfile floppym 20 Apr 2014
dev-python/mozinfo floppym 20 Apr 2014
dev-python/mozprocess floppym 20 Apr 2014
dev-python/mozprofile floppym 20 Apr 2014
dev-python/mozrunner floppym 20 Apr 2014
x11-themes/faenza-xfce-icon-theme ssuominen 23 Apr 2014
media-plugins/vdr-eggtimer hd_brummy 26 Apr 2014
media-plugins/vdr-ac3mode hd_brummy 26 Apr 2014
media-plugins/vdr-bitstreamout hd_brummy 26 Apr 2014
gnome-extra/evolution-groupwise pacho 26 Apr 2014
net-analyzer/ethstatus jer 27 Apr 2014

Additions

Package Developer Date
sys-apps/toybox patrick 01 Apr 2014
kde-base/zeroconf-ioslave johu 01 Apr 2014
dev-python/kivy-garden slis 02 Apr 2014
dev-python/Kivy slis 02 Apr 2014
dev-ruby/combustion mrueg 02 Apr 2014
dev-libs/double-conversion bicatali 02 Apr 2014
sci-libs/openlibm bicatali 02 Apr 2014
dev-python/cryptography-vectors radhermit 03 Apr 2014
media-libs/gstreamer-editing-services eva 06 Apr 2014
app-admin/clog tomwij 07 Apr 2014
dev-ruby/pygments_rb mrueg 07 Apr 2014
app-i18n/libcangjie naota 08 Apr 2014
sys-apps/netloc alexxy 08 Apr 2014
mate-base/caja tomwij 10 Apr 2014
dev-ruby/rkelly-remix zerochaos 11 Apr 2014
app-emulation/rex-client mduft 11 Apr 2014
xfce-extra/multiload-nandhp ssuominen 11 Apr 2014
app-backup/duply hwoarang 13 Apr 2014
dev-python/sparqlwrapper idella4 14 Apr 2014
media-video/movit patrick 15 Apr 2014
dev-python/cangjie naota 16 Apr 2014
sys-infiniband/libmlx5 alexxy 16 Apr 2014
sys-infiniband/qperf alexxy 16 Apr 2014
sys-infiniband/libocrdma alexxy 16 Apr 2014
dev-python/pyringe dastergon 16 Apr 2014
kde-base/baloo-widgets johu 16 Apr 2014
kde-base/kfilemetadata johu 16 Apr 2014
kde-base/baloo johu 16 Apr 2014
dev-python/pyroma dastergon 16 Apr 2014
dev-libs/libntru hasufell 16 Apr 2014
sys-libs/ntdb polynomial-c 17 Apr 2014
www-apps/jekyll mrueg 18 Apr 2014
dev-ruby/awesome_nested_set mrueg 18 Apr 2014
sec-policy/selinux-accountsd swift 18 Apr 2014
net-analyzer/nagios-check_openvpn-simple mjo 20 Apr 2014
dev-python/oslo-rootwrap prometheanfire 20 Apr 2014
dev-python/oslo-messaging prometheanfire 21 Apr 2014
dev-python/pycadf prometheanfire 21 Apr 2014
dev-ruby/fivemat zerochaos 21 Apr 2014
dev-python/python-saharaclient prometheanfire 22 Apr 2014
dev-ruby/charlock_holmes mrueg 22 Apr 2014
dev-ruby/forgery mrueg 22 Apr 2014
kde-base/kqtquickcharts kensington 22 Apr 2014
kde-base/artikulate kensington 22 Apr 2014
app-admin/eselect-lua mabi 22 Apr 2014
dev-python/pycollada xmw 23 Apr 2014
app-i18n/ibus-cangjie naota 24 Apr 2014
www-misc/zoneminder dilfridge 25 Apr 2014
net-libs/libosmo-abis zx2c4 26 Apr 2014
net-wireless/openbsc zx2c4 26 Apr 2014
net-wireless/osmobts zx2c4 26 Apr 2014
dev-ruby/actionview graaff 26 Apr 2014
dev-libs/uchardet maksbotan 26 Apr 2014
net-dns/dnscap wschlich 26 Apr 2014
net-libs/liba53 zx2c4 26 Apr 2014
net-firewall/fwknop tomwij 27 Apr 2014
net-misc/lcr zx2c4 27 Apr 2014
app-arch/engrampa tomwij 27 Apr 2014
app-editors/pluma tomwij 27 Apr 2014
app-text/atril tomwij 27 Apr 2014
media-libs/libmediaart eva 27 Apr 2014
net-libs/libgfbgraph eva 27 Apr 2014

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 29 March 2014 and 28 April 2014. Not fixed means bugs that were resolved as NEEDINFO, WONTFIX, CANTFIX, INVALID or UPSTREAM.
gmn-activity-2014-04

Bug Activity Number
New 1452
Closed 891
Not fixed 148
Duplicates 164
Total 5677
Blocker 4
Critical 17
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 44
2 Gentoo KDE team 37
3 Python Gentoo Team 35
4 Gentoo Linux Gnome Desktop Team 34
5 Gentoo Security 30
6 Nikoli 23
7 Java team 19
8 media-video herd 18
9 Gentoo Linux MySQL bugs team 17
10 Others 633

gmn-closed-2014-04

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 Linux bug wranglers 90
2 Gentoo Security 85
3 Gentoo KDE team 55
4 Gentoo Linux Gnome Desktop Team 55
5 Nikoli 52
6 Python Gentoo Team 48
7 Gentoo's Team for Core System packages 44
8 Portage team 34
9 Gentoo Games 28
10 Others 960

gmn-opened-2014-04

Tip of the month

Portage File List

What is Portage File List?
Portage File List collects which files are installed by which ebuild on users machines. It shares this data publicly for searching/browsing.

PFL needs Portage data from your system. The more ebuilds you have installed the better. The more exotic ebuilds you have installed the better. Every Gentoo user can help!

emerge app-portage/pfl

This will install a cron job that submits new data to the PFL servers every week. Don’t worry, your privacy remains protected as we are not collecting anything else than portage data, and we don’t store who sends what.

As a bonus you get /usr/bin/e-file a command line utility to search for files installed by ebuilds. It allows a user to search for files that are not installed on their system and figure out which ebuild they need to install in order to obtain it. E-file requires internet access to obtain its information from the PFL website and database. Pfl is quicker than equery to search for files (even if not installed locally), while equery is more powerful and gives more options to search. Equery is limited to currently installed packages only.

The equery program is installed with the app-portage/gentoolkit package, a collection of administration scripts for Gentoo.

Heard in the community

Send us your favorite Gentoo script or tip at gmn@gentoo.org

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.

April 28, 2014
Alex Legler a.k.a. a3li (homepage, bugs)
Gentoo LaTeX Beamer Theme (April 28, 2014, 11:44 UTC)

Due to frequent requests, here’s the LaTeX Beamer theme I made for the 2012 Gentoo Miniconf in Prague:

Gentoo beamer theme

It’s available via git:
https://git.a3li.li/r/gentoo/beamer-gentoo.git
or to browse online:
https://git.a3li.li/summary/gentoo!beamer-gentoo.git

The contrib/ directory contains a fixed outer template for LaTeX Beamer that increases the top and bottom margins. That hack was needed as the projector back in Prague cropped the image in a weird way. May come in handy for other venues as well. ;)

April 23, 2014
Hans de Graaff a.k.a. graaff (homepage, bugs)
The precarious state of jruby in Gentoo (April 23, 2014, 17:13 UTC)

tl;dr jruby in Gentoo will have to go unless we get volunteers to help us with the jruby 1.7 series.

jruby has been available in Gentoo since 2004 and is currently at version 1.6.8. People following jruby will realize that this is a problem: the latest upstream version is 1.7.12 as of this writing. The 1.6 series is also based on ruby 1.8.7 by default. This is a problem since we have removed ruby 1.8 from the tree altogether, and support for it in ruby packages is disappearing fast. jruby 1.6 has a 1.9 mode, but that is based on ruby 1.9.2 where most packages expect at least 1.9.3. We are currently experimenting with defaulting to 1.9.2 mode to extend the 1.6 series. In short, more and more packages that currently have jruby target will loose it on updates since it simply is no longer compatible with jruby 1.7 and in its current state jruby in Gentoo is ready for a slow and agonizing descent. Or we could just be quick about it and mask it soon.

Why not just update to jruby 1.7, you might wonder? We have bug 442230 to track this update, but unfortunately it turns out that it is not easy to add the 1.7 series of jruby to Gentoo. The biggest stumbling block here is that the 1.7 build system is based on Maven. Using Maven is not well supported in Gentoo, mostly because Maven requires the ability to download code during its build phase and does not play very nice with Gentoo's package structure in general. It may be possible to fix this, but that requires good knowledge of Java and Ruby on Gentoo. Currently we don't have any developers capable of both, and passing the code back and forth isn't very practical and proves to go very slow in practice.

So we are looking for a volunteer who wants to pick up this project, and help us bring the jruby 1.7 series to Gentoo. If you see this as a step to become a Gentoo developer than that's great and we can mentor you. If you see this as an interesting one-off project to help out with, that's great too. Once 1.7 is in the tree it should not be a big deal to keep up with new versions. Feel free to drop by in #gentoo-ruby to discuss this with us if you are interested. Our ruby overlay holds the current work-in-progress on jruby 1.7.

If no-one volunteers, unless a magical break-through suddenly appears, we will most likely be forced to mask jruby and remove it from the tree. Help us to not do that!

April 20, 2014
Sven Vermeulen a.k.a. swift (homepage, bugs)

Today I had to verify a patch that I pushed upstream but which was slightly modified. As I don’t use the tool myself (it was a user-reported issue) I decided to quickly drum up a live ebuild for the application and install it (as the patch was in the upstream repository but not in a release yet). The patch is for fcron‘s SELinux support, so the file I created is fcron-9999.ebuild.

Sadly, the build failed at the documentation generation (something about “No targets to create en/HTML/index.html”). That’s unfortunate, because that means I’m not going to ask to push the live ebuild to the Portage tree itself (yet). But as my primary focus is to validate the patch (and not create a live ebuild) I want to ignore this error and go on. I don’t need the fcron documentation right now, so how about I just continue?

To do so, I start using the ebuild command. As the failure occurred in the build phase (compile) and at the end (documentation was the last step), I tell Portage that it should assume the build has completed:

~# touch /var/portage/portage/sys-process/fcron-9999/.compiled

Then I tell Portage to install the (built) files into the images/ directory:

~# ebuild /home/swift/dev/gentoo.overlay/sys-process/fcron/fcron-9999.ebuild install

The installation phase fails again (with the same error as during the build, which is logical as the Makefile can’t install files that haven’t been properly build yet.) As documentation is the last step, I tell Portage to assume the installation phase has completed as well, continuing with the merging of the files to the life file system:

~# touch /var/portage/portage/sys-process/fcron-9999/.installed
~# ebuild /home/swift/dev/gentoo.overlay/sys-process/fcron/fcron-9999.ebuild qmerge

Et voila, fcron-9999 is now installed on the system, ready to validate the patch I had to check.

April 17, 2014
Sven Vermeulen a.k.a. swift (homepage, bugs)
If things are weird, check for policy.29 (April 17, 2014, 19:01 UTC)

Today we analyzed a weird issue one of our SELinux users had with their system. He had a denial when calling audit2allow, informing us that sysadm_t had no rights to read the SELinux policy. This is a known issue that has been resolved in our current SELinux policy repository but which needs to be pushed to the tree (which is my job, sorry about that). The problem however is when he added the policy – it didn’t work.

Even worse, sesearch told us that the policy has been modified correctly – but it still doesn’t work. Check your policy with sestatus and seinfo and they’re all saying things are working well. And yet … things don’t. Apparently, all policy changes are ignored.

The reason? There was a policy.29 file in /etc/selinux/mcs/policy which was always loaded, even though the user already edited /etc/selinux/semanage.conf to have policy-version set to 28.

It is already a problem that we need to tell users to edit semanage.conf to a fixed version (because binary version 29 is not supported by most Linux kernels as it has been very recently introduced) but having load_policy (which is called by semodule when a policy needs to be loaded) loading a stale policy.29 file is just… disappointing.

Anyway – if you see weird behavior, check both the semanage.conf file (and set policy-version = 28) as well as the contents of your /etc/selinux/*/policy directory. If you see any policy.* that isn’t version 28, delete them.

April 16, 2014
Alexys Jacob a.k.a. ultrabug (homepage, bugs)
py3status v1.4 (April 16, 2014, 10:18 UTC)

I’m glad to announce the release of py3status-1.4 which I’d like to dedicate to @guiniol who provided valuable debugging (a whole Arch VM) to help me solve the problem he was facing (see changelog).

I’m gathering wish lists an have some (I hope) cool ideas for the next v1.5 release, feel free to post your most adventurous dreams !

changelog

  • new ordering mechanism with verbose logging on debug mode. fixes rare cases where the modules methods were not always loaded in the same order and caused inconsistent ordering between reloads. thx to @guiniol for reporting/debugging and @IotaSpencer and @tasse for testing.
  • debug: dont catch print() on debug mode
  • debug: add position requested by modules
  • Add new module ns_checker.py, by @nawadanp
  • move README to markdown, change ordering
  • update the README with the new options from –help

contributors

Special thanks to this release’s contributors !

  • @nawadanp
  • @guiniol
  • @IotaSpencer
  • @tasse

April 15, 2014

Recent versions of OpenSSL were found to be affected by an information disclosure vulnerability related to TLS heartbeats, nicknamed Heartbleed. It allows attackers to read up to 64kb of random server memory, possibly including passwords, session IDs or even private keys.

After the public disclosure on April 7, we have confirmed that several services provided by Gentoo Infrastructure were vulnerable as well. We have immediately updated the affected software, recreated private keys, reissued certificates, and invalidated all running user sessions. Despite these measures, we cannot exclude the possibility of attackers exploiting the issue during the time it was not publicly known to gain access to credentials or session IDs of our users. There are currently no indications this has happened.

However, to be safe, we are asking you to reset your passwords used for Gentoo services within the next 7 days. You need to take action if you have an account on one of the following sites:

  • blogs.gentoo.org
  • bugs.gentoo.org
  • forums.gentoo.org
  • wiki.gentoo.org

After 7 days, we will be removing all passwords to avoid abuse. For more information and the full announcement, visit http://infra-status.gentoo.org/notice/20140413-heartbleed.

April 10, 2014
Luca Barbato a.k.a. lu_zero (homepage, bugs)
Security and Tools (April 10, 2014, 09:51 UTC)

Everybody should remember than a 100% secure device is the one unplugged and put in a safe covered in concrete. There is always a trade-off on the impairment we inflict ourselves in order to stay safe.

Antonio Lioy

In the wake of the heartbleed bug. I’d like to return again on what we have to track problems and how they could improve.

The tools of the trade

Memory checkers

I wrote in many places regarding memory checkers, they are usually a boon and they catch a good deal of issues once coupled with good samples. I managed to fix a good number of issues in hevc just by using gcc-asan and running the normal tests and for vp9 took not much time to spot a couple of issues as well (the memory checkers aren’t perfect so they didn’t spot the faulty memcpy I introduced to simplify a loop).

If you maintain some software please do use valgrind, asan (now also available on gcc) and, if you are on windows, drmemory. They help you catch bugs early. Just beware that sometimes certain versions of clang-asan miscompile. Never blindly trust the tools.

Static analyzers

The static analyzers are a mixed bag, sometimes they spot glaring mistakes sometimes they just point at impossible conditions.
Please do not put asserts to make them happy, if they are right you just traded a faulty memory access for a deny of service.

Other checkers

There are plenty other good tools from the *san family one can use, ubsan is maybe the newest available in gcc and it does help. Valgrind has plenty as well and the upcoming drmemory has a good deal of interesting perks, if only upstream hadn’t been so particular with release process and build systems you’d have it in Gentoo since last year…

Regression tests

I guess everybody is getting sick of me talking about fuzzy testing or why I spent weeks to have a fast regression test archive called playground for Libav and I’m sure everybody in Gentoo is missing the tinderbox runs Diego used to run.
Having a good and comprehensive batch of checks to make sure new code and new fixes do not have the uncalled side effect of breaking stuff is nice, coupled with git bisect makes backporting to fix issues in release branches much easier.

Debuggers

We have gdb, that works quite well, and we have lldb that should improve a lot. And many extensions on top of them. When they fail we can always rely on printf, or not

What’s missing

Speed

If security is just an acceptable impairment over performance in order not to crash, using the tools mentioned are an acceptable slow down on the development process in order not to spend much more time later tracking those issues.

The teams behind valgrind and *san are doing their best to just make the execution three-four times as slow when the code is instrumented.

The static analyzers are usually just 5 times as slow as a normal compiler run.

A serial regression test run could take ages and in parallel could make your system not able to do anything else.

Any speed up there is a boon. Bigger hardware and automation mitigates the problem.

Precision

While gdb is already good in getting you information out of gcc-compiled data apparently clang-compiled binaries are a bit harder. Using lldb is a subtle form of masochism right now for many reasons, it getting confused is just the icing of a cake of annoyance.

Integration

So far is a fair fight between valgrind and *san on which integrates better with the debuggers. I started using asan mostly because made introspecting memory as simple as calling a function from gdb. Valgrind has a richer interface but is a pain to use.

Reporting

Some tools are better than other in pointing out the issues. Clang is so far the best with gcc-4.9 coming closer. Most static analyzers are trying their best to deliver the big picture and the detail. gdb so far is incredibly better compared to lldb, but there are already some details in lldb output that gdb should copy.

Thanks

I’m closing this post thanking everybody involved in creating those useful, yet perfectible tools, all the people actually using them and reporting bugs back and everybody actually fixing the mentioned bugs so I don’t have to do myself alone =)

Everything is broken, but we are fixing most of it together.

April 08, 2014
Alexys Jacob a.k.a. ultrabug (homepage, bugs)
mongoDB 2.4.10 & pymongo 2.7 (April 08, 2014, 16:05 UTC)

I’m pleased to announce those latest mongoDB related bumps. The next version bump will be for the brand new mongoDB 2.6 for which I’ll add some improvements to the Gentoo ebuild so stay tuned ;)

mongodb-2.4.10

  •  fixes some memory leaks
  • start elections if more than one primary is detected
  • fixes issues about indexes building and replication on secondaries
  • chunk size is decreased to 255 KB (from 256 KB) to avoid overhead with usePowerOf2Sizes option

All mongodb-2.4.10 changelog here.

pymongo-2.7

  • of course, the main feature is the mongoDB 2.6 support
  • new bulk write API (I love it)
  • much improved concurrency control for MongoClient
  • support for GridFS queries

All pymongo-2.7 changelog here.

April 06, 2014
Raúl Porcel a.k.a. armin76 (homepage, bugs)
New AArch64/arm64 stage3 available (April 06, 2014, 12:54 UTC)

Hello all,

Following up with my AArch64/ARM64 on Gentoo post, in the last months Mike Frysinger (vapier) has worked in bringing arm64 support to the Gentoo tree.

He has created the profiles and the keyword, along with keywording a lot of packages(around 439), so props to him.

Upstream qemu-2.0.0-rc now supports aarch64/arm64, so I went ahead and created a stage3 using the new arm64 profile. Thanks to Mike I didn’t had to fight with a lot of problems like in the previous stage3.

For building I just had to have this in my package.keywords file:

=app-text/opensp-1.5.2-r3 **
=dev-util/gperf-3.0.4 **
=sys-apps/busybox-1.21.0 **
=app-text/sgml-common-0.6.3-r5 **
=app-text/openjade-1.3.2-r6 **
=app-text/po4a-0.42 **
=dev-perl/Text-CharWidth-0.40.0 **
=dev-perl/SGMLSpm-1.03-r7 **
=dev-util/intltool-0.50.2-r1 **
=dev-perl/XML-Parser-2.410.0 **
=dev-perl/Text-WrapI18N-0.60.0 **
=sys-apps/coreutils-8.22

And in my package.use file:

sys-apps/busybox -static

coreutils-8.21 fails to build, 8.22 built fine. And building busybox with USE=”static” still fails.

Also I’ve just found out that USE=”hpn” on net-misc/openssh makes the client segfault. Not sure if its because of qemu or because the unaligned accesses hpn had aren’t happy on arm64. So if you plan to use the ssh client in the arm64 chroot, make sure you have USE=”-hpn”

By the way, app-arch/lbzip2 seems to fail to run here, not sure if its because of qemu or it simply doesn’t work on arm64. It segfaults.

You can download it from: http://gentoo.osuosl.org/experimental/arm/arm64

I’ve also starting to upload some binary packages: http://tinderbox.dev.gentoo.org/default/linux/arm64/

Also, if someone wants to give us access to arm64 hardware, we would be really happy :)

 


April 05, 2014
Patrick Lauer a.k.a. bonsaikitten (homepage, bugs)
"smart" software (April 05, 2014, 10:29 UTC)

1) Grab webbwrowser
2) Enter URL
3) Figure out that webbrowser doesn't want to use HTTP because ... saturday? I don't know, but ass'u'me'ing that some URLs are ftp is just, well stupid, because your heuristic is whack.

Or, even more beautiful:

$ clementine
18:02:59.662 WARN  unknown                          libpng warning: iCCP: known incorrect sRGB profile 
Bus error


I have no idea what this means, so I'll be explicitly writing http:// at the beginning of all URL I offer to Firefox. And Clementine just got a free travel to behind the barn, where it'll get properly retired - after all it doesn't do the simple job it was hired to do. Ok, before it randomly didn't play "some" music files because gstreamer, which makes no sense either, but open rebellion will not have happy results.

I guess the moral of the story is: Don't misengineer things, clementine should output music and not be a bus driver. Firefox should not interpret-dance the URLS offered to it, but since it's still less retarded than the competition it'll be allowed to stay a little bit longer.

Sigh. Doesn't anyone engineer things anymore?

April 01, 2014
Gentoo Monthly Newsletter - March 2014 (April 01, 2014, 03:02 UTC)

The March 2014 GMN issue is now available online.

This month on GMN:

  • Interview with Gentoo developer Tom Wijsman (TomWij)
  • Tracking the history of Gentoo: Gentoo Galaxy
  • Latest Gentoo news, tips, interesting stats and much more.

March 31, 2014
Gentoo Monthly Newsletter: March 2014 (March 31, 2014, 19:07 UTC)

Gentoo News

Interview with Tom Wijsman (TomWij)

(by David Abbott)

1. To get started, can you give us a little background information about yourself?

Tom Wijsman is my full name; TomWij is formed as a shorter nickname, taking the first three letters twice. 24 years is how long I’ve been alive and Antwerp, Belgium is where you can find me eating, hanging around, sleeping, studying, working and so on…

At university, I study the Computer Science programme with a specialization in Software Engineering. As the last year starts now, my student time is almost over.

Over the last years, a lot of programming languages have passed by there and on Gentoo Linux; which makes participation in both of them really worth it.

Besides programming, listening and playing some music is what I like to do. Currently I own an electric guitar, which sometimes is played on; but maybe I go for another instrument soon and practice in a more dedicated manner. Occasionally, I play FPS or RTS games too.

2. Tell us about your introduction to Gentoo?

The first look at Gentoo was when I was a dedicated enthusiast Windows user, who would run as much on Windows as possible. Once I’ve tried to set up a Windows / Linux combination by running SUA / Interix together with Xming, but as I barely knew Linux back then that didn’t come to a good end. Later, Linux was needed for university; as we needed to guarantee our software compiles and works on the lab computers that run Linux.

Having used another distribution in a virtual machine for some time; I discovered that it was slow without hardware virtualization, which we didn’t have yet back then. Something fast and small on a separate partition was needed; and thus, a small bit of space was cleaned out at the end of the partition and Gentoo was used to create a quite minimal setup with just what’s necessary to develop, compile and test.

When the need for that was over, the small partition was ditched; thus I have been using Windows for several years, but with Windows 8 going RTM and the changes that happened I started to realize that I wanted an OS that can be changed to what I like, instead of doing things the way in the limited amount of ways they can be done.

So, Gentoo Linux came back in mind; and that’s how I made the switch to it last year.

3. Describe your journey to become a Gentoo developer?

Not long after becoming an user of Gentoo, I decided to contribute back; so, I started to try to package some things that I used on Windows or which fitted the current needs back then. From there on I looked for ways to contribute, at which time I found a blog post that the kernel team is looking for users to help; there was too many users, so, I didn’t make the cut.

Apparently, none of them sticked to it; so, later I got back to try again and then the kernel lead mentored me. As this was a good opportunity, the next days were spent on studying the development manual and answering the quizzes as detailed as possible; I took a self-study approach here, looking back on it having seen every part of the devmanual certainly gains you a lot, as you can recall where things are and know enough to not break the Portage tree.

After a recruiter reviewed the quiz responses a year ago; I learned more during the review, that’s how I became Gentoo Developer and six months after I switched from Windows.

4. What are some of the projects you are involved with and the packages you help maintain?

Besides working on our Kernel releases, recently I have joined the QA and Portage team to keep the quality of our distribution high and improve repoman; in the longer end I plan to improve Portage and/or pkgcore when I get to learn their code base better. Other teams I am on are the Proxy Maintainers (to help Gentoo users maintain packages without them needing to become a Gentoo Developer); as well as the Java, Dotnet, Bug Wranglers and Bug Cleaners projects. The last two projects help get bugs assigned and cleaned up.

Next to those projects I maintain or help maintain some packages that I either personally use, am interested in or where work was needed. One of the last introduced packages is Epoch, a new minimal init system. It boots extremely fast on the Raspberry Pi.

5. I proxy-maintain a few packages myself. I am a staff member without commit rights. Its a great way to give back and also help maintain a package that you like and use. To prepare I did the ebuild quiz for my own understanding of ebuild writing and set up a local overlay to test my ebuilds. What are some other ways a user can become confident enough to maintain some packages?

The basic guide to write Gentoo Ebuilds is a guide that was started to cover the very first steps to writing an ebuild; this resource was previously non existing, it was written to close the gap between having no prior knowledge and the Gentoo Development Guide.

The Gentoo Development Guide is a great reference to find most details and policy one needs to know for writing ebuilds; when working in the terminal, checking out man 5 ebuild can be handy to quickly look up syntax, variables and functions of the ebuild format.

Creating a local overlay allows you to start locally experimenting with ebuilds. When you feel confident you can request a hosted overlay (or create one yourself on a third party service like GitHub and file a similar bug requesting it to be added to the overlay list) or contribute to the Portage tree (through proxy maintenance or you can become developer if you want to) or an existing overlay.

When you do proxy maintenance, the proxy maintainers will help you by advising and reviewing the ebuild and letting you know how to improve it; if you work on an overlay, there are other mediums (where proxy maintainers are present as well) to ask questions or get your ebuild reviewed. For example, #gentoo-dev-help on the Freenode IRC network is helpful.

Besides that users are advised to run

repoman manifest && repoman full

to check for QA errors, QA keywords are explained in the last part of man repoman it can help find common mistakes, as well as help increase the quality for it to be added to the Portage tree.

6. What do you think Gentoo’s strengths and weaknesses are both as a development platform and as a general purpose Linux Distribution?

That you can very easily patch up packages is a very nice feature, as well as the code that gets compiled by those packages; you can simply unpack the code;

ebuild unpack foo-1.ebuild

and write a patch for one or more file(s), then put the patch in /etc/portage/patches/app-bar/foo and there you have your patched code.

Besides patching up packages, the USE flag control in Gentoo is what makes Gentoo powerful. This controls the features of packages to allow you to have packages fit your usage rather than become bloated with features, libraries and other size hogs you never need. Alongside USE flag control becomes the ability to choose alternative libraries, alternative GUIs more; which is nice when you prefer the way something works or looks like.

What I think Gentoo could use more is more manpower; what made Gentoo powerful is its community, and its community is formed by users who contribute. And to this extent the amount of contributions determine how powerful Gentoo becomes.

If users are interested; they are welcome to contribute to Gentoo, to make it even more powerful than ever before. They don’t necessarily need much prior knowledge, there’s something for everybody; and if needed, we can help them learn more.

7. Can you describe your personal desktop setup (WM/DE)?

As desktop environment; I use GNOME 3, I’m glad to see the way they have progressed in terms of their user interface. GNOME 2 I’ve also used in the past, because I didn’t bother searching further too much; but didn’t really like GNOME 2’s UI. GNOME 3’s UI gets out of the way and I like how it focuses on the more typical user that has no special requirements.

Alongside that comes the requirement to run systemd; though that was in use long before running GNOME 3, as a while ago I was on XFCE and was experimenting around to see if systemd fits certain needs. It does; so does XFCE as well, so while I don’t really like it UI like with GNOME 2, I considered XFCE as an alternative DE to switch to. However, very recently I’m using MATE on top of GNOME 3; if GNOME 3 breaks, MATE is my new alternative DE.

The particular thing that I like about systemd is that it allows you to easily make a huge cut in boot time; while this kind of parameter has no good purpose in general, it does help as I need to test kernel releases and sometimes switch between NVIDIA and Nouveau module. The boot is down to two seconds after the boot loader hands over; at this point, you discover that the bootchart PNG export feature doesn’t allow you to scale the graph…

On the Raspberry Pi, Epoch gets the boot time down to seconds; as it was bothering that it previously took over a minute, as that is what running init scripts (which are shell) does together with all what they call when you run it on slow embedded hardware. Whereas Epoch is a daemon with a single configuration file that just starts a few processes and that’s it.

It also helped for bisecting as well as hacking up a reclocking patch for the Nouveau module a bit; while making it work on the NVIDIA card, the patch is still unstable and might break other cards and further improving it is quite a steep learning curve and a lot of work.

Other software that I use is AutoKey to quickly paste text that I need to repeat often (comments on bugs, e-mail responses, …); Chromium which I think is a browser that gets out of the way with its minimal interface; WeeChat (actively developed irssi clone with a ton of extra features); a mail client that does what I need (Claws Mail); and I could go on for hours, so, feel free to ask if you want to know more…

8. What are the specs of your current boxes?

Currently I own a Clevo W870CU barebone laptop that is put together; it features a Intel Corporation 5 Series/3400 Series Chipset, a Full HD 17 inch screen and enough interface ports. The processor in it is an Intel(R) Core(TM) i7 CPU Q 720. As hard disks I use a Intel X25-M 160 GB SSD and a Seagate Momentus 7200.3 320 GB HDD. There are also a NVIDIA GeForce GTX 285M, Intel Corporation WiFi Link 5100 and Realtek RTL8111/8168/8411 PCIE Gigabit Ethernet Controller inside.

As for the Raspberry Pi, it is a model B; you can find its specifications here. I gave it a 32 GB SD card with Gentoo on it where the 32 GB gives it some room before wearing it out. Alongside there are two external drives of a few terabytes to store big data and backups.

The Raspberry Pi here kind of acts like a cheap all-in-one NAS and/or media solution.

9. As a Gentoo Developer what are some of your accomplishments?

On the kernel team, the kernel eclass and genpatches scripts were adapted to bring support for experimental patches; this allows adding experimental patches to kernel packages using USE=experimental, without applying them by default. A condition for an experimental patch to be added is that applying the patch does not change the runtime behavior; in other words, we want changes to be guarded by a config option, in addition to USE=experimental. The eventual end goal is to have a lot of the regular experimental patches supported, to deduplicate work amongst kernel packages and our users.

Besides making improvements to the kernel packaging I maintain packages that I use and/or packages that need maintenance; at the moment, MATE is being brought to the Portage tree. Quality Assurance work I also do to keep the quality of the Portage tree high.

10. What would be your dream job?

While not having anything specific in mind, developing on “something” is what I have in mind.

In the context of the business world, that could be solutions that aid users with their daily tasks; in the context of the gaming world, maybe some indie game in the hope that it grows out; and last, I listen to music a lot, so, maybe within that context it could be some kind of computer science solution within that field.

Relying on yet-to-discover science is what I’d like to avoid, and rather rely on what is a given already; such that becoming popular is the only real risk. Once popularity has been obtained, then exploration might become an option; although one should not ignore that exploration can lead to popularity, but as said that is not without risk.

11. What users would you like to recruit to become Gentoo Developers?

Good question; many people are qualified, anyone that’s interested can expect help from us.

12. What gives you the most enjoyment within the Gentoo community?

Giving back to the community as an appreciation of what the community has given to me.

Gentoo Galaxy: Keeping History of Gentoo

(by Seemant Kulleen)

Gentoo Galaxy aims to make sure that Gentoo’s history is as accurate as possible, that every Gentoo developer’s contribution is acknowledged and valued. We’re starting with our list of Gentoo developers. We currently have all developers who have been active in Bugzilla and/or the 4 main CVS repositories throughout Gentoo’s history represented in a visualization here: http://kulleen.org/gentoo/galaxy

That page contains a list of developers for whom we need more information — we want to visualize everybody’s contributions. If you are or know a developer on that list, please get in touch with us via bugzilla. e-mail, twitter, google plus or IRC in #gentoo or #gentoo-dev.

Trustee News

Gentoo Foundation 2013 Treasure Summary
In the fiscal year 2013, for the period of July 1st through June 30th we had total assets of $73,494.40. Our main income was $7,000.00 from GSOC, next was donations thru paypal for $6,386.94 and the official Gentoo store generated $558.85 in commissions.

Our expenses totaled $3,396.01 with $2,399.23 to Gentoo GSoC 2012 mentor’s summit travel reimbursement.

Our expenses are kept to a minimium because of all our generous sponsors plus the work of our Infrastructure team to secure donations of hosting, hardware and bandwidth.

Requests for Funds, Project Support, or Equipment
Requests for funds, project support, or equipment need to be sent to the Foundation in the form of a proposal. This proposal is to inform all trustees of the need (not all of them will be aware of the need or the background of the situation). The proposal process will also help to maintain a trusting relationship between the Foundation and its donors. Donors know and expect that without exception money will only be spent after a proposal and vote by the Board of Trustees. Additionally, the proposals will be archived to provide accountability for money spent.

Please review our policy documentation for more information.

News Items

Subject: Ruby 1.8 removal, Ruby 1.9 and Ruby 2.0 activated by default

The Gentoo Ruby team would like to inform you, that the default active ruby targets changed from “ruby19 ruby18″ to “ruby19 ruby20″.

It is about time, because Ruby 1.8 was retired by upstream in July 2013 [1] and has got known security issues (CVE-2013-4164). In Gentoo, we’re going to remove the currently package.masked Ruby MRI 1.8 soon. All packages, depending on ruby, have been converted to support at least Ruby 1.9 or were added to the package.mask at the same time with Ruby 1.8. In case of issues during or after the upgrade, feel free to fill a bug at bugs.gentoo.org

If your currently eselected Ruby interpreter is ruby18, our recommendation is to change it to ruby19. [2] At the moment Ruby MRI 1.9 delivers the best possible support of all Ruby interpreters in tree.

Check the current setting via:
eselect ruby show

Change the current setting to Ruby MRI 1.9 via:
eselect ruby set ruby19

[1] https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/
[2] https://wiki.gentoo.org/wiki/Project:Ruby/Ruby_1.9_migration

Gentoo Developer Stats

Summary

Gentoo is made up of 252 active developers, of which 38 are currently away.
Gentoo has recruited a total of 794 developers since its inception.

Changes

The following developers have recently changed roles:
Jason A. Donenfeld (zx2c4) Joined the systemd project

Additions

The following developers have recently joined the project:
None this month

Moves

The following developers recently left the Gentoo project:
None this month

Portage

This section summarizes the current state of the portage tree.

Architectures 45
Categories 161
Packages 17342
Ebuilds 36489
Architecture Stable Testing Total % of Packages
alpha 3612 510 4122 23.77%
amd64 10703 6142 16845 97.13%
amd64-fbsd 0 1577 1577 9.09%
arm 2631 1636 4267 24.61%
hppa 3034 484 3518 20.29%
ia64 3186 575 3761 21.69%
m68k 576 88 664 3.83%
mips 4 2362 2366 13.64%
ppc 6865 2349 9214 53.13%
ppc64 4334 849 5183 29.89%
s390 1493 290 1783 10.28%
sh 1714 339 2053 11.84%
sparc 4135 877 5012 28.90%
sparc-fbsd 0 323 323 1.86%
x86 11418 5183 16601 95.73%
x86-fbsd 0 3233 3233 18.64%

gmn-portage-stats-2013-11

Security

The following GLSAs have been released by the Security Team

GLSA Package Description Bug
201403-08 dev-perl/PlRPC PlRPC: Arbitrary code execution 497692
201403-07 sys-apps/grep grep: User-assisted execution of arbitrary code 448246
201403-06 net-libs/libupnp libupnp: Arbitrary code execution 454570
201403-05 app-editors/emacs GNU Emacs: Multiple vulnerabilities 398239
201403-04 dev-qt/qtcore QtCore: Denial of Service 494728
201403-03 sys-apps/file file: Denial of Service 501574
201403-02 dev-libs/libyaml LibYAML: Arbitrary code execution 499920
201403-01 www-client/chromium Chromium-V8: Multiple vulnerabilities 486742

Package Removals/Additions

Removals

Package Developer Date
x11-misc/slimlock titanofold 10 Mar 2014
dev-libs/ido ssuominen 15 Mar 2014
dev-ruby/ruby-bdb mrueg 15 Mar 2014
www-servers/mongrel_cluster mrueg 15 Mar 2014
virtual/emacs-cedet ulm 17 Mar 2014
gnustep-libs/cddb voyageur 17 Mar 2014
app-emacs/nxml-mode ulm 17 Mar 2014
app-emacs/erc ulm 17 Mar 2014
app-emacs/cperl-mode ulm 17 Mar 2014
app-emacs/alt-font-menu ulm 17 Mar 2014
app-emacs/u-vm-color ulm 17 Mar 2014
app-emacs/eperiodic ulm 20 Mar 2014
app-emacs/view-process ulm 20 Mar 2014
media-sound/audio-entropyd angelos 22 Mar 2014
app-emacs/http-emacs ulm 23 Mar 2014
app-emacs/mairix ulm 23 Mar 2014

Additions

Package Developer Date
dev-python/pretend radhermit 01 Mar 2014
dev-python/cryptography radhermit 01 Mar 2014
dev-java/boilerpipe ercpe 01 Mar 2014
media-plugins/gst-plugins-vaapi pacho 01 Mar 2014
dev-db/derby ercpe 01 Mar 2014
net-analyzer/masscan robbat2 01 Mar 2014
mate-base/mate-desktop tomwij 02 Mar 2014
mate-extra/mate-dialogs tomwij 02 Mar 2014
mate-extra/mate-polkit tomwij 02 Mar 2014
x11-libs/libmatewnck tomwij 02 Mar 2014
dev-python/ssl-fetch dolsen 02 Mar 2014
dev-java/hamcrest-integration ercpe 02 Mar 2014
sci-libs/Fiona slis 03 Mar 2014
dev-python/ipdbplugin slis 03 Mar 2014
sci-libs/pyshp slis 03 Mar 2014
dev-util/lttng-modules dlan 04 Mar 2014
dev-util/lttng-ust dlan 04 Mar 2014
dev-util/lttng-tools dlan 04 Mar 2014
dev-util/babeltrace dlan 04 Mar 2014
games-misc/papers-please hasufell 04 Mar 2014
dev-haskell/scientific qnikst 04 Mar 2014
dev-haskell/text-stream-decode qnikst 04 Mar 2014
kde-base/kwalletmanager johu 04 Mar 2014
mate-base/mate-panel tomwij 05 Mar 2014
mate-base/mate-settings-daemon tomwij 05 Mar 2014
net-wireless/crackle zerochaos 05 Mar 2014
dev-util/appdata-tools polynomial-c 06 Mar 2014
media-libs/libepoxy mattst88 06 Mar 2014
dev-ruby/magic mrueg 06 Mar 2014
net-wireless/mate-bluetooth tomwij 07 Mar 2014
x11-themes/mate-icon-theme tomwij 07 Mar 2014
x11-wm/mate-window-manager tomwij 07 Mar 2014
dev-ruby/ruby-feedparser mrueg 07 Mar 2014
dev-java/dnsjava ercpe 07 Mar 2014
dev-haskell/abstract-deque-tests gienah 09 Mar 2014
dev-haskell/exceptions gienah 09 Mar 2014
dev-haskell/errorcall-eq-instance gienah 09 Mar 2014
dev-haskell/asn1-encoding gienah 09 Mar 2014
dev-haskell/asn1-parse gienah 09 Mar 2014
dev-haskell/chunked-data gienah 09 Mar 2014
dev-haskell/enclosed-exceptions gienah 09 Mar 2014
dev-haskell/esqueleto gienah 09 Mar 2014
dev-haskell/foldl gienah 09 Mar 2014
dev-haskell/x509 gienah 09 Mar 2014
dev-haskell/x509-store gienah 09 Mar 2014
dev-haskell/x509-system gienah 09 Mar 2014
dev-haskell/x509-validation gienah 09 Mar 2014
mate-base/mate-file-manager tomwij 09 Mar 2014
mate-extra/mate-calc tomwij 09 Mar 2014
mate-extra/mate-character-map tomwij 09 Mar 2014
mate-extra/mate-power-manager tomwij 09 Mar 2014
mate-extra/mate-screensaver tomwij 10 Mar 2014
mate-extra/mate-sensors-applet tomwij 10 Mar 2014
dev-python/ansicolor jlec 10 Mar 2014
dev-libs/liblogging ultrabug 10 Mar 2014
sys-apps/gentoo-functions williamh 10 Mar 2014
mate-extra/mate-system-monitor tomwij 10 Mar 2014
mate-extra/mate-utils tomwij 11 Mar 2014
x11-terms/mate-terminal tomwij 11 Mar 2014
x11-themes/mate-backgrounds tomwij 11 Mar 2014
x11-themes/mate-themes tomwij 11 Mar 2014
media-video/atomicparsley-wez ssuominen 11 Mar 2014
app-arch/mate-file-archiver tomwij 12 Mar 2014
app-editors/mate-text-editor tomwij 12 Mar 2014
app-text/mate-document-viewer tomwij 12 Mar 2014
games-misc/games-envd hasufell 12 Mar 2014
perl-core/Dumpvalue zlogene 12 Mar 2014
dev-python/python-caja tomwij 12 Mar 2014
dev-haskell/fingertree qnikst 12 Mar 2014
dev-haskell/reducers qnikst 12 Mar 2014
dev-haskell/monadrandom qnikst 12 Mar 2014
dev-haskell/either qnikst 12 Mar 2014
media-libs/x265 aballier 12 Mar 2014
dev-haskell/tasty-rerun qnikst 12 Mar 2014
dev-haskell/ekg qnikst 12 Mar 2014
dev-lang/lfe patrick 13 Mar 2014
dev-ml/optcomp aballier 13 Mar 2014
dev-ml/deriving aballier 13 Mar 2014
dev-python/venusian patrick 14 Mar 2014
dev-python/pyramid patrick 14 Mar 2014
kde-misc/about-distro johu 14 Mar 2014
dev-haskell/errors qnikst 14 Mar 2014
perl-core/Math-Complex zlogene 14 Mar 2014
dev-libs/ido ssuominen 15 Mar 2014
dev-python/dugong radhermit 17 Mar 2014
mate-base/mate-applets tomwij 17 Mar 2014
mate-extra/caja-dropbox tomwij 17 Mar 2014
mate-extra/mate-file-manager-image-converter tomwij 17 Mar 2014
mate-extra/mate-file-manager-open-terminal tomwij 17 Mar 2014
mate-extra/mate-file-manager-sendto tomwij 17 Mar 2014
mate-extra/mate-file-manager-share tomwij 17 Mar 2014
dev-util/emilpro zerochaos 18 Mar 2014
kde-misc/kcmsystemd johu 18 Mar 2014
media-gfx/mate-image-viewer tomwij 19 Mar 2014
x11-misc/mate-menu-editor tomwij 19 Mar 2014
net-analyzer/mate-netspeed tomwij 19 Mar 2014
x11-misc/mate-notification-daemon tomwij 19 Mar 2014
x11-themes/mate-icon-theme-faenza tomwij 19 Mar 2014
dev-ruby/rb-readline zerochaos 19 Mar 2014
dev-vcs/hg-fast-export ottxor 21 Mar 2014
sys-apps/audio-entropyd angelos 22 Mar 2014
dev-vcs/git-flow johu 22 Mar 2014
app-emacs/gnuplot-mode ulm 22 Mar 2014
app-admin/mate-system-tools tomwij 22 Mar 2014
mate-extra/mate-media tomwij 22 Mar 2014
mate-base/mate-control-center tomwij 22 Mar 2014
net-misc/portspoof zerochaos 22 Mar 2014
app-leechcraft/lc-ooronee maksbotan 23 Mar 2014
app-leechcraft/lc-cpuload maksbotan 23 Mar 2014
app-leechcraft/lc-certmgr maksbotan 23 Mar 2014
mate-extra/mate-user-share tomwij 23 Mar 2014

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 25 February 2014 and 27 March 2014. Not fixed means bugs that were resolved as NEEDINFO, WONTFIX, CANTFIX, INVALID or UPSTREAM.
gmn-activity-2014-02

Bug Activity Number
New 1820
Closed 1307
Not fixed 177
Duplicates 159
Total 5600
Blocker 4
Critical 19
Major 65

Closed bug ranking

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

Rank Team/Developer Bug Count
1 Python Gentoo Team 76
2 Perl Devs @ Gentoo 63
3 Gentoo KDE team 47
4 Gentoo Security 41
5 Gentoo's Team for Core System packages 41
6 Gentoo's Haskell Language team 35
7 Gentoo Linux Gnome Desktop Team 31
8 GNU Emacs Team 29
9 Default Assignee for Orphaned Packages 28
10 Others 915

gmn-activity-2014-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 Linux bug wranglers 119
2 Gentoo Security 95
3 Gentoo Games 75
4 Gentoo KDE team 57
5 Gentoo Linux Gnome Desktop Team 57
6 Python Gentoo Team 52
7 Gentoo's Team for Core System packages 51
8 Gentoo's Haskell Language team 41
9 GNU Emacs Team 41
10 Others 1231

gmn-activity-2014-02

Tip of the month

Gentoolkit has a little known utility called enalyze.

Enalyze analyzes the deployment information Gentoo keeps of all packages and checks this against the current settings status.

There are 2 sub-modules:
- the “analyze” module produces the reports, and
- the “rebuild” module which allows for rebuilding package.use, package.accept_keywords, and package.unmask files which can be placed in /etc/portage.

The difference between it and equery, is that equery does specific queries, while enalyze does complete reports. So, essentially it can be used as a tune up or repair kit for your gentoo system. It does not do everything for you, it does leave some of the decision making to you. But after reviewing the reports, you may want to edit your make.conf to optimize its settings. An interesting feature is that enalyze supports creation of new package.use, package.accept_keywords or package.unmask files based on the currently installed package information, your current profile and make.conf settings. Through it, enalyze can help you rebuild these files or remove obsolete entries from it.

Please note that it does not use or modify existing /etc/portage/package.* files

eg:

# enalyze analyze -v use

This produces a report of all use flags used by packages on your system as well as how they are used. It shows if a USE flag is enabled or disabled, and shows if the USE flag has a “default” setting (a summary of: a profile enabled USE flag, a global make.defaults USE flag, etc.) For each USE flag, the packages that use it are listed as well when called with the -v module option.

From that information you can edit your make.conf’s USE= and remove any flags that are already defaulted. if there is a flag that has more than a few packages using that setting, you could add it to the USE= instead of relying on having that flag in package.use for those packages.

When finished the above:

# enalyze rebuild use

Will generate a new package.use file (neatly sorted) of only the entries needed to preserve the current state of the packages installed. Once you check over the file, add some custom tweaks (to your satisfaction) you can replace the existing or missing file in /etc/portage.

It also runs completely as any user in the portage group. There is no need to run it with superuser rights. Any files generated are saved in the users home directory.

Tip: It is very useful for changing profiles too. Just run them to adapt to the new profile and the new defaults.

P.S. There is room for the utility to get many more reports and rebuild options. So, submit your requests (and hopefully code).

Send us your favorite Gentoo script or tip at gmn@gentoo.org

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.

Sven Vermeulen a.k.a. swift (homepage, bugs)
Proof of concept for USE enabled policies (March 31, 2014, 16:33 UTC)

tl;dr: Some (-9999) policy ebuilds now have USE support for building in (or leaving out) SELinux policy statements.

One of the “problems” I have been facing since I took on the maintenance of SELinux policies within Gentoo Hardened is the (seeming) inability to make a “least privilege” policy that suits the flexibility that Gentoo offers. As a quick recap: SELinux policies describe the “acceptable behavior” of an application (well, domain to be exact), often known as the “normalized behavior” in the security world. When an application (which runs within a SELinux domain) wants to perform some action which is not part of the policy, then this action is denied.

Some applications can have very broad acceptable behavior. A web server for instance might need to connect to a database, but that is not the case if the web server only serves static information, or dynamic information that doesn’t need a database. To support this, SELinux has booleans through which optional policy statements can be enabled or disabled. So far so good.

Let’s look at a second example: ALSA. When ALSA enabled applications want to access the sound devices, they use IPC resources to “collaborate” around the sound subsystem (semaphores and shared memory to be exact). Semaphores inherit the type of the domain that first created the semaphore (so if mplayer creates it, then the semaphore has the mplayer_t context) whereas shared memory usually gets the tmpfs-related type (mplayer_tmpfs_t). When a second application wants to access the sound device as well, it needs access to the semaphore and shared memory. Assuming this second application is the browser, then mozilla_t needs access to semaphores by mplayer_t. And the same for chromium_t. Or java_t applications that are ALSA-enabled. And alsa_t. And all other applications that are ALSA enabled.

In Gentoo, ALSA support can be made optional through USE="alsa". If a user decides not to use ALSA, then it doesn’t make sense to allow all those domains access to each others’ semaphores and shared memory. And although SELinux booleans can help, this would mean that for each application domain, something like the following policy would need to be, optionally, allowed:

# For the mplayer_t domain:
optional_policy(`
  tunable_policy(`use_alsa',`
    mozilla_rw_semaphores(mplayer_t)
    mozilla_rw_shm(mplayer_t)
    mozilla_tmpfs_rw_files(mplayer_t)
  ')
')

optional_policy(`
  tunable_policy(`use_alsa',`
    chromium_rw_semaphores(mplayer_t)
    chromium_rw_shm(mplayer_t)
    chromium_tmpfs_rw_files(mplayer_t)
  ')
')

And this for all domains that are ALSA-enabled. Every time a new application is added that knows ALSA, the same code needs to be added to all policies. And this only uses a single SELinux boolean (whereas Gentoo supports USE="alsa" on per-package level), although we can create separate booleans for each domain if we want to. Not that that will make it more manageable.

One way of dealing with this would be to use attributes. Say we have a policy like so:

attribute alsadomain;
attribute alsatmpfsfile;

allow alsadomain alsadomain:sem rw_sem_perms;
allow alsadomain alsadomain:shm rw_shm_perms;
allow alsadomain alsatmpfsfile:file rw_file_perms;

By assigning the attribute to the proper domains whenever ALSA support is needed, we can toggle this more easily:

# In alsa.if
interface(`alsa_domain',`
  gen_require(`
    attribute alsadomain;
    attribute alsatmpfsfile;
  ')
  typeattribute $1 alsadomain;
  typeattribute $2 alsatmpfsfile;
')


# In mplayer.te
optional_policy(`
  tunable_policy(`use_alsa',`
    alsa_domain(mplayer_t, mplayer_tmpfs_t)
  ')
')

That would solve the problem of needlessly adding more calls in a policy for every ALSA application. And hey, we can probably live with either a global boolean (use_alsa) or per-domain one (mplayer_use_alsa) and toggle this according to our needs.

Sadly, the above is not possible: one cannot define typeattribute assignments inside a tunable_policy code: attributes are part of the non-conditional part of a SELinux policy. The solution would be to create build-time conditionals (rather than run-time):

ifdef(`use_alsa',`
  optional_policy(`
    alsa_domain(mplayer_t, mplayer_tmpfs_t)
  ')
')

This does mean that use_alsa has to be known when the policy is built. For Gentoo, that’s not that bad, as policies are part of separate packages, like sec-policy/selinux-mplayer. So what I now added was USE-enabled build-time decisions that trigger this code. The selinux-mplayer package has IUSE="alsa" which will enable, if set, the use_alsa build-time conditional.

As a result, we now support a better, fine-grained privilege setting inside the SELinux policy which is triggered through the proper USE flags.

Is this a perfect solution? No, but it is manageable and known to Gentoo users. It isn’t perfect, because it listens to the USE flag setting for the selinux-mplayer package (and of course globally set USE flags) but doesn’t “detect” that the firefox application (for which the policy is meant) is or isn’t built with USE="alsa". So users/administrators will need to keep this in mind when using package-local USE flag definitions.

Also, this will make it a bit more troublesome for myself to manage the SELinux policy for Gentoo (as upstream will not use this setup, and as such patches from upstream might need a few manual corrections before they apply to our tree). However, I gladly take that up if it means my system will have somewhat better confinement.

March 29, 2014
Robin Johnson a.k.a. robbat2 (homepage, bugs)

This is a slightly edited copy of an email I send to the mailing lists for my local hackspace, VHS. I run their mailing lists presently for historical reasons, but we're working on migrating them slowly.


Hi all,

Speaking as your email list administrator here. I've tried to keep the logs below as intact as possible, I've censored only one user's domain as being identifying information explicitly, and then two other recipient addresses.

There have been a lot of reports lately of bounce notices from the list, and users have correctly contacted me, wondering what's going on. The bounce messages are seen primarily by users on Gmail and hosted Google Apps, but the problems do ultimately affect everybody.

67.6% of the vhs-general list uses either gmail or google apps (347 subs of 513). For the vhs-members list it's 68.3% (both of these stats created by checking if the MX record for the user's domain points to Google).

Google deciding that a certain list message is too much like spam, because of two things:

  • because of content
  • because of DMARC policy

Content:

We CAN do something about the content.

Please don't send email that has one or twos, containing a URL and a short line of text. It's really suspicious and spam-like.

Include a better description (two or three lines) with the URL.

This gets an entry in the mailserver logs like:

delivery 47198: failure:
+173.194.79.26_failed_after_I_sent_the_message./Remote_host_said:_550-5.7.1_[66.196.40.251______12]_Our_system_has_detected_that_this_message_is/550-5.7.1_likely_unsolicited_mail._To_reduce_the_amount_of_spam_sent_to_Gmail,/550-5.7.1_this_message_has_been_blocked._Please_visit/550-5.7.1_http://support.google.com/m
+ail/bin/answer.py?hl=en&answer=188131_for/550_5.7.1_more_information._mu18si1139639pab.287_-_gsmtp/

That was triggered by this email earlier in the month:

> Subject: Kano OS for RasPi
> http://kano.me/downloads
> Apparently it's faster than Rasbian

DMARC policy:

TL;DR: If you work on an open-source mailing list app, please implement DMARC support ASAP!

Google and other big mail hosters have been working on an anti-spam measure called DMARC [1].

Unlike many prior attempts, it latches onto the From header as well as the SMTP envelope sender, and this unfortunately interferes with mailing lists [2], [3].

I do applaud the concept behind DMARC, but the rollout seems to be hurting lots of the small guys.

At least person (Eric Sachs) at Google is aware of this [4]. There is no useful workaround that I can enact as a list admin right now, other than asking the one present user to tweak his mailserver if possible.

There is also no completed open source support I can find for DMARC. Per the Google post above, the Mailman project is working on it [5], [6], but it's not yet available as of the last release. Our lists run on ezmlm-idx, and I run some other very large lists using mlmmj (gentoo.org) and sympa; none of them have DMARC support.

The problem is only triggering with a few conditions so far:

  • Recpient is on a mail service that implements DMARC (and DKIM and SPF)
  • Sender is on a domain that has a DMARC policy of reject

Of the 115 unique domains used by subscribers on this list, here are all the DMARC policies:

_dmarc.gmail.com.       600  IN TXT "v=DMARC1\; p=none\; rua=mailto:mailauth-reports@google.com"
_dmarc.USERDOMAIN.ca.   7200 IN TXT "v=DMARC1\; p=reject\; rua=mailto:azrxfkte@ag.dmarcian.com\; ruf=mailto:azrxfkte@fr.dmarcian.com\; adkim=s\; aspf=s"
_dmarc.icloud.com.      3600 IN TXT "v=DMARC1\; p=none\; rua=mailto:dmarc_agg@auth.returnpath.net, mailto:d@rua.agari.com\; ruf=mailto:d@ruf.agari.com, mailto:dmarc_afrf@auth.returnpath.net\;rf=afrf\;pct=100"
_dmarc.mac.com.         3600 IN TXT "v=DMARC1\; p=none\; rua=mailto:d@rua.agari.com\; ruf=mailto:d@ruf.agari.com\;"
_dmarc.me.com.          3600 IN TXT "v=DMARC1\; p=none\; rua=mailto:d@rua.agari.com\; ruf=mailto:d@ruf.agari.com\;"
_dmarc.yahoo.ca.        7200 IN TXT "v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc-yahoo-rua@yahoo-inc.com\;"
_dmarc.yahoo.com.       1800 IN TXT "v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc-yahoo-rua@yahoo-inc.com\;"
_dmarc.yahoo.co.uk.     1800 IN TXT "v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc-yahoo-rua@yahoo-inc.com\;"

Only one of those includes a reject policy, but I suspect it's a matter of time until more of them will include it. I'm going to use USERDOMAIN.ca here as the rest of the example, and that user is indirectly responsible for lots of the rejects we are seeing.

Step 1.

User sends this email.

From: A User <someuser@userdomain.ca>
To: vhs-general@lists.hackspace.ca

Delivered to list server via SMTP (these two addresses form the SMTP envelope)

MAIL FROM:<someuser@userdomain.ca>
RCPT TO:<vhs-general@lists.hackspace.ca>

Step 2.

If the MAIL-FROM envelope address is on the list of list subscribers, your message is accepted.

Step 3.0.

The list adjusts the mail to outgoing, and uses SMTP VERP [7] to get the mail server to send the new message. This means it hands off a single copy of the email, as well as a list of all recipients for the mail. Envelope from address in this case will encode the name of the list and the number of the mail in the archive.

If it was delivering to me (robbat2@orbis-terrarum.net), the outgoing SMTP connection would look roughly like:

MAIL FROM:<vhs-general-return-18094-robbat2=orbis-terrarum.net@lists.hackspace.ca>
RCPT TO:<robbat2@orbis-terrarum.net>

And the mail itself still looks like:

From: A User <someuser@userdomain.ca>
To: vhs-general@lists.hackspace.ca

Step 3.1.

I got this email, and if I open it I see this telling me about the SMTP details:

Return-Path: <vhs-general-return-18094-robbat2=orbis-terrarum.net@lists.hackspace.ca>

I don't implement DMARC on my domain. If my system bounced the email, it would have gone to that address, and the list app would know that message 18094 on list vhs-general bounced to user robbat2@orbis-terrarum.net.

Step 3.2.

Google DOES implement DMARC, so lets run through that.

The key part of DMARC is that it takes the domain from the From header.

_dmarc.USERDOMAIN.ca.   7200 IN TXT "v=DMARC1\; p=reject\; rua=mailto:azrxfkte@ag.dmarcian.com\; ruf=mailto:azrxfkte@fr.dmarcian.com\; adkim=s\; aspf=s"

The relevant parts to us are:

p=reject, aspf=s

The ASPF section applies strict mode, and says the mail with a From header of someuser@USERDOMAIN.ca, must have an exact match of the MAIL FROM transaction of @USERDOMAIN.ca.

It doesn't match, as the list changed the MAIL FROM address. The p=reject says to reject the mail if this happens.

This runs counter to the design principles of mailing lists, so DMARC has a bunch of options, all of which require changing the mail in some way.

Here's the logs from the above failure:

> 2014-03-19 11:19:50.783996500 new msg 98907
> 2014-03-19 11:19:50.783998500 info msg 98907: bytes 8864 from <vhs-general-return-18094-@lists.hackspace.ca-@[]> qp 32511 uid 89
> 2014-03-19 11:19:50.785359500 starting delivery 211352: msg 98907 to remote user1@gappsdomain.com
> 2014-03-19 11:19:50.785385500 status: local 1/10 remote 1/40
> 2014-03-19 11:19:50.785450500 starting delivery 211353: msg 98907 to remote user2@gmail.com
> ...
> 2014-03-19 11:19:58.713558500 delivery 211352: failure:
+74.125.25.27_failed_after_I_sent_the_message./Remote_host_said:_550-5.7.1_Unauthenticated_email_from_USERDOMAIN.ca_is_not_accepted_due_to_domain's/550-5.7.1_DMARC_policy._Please_contact_administrator_of_USERDOMAIN.ca_domain_if/550-5.7.1_this_was_a_legitimate_mail._Please_visit/550-5.7.1__http://support.google.com
+/mail/answer/2451690_to_learn_about_DMARC/550_5.7.1_initiative._ub8si9386628pac.133_-_gsmtp/
> 2014-03-19 11:19:59.053816500 delivery 211353: failure:
+173.194.79.26_failed_after_I_sent_the_message./Remote_host_said:_550-5.7.1_Unauthenticated_email_from_USERDOMAIN.ca_is_not_accepted_due_to_domain's/550-5.7.1_DMARC_policy._Please_contact_administrator_of_USERDOMAIN.ca_domain_if/550-5.7.1_this_was_a_legitimate_mail._Please_visit/550-5.7.1__http://support.google.co
+m/mail/answer/2451690_to_learn_about_DMARC/550_5.7.1_initiative._my2si9389106pab.76_-_gsmtp/

[1] http://dmarc.org/
[2] http://dmarc.org/faq.html#s_3
[3] http://dmarc.org/faq.html#r_2
[4] https://sites.google.com/site/oauthgoog/mlistsdkim
[5] http://www.marshut.com/qskkv/adding-dmarc-support-for-mailman-3.html
[6] https://code.launchpad.net/~jimpop/mailman/dmarc-reject
[7] http://en.wikipedia.org/wiki/Variable_envelope_return_path

March 27, 2014
Sven Vermeulen a.k.a. swift (homepage, bugs)
Online hardened meeting of March (March 27, 2014, 21:44 UTC)

I’m back from the depths of the unknown, so time to pick up my usual write-up of the online Gentoo Hardened meeting.

Toolchain

GCC 4.9 is being worked on, and might be released by end of April (based on the amount of open bugs). You can find the changes online.

Speaking of GCC, pipacs asked if it is possible in the upcoming 4.8.2 ebuilds to disable the SSP protection for development purposes (such as when you’re developing GCC plugins that do similar protection measures like SSP, but you don’t want those to collide with each other). Recent discussion on Gentoo development mailinglist had a consensus that the SSP protection measures (-fstack-protector) can be enabled by default, but of course if people are developing new GCC plugins which might interfere with SSP, disabling it is needed. One can use -fno-stack-protector for this, or build stuff with -D__KERNEL__ (as for kernel builds the default SSP handling is disabled anyway, allowing for kernel-specific implementations).

Other than those, there is no direct method to make SSP generally unavailable.

Blueness is also working on musc-libc on Gentoo, which would give a strong incentive for hardened embedded devices. For desktops, well, don’t hold your breath just yet.

Kernel grSec/PaX

It looks like kernel 3.13 will be Ubuntu’s LTS kernel choice, which also makes it the kernel version that grSecurity will put the long term support for in. And with Linux 3.14 almost out, the grsec patches for it are ready as well. Of the previous LTS kernels, 3.2 will probably finish seeing grsec support somewhere this year.

The C wrapper (called install-xattr) used to preserve xattr information during Portage builds has not been integrated in Portage yet, but the development should be finished.

During the chat session, we also discussed the gold linker and how it might be used by more and more packages (so not only by users that explicitly ask for it). udev version 210 onwards is one example, but some others exist. But other than its existence there’s not much to say right here.

SELinux

The 20140311 release of the reference policy is now in the Portage tree.

Also, prometheanfire caught a vulnerability (CVE-2014-1874) in SELinux which has been fixed in the latest kernels.

System Integrity

I made a few updates to the gentoo hardening guide in XCCDF/OVAL format. Nothing major, and I still need to add in a lot of other best practices (as well as automate the tests through OVAL), but I do intend to update the files (at least the gentoo one and ssh as OpenSSH 6 is now readily available) regularly in the next few weeks.

Profiles

A few minor changes have been made to hardened/uclibc to support multilib, but other than that nothing has been done (nor needed to be done) to our profiles.

That’s it for this months hardened meeting write-up. See you next time!

March 26, 2014
Jan Kundrát a.k.a. jkt (homepage, bugs)
Tagged pointers, and saving memory in Trojita (March 26, 2014, 17:02 UTC)

One of the improvements which were mentioned in the recent announcement of Trojitá, a fast Qt e-mail client, were substantial memory savings and speed improvements. In the rest of this post, I would like to explain what exactly we have done and how it matters. This is going to be a technical post, so if you are not interested in C++ or software engineering, you might want to skip this article.

Planting Trees

At the core of Trojitá's IMAP implementation is the TreeItem, an abstract class whose basic layout will be familiar to anyone who has worked with a custom QAbstractItemModel reimplementation. In short, the purpose of this class is to serve as a node in the tree of items which represent all the data stored on a remote IMAP server.

The structure is tree-shaped because that's what fits both the QAbstractItemModel's and the IMAP way of working. At the top, there's a list of mailboxes. Children of these mailboxes are either other, nested mailboxes, or lists of messages. Below the lists of messages, one can find individual e-mails, and within these e-mails, individual body parts as per the recursive nature of the MIME encapsulation. (This is what enables messages with pictures attached, e-mail forwarding, and similar stuff. MIME is fun.) This tree of items is used by the QAbstractItemModel for keeping track of what is where, and for issuing the QModelIndex instances which are used by the rest of the application for accessing, requesting and manipulating the data.

When a QModelIndex is used and passed to the IMAP Model, what matters most is its internalPointer(), a void * which, within Trojitá, always points to an instance of some TreeItem subclass. Everything else, like the row() and column(), are actually not important; the pointer itself is enough to determine everything about the index in question.

Each TreeItem has to store a couple of interesting properties. Besides the usual Qt-mandated stuff like pointer to the parent item and a list of children, there are also application-specific items which enable the code to, well, actually do useful things like printing e-mail subjects or downloading mail attachments. For a mailbox, this crucial information might be the mailbox name. For a message, the UID of the message along with a pointer to the mailbox is enough to uniquely identify everything which is needed.

Lazy Loading

Enter the lazy loading. Many people confirm that Trojitá is fast, and plenty of them are not afraid to say that it is blazingly fast. This speed is enabled by the fact that Trojitá will only do the smallest amount of work required to bring the data over the network (or from disk, for that matter). If you open a huge mailbox with half a million messages, perhaps the GMail's "All messages" account, or one's LKML archive, Trojitá will not start loading half a million of subjects. Instead, the in-memory TreeItem nodes are created in a special state "no data has been requested yet". Trojitá still creates half a million items in memory, but these items are rather lightweight and only contain the absolute minimum of data they need for proper operation.

Some of these "empty" nodes are, eventually, consulted and used for item display -- perhaps because a view is attached to this model, and the view wants to show the recent mail to the user. In Qt, this usually happens via the data() method of the QAbstractItemModel, but other methods like rowCount() have a very similar effect. Whenever more data are needed, the state of the tree node changes from the initial "no data have been requested" to "loading stuff", and an asynchronous request for these data is dispatched. An important part of the tale is that the request is indeed completely asynchronous, so you won't see any blocking whatsoever in the GUI. The QTreeView will show an animation while a subtree is expanded, the message viewer might display a spinner, and the mail listing shows greyed-out "Loading..." placeholder instead of the usual message subjects.

After a short while, the data arrive and the tree node is updated with the extracted contents -- be it e-mail subject, or perhaps the attached image of dancing pigs. As the requested data are now here, the status of the tree node is updated from the previous "loading stuff" into "done". At the same time, an appropriate signal, like dataChanged or rowsInserted, is emitted. Requesting the same data again via the classic MVC API will not result in network requests, but everything will be accommodated from the local cache.

What we see now is that there is just a handful of item states, yet the typical layout of the TreeItem looks roughly like this:

enum class FetchingStatus {
    INITIAL_NOTHING_REQUESTED_YET,
    LOADING,
    DONE,
    FAILED
};
class TreeItem {
    TreeItem *m_parent;
    QList<TreeItem*> m_children;
    FetchingStatus m_status;
};

On a 64bit system, this translates to at least three 64bit words being used -- one for the painter to the parent item, one (or much more) for storage of the list of children, and one more for storing the enum FetchingStatus. That's a lot of space, given we have just created half a million of these items.

Tagged Pointers

An interesting property of a modern CPU is that the data structures must be aligned properly. A very common rule is that e.g. a 32bit integer can only start at memory offset which is a multiple of four. In hex, this means that an address, or a pointer value, could end with 0x0, or 0x4, or 0x8, or 0xc. The detailed rules are platform-specific and depend on the exact data structure which we are pointing to, but the important message is that at least some of the low bits in the pointer address are always going to be zero. Perhaps we could encode some information in there?

Turns out this is exactly what pointer tagging is about. Instead of having two members, one TreeItem * and one FetchingStatus, these are squashed into a single pointer-sized value. The CPU can no longer use the pointer value directly, all accesses have to go via an inlined function which simply masks away the lowest bits which do bring a very minor performance hit, but the memory conservation is real.

For a real-world example, see this commit in Trojitá.

Using Memory Only When Needed

Back to our example of a mailbox with 500k messages. Surely a user is only going to see a small subset of them at once, right?

That is indeed the case. We still have to at least reserve space for 500k items for technical reasons, but there is certainly no need to reserve space for heavy stuff like subjects and other headers. Indeed, in Trojitá, we track the From/To/Cc/Bcc headers, the subjects, various kinds of timestamps, other envelope items and similar stuff, and this totals a couple hundred bytes per each message. A couple hundred bytes is not much (pun intended), but "a couple hundred bytes" times "half a million" is a ton of memory.

This got implemented here. One particular benchmark which tests how fast Trojitá resynchronizes a mailbox with 100k of messages showed immediate reduction in memory usage from previous 45 MB to 25 MB. The change, again, does come with a cost; one now has to follow one more pointer redirection, and one has to perform one more dynamic allocation for each message which is actually visible. That, however, proves to be negligible during typical usage.

Measure, Don't Guess

As usual with optimizing, the real results might sometimes be surprising. A careful reader and an experienced Qt programmer might have noticed the QList above and shuddered in horror. In fact, Trojitá now uses QVector in its place, but when I was changing the code, using std::vector sounded like a no-brainer. Who needs the copy-on-write semantics here anyway, so why should I pay its price in this context? These data (list of children of an item) are not copied that often, and copying a contiguous list of pointers is pretty cheap anyway (it surely is dwarfed by dynamic allocation overhead). So we should just stick with std::vector, right?

Well, not really. It turned out that plenty of these lists are empty most of the time. If we are looking at the list of messages in our huge mailbox, chances are that most of these messages were not loaded yet, and therefore the list of children, i.e. something which represents their inner MIME structure, is likely empty. This is where the QVector really shines. Instead of using three pointers per vector, like the GCC's std::vector does, QVector is happy with a single pointer pointing to a shared null instance, something which is empty.

Now, factor of three on an item which is used half a million times, this is something which is going to hurt. That's why Trojitá eventually settled on using QVector for the m_children member. The important lesson here is "don't assume, measure".

Wrapping up

Thanks to these optimization (and a couple more, see the git log), one particular test case now runs ten times faster while simultaneously using 38% less memory -- comparing the v0.4 with v0.3.96. Trojitá was pretty fast even before, but now it really flies. The sources of memory diet were described in today's blog post; the explanation on how the time was cut is something which will have to wait for another day.

Sven Vermeulen a.k.a. swift (homepage, bugs)
Fixing the busybox build failure (March 26, 2014, 12:18 UTC)

Since a few months I have a build failure every time I try to generate an initial ram file system (as my current primary workstation uses a separate /usr and LVM for everything except /boot):

* busybox: >> Compiling...
* ERROR: Failed to compile the "all" target...
* 
* -- Grepping log... --
* 
*           - busybox-1.7.4-signal-hack.patch
* busybox: >> Configuring...
*COMMAND: make -j2 CC="gcc" LD="ld" AS="as"  
*  HOSTCC  scripts/basic/fixdep
*make: execvp: /var/tmp/genkernel/18562.2920.28766.17301/busybox-1.20.2/scripts/gen_build_files.sh: Permission denied
*make: *** [gen_build_files] Error 127
*make: *** Waiting for unfinished jobs....
*/bin/sh: scripts/basic/fixdep: Permission denied
*make[1]: *** [scripts/basic/fixdep] Error 1
*make: *** [scripts_basic] Error 2

I know it isn’t SELinux that is causing this, as I have no denial messages and even putting SELinux in permissive mode doesn’t help. Today I found the time to look at it with more fresh eyes, and noticed that it wants to execute a file (gen_build_files.sh) situated in /var/tmp somewhere. That file system however is mounted with noexec (amongst other settings) so executing anything from within that file system is not allowed.

The solution? Update /etc/genkernel.conf and have TMPDIR point to a location where executing is allowed. Of course, this being a SELinux system, the new location will need to be labeled as tmp_t as well, but that’s just a simple thing to do.

~# semanage fcontext -a -t tmp_t /var/build/genkernel(/.*)?
~# restorecon -R /var/build/genkernel

The new location is not world-writable (only for root as only root builds initial ram file systems here) so not having noexec here is ok.

March 24, 2014
Sven Vermeulen a.k.a. swift (homepage, bugs)
Create your own SELinux Gentoo profile (March 24, 2014, 19:51 UTC)

Or any other profile for that matter ;-)

A month or so ago we got the question how to enable SELinux on a Gentoo profile that doesn’t have a <some profilename>/selinux equivalent. Because we don’t create SELinux profiles for all possible profiles out there, having a way to do this yourself is good to know.

Sadly, the most efficient way to deal with this isn’t supported by Portage: creating a parent file pointing to /usr/portage/profiles/features/selinux in /etc/portage/profile, as is done for all SELinux enabled profiles. The /etc/portage/profile location (where users can do local changes to the profile settings) does not support a parent file in there.

Luckily, enabling SELinux is a matter of merging the files in /usr/portage/profiles/features/selinux into /etc/portage/profile. If you don’t have any files in there, you can blindly copy over the files from features/selinux.

Edit: aballier on #gentoo-dev mentioned that you can create a /etc/portage/make.profile directory (instead of having it be a symlink managed by eselect profile) which does support parent files. In that case, just create one with two entries: one path to the profile you want, and one path to the features/selinux location.

Hidden symbols and dynamic linking (March 24, 2014, 19:14 UTC)

A few weeks ago, we introduced an error in the (~arch) libselinux ebuild which caused the following stacktrace to occur every time the semanage command was invoked:

~ # semanage
Traceback (most recent call last):
  File "/usr/lib/python-exec/python2.7/semanage", line 27, in 
    import seobject
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 27, in 
    import sepolicy
  File "/usr/lib64/python2.7/site-packages/sepolicy/__init__.py", line 11, in 
    import sepolgen.interfaces as interfaces
  File "/usr/lib64/python2.7/site-packages/sepolgen/interfaces.py", line 24, in 
    import access
  File "/usr/lib64/python2.7/site-packages/sepolgen/access.py", line 35, in 
    from selinux import audit2why
ImportError: /usr/lib64/python2.7/site-packages/selinux/audit2why.so: undefined symbol: sepol_set_policydb

Usually this error means that a needed library (a .so file) is missing, or is not part of the /etc/ld.so.conf list of directories to scan. And when SELinux is enabled, you might want to check the permissions of that file as well (who knows). But that wasn’t the case here. After trying to figure things out (which includes switching Python versions, grepping for sepol_set_policydb in libsepol.so and more) I looked at the audit2why.c code and see if/where sepol_set_policydb is needed, as well as at the libsepol sources to see where it is defined. And yes, the call is (of course) needed, but the definition made me wonder if this wasn’t a bug:

int hidden sepol_set_policydb(policydb_t * p)
{
        policydb = p;
        return 0;
}

Hidden? But, that means that the function symbol is not available for dynamic linking… So if that is the case, shouldn’t audit2why.c not call it? Turns out, this was due to a fix we introduced earlier on, where libsepol got linked dynamically instead of statically (i.e. using libsepol.a). Static linking of libraries still allows for the (hidden) symbols to be used, whereas dynamic linking doesn’t.

So that part of the fix got reverted (and should fix the bug we introduced), and I learned a bit more about symbols (and the hidden statement).

Bonus: if you need to check what symbols are available in a binary / shared library, use nm:

~$ nm -D /path/to/binary

March 21, 2014
Nathan Zachary a.k.a. nathanzachary (homepage, bugs)

Recently I ran into a problem with RHEL 6 (and any derivatives, like CentOS 6 or Scientific Linux 6) where having two NICs (network interfaces) in the same subnet resulted in strange behaviour. In RHEL ≤5 (or CentOS ≤5), one could have two interfaces with IPs in the same subnet and there weren’t any problems (besides the obvious question of why one would set it up this way instead of just bonding the interfaces). However, in RHEL 6 (or CentOS 6), having two interfaces with IPs in the same subnet results in the primary one pinging but the secondary one not responding.

The cause of this problem is that the rp_filter settings changed between these kernels (2.6.18 in RHEL 5 and 2.6.32 in RHEL 6). In RHEL 5, the rp_filter setting was a boolean where 1 meant that source validation was done by reversed path (as in RFC1812), and 0 meant no source validation. However, in RHEL 6, this setting changed to an integer with the following settings:

*****
0 – No source validation

1 – Strict Reverse Path validation (RFC3704) – Packets are checked against the FIB (Forwarding Information Base), and only the best ones succeed

2 – Loose Reverse Path validation (RFC3704) – Packets are checked against the FIB, but only non-reachable BY ANY INTERFACE will fail
*****

So, though the default setting is still 1, it now has a different meaning. In order to get these two network interfaces with IPs in the same subnet to both respond, I needed to make two changes in /etc/sysctl.conf:

  • Change net.ipv4.conf.default.rp_filter from ’1′ to ’2′
  • Add the line net.ipv4.conf.all.rp_filter = 2

To better illustrate the changes, here are the differences:

DEFAULT SETTINGS:
# grep '.rp_filter' /etc/sysctl.conf
net.ipv4.conf.default.rp_filter = 1

REQUIRED SETTINGS:
# grep '.rp_filter' /etc/sysctl.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2

In order to make these changes effective immediately, you can reload the configuration with:

# sysctl -p

Ultimately, the new defaults make it so that the kernel discards packets when the route for outbound traffic differs from the route of incoming traffic. Changing these settings as mentioned above will make the kernel handle those packets like it did before 2.6.32. That way, having two or more interfaces with IPs in the same subnet will function as intended. Also, these changes aren’t limited to just RHEL 6 and derivatives, but also to any distribution with ≥kernel-2.6.32 in which the defaults were not changed.

Cheers,
Zach

March 20, 2014
Jan Kundrát a.k.a. jkt (homepage, bugs)

Summary

An SSL stripping vulnerability was discovered in Trojitá, a fast Qt IMAP e-mail client. User's credentials are never leaked, but if a user tries to send an e-mail, the automatic saving into the "sent" or "draft" folders could happen over a plaintext connection even if the user's preferences specify STARTTLS as a requirement.

Background

The IMAP protocol defines the STARTTLS command which is used to transparently upgrade a plaintext connection to an encrypted one using SSL/TLS. The STARTTLS command can only be issued in an unauthenticated state as per the IMAP's state machine.

RFC 3501 also allows for a possibility of the connection jumping immediately into an authenticated state via the PREAUTH initial response. However, as the STARTTLS command cannot be issued once in the authenticated state, an attacker able to intercept and modify the network communication might trick the client into a state where the connection cannot be encrypted anymore.

Affected versions

All versions of Trojitá up to 0.4 are vulnerable. The fix is included in version 0.4.1.

Remedies

Connections which use the SSL/TLS form the very beginning (e.g. the connections using port 993) are secure and not vulnerable.

Possible impact

The user's credentials will never be transmitted over a plaintext connection even in presence of this attack.

Because Trojitá proceeded to use the connection without STARTTLS in face of PREAUTH, certain data might be leaked to the attacker. The only example which we were able to identify is the full content of a message which the user attempts to save to their "Sent" folder while trying to send a mail.

We don't believe that any other data could be leaked. Again, user's credentials will not be leaked.

Acknowledgement

Thanks to Arnt Gulbrandsen on the imap-protocol ML for asking what happens when we're configured to request STARTTLS and a PREAUTH is received, and to Michael M Slusarz for starting that discussion.

March 18, 2014
Donnie Berkholz a.k.a. dberkholz (homepage, bugs)

Students, this Friday at 1900 UTC is the deadline to apply for this year’s GSoC. It’s an awesome program that pays you to work on open-source projects for a summer (where you == a university/college student).

It’s by no means too late, but start your application today. You can find more information on Gentoo’s projects here (click on the Ideas page to get started; also see our application guidelines) and on the broader GSoC program here.

Good luck!


Tagged: community, development, gentoo, gsoc

March 07, 2014
Alexys Jacob a.k.a. ultrabug (homepage, bugs)
Couchbase on Gentoo Linux (March 07, 2014, 16:29 UTC)

Back in 2010 when I was comparing different NoSQL solutions I came across CouchDB. Even tho I went for mongoDB in the end, it was still a nice and promising technology even more since the merge with the Membase guys in late 2012 which lead to the actual Couchbase.

I won’t go into the details of Couchbase itself since it’s way covered all around the net but I wanted to let you guys know that I’ve packaged most of the couchbase ecosystem for Gentoo Linux :

  • dev-db/couchbase-server-community-2.2.0 : the community server edition (bin)
  • dev-libs/libcouchbase-2.2.0 : the C client library
  • dev-python/couchbase-1.2.0 : the python client library

Those packages are still only available on my overlay (ultrabug on layman) since I’m not sure about the interest of other users in the community and I still need to make sure it’s production ready enough.

If you’re interested in seeing this package in portage, please say so !

I dedicate this packaging to @atorgfr :)

March 05, 2014
Michał Górny a.k.a. mgorny (homepage, bugs)

In a previous article titled ‘using deltas to speed up SquashFS ebuild repository updates’, the author has considered benefits of using binary deltas to update SquashFS images. The proposed method has proven very efficient in terms of disk I/O, memory and CPU time use. However, the relatively large size of deltas made network bandwidth a bottleneck.

The rough estimations done at the time proved that this is not a major issue for a common client with a moderate-bandwidth link such as ADSL. Nevertheless, the size is an inconvenience both to clients and to mirror providers. Assuming that there is an upper bound on disk space consumed by snapshots, the extra size reduces the number of snapshots stored on mirrors, and therefore shortens the supported update period.

The most likely cause for the excessive delta size is the complexity of correlation between input and compressed output. Changes in input files are likely to cause much larger changes in the SquashFS output that the tested delta algorithms fail to express efficiently.

For example, in the LZ family of compression algorithms, a change in input stream may affect the contents of the dictionary and therefore the output stream following it. In block-based compressors such as bzip2, a change in input may shift all the following data moving it across block boundaries. As a result, the contents of all the blocks following it change, and therefore the compressed output for each of them.

Since SquashFS splits the input into multiple blocks that are compressed separately, the scope of this issue is much smaller than in plain tarballs. Nevertheless, small changes occurring in multiple blocks are able to grow delta two to four times as large as it would be if the data was not compressed. In this paper, the author explores the possibility of introducing a transparent decompression in the delta generation process to reduce the delta size.

Read on… [PDF]

Jan Kundrát a.k.a. jkt (homepage, bugs)
Trojita 0.4 "Ukraine" is released (March 05, 2014, 14:22 UTC)

Hi all,
we are pleased to announce version 0.4 of Trojitá, a fast Qt IMAP e-mail client. For this release, a lot of changes were made under the hood, but of course there are some changes that are visible to the user as well.

Improvements:

  • Users are able to use multiple sessions, which means that it is possible to use Trojitá with multiple IMAP accounts at the same time. It can be used by invoking Trojitá with the --profile something switch. For each profile, a new instance of the application is started. Please note that this is not our final solution for the multi-accounts problem; work on this is ongoing. For details, refer to the detailed instructions.
  • In the Composer Window, users can now control whether the current message is a reply to some other message. Hopefully, this will make it easier to reply to a ton of people while starting a new thread, not lumping the unrelated conversations together.
  • Trojitá will now detect changes to the network connection state. So for example, when a user switches from a wireless connection to a wired one, Trojitá will detect that and try to reconnect automatically.
  • Trojitá gained a setting to automatically use the system proxy settings.
  • SOCKS5 and HTTP proxies are supported.
  • Memory usage has been reduced and speed has been improved. Our benchmarks indicate being ten times faster when syncing huge mailboxes, and using 38% less memory at the same time.
  • The Compose Window supports editing the "From" field with hand-picked addresses as per common user requests.

This release has been tagged in git as "v0.4". You can also download a tarball (GPG signature). Prebuilt binaries for multiple distributions are available via the OBS .

This release is dedicated to the people of all nations living in Ukraine. We are no fans of political messages in software announcements, but we also cannot remain silent when unmarked Russian troops are marching over a free country. The Trojitá project was founded in a republic formerly known as Czechoslovakia. We were "protected" by foreign aggressors twice in the 20th century — first in 1938 by the Nazi Germany, and second time in 1968 by the occupation forces of the USSR. Back in 1938, Adolf Hitler used the same rhetorics we hear today: that a national minority was oppressed. In 1968, eight people who protested against the occupation in Moscow were detained within a couple of minutes, convicted and sent to jail. In 2014, Moscowians are protesting on a bigger scale, yet we all see the cops arresting them on Youtube — including those displaying blank signs.

This is not about politics, this is about morality. What is happening today in Ukraine is a barbaric act, an occupation of an innocent country which has done nothing but stopped being attracted to their more prominent eastern neighbor. No matter what one thinks about the international politics and the Crimean independence, this is an act which must be condemned and fiercely fought against. There isn't much what we could do, so we hope that at least this symbolic act will let the Ukrainians know that the world's thoughts are with them in this dire moment. За вашу и нашу свободу, indeed!

Finally, we would like to thank Jai Luthra, Danny Rim, Benjamin Kaiser and Yazeed Zoabi, our Google Code-In students, and Stephan Platz, Karan Luthra, Tomasz Kalkosiński and Luigi Toscano, people who recently joined Trojitá, for their code contributions.

The Trojitá developers

  • Jan Kundrát
  • Yuri Chornoivan
  • Karan Luthra
  • Pali Rohár
  • Tomasz Kalkosiński
  • Christian Degenkolb
  • Jai Luthra
  • Stephan Platz
  • Thomas Lübking

March 03, 2014
Gentoo Monthly Newsletter - February 2014 (March 03, 2014, 19:02 UTC)

The February 2014 GMN issue is now available online.

This month on GMN:

  • Interview with Gentoo developer Sven Vermeulen (swift)
  • Latest Gentoo news, job openings, interesting stats and much more.