Dependency of essential Linux bluetooth features on dbus
Apparently I'm not the
only one with outspoken criticism of the BlueZ dependencies on dbus.
I do not want to debate the merits of a message bus system on any system
(desktop or non-desktop) and neither do I want to start a debate on how
efficient dbus is trying to solve that problem.
However, what I'm fundamentally opposed to is when basic interaction in a network
or between a computing device and its peripherals depends on extensive
userspace dependencies. Now you might argue that ipsec needs a userspace
keying daemon, that routing protocols need a routing daemon, and 802.1x or WPA
need a userspace daemon, too. This is not the point. There are very valid
technical reasons for doing so, and nobody really proposes that such things
should move into the kernel. Also, none of the above-mentioned programs have
requirements on other userspace components aside from glibc or maybe some
netlink specific library.
Bluetooth however now requires dbus. At least it is almost impossible to do
without. I have tried for neverending hours and didn't make it work. Others
apparently have similar problems.
If people want to [d]bus-enable their kernel-related tools, let them do it.
But please make it optional and don't depend on it. This is just not how
things are done in the Linux kernel world until now, and I don't think there
has been any debate on whether we really want such a paradigm change yet..
proprietary MiFARE [in]security finally falling
presentation entitled "Mifare - Little security, despite obscurity" at the
24C3, Henryk Ploetz and Karsten
Nohl presented about their revelations of the proprietary Philips MiFARE classic
As everyone in the IT industry suspected, the level of security provided by such a
cheap, low-gate and completely undisclosed system is in fact very limited.
I'm particularly proud that this security research is exactly what Milosch and
me originally wanted to enable by creating the OpenPCD and OpenPICC project. We wanted to put
easier accessible and open, documented tools for low-level access to 13.56MHz
With a bit of luck, at some point in 2008, it should once again become clear that
security by obscurity doesn't work. This lesson seems to be well-understood in
the Internet world, but apparently has little penetration into the RFID sphere
so far. There are still many proprietary systems whose security relies solely on
the secrecy. Once a single person reveals that secret, the system is broken.
I can only hardly imagine the amount of economic damage imposed by the
perpetrators of such systems. There are a couple of hundred million MiFARE
classic tags on this planet, particularly in public transport ticketing and
access control. The vendors of such systems should be blamed for their false
claims. And anyone who bought it should be blamed for their blind belief in
the claims of profit-oriented corporations without any independent validation