In case you've been living under a rock these past years, I shouldn't have to tell you what this is about :). Well, just in case.
The Google Summer of Code (GSoC) is an international program that offers student developers stipends to write code for various open source software projects. Debian has participated since 2006, mentoring dozens of students on Debian projects.

The important part of the 2009 edition of the Google Summer of Code is going to start next week with the Organizations application period (March 9th). By that time, we should have listed a reasonable number of ideas on the dedicated wiki page.

We will try this year to improve on the performance of the previous years, starting first with more and more dedicated manpower. If you have some time to spare to help manage our Summer of Code bid this year, we can make it a much better experience for the students and for Debian.

Help is immediately needed in many areas. Some examples:

• Map out which areas in Debian could benefit from a Summer of Code project and connect the right people with the right projects ideas


• Ideas, Ideas, Ideas for Summer of Code projects

By mid-March, we will need:

• Dedicated documentation to present Debian to the prospective student


• Publicity material to promote the Summer of Code at Debian


• Ideas, Ideas, Ideas for Summer of Code projects

Further in the spring:

• Mentors, people to review proposals, do interviews


• Ideas, Ideas, Ideas for Summer of Code projects

In the summer:

• Mentoring students


• Testing and feedback for projects


• Internal communication with the community

As you can see, there is much work ahead. It's time to pitch out your favorite pet project :)
Remember! The Summer of Code has become a prominent outreach forum for open source organizations. It puts a spotlight on each of them to provide a well-rounded and deep experience of open source development.

Right now, you can help with the Wiki, join us on IRC on #debian-soc on OFTC or join the mailing-list at soc-coordination on alioth.

The short "flyers-friendly" URL for the Summer of Code at Debian is : <http://wiki.debian.org/gsoc>. Publicize it!

See you this summer!

• Bulgarian, Khmer, Korean complete level 1
• Progress for Arabic, Danish, Turkish, Traditional Chinese
• Progress for Burmese (my), which is still prospective

Status for D-I level 1 (core D-I files):

• 22 languages 100%: bg cs de eo es fr it ja kk km ko mr nb nl pl pt ru sk sv th uk zh_CN
• 7 languages 99%: bs fa gu hi si ta te
• 3 languages 97%: ar eu tr
• 3 languages 96%: be he sr
• 3 languages 95%: bn dz zh_TW
• 5 languages 94%: ast da ga id ro
• 4 languages 93%: el hu is lo
• 1 language 92%: sl
• 3 languages 91%: et pa vi
• others are 90% or below

Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.):

• 14 languages 100%: cs de es fa fr it kk nl pt ru si sk uk zh_CN
• 9 languages 99%: be bg da eo id ja sl sv th
• 4 languages 98%: ca eu pt_BR ro
• 1 language 97%: is
• 1 language 96%: nb
• 3 langauges 95%: el fi he
• 7 languages 94%: ar ast dz gl hr vi zh_TW
• 8 languages 92%: bn bs hu ko ne pl sr tr
• 9 languages 91%: ga gu ka km lt mk mr ta te
• others are 90% or below

Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader)

• 26 languages 100%: be bg bs ca cs de el eo es fa fi fr ga gl is it ja kk nb nl pt ru sk sv th tr
• 4 languages 98%: he hu uk zh_CN
• others are 90% or below

Full 100% completeness (hall of fame) for: Czech, German, Spanish, French, Italian, Kazakh, Dutch, Portuguese, Russian, Slovak

So, at work we have a little single port IP KVM, it is a StarTech SV1107IPEXT - it's not a "bad" bit of kit, if you're completely configured for using it in the way they expect... When you're not, then it throws a NullPointerException when you try to connect with it's Java applet. This morning (mostly because the monitor and keyboard I had been using for building stuff on my desk has gone missing) I decided I'd try again with the device, it's not on our default office network range, mostly because it might not always be in the office, so I quickly added an ip alias using ip addr add 192.168.0.59/24 dev wlan0 on my laptop to bring up a route to it. Navigated to the page and asked it to fire up the Java applet. Straight off, a NullPointerException happens - hmm. So looked at what was being logged by the JVM - it was trying to run ifconfig (no, really, the java applet ran ifconfig... with no path...) which, on my debian laptop, is not in the default path... so I went and make a quick wrapper in ~/bin for it... right - now it can run that... still a NPE, hmm. So look a little closer, it's looking for the MAC address assigned to the IP that you're coming from... no, really! WTF! So I went and hacked my little ifconfig wrapper to rewrite the address for wlan0 to be what the KVM expected it to be, low and behold, I can now run the java client (hoorah!). Why the heck are they doing that though - that's just plain insane! On the plus side, I now have a work around, on the minus side, egad that's ugly!

