Codehelp blog

*.myopenid.com - page security information.
Equifax Secure Global eBusiness CA-1
PKCS #1 MD5 With RSA Encryption

Same for https://www.myopenid.com/signin_password and the same for the myOpenID.com SSL certificates that you actually use with myOpenID.com - all now known to be vulnerable to spoofing. I don't think I'll be using those any more.

SSL spoofing via MD5 certification

CA's using only MD5 to sign the certificate

Oops.

It depends on how you use OpenID I suppose, but if known weak certificates are removed from browsers in order to protect users from possible SSL spoofing, current myOpenID.com certificates will simply stop working.

Not really a surprise considering how Canonical came to exist but, Launchpad OpenID has got it right. Launchpad itself doesn't use a CA that relies solely on the weak MD5. Maybe I'll start using the Launchpad OpenID instead. (Launchpad OpenID still works with the Alioth OpenID support). However, it would be nice if the Launchpad OpenID could provide SSL certificates for users to import into browsers and then I could log into various sites directly. I did like that functionality with myopenid.com but those certificates have had to be revoked now.

Gold stars for Ubuntu and the Alioth admins. A pile of stinky brown stuff for the myopenid.com team.

Update:
Maybe it's time for Alioth to support OpenID more fully? Or there again, maybe not. After a little reading up on the multiple failings of openid in general, I'm going to leave openid as it is (mostly disabled in my case) and use it only for stuff that really doesn't matter much. Using openid for important stuff just doesn't make any sense.

Something that's bothered me and Emdebian in general for months is that it should be simple to compare two repositories and work out which packages need to migrate, which are behind etc. using perl. apt-cross has had rough support for this for some time but it isn't general - it relies on the apt perl bindings.

Recently, the shell scripts for Emdebian Grip became too complex to maintain long term - and far too slow. The main reason was the difficulty in getting all the relevant repository data into memory within a shell scripts. So, I turned to perl and the result is the tenth package to be derived from emdebian-tools source: libdebian-packages-compare-perl - Debian::Packages::Compare - emdebian repository comparison support. So far, it is meant to run on the server because various elements of meta-data need to be read from the repository configuration and that means relying on reprepro. In time, I hope to extend it so that this meta-data can be set arbitrarily so that the module only requires a pair of Packages files - at which point it can be extended to handle a Packages.gz file too (it already looks for and handles the Sources.gz file). The module includes bespoke handling for Emdebian TDebs and the locale root layout.

It reads the Packages file, create a hash of Package and version - once per arch, one per suite, one pair per repo. The underlying libparse-debian-packages-perl is a very simple module, there probably isn't any point putting extra data into the comparison hashes, get the data necessary and load the full Packages data separately using get_single_package.

This module is currently tied to the repository layout used by reprepro in order to identify the architecture list and various other pieces of meta-data. In time, functions can be added to provide such lists.

The module expects to find all repositories beneath a single base directory:

$base/$repo_name/conf/distributions

If $base is undefined or if the repository directories cannot be found, subsequent functions each return undef.

etc.

Example code:

use Debian::Packages::Compare;

my $base = '/path/to/repositories/'
&set_base($base);

my $debu = &read_packages ('unstable', 'filter');
my $gripu = &read_packages ('unstable', 'grip');
my %debianunstable = %$debu if (defined $debu);
my %gripunstable = %$gripu if (defined $gripu);
foreach my $pkg (sort keys %debianunstable)
{
if ($debianunstable{$pkg}{'source'} ne $gripunstable{$pkg}{'source'})
{
# $pkg is either not in grip repository or is a different version
}
}


The main features for subsequent versions will involve more verbose error handling.

Currently just in Emdebian SVN, I'll be releasing to Emdebian fairly soon. If there's interest, I could put it into experimental but I think it needs that meta-data handling code first.

Debian::Packages::Compare.pm.

So the failings of the GR result in just what everyone didn't need - a restarted discussion about the firmware issue without first releasing Lenny. Come on people, leave it alone and get Lenny done. Anthony, Thomas and Theodore (also in his blog) all seem to be missing the point(s):

• We had the GR and despite all the manifold failings of the GR itself, Further Discussion FAILED as did the option to delay Lenny ad infinitum (Option 1 on the vote).


