Debian LTS - impressions and thoughts from my first month involvement About LTS - we want feedback and more companies supporting it financially Squeeze LTS, and even more Debian LTS, is a pretty young project, started in May 2014, so it's still a bit unclear where exactly we'll be going One purpose of this post is to spread some information about the initiative and invite you to tell us what you think about it or what your needs are. LTS stands for "Long Term Support" and the goal of the project is to extend the security support for Squeeze (aka the current oldstable distribution) by two years. If it weren't for Squeeze LTS, the security support for it would have been stopped in May 2014 (=one year after the release of the current stable distribution), which for many is a too short timespan after it's release in February 2011. It's an experiment, we hope that there will be a similar Wheezy LTS initiative in future, but the future is unwritten and things will change based on our experiences and your needs. If you have feedback on the direction LTS should take (or anything else LTS related), please comment on the lts mailing list. For immediate feedback there is also the #debian-lts IRC channel. Another quite pragmatic way to express your needs is to read more about how to financially contribute to LTS and then doing exactly that - and unsurprisingly we are prioritizing the updates based on the needs expressed from our paying customers. My LTS work in July 2014 So, "somehow" I started working for money on Debian LTS in July, which means there were 10h I got paid, and probably another 10h where I did LTS related work unpaid. I used those to release four updates for squeeze-lts (linux-2.6, file, munin and reportbug) fixing 22 CVEs in total. The unpaid work was mostly spent on unsuccessfully working on security updates and on adding support for LTS to the security team tracker, which I improved but couldn't fully address and which I haven't properly shared / committed yet... but at least I have a local instance of the tracker now, which - for LTS - is more useful than the .debian.org one. Hopefully during DebConf14 we'll manage to fix the tracker for good. Without success I've looked at libtasn1-3 (where the first fixes applied easily but then the code had changed too much from what was in squeeze compared to the available patches that I gave up) and libxstream-java (which is at version 1.3, while patches exist for upstream branches 1.4 and 2.x, but those need newer java to build and maybe if I'll spend two more hours I'll can get it build and then I'll have to find a useful test case, which looked quite difficult on a brief look.. so maybe I give up on libxstream-java too.... OTOH, if you use it and can do some testing, please do tell me. Working on all these updates turned out to be more team work than expected and a lot of work involving code (which I did expect), and often code which I'd normally not look at... similarily with tools: one has to deal with tools one doesnt like, eg I had to install cdbs... And as I usually like challenges, this has actually been a lot of fun! Though it's also pretty cool to use common best practices, easy and understandable workflows. I love README.Source (or better yet, when it's not needed). And while git is of course really really great, it's still very desirable if your package builds twice (=many times) in a row, without resetting it via git. Some more observations The first 16 updates (until July 19th) didn't have a DLA ID, until I suggested to introduce them and insisted until we agreed. So now we agreed to put the DLA ID in the subject of the announcement mails and there is also some tool support for generating the templates/mails, but enforcing proper subjects is not done, as silent bounces are useless (and non silent ones can be abused too easily). I'm not really happy about this, but who is happy with the way email works today? And I agree, it's not the end of the world if an LTS announcement is done without a proper ID, but it looks unprofessional and could be avoided, but we have more important work to do. But one day we should automate this better. Another detail I'm not entirely happy is the policy/current decision that "almost everything is fine to upload if deemed sensible by the uploader" (which is everyone in the Debian upload keyring(s)). In discussions before actually having the archive some people suggested the desire to upload new upstream versions too (eg newer kernels, iceweasel or other software to keep running a squeeze desktop in the modern world were discussed). I sincerely hope for most intrusive new upstream versions squeeze-(sloppy-)backports is used instead, and squeeze-lts rather not. Luckily so far all uploads were (IMHO) sensible and so, right now, I will just say that I hope it will stay this way. And it's true, one also has to install these upgrades in the first place. But people do that blindly all the time... So by design/desire currently there is no gatekeeping mechanism whatsover (no NEW, no proposed updates), except that only some selected "few" can upload. What is uploaded (and signed correctly), gets pushed to archive, buildds and the mirrors, and hopefully maybe someone will send an announcement. So far this has worked remarkedly well - and it's also the way the Debian Security team works, as I'm told. Looking at this from a process quality / automatisation perspective, all this manual and errorprone labour seems very strange to me. And then there is another thing: as already mentioned, the people working paid hours for this, are prioritizing their work based on customer requests. So we did two updates (python-scipy and file), which are not fixed in wheezy yet. I think this is unfortunate and while I could probably prepare the wheezy DSA for file, I don't really want to join the Security Team... or maybe I want/should join the Security Team and be a seldomly active member (eg fixing file in wheezy now....) A note related to this: out of those 37 uploads done until today, 16 were done by those two people being paid, while the other 21 uploads were done by 10 volunteers (or at least not paid by Debian LTS). It will be interesting to see how this statistics evolves over time. Last, but not least, there is also this can of worms (aka: the discussion) about paying people to work on Debian... I do agree it's work we didnt find volunteers for and I also see how the (financial side of the) setup is done outside of Debian (and well too, btw!), but... then we also use Debian ressources like buildds, the archive itself and official mailing lists. Also I'm currently biased in this discussion, as I directly (and happily) profit from it. I'm mentioning this here, because I believe it's important we discuss this and come to both good and practical conclusions. FWIW, we have also discussed this on the list, feel free to search the archives for it. To bring this post to an end: for those attending DebConf14 (directly or thanks to some ninjas), there will be an event about LTS in Portland, though I'm not sure yet what I will have to talk about what hasn't been already covered here But this probably means that will be a good opportunity for you to do lots of talking instead! I'm curious what you will have to say! Thanks for reading this far. I think I can promise that my next LTS report will be shorter

I would like to publicly apologise for the inconvenience caused by my recent updates to the mediawiki and mediawiki-extensions source packages in Debian wheezy (stable-security). As for reasons I m doing Mediawiki-related work at my dayjob, as part of FusionForge/Evolvis development, and try to upstream as much as I can. Our production environment is a Debian wheezy-based system with a selection of newer packages, including MediaWiki from sid (although I also have a test system running sid, so my uploads to Debian are generally better tested). I haven t had experience with stable-security uploads before, and made small oversights (and did not run the full series of tests on the final , permitted-to-upload, version, only beforehand) which led to the problems. The situation was a bit complicated by the need to update the two packages in lockstep, to fight an RC bug file/symlink conflict, which was hard enough to do in sid already, plus the desire to fix other possibly-RC bugs at the same time. I also got no external review, although I cannot blame anyone since I never asked anyone explicitly, so I accept this as my fault. The issues with the updates are:

• mediawiki 1.19.5-1+deb7u1 (the previous stable-security update) was not made by me but by Jonathan Wiltshire
• mediawiki 1.19.11+dfsg-0+deb7u1 (made by me) was fine, fixed the bugs it was supposed to, but was delayed after being uploaded to security-master-unembargoed
• mediawiki 1.19.14+dfsg-0+deb7u1 was supposed to be a mostly upstream update, but I decided to add changes to fix issues pointed out by lintian (not trivial ones), and mistakenly forgot to remove two lines that should not have crept in from sid
• mediawiki 1.19.14+dfsg-0+deb7u2 was quickly uploaded to fix this issue but took about half a day to be ACCEPTed
• mediawiki-extensions 3.5~deb7u1 should have be named 2.12 but could not, due to the aforementioned lockstep update requirement and version checks in maintainer scripts; it fixes the issues but does not add other changes from 3.5 in sid unfortunately, the packaging uses cdbs (which I dislike quite a lot, but as the newcomer in the team I decided to accept it and go on; changing the existing packaging would be quite some effort anyway) and wants debian/control to be regenerated from control.in which I thought I had done, and normally do
• mediawiki-extensions 3.6 (in sid) fixes another dir/symlink conflict shown up after 3.5 was made. I ve requested upload permission for regenerating debian/control and asked whether I am allowed to include this fix as well

My unfamiliarity with some of the packaging concepts used here, combined with this being something I do during $dayjob (which can limit the time I can invest, although I m doing much more work on Mediawiki in Debian than I thought I could do on the job), can cause some of those oversights. I guess I also should install a vanilla wheezy environment somewhere for testing I do not normally do stable uploads (jmw did them before), so I was not prepared for that. And, while here: thanks to the Debian Security Team for putting up with me (also in this week s FusionForge issue), and thanks to Mediawiki upstream for agreeing to support releases shipped in Debian stable for longer support, so we can easily do stable-security updates.

The Debian Security Team announced in the bits from their last meeting that they're considering to ask for the addition of a new suite to provide long term support (LTS) for Squeeze. Quoting their announcement:

• It needs to be pointed out that for this effort to be sustainable actual contributions by interested parties are required. squeeze-lts is not something that will magically fall from the sky. If you're dependent/interested in extended security support you should make an effort to contribute, either by contributing on your own or by paying a Debian developer/consultant to contribute for you. The security team itself is driving the effort, NOT doing it. Some team members will contribute to it individually, however.
• Anyone interested in contributing, please get in touch with team@security.debian.org. We'll setup an initial coordination list with all interested parties. All policies / exact work will be sorted out there.

This means this is still not something settled and if you or your company is insterested in joining this effort, you should contact the security team ASAP. So they can see if there is enough people and resources to launch the LTS.

There are many ways to build Debian distributions from source. None of them are trivial enough for beginners and all of them require complex setups. For instance, the Debian official setup uses the following software components:

• Centralized database with package information, wanna-build.
• Build daemon software along installation documentation.

Around the core components, there are other software components needed to run the Debian distribution:

• Incoming package queues (ftp-master)
• Repository management (dak)

Thanks to Debian ftp-master and buildd team, all software is built for several architectures and several ports. Most Debian infrastructure is managed and maintained by Debian System Administration team. Debian Wiki has been growing different random pages trying to ease the setup and configuration problems concerning to Debian build system infrastructure.

• Debian Wanna Build Infrastructure on one server
• Build Service for Wanna Build
• Buildd Setup

The above infrastructure barely documents what it is involved to create and generate Debian unstable ( sid ) distribution suite. In order to produce Debian stable distribution suite, there are software transitions to happen and yet another Debian team gets involved in the process, our beloved Debian release team. Once distribution reaches its maturity level and gets released as in its stable version, it gets updates also lead by release team and security related updates, which yet another team is responsible for them, the Debian security team. and there are lots of Debian teams doing many other things you might enjoy, have a byte

There are many ways to build Debian distributions from source. None of them are trivial enough for beginners and all of them require complex setups. For instance, the Debian official setup uses the following software components:

• Centralized database with package information, wanna-build.
• Build daemon software along installation documentation.

Around the core components, there are other software components needed to run the Debian distribution:

• Incoming package queues (ftp-master)
• Repository management (dak)

Thanks to Debian ftp-master and buildd team, all software is built for several architectures and several ports. Most Debian infrastructure is managed and maintained by Debian System Administration team. Debian Wiki has been growing different random pages trying to ease the setup and configuration problems concerning to Debian build system infrastructure.

• Debian Wanna Build Infrastructure on one server
• Build Service for Wanna Build
• Buildd Setup

The above infrastructure barely documents what it is involved to create and generate Debian unstable ( sid ) distribution suite. In order to produce Debian stable distribution suite, there are software transitions to happen and yet another Debian team gets involved in the process, our beloved Debian release team. Once distribution reaches its maturity level and gets released as in its stable version, it gets updates also lead by release team and security related updates, which yet another team is responsible for them, the Debian security team. and there are lots of Debian teams doing many other things you might enjoy, have a byte

Just posted to d-d-a, here are the monthly DPL bits.

---

Dear project members,
here's the periodic report of what has happened in DPL land, this time during May 2012. It's briefer than usual, as this year I've enjoyed the lovely French habit of frequent holidays during the month of May. Highlight First highlight for this month is an invitation to us all. We're now in June and the Wheezy freeze is literally a few days away. The RC bugs count is moving in the right direction, but it's still stellar if we want to ensure a short freeze. And a short freeze is of paramount importance: it'll reduce the time during which we can't implement great plans for the future, increase the "freshness" of software we'll ship with Wheezy, and reduce the inconveniences for those who run the testing suite due to its nice "rolling" feature. So please set out some regular time to do RC bug squashing, by providing patches and doing NMUs. Releasing Wheezy is not something that could be outsourced to the Release Team, it's a collective responsibility that kicks in as soon as our own packages are RC bug free (which they already are, right? The second highlight is more on the internal structure camp. As mentioned last month, I've discussed with the tech-ctte insisting a bit to set up periodic IRC meetings, to ensure outstanding issues get periodically reviewed. At the end of May the first IRC meeting has happened, and has been very productive. See the minutes. Another one has been scheduled, trying to setup a monthly cadence, for the end of June. Many thanks to all tech-ctte members who have took part in and helped with the meeting organization. Communication I've given an interview to iTWire, answering a number of questions about several past and future Debian challenges. Discussions The ongoing discussion to harmonize packaging of multimedia software between the official Debian archive and the unofficial debian-multimedia.org archive (dmo) has progressed. I've tried to help the two groups reaching an agreement on which packages belong where, so that both duplicate packaging efforts and user inconveniences are minimized. That seems not to have worked and dmo maintainers have simply announced that they will move away from the current domain name to a new one that does not include "debian" in its name. Sprints There will be a Debian Science sprint in June, co-located with the broader Debian Science event organized by European Synchrotron Radiation Facility (ESRF) in Grenoble. I've confirmed my attendance for the opening talk of the conference day. ESRF organizers have kindly sponsored travel for all Debian attendees, many thanks to them! Another sprint will happen next week-end in Paris, this time by the i18n/l10n team. I've approved the corresponding tentative budget for travel sponrship for ~2'000 EUR. Other expenses Hardware replacement plans go on. We've ordered SSDs (for ~3'000 CAD) for recently bought machines meant to replace bugs-mirror, bugs-master, and udd. On the "small emergencies" front, we also had to replace failing disks on wagner (1/2 of alioth), for as little as 100 GBP. Miscellanea

• I've helped a bit with the ratification of the Debian diversity statement by seconding it and shortening the discussion period
• on the multimedia front, I've also sought legal advice for the multimedia team, to better understand how to provide a decent multimedia experience for Debian users while respecting the draconian copyright system that exists almost world-wide. There seem to be some solutions in sight for the few missing packages (which I'm still discussing with the respective maintainers), but they'll hardly be ready for Wheezy
• three people replied to my call for help with DPL tasks (thanks!). I'll be shortly contact them to share the list of tasks that can be outsourced to anyone willing to help; then I'll try to setup a calendar of periodic IRC public meetings. There's still time to apply if you are interested (hint hint!)
• on behalf of Debian, SPI has entered in the ISC Forum Membership Agreement, giving access to the Debian security team to security notices for softwares like BIND and DHCP. We previously had a similar agreement for individual maintainers, but it's good to move it at a project level, in order to diminish bus factors

Happy Wheezy freeze,
and RC bugs squashing!

---

PS the boring day-to-day activity log for May is available at master:/srv/leader/news/bits-from-the-DPL.txt.201205

This week in brief:

I've rejoined the Debian Security Team

My first (recent) DSA was released earlier today, with assistance from various team members. (My memory of the process was poor, and some things have changed in my absence.)

BlogSpam gains a new user

The BlogSpam API is now available for users of Trac.

Finally, before I go, I've noticed several people on Planet Debian report their photo-challenges; either a picture a day or one a week. I too take pictures, and I'm happy if I get one session a month. I suspect some of my content might be a bit too racy for publication here. If you're not avoiding friendface-style sites you can follow "highlights" easily enough - or just look at the site. ObQuote: "Be strong and you will be renewed. Identify. " - Logan's Run (1976)

I was asked to write about what I do at Canonical and what I do in the Free Software community at large. There is obviously a great deal of overlap, but I ll start with the things I m involved with when I m wearing my Ubuntu hat. My primary job at Canonical is keeping Ubuntu secure. This means that I, along with the rest of the Ubuntu Security Team, coordinate with other Free Software distributions and upstream projects to publish fixes together so that everyone in the community has the smallest possible window of vulnerability, no matter if they re running Ubuntu, Debian, RedHat/Fedora, SUSE/openSUSE, Gentoo, etc. Between vendor-sec, oss-security, and the steady stream of new CVEs, there is plenty going on. In addition to updates, the Security Team works on pro-active security protections. I work on userspace security hardening via patches to gcc and the kernel, and via build-wrapper script packages. Much of this work has been related trying to coordinate these changes with Debian, and to clean up unfinished pieces that were left unsolved by RedHat, who had originally developed many of the hardening features. Things like proper /proc/$pid/maps permissions, real AT_RANDOM implementation, upstreaming executable stack fixing patches, upstreaming kernel NX-emu, etc. Most of the kernel work I ve done has gotten upstream, but lately some of the more aggressive protections have been hitting frustrating upstream roadblocks. Besides the hardening work, I also improve and support the AppArmor Mandatory Access Control system, as well as write and improve confinement profiles for processes on Ubuntu. This work ends up improving everyone s experience with AppArmor, especially now that it has gotten accepted upstream in the Linux kernel. I audit code from time to time, both on the clock with Canonical and in my free time. I m no Tavis Ormandy, but I try. ;) I ve found various security issues in Xorg, Koffice, smb4k, libgd2, Inkscape, curl+GnuTLS, hplip, wpa_supplicant, Flickr Drupal module, poppler/xpdf, LimeSurvey, tunapie, and the Linux kernel. With my Canonical hat off, I do all kinds of random things around the Free Software ecosystem. I m a sysadmin for kernel.org. In Debian, I maintain a few packages, continue to try to push for security hardening, and contribute to the CVE triage efforts of the Debian Security Team. I ve written or maintain several weird projects, including MythTVFS for browsing MythTV recordings, GOPchop for doing non-encoding editing of MPEG2-PS streams, Perl s Device::SerialPort module, and the TAP paging server Sendpage. For a selection of things I ve contributed to other project, I ve implemented TPM RNG access in rng-tools, made contributions to Inkscape s build and print systems, implemented CryptProtect for Wine, wrote a PayPal IPN agent in PHP that actually checks SSL certificates unlike every other implementation I could find, added additional protocol-specific STARTTLS negotiations to OpenSSL, implemented the initial DVD navigation support in MPlayer, updated serial port logic in Scantool for communicating with vehicle CAN interfaces, tried to add support for new types of timeouts in Snort and Ettercap, fixed bugs in mutt, and added HPUX audio support to the Apple ][ emulator XGS. As you can see, I like making weird/ancient protocols, unfriendly file formats, and security features more accessible to people using Free Software. I ve done this through patches, convincing people to take those patches, auditing code, testing fixes and features, and doing packaging work. When I go to conferences, I attend UDS, DefCon, OSCon, and LinuxCon. I ve presented in the past at OSCon on various topics including security, testing, and video formats, and presented at the Linux Security Summit (miniconf before LinuxCon this year) on the need to upstream various out-of-tree security features available to the Linux kernel. I love our ecosystem, and I love being part of it. :)