As sort of new year's resolution I started picking up the habit to work on release critical bugreports for squeeze again. The number is way to high to be healthy, but at least it is (still) below the amount of release critical bugreports for unstable. It will be an uneven fight because it seems that there are quite some people working on weeding out release critical bugreports in unstable, but those who are interested in weeding out releasing critical bugreports in stable seems to be limited, even though it is one of our supported releases and thus should receive quite some attention, at least by the corresponding package maintainers themself. So here is the list that I managed so far:

• 651792: not relevant for squeeze
• 653520: builds on squeeze
• 654568: re-add version information lost in reassign
• 654276: not relevant for squeeze
• 654257: not failing on squeeze
• 654810: not happening on squeeze
• 654459: not relevant for squeeze
• 654406: not release critical at all, shipped as upstream
• 655007: python2.7 isn't default in squeeze
• 655372: doesn't fail in squeeze
• 527403: libjack-dev in squeeze provides libjack0.100.0-dev
• 622903: not relevant for squeeze
• 625764: squeeze has older version of libvelocity-tools-java, not affected
• 654818: does work in squeeze
• 647795: squeeze still has libahven1-dev
• 647796: squeeze still has libahven1-dev
• 636823: not obsolete in squeeze
• 628500: no perl 5.14 in squeeze
• 629255: no perl 5.14 in squeeze
• 629284: no perl 5.14 in squeeze
• 629293: no perl 5.14 in squeeze
• 636132: no perl 5.14 in squeeze
• 636268: no perl 5.14 in squeeze
• 636271: no perl 5.14 in squeeze
• 636517: no perl 5.14 in squeeze
• 636520: no perl 5.14 in squeeze
• 636521: no perl 5.14 in squeeze
• 636522: no perl 5.14 in squeeze
• 636823: not obsolete dependencies in squeeze

That makes 29 squeeze RCs squashed so far, I hope I can keep up with it. Enjoy!

/debian permanent link Comments: 2 Flattr this

Like last year, here s a list of Debian related goals that I d like to achieve this year. I might not have the time to implement all the projects, but I like to write them down to keep me motivated. And maybe it can inspire other people to implement some of them (or to help me).

1. Finish the translation of the Debian Administrator s Handbook The target is to have the book available in April. It would be nice to complete the liberation fund until then so that the book is immediately made available under a DFSG-free license.
2. Update the Debian Administrator s Handbook for Wheezy
Translating the book in English is only the start of the journey. The real challenge is to keep the book up-to-date with each subsequent release of Debian. And Wheezy should hopefully be released in 2012 since the freeze is in June.
3. Design and implement the Debian Package Maintenance Hub It s an ambitious project that aims to merge and replace the PTS, the DDPO and their respective mail variants. It should also standardize the flow of information directed towards package maintainers. I m going to use the DEP process to drive this project. This could easily take most of the year, but hopefully I ll motivate other people to chime in and help.
4. Implement dpkg --check-db and dpkg --repair-db While dpkg is fairly reliable, it s not exempt of bugs and more annoyingly, harddrives/filesystems are not 100% reliable either, thus it happens that some internal database files get corrupted. Given that most files are text based, advanced users can manually fix them but many less skilled users are just left with a broken system that they tend to reinstall. To avoid this, we could provide a command that would try to automatically bring back the internal database to a sane state by looking for a working backup to restore (while at the same time marking some packages as requiring re-installation since we have some indications that they were present).
5. Implement storage of dpkg s internal files in Git This would be an extension of the former idea. Installing a package dpkg-db-history (any idea for a better name?) would setup dpkg hooks that would record every database change in a git repository. This repository could then be used to restore the last working version of the database.

