22 Jul 2014

feedPlanet Gentoo

Diego E. Pettenò: LibreSSL: drop-in and ABI leakage

There has been some confusion on my previous post with Bob Beck of LibreSSL on whether I would advocate for using a LibreSSL shared object as a drop-in replacement for an OpenSSL shared object. Let me state this here, boldly: you should never, ever, for no reason, use shared objects from different major/minor OpenSSL versions or implementations (such as LibreSSL) as a drop-in replacement for one another.

The reason is, obviously, that the ABI of these libraries differs, sometimes subtly enought that they may actually load and run, but then perform abysmally insecure operations, as its data structures will have changed, and now instead of reading your random-generated key, you may be reading the master private key. nd in general, for other libraries you may even be calling the wrong set of functions, especially for those written in C++, where the vtable content may be rearranged across versions.

What I was discussing in the previous post was the fact that lots of proprietary software packages, by bundling a version of Curl that depends on the RAND_egd() function, will require either unbundling it, or keeping along a copy of OpenSSL to use for runtime linking. And I think that is a problem that people need to consider now rather than later for a very simple reason.

Even if LibreSSL (or any other reimplementation, for what matters) takes foot as the default implementation for all Linux (and not-Linux) distributions, you'll never be able to fully forget of OpenSSL: not only if you have proprietary software that you maintain, but also because a huge amount of software (and especially hardware) out there will not be able to update easily. And the fact that LibreSSL is throwing away so much of the OpenSSL clutter also means that it'll be more difficult to backport fixes - while at the same time I think that a good chunk of the black hattery will focus on OpenSSL, especially if it feels "abandoned", while most of the users will still be using it somehow.

But putting aside the problem of the direct drop-in incompatibilities, there is one more problem that people need to understand, especially Gentoo users, and most other systems that do not completely rebuild their package set when replacing a library like this. The problem is what I would call "ABI leakage".

Let's say you have a general libfoo that uses libssl; it uses a subset of the API that works with both OpenSSL. Now you have a bar program that uses libfoo. If the library is written properly, then it'll treat all the data structures coming from libssl as opaque, providing no way for bar to call into libssl without depending on the SSL API du jour (and thus putting a direct dependency on libssl for the executable). But it's very well possible that libfoo is not well-written and actually treats the libssl API as transparent. For instance a common mistake is to use one of the SSL data structures inline (rather than as a pointer) in one of its own public structures.

This situation would be barely fine, as long as the data types for libfoo are also completely opaque, as then it's only the code for libfoo that relies on the structures, and since you're rebuilding it anyway (as libssl is not ABI-compatible), you solve your problem. But if we keep assuming a worst-case scenario, then you have bar actually dealing with the data structures, for instance by allocating a sized buffer itself, rather than calling into a proper allocation function from libfoo. And there you have a problem.

Because now the ABI of libfoo is not directly defined by its own code, but also by whichever ABI libssl has! It's a similar problem as the symbol table used as an ABI proxy: while your software will load and run (for a while), you're really using a different ABI, as libfoo almost certainly does not change its soname when it's rebuilt against a newer version of libssl. And that can easily cause crashes and worse (see the note above about dropping in LibreSSL as a replacement for OpenSSL).

Now honestly none of this is specific to LibreSSL. The same is true if you were to try using OpenSSL 1.0 shared objects for software built against OpenSSL 0.9 - which is why I cringed any time I heard people suggesting to use symlink at the time, and it seems like people are giving the same suicidal suggestion now with OpenSSL, according to Bob.

So once again, don't expect binary-compatibility across different versions of OpenSSL, LibreSSL, or any other implementation of the same API, unless they explicitly aim for that (and LibreSSL definitely doesn't!)

22 Jul 2014 11:09pm GMT

20 Jul 2014

feedPlanet Gentoo

Diego E. Pettenò: LibreSSL and the bundled libs hurdle

It was over five years ago that I ranted about the bundling of libraries and what that means for vulnerabilities found in those libraries. The world has, since, not really listened. RubyGems still keep insisting that "vendoring" gems is good, Go explicitly didn't implement a concept of shared libraries, and let's not even talk about Docker or OSv and their absolutism in static linking and bundling of the whole operating system, essentially.

It should have been obvious how this can be a problem when Heartbleed came out, bundled copies of OpenSSL would have needed separate updates from the system libraries. I guess lots of enterprise users of such software were saved only by the fact that most of the bundlers ended up using older versions of OpenSSL where heartbeat was not implemented at all.

Now that we're talking about replacing the OpenSSL libraries with those coming from a different project, we're going to be hit by both edges of the proprietary software sword: bundling and ABI compatibility, which will make things really interesting for everybody.

If you've seen my (short, incomplete) list of RAND_egd() users which I posted yesterday. While the tinderbox from which I took this is out of date and needs cleaning, it is a good starting point to figure out the trends, and as somebody already picked up, the bundling is actually strong.

Software that bundled Curl, or even Python, but then relied on the system copy of OpenSSL, will now be looking for RAND_egd() and thus fail. You could be unbundling these libraries, and then use a proper, patched copy of Curl from the system, where the usage of RAND_egd() has been removed, but then again, this is what I've been advocating forever or so. With caveats, in the case of Curl.

But now if the use of RAND_egd() is actually coming from the proprietary bits themselves, you're stuck and you can't use the new library: you either need to keep around an old copy of OpenSSL (which may be buggy and expose even more vulnerability) or you need a shim library that only provides ABI compatibility against the new LibreSSL-provided library - I'm still not sure why this particular trick is not employed more often, when the changes to a library are only at the interface level but still implements the same functionality.

Now the good news is that from the list that I produced, at least the egd functions never seemed to be popular among proprietary developers. This is expected as egd was vastly a way to implement the /dev/random semantics for non-Linux systems, while the proprietary software that we deal with, at least in the Linux world, can just accept the existence of the devices themselves. So the only problems have to do with unbundling (or replacing) Curl and possibly the Python SSL module. Doing so is not obvious though, as I see from the list that there are at least two copies of libcurl.so.3 which is the older ABI for Curl - although admittedly one is from the scratchbox SDKs which could just as easily be replaced with something less hacky.

Anyway, my current task is to clean up the tinderbox so that it's in a working state, after which I plan to do a full build of all the reverse dependencies on OpenSSL, it's very possible that there are more entries that should be in the list, since it was built with USE=gnutls globally to test for GnuTLS 3.0 when it came out.

20 Jul 2014 9:55am GMT

19 Jul 2014

feedPlanet Gentoo

Paweł Hajdan, Jr.: Recovering from removed libgcc_s.so.1 (and missing busybox)

I was experimenting in my arm chroot, and after a gcc upgrade and emerge --depclean --ask that removed the old gcc I got the following error:

# ls -l
ls: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory

Fortunately the newer working gcc was present, so the steps to make things work again were:

# LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.2/" gcc-config -l
* gcc-config: Active gcc profile is invalid!

[1] armv7a-hardfloat-linux-gnueabi-4.8.2

# LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.2/" gcc-config 1
* Switching native-compiler to armv7a-hardfloat-linux-gnueabi-4.8.2 ...