It is our pleasure to announce that Aur lien Jarno is now an assistant to the Debian Security Team.

He will concentrate most of his efforts on security support for the new kFreeBSD kernel.

Thanks Aur lien, and welcome to the team.

Contributed by:Steffen Joeris, on behalf of the Security Team

I ve just added the Wordpress Minify [1] plugin to my blog. It s purpose is to combine CSS and Javascript files and to optimise them for size and it s based on the Minify project [2]. On my documents blog this takes the main page from 313KB uncompressed, 169KB compressed, and a total of 23 HTTP transfers to 306KB uncompressed, 117KB compressed, and 21 HTTP transfers. In each case 10 of the HTTP transfers are from Google for advertising. It seems that a major obstacle to optimising the web page load times is Google adverts of course Google has faster servers than I do so I guess it s not that much of a performance problem. The minify plugin caches it s data files and I had to really hack at the code to make it use /var/cache/wordpress-minify a subdirectory of the plugins directory was specified in many places. deb http://www.coker.com.au lenny wordpress
I ve added a wordpress-minify package to my repository of Wordpress packages for Debian/Lenny with the above APT line. I ve also got the following packages:
adman
all-in-one-seo-pack
google-sitemap-generator
openid
permalink-redirect
stats
subscribe-to-comments
yubikey The Super Cache [3] plugin has some nice features. It generates static HTML files that are served to users who aren t logged in and who haven t entered a comment. This saves significant amounts of CPU time when there is high load. The problem is that installing this requires modifying the main .htaccess file, adding a new .htaccess file in the plugins directory, and lots of other hackery. The main reason for this is to avoid running any PHP code in the most common cases, it would be good for really heavy use. Also PHP safe mode has to be disabled for some reason, which is something I d rather not do. The Cache [4] plugin was used as the base for the Super Cache plugin. It seems less invasive, but requires the ability to edit the config file. Getting it into a shape that would work well in Debian would take more time than I have available at the moment. This combined with the fact that my blog will soon be running on a system with two quad-core CPUs that won t be very busy means that I won t be packaging it. If anyone would like to Debianise the Cache or Super Cache plugin then I would be happy to give them my rough initial efforts as a possible starting point. I m not planning to upload any of these packages to Debian, it would just add too much work to the Debian security team without adding enough benefit.