Besides those concrete projects, I want to do better than last year on the topic of funding my Debian work. I will thus reiterate some objectives:

1. Write useful articles for Debian users and Debian contributors. They should complete the pages Mastering Debian, Contributing to Debian 101, Debian Packaging Tutorials, and help me increase the audience of this blog.
2. Write at least one Debian-related ebook (different from the Debian Admin Handbook) and sell it. It could be an ebook targetting testing users since I believe that many more users could benefit from it if they had some better knowledge of the limitations and of the way to mitigate the problems that arise from time to time. Or maybe it could be an ebook for people who want to start contributing to Debian, it could even be bundled with a few hours of mentoring.
3. By the end of the year, have at least 1/3 of my time funded by donations and/or earnings of my information products. This means doing 3,5 times better than in 2011. It should be doable given that the sales of the Debian Administrator s Handbook will contribute to this goal (once the translation is over).

That makes up lots of challenges for this year. Feel free subscribe to my newsletter to stay up-to-date with my progress and to get my monthly summary of the Debian/Ubuntu news. It s also a good way to help me reach those goals since you will be informed of all my new projects.

11 comments Liked this article? Click here. My blog is Flattr-enabled.

Just recently arrived from DHL, a solid-run CuBox. I guess nobody who knows me will be surprised when I tell it features an ARM cpu. Specifically an Marvell Armada 510. It features ARMv7 compatibility, with a slight twist of replacing NEON extensions with iWMMX extensions. On the boasting side Armada 510 promises 1080p video decoding and OpenGL ES graphics acceleration (closed source, unfortunately).
The tiny form factor of CuBox is pretty much more than the impressive amount of connectors included;

* Gigabit ethernet
* 2*USB
* eSATA
* HDMI out
* s/pdif optical audio out
* microSD slot
* microUSB serial/jtag port

The last item being important as it makes CuBox unbrickable.. Some will probably lament the lack of WiFi/Bluetooth, but get everything in one device ;). Besides, the USB slots are there to be filled..
Getting started was an slightly rough ride, as in the included Ubuntu (10.04 LTS), X refused to start. After wrongly suspecting that my Display was at fault, turned out the microSD included was slightly corrupted, and some critical contents of xkb-data package were garbage. After reinstall of that package, everything worked, including playing Big Buck Bunny in FullHD with totem.
Biggest disappointment so far is the non-mainline kernel, based on old 2.6.32.9. Some mainline support of Armada 510 exist, but will it work with the proprietary graphics code?

I ve written before about joining Singly and a little bit about the open source software we re building. There s now a bit more content on our website too, or you could watch my colleague, Jabber founder Jeremie Miller, talk about it on stage.
Suffice to say, it s pretty interesting stuff, and we need more interesting people to join the team in order to achieve our goals in the next year. In particular, we re looking for engineers to build highly flexible, resilient and performant back-end infrastructure using Ubuntu, and innovative, usable and beautiful front-end interfaces using HTML5. For full details and how to apply, check out the Singly blog or contact me directly. At this time, we have a preference for candidates in the San Francisco bay area, but are open to exceptional candidates from elsewhere.

Oh, shit yet another step to shrink the public domain.
Filed under: Free software licenses

As a Debian administrator, power user or contributor, one often goes to look for information about a package, a bug, a developer or a message from the mailing lists. If you are in this case, you may be interested in the Firefox/Iceweasel extension Debian buttons , written by Damyan Ivanov and packaged by myself. Description When installed, this extension provides five buttons, that you can place in your Firefox or Iceweasel toolbar. These buttons take the text from the X11 PRIMARY selection and act as shortcuts to the web pages corresponding to:

• a package from the archive;
• the development of a package (Package Tracking System);
• a bug report (Bug Tracking System);
• a Debian Developer's packages (Developer's Packages Overview);
• a message from the mailing-lists.

Typical use case Let us imagine you see the following sentence on IRC:

12:42 < Tanguy> I am packaging a cool Firefox/Iceweasel extension (ITP #654896)!

If you want to check out the corresponding ITP report, just double-click on the bug number to select it (do not worry about the leading hash or even the possible trailing bracket, it will be handled), and click on the BTS button on your browser toolbar: here you are! Depending on your needs and habits, this extension may considerably speed up and simplify your quests for information. At least, it does for me, so I hope you will enjoy it too!

I was on the brink of mindlessly clicking through the ACLU action center as usual to send an email opposing SOPA. But then I read their boilerplate text, and ended up cancelling the letter to my rep and instead sending this quick note to the ACLU:

Your SOPA suggested letter text supports current copyright law, and also backhandedly supports PIPA (the Senate version of the bill). This is far too weak of a position. As a donor, I ask you to take a stronger position that current copyright law unjustly restricts free speech, and that no further enforcement measures should be instituted until that fundamental problem is addressed. At least take on BOTH of these bills strongly. Most of the significant Internet is blacked out today to oppose both bills -- why would you cede so much ground to copyright maximalists? We have the support to oppose and defeat both bills.

For reference, here was their text:

While I believe it's important to protect copyrighted material online, the language of the Stop Online Piracy Act (SOPA) is flawed and will lead to the blocking of lawful content. Unlike the Senate version of the bill, SOPA eliminates the concept of sites 'dedicated to infringing activity' and enables law enforcement to target all sites that contain some infringing content -- no matter how trivial. The potential for impact on non-infringing content is much greater under SOPA than under other versions of this bill. Sites with user-generated content, like YouTube, Twitter, and Facebook, would be especially vulnerable, as one small piece of infringing content could lead to blocking the entire site. Even though proposed changes would narrow the amount of lawful content impacted, the changes don't go far enough. It is still likely that search engines will end up blocking access to perfectly legal online content. Congress should focus not just on the goal of protecting copyright owners, but also protecting the speech rights of consumers and providers who are reading and producing wholly non-infringing content. Congress must eliminate the collateral damage to protected non-infringing content. Only in that way will Congress truly achieve its goal of protecting authors while respecting the constitutional right to free speech.

Maybe I'm overreacting, but I dislike it when good organizations take weak positions unnecessarily. Usually this is not a problem with the ACLU, for me. It doesn't help that I keep seeing this meme everywhere in the anti-SOPA/PIPA conversation: "I agree we need to do something about piracy, but not this..." I don't think we need to do anything to fix violations of an extraordinarily unjust law until the law itself is fixed. I don't find that to be a very radical position.

Once again, lawmakers are considering a stupid protectionist measure and this time it s the US, so it has some effects outside the US too. Once again, some websites have taken themselves offline and caused great inconvenience to their supporters. This is really annoying. Protesting about threats to take websites offline by taking websites offline is as stupid as protesting against a ban on kissing by not kissing. It just demonstrates that you can do without your websites/kisses if you must. I feel it s much better to use websites to distribute information and call people to action, like this epetition for UK citizens and residents, or by asking your associations and suppliers to oppose these measures and their supporters. Wikipedia is probably a bit to blame. Although it called its action a blackout, it wasn t one and there were still many ways to access its information. In fact, if you use NoScript, the banner didn t even display and there s only a line on the front page to say anything is happening. The one that really annoyed me was identi.ca, which even turned off its API so clients just started spewing errors everywhere (I returned to my desk to a stack of retry questions). That stopped some of my websites from distributing a link to the anti-SOPA epetition because they read from my identi.ca stream how much other anti-SOPA activism was hindered? I ve been told that Evan held a vote, but I didn t see it, so I didn t vote and I don t know the turnout or anything. How many people voted for the blackout because they use other sites like twitter more anyway? Banners: yes; Blackouts: no.

Yesterday, I uploaded hdf5 1.8.8 in unstable. This new version, which has been available in experimental for a while, is a major step in the HDF5 packaging. For those who are using this package, besides the switch from version 1.8.6 to 1.8.8, the changes are the following:

• Since upstream is now trying to keep a consistent ABI/API, packages have been renamed from libhdf5-xxx-X.Y.Z (X, Y and Z being the version number) to libhdf5-xxx-7 (7 being the version of the soname)
• The package libhdf5-serial-* have been renamed to libhdf5-7 or libhdf5-dev
• Symbol files have been added for all the libraries.
• arm archs have also libhdf5-openmpi-dev
• Support of HURD, armhf & s390x
• Help is now up to date and the debian/html.tgz.uu removed (thanks to the source format v3.0, two source tarballs are now used)
• A new package hdf5-helpers which contains h5cc, h5c++ and h5fc has been introduced
• Fix many lintian warnings
• Java HDF has been updated to version 2.8

More information about the transition:
http://release.debian.org/transitions/html/hdf5.html TODO: Fix the FTBFS (Fail To Build From Sources) under sparc & ia64.

Those lovely people over at Flickr have finally bitten the bullet and are turning off FlickrAuth in the summer, meaning that all applications that use the Flickr API need to use OAuth. This is something I totally agree with, whilst FlickrAuth works and was clearly an important influence on OAuth, it's a single-service protocol when OAuth has managed to get massive adoption and a huge developer base. The problem I've got is libsocialweb, which has a Flickr module that allows both fetching of your contact's recent photos and uploading images. This uses FlickrAuth so at the end of July will suddenly stop working. I've got enough on my plate at the moment and would love for more people to understand how the entire social spagetti works, so this is a call for a volunteer to work on this, for which I'll obviously be available to offer any guidance and mentoring required. There are two ways of approaching this, the easy way and the slightly harder way. The easy way is to update libsocialweb to use an OAuthProxy instead of a FlickrProxy, and update the module metadata so that Bisho uses the generic OAuth flow instead of a Flickr-specific flow. This should be fairly simple and needs to happen soon so that any distributions that are using libsocialweb don't break in the summer. The harder way is to add Flickr support to gnome-online-accounts, using the Twitter service as an example, and then port the Flickr service in libsocialweb to use gnome-online-accounts to authenticate. I've a proof of concept for the librest-goa integration which will be a useful starting point. This is more of a proof of concept for libsocialweb, we've been looking at moving away from Bisho but haven't done anything substantial yet. Ideally both of these happen, so the current code will continue to work in the future and the GOA work demonstrates how GOA and libsocialweb would work together. So, anyone interested?

Just a short announcement: yaWP 0.4.2 is available from Debian Sid and should enter Testing (Wheezy) in ten days. One of the main changes (compatibility with KDE SC 4.7+) isn't affecting Debian yet, but the fixes to e.g. the Wunderground ION are nice to have (no matter which wheather frontend you use). Thanks to Ulf, the current main upstream developer, for keeping yaWP the (in my partial opinion) best weather Plasmoid out there! Now a little request to the various users around the world: It'd be nice if some of you would upload a screenshot of your yaWP instance to screenshots.debian.net in order to get a little variety on the package page for plasma-widget-yawp. Other themes or usage in the bar would be most welcome.

The increasing storm of localization NMUs and uploads, related to debconf translations, has an interesting effect: some teams are now incredibly active at pushing translations for their language towards the magic 100%. So, after Danish (effort lead by Joe Hansen) and Dutch (effort lead by Jeroen Schot) which I already mentioned, it seems that the Italian localization team started engines and is now taking off. It will be interesting to watch these teams competing (in a friendly way) to climb in statistics over next months..:-) So, if you're Italian (or speak it well) and want to help, please join the Italian l10n mailing list (debian-l10n-italian on lists.debian.org. If you're Danish or Dutch and want to stay ahread the two others, please joind debian-l10n-danish or debian-l10n-dutch. PS: why did I write "Zou" in this post's title? Because this is a common French interjection for "Whoooosh" and because this is part of the nickname of the tireless and incredibly active, in many places, Francesca Ciceri, aka MadameZou, who's is doing so much for Italian localization (and many other areas in Debian such as the publicity and web team). And that really deserves some lights, trumpets, etc.