Actually my first thought was using busybox. The unexpected breakage during a routine gcc upgrade made me do some research in case I can't rely on /bin/busybox being present and working.

I highly recommend the following links for further reading:
http://lambdaops.com/rm-rf-remains
http://eusebeia.dyndns.org/bashcp
http://www.reddit.com/r/linux/comments/27is0x/rm_rf_remains/ci199bk

Read more »

19 Jul 2014 5:19pm GMT

Diego E. Pettenò: LibreSSL is taking a beating, and that's good

When I read about LibreSSL coming from the OpenBSD developers, my first impression was that it was a stunt. I did not change my impression of it drastically still. While I know at least one quite good OpenBSD developer, my impression of the whole set is still the same: we have different concepts of security, and their idea of "cruft" is completely out there for me. But this is a topic for some other time.

So seeing the amount of scrutiny from other who are, like me, skeptical of the OpenBSD people left on their own is a good news. It keeps them honest, as they say. But it also means that things that wouldn't be otherwise understood by people not used to Linux don't get shoved under the rug.

This is not idle musings: I still remember (but can't find now) an article in which Theo boasted not ever having used Linux. And yet kept insisting that his operating system was clearly superior. I was honestly afraid that the way the fork-not-a-fork project was going to be handled was the same, I'm positively happy to be proven wrong up to now.

I actually have been thrilled to see that finally there is movement to replace the straight access to /dev/random and /dev/urandom: Ted's patch to implement a getrandom() system call that can be made compatible with OpenBSD's own getentropy() in user space. And even more I'm happy to see that at least one of the OpenBSD/LibreSSL developers pitching in to help shape the interface.

Dropping out the egd support made me puzzled for a moment, but then I realized that there is no point in using egd to feed the randomness to the process, you just need to feed entropy to the kernel, and let the process get it normally. I have had, unfortunately, quite a bit of experience with entropy-generating daemons, and I wonder if this might be the right time to suggest getting a new multi-source daemon out.

So a I going to just blindly trust the OpenBSD people because "they have a good track record"? No. And to anybody that suggest that you can take over lines and lines of code from someone else's crypto-related project, remove a bunch of code that you think is useless, and have an immediate result, my request is to please stop working with software altogether.

Security Holes Copyright © Randall Munroe.

I'm not saying that they would do it on purpose, or that they wouldn't be trying to do the darndest to make LibreSSL a good replacement for OpenSSL. What I'm saying is that I don't like the way, and the motives, the project was started from. And I think that a reality check, like the one they already got, was due and a good news.

On my side, once the library gets a bit more mileage I'll be happy to run the tinderbox against it. For now, I'm re-gaining access to Excelsior after a bad kernel update, and I'll just go and search with elfgrep for which binaries do use the egd functionalities and need to be patched, I'll post it on Twitter/G+ once I have it. I know it's not much, but this is what I can do.

19 Jul 2014 4:23pm GMT

14 Jul 2014

feedPlanet Gentoo

Richard Freeman: Quick systemd-nspawn guide

I switched to using systemd-nspawn in place of chroot and wanted to give a quick guide to using it. The short version is that I'd strongly recommend that anybody running systemd that uses chroot switch over - there really are no downsides as long as your kernel is properly configured.

Chroot should be no stranger to anybody who works on distros, and I suspect that the majority of Gentoo users have need for it from time to time.

The Challenges of chroot

For most interactive uses it isn't sufficient to just run chroot. Usually you need to mount /proc, /sys, and bind mount /dev so that you don't have issues like missing ptys, etc. If you use tmpfs you might also want to mount the new tmp, var/tmp as tmpfs. Then you might want to make other bind mounts into the chroot. None of this is particularly difficult, but you usually end up writing a small script to manage it.

Now, I routinely do full backups, and usually that involves excluding stuff like tmp dirs, and anything resembling a bind mount. When I set up a new chroot that means updating my backup config, which I usually forget to do since most of the time the chroot mounts aren't running anyway. Then when I do leave it mounted overnight I end up with backups consuming lots of extra space (bind mounts of large trees).

Finally, systemd now by default handles bind mounts a little differently when they contain other mount points (such as when using -rbind). Apparently unmounting something in the bind mount will cause systemd to unmount the corresponding directory on the other side of the bind. Imagine my surprise when I unmounted my chroot bind to /dev and discovered /dev/pts and /dev/shm no longer mounted on the host. It looks like there are ways to change that, but this isn't the point of my post (it just spurred me to find another way).

Systemd-nspawn's Advantages

Systemd-nspawn is a tool that launches a container, and it can operate just like chroot in its simplest form. By default it automatically sets up most of the overhead like /dev, /tmp, etc. With a few options it can also set up other bind mounts as well. When the container exits all the mounts are cleaned up.

From the outside of the container nothing appears different when the container is running. In fact, you could spawn 5 different systemd-nspawn container instances from the same chroot and they wouldn't have any interaction except via the filesystem (and that excludes /dev, /tmp, and so on - only changes in /usr, /etc will propagate across). Your backup won't see the bind mounts, or tmpfs, or anything else mounted within the container.

The container also has all those other nifty container benefits like containment - a killall inside the container won't touch anything outside, and so on. The security isn't airtight - the intent is to prevent accidental mistakes.

Then, if you use a compatible sysvinit (which includes systemd, and I think recent versions of openrc), you can actually boot the container, which drops you to a getty inside. That means you can use fstab to do additional mounts inside the container, run daemons, and so on. You get almost all the benefits of virtualization for the cost of a chroot (no need to build a kernel, and so on). It is a bit odd to be running systemctl poweroff inside what looks just like a chroot, but it works.

Note that unless you do a bit more setup you will share the same network interface with the host, so no running sshd on the container if you have it on the host, etc. I won't get into this but it shouldn't be hard to run a separate network namespace and bind the interfaces so that the new instance can run dhcp.

How to do it

So, getting it actually working will likely be the shortest bit in this post.

You need support for namespaces and multiple devpts instances in your kernel:

CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

From there launching a namespace just like a chroot is really simple:

systemd-nspawn -D .

That's it - you can exit from it just like a chroot. From inside you can run mount and see that it has taken care of /dev and /tmp for you. The "." is the path to the chroot, which I assume is the current directory. With nothing further it runs bash inside.

If you want to add some bind mounts it is easy:

systemd-nspawn -D . -bind /usr/portage

Now your /usr/portage is bound to your host, so no need to sync/etc. If you want to bind to a different destination add a ":dest" after the source, relative to the root of the chroot (so -bind foo is the same as -bind foo:foo).

If the container has a functional init that can handle being run inside, you can add a -b to boot it:

systemd-nspawn -D . -bind /usr/portage -b

Watch the init do its job. Shut down the container to exit.

Now, if that container is running systemd you can direct its journal to the host journal with -h:

systemd-nspawn -D . -bind /usr/portage -j -b

Now, nspawn registers the container so that it shows up in machinectl. That makes it easy to launch a new getty on it, or ssh to it (if it is running ssh - see my note above about network namespaces), or power it off from the host.

That's it. If you're running systemd I'd suggest ditching chroot almost entirely in favor of nspawn.


Filed under: foss, gentoo, linux

14 Jul 2014 8:31pm GMT

Patrick Lauer: Biggest ebuilds in-tree

Random datapoint: There's only about 10 packages with ebuilds over 600 lines.

Sorted by lines, duplicate entries per-package removed, these are the biggest ones:

828 dev-lang/ghc/ghc-7.6.3-r1.ebuild
817 dev-lang/php/php-5.3.28-r3.ebuild
750 net-nds/openldap/openldap-2.4.38-r2.ebuild
664 www-client/chromium/chromium-36.0.1985.67.ebuild
654 www-servers/nginx/nginx-1.4.7.ebuild
658 games-rpg/nwn-data/nwn-data-1.29-r5.ebuild
654 media-video/mplayer/mplayer-1.1.1-r1.ebuild
644 dev-vcs/git/git-9999-r3.ebuild
621 x11-drivers/ati-drivers/ati-drivers-13.4.ebuild
617 sys-freebsd/freebsd-lib/freebsd-lib-9.1-r11.ebuild

14 Jul 2014 6:39am GMT

12 Jul 2014

feedPlanet Gentoo

Hanno Böck: LibreSSL on Gentoo

LibreSSL PuffyYesterday the LibreSSL project released the first portable version that works on Linux. LibreSSL is a fork of OpenSSL and was created by the OpenBSD team in the aftermath of the Heartbleed bug.

Yesterday and today I played around with it on Gentoo Linux. I was able to replace my system's OpenSSL completely with LibreSSL and with few exceptions was able to successfully rebuild all packages using OpenSSL.

After getting this running on my own system I installed it on a test server. The Webpage tlsfun.de runs on that server. The functionality changes are limited, the only thing visible from the outside is the support for the experimental, not yet standardized ChaCha20-Poly1305 cipher suites, which is a nice thing.

A warning ahead: This is experimental, in no way stable or supported and if you try any of this you do it at your own risk. Please report any bugs you have with my overlay to me or leave a comment and don't disturb anyone else (from Gentoo or LibreSSL) with it. If you want to try it, you can get a portage overlay in a subversion repository. You can check it out with this command:
svn co https://svn.hboeck.de/libressl-overlay/
git clone https://github.com/gentoo/libressl.git

This is what I had to do to get things running:

LibreSSL itself

First of all the Gentoo tree contains a lot of packages that directly depend on openssl, so I couldn't just replace that. The correct solution to handle such issues would be to create a virtual package and change all packages depending directly on openssl to depend on the virtual. This is already discussed in the appropriate Gentoo bug, but this would mean patching hundreds of packages so I skipped it and worked around it by leaving a fake openssl package in place that itself depends on libressl.

LibreSSL deprecates some APIs from OpenSSL. The first thing that stopped me was that various programs use the functions RAND_egd() and RAND_egd_bytes(). I didn't know until yesterday what egd is. It stands for Entropy Gathering Daemon and is a tool written in perl meant to replace the functionality of /dev/(u)random on non-Linux-systems. The LibreSSL-developers consider it insecure and after having read what it is I have to agree. However, the removal of those functions causes many packages not to build, upon them wget, python and ruby. My workaround was to add two dummy functions that just return -1, which is the error code if the Entropy Gathering Daemon is not available. So the API still behaves like expected. I also posted the patch upstream, but the LibreSSL devs don't like it. So on the long term it's probably better to fix applications to stop trying to use egd, but for now these dummy functions make it easier for me to build my system.

The second issue popping up was that the libcrypto.so from libressl contains an undefined main() function symbol which causes linking problems with a couple of applications (subversion, xorg-server, hexchat). According to upstream this undefined symbol is intended and most likely these are bugs in the applications having linking problems. However, for now it was easier for me to patch the symbol out instead of fixing all the apps. Like the egd issue on the long term fixing the applications is better.

The third issue was that LibreSSL doesn't ship pkg-config (.pc) files, some apps use them to get the correct compilation flags. I grabbed the ones from openssl and adjusted them accordingly.

OpenSSH

This was the most interesting issue from all of them.

To understand this you have to understand how both LibreSSL and OpenSSH are developed. They are both from OpenBSD and they use some functions that are only available there. To allow them to be built on other systems they release portable versions which ship the missing OpenBSD-only-functions. One of them is arc4random().

Both LibreSSL and OpenSSH ship their compatibility version of arc4random(). The one from OpenSSH calls RAND_bytes(), which is a function from OpenSSL. The RAND_bytes() function from LibreSSL however calls arc4random(). Due to the linking order OpenSSH uses its own arc4random(). So what we have here is a nice recursion. arc4random() and RAND_bytes() try to call each other. The result is a segfault.

I fixed it by using the LibreSSL arc4random.c file for OpenSSH. I had to copy another function called arc4random_stir() from OpenSSH's arc4random.c and the header file thread_private.h. Surprisingly, this seems to work flawlessly.

Net-SSLeay

This package contains the perl bindings for openssl. The problem is a check for the openssl version string that expected the name OpenSSL and a version number with three numbers and a letter (like 1.0.1h). LibreSSL prints the version 2.0. I just hardcoded the OpenSSL version numer, which is not a real fix, but it works for now.

SpamAssassin

SpamAssassin's code for spamc requires SSLv2 functions to be available. SSLv2 is heavily insecure and should not be used at all and therefore the LibreSSL devs have removed all SSLv2 function calls. Luckily, Debian had a patch to remove SSLv2 that I could use.

libesmtp / gwenhywfar

Some DES-related functions (DES is the old Data Encryption Standard) in OpenSSL are available in two forms: With uppercase DES_ and with lowercase des_. I can only guess that the des_ variants are for backwards compatibliity with some very old versions of OpenSSL. According to the docs the DES_ variants should be used. LibreSSL has removed the des_ variants.

For gwenhywfar I wrote a small patch and sent it upstream. For libesmtp all the code was in ntlm. After reading that ntlm is an ancient, proprietary Microsoft authentication protocol I decided that I don't need that anyway so I just added --disable-ntlm to the ebuild.

Dovecot

In Dovecot two issues popped up. LibreSSL removed the SSL Compression functionality (which is good, because since the CRIME attack we know it's not secure). Dovecot's configure script checks for it, but the check doesn't work. It checks for a function that LibreSSL keeps as a stub. For now I just disabled the check in the configure script. The solution is probably to remove all remaining stub functions. The configure script could probably also be changed to work in any case.

The second issue was that the Dovecot code has some #ifdef clauses that check the openssl version number for the ECDH auto functionality that has been added in OpenSSL 1.0.2 beta versions. As the LibreSSL version number 2.0 is higher than 1.0.2 it thinks it is newer and tries to enable it, but the code is not present in LibreSSL. I changed the #ifdefs to check for the actual functionality by checking a constant defined by the ECDH auto code.

Apache httpd

The Apache http compilation complained about a missing ENGINE_CTRL_CHIL_SET_FORKCHECK. I have no idea what it does, but I found a patch to fix the issue, so I didn't investigate it further.

Further reading:
Someone else tried to get things running on Sabotage Linux.

Update: I've abandoned my own libressl overlay, a LibreSSL overlay by various Gentoo developers is now maintained at GitHub.

12 Jul 2014 6:31pm GMT

09 Jul 2014

feedPlanet Gentoo

Sven Vermeulen: Segmentation fault when emerging packages after libpcre upgrade?

SELinux users might be facing failures when emerge is merging a package to the file system, with an error that looks like so:

>>> Setting SELinux security labels
/usr/lib64/portage/bin/misc-functions.sh: line 1112: 23719 Segmentation fault      /usr/sbin/setfiles "${file_contexts_path}" -r "${D}" "${D}"
 * ERROR: dev-libs/libpcre-8.35::gentoo failed:
 *   Failed to set SELinux security labels.

This has been reported as bug 516608 and, after some investigation, the cause is found. First the quick workaround:

~# cd /etc/selinux/strict/contexts/files
~# rm *.bin

And do the same for the other SELinux policy stores on the system (targeted, mcs, mls, …).

Now, what is happening… Inside the mentioned directory, binary files exist such as file_contexts.bin. These files contain the compiled regular expressions of the non-binary files (like file_contexts). By using the precompiled versions, regular expression matching by the SELinux utilities is a lot faster. Not that it is massively slow otherwise, but it is a nice speed improvement nonetheless.

However, when pcre updates occur, then the basic structures that pcre uses internally might change. For instance, a number might switch from a signed integer to an unsigned integer. As pcre is meant to be used within the same application run, most applications do not have any issues with such changes. However, the SELinux utilities effectively serialize these structures and later read them back in. If the new pcre uses a changed structure, then the read-in structures are incompatible and even corrupt.

Hence the segmentation faults.

To resolve this, Stephen Smalley created a patch that includes PCRE version checking. This patch is now included in sys-libs/libselinux version 2.3-r1. The package also recompiles the existing *.bin files so that the older binary files are no longer on the system. But there is a significant chance that this update will not trickle down to the users in time, so the workaround might be needed.

I considered updating the pcre ebuilds as well with this workaround, but considering that libselinux is most likely to be stabilized faster than any libpcre bump I let it go.

At least we have a solution for future upgrades; sorry for the noise.

Edit: libselinux-2.2.2-r5 also has the fix included.

09 Jul 2014 6:35pm GMT

Michał Górny: The Council and the Community

A new Council election is in progress and we have a few candidates. Most of them have written a manifesto. For some of them this is one of the few mails they sent to the public mailing lists recently. For one of them this is the only one. Do we want to elect people who do not participate actively in the Community? Does such election even make sense?

Gentoo is an open, free community. While the Developer Community is not really open (joining consumes a lot of time), the discussion media were always open to non-developer comments and ideas. Most of the people working on Gentoo are volunteers, doing all the work in their free time or between other tasks.

While we have formal rules, leaders and projects, all of them have very limited power. The rules pretty much boil down to being «do not»s. You can try to convince developer to follow your vision but you can't force him to. If you try too hard, the best you can get is losing a valuable contributor. And I'm not talking about the extremes like rage quits; the person will simply no longer be interested in working on a particular project.

Most of the mailing list (and bug) discussions are about that. Finding possible solutions, discussing their technical merits and finding an agreement. It is not enough to choose a solution which is considered best by a majority or a team. It is about agreeing on a solution that is good and that comes with people willing to work on it. Otherwise, you end up with no solution because what has been chosen is not being implemented.

Consider the late games team policy thread. The games team and their supporter believes their solutions to have technical merit. Without getting into debating this, we can easily see the effects. The team is barely getting any contributions, mostly thanks to a few (three?) persistent out-of-team developers that are willing to overcome all the difficulties. And even those contributors support the idea of abolishing the current policy.

So, what's the purpose of all the teams, their leads and the Council in all this? As I see it, teams are the people who know the particular area better than others, and have valuable experience. Yet teams need to be open to the Community, to listen to their feedback, to provide valuable points to the discussion and to guide it towards a consensus.

The teams may need to make a final decision if a mailing list discussion doesn't end in a clear agreement. However, they need to weigh it carefully, to foresee the outcome. It is not enough to discuss the merits in a semi-open meeting, and it is not enough to consider only the technical aspect. The teams need to predict how the decision will affect the Community, how it will affect the users and the contributors.

The Council is not very different from those teams, albeit more formal in its proceedings. Likewise, it needs to listen to the Community, especially if it is called specifically to revise a team's decision (or lack of action).

Now, how could the Council determine what's best for Gentoo without actively participating in the proceedings of the Community? Non-active candidates, do you expect to start participating after being elected? Or do you think that grepping through the threads five minutes before the meeting is enough?

Well, I hope that the next Council will be up to the task. That it will listen to the Community and weigh their decisions carefully. That it will breed action and support ideas backed by technical merits and willing people, rather than decisions that discourage further contribution.

09 Jul 2014 6:27am GMT

06 Jul 2014

feedPlanet Gentoo

Sebastian Pipping: EGF Xiangqi file format tool and documentation

Hello :)

I don't get to playing with code much lately. Yesterday and today I put some effort into trying to understand and document the EGF file format used by Xie Xie to store Xiangqi games including per-move comments and a bit of other metadata.

Status quo includes a simple command line tool:

# ./egf/cli.py test.egf 
Event:  Blog post
Site:  At home
Date:  6-7-2014
Round:  1
Red name:  sping
Black name:  Xie Xie Freeware 2.5.0
Description:  Command line tool demo input
Author:  sping

File i:  R _ _ P _ _ p _ _ r
File h:  H _ C _ _ _ _ c _ h
File g:  E _ _ P _ _ p _ _ e
File f:  A _ _ _ _ _ _ _ _ a
File e:  K _ _ P _ _ p _ _ k
File d:  A _ _ _ _ _ _ _ _ a
File c:  E _ _ P _ _ p _ _ e
File b:  H _ C _ _ _ _ c _ h
File a:  R _ _ P _ _ p _ _ r
(Ranks 9 to 0 from left to right)

To start:  red

6 single moves in total
[ 1]  c h3  - e3 
[ 1]                   H h10 - g8 
[ 2]  h h1  - g3 
[ 2]                   R i10 - h10
[ 3]  r i1  - h1 
[ 3]                   C h8  - h4 

Result:  to be determined

Bytes remaining to be read:
0 0

I welcome help to fill in the remaining blanks, e.g. with decoding time markers and king-in-check markers of moves.

If you are on Gentoo and would like to run Xie Xie the easy way, grab games-board/xiexie-freeware-bin from the betagarden overlay.

EGF files for inspection can be downloaded from http://www.cc-xiexie.com/download.php.

06 Jul 2014 5:17pm GMT

Gentoo Monthly Newsletter: Gentoo Monthly Newsletter: June 2014

Gentoo News

Interview with Patrick McLean (chutzpah)

(by David Abbott)
1. Hi Patrick o/ tell us about yourself?
I am currently a Gentoo Engineer (yes, that is my actual job title) at Gaikai. Before this job I was a Systems Administrator at the McGill Centre for Intelligent Machines, in Montreal, Quebec, Canada.
When I am not coding or packaging I like to watch television, read sci-fi and fantasy, cycle, occasionally go on hikes. When I can I love downhill skiing, but it's a little harder in California than it was in Quebec.

2. How did you get involved with Linux and Open Source, and what was the path that lead to you to Gentoo?
I started using Linux at the end of 1996. Originally I switched to Linux because with the slow Internet connections of the times, web pages would take a long time to load. I would often open dozens of windows so I could be reading on site while others were loading. After a certain number of open browsers, Windows 95 would start to bog down then just crash, while when I did the same thing on Linux it would just happily chug along.
Around 2001, when Gnome 2 came out, I wanted to try out, and I don't like installing software outside of the package manager, so I attempted to get the rpms from the rawhide repository. This experience made me decide to look for a different distro, and I ended up liking Gentoo the most.

3. What aspects of Gentoo do you feel the developers and maintainers have got right?
The ebuild is a great source-based package format, it has it's drawbacks but it is far superior to the other formats I have looked at. I also like that Gentoo treats configurability as an important feature. The frequent use of /etc/foo.d and the scriptability of many parts of the system is great.
I also like some of the more recent work that has gone in to not breaking systems, preserved-rebuild and (despite some overuse) subslots fix many of the annoyances we had in the old days.
I am also a big fan of what is now OpenRC, ever since I first started using Gentoo, I have thought that this is a huge improvement over the alternatives.

4. What is it about Gentoo you would like to see improved?
I think that portage itself is getting very crufty, and the code base is not very nice to work with. I am sure just about everyone reading this would agree that dependency resolution is way too slow at the moment (especially with subslots). Sometimes it generates error messages that are horribly verbose with no indication of how to fix them. I have seen those errors make people leave Gentoo, this is especially bad when the things it's generating errors about are relatively harmless.
There are also other problems with how portage stores the information about installed packages on the disk, and binary packages in their current form just suck, and are pretty useless.

5. What resources have you found most helpful when troubleshooting within Gentoo and Linux in general?
For doing research into problems, google of course is very useful. For tracking down problems strace is probably the one tool I find the most useful. Of course also digging into the source is probably the single best way to figure out what is actually going on.

6. What are some of the projects within Gentoo that you enjoy contributing to?
I mostly do ebuild work at the moment, python is one area that I contribute the most to. I would like to get more in to package manager work, and I want to start helping more with OpenRC, but finding time is frequently a problem.

7. What is your programming background?
I taught myself to program on GW-BASIC for DOS, it was in no way a modern or even remotely modern language. I moved on to QBASIC a bit later on. Once I got to post high school I started learning Java, C, C++, but my first programming job was Visual Basic, it was an internship that turned in to a summer job. During this time frame I also taught myself shell scripting.
Later (around 2008) I taught myself python when a friend and I were trying to start a business.

8. For someone new to Python what tips could you give them to get a good foundation?
There are lots of good tutorials out there, I personally used Dive in to Python and found it quite useful. I also found that when I learned more about how Python is implemented, it improved my abilities quite a bit. If you truly understand that in Python everything is a dictionary, and the implications of that then it helps quite a bit in debugging the root cause of problems and write better code.

9. Tell us about pkgcore, its features and future?
Pkgcore is an alternative implementation of the PMS. It's basically an alternative to portage. It has always had the eventual goal of becoming the default package manager on Gentoo, replacing portage. It's currently orders of magnitude faster than portage. It's code base is much cleaner, though a little hard to understand at first thanks to it's use of libsnakeoil for performance optimization. Currently Tim Harder (radhermit) is working on getting all the recent portage feature implemented, it mostly supports EAPI 5 in the git repo now.
Hopefully it can attract more developers and eventually become a truly viable portage replacement, so we can get rid of the cruft that has built up in the portage source over the years.

10. Which open source programs would you like to see developed?
That's a hard question to answer. I think the biggest one is I would love to see an open source firmware for BMC controllers. These are the extra small computers included in servers that allow things such as remote console and the ability to remotely manage servers. Currently the ecosystem is full of half-assed implementations done by hardware companies, many of which are rife with security holes. There is no standard for remote console, so they all use buggy and horrible java applets to implement this. I would love to see a standard open source suite that motherboard developer all use, with native remote console clients for major OSes.

11. What would be your dream job?
Well I have long wanted a job as a kernel developer, but have never had the time to really dedicate to get to the point where someone would hire me. My current job is a close second. I work with Gentoo every day at work, often writing new ebuilds an fixing bugs in existing ebuilds as part of my day-to-day duties at work.
My day-to-day duties involve ebuild development and debugging. I also do a lot of automation of things like installing new systems, and was the lead developer on our in-house answer to configuration management. I get to do a lot of cool stuff with Gentoo and I get to get paid for it.

12. Need any help?
Yes, we are currently hiring lots of positions, all working with Gentoo. We are really looking for ebuild developers of all kinds, especially if you are comfortable with Java ebuilds (not mandatory, but it would be nice). We are also looking for anyone who is familiar with Gentoo to help with work in Release Engineering and Site Reliability Engineering. We currently have offices in Southern California, USA and Berlin, Germany.
If you are interested in getting paid to work with Gentoo, please drop me a line.

13. With your skills you would be welcome in any project, why did you chose Gentoo?
It had been my distro of choice for many years, and I just ended maintaining a local overlay with many bug fixes and miscellaneous things, so I decided to become a developer to share my work with everyone else.

14. What can we do to get more people involved as Gentoo developers?
That's a hard question to answer, at the moment probably the best way would be to get back the "hot" and "cool" factors. These days Gentoo is sort of a "background" distro that has been around for ages, has loads of users but new people don't get excited about anymore, kind of like Debian.
I think we also need to reduce developer burnout, I get the impression that once some people become developers, they feel that they have to fix every bug in the tree. This leads to them being really productive devs for a few months, then leaving when they get burned out and quit.

15. What users would you like to see recruited to become Gentoo developers?
It would be nice to recruit some of the proxy maintainers to contribute to more packages. I don't have anyone specific in mind at this moment.

16. As a Gentoo developer what are some of your accomplishments?
When I first started, I was on the amd64 bandwagon very early, so I ended up doing the 64-bit ports for a pretty large number of packges. More recently I maintain ebuilds for some particularly tricky packages such as Ganeti, which is a mixture of Python and Haskell code.

17. Same question but work related.
Well, it's probably a combination of two things.
Creating Gentoo profiles to auto generate dozens of different server image types, and building solid base Gentoo install for those servers.
Also building a fully automated Gentoo installation system that can partition disks, set up RAID, LVM and other parameters based on a JSON definition. Also a configuration file generation system that makes up the basis of our configuration management system.

18. What are the specs of your personal and work boxes?
My home box is a 6-core Core-i7 970 with 24GB of RAM, a GeForce 770, a 256GB SSD, 2 500GB spinning disks and a 1TB spinning disk. I have a 24" monitor and a 22".
My workstation at work is a 8-core Opteron with 16GB of RAM. I have 2 32" monitors hooked up to it. We also have some pretty beefy servers for building Gentoo images.

19. Describe your home network.
Nothing that exciting, I have a Netgear WNDR3800 running OpenWRT, and a gigabit switch. Connected to that I have a Synology NAS, a smart TV that I never use the smart features of, a media streaming box, a Blu-Ray, a PS4 (I work for Sony) and a couple of computers.

20. What de/wm do you use now and what did you use in the past?
I currently use XFCE, I used to use Gnome 2, tried out Gnome 3 for 2 days, decided that it isn't for me so created a huge package.mask to mask it. I stuck with that for several months, then decided I should switch to something else. I tried out Cinnamon for a bit, played with E17, considered Mate but then settled on XFCE.

21. What gives you the most enjoyment within the Gentoo community?
In general developers get along pretty well, this is more true on IRC than on the mailing lists. Also, at conferences there is a strong feeling of community among the Gentoo developers who are attending the conference.

22. How did you get the nick (chutzpah)?
It's kind of a silly story. Way back when I first started hanging out online (early 90s) I needed a nick. I ended up choosing the name of a particularly challenging Ski Trail at the Sunday River ski resort in Maine. I have been using the name ever since.

Council News

This month's big issue was to compile a preliminary list of features that could go into the next EAPI. It probably does not make sense to go into all the technical details here; you can find the accepted items in the meeting summaries [1,2,3] or on a separate wiki page [4]. One user-visible change will be that from EAPI=6 on every ebuild should accept user patches from /etc/portage/patches [5], as many do already today. Another one will be that(given an implementation in Portage is ready in time) a new type of use-flags will be introduced that can be used to, e.g., only pull in run-time dependencies; toggling such a useflag does not require a rebuild of the package.

In addition, some of us prepared a proposal to make it in the end easier for developers to host semi-official services within the gentoo.org domain [6]. This still needs work and is definitely not something the council can do on its own, but the general idea was given clear support.

Election News

The nomination process is complete, and voting is now open. This year's candidates are blueness, dberkholz, dilfridge, jlec, patrick, pinkbyte, radhermit, rich0, ryao,TomWij, ulm, williamh, and zerochaos. Additionally, almost every developer was nominated for the council. Elections will be open until 2359 UTC on July 14, and results should be posted around July 16. We've already had around 30 people vote, but there are 200 more developers who can vote. Get out there and vote!

Featured New Project: Hardened Musl

(by Anthony G. Basile)

The hardened musl project aims to build and maintain full stage3 tarballs for amd64, arm, mips and i686 architectures using musl as a its C standard library rather than glibc. The "hardened" aspect means that we will also make use of toolchain hardening features so that the resulting userland executables and libraries are more resistant to exploit, although we also provide a "vanilla" flavor without any hardening. In every respect, these stages will be like regular Gentoo stages, except glibc will be replaced by musl.

musl, like uClibc, is ideal for embedded systems although both can be used for servers and desktops. Embedded systems generally have three needs beyond regular systems: 1) They need to have a small footprint both on their storage device and in RAM. 2) They need speed for real time applications. 3) And in some situations, they need their executables to be statically linked. A typical embedded system has has a minimally configured busybox for some needed utilities as well as whatever service the image is to provide, eg. some httpd service. The stages we are producing are not really embedded stages because they don't use busybox to provide some minimal set of utilities; rather, they use the full set of utilities provided by coreutils, util-linux and friends. This makes these stages ideal as development platforms for building custom embedded images [1] or expanded into a server or desktop system.