• [1] http://wordpress.org/extend/plugins/wp-minify/
• [2] http://code.google.com/p/minify/
• [3] http://ocaoimh.ie/wp-super-cache/
• [4] http://wordpress.org/extend/plugins/wp-cache/

Last week I resigned from my position as member of the Debian Security Team. Historically several Debian teams have had members inactive for months and years at a time, and I'd rather be removed of my own volition than end up listed but inactive like that. It's been a pleasure working with all members of the team, past and current (especially Joey), and who knows I might return in the future. If you're interested in security work then getting involved isn't difficult. It just takes time, patience, and practise. ObFilm: The Goonies

Alexander Wirt just wrote a mail to our mailinglist to announce that lenny-backports suite is ready for uploads. We will of course continue supporting etch-backports with security updates as long as etch will be supported by the Debian security team.

Happy backporting!

SE Linux is almost ready to use in Lenny. Currently I am waiting on the packages libsepol1 version 2.0.30-2, policycoreutils 2.0.49-3, and selinux-policy-default version 0.0.20080702-4 to make their way to testing. The first two should get there soon, the policy will take a little longer as I just made a new upload today (to make it correctly depend on libsepol1 and also some policy fixes). Update: libsepol1 version 2.0.30-2 and policycoreutils 2.0.49-3 are now in Lenny (testing). Now I’m just waiting for the policy. Ideally we would be able to pin the apt repositories to take just the packages we want from Unstable (here is a document on how it’s supposed to work [1]). That doesn’t work, so I also tried setting “APT::Default-Release “stable”;” in /etc/apt/apt.conf (as suggested on IRC). This gave better results than pinning (which seems to not work at all) but it still wanted to take unreasonably large numbers of packages from unstable. Currently to get SE Linux in Lenny (Testing) working you must first upgrade everything to the testing versions, then install libsepol1 from Unstable (this is really important as until a few hours ago the Policy packages in Unstable didn’t depend on it). Then you install policycoreutils and finally the policy package which will be selinux-policy-default for almost everyone - I have not tested the MLS package (selinux-policy-mls) and it’s quite likely that it won’t work well. The policycoreutils package has a bug related to Python libraries [2] which I don’t know how to fix. Any advice would be appreciated. It’s obvious that the package name needs to not contain a hyphen, but what the name should be and where the files should be stored. The release team have been pretty cooperative with my requests so far to get broken things fixed, hopefully I’ll find a solution to this (and the other similar issues) soon enough to avoid any great inconvenience to them. I’m sure that they will agree that significantly broken packages (which have syntax errors in scripts) need to be fixed before release. There are also some last minute policy issues that need to be fixed. To properly test this I’m now running the server for my blog and mail server on Lenny with SE Linux. I think that I’m only one policy bug away from running in enforcing mode. While the situation is pretty difficult at the moment (I’ve had a report forwarded to me from an OLS delegate who tried Lenny SE Linux with the older policy packages and got a bad result), I believe that once Lenny is released we will have the best ever support for SE Linux. The Debian security team recently released an update to the SE Linux policy packages to match the recent updates to BIND [3]. I was grateful that they did this - and without any significant involvement from me. I was asked to advise on the patch that they had written, I confirmed that it looked good (which took hardly any effort), and they did the rest (which appears to be a moderate amount of work). Given the situation it would have been understandable if they had decided that it was something that could be worked around. I expect that SE Linux on Lenny will get more users than on Etch, so therefore more issues of this nature will be discovered so I expect to have more interaction with the Debian security group in future.

