I'm a long time Python user (since 1994) and fan, and lately I've been trying to catch up on some of the many changes the language have been going through. I must say, pretty much everything they have changed or added since the old 1.x days are awesome! As if Python wasn't a great language already, it's shaping up to be a very strong contender indeed.

If you haven't looked at Python lately, take a quick look at the following "summaries" of changes that's been made in recent years:

• What's new in python 2.0
• What's new in Python 2.1
• What's new in Python 2.2
• What's new in Python 2.3
• What's new in Python 2.4
• What's new in the next Python
• Python PEPs

Anyways, last week I was playing with the super() function, to clean up some old code which used the old style calling conventions for accessing the super class members. This new built-in function was added to Python 2.2, to better support the new multiple inheritance lookup rules (see above). The following example shows the two different styles (but read the docs above for more in depth analysis why using super() is useful):

class Foo(BaseFoo):
    def __init__(self, arg1, arg2):
        BaseFoo.__init__(self, arg1, arg2)
        ...

class Bar(BaseBar):
    def __init__(self, arg1, arg2):
        super(Bar, self).__init__(arg1, arg2)
        ...

This worked most of the time in my code, except when I tried to sub-class some old-style classes, for instance:

from HTMLParser import HTMLParser, HTMLParseError

class HTMLImageParser(HTMLParser):
    def __init__(self, callback=None):
        super(HTMLImageParser, self).__init__()
        ....

This would generate an error like:

TypeError: super() argument 1 must be type, not classobj

The simple solution was to change my sub-class to also be a sub-class of the object class, making it a new-style class:

class HTMLImageParser(HTMLParser, object):
    def __init__(self, callback=None):
        super(HTMLImageParser, self).__init__()
        ...

Project goal

Clients and TLS vs SSL-only

The SMTP server for "Ogre" does not recognize any of the authentication
methods supported by Entourage. To send mail, try disabling SMTP
authentication in the account settings or talk to your administrator.

An unknown error (5530) occurred

Security failure. Personal certificate required.

Rebuilding sendmail with SASL support

