Bughunting is fun
Two reasons:
- 'foo FTBFS on m68k' is not RC. 'foo FTBFS on m68k because it segfaults during the build since it does bar and baz, which just happens to result in a segfault on m68k at startup but might randomly result in a segfault on every architecture, really' in most cases is.
- It, well, is just fun to debug someone else's code. On m68k, it's easy to do that, too, if you know a bit of assembly language.
Today's (and last week's) bug: #497262. Xemacs21 segfaults at startup on m68k (and FTBFSes because of that), which is RC for m68k. Reason: confusion between a pointer and its value. In other words: the sanity check might succeed, or it might not, depending on your luck. In fact, the first time the code flows through this buggy path, it does not bomb. Once we do get through this bit, it's also very likely that regular error handling will catch it—the only reason why xemacs segfaults here is because we're still in initialization, and the error object in the lisp stuff hasn't been initialized yet, so we get a nice null pointer dereference...
That alone isn't enough to make it RC everywhere, but it's good enough to make it important and fixable for the maintainer. Like I said, fun.
Sorry for those of you who want to release Lenny ASAP, but I think I'll be making your life a bit harder :->
Next week's bug: a similar issue in emacs, or the build failure of ghc6 on m68k, depending on time and complexity.
Octocores are fun
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND 26205 wouter 20 0 21208 3940 2264 R 100 0.1 6:39.38 4 povray 26220 wouter 20 0 21204 3988 2264 R 100 0.1 6:39.54 6 povray 26222 wouter 20 0 21208 3960 2264 R 100 0.1 6:39.29 5 povray 26223 wouter 20 0 21208 3948 2264 R 100 0.1 6:39.29 7 povray 26214 wouter 20 0 21212 4008 2264 R 100 0.1 6:39.02 3 povray 26224 wouter 20 0 21204 3924 2264 R 100 0.1 6:39.28 2 povray
Generating some test clips for a project at work...
Philip,
Sometimes you're just flat out wrong.
While I can understand your position of 'all fear-mongerers and religious fanatics should just commit suicide', I do not agree with it. However, this time, the girl you refer to didn't actually commit suicide because she fell in any of those categories.
Had you actually read that BBC story you link to in some detail, you'd have found that:
- The girl was sixteen years old. While old enough to understand danger, it usually isn't old enough to understand the intricacies of science.
- She took her own life after watching a sensationalist TV channel that was spreading the lie that the LHC would cause the earth to crack up
Now I agree that ignorance to science is something that should be advocated against; but if the facts of science are misrepresented through a TV channel that is only interested in its own profits, are those who do believe their only source of information then to be blamed? If the only data you get are outright lies, is the world then indeed a better place because it got rid of one "mis"believer?
I think not.
Why I don't want an iSomething
QOTD:
iPhone 2.1 OS. OMG - it's just like the old days. I can scroll through the address book, sync with iTunes. Love You, Apple
If people have to be excited because they can scroll in their address book, that's pretty pathetic.
I'll have Free Software any day, thank you very much. Even if that means having something rough-edged, like the Neo Freerunner, which isn't even remotely ready.
Worst. Error. Ever.
ldaphost:~# slapadd < ldapdump slapadd: bad configuration file! ldaphost:~# man slapadd ldaphost:~# slapadd -v < ldapdump slapadd: bad configuration file!
Helping users? You gotta be kidding me.
SSL "telnet"
A common way to debug a network server is to use 'telnet' or 'nc' to connect to the server and issue some commands in the protocol to verify whether everything is working correctly. That obviously only works for ASCII protocols (as opposed to binary protocols), and it obviously also only works if you're not using any encryption.
But that doesn't mean you can't test an encrypted protocol in a similar way, thanks to openssl's s_client:
wouter@country:~$ openssl s_client -host samba.grep.be -port 443
CONNECTED(00000003)
depth=0 /C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=svn.grep.be/emailAddress=wouter@grep.be
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=svn.grep.be/emailAddress=wouter@grep.be
verify return:1
---
Certificate chain
0 s:/C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=svn.grep.be/emailAddress=wouter@grep.be
i:/C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=svn.grep.be/emailAddress=wouter@grep.be
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDXDCCAsWgAwIBAgIJAITRhiXp+37JMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNV
BAYTAkJFMRAwDgYDVQQIEwdBbnR3ZXJwMREwDwYDVQQHEwhNZWNoZWxlbjEUMBIG
A1UEChMLTml4U3lzIEJWQkExFDASBgNVBAMTC3N2bi5ncmVwLmJlMR0wGwYJKoZI
hvcNAQkBFg53b3V0ZXJAZ3JlcC5iZTAeFw0wNTA1MjEwOTMwMDFaFw0xNTA1MTkw
OTMwMDFaMH0xCzAJBgNVBAYTAkJFMRAwDgYDVQQIEwdBbnR3ZXJwMREwDwYDVQQH
EwhNZWNoZWxlbjEUMBIGA1UEChMLTml4U3lzIEJWQkExFDASBgNVBAMTC3N2bi5n
cmVwLmJlMR0wGwYJKoZIhvcNAQkBFg53b3V0ZXJAZ3JlcC5iZTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAsGTECq0VXyw09Zcg/OBijP1LALMh9InyU0Ebe2HH
NEQ605mfyjAENG8rKxrjOQyZzD25K5Oh56/F+clMNtKAfs6OuA2NygD1/y4w7Gcq
1kXhsM1MOIOBdtXAFi9s9i5ZATAgmDRIzuKZ6c2YJxJfyVbU+Pthr6L1SFftEdfb
L7MCAwEAAaOB4zCB4DAdBgNVHQ4EFgQUtUK7aapBDaCoSFRWTf1wRauCmdowgbAG
A1UdIwSBqDCBpYAUtUK7aapBDaCoSFRWTf1wRauCmdqhgYGkfzB9MQswCQYDVQQG
EwJCRTEQMA4GA1UECBMHQW50d2VycDERMA8GA1UEBxMITWVjaGVsZW4xFDASBgNV
BAoTC05peFN5cyBCVkJBMRQwEgYDVQQDEwtzdm4uZ3JlcC5iZTEdMBsGCSqGSIb3
DQEJARYOd291dGVyQGdyZXAuYmWCCQCE0YYl6ft+yTAMBgNVHRMEBTADAQH/MA0G
CSqGSIb3DQEBBQUAA4GBADGkLc+CWWbfpBpY2+Pmknsz01CK8P5qCX3XBt4OtZLZ
NYKdrqleYq7r7H8PHJbTTiGOv9L56B84QPGwAzGxw/GzblrqR67iIo8e5reGbvXl
s1TFqKyvoXy9LJoGecMwjznAEulw9cYcFz+VuV5xnYPyJMLWk4Bo9WCVKGuAqVdw
-----END CERTIFICATE-----
subject=/C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=svn.grep.be/emailAddress=wouter@grep.be
issuer=/C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=svn.grep.be/emailAddress=wouter@grep.be
---
No client certificate CA names sent
---
SSL handshake has read 1428 bytes and written 316 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 65E69139622D06B9D284AEDFBFC1969FE14E826FAD01FB45E51F1020B4CEA42C
Session-ID-ctx:
Master-Key: 606553D558AF15491FEF6FD1A523E16D2E40A8A005A358DF9A756A21FC05DFAF2C9985ABE109DCD29DD5D77BE6BC5C4F
Key-Arg : None
Start Time: 1222001082
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
HEAD / HTTP/1.1
Host: svn.grep.be
User-Agent: openssl s_client
Connection: close
HTTP/1.1 404 Not Found
Date: Sun, 21 Sep 2008 12:44:55 GMT
Server: Apache/2.2.3 (Debian) mod_auth_kerb/5.3 DAV/2 SVN/1.4.2 PHP/5.2.0-8+etch11 mod_ssl/2.2.3 OpenSSL/0.9.8c
Connection: close
Content-Type: text/html; charset=iso-8859-1
closed
wouter@country:~$
As you can see, we connect to an HTTPS server, get to see what the server's certificate looks like, issue some commands, and the server responds properly. It also works for (some) protocols who work in a STARTTLS kind of way:
wouter@country:~$ openssl s_client -host samba.grep.be -port 587 -starttls smtp
CONNECTED(00000003)
depth=0 /C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=samba.grep.be
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=samba.grep.be
verify return:1
---
Certificate chain
0 s:/C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=samba.grep.be
i:/C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=samba.grep.be
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDBDCCAm2gAwIBAgIJAK53w+1YhWocMA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNV
BAYTAkJFMRAwDgYDVQQIEwdBbnR3ZXJwMREwDwYDVQQHEwhNZWNoZWxlbjEUMBIG
A1UEChMLTml4U3lzIEJWQkExFjAUBgNVBAMTDXNhbWJhLmdyZXAuYmUwHhcNMDgw
OTIwMTYyMjI3WhcNMDkwOTIwMTYyMjI3WjBgMQswCQYDVQQGEwJCRTEQMA4GA1UE
CBMHQW50d2VycDERMA8GA1UEBxMITWVjaGVsZW4xFDASBgNVBAoTC05peFN5cyBC
VkJBMRYwFAYDVQQDEw1zYW1iYS5ncmVwLmJlMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCee+Ibci3atTgoJqUU7cK13oD/E1IV2lKcvdviJBtr4rd1aRWfxcvD
PS00jRXGJ9AAM+EO2iuZv0Z5NFQkcF3Yia0yj6hvjQvlev1OWxaWuvWhRRLV/013
JL8cIrKYrlHqgHow60cgUt7kfSxq9kjkMTWLsGdqlE+Q7eelMN94tQIDAQABo4HF
MIHCMB0GA1UdDgQWBBT9N54b/zoiUNl2GnWYbDf6YeixgTCBkgYDVR0jBIGKMIGH
gBT9N54b/zoiUNl2GnWYbDf6YeixgaFkpGIwYDELMAkGA1UEBhMCQkUxEDAOBgNV
BAgTB0FudHdlcnAxETAPBgNVBAcTCE1lY2hlbGVuMRQwEgYDVQQKEwtOaXhTeXMg
QlZCQTEWMBQGA1UEAxMNc2FtYmEuZ3JlcC5iZYIJAK53w+1YhWocMAwGA1UdEwQF
MAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAAnMdbAgLRJ3xWOBlqNjLDzGWAEzOJUHo
5R9ljMFPwt1WdjRy7L96ETdc0AquQsW31AJsDJDf+Ls4zka+++DrVWk4kCOC0FOO
40ar0WUfdOtuusdIFLDfHJgbzp0mBu125VBZ651Db99IX+0BuJLdtb8fz2LOOe8b
eN7obSZTguM=
-----END CERTIFICATE-----
subject=/C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=samba.grep.be
issuer=/C=BE/ST=Antwerp/L=Mechelen/O=NixSys BVBA/CN=samba.grep.be
---
No client certificate CA names sent
---
SSL handshake has read 1707 bytes and written 351 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 6D28368494A3879054143C7C6B926C9BDCDBA20F1E099BF4BA7E76FCF357FD55
Session-ID-ctx:
Master-Key: B246EA50357EAA6C335B50B67AE8CE41635EBCA6EFF7EFCE082225C4EFF5CFBB2E50C07D8320E0EFCBFABDCDF8A9A851
Key-Arg : None
Start Time: 1222000892
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
250 HELP
quit
221 samba.grep.be closing connection
closed
wouter@country:~$
OpenSSL here connects to the server, issues a proper EHLO command, does STARTTLS, and then gives me the same data as it did for the HTTPS connection.
Isn't that nice.
SSH with Belgian electronic ID card
OpenSSH can be compiled against OpenSC. Since the latter has support for the Belgian electronic ID card, that means you can use your eID card to log on to a remote server using OpenSSH. To do this is fairly simple, once you know how it works.
First, obviously, you need to have ssh compiled against opensc. Unfortunately, the Debian package comes with that option disabled, but it's easy to enable that:
sudo apt-get build-dep openssh sudo apt-get source openssh cd openssh-* $EDITOR debian/rules
Find the "Common build options", and add another line:
confflags += --with-opensc=/usr
Now add another changelog entry, so that your next apt-get upgrade won't overwrite your locally-modified SSH package:
dch -i
Next, build and install the package:
dpkg-buildpackage -rfakeroot -b -uc -us cd .. sudo dpkg -i openssh-client*
You now have an OpenSSH that can access smartcards. So, how do you use it to log on to a remote system? Simple:
pkcs15-tool -c ssh-keygen -D 0
The first command will tell you the order of the certificates on the card. In my case, the Authentication certificate is first, while the Signature certificate is second. You do not want the Signature certificate; you only want the Authentication certificate.
The second command will output the RSA public keys that are on the smartcard in both SSH1 and SSH2 format, in the same order as in the pkcs15-tool output. You only want the SSH2 version, and you only want to get the Authentication key. That key needs to be added to your ~/.ssh/authorized_keys on the remote host. Note that the '0' assumes that your smartcard is in slot 0; if that doesn't work, 'pkcs11-tool -L' should tell you which slot you need.
After we've done this, we're ready to start using the smartcard to log in. While ssh-add has an option to load keys from a smartcard, this only works with smartcards that allow one to download the private key from the smartcard into the computer's RAM. This is not possible with the eID (and for good reason), so you can't use ssh-agent with your eID card. However, you don't really need it.
beid-pkcs11-tool -l -t
This will log in to the Authentication key on the smartcard (note that while it is possible to log in to the Authentication key, it is not possible to do the same with the Signature key). You will get the familiar belpic login window now, and the smartcard will now allow use of the private key. In order to actually use this key, you need to specify one extra option to ssh:
ssh -I 0
The -I option instructs SSH to use a smartcard key as a private key. Since we're already logged in to the smartcard, we do not need to enter a PIN code (and regardless, SSH does not know how to do that). You will now be logged on to the server.
Note that there is no way to 'log out' of a smartcard; the proper way to do that is to remove your card from the cardreader...
Autoconf: sigh
wouter@country:~/nbd-2.9.11$ ./configure --host=m68k-linux --build=powerpc-linux [...] checking for m68k-linux-gcc... no checking for gcc... gcc [...] wouter@country:~/nbd-2.9.11$ ./configure --host=m68k-linux-gnu --build=powerpc-linux [...] checking for m68k-linux-gnu-gcc... m68k-linux-gnu-gcc [...]
So why do we have config.sub again?