However, be warned! If you try to build a full desktop system, you will hit breakage since musl adheres closely to standards while many packages do not. We are working on getting patches [2] for as a full XFCE4 desktop as we did for uClibc [3]. On the other hand, I've had lots of success building servers and routers from those stages without any extra patching.

[1] An example of the hardened uClibc stages being used this way is "Real Time And Tiny" (aka RAT) Gentoo.
[2] These patches are house on the musl branch of the hardened dev overlay.
[3] As a subproject of the Hardened uClibc project, maintain a full XFCE4 desktop based on uClibc, affectionately named "Lilblue" after the Little Blue Penguin, a smaller relative of the Gentoo.

Gentoo Developer Moves

Summary

Gentoo is made up of 237 active developers, of which 35 are currently away.
Gentoo has recruited a total of 799 developers since its inception.

Changes

The following developers have recently changed roles:
None this month

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 17529
Ebuilds 37513
Architecture Stable Testing Total % of Packages
alpha 3604 551 4155 23.70%
amd64 10781 6247 17028 97.14%
amd64-fbsd 0 1578 1578 9.00%
arm 2662 1726 4388 25.03%
hppa 3059 482 3541 20.20%
ia64 3181 620 3801 21.68%
m68k 623 82 705 4.02%
mips 4 2386 2390 13.63%
ppc 6819 2375 9194 52.45%
ppc64 4317 875 5192 29.62%
s390 1486 316 1802 10.28%
sh 1681 387 2068 11.80%
sparc 4122 896 5018 28.63%
sparc-fbsd 0 316 316 1.80%
x86 11444 5308 16752 95.57%
x86-fbsd 0 3236 3236 18.46%