• Everyone seems hung up on firmware as something that requires source code, when the real point is that firmware isn't necessarily like other content in Debian and in some (many?) situations, there is no, nor can be any, human-readable form - it really can be nothing more than a series of initialisation flags, not instructions that are specific to that chip or would not make any sense to any CPU.

To me, it's more like data for the chips - it's saying "this is who you are, this is what you do and this is how to understand all subsequent instructions". Software is what follows - the instructions themselves.

We have a very good understanding of the separation between software and data in userspace - we all recognise that unless the output of a program consists to a large extent of modified versions of already licensed code (e.g. code generators), then the data created by your free software GPL-3+ text editor (or blogging client) cannot be deemed to be under the GPL-3+ or any other licence until such a statement is made by the copyright holder and that the copyright holder is the user of the software, not the author of the software. I could quite easily put this blog under a Microsoft-style EULA or even NDA if I wanted to be obtuse, despite it being created using a free software stack. The point remains - I am the copyright holder of the content created using the free software on my machines and I am free to publish that data as I see fit. The authors of the software itself have no rights to dictate what I do with the content I create using the software, just as I - as a user - cannot dictate whether the authors of my editor choose to migrate from GPL-2+ to GPL-3+ or even BSD.

Where firmware can have source code, let it have source code - we have such packages in Debian already. Even then, much of the code may be simply calculations or conditionals to select the right combination of binary flags for specific situations. This isn't about Nvidia kernel drivers that do real runtime calculations during the entire runtime of the machine, this is about tiny bits of initialisation data that are set once and not touched again. Can we not accept that some firmware is derived from a process that does not involve source code? How about experimentation and calculation? We know the voltage on pins 5 and 19, we know the state of register A and that for this specific case, it needs to be toggled to match the state of register E because otherwise another chip on the same board gets confused, so setup the chip to do that by setting a firmware datum point to initialise A? Where's the source code in that process? There is none - it is a piece of data, an item in the design notes (or more likely the errata). Yes, maybe the chip should know how to set this datum itself but for whatever reason (probably financial), it doesn't.

Source code could be used to calculate the datum point for a range of chips and chipsets according to a range of data inputs but the creative effort is then in the calculation not the data. The chip doesn't want the calculation, it cannot perform a calculation in this uninitialised state, it needs the datum point. Once it has the registers set, it can then understand subsequent instructions - the software itself. The datum point itself is just a raw piece of initialisation junk for the chip, it has no source code, it is determined by a physical process. It is a reference point - a fixed value that is determined during the design of the chip and/or chipset.

It's like saying you want the source code that determines whether there are one hundred cents in a Euro so that you could modify it to create a thousand or just ten or maybe turn the Euro into a hexadecimal currency. Weird. The fact that the Euro has one hundred sub-divisions is not up for negotiation, it isn't a modifiable value - changing the value unilaterally is not going to magically make everyone use the new value. It is a fixed reference point - a single datum point that initialises all subsequent behaviour of all software utilising such a currency. Even if there was source code (gee, what could that be, do you think? "%.2i" ?) it would be meaningless to insist on being able to modify it.

Few people can make the judgement about whether particular firmware can or cannot have source code - in most cases it comes down to the hardware design of either just the chip or how the chip is utilised for a particular board.

At some point, Debian has to accept that we cannot know if source code was used to create a particular blob. We simply have to ensure that maintainers ask upstream, elucidate as much information as possible about how the firmware was created and document that in debian/copyright. If that information is proved to be incorrect, then we have to deal with it as best we can - on a package-by-package basis. The assumption has to be that firmware does not necessarily have any source code.

In the end, I think the GR came up with the right result, despite all the failings - Option 5, assume that firmware is compliant with the GPL unless there is evidence to the contrary.

Sometimes, there simply is no source code - sometimes all you have is data.

Debian cannot insist on source code for data that is not generated from source code and it is the difficulty in deciding whether one set of figures is initialisation data or a set of compiled instructions that will defeat all debate on a general solution for the firmware debate. It is comparing apples and oranges - we can insist on source code where source code was used but we also have to accept that some firmware is identified, not programmed. In the end, Debian will have to trust the maintainer and the maintainer will have to trust upstream. Documenting that in debian/copyright seems to be the only sane option.