APPENDDEF(`confENVDEF', `-DSASL=2 -DSTARTTLS')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2 -lssl -lcrypto')
APPENDDEF(`confLIBDIRS', `-L/usr/local/lib -R/usr/local/lib')
APPENDDEF(`confINCDIRS', `-I/usr/local/include')

APPENDDEF(`conf_sendmail_ENVDEF', `-D_FFR_SMTP_SSL')

SSL certificates

Reconfigure sendmail

define(`confCACERT_PATH',`/usr/local/SSL/private')dnl
define(`confCACERT',`/usr/local/SSL/private/CAcert.pem')dnl
define(`confSERVER_CERT',`/usr/local/SSL/certs/sendmail-cert.pem')dnl
define(`confSERVER_KEY',`/usr/local/SSL/certs/sendmail-key.pem')dnl

define(`confAUTH_MECHANISMS',`LOGIN PLAIN')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN)dnl
define(`confDONT_BLAME_SENDMAIL', `GroupReadableSASLDBFile')dnl

DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
DAEMON_OPTIONS(`Port=465, Name=SSA, M=Eas')dnl
define(`confAUTH_OPTIONS', `A,p,y')dnl

define(`confTLS_SRV_OPTIONS',`V')dnl

Conclusions

Credits

So, for the second or third time, I read on Slashdot about people complaining about the "serious security" problems with MacOSX. I finally couldn't stop myself from posting to one of these discussions, not because I'm a Macintosh fan, but because I find it prepostoreous to even call this a bug.

As far as I'm concerned, Apple has implemented their solutions as per specifications. They probably could have made better documentation, GUI/tools and training around the well known security issues around DHCP in general, and the LDAP option in particular. And arguably, using DHCP with the LDAP option like they did might have been a poor design decision, but it was no less secure than their previous systems afaik (e.g. Netinfo).

I first posted this response to the latest /. article:

I still don't understand why this security "hole" got so much attention... Are people struggling
to find problems with MacOSX? First of all, attacks like this is nothing new, just remember the
old YP/NIS problems with broadcasting for the server, to mention just one example.

Secondly, when we wrote the DHCP LDAP option specs way back when, we explicitly
documented this problem in the security section:

    5. Security considerations

    Security considerations discussed in [3], particularly with respect to the
    provision of authentication information, are directly applicable here.
    Additionally, it should be noted that providing LDAP server information by
    a broadcast protocol such as DHCP may allow unauthorized clients to learn
    the location of and authentication information for LDAP servers and hence
    pose as valid clients. This presents a security problem when sensitive
    information, such as user passwords, is published via LDAP servers.

    The DHCP protocol provides no mechanisms for the client to verify the
    validity and correctness of the received information. The security
    considerations in [1] discuss several weaknesses, particularly the problem
    with unauthorized DHCP servers.

This was written in 1997, note the last paragraph above. These issues have been discusses
and documented in several RFCs, many years ago...

Someone posted a question asking if this was a MacOSX specific problem, to which I responded:

Well, DHCP is inherently insecure, so this is definitely not a MacOSX specific "bug" (but I
personally don't consider it a bug). This is all well documented in the DHCP RFCs and docs,
e.g. from RFC 2131:

    7. Security Considerations

          DHCP is built directly on UDP and IP which are as yet inherently
          insecure. Furthermore, DHCP is generally intended to make
          maintenance of remote and/or diskless hosts easier. While perhaps
          not impossible, configuring such hosts with passwords or keys may be
          difficult and inconvenient. Therefore, DHCP in its current form is
          quite insecure.

          Unauthorized DHCP servers may be easily set up. Such servers can
          then send false and potentially disruptive information to clients
          such as incorrect or duplicate IP addresses, incorrect routing
          information (including spoof routers, etc.), incorrect domain
          nameserver addresses (such as spoof nameservers), and so on.
          Clearly, once this seed information is in place, an attacker can
          further compromise affected systems.

          Malicious DHCP clients could masquerade as legitimate clients and
          retrieve information intended for those legitimate clients. Where
          dynamic allocation of resources is used, a malicious client could
          claim all resources for itself, thereby denying resources to
          legitimate clients.

I think what makes MacOSX "unique" is that they use services traditionally not provided by DHCP (in this case, LDAP server information). Just like with NIS/YP, we have a tradeoff between ease of deployment (automatic service discovery) vs strong security. I know for a fact that way back, many YP/NIS deployments got hacked (in open networks, most commonly Universities) by simply pretending to be an NIS server. NIS+ addressed this problem (and others), and made it close to impossible to deploy and maintain. :-)

I don't know what Apple will do to "secure" this, the natural solution seems to be to have the DHCP client limit which servers it will talk to (establish a trust relation). It could be done with something as simple as a DHCP server host list, or more likely using Kerberos tickets to verify the authenticity of the DHCP response (I'm no Kerberos expert, so don't quote me on that one). More than likely, it'll make deployment a bit harder that what it is now.

Nothing new about this at all....

Some readers might know that one of my pet peeves is Spam. I've spent so much time trying to fight spam, and I'm actually "winning" right now. It is a constant battle though, as spammers adapt to new (and old) anti-spam tools, and I have to constantly update and tune my systems.

I guess one of these days I should write something about what I do for anti-spam, I just haven't had the time. I do run a number of different toolkits together, which has turned out to be very effective. A few months ago I added a Bayesian filter system, which even though it is effective, is incredibly painful to maintain. I'm also thinking of adding RBL to my systems, assuming they let me use it for free. :-)

I'm working on a tool to let me manage the learning through IMAP clients (e.g. Mozilla), more or less automatically. I'll post more on that when I get closer to release. (And yes, I know there are similar tools out there already, but I need something that's 100% server side).

Oh, and for what it's worth, I'm currently catching 10k spam / month / user on my system, and that's not counting spam/virus that are rejected immediately at the MTA layer. That'd add up to well over 100k spam / year for one person, it's just insane. For me personally, spam is over 75% of my incoming mail, and I'm on a lot of fairly large mailing lists...

Stop spam

---
UPDATE!

This seems to have been resolved in the latest vmware "fix" package from Petr (v44), see more info in this Bugzilla bug.
---
UPDATE #2!
I think they removed this compile option again from the unofficial 2.6 builds, maybe because it broke other binary only kernel modules (like nVidia)? But the nVidia drivers are still broken, since the new CONFIG_X86_4G_VM_LAYOUT is used. More information on the nVidia for 2.6 site.
---
So, I've been tooling around using the 2.6 RPMs provided by some nice fellow at RedHat . I simply followed the instructions from Thomer M. Gil. It was suprisingly easy to get my ))RedHat 9(( system upgraded to 2.6 using these RPMs and instructions.

This all worked nice and well up until (I think) test-8. After this release, I could no longer get VMWare to run, even after applying Petr's patches. Reading the News group for running VMWare on "experimental plaforms", I found this comment from Petr:

^''linux-2.6.0-compile.patch in Arjan's kernel is responsible for that. It adds __-mregparm=3__ to the CFLAGS, completely breaking ABI: functions do not expect arguments on the stack, but in registers (and so misc_register() uses leftover 165 value in EAX as a miscdevice pointer...).''^

I've been playing around a bit with the latest "unstable" Ximian Gnome packages, with mixed results. Most disturbing, my Emacs settings got completely whacky. My colors were all changed, fonts weren't right, and many other of my custom settings were being ignored. After some annoying debugging, I realized Gnome was now setting some X11 resources, which obviously affected my Emacs run-time.

The offending file (at least for me), turned out to be:

/usr/share/control-center-2.0/xrdb/Emacs.ad

which is part of the control-center package. Simply removing this file, and restarting Gnome/X11 solved all my Emacs problems, since the conflicting X11 resources are now gone. I have no idea why this file was put in there... I control all my Emacs settings through E-lisp, thank you very much, and X11 resources should be avoided when possible IMO. :-)

Introduction

00:1f.5 Multimedia audio controller: Intel Corp. 82801EB AC'97 Audio (rev 02)
       Subsystem: ABIT Computer Corp.: Unknown device 1022
       Flags: bus master, medium devsel, latency 0, IRQ 17
       I/O ports at d400 [size=256]
       I/O ports at d800 [size=64]
       Memory at fc002000 (32-bit, non-prefetchable) [size=512]
       Memory at fc003000 (32-bit, non-prefetchable) [size=256]
       Capabilities: [50] Power Management version 2

ALSA to the rescue!

kernel-smp-module-alsa-0.9.6-1.fr_2.4.20_20.9
gnome-alsamixer-0.9.3-fr1
alsaplayer-0.99.75-fr1
alsa-lib-0.9.6-1.fr
alsa-utils-0.9.6-1.fr
xmms-alsa-0.9.12-1.fr
alsa-driver-0.9.6-1.fr

Could this work with the ABIT IC7?

root # alsactl store

alias sound-slot-0 snd-intel8x0
post-install snd-slot-0 /usr/sbin/alsactl restore >/dev/null 2>&1 || : 

But what about the Gnomes?

alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

Conclusions

Updates and user feedback

11/22/2003: XMMS and ESD

 esd -d /dev/dsp