In the past I was not blogging small things if they were not worth a full blog entry on their own (or if I did not have the time to make up a full entry of it :). Inspired by the example of Raphaël Hertzog <hertzog@debian.org> with "News for Debian developers" for <debian-devel-announce@lists.debian.org>, I am intending to do the same on a monthly basis about my own Debian related work. This first entry about January 2008 also covers a few things from the last month of 2007. General News

• Trusted Computing
  
  After having taken over some rotting ITP bugs, Debian has now all the important packages to support Trusted Computing on platforms containing a TPM chip. The packages are not in good enough quality for release, but there is still some time left to fix that. Looking forward to make lenny supporting TPM properly out of the box, as well as aiming for making Debian the best TPM enabled distribution available.
  
  Currently, the TSS software stack consists of trousers, tpm-tools, opencryptoki, libengine-tpm-openssl, and ecryptfs-utils.
  
  
• Smartcards
  
  I am using smartcards since a while to hold GnuPG, LUKS, and OpenSSL keys/certificates. Thanks to Jonas Meurer <mejo@debian.org> for applying a fix and a patch of mine to cryptsetup. Together with my uploads of gnupg-pkcs11-scd, pam-pkcs11 and pcsc-omnikey, I can now use Debian out of the box with smartcards for authentification, not relaying on patched or private packages anymore.
  
  The next aim is to integrate smartcard support into debian-installer. It should be possible to use/store keys or certificates for encrypted filesystems directly from/to a smartcard during installation time.
  

Package News

• botan-devel
  
  The Botan library is maintained upstream in a stable release branch and a development release branch. Before, I was uploading as versioned source packages, botan1.4 and botan1.5. To be a bit more consistent, the two source packages are named botan and botan-devel now.
  
  
• gitosis
  
  Tommi Virtanen <tv@eagain.net> has written a marvelous tool to securely manage hosted git repositories, named gitosis. Having always looked for an elegant sollution to maintain git repositories through push/pull over SSH only, this package made an excellent addition to the Debian archive.
  
  
• gnunet
  
  GNUnet, more precisely the gnunet, gnunet-gtk and gnunet-qt packages where mainly maintained the last years by Arnaud Kyheng <Arnaud.Kyheng@free.fr> with me playing co-maintainer.
  
  Arnaud has become busy within the last months, so I took over a more active role on its maintenance. Currently, all gnunet related packages are in sync and in its latest upstream version available in the archive. There is even a new sibling, gnunet-fuse.
  
  
• icedove-l10n
  
  After one and a half year of pushing its maintainer without any effect at all, I finally took over the unmaintained icedove-locales package in October 2007. I immediately changed the package to the proper naming scheme (icedove-l10n-*) which was an outstanding issue since August 2006.
  
  In the last weeks, I have added unofficial localizations for Galizian, Nepali and Ukrainian, now supporting 38 localizations in total. Icedove localizations are now in good shape again, always matching the Icedove version and no longer lagging behind.
  
  
• iceowl-l10n
  
  Following iceweasel-l10n and icedove-l10n, there are finally also localizations for iceowl (Mozilla Sunbird) available. Populating packages for iceowl-extension (Mozilla Lightning) from the same source package is a bit trickier package-wise, but will be available soon too.
  
  
• iceweasel-l10n
  
  In September 2007, Robert Milan <rmh@debian.org> on behalf of the Catalan/Valencian Debian translator team asked me to remove the iceweasel-l10n-roa-es-val package. Unfortunately, this localization is related to a long standing cultural and political dispute between the Catalan speaking Spanish people and the City of Valencia. Additionally, the localization itself is of poor quality. Of course, I removed the package in unstable immediately and prepared an upload for stable at the same time.
  
  As usual, me asking something on debian-release results in first beeing ignored, then denied and third, two month after my request, beeing privately asked to upload nevertheless. This is one of the reasons I sometimes fully understand fellow maintainers not carring about stable at all anymore, it has become indeed too much of a hassle.
  
  
• traceroute
  
  For the last decade, Debian was shipping an implementation of traceroute originating from BSD. After I took over the package in late 2006, it became clear to me that Debian should not maintain its very own version of traceroute. Therefore, I replaced traceroute in August 2007 with an implementation from Dmitry K. Butskoy <Dmitry@Butskoy.name>. Apart from the fact, that this modern implementation is better in every way (faster, cleaner, less bugs), it has an active upstream maintainer and is used by different other Linux distributions too.
  
  
• syslinux
  
  Thanks to the work of Robert Milan <rmh@debian.org>, syslinux has now 64-bit CPU detection in unstable (2:3.55-2) and experimental (2:3.60-2) again.
  
  

Team News

• Debian Forensics
  
  Unfortunately, Debian has at the moment very few forensic related packages in the archive.
  
  Christophe Monniez <dfence.242@gmail.com> maintains a lot of forensic related packages on behalf of his Debian based forensic LiveCD. Beeing interested to see them in Debian, I am mentoring him now how to merge them properly into Debian where possible, and maintain them in the official archive. We have formed an Alioth project for this purpose. Packages are maintained in git, everyone is welcome to join.
  
  
• Debian Website
  
  After having offered my help to maintain the Debian Consultants list, I got added to the webwml team. Doing Debian consultancy myself, this is just another way of helping out Debian from time to time by adding, removing and updating some entries of like-minded people in a list.
  
  