Now can we all just shut up and release Lenny? Please?

Following a thread on Planet GNOME, I decided to add a few more warning options to my main upstream projects. I started with:
-g -O2 -g2 -Wall -Werror -Wdeclaration-after-statement -Wno-pointer-sign -Wcast-align -Wbad-function-cast -Wmissing-declarations -Winline -Wsign-compare -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wl,--as-needed


I'm adding -Wredundant-decls (which itself has highlighted a bug in QOF 0.7.5, fixed in 0.8.0 SVN). and -Wwrite-strings which caught lots of nasty bugs. (You know the ones, you're confident that a string is newly allocated and needs a g_free but then the program seg.faults in operation and you can't find why?) Also added -Wformat-security, -Wswitch-enum, -Winit-self - the first one to not cause any new errors and -Wmissing-include-dirs (which I'm glad to say raised no errors because it is checking my autotools foo). Test project for this run: pilot-qof. Changes now in CVS (yes, CVS - why not? pilot-qof is stable enough that it doesn't need any of the SVN features that caused migration of other projects).

Later, I'll add the same warnings to QOF and gpe-expenses upstream.

Sticking with the theme that blogs are all about completely biased and probably controversial opinion and not much else, I'm glad that Thomas has made his thoughts clear. Thomas - I fully agree (but your blog doesn't support comments, so I'm putting it here).

Debian, to me, needs to about Quality over quantity (being very aggressive over orphaned packages and their reverse dependencies) and about everyone working towards the releases. Not to pick arbitrary time-based deadlines for releases but actively fixing release-critical bugs, so that the release can proceed smoothly with stable, reliable packages. Debian developers who feel unable to fix release critical bugs maybe should not be developers any more - or at least be banned from mailing lists on lists.debian.org which appear to be the only "contribution" being made.

There's no reason to continue using Gtk1.2 and no point in complaining about it because there is no prospect of anyone stepping up to maintain gtk1.2 itself. There is therefore no point in the long threads complaining about removing gtk1.2 because nobody is going to do any work to retain gtk1.2.

If you aren't prepared to do the work, you should not feel you have any rights to complain about the lack of such work being done. We're all volunteers - don't expect someone else to sift the wheat from the chaff, get rid of your own cruft. Debian needs to be an association of people who do, not the current association of people who complain, moan and generally fight amongst themselves. The answer to this negativity is a can-do attitude - it is not as if there aren't enough problems out there to fix, get out there and raise the quality. (First though, get Lenny released.)

Not everyone can do the same amount of workload but within the work that you are able to do, there must be a balance between the work you do for yourself and the work you do for the distribution. I'm not expecting people to have to match my levels of output, I am expecting people to match the proportion of time that they allocate to fixing problems outside their own limited niche. If that proportion approaches zero then maybe Debian doesn't need you any more.

There is no reason to have project members who do not contribute to either quality or releases - that doesn't just mean not fixing bugs, it means not being a part of any team or other group in Debian that provides support for general quality or the release.

If you aren't fussed about the quality of packages (in general, not just your own) and aren't willing to contribute just a small amount of your time to use your privileges to fix release-critical issues, then those privileges should be removed - you obviously don't need them. (Also, if you aren't a DD yet and you want sponsorship, these rules apply to you too. I won't sponsor people who have no feel for quality or want to help Debian make releases. I'm beginning to wish other sponsors would do the same. Quality is far more important than quantity - merely adding packages because they exist and because someone posts a request for a sponsor is insufficient. Completely insufficient, counter-productive too. See my sponsorship requirements.)

Note: this post is entirely opinionated and I don't care if you disagree. I will take a particularly brutal approach to comments that do not grasp this fact.

Taking on from Wouter's post on metablogging, I can only say that official sounding blogs are very off-putting and I stop reading them very quickly. If a blog (or more typically the blogger) starts thinking too much of their blog, considering it an enduring reference or a permanent piece of documentation then that blogger is deluded. A typical sign of such a blog is a long list of references at the end and topics that try to stipulate how other people should blog.

