Re:
I recently (some of it during debconf, some of it right after) blogged a few things that are, shall we say, controversial. Obviously I got some response to that. Since I haven't replied individually to most of those replies, I thought a new blog post would work well.
On my very short and rather unconstructingly hateful post about gnome-keyring, JanC wrote:
I can understand why you would get popups from seahorse-agent if you use that, but if ssh gives you popups from gnome-keyring, that sounds like something is misconfigured to me?
BTW: it's easy to configure things in such a way that seahorse-agent doesn't get used inside a terminal; it's just another ssh-agent after all...
Well, presumably. But I didn't do it.
wouter@celtic:~/data/blog/live/en/computer$ sudo dpkg-divert --list|grep gnome Password: local diversion of /usr/bin/gnome-power-manager to /usr/bin/gnome-power-manager-sucks local diversion of /usr/bin/gnome-keyring-daemon to /usr/bin/g-k-sucks wouter@celtic:~/data/blog/live/en/computer$ svn up ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success ** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success At revision 1086. wouter@celtic:~/data/blog/live/en/computer$
Note particularly the fact that the login works perfectly okay right after whatever causes this finally gives up trying to call gnome-keyring, and svn finds the authentication info in its config file (this is my blog. Not as if there's anything of serious security there; those repositories that are important are behind SSH)
I never even asked anything to run gnome-keyring-daemon; but if I allow svn to do its thing without asking, this is what happens. I don't have libpam-gnome-keyring installed, and I'm no longer running gdm; two sources of things that run gnome-keyring-daemon without my asking. Yet the bloody thing keeps cropping up everywhere I look. It is broken, and it should not exist. Thank god for dpkg-divert.
On my post about MS and the GPL, some people wrote that Microsoft only published the code for GPL compliancy, not because they thought it a good idea or some such.
While this might be true, the fact of the matter is that, unlike many many many other companies out there, they decided to not just put a blob of code on their website and be done with it, but instead to do the right thing, and get the code merged. That is far beyond what the GPL requires them to do, and it signals to me that they did this because they are changing—the Microsoft of 10 years ago wouldn't even have written those drivers in the first place, let alone get them merged. That, I think, was the most important point of that post.
On my post about passwords, Matthew Johnson wrote:
An SSH key is very much not just "a password written down". Passwords are sent in the clear (inside the tunnel) and are therefore more subject to MITM attacks, keyloggers, etc. SSH keys, because of the asymmetric crypto, if you do manage an MITM attack using an SSH key does not reveal anything which could be used to authenticate another time.
Good point; I overlooked that. Yes, that does make passwords somewhat less secure, and defeats most of what I said. However, it does not defeat the fact that allowing only one way to login increases the chance that you will require some people to jump through hoops—me, I do not keep my SSH keys on my laptop's hard disk, so they don't get compromised should the laptop ever get stolen. That does make it harder for me to log on to a system using these keys, however, and it makes me consider generating a separate SSH key that I will keep on my laptop, just for Debian.org hosts. I need to log in to some of them far too often.
On that latter post about buildd maintenance, I received a response from Riku about how he feels using tr on the client-side is wrong, and how I should instead have patched buildd-mail instead to decode MIME encodings.
Technically, he's right. Practically, he's not. When I wrote this script, it was far easier to fix the problem once, on my side of the equation, rather than every time I install or upgrade buildd. At the time, the code was in a repository that only Ryan had commit access to, and as a result most people kept patches locally. I should still have a patch lying around somewhere that has the same effect as the one that got committed, but gave up trying to use it, as in my ever-changing set of buildd hosts, one would creep up again and again that did not have the patch applied, because it was recently reinstalled after a dead disk, or because buildd was upgraded, or some such, meaning that signatures would fail and I would have a shitload of unnecessary manual work. In such a context, writing code on my client side—in casu 21 characters—is far easier than trying to fix the code centrally.