gmn-portage-stats-2013-11

Security

The following GLSAs have been released by the Security Team

GLSA Package Description Bug
201406-36 net-nds/openldap OpenLDAP: Multiple vulnerabilities 290345
201406-35 net-im/openfire Openfire: Multiple vulnerabilities 266129
201406-34 kde-base/kdelibs KDE Libraries: Multiple vulnerabilities 358025
201406-33 net-analyzer/wireshark Wireshark: Multiple vulnerabilities 503792
201406-32 dev-java/icedtea-bin IcedTea JDK: Multiple vulnerabilities 312297
201406-31 kde-base/konqueror Konqueror: Multiple vulnerabilities 438452
201406-30 app-admin/sudo sudo: Privilege escalation 503586
201406-29 net-misc/spice-gtk spice-gtk: Privilege escalation 435694
201406-28 media-video/libav Libav: Multiple vulnerabilities 439052
201406-27 None polkit Spice-Gtk systemd HPLIP libvirt: Privilege escalation 484486
201406-26 dev-python/django Django: Multiple vulnerabilities 508514
201406-25 net-misc/asterisk Asterisk: Multiple vulnerabilities 513102
201406-24 net-dns/dnsmasq Dnsmasq: Denial of Service 436894
201406-23 app-admin/denyhosts DenyHosts: Denial of Service 495130
201406-22 media-libs/nas Network Audio System: Multiple vulnerabilities 484480
201406-21 net-misc/curl cURL: Multiple vulnerabilities 505864
201406-20 www-servers/nginx nginx: Arbitrary code execution 505018
201406-19 dev-libs/nss Mozilla Network Security Service: Multiple vulnerabilities 455558
201406-18 x11-terms/rxvt-unicode rxvt-unicode: User-assisted execution of arbitrary code 509174
201406-17 www-plugins/adobe-flash Adobe Flash Player: Multiple vulnerabilities 512888
201406-16 net-print/cups-filters cups-filters: Multiple vulnerabilities 504474
201406-15 kde-misc/kdirstat KDirStat: Arbitrary command execution 504994
201406-14 www-client/opera Opera: Multiple vulnerabilities 442044
201406-13 net-misc/memcached memcached: Multiple vulnerabilities 279386
201406-12 net-dialup/freeradius FreeRADIUS: Arbitrary code execution 501754
201406-11 x11-libs/libXfont libXfont: Multiple vulnerabilities 510250
201406-10 www-servers/lighttpd lighttpd: Multiple vulnerabilities 392581
201406-09 net-libs/gnutls GnuTLS: Multiple vulnerabilities 501282
201406-08 www-plugins/adobe-flash Adobe Flash Player: Multiple vulnerabilities 510278
201406-07 net-analyzer/echoping Echoping: Buffer Overflow Vulnerabilities 349569
201406-06 media-sound/mumble Mumble: Multiple vulnerabilities 500486
201406-05 mail-client/mutt Mutt: Arbitrary code execution 504462
201406-04 dev-util/systemtap SystemTap: Denial of Service 405345
201406-03 net-analyzer/fail2ban Fail2ban: Multiple vulnerabilities 364883
201406-02 app-arch/libarchive libarchive: Multiple vulnerabilities 366687
201406-01 None D-Bus GLib: Privilege escalation 436028

