Tag: Gentoo
Steve Dibb: new cell phone: droid x
by febuntoo on Sep.09, 2010, under Gentoo, Uncategorized
I got a new phone this week, the Motorola Droid X, running Android ... woo! Boy, that sentence is gonna attract a lot of spammers. :T
It's an awesome phone. I like it. Well, actually, I dunno about the phone part, I think I've called one person. I've been playing with all the cool apps. This is my first smartphone, so having access to all this stuff is really quite a novelty to me. Right now, I'm a big fan of Foursquare. 
I think it's handy, since I can see what's nearby quickly.
The Google Voice integration is nice ... I can call out directly using the number they provide instead of my carrier's, and I can use it to send free text messages. Although, I'll admit, as applications go, the native Android text messaging software is much better.
I don't have Android 2.2 on here, which is supposed to be the new hawtness, I hear. I like everything so far. My only complain right now is that there's no port of Oregon Trail. 
Alright, I really don't have much more to say about it. I'm excited.
I'll admit I wrote this post just to use that LOLcat.
Diego E. Pettenò: Are we done with LDFLAGS?
by febuntoo on Sep.09, 2010, under Gentoo, Uncategorized
Quite some weeks ago, Markos stated asking for a more thorough testing of ebuilds to check whether they support LDFLAGS; he then described why that is important which can be summarised in “if LDFLAGS are ignored, setting --as-needed by default is pointless”. He’s right on this of course, but there are a few more tricks to consider.
You might remember that I described an alternative approach to --as-needed that I call “forced --as-needed”, by editing the GCC specifications. The idea is that by forcing the flag in through this method, packages ignoring LDFLAGS and packages using unpatched libtool won’t simply ignore it. This was one of the things I had in mind when I suggested that approach, but alas, as it happens, I wasn’t listened to.
Right now there are 768 bugs reported blocking the tracker of which 404 are open and, in the total, 635 were reported by me (mostly through the tinderbox but not limited to). And I’m still opening bugs on a daily basis for those.
But let’s say that these are all the problems there are, and that in two weeks time no package is reporting ignored LDFLAGS at all. Will that mean that all packages will properly build with --as-needed at that point? Not really.
Unfortunately, LDFLAGS-ignored warnings have both false positives (prebuild binary packages, packages linking with non-GNU linkers) and false partially-negatives. To understand that you have to understand how the current warning works. A few binutils versions ago, a new option was introduced, called --hash-style; this option is used to change the way the symbol table is hashed for faster loading by the runtime linker/loader (ld.so); the classic hashing algorithm (SysV) is not excessively good for very long, similar symbols that are way too common when using C++, so there has been some work to replace that with a better GNU-specific algorithm. I’ve followed most of the related development closely at the time, since Michael Meeks (of OpenOffice.org fame) actually came asking Gentoo for some help testing things out; it was that work that actually got me interested in linkers and the ELF format.
At any rate, while the original hash table was created in the .hash section, the new hash table, being incompatible, is in .gnu.hash. The original patch only replaced one with the other, but what actually landed in binutils was slightly different (it allows to choose between SysV, GNU, or both hash tables), and the default has been to enable both hash tables, so that older systems can load .hash and the new ones can load .gnu.hash; win win. On the other hand, on Gentoo (and many other distributions) where excessively old GLIBC versions are not supported at all, there is enough of a reason to use --hash-style=gnu to disable the generation of the SysV table entirely.
Now, the Portage warning is derived by this situation: if you add -Wl,--hash-style=gnu to your LDFLAGS, it will be checking the generated ELF files and warn if it finds the SysV .hash section. Unfortunately this does not work for non-Linux profiles (as far as I know, FreeBSD does not support the GNU hashing style yet; uClibc does), and will obviously report all the prebuilt binaries coming from proprietary packages. In those cases, you don’t want to strip .hash because it might be the only hash table preventing ld.so from doing a linear search.
So, what is the problem with this test? Well, let’s note one big difference between --as-needed and --hash-style flags: the former is positional, the second is not. That means that --as-needed, to work as intended, needs to be added before the actual libraries are listed, while --hash-style can come at any point in the command line. Unfortunately this means that if any package has a linking line such as
$(CC) $(LIBS) $(OBJECTS) $(LDFLAGS)
It won’t be hitting the LDFLAGS warning from Portage, but (basic) --as-needed would fail — OTOH, my forced --as-needed method would work just fine. So there is definitely enough work to do here for the next… years?
Hanno Böck: Test your browser for Clickjacking protection
by febuntoo on Sep.08, 2010, under Gentoo, Uncategorized
In 2008, a rather interesting new kind of security problem within web applications was found called Clickjacking. The idea is rather simple but genious: A webpage from the attacked web application is loaded into an iframe (a way to display a webpage within another webpage), but so small that the user cannot see it. Via javascript, this iframe is always placed below the mouse cursor and a button is focused in the iframe. When the user clicks anywhere on an attackers page, it clicks the button in his webapp causing some action the user didn't want to do.What makes this vulnerability especially interesting is that it is a vulnerability within protocols and that it was pretty that there would be no easy fix without any changes to existing technology. A possible attempt to circumvent this would be a javascript frame killer code within every web application, but that's far away from being a nice solution (as it makes it neccessary to have javascript code around even if your webapp does not use any javascript at all).
Now, Microsoft suggested a new http header X-FRAME-OPTIONS that can be set to DENY or SAMEORIGIN. DENY means that the webpage sending that header may not be displayed in a frame or iframe at all. SAMEORIGIN means that it may only be referenced from webpages on the same domain name (sidenote: I tend to not like Microsoft and their behaviour on standards and security very much, but in this case there's no reason for that. Although it's not a standard – yet? - this proposal is completely sane and makes sense).
Just recently, Firefox added support, all major other browser already did that before (Opera, Chrome), so we finally have a solution to protect against clickjacking (konqueror does not support it yet and I found no plans for it, which may be a sign for the sad state of konqueror development regarding security features - they're also the only browser not supporting SNI). It's now up to web application developers to use that header. For most of them – if they're not using frames at all - it's probably quite easy, as they can just set the header to DENY all the time. If an app uses frames, it requires a bit more thoughts where to set DENY and where to use SAMEORIGIN.
It would also be nice to have some "official" IETF or W3C standard for it, but as all major browsers agree on that, it's okay to start using it now.
But the main reason I wrote this long introduction: I've set up a little test page where you can check if your browser supports the new header. If it doesn't, you should look for an update.
Tobias Klausmann: Gauging interest
by febuntoo on Sep.08, 2010, under Gentoo, Uncategorized
I do a fair amount of stuff using RRDTool. When developing a
new thing to store in and graph with RRD, it often happens that you get data
that is wrong. On top of that, rollover (aka cycling or flapping) can
introduce artifacts, even though RRDTool is good at detecting those. Since I
don't like editing XML files by hand, I wrote a tool to help me edit out data
that I know is wrong. It's not polished enough to release and getting it ready
is a fair amount of work. So here's my question: is there reasonable interest
in it? Do you pine for such a tool? If yes, send me a message/comment!Fabio Erculiani: An iterator that never ends
by febuntoo on Sep.08, 2010, under Gentoo, Uncategorized
Most of the time I feel like dealing with a never ending iterator while fixing bugs. Once you fix one bug, another immediately pops up somewhere else. Or while you fix a bug, you find other two in a row. 90% of the time, it is because somebody else decided to break his API or just because in hurry, thus not seeing the whole picture in that exact moment. A new super-fast rewritten routine could impact the reliability of the whole code and cause damage. Even if a stupid file path mistake could generate tremendous effects. It is here, that corner-cases support is dropped.
What do I mean? That probably somewhere in your application you’re using a library in a legal-but-not-very-common way. …and upstream doesn’t know about it!
So, the efficiency drops a LOT! I can estimate that 60% of my time as free software developer is spent at fixing what other people broke. And other people spend time at fixing what I break, too, of course. So what could be a viable “solution” in order to mitigate the problem? Beside saying “there’s nothing against laziness, nothing against people forgetting to let other people know about important changes in their software” not much. Perhaps some kind of Twitter/Identi.ca interface? The Publisher/Subscriber pattern might work well. Maybe this is going to happen someday in future, who knows…