I had a couple of annoyances with suspend in my laptop, namely that the screen would not lock prior to suspending (this seems to be #407224), and that sound would not work after resume (this seems to be an ALSA driver bug; muting and unmuting Master and PCM solves the issue). For this latter problem, I just wanted to drop a script somewhere to do the mute/unmute dance on resume automatically, but I was a bit lost as to where to put it. (Or, rather, I thought I’d be a bit lost even if I investigated.) Anyway, I recently moved to pm-utils from powersaved, since that’s what my kpowersave recommends first, and not only now my screen gets locked properly, but there is somewhat clear documentation as to where to put such scripts: /etc/pm/sleep.d. So I now have there a script like:

  case "$1" in
      thaw resume)
          amixer -q sset Master mute
          amixer -q sset Master unmute
          amixer -q sset PCM mute
          amixer -q sset PCM unmute
      ;;
      *)
      ;;
  esac

I only miss one thing: in my old suspend to disk scheme, the computer would change to a console where progress about the operation would be reported. Now it’s just a blank console. Guess it’s time to investigate again. (But overall I’m happy about the move.)

• I've moved packages.ubuntu.com to a new server but until one day ago forgot to tell anyone about that :( The old server will probably go offline today and it might be some time until the IP address gets corrected in DNS and until these changes arrive at your DNS server. Sorry for any inconvienience caused. You can access the new server under the alternate address packages.ubuntu.lichtenheld.net for now.
• I've improved the search code for packages.debian.org a bit to give more usefull results even if the keyword is very generic. Feel free to test the new code at the usual address before I put it online on packages.debian.org. I will wait some days to give the translators a chance to catch up before doing that.
• If you are interested in packages.debian.org development and you will attend FOSDEM, please note that I will give a talk about it there in the Debian DevRoom. I would be glad if someone shows up ;)

I am going to make some suggestions to a company that might possibly sponsor development of free electronic text books for schools (suitable for running on an OLPC machine). I would appreciate any suggestions for things I should include. I will make my suggestions as a blog post summarising all input I receive and send the URL to the company in question.

Share This

Last year at LCA Crispin Cowan suggested to me that I make a joint offer of a combined tutorial on SE Linux and AppArmor as a way of publicly comparing the two technologies. I ended up not accepting the challenge, among other things I had a long-term project going in production in early December that needed some ongoing support. Crispin’s plan B was to just give a lecture about AppArmor. Recently Crispin joined Microsoft [1] and John Johansen of Suse was going to give the talk in his place. The LCA people made a minor mistake by having the conference web site give the description of the tutorial option [2] (which I don’t believe was ever going to happen as I had not accepted the offer), but it’s easy to understand the webmaster copying the wrong description when the one person makes two offers (which I believe is not a common practice). So this morning I and about 150 other people were waiting in the main lecture theatre and no-one from Suse turned up. Being fairly audacious when the announcement was made that the event was officially cancelled I stood up and asked if anyone would like an impromptu talk about SE Linux instead. The audience received that idea quite well. My talk wasn’t as good as I had hoped, not having had a proper breakfast or any caffeinated drinks reduced my mental stack space. So I could talk well on one topic but when questions diverted me to a side topic I found it difficult to remember the previous point I was making. Fortunately when giving an impromptu talk with no notes or presentation materials the audience expectations for a consistent plan of the talk seem reasonably low. ;) I started by talking about my SE Linux Play Machines. Some of that material had been covered in previous talks at other conferences (such as at a previous SE Linux Symposium), but some things (such as my use of Xen) I had not previously covered, but none of it had been mentioned in a talk in Australia for a while. Having given an hour-long talk about SE linux yesterday to an audience with many of the same members I wanted to start by talking about something that they hadn’t heard before, and I was also wearing a Play Machine T-shirt (with the root password printed on it) [4]. After I finished talking about my Play Machines and started covering some of the same material as yesterday about a quarter of the audience left (which was fair enough). I then spoke about general SE Linux issues, largely in response to questions. I covered the differences between the policies (including the history of policy development), the JFFS2 XATTR development (and how SE Linux couldn’t be used on an iPaQ without it), issues of disk space usage for XATTRs for SE Linux labelling on various filesystems and how it drives the use of context mount options, poly-instantiated directories (including some discussion on how the actual storage location for such directories can be on a different filesystem and how this could be convenient when using encrypted filesystems), how Apache/PHP work in a SE Linux environment, and a lot more. I couldn’t resist mentioning to the audience the irony that I had declined a challenge for a joint presentation and then got a sole presenter spot (and a large audience) due to the Suse guy not showing up. For future situations I plan to load lecture notes from all my common talks on my iPaQ. Then next time I have such a speaking opportunity I can give a better prepared talk. Update: It turned out that the LCA people had been informed that the Suse talk was cancelled and had made a mistake, see this link for details.

• [1] http://blogs.msdn.com/michael_howard/archive/2008/01/17/crispin-cowan-joins-the-windows-security-team.aspx


• [2] http://linux.conf.au/programme/detail?TalkID=210


• [3] http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html


• [4] http://www.cafepress.com/play_machine

Share This

On January 26th 2008, the OCaml community has its first meeting in Europe. There was 5 different talks, including one from me. The meeting was pretty constructive and i think some great things should come out of it. In this post, i will focus on the Debian maintainer point of view. The meeting was organized by me, with the help of Garbriel Kerneis and Vincent Balat. I wish to thank Mme Turgis from ENST/ParisTech who has made possible all this to happen. Introduction: I announce the creation of OCamlCore, a SS2L. It will provide commercial support for OCaml and related products. It will also provide community with some resources (including a GForge, a planet, some SCM repository...) For now, i will open administration to Debian people who wish to help (for root rights) and from the whole community for other task (gforge and general administration). For now, i will choose alone who can administrate and who cannot... This is not a very open position, but this server is also for my company. Xavier Leroy give us a nice talk that has let us see some future direction:

• OCaml 3.11 will have native dynlink
• hope to integrate GHC like type system (GADT: Generalized Algebraic Data Types)
• need to work on parallelism, following different paradigm

But above all, Xavier talked about the fact that there is a lack of manpower at INRIA and invited the community to build tools and other things (including a CPAN like distribution) to make the language more widespread. He also stated that a lot of things will stay in place in the name of backward compatibility. OCsigen Vincent Balat has given us a nice talk about OCsigen, a new framework for programming web application. This program is already in Debian and it is at the root of Debian discussion about moving .cm[ao] into libxxx-ocaml package. This new framework allows to program web application using continuation, which should ease a lot of aspect. It also features static type checking, including static verification of the generated HTML pages. GODI I was impressed to see G. Stolpmann coming to the meeting. Unfortunately, i cannot follow the whole talk, since i have some phone call to make, in order to book the restaurant. From what i have seen, it seems that GODI is growing, in term of manpower. They have some issues with OCaml 3.10, because of camlp4 and some packages. At the end of the conference, he was pushing for a more general use of GODIVA. In particular, it requires to have a very uniform way of building software. It should be the foundation of a build standard for OCaml software. In my humble opinion, i don't agree on this point. Basically, its proposal was based on configure/make all, which is too C style way of doing. It is not bad, but just exclude ocamlbuild enabled software. ocamlbuild Nicolas Pouillard has made an introduction on how to use ocamlbuild. I have discovered how it was working, since i didn't have time to work on this topic. It seems a good thing. I hope to be able to try it at some point. The conclusion was about modifying ocamlbuild to allow the use of multiple plugins. For now, the plugin is a separate file which is compiled first and then loaded, as a special case. Nicolas is looking for a full OCaml way to handle this for multiple plugins. OCaml in Debian I have spoken about different aspect of Debian packaging. After a short introduction and some history about OCaml in Debian, I come to some conclusions/problems:

• we have an early integration, which makes Debian handle a lot of packages, but this is due to a long history
• we still are not able to cope with libraries incompatibilities when rebuilding, we only have addressed ocaml package ABI problem
• the debian package management system is not really compliant with the OCaml way of creating libraries, which is our main problem
• native compilation is broken on 3 arches (Xavier Leroy told us that this should be solved for ARM)
• use of Alioth has made us more efficient to integrate packages
• Debian team are working by step: from time to time we begin to integrate a lot of packages, mostly because of some maintainers wishing to integrate a software with a lot of dependencies

Talking with Xavier give me some additional informations:

• ARM is fixed, it should compile with Debian stable on ARM, he explains that the problem is related to the multi ABI flavor of ARM
• he says that we should not have any problem concerning bytecode stripping of executable, if there is still some we should find the OCaml library that triggers this behavior
• I realize that this behavior can be triggered by ocamlmakefile, that still have a "-custom" option
• he promises me that he will send me a simple test to find custom bytecode application (combination of "file X" and a specific string at the end of the file)

At the end of the presentation, there were some questions. I discover that many people are ignoring the ABI problem with OCaml and its libraries. They seem to discover that it requires regular rebuild of our packages. I also have a discussion about the fact that Debian binary distribution doesn't fit developers need. It seems that developers prefer to have the source of libraries they compile and also the most recent release. But at the same time, people avoid using GODI, which also have the problem of needing to wait for a particular library to be released... After some discussion, I point that some companies prefer to live in a frozen world, which Debian stable can provide. Living in a frozen world helps company developers to have the same environment from the beginning to the end of a project - which can last years. It also help to avoid build environment de-synchronization between company developers. There was also a question about interaction between installed OCaml package and GODI software. I cannot answer it, expect with a "patches are welcome". OCaml on a JVM using OCaml-Java Xavier Clerc explained us how he has achieved running a full OCaml environment on a JVM. This work was pretty impressive, because he was able to compile OCaml top level and provide it as an applet. This is something amazing (and working). He stated also that this should allow to do some binding with java graphical user interface from OCaml. I was pretty busy with a phone call (to a restaurant for the dinner), so i don't have attend the whole conference. Anyway, the project is promising, but it needs to recompile every library using its compiler. I think this is not suited for Debian for now. Workshop The workshop was shorter than it should have been. This is due to accumulated time shift during the day. However, it was pretty interesting, because everybody can talked almost freely. The initial discussion was about the "Unicode situation". This was a question about Unicode in Unison, but there is no real solution about it. For reader information, unison has problem with filename containing UTF-8 char. In particular when syncing two directories which are on two file system with a different encoding on each. Even if the file can be represented on the two file systems, the comparison (between UTF-8 and ISO8859-15) fails. This is because the comparison is a byte to byte comparison. We discuss further the idea of OSR (OCaml standard recommendation) which was briefly discussed in the morning. I think David Teller (who have also done a great part of the IRC retranscription) was very keen on this idea. I invited Nicolas Pouillard to discuss the three following subjects. About camlp4 documentation, Nicolas told people about the he set up. About ocamlfind and ocamlbuild, he went back to the multiple plugin problems. About ocamlbuild and GODI, Gerd, Nicolas and Xavier tried to build a list of what metadata can be shared. This includes list of files to be installed (PLIST in GODI). Concerning the "feedback from the Gallium", Xavier explains that he has done this in the morning (which is true). I think that Xavier implicitly agreed on the fact that if this kind of event happens again, he can do another talk about future of OCaml. Concerning Summer of Code, I just remind that people can write description of Google Summer of Code project in the cocan wiki. Another one remind about Jane St Capital summer of code. Points concerning common interfaces raise the discussion about OSR. The organization of next year events doesn't raise particular interest. I think people would be interested to have one next year, if something comes out of this meeting.

