You can only really expire cookies on the server
(Every so often I feel like stating outright something that I havepreviously mentioned in asides in other entries. Today is one of thosetimes.)
Here is an important corollary of the basic rule of website security : if you want your cookies to expire you mustforce them to expire on the server, not count on web browsers to expirethem for you. Neither using session cookies norputting an explicit expiry time on your non-session cookies willactually make your cookies expire if the user doesn't want them
How I should have done password crypto for DWiki
DWiki (the software behind WanderingThoughts ) uses cryptography for thetraditional web application things, namely login passwords and logincookies; it stores hashed versions of login passwords, and it signs itslogin cookies. I had very little idea what I was doing when I wrote thatcode, so DWiki 's current use of cryptography is better off not discussedin polite company; instead, let's discuss how it should work.
(I was so stupid that I didn't use HMAC, despite it being in thePython
A Python safety tip: Do notice that things can throw exceptions
Recently, I discovered and fixed a long-standing bug in DWiki . Thebug itself was simple, but typical of a certain kind of error thatI keep making in Python: I had forgotten that the Cookie module could throw an exception,so I didn't catch it.
(Well, my general error code logged it, but I mean DWiki itself didn't catch it and do anything sensible; in this case,either ignoring the broken HTTP cookie header or perhaps reporting asecurity error.)
This
Three ways to get tracebacks in your CGI Python application
There are at least four ways to get Python tracebacks in your CGI orweb-app in case something goes wrong; the easy but wrong way, the moreor less right but inconvenient way, the flawed way, and the good way.
The easy but wrong way is ' import cgitb; cgitb.enable() '. Thereason this is the wrong way (except when you yourself are developingyour program) is that this dumps error tracebacks on the usersof your application. Ignoring any information disclosure issues,
The argument for not managing systems via packages
Although I haven't changed my mind ingeneral, I think that there are arguments for configuration managementsystems like Cfengine and Puppet over packaging systems. Apart fromtheir actual existence in usable form, one of them is that CM systemsare going to be inherently more agile than packaging systems.
The drawback of packaging systems is that they fundamentally work onpackages. This means that doing things via them requires a multi-stepprocess; you must assemble your files, build one or more packages fromthem, and finally propagate
One of the things that killed network computers (aka thin clients)
Here is a thesis about network computing's lack of success:
The compute power to deliver your applications has to live somewhere,whether that is in the machine in front of you or on a server that sitsin a machine room somewhere. It turns out that the cost of deliveringcompute power in one box does not scale linearly; at various points, itturns up sharply. For various reasons, there is also a minimum amount ofcomputing power that gets delivered in boxes; it is generally impossibleto obtain a
OpenSolaris versus Solaris
Discussions about Solaris often wind up bringing up OpenSolaris (andsometimes it crops up in other contexts). However, I do not findOpenSolaris particularly interesting.
My view is that right now, OpenSolaris is essentially a technologydemonstrator. You can't use OpenSolaris by itself, because it lackssufficient support to use it directly and sufficient genuine opennessfor sensible people to base stable things on it. You can't use it as thefuture of Solaris, because I'm not aware of any commitment from Sun that
More on mismatched sectors on Linux software RAID mirrors
Some brief followups from my first entry on this.
First, the mismatch_cnt numbers are reset from scratch everytime you re-run a check (and probably every time there is a mirrorresync). On many current systems, this means that they will be resetevery week. This makes sense and is even implied by the documentation (in the usual Unixfashion of reading between the lines),but it would have been nice to have it explicitly documented.
(I'm aware that I'm
I do not like Unix's fossilization
I like Unix, but I'm not entirely happy with the modern world of Unix,and not for the reason you might expect. Instead of disliking thechanges from the old days, I find it distressing to see Unix slowlyfossilize.
Unix should be picking up new good ideas. It should be adopting betterways of writing shell scripts, adding more little programs,and all of that. Yes, things like seq and (GNU) stat and (GNU) date and time are not in the Posix specification
Different visions of what packaging systems are for
I think I should write down one of my background views on what packagingsystems are for, and what jobs they do, because there are competing (orsomewhat clashing) visions about what is within their scope.
One view is that the job of a packaging system is more or less confinedto properly installing, removing, and upgrading packages. This need notexclude things like apt-get ; if you take a broad view of 'installingpackages', this can easily include fetching packages and dependenciesover the Internet.