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!