As I use Drupal for Czech phpMyAdmin pages, it was only a matter of time till I will have (or want) to add some functionality. My first Drupal module is quite trivial, but anyway I already got positive feedback on it just after committing to Drupal CVS :-). Today I finished little cleanup which my initial version required and I decided to make a first release out of it. And what I'm still talking about? It's a module for adding measuring code for various web auditing systems used in Czechia. I didn't wanted to hack this somehow into templates and module which will provide block with those looks as best solution to me. You can get it on Drupal pages.

Main changes here are including the translations provided by Debian - thanks to all those who submitted po files.
No new functionality in this release - more an incremental improvement in the underlying codebase.
Future plans for QuickList
The 0.9.x series will continue the theme of incremental improvements, but once libqof2 is released, quicklist will begin to use QOF objects that are created dynamically from QuickList data as well as using QOF features like 64bit time and a choice of backends. I expect this to bring with it a SQL-query interface that would allow QuickList to provide a more usable report interface, finally replacing the missing functionality from the old QuickList. The QOF support will be implemented as a "read-only" mode, certainly initially, so that QuickList could read any QOF data source then produce SQL-based reports in HTML on the data. Eventually, this "read-only" mode should be able to handle "integral" data sources like the apt cache or other well-established sources where a suitable C API exists. This would allow any QuickList user to load the apt-cache, select data in any control field of any package using SQL syntax (via a GUI or via direct text entry), format a report in HTML and export that report to a file.
The QOF support would allow the code to support these data sources to be packaged as Glib modules (similar to libqofexpensesobjects0) to keep dependencies under control.
With this kind of support in place, I could finally be ready to release quicklist 1.0.0 sometime after Lenny.
If anyone is interested in any of these ideas, feel free to help with QuickList development.
http://quicklist.sourceforge.net/
Query Object Framework (QOF).

I speculate that most of what we do for Debian squares with what others do for their respective distro. Thus, it should be possible to identify a conceptual workflow applicable to all distros, consolidate individual workflows on a per-package basis, and profit from each other. Jonathan let me have the after-afternoon-coffee slot of the Distro Summit for an impromptu discussion on the various workflows used by distros for packaging. The discussion round was very short-notice and despite the announcement sent to the conference mailing list, only ten people showed up: two people familiar with Fedora, and ( versus ) eight Debianites. Regardless, I think the discussion was success- and fruitful. We were able to identify a one-to-one mapping between the Fedora and Debian workflows, even though we use different techniques:

• both distros separate original software ( orig tarball ) from modifications made to fit the software in with the rest of the distro.
• Fedora keeps the .spec file, which references the original tarball, alongside any patch files in a per-release directory in their CVS tree, e.g. /mdadm/fedora8 and /glibc/rawhide. To obtain a source tree, the contributor checks out the CVS subtree, downloads the tarball according to the .spec file, and merges the two. There is a tool to automate this, obviously. This process is regularly executed to produce source RPMs .
• Debian keeps the original tarball next to a diff.gz file on the mirrors, along with a dsc file which refers to them both. Tools like dget take the URL to the dsc file to download all three, then invoke dpkg-source to unpack the tarball and apply the diff. Individual patch files are either stored in ./debian/patches/ (and applied by the diff), or they don t exist (meaning that all modifications are concatenated in the diff.gz file.

Many Debian package maintainers use version control systems to maintain the ./debian directory, and if patch files are stored in ./debian/patches/, then Debian and Fedora both store patch files in a version control repository, which seems awful. Just as I am only one of many who are experimenting with VCS-based workflows for Debian packaging, the Fedora people are also considering the use of version control for packaging. Unlike Fedora, who seem to try to standardise on bzr, I try to cater for the plethora of version control systems in use in Debian, anticipating the impossibility of standardising/converging on a single tool across the entire project. It seems that our two projects are both at the start of a new phase in packaging, a paradigm shift . What better time could there be for us to listen to each other and come up with a workflow that works for both projects? My suggestion currently centres around a common repository for each package across all (participating) distros, and feature branches. Specifically, given an upstream source tree, modifications made during packaging for a given distro fall into four categories:

• upstream changes, such as bug fixes in the original code, or simple things like manpage typos.
• (Linux) distro stuff, such as init.d scripts or Linux-ifications, which upstream doesn t care about or doesn t want.
• .deb/.rpm-specific changes, like the ./debian directory or the .spec file.
• distro-specific modifications, like policy compliance and the like.

Given a version control system with sufficient branching support, I imagine having different namespaces for branches: upstream-patches/*, distro/*, rpm/* or debian/*. Now, when building the Debian package, I d apply upstream-patches/*, distro/*, deb/* and debian/* in order, while my colleague from the Fedora project would apply upstream-patches/*, distro/*, rpm/* and fedora/*, before calling the build tools and uploading the package. There are surely problems to be overcome. Pascal Hakim mentioned patch dependencies, and I can t necessarily say with a clear conscience that my workflow isn t too complicated to be unleashed into the public yet. But if we find a conceptual workflow applicable to more than one distro, it should be possible to implement a higher-level tool to implement it. Also, the above is basically patch maintenance, not the entire workflow. Bug tracking system integration is going to play a role, as well as other aspects of daily distro packaging. I ll leave those for future time. For me, this is the start of a potentially fruitful cooperation and I hope that interested parties from other distros jump on. For now, I suggest my mailing list for discussion. You can also find some links on the Debian wiki.

As written earlier, I'm switching build system for one of my projects. In the end, I decided to roll my own. Yes, another build system out there. The general idea is to combine the strengths of automake and MSBuild, and take them to new extremes by not compromising where they have (that makes my build system a tad inflexible though). Automake's biggest strength is that it is descriptive, rather than imperative, and while it allows for rules to be entered directly to allow for some flexibility, this is usually the point where the Makefiles that are produced become unportable. But in general, the idea of having a tool deduce what exactly should be done to transform a set of input files into a set of output files is a good one, I think. From MSBuild, I stole the idea of making an explicit distinction between higher-level integration projects ("solutions" in their lingo) and actual build projects. Build projects only have one (main) output, which usually is a program or a library, and several auxiliary outputs (development files, translation templates, ...), while integration projects coordinate the build process (for example, if one of the build projects builds a tool, all projects using that need to be re-run if the tool is rebuilt, but only then. Automake's biggest downfall is stuff that is not explicitly supported. One of my projects uses IDL extensively, which leads to quite a lot of explicit rules supporting different ORBs. If I wanted to teach automake about that, I'd have to understand lots of perl code that emits code fragments that, when combined, will do the right thing. In a way, automake is a compiler, but based around the idea that since we start out from a Makefile compatible syntax, just adding things will magically work. Where it doesn't, special cases are invented, such as for libtool support, but stacking special cases is really difficult. MSBuild, on the other hand, leaves a lot to be desired when it comes to project-to-project integration. There is no way to tell it "publish these include files under the such-and-such directory for use by other projects", rather, you are expected to have the project using them explicitly reference your project in the include directories. If a project uses includes that reference includes from yet another project, it gets worse. Milestone 1 is going to be when the main binary can build itself on Windows and Linux.

AdSense patch for ikiwiki's embed pluging Today I've started playing with AdSense, mainly to check whether a typical homepage+blog web site (read: mine) can survive its hosting costs by the means of this kind of revenue or not. However I don't want the ads to be visible on all pages, but only in some of them, mainly the main blog page (which scores high in search engine results and is also not prone to the risk of bothering usual readers, thanks to---$DEITY bless them---RSS/Atom feeds) and some selected pet software project homepages. With ikiwiki implementing this appeared trickier than I expected. The main difficulty is of course the wiki-wide htmlscrubber plugin which I do not want to switch off because of discussion pages and a part of my website which is actually used as a world-editable wiki. Googling around it seems that there is an adsense.pm plugin for ikiwiki, but it is not registered in the ikiwiki plugins page; as such I was not particularly envy to try it out. Besides, the right place to add such a feature to me seems the embed plugin. ... so I've minimally patched it: see bug #462970. If you're willing to use AdSense with ikiwiki please try out the patch: since I'm an AdSense newbie it might well be I've underestimated the possible script snippets it can generate. Post comments to bug #462970.

Today I gave a talk about Debian security at the security mini-conf of LCA. Before I started the talk I asked for suggestions as to how to get more entries in my security blogging contest [0]. During the talk I asked for suggestions as to how to get more people involved in security development. One suggestion was to offer incentives. I’m experimenting with that with my blogging contest and may do future variations of the same thing. I started with describing some of the history of security in Debian (primarily things that involved me in some way): In 2003 I suggested that exec-shield be a standard feature in Debian kernel images [1]. I created a kernel-patch-exec-shield package in 2003 and Marcus Better took it over in 2004. We are hoping to get it included in Lenny. AMD64 architecture doesn’t need exec-shield as the CPU has separate write and execute bits in the page table, but it would be nice to get exec-shield included before the last P4 machine gets decommissioned. A presentation at the security miniconf at LCA 2005 on the topic of stack smashing is interesting [2]. At the time Adamantix was a distribution based on Debian which used PaX (similar to exec-shield). Adamantix has gone away. Hardened Gentoo has been available with Pax for all this time (but is not widely used). RHEL and Fedora have been available for all this time with exec-shield… In mid 2002 I demonstrated the first SE Linux Play machine at a conference in Germany. It was fully operational with root as the guest user. At that time SE Linux support in Debian was essentially complete. Since that time the scope of the SE Linuc project has increased slightly (EG controlling DBUS access) so the amount of work required for full support is greater. Most of that support is in Debian and Etch is basically working with SE Linux (although not quite as well as it was in 2002 due to lack of support for the strict policy). The aim is to have Lenny SE Linux become as functional as SE Linux in Fedora Core 5. While FC5 has more SE Linux features than the SE Linux project supported in 2002 it’s still a great disappointment that it’s taken so long. FC5 had pam_namespace to polyinstantiate directories such as /tmp. Lenny will hopefully have it. I described the current status: The hardening-wrapper package in unstable allows environment variables starting with DEB_BUILD_HARDENING_ to be used to control execution of GCC. Documented on the Debian Hardening Wikipedia page [3]. It’s still a little experimental and may change in the near future, but it works. Lucas Nussbaum is working on automatically building Debian packages with warnings for security related issues. The aim is to build all packages and maintain a central location for the logs to allow DDs to find and fix the problems in their packages. The Alioth Hardening project [4] will hopefully get some action soon (the people involved are busy doing work but not updating the project). The current plan is to base the Debian Hardening work around it. SE Linux in Debian is something that I want to get working correctly. There are still some significant issues that make strict policy unusable (such as correct labelling of /etc/passwd) as of last time I tested it. Finally I described the future plans. There were many questions about usability features for SE Linux, I mentioned in concept the features that Red Hat and Tresys people are developing (which I often don’t use as I prefer vi for policy editing). There were some questions about how SE Linux works. More than half the audience indicated that they had used it so I assumed some basic knowledge of SE Linux when describing how SE Linux works in regard to minimum privilege and the benefits of MAC in terms of limiting the scope of attack. I noted that every program has bugs and every program which performs security related tasks (which includes serving data to the net without being owned) should be assumed to inevitably have security related bugs (see the The Inevitability of Failure paper []). Based on the Twilight of the Books [5] article I decided to give this talk with no slides as an experiment. I talked from notes that I wrote and advised the delegates to read my blog for the details. Not presenting any slides meant that the room lights were all left on, which made things much easier when answering the many questions (I prefer an interactive format to my talks and have more questions than most speakers). It will be interesting to get some feedback from delegates about how they regarded this.

• [0] http://etbe.coker.com.au/2008/01/20/lca-2008-security-blogging-contest/


• [1] http://www.debian.org/News/weekly/2003/45/


• [2] http://www.linux.org.au/conf/2005/security_miniconf/presentations/smashing.pdf


• [3] http://wiki.debian.org/Hardening


• [4] http://alioth.debian.org/projects/hardening/


• [5] http://etbe.coker.com.au/2007/12/28/twilight-of-the-books/

Share This

According to a notification of trade on the Oslo B rs market, Nokia has made an offer for Trolltech of about 843 million Norwegian kroner , around 104 million. What this could mean for GTK+ is anyone’s guess. I’d expect at least that Nokia’s competitors that use Qtopia (like Motorola, Panasonic and Sony) are probably a little worried at the moment. Maybe there’ll be impetus for OSSO to move over to Qt, or maybe there’ll be internal competion at Nokia between a Qtopia stack and a GTK+/X11/Freedesktop stack. Maybe Qt will become more closed as Nokias pushes its advantage, or maybe it’ll be more open as development becomes less dependant on non-GPL license revenues, or maybe it’ll just stay the same. An interesting left-field move in this space is OpenMoko moving over to EFL, but on a primarily GNOME/Freedesktop stack. EFL is certainly much more capable than GTK+ in producing flashy UI’s on limited hardware. I”ve also heard of some companies writing UI’s in Flash using Gnash. I also wouldn’t be suprised if we start seeing embedded hardware running Mono and Moonlight at some point. Maybe one day we’ll have a GTK3 with DOM-like two pass event system and a cairo backend that renders totally on the GPU. One thing’s for certain, there’s a hell of a lot of competition on the toolkit front and it will only grow.

The first of my talks at LCA 2008 gave me a chance to talk about the current state of the Debian project, which got me my first LWN.net coverage with a photo, even (subscribers only for now, the article will become public on 7 February). Thank you, Jonathan Corbet, for a very good article which nailed all the main points! Slides are here. I agreed to this talk on short notice because I like to talk about Debian and was honoured by the chance to represent the project in this form. I would not have been able to do it without plenty of helpful input from colleagues in the last few days. Since I didn t get a chance to display the final slide with the acknowledgements during the talk, I would herewith like to thank specifically Andreas Tille, Michael Banck, Kevin Mark, Josip Rodin, MJ Ray, Cyril Brulebois, Stefano Zacchiroli, Frans Pop, Moritz M hlenhoff, Russ Allbery, Steve Langasek, Luk Class, Andreas Schuldei, and Christian Perrier. No guarantees for the completeness of the list. The talk ended in an open discussion on how Debian could improve. I took notes and shall forward them to the project mailing list, once I get a chance. Thanks to all the participants, as well. Update: during the talk, I mentioned that there was no security support around the time of the etch release. Thanks to Moritz M hlenhoff, who spotted my error: that should have been sarge . The problems with security support had long been resolved by the time etch was being prepared, and this was in (large?) part thanks to Moritz. Sorry for the screwup! I also called Linux to tend towards multimedia more than one might like. I should not have made this comment as a representative of the Debian project, and I probably did unjust to the Linux kernel in whole. This is entirely a personal issue, I have a number of problems with Linux memory management, scheduling, and some other points relevant to production use. I ve had some of these problems for years, but they seem never to get fixed, while development is fast-paced. Then I look at some of the work being done and I wonder what the priorities are. Regardless, I should not have made this comment and I apologise for it.

I've got an upload of gpe-tetris pending - see 462306 - to provide a smaller version of the popular falling blocks game for embedded devices. One or two things crop up from this package:

1. popcon - a lot of maintainers put a lot of store by popcon results but the popularity-contest package is perl and perl is not available in Emdebian (it is thrown out along with "Essential: yes" for space reasons). Writing a replacement for popcon may not be particularly sensible either because embedded devices, although often left running for long periods in a "low power" mode, often have rare and intermittent access to any form of internet connection. This could easily result in maintainers thinking that because a package has few (or even zero) popcon figures, it is not used. On the contrary, the package could simply be used on devices that either do not support perl (Emdebian) or which do not have the ability to file popcon reports despite being able to support perl. (With the probability that GPEPhone will be added to the GPE support already in Debian, users may not wish to have popcon "phoning home" because it would likely cost real money to do so - even if a C version of popcon was written.) So I'm posting this here so that I can refer back to this post if queries arise later on.
   


2. GPE apps on Debian - gpe-tetris is inherently designed for small devices with small screens and relatively slow processors, just like the majority of GPE. gpe-tetris is also designed to be usable on a handheld device where the lack of a normal keyboard can make game play awkward. As a result, playing gpe-tetris on an average Debian box is likely to appear trivially easy and the "progression" between levels would appear very slow in comparison with the tetris available in GNOME or KDE. This is deliberate and is expressly intended to allow the game to be playable on embedded hardware that has fiddly little keys. (I'll be adding this to the manpage and a brief summary of this to debian/control.) This does give the opportunity for a little sleight-of-hand such that a device could be provided with a highscore file created on a much more powerful device and so preventing any new highscores being set, but please don't do that - play nicely!
   


3. small apps != bad code - Yes, lots of GPE packages are very small, some were clearly written originally as "demos" or during the process of learning how to write larger packages. This does not necessarily mean the packages contain bad code. I will feed back sensible patches to upstream to resolve flaws in the code but please do not think ill of the packages merely because the source code looks "trivial" compared to a GNOME package.
   


4. dpkg-shlibdeps - one issue that I must begin to track after Fosdem will be to aggregate the "foo should not be linked against" messages from dpkg-shlibdeps in GPE packages and try to build a complete picture, in case there is a real possibility of completely dropping some packages that always seem to appear in that list due to the pkg-config --libs gtk+-2.0 listing. If so, I'll begin discussions with upstream about manually specifying the GTK_LIBS variable whilst retaining the PKG_CHECK_MODULES macro that ensures that the -dev package is available in the cross-building environment. This is likely to be some form of database-query mechanism - feeding data in from grepping the build logs, building a query from the list of packages to be used for a specific Emdebian root filesystem (machine/variant specific) and then spitting out whether particular package sets can have particular targets removed. If anyone fancies working on that already, the Debian version of the information is already available via the buildd network and the Emdebian cross-build results will not differ greatly from those at this stage.
   

Other uploads include updates of libgpeschedule, gpe-calendar and gpe-clock if gpe-announce makes it through NEW as expected. Updates for emdebian-tools and apt-cross and likely new releases for QOF, gpe-expenses and pilot-qof.
debcheckout compliance
In other developments, I've worked out how to specify Vcs-Cvs correctly such that debcheckout can find the repository data correctly. Sadly, vim syntax highlighting does not help with the CVS version but the CVS syntax is:

Vcs-Browser: http://alioth.debian.org/plugins/scmcvs/cvsweb.php/dpkg-view/?cvsroot=dpkg-view

Vcs-Cvs: :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/dpkg-view dpkg-view

Note the colon prefix to pserver and the space between the repository login location and the module name. Remember to omit the "-d" - debcheckout will add that for you (and won't check to see if you have already specified it).

Firstly, I haven't been following debian-devel as closely as in recent months and some things have passed me by. Secondly, I am rather pre-occupied with my own small world of Embedded Debian. One result of this is that I wasn't really paying attention to arguments over the source package format and took longer than I expected to respond to a request to take a look at tslib - a touchscreen library for embedded devices. When I did start work on it I managed to upset Joey Hess by implementing dpatch support which he had recently decried as unhelpful. I also added some extra fuel by getting myself in a two-and-eight over svn-buildpackage and it's broken bias towards native packages.
I happen to disagree with the idea that maintainers should alter upstream files directly, merely relying on the .diff.gz or some weird $RCS runes. Instead, I seek to ensure that the .diff.gz contains no changes outside the debian/ directory. I'm not happy keeping the entire upstream source in yet another RCS (for any reason) and would much rather make updates to my Debian packages by simply copying the debian/ contents into an unpacked pristine upstream source (preferably via uscan). I find it really useful to simply check out the latest CVS/SVN/$RCS, dump debian/ into place and call 'debuild' when testing various upstream development issues. Maybe this is because I have relatively few Debian packages that need debian/patches/* and certainly few that need more than a couple of patch files. It certainly has a lot to do with my embedded work where I need to make changes to the contents of debian/ to make an Emdebian package whilst retaining the same upstream code as is used in existing embedded projects like Open Embedded and Familiar. I don't want to be chasing changes through the upstream source - I want all the changes in a single place so that I can create Emdebian patches against the Debian source. (I'd rather not have patches in the Debian source at all but this is only realistic for either my own packages or those released as part of GPE for various embedded-native compatibility reasons.) I certainly do not want any Debian $RCS to be lumbered with yet another set of upstream sources that will always be out of date compared to the real upstream sources.
I am also a great fan of CDBS - much to the horror of some in Debian - primarily for one very simple reason, it cross builds so easily. Considering my workload, it should not be a surprise that the ability to support cross building without requiring any changes to the Debian package is incredibly persuasive when selecting a build system for a package of my own. debhelper really is woeful at cross building - each package needs customised cross building support painstakingly devised and tested, making script-based mass bug filing impossible. CDBS shows that with a little wrapping, debhelper can support cross building in a clean and completely non-intrusive manner.
This means I can concentrate on those changes that are actually important - the changes that provide the benefits of cross-building and justify the effort of actually cross building the entire dependency chain: the ability to fully control Debian-specifics like "Essential: yes" and to disable, modify or adapt components of any package such that the installed system has a fraction of the dependencies of the Debian version of precisely the same package. TDeb support is good too but that can be implemented against any build, it doesn't need to be a cross build.
Sadly, the end result of all this for tslib is that it will be removed from collab-maint very soon, Joey does not wish to be associated with the new version because although it includes some features which he is happy to see implemented, my use of dpatch and the hacks I had to devise to workaround svn-buildpackage do not fit with his workload patterns. Once tslib is removed from collab-maint, these hacks become redundant and I can use my normal packaging methods. Equally, his methods (in particular the lack of debian/patches/*) do not fit with my workload patterns and although I do not have as many packages as Joey, I have enough (when the 200 Emdebian source packages are also considered) to make the issue into a blocker. The new version of tslib uses the upstream SONAME and adds a -dbg package so it will spend some time in NEW. I am also likely to migrate it to CDBS once removed from collab-maint.
I suspect these issues will be revisited during discussions at Fosdem 2008 where I'll be presenting two talks - one in the Debian developer room and one in the Embedded developer room. Feel free to harangue me if you feel strongly that there is a sane way of cross building that does a better job than CDBS.

Some days ago, my RSS reader found Mark Jason Dominus' Help.pm - Yes, the module is (so far, at least - I could not find it on CPAN) only published as a blog post. But don't let that fool you - It's a beautiful (and simple!) Perl module that can help developers that are too lazy to go look up methods in the man pages. Perl's introspection capabilities are not behind other dynamic languages' (i.e. Python's or Ruby's, speaking only about what I'm familiar with). However, it's used much more seldom, partly because Perl does not ship by default with an interactive console (such as Ruby's irb or Python's regular behaviour when called without an input script). Of course, writing a Perl console is an easy task, and good Perl consoles exist, although its use is not part of the Perl culture. But of course, just glancing over MJD's code made me come up with a simple, yet useful, way to use introspection in Perl, usable as a simple one-liner. Say you want to look at all of the methods provided by IO::File:

gwolf_at_mosca[25]/tmp$ perl -e 'use IO::File; print join(", ", grep defined & "IO::File::$_" sort keys % "IO::File::" ), "\n"'
binmode, carp, confess, croak, gensym, new, new_tmpfile, open, qualify, qualify_to_ref, ungensym

Want the scalar variables? Of course:

gwolf_at_mosca[26]/tmp$ perl -e 'use IO::File; print join(", ", grep defined $ "IO::File::$_" sort keys % "IO::File::" ), "\n"'
VERSION

Same goes for arrays and hashes. And, of course, leaving out the grep gives you anything. Yup, it's the magic package-name hash trick. Main difference between this and MJD's Help.pm? That Help.pm goes up the inheritance chain, and is thus much more correct. Of course, I'll be uploading Help.pm to Debian very soon - And, why not, I think I'll add a way for it to query on different symbols, not just on methods. And the simple binary to call from the command line. Sounds very much worth it ;-) Thanks, MJD!

We have a problem with our tools in Debian, and it's this: Above the core tools in dpkg-dev, and the nearly core tools in debhelper and devscripts, and the many different -- but all slowly converging -- revision control systems, there is the potential for infinite cruft to pollute the source package. Note that one developer's cruft is another developer's use of an excellent tool. If you don't believe that, you haven't read a lot of crufy upstream build systems, because Debian isn't the only project with this problem. The source of this cruft is a near-constant stream of new tools that are each developed in good faith by someone who needs that tool, and then adopted and used in packages of a generally small percentage of developers, who think that tool might be a good fit for their problems. The tool isn't yet suitable for everyone to use, and most of these tools never become suitable for everyone, because

1. making the leap from a special-purpose, poorly-designed hack to a general-purpose tool is hard
2. getting the project to standardise on a tool is hard
3. a tool often doesn't become general purpose until enough people use it, no matter how well designed it is to start out with

So after a while, a better, or at least different, solution to some of the same problems will come along, and some generally small percentage of developers will choose to use it in their source packages. Meanwhile, the developers who chose the old thing will be set in their ways and not want to use the new thing, and generally cannot be budged to stop using the old thing by any amount of argument. Which in a sense is normal, and fine, until you have to collaborate with them. I don't care if someone I'm collaborating with uses emacs to my vim, but I do care if they use cdbs to my debhelper. I care because their tool-choice encrufts the source that I'm supposed to be working on. Once a significant percentage of all the source packages in Debian are encrufted for a wide array of different tools, it will become harder and harder to work with Debian's source packages. We're already seeing this happen. Another way of looking at it is that we've invented dozens of source package formats that all work differently, aside from a small shared core, and we expect our developers to be able to use all of them. At this point I see this as a huge, potentially killer problem, that is making Debian development become worse with every passing year. But I have no real solution. Obviously pointing out that tools are obsoleted or bad doesn't work; we still have dozens of packages using yada, which everyone agrees is horrible. That doesn't bode well, does it? One partial solution is to design a category killer, and get it embedded in acknowledged core tools. That's what I have tried, and so far, failed, to do with an evolutionary change to the Debian source package format, which I'd hope would give people a reason to stop using dpatch, dbs, and their ilk. As noted, this approach is Hard.

---

For now, I have no interest in being on a team that requires I use any of the following things:

• dpatch
• dbs
• quilt
• Any similar system that is used to move all patches to under the debian/ directory.
• Any system that nests the actual original upstream .tar.gz inside an .orig.tar.gz.
• yada
• cdbs
• Any similar system that obfuscates debian/rules.
• Any special script that is required to be used to build a package as a wrapper around dpkg-buildpackage.

This means that I can't be on the security or release teams, and even teams like the perl team are getting sticky to be on.

---

PS, this doesn't mean I dislike quilt. I dislike quilt encrufting Debian source packages, which is entirely different. PPS, In case you're wondering why debhelper gets a pass, it's because it's gone through the three numbered steps above to become a standard, general purpose tool, and has no serious competators. (Though it does have parasites, like cdbs.)