Finally I've also find time to test ColorHug on openSUSE 12.1. For my experiences on Debian check previous blog post. Unfortunately on openSUSE calibration is also not that easy. First of all, you have to install patched argyll CMS from multimedia:color_management repository. You can also install gnome-color-management (and colord), but for some reasons they did not offer me any screen for calibration, so I gave up on this and tried manual calibration using Argyll. After looking into documentation, it seems to be pretty straightforward:

$ dispcal -y l -o /tmp/L220x
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Display adjustment menu:
Press 1 .. 7
1) Black level (CRT: Offset/Brightness)
2) White point (Color temperature, R,G,B, Gain/Contrast)
3) White level (CRT: Gain/Contrast, LCD: Brightness/Backlight)
4) Black point (R,G,B, Offset/Brightness)
5) Check all
6) Measure and set ambient for viewing condition adjustment
7) Continue on to calibration
8) Exit
Doing check measurements
  Current Brightness = 190.74
  Target 50% Level  = 36.14, Current = 47.98, error =  6.2%
  Target Near Black =  1.91, Current =  4.11, error =  1.2%
  Current white = x 0.3424, y 0.3179, VDT 5910K DE 2K 18.3
  Target black = x 0.3424, y 0.3179, Current = x 0.3123, y 0.2711, error = 18.06 DE