Package Removals/Additions

Removals

Package Developer Date
dev-python/python-gnutls mrueg 02 Jun 2014
dev-ruby/fastthread mrueg 07 Jun 2014
dev-perl/perl-PBS zlogene 11 Jun 2014
games-strategy/openxcom mr_bones_ 14 Jun 2014
media-plugins/vdr-noepgmenu hd_brummy 15 Jun 2014
net-mail/fetchyahoo eras 16 Jun 2014
app-emacs/redo ulm 17 Jun 2014
games-emulation/boycott-advance-sdl ulm 17 Jun 2014
games-emulation/neopocott ulm 17 Jun 2014

Additions

Package Developer Date
dev-ruby/sshkit graaff 01 Jun 2014
media-gfx/plantuml pva 02 Jun 2014
dev-python/sphinxcontrib-plantuml pva 02 Jun 2014
dev-util/kdevelop-qmake zx2c4 02 Jun 2014
x11-misc/easystroke jer 04 Jun 2014
dev-python/docopt jlec 04 Jun 2014
dev-python/funcsigs jlec 04 Jun 2014
virtual/funcsigs jlec 04 Jun 2014
dev-python/common jlec 04 Jun 2014
dev-python/tabulate jlec 04 Jun 2014
app-admin/ngxtop jlec 04 Jun 2014
dev-python/natsort idella4 05 Jun 2014
dev-libs/liblinear jer 05 Jun 2014
net-analyzer/arp-scan jer 06 Jun 2014
www-servers/mongoose zmedico 06 Jun 2014
dev-ruby/spring graaff 06 Jun 2014
dev-ruby/wikicloth mrueg 06 Jun 2014
net-analyzer/ipgen jer 07 Jun 2014
sec-policy/selinux-dropbox swift 07 Jun 2014
dev-python/jingo idella4 08 Jun 2014
dev-python/click rafaelmartins 08 Jun 2014
dev-python/Coffin idella4 08 Jun 2014
dev-python/sphinx_rtd_theme bicatali 09 Jun 2014
dev-ruby/netrc graaff 09 Jun 2014
dev-ruby/delayer naota 11 Jun 2014
www-client/qtweb jer 11 Jun 2014
dev-python/pyoembed rafaelmartins 12 Jun 2014
www-apps/blohg-tumblelog rafaelmartins 12 Jun 2014
dev-python/jaraco-utils patrick 12 Jun 2014
dev-python/more-itertools patrick 12 Jun 2014
dev-libs/libserialport vapier 12 Jun 2014
dev-python/pretty-yaml chutzpah 12 Jun 2014
net-libs/phodav dev-zero 13 Jun 2014
dev-python/django-haystack idella4 14 Jun 2014
sci-libs/libsigrok vapier 14 Jun 2014
sci-libs/libsigrokdecode vapier 14 Jun 2014
sci-electronics/sigrok-cli vapier 14 Jun 2014
sys-firmware/sigrok-firmware-fx2lafw vapier 14 Jun 2014
sci-electronics/pulseview vapier 14 Jun 2014
dev-ruby/hashr mrueg 14 Jun 2014
games-strategy/openxcom maksbotan 14 Jun 2014
games-engines/openxcom mr_bones_ 14 Jun 2014
net-analyzer/icinga2 prometheanfire 15 Jun 2014
dev-python/pyxenstore robbat2 15 Jun 2014
sys-cluster/ampi jauhien 16 Jun 2014
dev-python/pyjwt idella4 17 Jun 2014
app-emulation/openstack-guest-agents-unix robbat2 22 Jun 2014
dev-python/plyr idella4 22 Jun 2014
app-misc/relevation radhermit 22 Jun 2014
media-sound/lyvi idella4 22 Jun 2014
app-emulation/xe-guest-utilities robbat2 23 Jun 2014
net-misc/yandex-disk pinkbyte 24 Jun 2014
sec-policy/selinux-resolvconf swift 25 Jun 2014
dev-python/json-rpc chutzpah 26 Jun 2014
app-backup/cyphertite grknight 26 Jun 2014
dev-python/jdcal idella4 26 Jun 2014
net-libs/libcrafter jer 26 Jun 2014
net-analyzer/tracebox jer 26 Jun 2014
dev-python/python-catcher jlec 27 Jun 2014
dev-python/python-exconsole jlec 27 Jun 2014
dev-python/reconfigure jlec 27 Jun 2014
sys-block/sas2ircu robbat2 27 Jun 2014
sys-block/sas3ircu robbat2 27 Jun 2014
dev-ruby/psych mrueg 27 Jun 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 31 May 2014 and 30 June 2014. Not fixed means bugs that were resolved as NEEDINFO, WONTFIX, CANTFIX, INVALID or UPSTREAM.