To me a blog is merely the opinion of the blogger. I do use my blog for announcements but only when the subject matter isn't finalised and / or isn't ready for widespread usage outside a limited list of developers. Where things are more certain, I use mailing lists and if things are just records of what happened at a particular event, I'll use the News parts of websites. As for the time taken to write a blog entry - as short as possible - like this one. Gotta go....

I'm pleased to make Emdebian Grip unstable available - a smaller, binary-compatible, Debian without manpages, without unwanted translation files (uses Emdebian TDebs) and without package documentation. The current packages will be migrated into Emdebian Grip testing in due course and then be released alongside Lenny.
Emdebian now has two flavours with Grip taking the intermediate position in terms of size whilst retaining full compatibility with Debian. Grip "cherry-picks" packages from Debian but retains the unchanged Debian sources - the main binary and library packages will exist but -dev, -doc and -dbg packages may well be missing, as well as some of the more unusual OR dependencies).

I've just converted my Acer Aspire1 (i386) - running XFCE - from Debian Lenny to Emdebian Grip:
607 upgraded, 1 newly installed, 2 to remove and 0 not upgraded.
Need to get 184MB of archives.
After this operation, 278MB disk space will be freed.

Yes, update 600 packages and have nearly 300Mb more free space - that's a 400Kb space saving per package, on average. Gaining 90Mb more free space than the total size of the download is nice too. Comparisons are after using 'sudo apt-get clean' to remove downloaded archives:
Debian Lenny:
/dev/sda1 7.1G 1.2G 5.6G 17% /
Emdebian Grip (unstable)
/dev/sda1 7.1G 919M 5.8G 14% /

I make that about 25% smaller and not all packages installed on the machine have been "gripped" - (about 100 remain, many of which I should probably remove anyway).
Method: See http://www.emdebian.org/grip/index.html.

Add the Grip source to /etc/apt/sources.list.d/
deb http://buildd.emdebian.org/grip/ unstable main
$ sudo apt-get update
$ sudo apt-get install grip-config

This is a very important stage - Emdebian Grip is still in development and with the Lenny freeze, a few wrappers and helpers are needed to allow smooth migrations between Debian and Emdebian - grip-config is Architecture:all and contains the relevant scripts. (grip-config is Priority: required so debootstrap picks it up by default - this also means that grip-config cannot be part of Debian.) grip-config also includes the same key as the emdebian-archive-keyring package used by all Emdebian repositories.

Only after grip-config is installed should you use:
$ sudo apt-get dist-upgrade

Note that this is a complete replacement, including libc6, apt, coreutils, dpkg and (on i386) the stock kernel. As such, it can take a while to complete the installation once the download is complete. (As ever, if the kernel is updated, ensure you reboot before you next suspend to disk - even the minimal "gripping" changes to the kernel package may confuse grub when deciding whether to use the suspended image.)

A few packages are currently behind Debian Sid (notably ncurses) and I'm working on the scripts to enable full update automation.

One other problem is that /usr/share/locale/locale.alias has also disappeared which compromises localisation support right now but that's fairly easy to fix. (langupdate is also missing so there is no effective localisation support right now - I need to cross-build langupdate for the grip architectures.)
Note that this test install adds the Emdebian Grip repository to the existing Debian sources and relies on the em[0-9] version suffix to implement the upgrade - packages that are behind Debian get left at the Debian versions, you can also use normal pinning.

$ apt-cache policy
Package files:
100 /var/lib/dpkg/status
release a=now
500 http://buildd.emdebian.org unstable/main Packages
release v=0.1,o=Debian,a=sid,l=EmdebianGrip,c=main
origin buildd.emdebian.org
500 http://ftp.uk.debian.org sid/main Packages
release o=Debian,a=unstable,l=Debian,c=main
origin ftp.uk.debian.org
Pinned packages:

I've done some testing with debootstrap and a chroot works too - it should be possible to ally these packages with the normal Debian installer because there is no point "gripping" udebs that are already v.small and the packages that actually get installed are dictated by your choice of mirror. debian-live should be gaining support for Emdebian Grip in due course.

If someone fancies trying a test installation by choosing http://buildd.emdebian.org/grip as their mirror in d-i, let me know.

