Fernando J. Pereda’s blag

May 29, 2008

Exherbo Workflow

Filed under: blag — Tags: , — Fernando J. Pereda @ 12:27 pm

I’ve found myself using these functions a lot while working on exherbo (which are suitable for Gentoo overlays using git too):

 1 # Fernando J. Pereda
 2 # exherbo workflow
 4 reponame()
 5 {
 6     local reponame=$1
 7     if [[ -z ${reponame} ]] ; then
 8         local t=$(git rev-parse --git-dir)
 9         t=${t//\.git}
10         if [[ -z ${t} ]] ; then
11             t=${PWD}
12         else
13             t=${t%/}
14         fi
15         reponame=${t##*/}
16     fi
17     echo ${reponame}
18 }
20 repoclean()
21 {
22     local n=$(reponame $1)
23     (
24         cd /var/repositories/"${n}"
25         sudo git clean -fd
26         sudo git checkout -f
27     )
28 }
30 repoexport()
31 {
32     local n=$(reponame $1) rhead repo
33     repo=/var/repositories/"${n}"
34     rhead=$(git --git-dir="${repo}"/.git rev-parse HEAD)
35     if ! git cat-file -t ${rhead} >/dev/null 2>&1 ; then
36         echo >&2 "Remote HEAD not found. Need 'git pull --rebase'?"
37         return 127
38     fi
39     GIT_PAGER=cat git log --pretty=format:'- %s' ${rhead}..
40     echo
41     git diff ${rhead}.. | ( cd ${repo} ; sudo git apply - )
42 }

I usually work in my own clones of the repositories I have configured in paludis, for instance:

$ for repo in x11 arbor ; do git clone --reference /var/repository/${repo} git://git.exherbo.org/${repo} ; done

Then I work on topic branches until they are ready:

$ git checkout -b mybranch
[ gvim + git commit + ... ]
$ repoclean
$ repoexport
$ sudo paludis ...... # try the package(s) I'm working on until I'm happy

At that point, I do:

$ git fetch
$ git rebase origin/master
$ git checkout master
$ git merge mybranch
$ git push

— ferdy

Update: As rbrown points out. The clone command was wrong.

May 27, 2008

What’s missing from latest GMN

Filed under: blag — Tags: , , — Fernando J. Pereda @ 11:07 am

Latest Gentoo Montly Newsletter is missing something… what is it?

Yeah, right. It doesn’t mention the fact that the council missed their metting and they should get the boot.

Gentoo is a joke these days. Trying to stuff shit under the carpet is surely not going to work forever.

— ferdy

Shipping default configurations

Filed under: blag — Tags: — Fernando J. Pereda @ 1:08 am

I’ve spent a couple of days getting postfix into arbor. At some point, I got to decide what to provide our users with with respect to configurations.

Postfix has two main configuration files, main.cf and master.cf. The former controls general postfix settings like “who do I accept mail from?” (mynetworks), “for which hosts am I going to receive mail?” (mydestination), “who do I send mail to?” (relayhost) and so on. While the latter specifies which servers (postfix works by doing different tasks in different servers) are going to be run and whith which parameters.

In Exherbo, we are going to follow upstream unless when we can’t. In this particular case, upstream’s wording isn’t particularly clear to me. They discourage providing a big file full of comments by default (which is what Gentoo does) so that people don’t tinker with stuff they don’t understand. And they encourage packagers to provide a small configuration. Turns out this isn’t exactly possible since there are several different use cases for a software package like postfix.

I also hate what Debian does, they usually provide a default configuration and automagically start the service. Leaving you potentially open to security attacks.

In the end, I decided to ship a simple example configuration file that postfix won’t see and let users provide their own configuration. I, for instance, expect people using postfix to know what they are doing and to be able to configure it themselves. For the master.cf, I ended up copying the one in the source distribution since that one seems simple enough.

What do you think about this? Do you expect software to be configured for you upfront?

It is not like it is going to change what we do in Exherbo, but I got curious.

— ferdy

May 26, 2008

Security trivia II

Filed under: blag — Tags: , — Fernando J. Pereda @ 6:25 pm

Suppose you have the following code:

char *start, *end, *ref;
/* Some code that process user input so that start and end
 * point to valid memory addresses and start + k < end.
 * Where k is some constant you can't control.
 * ref is made to point to some program-defined chunk,
 * but you can't control this one.
int n = end - start;
if (memcmp(ref, start, n) != 0) {
    printf("Checksum mismatch. Access denied.\n");
printf("Checksum matches. Access granted.\n");

This one is probably easier than the first one, but anyway:

  • What’s wrong with this code?
  • What environment do you need to exploit it?
  • Given such an environment, how can you exploit it?
  • How would you fix the code?

If you’ve seen me ranting about this in #exherbo-dev, you are not allowed to answer :)

— ferdy

May 23, 2008

Security trivia

Filed under: blag — Tags: , — Fernando J. Pereda @ 2:37 pm

Apparently, this kind of issues are difficult to understand. Sometimes, you can pretend they don’t exist, but you want to get rid of them. Security is often about small mistakes here and there that lead to big holes when used together.


  • What’s wrong with this code?
  • What environment do you need to exploit it?
  • Given such an environment, how can you exploit it?
  • How would you fix the code?
if(-l $statefile) {
        die("$statefile is a symbolic link, refusing to touch it.");
open (OUT, ">$statefile") or exit 4;
print OUT "$pos:$delivered\n";

A couple of days ago, I reported a similar issue (which I suspect it can be exploitable) and couldn’t get upstream to fix it (I can’t be bothered with a patch because I don’t use the software anyway). I’m not sure why they didn’t fix it, probably they don’t care about security, or they don’t understand the issue at hand.

I’ll post the answer in a couple of days or whenever someone gets it right.

— ferdy

May 22, 2008


Filed under: blag — Tags: , , — Fernando J. Pereda @ 1:29 am

Recently Read

  • Linux System Programming, Robert Love. This book disappointed me. I expected much deeper stuff and not only a mere listing of syscalls and some hints here and there.
  • Beyond Fear, Bruce Schneier. I liked it very much, really enlightening.

Currently Reading

Recommendation: Secure Coding in C and C++, Robert C. Seacord. Even if it is difficult to read at first, it is really enjoyable and interesting.

— ferdy

Awesome is awesome

Filed under: blag — Tags: , — Fernando J. Pereda @ 1:02 am

To work on exherbo I needed a comfortable environment. After tinkering around packaging open-vm-tools (which took a fair bit to get working) I tried to install fluxbox, which didn’t seem to compile for me. At this point I remembered I wanted to try awesome.

Most of its deps where already available in our x11 repository, except for confuse and awesome itself. In less than fifteen minutes I was using it. It seems that my usual workflow fits quite nicely in how awesome works. I had already tried some tiling window managers and always ended up switching back to fluxbox and my rusty set of shortcuts. Today, I’ve just looked at awesome’s Command Reference a couple of times. And I’m really eager to install it on my main box (when I get that screen back from repair).

I’ve also found the time to package mutt and do a couple of fixes here and there. Some of the stuff is in arbor, some in x11, and some more in my supplemental repository for exherbo at git://git.ferdyx.org/ferdy-supplemental.git.

— ferdy

May 20, 2008

Gmandel, Gtk+ and Threads

Filed under: blag — Tags: , , , — Fernando J. Pereda @ 1:18 am

For gmandel (see Chaotic Stuff for more info) I had to add a little GtkProgressBar so that users have a rough estimate of the time it’ll take rendering the fractal.

I wanted to have a clean and easy to study code, so, to avoid threads (that are usually difficult to study for newcomers) I used the following hack to update the progress bar:

static inline void flush_events(void)
    while (gtk_events_pending())

And, with some code to save expose events and relaunch them once the image had been rendered, it worked fine. However, that’s a hack, and the real solution is to fire a new thread to do the rendering work and update the widget when it’s finished. Naïve I was.

Gtk+’s documentation states it very clearly: Make sure you protect all calls to Gtk with a gdk_threads_enter(), gdk_threads_leave() pair. With that, you can call Gtk functions from any thread you want and forget about implementing IPC mechanisms to make all the calls from one thread. One of the problems is that the default implementation of the Gdk lock is a non-reentrant mutex, which means you lock it while already holding it (otherwise, you deadlock).

It should be noted that gtk_main() should also be enclosed in an enter-leave which means that functions called by it, can’t try to lock Gdk’s mutex or they’ll deadlock. This is a problem if you are trying to share functions between event handlers and threads. The trick here is to replace that mutex with a couple of functions that lock a reentrant mutex using gtk_threads_set_lock_functions().

What isn’t clear is that gtk_events_pending() will try to acquire Gdk’s lock. For some reason, I forgot to remove the hack that events_flush() was, and had wasted lots of time trying to fix a small, difficult to reproduce, race condition because I was calling gtk_events_pending() while holding the Gdk lock.

So, really, working with threaded applications in Gtk+ is really easy. It is just a matter of protecting calls to Gtk with a critical section. I’m not sure why the documentation isn’t more clear, and the fact that some of the old information floating in the web still advises to only call Gtk from one thread doesn’t really help. Had I started with a threaded version instead of using events_flush() thing would’ve been far easier :)

Bottom line: If something is difficult, working it around won’t make it easier, quite the contrary.

— ferdy

May 19, 2008


Filed under: blag — Tags: — Fernando J. Pereda @ 4:13 pm

This is really exciting. Nothing interesting to see, yet lots of interesting stuff to expect in the not so distant future.

Good luck everyone and congratulations.

— ferdy

May 18, 2008

Chaotic stuff

Filed under: blag — Tags: , , — Fernando J. Pereda @ 11:25 pm

I’ve been working on a couple of utilities to toy around with L-Systems and the Mandelbrot Set.

lsys is a simple utility that would take an axiom, generation rules and a depth. After some crunching (depends on the complexity of the fractal), it will show a window with the fractal. It has some examples bundled with it for further toying. The idea behind gmandel is a nice Mandelbrot Set explorator, reality is a bit far from that though :) . However, it offers something I haven’t seen in most fractal applications, Mandelbrot Orbits. Those are really nice to see to understand the set a bit more. It has facilities to load and save states and lets you save the image you are seeing (yay for fractal wallpapers).


It also has some dull color themes. All the code is really implementing a widget that draws the fractal, the idea is to inherit that widget to display Julia Sets too. But since I’m only spending a couple of hours every two months on this, it might take a while :)

I haven’t bothered with ebuilds for this yet, though the code is publicly available at: git://git.ferdyx.org/lsys.git and git://git.ferdyx.org/gmandel.git. The former needs copme (an option parsing library that doesn’t suck), which can be found at git://git.ferdyx.org/copme.git and for which there’s an ebuild at git://git.ferdyx.org/ferdy-overlay.git.

— ferdy

Older Posts »

Create a free website or blog at WordPress.com.