Bug Activity Number
New 1991
Closed 1065
Not fixed 171
Duplicates 147
Total 5843
Blocker 5
Critical 18
Major 64

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 152
2 Gentoo Linux Gnome Desktop Team 54
3 Python Gentoo Team 39
4 Gentoo KDE team 33
5 Gentoo Games 28
6 Gentoo Ruby Team 20
7 Default Assignee for Orphaned Packages 20
8 media-video herd 17
9 Julian Ospald (hasufell) 17
10 Others 684


Assigned bug ranking

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

Rank Team/Developer Bug Count
1 Gentoo Security 97
2 Gentoo Linux Gnome Desktop Team 91
3 Gentoo Linux bug wranglers 91
4 Python Gentoo Team 70
5 Gentoo Games 64
6 Gentoo KDE team 50
7 Gentoo Prefix 49
8 Default Assignee for Orphaned Packages 49
9 Gentoo's Team for Core System packages 35
10 Others 1394


Tips of the month

(by Sven Vermeulen)
Quick one-time patching of packages

If you want to patch a package once (for instance to test a patch provided through bugzilla), just start building the package, but when the following is shown, interrupt it (Ctrl-Z):

>>> Source prepared.

Then go to the builddir (like /var/tmp/portage/net-misc/tor-0.2.4.22/work/tor-0.2.4.22) and apply the patch. Then continue the build (with "fg" command).