• [1] http://jaqque.sbih.org/kplug/apt-pinning.html


• [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486120


• [3] http://www.debian.org/security/2008/dsa-1617

Share This

This Tuesday Robert Felber released a new upstream version. It is a (local) security bugfix (and some minor fixes) which was reported on Sunday by Chris Howells to the Debian Security Team (as well as to other vendors). Today DSA-1531 was released. Right from the DSA:
“… created its socket in an insecure way, which may be exploited to overwrite or remove arbitary files from the local system.” So please update you systems if you use this package asap. While we are at policyd-weight… there is one bug open (#471645) where I’m unsure if I want to fix it, cause only stable is effected and the problem can be solved by providing a adjusted array of rbl in the config file. Should I ask for inclusion directly into stable? But it’s a really minor issue. Or try to get 0.1.14.15 uploaded to volatile? I’m really unsure and suggestions are welcome.

Serious business involving the vmsplice() exploit: The kernel is fixed, hopefully Debian security team will have a fix for production use soon. In the meantime, waldi has provided unofficial fixed images. Thanks! They are confirmed to be working. These images are for etch. Lenny and sid are still vulnerable, but I suspect this will be fixed soon. If you are using these images in virtual machines, be aware that you will need to install the modules into each one or they may have problems later. GNOME is broken on Debian/kFreeBSD: All of this exploit nonsense made me consider installing Debian/kFreeBSD on one of my machines to see if it was worth using as a desktop system. Sadly, it doesn’t work for me right now. I guess I’ll try back in a couple of months. Also, it’d be nice if a new install CD was released with the proper /etc/apt/sources.list (ftp.gnuab.org -> ftp-debian-ports.org).

Today is the end of a pretty long week-end of dealing with samba. About 10 days ago, we (the samba packaging team in Debian) were privately notified of security issues found by the Samba Team developers in this quite popular package. This very close to one of their bi-annual releases, namely 3.0.25. No less than three security issues were unveiled. Two of them (CVE-2007-2446 and CVE-2007-2447) affect all currently supported Debian releases, namely sarge, etch and sid. One (CVE-2007-2444) affects both etch and unstable. This was the beginning of long days of rehearsal, helped out by Noah Meyerhans from the security team. Finally, updated versions for sarge and etch were uploaded to oldstable-security and stable-security for the autobuilders to catch up (they still are catching up because I uploaded the updates without the .orig.tar.gz file, which unveiled a bug in the security autobuilders apparently). These updates for sarge and etch should be available as soon as the security team completes the final checks and approval, I guess. And, today, the Samba Team gave us early access to the newly released 3.0.25 version of samba so that we could build and upload that package 2 hours before it was officially announced..:-) Thanks a lot again to the Samba Team for their care and more particularly to Gerald "Jerry" Carter (someone I have deep respect for, along with Jeremy Allison and Andrew Tridgell). Thanks to Steve Langasek for his hard work preparing the 3.0.25 release (tracking down an upstream bug in the Pythin bindings build). And, finally, thanks to the Debian security team and more particularly to Noah Meyerhans for his work on backporting some of the patches. This was a tiring but really motivating week-end. I hope that all Debianers who use Samba will enjoy the result.

My face is covered in egg. Antti-Juhani Kaijanaho found a security problem in EoC, both the 1.0.3 and the 1.2.3 versions. The problem is that EoC did not quote shell arguments properly. I have fixed the problem in 1.2.4, which contains no other changes relative to 1.2.3. This problem has the code CVE-2006-5875. You can find the 1.2.4 version from the EoC website: http://liw.iki.fi/liw/eoc/ and I have also uploaded it to Debian's unstable. Debian's stable contains 1.0.3, and I have prepared a patch for that. It is actually essentially the same patch as was used to create 1.2.4. The Debian security team has uploaded a fixed version of the 1.0.3 package to security.debian.org. I've attached it to this message in case anyone not running Debian wants to stay with 1.0.3, but I won't be releasing a 1.0.4 unless someone really needs it (if you do, please tell me immediately). For risk assessment: I was unable to come up with an exploit. Doing so would require getting a certain kind of construct through the SMTP level to EoC, and I wasn't able to make that happen, but I would not rely on it being impossible. Therefore, please upgrade immediately. I apologize for this problem. It was amateurish to let the problematic code into a released version of the program, I knew better than do that.

I personally continue to work on Debian how I can but the Dunk Tank think made me thoght about the priorities that some people are putting in few (better, one) position only of project. I disagree completely how is this working and see, not too few people, reducing their work on Debian. Some are clearly not caused by this annoyance but others not. Why does our FTP Masters and NEW queue processing people are not included on that list of people that are receiving money to work? Debian Security team? Debian Installer team? Those teams has the same importance of RM team. Can we release without a propor security or lacking a Debian Installer? Of even, can we release without a good libc or a stable and well maintained GCC compiler? That “Dunk Tank” or, in my understanding, “How we workaround a project concensuos” thing, is wrong. Obs.: you don’t need to agree with me and that is my point of view.

Disclaimer: I am not comfortable with technical documents in my native language, German. I generally find German translations of technical stuff clumsy, overly complicated and badly worded. I might have a “special” feeling for the language, but some output of translators is just too bad to tolerate.For example, I constantly keep stumbling over the german translation of the Debian security team FAQ, which I consider horrendously badly done. Especially the use of the german word “Gutachten”, which basically means “opinion” in the legal sense (as the document produced by an expert called by a court of law) to translate “advisory” is a very very bad choice. My toes curl when I read the german version.In April 2005, I suggested to the German translation team to review the translation of the security team FAQ. I might not have chosen the right wording for that request, but besides a lot of flamage and “the translation is just fine”, I received the usual “send a patch”. Which I did in April 2005.No answer. In October 2005, I asked again, and received answer from the translator that my patch was just too intrusive. Well, a bad translation was rewritten, and the bad translation is still being used.Consequences for me? I’m not going to bother any more about German translations. English is just fine, and when somebody needs a German translation, I’m going to translate the stuff myself. Pointing people to the official German translations is just too embarrassing. A pity.

Before:

skx@desktop:~$ ssh security-master.debian.org groups
Password:
Debian webwml sec_data
skx@desktop:~$

After:

skx@desktop:~$ ssh security-master.debian.org -l skx groups
Password:
Debian security webwml sec_data

… or in other words I’m no longer a secretary of the Debian Security Team, instead I’m a full member!