Press 1 .. 7
1) Black level (CRT: Offset/Brightness)
2) White point (Color temperature, R,G,B, Gain/Contrast)
3) White level (CRT: Gain/Contrast, LCD: Brightness/Backlight)
4) Black point (R,G,B, Offset/Brightness)
5) Check all
6) Measure and set ambient for viewing condition adjustment
7) Continue on to calibration
8) Exit
Commencing device calibration
The instrument can be removed from the screen.
$ dispwin -I /tmp/L220x.icc 
$ dispwin -L

It turned out, that the change after calibration are quite minor here. This is sort of thing I've expected from past experiences with editing photos here, but anyway, now I trust results here even more :-).

Filed under: English Photography Suse 0 comments Flattr this!

I wrote about the technical details of supporting the UEFI secure boot specification with Linux. Despite me pretty clearly saying that this was ignoring issues of licensing and key distribution and the like, people are now using it to claim that Linux could support secure boot with minimal effort. In a sense, they're right. The technical implementation details are fairly straightforward. But they're not the difficult bit.
Secure boot requires that all code that can touch hardware be trustedRight now, if you can run unstrusted code before the OS then you can subvert the OS. Secure boot gives you a mechanism for making sure you only run trusted code, which protects against that. So your UEFI drivers have to be signed, your bootloader has to be signed, and your bootloader must only load a signed kernel. If you've only booted trusted code then you know that your OS is safe. But, unlike trusted boot, secure boot provides no way for you to know that only trusted code was executed. That has to be ensured by OS policy.

This doesn't sound like too much of a problem. But it is. Imagine we have a signed Linux bootloader and a signed Linux kernel, and that these signatures are made with a globally trusted key. These will boot on any hardware using secure boot. Now imagine that an attacker writes a kernel module that sets up a fake UEFI environment, stops the kernel from running code and then executes the Windows bootloader - kind of like kexec, but a little more fiddly. The Windows bootloader believes that it's performing a secure boot, but in fact everything that it believes is trustworthy is the attacker's fake UEFI code. The user's encryption passphrase is logged, the Windows kernel is modified to hide the Linux code and despite everything looking fine your credit card details are on their way to China. In this scenario, the signed Linux kernel is simply used as a malware loader. The only sign that anything is wrong is that boot will be slightly slowed down.

Signing the kernel isn't enough. Signed Linux kernels must refuse to load any unsigned kernel modules. Virtualbox on Linux? Dead. Nvidia binary driver on Linux? Dead. All out of tree kernel modules? Utterly, utterly dead. Building an updated driver locally? Not going to happen. That's going to make some people fairly unhappy.