Verify integrity of installed software

If you don't want the full-fledged features of tools like AIDE, you can use qcheck to verify this for installed packages:
~# qcheck -e vim-core
Checking app-editors/vim-core-7.4.273 ...
MD5-DIGEST: /usr/share/vim/vim74/doc/tags
* 1783 out of 1784 files are good

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.

06 Jul 2014 3:00pm GMT

02 Jul 2014

feedPlanet Gentoo

Sven Vermeulen: Multilib in Gentoo

One of the areas in Gentoo that is seeing lots of active development is its ongoing effort to have proper multilib support throughout the tree. In the past, this support was provided through special emulation packages, but those have the (serious) downside that they are often outdated, sometimes even having security issues.

But this active development is not because we all just started looking in the same direction. No, it's thanks to a few developers that have put their shoulders under this effort, directing the development workload where needed and pressing other developers to help in this endeavor. And pushing is more than just creating bugreports and telling developers to do something.

It is also about communicating, giving feedback and patiently helping developers when they have questions.

I can only hope that other activities within Gentoo and its potential broad impact work on this as well. Kudos to all involved, as well as all developers that have undoubtedly put numerous hours of development effort in the hope to make their ebuilds multilib-capable (I know I had to put lots of effort in it, but I find it is worthwhile and a big learning opportunity).