(Installing Grip is likely to result in further size gains as the Grip repository data does not support Recommends, so you don't have to try and get d-i to not use recommended packages).

Emdebian Grip (unstable) is now available for 7 architectures:

i386, amd64, arm, armel, mips, mipsel and powerpc.
(amd64 is only supported for debugging purposes, most of my development machines are amd64.)
Please report any and all bugs to the buildd.emdebian.org pseudo-package in the Debian BTS.

If you want more packages added, set up a Debian machine or chroot with all the packages you need (and only the ones you need) and send the
complete output of 'dpkg --get-selections' to the debian-embedded mailing list. Alternatively, file RFP bugs against buildd.emdebian.org at wishlist severity.

To see the current list of packages, use the search support

Headline packages:

coreutils, perl, python, apt, dpkg, grip-config, XFCE, debhelper, make, devscripts, sylpheed, iceweasel, drivel, xchat-gnome, gpe-tetris,
totem-gstreamer, liferea, thunar, evince, seahorse, gthumb, libsqlite3, pilot-link, python-gnome2, lua, tcl, gcc-4.3, binutils, libmysqlclient15off.

Currently, very few -dev packages exist in Grip. I'll make the emdebian-grip package available on Grip itself in due course so that new and bespoke packages can also be "gripped".

I'm migrating the current packages to Emdebian Grip testing soon and I'll be making a release of Emdebian Grip 1.0 (based on Debian 5.0 "Lenny") as well as Emdebian Crush 1.0 (based on Debian 5.0 "Lenny"), alongside the main Lenny release.

Finally, note that Grip is binary compatible with Debian - indeed, the binaries themselves are untouched - but bugs that appear in Emdebian Grip must only be filed against the buildd.emdebian.org pseudo-package. Right now, reportbug is not part of Emdebian Grip because I need a way of telling reportbug to only use the pseudo-package.

The main usability improvements will come in the development of Emdebian 2.0 (based on Debian 6.0 "Squeeze") - please consider Emdebian 1.0 as a "developer release", think back to what things were like with Slackware 1.0 or Debian buzz, rex or bo.

P.S. there is no concept of a release-critical bug in Emdebian Grip (at least, not yet) - the 1.0 release will happen as soon as Grip testing is in sync with the released Lenny (no matter what). Please do not file any bugs against buildd.emdebian.org with higher severity than important, it will just annoy people trying to fix RC bugs in Lenny.

If you are a maintainer in Debian and you inadvertently receive a bug report listed as 'found' in a version that ends in em[0-9], please reassign to buildd.emdebian.org, at severity no higher than important. Thanks.

A variety of Debian tasks all lined up in the top priority - get it done now or not at all - work queue this morning. Two GR's, one RC bug fix and one long overdue experimental upload.
All I'm saying about the first GR (the "anti-ganeff" vote) is 2212. That was the most ridiculous GR I've come across so far, until vote3 which is just politics gone insane. My own opinion? 7235146 which disagrees quite a lot with bubulle even though I have the same aims as bubulle - that alone indicates the nature of the vote. The options are illogical, the vote is pointless, the subject matter is moot, the initial proposal doesn't have any understanding or relation to the real world and the amendments have been unnecessarily divided in such a way to make it all but impossible to be logical in the vote priorities. The abuse of votes by a vocal minority undermines the process itself. All in all, we desperately need an option that basically says stop being pathetic and get something useful done in all future GR's - as well as making it harder to make a GR in the first place. Over use of referenda is as poisonous to democracy as under use - just ask Ireland.
After all that political spin and muck spreading, I had to just do something useful as a partial compensation. So, after a ping from the MIT BSP I've fixed 507316.
I've also made the tslib experimental upload that has been quietly developing on my own system for a few days.
Right, now I'm getting back to adding more packages to Emdebian Grip - so far, we have enough packages for a basic XFCE/Gtk system with an email client, a blog client, a few GPE games and Thunar as file manager. Now need to add iceweasel and dependencies. Once that is done, I'll be switching my Acer Aspire1 from Debian Lenny to Emdebian Grip unstable and creating a testing repository for Grip. Once I've got some figures from that switch, I'll post some more details to debian-embedded@lists.debian.org.
Sigh. Emdebian Grip was meant to go alongside Debian Squeeze - it looks now as if Emdebian Grip will be released before Debian Lenny - it's even likely to use the Lenny installer and debian-live support. I hope the pedants are happy because I'm not.