(The same applies to Windows, of course. Windows 7 allows you to disable driver integrity checks. Windows 8 will have to forbid that when the system's using secure boot)
LicensingGPLv3 has various requirements for signing keys to be available. Microsoft's new requirement that systems support the installation of user keys would let users boot their own modified bootloaders, so that may end up being sufficient to satisfy the license. But we're then beholden on Microsoft - if they remove that requirement then users lose that freedom, and suddenly we're in an awkward licensing situation. There are ongoing conversations about exactly what we're able to do here, but it's not a solved problem.
Key distributionThe UEFI spec doesn't describe or mandate a central certifying authority. Microsoft require that everyone carry their key. We could generate our own, but we have much less sway with vendors. There's no way to guarantee that all hardware vendors will generate our key. And, obviously, if we generate a key, we can't just hand the private half out to others. That means that it becomes impossible for people to produce derivative versions of Linux distributions without getting their own key. The kind of identity verification that would be required for getting such a key is likely to be expensive, and also fairly likely to require that the distribution have a legally registered company in order to facilitate the identity verification. Think Extended Validation certificates, not Startssl Free. Hobbyist Linux distributions will be a thing of the past.
Doesn't custom mode fix this?Microsoft's certification requirements now state that all systems must support a custom mode, implying that it will be possible for a user to install their own keys. Linux vendors would then be able to ship with their own keys on the install media and impose their own policies. Everyone's happy. It's not really good enough, though. People have spent incredible amounts of time and effort making it easy to install Linux by doing little more than putting a CD in a drive. Asking them to go into the firmware and reconfigure things adds an extra barrier that restricts the ability to install Linux to more technically skilled users. And it's even worse than that. This is the full description of the requirement for custom mode:

1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
   
2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with Secure Boot turned off.
   
3. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.

There's a few things missing from this, namely:

• Any description of the UI. It's effectively impossible to document Linux installation when the first step becomes (a) complicated and (b) vendor specific. Vendors are using the UEFI transition to differentiate themselves by coming up with their own unique firmware interfaces. Custom mode is going to look different everywhere.
• Any description of the key format. A raw binary representation of the key? An EFI_SIGNATURE_DATA struct? A base64 encoding of one, further protected with ROT13? We just don't know.
• Any way to use custom mode for unattended installs. It's a firmware interface that requires a physically present user. Want to install a few thousand machines over the network? This isn't a scalable approach
• and this one's nitpicking, but there's not actually any requirement that the user be able to add keys - a vendor could conform to this language by only letting users delete keys. This is actually ok as long as the user deletes Pk, because then we'll effectively be back in setup mode and can install our own keys from the installer, but it still results in some practical problems

So no, custom mode doesn't make everything ok. Custom mode with a mandated UI and a documented key format would be much closer, but it wouldn't solve the problem of unattended automated installs.
SummaryWe can write the code required to support secure boot on Linux in a minimal amount of time - in fact, most of it's now done. But significant practical problems remain, and so far we have no workable solutions for any of them.

comments

The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the starsand in the middle you see the blue centerlight pop and everybody goes Awww!

~Jack Kerouac

For some reason my involvement with Fosdem is going up, not down.

So I will certainly be there, find me hacking the network again. Learning QoS in a trial by fire :).

This entry was originally posted at http://pvaneynd.dreamwidth.org/147845.html. Please comment there using OpenID.

Yesterday, I've unpacked new toy - ColorHug. It came in small packet with CD (which is unfortunately not that useful as it should be), mini USB cable and a letter from Richard Hughes. First attempt to use was of course just connect and make it work :-). The basic access works out of the box:

$ /usr/lib/colorhug-client/colorhug get-firmware-version
1.0.3
$ /usr/lib/colorhug-client/colorhug get-hardware-version
Hardware Version 1
$ /usr/lib/colorhug-client/colorhug get-serial-number
000019

Unfortunately calibration with colord does not yet work out of the box on Debian due to bug 655888. Hopefully it will be fixed soon and it will work nicer. For now you have to rebuild Argyll with Colorhug support (with extra pain caused by Debian package using different build system than upstream). I won't provided binary packages as I pretty much gave up after effort to build clean packages from same sources on i386 and amd64, which always failed on patched autoconf based build system. Side note: I somehow hoped that I won't hit new (in meaning that I don't know them) open source projects which do not use some version control. Unfortunately Argyll CMS is one of such projects... After this update (and restarting GNOME), when connecting ColorHug, the Gnome Color Manager pops up and man can calibrate the screen. The biggest problem is to make ColorHug hold on desired place on screen, if it is not close enough to screen, you will get really bad results. The first result is of course far from being perfect, but colors are definitely better than without calibration or with ICC profile shipped with notebook.

Filed under: Debian English Photography 0 comments Flattr this!