Introducing biometric authentication in our systems is a very good idea. It is the key to two-factor authentication which, while not solving all security issues, can bring a giant leap in terms of security when done correctly.

Everything is in the correctly.

And I can t say I m impressed with the way people are developing fingerprint authentication systems. Let s look at the currently emerging standard, fprint, and its security notes:

In it's current state, fprint is not a very secure system: this data is stored on disk in unencrypted form. This data is not readable by other users, however it is possible that the super-user can access it, and also someone with local access could move the disk to another system in order to gain access to the whole disk.

This statement is followed by considerations on how to protect this data from being read, much like passwords are protected by MD5 hashes.

Wait Yes, they are treating biometrical data like a password. Password-based security relies on the fact it isn t easy to obtain your password without spying on you or torturing you. But obtaining your fingerprint? Unless you ve been wearing gloves for years, this is absolutely trivial. And this is how people focus on the wrong issues.

Biometric data is not a password, and it requires a radically different approach to authentication. You can t just expect the person in front of the computer to provide some data corresponding to the fingerprint. You have to ensure that the person in front of the computer is the one with the correct fingerprint. Biometric devices manufacturers have made impressive efforts to ensure fake fingers or cut fingers can t be used, but there is still a giant hole in the security model. While you can now be reasonably sure that the device will only return data corresponding to the person in front of it, you also need to ensure the data processed by the computer comes from the device.

Guess what? These devices are USB-based. And given how USB works, there is nothing that prevents an attacker to plug a custom device in the USB port and send the data he wants to the authentication system. Good job, guys. While you re busy hiding easily available data, the house s door is still wide open.

#451480 really made my day. I'll let you judge for yourself:

Package: debhelper
[snip]

When building a package and having libc6 2.7.0exp8 installed (from
experimental), debhelper (dh_shlibdeps ?) does not compute correct
dependencies:
Depends: libc6 (>= 2.7-1), xserver-xorg-core (>= 2:1.4)

The package is then uninstallable.

This strip is dedicated to lool.

If you know of an occasional passerby who takes the time to extract the contents of Debian source packages to see whether the RFCs are here or not, please let us know. We are always looking for new potential contributors.

— Josselin Mouette

This is the sum of the votes for the three fascist candidates at yesterday's French election. Not forgetting the 5.79 % of trotskist candidates, you can see how much the French like democracy. All in all, only 49.12 % of the French voted for a democratic candidate (christian-democrat, social-democrat, communist, green, post-globalization). Think about it before saying again that France is the country of human rights. This is confirming that after five years of Sarkozy and his omnipresent police - regularly pinpointed by Amnesty International - we're already the country of human half-rights.

Based on important samples of data found on various reliable sources, like mailing lists, blogs and IRC channels, the CGMRS (Cabalistic Group for Mind-Reading Studies) has established a generic profile of Debian developers. Let me present you the result of 10 years of research in 12 academic laboratories. This study was sponsored by the National Agency for Troll-based Energies.

With each new GNOME versions, the icon themes from gnome-themes-extras are becoming less useful. The desktop and applications needs evolve, and the default theme is growing, providing more and more icons the icon themes can't provide. Because of that, the desktop is looking less consistent when using those icon themes. With GNOME 2.16 and the move to the Tango naming scheme, it is even worse as most icons got renamed. As upstream isn't touching this package anymore, I have decided to rework it entirely, and to migrate it to the new naming scheme. It was a very tedious task, but the result is much better than what I expected. To my surprise, I found the freedesktop.org icon naming specification to be a very good document that brings much simplicity to icon themes. Especially, the MIME types specification makes it much simpler to provide only a few icons, and the default theme contains much fewer icons than before. The result is in the pkg-gnome alioth repository, and uploaded to experimental. As Clearlooks is good but not great, I appreciate much the grand retour of Gorilla and Nuvola, the best themes ever, on my desktop. They are now more tightly integrated to the desktop than ever before. What now? First, I'd like people to test the themes. There are 6 of them and I don't use all of them. Please report inconsistencies, obviously missing icons, or wrongly named ones. You can also help by making new icons. Just grab inkscape, open icons, and make the changes. It's much easier than you could expect, especially if you start by combining existing icons. The icon naming specification will show you which icons can be useful additions. Some translations are also completely wrong, please don't hesitate to send me updates.

"We are bad developers."

Daniel Glazman, about the Mozilla community.

Complaining about minds not being ready for a woman elected as president, while showing the same disrespect, calling her by her first name while keeping the full polite naming for male politicians, sounds, well, ironical.

Improving the speed of upgrades is a never-ending process. Last year, I worked on GConf schema registration which was painfully slow. Today, the introduction of apt-delay, which compensates for the absence of hooks in dpkg, paves the way for further improvement: single call for gconf-schemas (although we wouldn't gain much now), but also more recently widespread dog-slow stuff like update-mkinitrd and fc-cache. However this approach doesn't work for ldconfig, as this command must be launched before considering the package as configured. Therefore, you can't hook it into apt-delay and hope everything installs fine before running ldconfig. The ldconfig case can be solved by itself, as it is possible to use the simplest caching method by simply looking at the timestamps of the directories it scans. This patch (for glibc 2.5) adds simple checks to see whether the directories actually need to be rescanned before regenerating the cache. The improvement is visible as soon as you upgrade two libraries together - and generally, unstable users upgrade them by packs of ten, if not more. As Aur lien Jarno seemed to agree with the approach, I hope to see it included soon, at least in experimental.

Although you've not behaved very good, Santa Claus has a present for you: the entire GNOME 2.16.2 desktop in experimental. All core applications are here, only some bindings are still missing. Which means it's time for the most courageous to test it. With the experimental APT source configured, it should be a matter of apt-get install -t experimental gnome-desktop-environment. Be warned, it's still rough around the edges:

• GTK+ makes liferea crash repeatedly;
• there are a few glitches in the file chooser;
• there is only one working icon theme (the default one);
• evince seems to crash on some files;
• the keyboard switching stuff doesn't work at all.

But there are also many pleasant speed and UI improvements in most modules. Unfortunately for many, it is currently only available on amd64. Now, if a group of reindeers could rebuild it on i386, the children would be much happier. Otherwise, I will take some time to rebuild them in an i386 chroot in a few days.

Erich, every single word in your last post is either an insult or an outrageous lie.

Other planet readers: I apologize for not ignoring him earlier. Sorry for the pollution.

Erich Schubert's pastime seems to be accusing others of trolling and FUDing (a politically correct buzzword that actually means lying) while contributing to these trolls and spreading lies himself. I had warned I would reduce my involvement in the project if dunc-tank was started. I reduced it much less than I could, probably much less than I should. I had warned that maintaining libpng required a high profile developer with time and motivation, and I had lost the latter. Basically, the dunc-tank cabal chose to ignore such warnings - as well as similar warnings given by other developers - and thought they could do better without us. Fine. I didn't do anything to prevent libpng from being maintained, and yet you see the result. Trying to put the blame on me for this disaster is simply outrageous. Sure, I have my share in this disaster. Just like you, Erich. You and all others who didn't work on libpng for this time. You let a junior maintainer try to deal with a complicated package, and you let him fail, like every one of us would have failed when we were new in this project. Now, if you really think that:

• warning the release team of this disaster before it hit us,
• giving advice on how to fix it,
• helping them to build their fix,

was being childish, there's nothing I can do to help you, as the kind of help you need has nothing to do with computing. What I have learnt in the meantime, though, is that most people in the project are really able to appreciate any kind of help, which is why now, I won't let myself be hurt by those few who spend time insulting other developers rather than maintaining packages.