02 Jul 2014 7:03pm GMT

Anthony Basile: Continued support for the Lemote Yeeloong: Gentoo Mips is alive and well!

A few years back the Lemote Yeeloong made a splash in the open source community as the world's first completely "open" system requiring no proprietary software. Even its BIOS is open source. It wasn't long before pictures of Richard Stallman hugging his Yeeloong started popping up throughout the Internet, further boosting its popularity. I became interested because the Yeeloong involves everything that's near and dear to my heart: 1) Its loongson2f processor is a mips64el system and I love the slick nature of RISC architectures. I can actually make sense of its ISA and the assembly. 2) As a 64-bit mips, it supports multiple ABIs, and I love playing with different ABIs. The images I push come with o32, n32 and n64. 3) While other distros, like Debian, have ported their wares to the Yeeloong, these don't have the hardening goodness that Gentoo does and so this was an added challenge. Thanks to Magnus Granberg (zorry) for getting his hardened gcc patches work in mips. 4) Finally, it is "free" as in "libre". It is manufactured by Lemote in China, and I like to fantisize that hackers at the NSA curse everytime they encounter one in the wild, although the reality is more likely that I'm owned by the Chinese government :/

So here was the possibility of creating a free and secure system on my favorite architecture! A couple of summers back, I took on the challenge. I updated some older stages3 that Matt Turner (mattst88) had prepared and went through the process of seeing what desktop packages would build, which needed patching and which were hopelessly broken on mips, usually because of dependance on x86/amd64 assembly. The end result was a minimal XFCE4 desktop with full userland hardening. Unfortunatley, I still don't have a PaX kernel working, but the issues do not appear to be insurmountable.

Building the initial images was more fun than maintaining them, but I've been good about it and I recently prepared release 20140630. I even started to feel out the community more, so I announced this work as a project on freecode.com, just before the site closed down :( If you get a new Lemote Yeeloong, give these images a try. It'll save you about 4 days of compiling if you want to bootstrap from a stage3 to a full desktop, not counting all the broken packages you'll probably hit along the way. If you're already running one of my images then you can try to update on your own but expect a lot of conflicts/blockings etc since mips is not a stable arch. Perhaps the next step to making this more user-friendly is for me to provide the binpkgs on some host.

02 Jul 2014 1:21pm GMT

29 Jun 2014

feedPlanet Gentoo

Pavlos Ratis: Accepted for Google Summer of Code 2014

This year I've been accepted for Google Summer of Code 2014 with Gentoo Foundation for the Gentoo Keys project and my mentor will be Brian Dolbec (dol-sen). Gentoo Keys is a Python based project that aims to manage the GPG keys used for validation on users and Gentoo's infrastructure servers. These keys will be any/all of the release keys, developer keys and any other third party keys or keyrings available or needed.

Participating in large communities and being a developer has great responsibilities. Developers have access to commit their new changes to the main repository, however, even an unintended incorrect commit in the main repository would affect the majority of the users. This issue could be addressed easily by the developer that did the mistake instantly. A less innocent case is that if a developer's box is compromised, then the malicious user could commit malicious changes freely to the main tree. To prevent this kind of incidents, developers are requested to sign their own commits with their GPG key in order to ensure who they claim to be. It's an extra layer of protection that helps to keep the integrity of the main repository. Gentoo Keys aims to solve that and provides its features in many scenarios like overlays and release engineering management.

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. In addition, it will be used by Gentoo infrastructure team to achieve GPG signed git commits in the forthcoming git migration of the main CVS tree.

Gentoo Keys is an open source project which has its code available from the very first day in Gentoo's official repositories. Everyone is welcome to provide patches and request new features.

Source code: https://github.com/gentoo/gentoo-keys.
Weekly Reports are posted here.
Wiki page: https://wiki.gentoo.org/wiki/Project:Gentoo-keys.

Accepted for Google Summer of Code 2014 was originally published by Pavlos Ratis at dastergon's weblog on June 30, 2014.

29 Jun 2014 9:00pm GMT

25 Jun 2014

feedPlanet Gentoo

Patrick Lauer: Building Everything

Preparation:

Run: Start a screen session for each clone. Chroot in. Apply magic oneliner:

for i in $( qsearch -NC --all | sort -R ); do 
    if $( emerge --nodeps -pk $i > /dev/null ) ; then 
        emerge --depclean; echo $i; emerge -uNDk1 $i; 
    fi; 
done

Wait 4-5 days, get >10k binary packages, lots of logfiles.

Space usage:
~2.5G logfiles
~35G distfiles
~20G binary packages
~100G temp space (/var/tmp has lots of cruft unless FEATURES="fail-clean")


Triage of these logfiles yields about 1% build failures, on average.
It's not hard to do, just tedious!

make.conf additions:

FEATURES="buildpkg split-log -news"
PORT_LOGDIR="/var/log/portage/"
MAKEOPTS="-j4"
EMERGE_DEFAULT_OPTS="--jobs 4"

CLEAN_DELAY="0"
EMERGE_WARNING_DELAY="0"
ACCEPT_PROPERTIES="* -interactive"

25 Jun 2014 6:27am GMT

24 Jun 2014

feedPlanet Gentoo

Sebastian Pipping: freshplayerplugin (Chrome Flash for Firefox) in Gentoo betagarden, uses uriparser

Since Adobe has stopped developing Flash for Firefox and Mozilla has no plans to support the Pepper plug-in API, Rinat Ibragimov is developing a wrapper to use Google Chrome's Pepper-based Flash plug-in with Mozilla Firefox:

GitHub: i-rinat/freshplayerplugin

A live ebuild is now available in the "betagarden" overlay. Users of non-stable Chrome can edit the plug-in path in /etc/freshwrapper.conf.

Interestingly, freshplayerplugin makes use of my library uriparser for URI handling. Very nice! :)

24 Jun 2014 9:51pm GMT