Just a short note that I'm currently swamped with work and other stuff and that I will get back to stuff I said I would do as soon as I can. Which I have no idea when this will be, currently I'd love a weekend without touching a computer and I have faint hopes that this might happen time in June.
Don't hesitate to contact me and/or do stuff I said I'd do.

After shutdown of the old L.ROOT-SERVERS.NET the IP address formerly associated with it, the IP continued to answere requests. More informations can be found at the ICANN Blog
UPDATE: Before bothering around, if you read the ICANN Blog, you realize that the issue was fixed very shortly. The whole problem is, that the file of the root DNS servers have to be keeped up to date. This issue should be fixed by operator of resolving nameservers (usually your ISP). A goody will be, to have this fixed by the next point release of debian, but it is NOT security critical.
Thanks Thijs for make me sensible that my article may misslead people who are not reading the referenced document.
UPDATE 2: A more technical description can also be found at Renesys Blog and a disussion how it is related to debian.

The recent OpenSSL incident can not be hidden. It was a very important blow to the Debian project's public face and reputation. A major hole slipped under the door in the form of a bugfix - and with all the good intention. This was not a deliberate attack, nor was it the result of a bad or sloppy maintainer - It was a honest, although painful, human mistake.
Several people started laughing at our processes and supposed strengths right away. I do, however, feel this shows how Debian is stronger security-wise than any other system. And it also shows how this saying, with enough eyeballs, all bugs are shallow, not only didn't lose validity, but was reaffirmed. Free Software development was also proved to be better than security through obscurity again.
Why?
Because were it not because of OpenSSL (and in this case in particular, Debian's packaging) being Free and subject to a code audit, this problem would have never been found. I have been asking to some friends who are part of different black-hat groups, and looking for this kind of information on the Web, it seems that -were it not for Luciano's work, we would still be running cryptographically weakened versions of OpenSSL for a long time. After all, 32768 possible keys is still quite a lot for a black-hat group to find as uneven noise, as a lead to showing the undeniable weakness.
It took two years to find the bug, yes. But it was found doing quality assurance work on publicly available source code. It was promptly fixed, mitigating (as far as possible) as much damage as could be caused. Tools for finding and fixing the defective keys were crafted and freed together with the announcement. Yes, there will be some compromises due to this, I'm sure, but an embarassing hole has been dealt with in the best way possible.
Anyway... I am very happy - I was going over Luciano's NM report, and found something I only suspected but was not sure about. I can now state clearly: I have never been so happy to advocate somebody to become a DD.
Luciano wrote a very good blog post (in Spanish) with his viewpoints on the Debian OpenSSL incident. If you happen to understand Spanish and are reading this blog, please drop over Luciano's.
Luciano: Once again, my hat goes off for you :-)

Mom and I went to Wal-Mart today to pick up two digital converter boxes (specificlly coupon-eligible converter boxes, “CECBs”) as emergency backup for Comcast’s frequently-incompetent cable service in Memphis. It took about 15 minutes for the assorted checkout staff figured out how to ring up the converters and use the government coupons for them, but eventually we escaped with two RCA DTA800B converters. I found the box relatively easy to use and hook up. The boxes included quick start guides in English and Spanish and full user manuals in both languages, as well as a programmable remote control (with batteries) and a short push-on coax (F-type) cable for attaching the box to a TV over the “antenna” TV input. Both boxes worked moderately well in southeast Memphis with a rather lame RCA unpowered indoor VHF/UHF antenna I picked up a while back, which is no Silver Sensor but a bit more compact to haul around, less likely to attract quizzical stares from airport security, and better than nothing at all. Neither box was able to scan WMC‘s rather weak digital signal (authorized at 394 kW but clearly not transmitting at anything close to that power) and there’s no manual tuning option. I’d imagine if I’d brought a decent directional antenna like the Silver Sensor I’d have gotten WMC and a more stable signal on some of the other channels. So, overall, I have no real complaints about the boxes themselves, except for the lack of a manual tuning feature available on other converters, and the SmartAntenna feature will be nice for folks with hard-to-tune channels in multiple directions when you can actually buy one again. I’ll probably examine some of the other CECB models before settling on one, however, particularly now that it appears that the reported Zenith DTT900 audio problem is fixed in newer boxes.

One of the things I do when I’m at home is translating debconf templates into Galician. I’m not doing bad at all. Although it’s just me working alone (by choice), mine is the 10th most complete translation, and climbing :) I’m going to document my workflow, for two reasons: one is that others may find it useful or may suggest improvements. The other is that, in this way, I won’t depend on my bash history not being erased :) I have a compendium with almost all strings in all debconf templates I translated, and several scripts I use to maintain that compendium, apply it to translations, etc. It is available at http://darcs.tarrio.org/gl-templates/, and can be downloaded with Darcs using this command:

$ darcs get http://darcs.tarrio.org/gl-templates/

In my local machine I keep it in $HOME/pos. (You may use this compendium and scripts freely, if you want, but be sure to change all appearances of “gl.po” into the appropriate file name for your language.) Nowadays I’m mostly driven by bubulle’s NMU announcements. Whenever he announces a NMU for a package I haven’t translated or whose Galician translation is outdated, I work on it. This is what I do to start a new translation for a package called “example":

1. Extract the attached templates.pot file into $HOME/pos/example_templates.pot.
2. Bootstrap the translation with my compendium, using this command:

   $ ./bootstrap-po example_templates.pot > gl.po

   The script is smart enough to know that a file called example_templates.pot is a templates file for a package called example. However, I can specify a different package name as its second argument:

   $ ./bootstrap-po nonsensicalfilename.pot example > gl.po

3. The generated gl.po file is UTF-8 encoded. However, I use xemacs to translate, which cannot read that, so I encode it into iso-8859-1:

   $ msgconv -t iso-8859-1 gl.po -o gll.po

4. Edit the file.
5. Encode the edited file into utf-8:

   $ msgconv -t utf-8 gll.po -o gl.po

6. Add the translations to my compendium:

   $ ./add-total-po

   (My compendium is the total.po.txt file, hence the name.)
7. Optional: edit the compendium to remove obsolete strings or strings which may be ambiguous so I don’t want them in the compendium.
8. Send the translated file to the package maintainer using the BTS:

   $ ./send-po example

9. Record and push the changes to the compendium:

   $ darcs record -a
   $ darcs push -a

This is how I update an existing, outdated translation:

1. Extract the file into $HOME/pos/gl.po.
2. Most likely, it’s UTF-8 encoded. Encode it into iso-8859-1:

   $ msgconv -t iso-8859-1 gl.po -o gll.po

3. Edit the file, fix only the fuzzy translations.
4. Encode it back into UTF-8:

   $ msgconv -t utf-8 gll.po -o gl.po

5. Update the translation using the existing translated strings and the compendium:

   $ ./refresh-po gl.po   msgconv -t iso-8859-1 -o gll.po

6. Open the file. Hopefully you’ll have new fuzzy translations. Edit the translation and complete it, or do some strings then refresh again and edit and refresh again until the file is completed. If the file contains lots of similar sentences you can just translate a couple of them, refresh, and the other ones will then be all fuzzy. Magic!
7. When I’m done, encode into UTF-8, update the compendium, send to maintainer, submit changes to compendium.

I am in the process of moving all my services (including this website and my mail server) to a new host (actually a virtual server). Until now, almost all of them were (hum, are… see below) hosted on my home server on a DSL line. The aim is to ease maintenance, reduce power usage, and avoid any risk of fire when not at home. Most of the websites and the mail server were moved to the new virtual server at the beginning of the week. I had to postpone my backup configuration to deal with the OpenSSL vulnerability. Unfortunately, one of the filer of my new hosting company crashed on Thursday and all the data of my virtual host have been lost. The server is still unreachable, I had to move back to my home server on Friday. This lead to some outages on all my websites in the meantime. Sorry for any inconvenience. I have also lost a few e-mail (which I have received on the new host, but not yet read, ie. not yet in my MUA cache). If you sent something I haven’t yet answered to, please send it again. I hope I will be able to work on the virtual server again next week-end.

One of the most interesting debates concerning new technologies is whether human enchantment technologies have any reseamblance to the older practice of eugenics. One of my favorite articles on this subject is by The Case against Perfection, which simply stunned my students (and they are pretty hard to stun). Recently, the Chronicle of Higher Education published a couple of articles on the topic, and I wrote a response to one of them, (which as you will see, irked me some) here. While I agree with the author that medical genetics is not eugenics, it is still worth our while thinking through today’s genetic and reproductive technologies through the eyes of historical instance of eugenics.

Tonight at the Halfking is a reading by the author of American Nerd, a book that will be high on my reading list (and who knows, maybe I will assign in my course on hackers, as you know, hacking is related to nerd culture too

I am going to University of Haifa next week to participate in this conference on the commodification of community on the web. I will have a few free days on the 31s of May and June 1, and 2 to explore. I also know I am going to Jerusalem for a day and will explore Haifa for a day too. Any recommendations of what to check out would be appreciated. You can contact me at the email provided on my contact page

With my server migration I switched from PostgreSQL 8.2 to 8.3. However, I've installed MediaWiki for the awesome wiki on 8.2, but dumping from 8.2 and restoring to 8.3 just failed because of the tsearch2 extension, which is now part of PostgreSQL 8.3. With the help of my friend Dimitri, the pgloader author, I managed to migrate the database from PostgreSQL 8.2 to 8.3. Here is how I did. This was done with MediaWiki 1.12, and I doubt that older version supports PostgreSQL 8.3. Dump the database schema First, you need to dump the database schema, and then, the database data. We need to do it in two steps because we need to change the schema a bit. I assume that MediaWiki is installed in the mediawiki schema:

% pg_dump -s -n mediawiki wikidb > wikidb-schema.sql

Convert the schema Then, edit your wikidb-schema.sql. When you installed tsearch2, you probably did it in the public schema like I did. So it created two or three data types used by MediaWiki wich are named public.datatype. These tsearch2 datatypes are now part of PostgreSQL, so they're in the pg_catalog schema. You just need to replace a few lines with public.datatype with pg_catalog.datatype. For example public.tsvector is now pg_catalog.tsvector. For your information gin_tsvector_ops is now pg_catalog.tsvector_ops. Finished? Good, but that's not all. You need to split up the file in two parts: one with the tables creation, and another one with the constraints creation. Why? Because otherwise the data insertion will fail because of these constraints. That's not so hard, just split your files in wikidb-schema.sql with all CREATE TABLE and so one, and then you see that the SQL file begins to do some ADD CONSTRAINTS, just put this in another file, named wikidb-constraints-schema.sql. You'll also need to set the namespace before executing command in your second file, so do not forget to add a SET search_path = mediawiki, pg_catalog; line at the beginning. Dump the database data That's easy:

% pg_dump -a -n mediawiki wikidb > wikidb-data.sql

Create your new database That's easy too:

% createuser -S -D -R -P -E wikiuser #(then enter the password)
% createdb -O wikiuser wikidb
% createlang plpgsql wikidb

Restore the database That's even easier, but you need to respect this order, otherwise it will fail:

# Restore schema first
% psql wikidb < wikidb-schema.sql
# Then restore dat
% psql wikidb < wikidb-data.sql
# Then restore constraints
% psql wikidb < wikidb-constraints-schema.sql

Run update.php Just go the the maintenance directory. Then you can try to run update.php, but it'll fail.

% php update.php
[...]
Could not open "/var/www/awesome.naquadah.org/wiki/maintenance/postgres/archives/patch-tsearch2funcs.sql".

Well it seems that MediaWiki people just forgot this file in the 1.12 archive.. You can grab it on the SVN repository here. When you've put it in the good directory, really run:

% php update.php
[...]

You should see no error. And now it works. Give us some kudos This is the last and hardest part of this tutorial. Since everything works, you should give kudos to Dimitri and me.

This was meant to echo Jeff Bailey s Out and about!, where Jeff wrote about blood transfusion. Every country has its own values, rules, and methods for blood donation (be it about anonymity, retribution, etc.), but please consider getting informed, and donate. According to the tablissement Fran ais du Sang (roughly translated to: French Blood Institute), the key point is to donate again, possibly on a regular basis. Various possibilities in France: donate full blood (2 months delay between each, takes about 10 minutes), or selectively (plasma or platelets, 2 to 4 weeks delay between each, takes about a full hour). You can save lives. Will you do it? Many thanks to Helen for reminding me to write a note about important things.

Looking at the current discussions, I'm wishing some people would calm down a bit. It's always impressive how some things switch sides like pendulums. First of all, Debian already is centered about packing software and not developing them. We already have the rules and policies and methods in place. Our policy states:

If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.

And our source format shows how important marking the difference is to use: We have explicit .diff.gz files to contain them. The differences are not hidden in same Version Control System (like BSD) or in propretary formats (ever tried to unpack a .srpm without rpm or without downloading some magic perl script?), but in a simple universal understandable format. That said, please remember we are a distribution. Our priorities are our users and not the whims of software authors. We have to find the middle ground between harmful and necessary changes. Patching software to abide the FHS, to allow the user choose their editor or browser in an common way or any other thing to form a coherent set of packages is no bug in Debian, it is a bug in upstream to not allow this at least via some configure option. We have neither the manpower nor the job to rewrite and fork stuff to a usable state, though. Thus we have to keep to upstream and hope they will include our modifications or forward-port them to every new release. Thus, we need both: We need to patch (and in general, the worse the software from a distribution's point of view or from a general point, the more of this we need. This does not necessarily hold in the other direction, though.). And we need and want to show what we change. So our users can find out how exactly the software we ship is different. And so other people dealing with the same software can profit from our changes. (After all, free software is about "giving back" a lot.). And of course maintainer change over time and we want the new one understands what the previous one did. That said, there is of course things that can be improved. But as with all improvements there are things that improve and there are things where nothing is worse than good intentions. Adding more thing to keep in sync is almost always a bad thing in the long run. The easiest way to keep things accessible is to use stuff actually used. I think any additional place to track patches will be futile. A good interface to view the .diff.gz files in our archive in some browser, on the other hand, could hardly get unuseful. The format of a single .diff.gz is of course also improveable. Things like a quilt-like standardized patch series look like a very good idea to me. But the format is of course also very downgradeable. Storing VCS formated information for example, tempting as it is, spoils two very important points:

• universal readability is lost. Everyone coping with software can work with patches or patch series, no matter what tools they use.
• visibility of changes is sacrificed for history. Every single VCS I ever saw primarily coped with history. Even patch based ones represent changes in time and not by itself changes by topic.

And of course, a lot can be improved by just using some rules more strictly. Not using a pristine tarball or a proper subset of one where the first is not possible should not be some mere ignorable non-conformist behaviour, but seen as the serious problem it is.

Grisbi is now
available in Emdebian but without libofx. Similarly homebank is in Emdebian (note that homebank-data is also needed and is available), again without libofx.

I'm not convinced that libofx is that much of a loss on an embedded device - especially when libofx and dependencies could add 5Mb to an existing installation - just for the shared libraries!

The screenshots of Grisbi in Maemo gave my the idea of adding grisbi and I've been trying it out on the desktop too. Once I'd tweaked the column widths for the transaction window (hidden away in Preferences), it is quite usable - although I can't see any way of it handling invoices.

My own gpe-cash is not making much progress - the GnuCash objects are just too resistant to use outside GnuCash. It may be easier to create invoices from grisbi/homebank data via CSV and estron.

This is aimed at the more powerful end of Emdebian devices but each package is still 50% smaller in Emdebian than in Debian, closer to 80% smaller if you count the reduced dependencies. The main difference is the use of TDebs.

Christian Perrier and I are planning on working on TDebs during DebConf8 and Extremadura so that bugs and fixes to support TDebs can be implemented in Debian as soon as Lenny is released. Removing translations from the maintainer uploads and translation bugs from the package BTS should make it a lot easier to update translations without requiring an NMU of the entire package (which is complete overkill IMNSHO).

Together with DEB_BUILD_OPTIONS="nodocs" support, TDebs are the simplest way to reduce package sizes and installation sizes in Debian/Emdebian.

(I just wish #448615 could be fixed so that I could get on with preparing patches for packages that install docs without using debhelper.)

I’ve just released pommed v1.18, which is mainly a maintenance release. I’ve added some more USB IDs for Apple external keyboards and relaxed the event devices identification for internal keyboards. pommed will now happily start on a machine fitted with a keyboard+trackpad assembly that normally isn’t found on this model. This can happen when the topcase of the machine is replaced with the wrong part. I expect this situation will happen more and more often as people buy parts from EBay or similar to repair their laptops.

As I said a month ago, my main server Delmak was dying. Well it still runs (proof: you could read this blog some days ago). Thanks to friends I host for free, they've kindly given enough money to buy a brand new server (C2D E8400, 4 GB RAM, 2x500 GB RAID 1) in order to replace the good old Delmak. This new box has been named Prometheus after the only BC-303 class battleship ever built. Delmak was used to mainly run as a Web, mail and databases server. I decided to do use this server switch to change the server software I use. The first mail server I setup was based on Exim 3, courier- imap,pop -ssl, with userdb files. That was... rough. Later I switched to Exim 4, using vexim, and MySQL as a back-end. That was something like 3 years ago I guess. Since then I never really touched that back. I added spamassassin and clamav filtering some months after, because some users asked for it. That's all. So this week, I decided to switch away from this configuration. I do not understand Exim anymore anyway, so I decided to use Postfix which I often use and administrate at work. Obviously, I also now use PostgreSQL as database back-end, since it rocks, and since Postfixadmin supports it. By the way, be aware that the Debian package of postfixadmin is crappy (the configuration file is readable by anyone by default, with the database password in it). I also set up postgrey which is quite nice and efficient. Well, then was time for amavisd-new installation, but I did not do it. Seriously, amavisd-new configuration is a bloody mess, as the language it is written in (yes, Perl). So I switched to dspam which I heard is nice. Well, it seems to be for now, since it even supports clamav daemon usage directly, which is very very nice because that means I do not have to set up another thing for that. I also switched from courier to dovecot, mainly because the latter seems to be faster and lighter. I then changed the default virtual_transport to Dovecot LDA. The main advantage of this is that the LDA updates the Dovecot index while delivering. It also supports quota, which I do not use and plug-ins, like the Sieve language for mail filtering. So I decided to change my procmailrc to a new Sieve filter. My procmailrc is quite small since I only use regex to match lists and some mail address, so it has only something like 12 rules. And well, I did not do it since I discovered after some googling that Dovecot implementation of Sieve is grabbed from Cyrus which does not support variables for now. That means that the following procmailrc code:

:0:
* ^X-Mailing-List: <debian-.+@lists.debian.org>
* ^X-Mailing-List: <debian-\/[^@]+
list-debian-$MATCH/

which will translate to:

require [ "regex", "variables", "fileinto" ]
if header :regex "X-Mailing-List" "<debian-(.+)@"
 
    fileinto "lists.debian.$ 1 ";
    stop;
 

But that won't work since Dovecot Sieve implementation does not support "variables". Well, since I'm not ready to list all the lists I'm subscribed to, Sieve is a no-go for now. I'll stick with procmail.

It has recently been announced that Debian had a serious bug in the OpenSSL code [1], the most visible affect of this is compromising SSH keys - but it can also affect VPN and HTTPS keys. Erich Schubert was one of the first people to point out the true horror of the problem, only 2^15 different keys can be created [2]. It should not be difficult for an attacker to generate 2^15 host keys to try all combinations for decrypting a login session. It should also be possible to make up to 2^15 attempts to login to a session remotely if an attacker believes that an authorized key was being used - that would take less than an hour at a rate of 10 attempts per second (which is possible with modern net connections) and could be done in a day if the server was connected to the net by a modem. John Goerzen has some insightful thoughts about the issue [3]. I recommend reading his post. One point he makes is that the person who made the mistake in question should not be lynched. One thing I think we should keep in mind is the fact that people tend to be more careful after they have made mistakes, I expect that anyone who makes a mistake in such a public way which impacts so many people will be very careful for a long time… Steinar H. Gunderson analyses the maths in relation to DSA keys, it seems that if a DSA key is ever used with a bad RNG then it can be cracked by someone who sniffs the network [4]. It seems that it is safest to just not use DSA to avoid this risk. Another issue is that if a client supports multiple host keys (ssh version 2 can use three different key types, one for the ssh1 protocol, one for ssh2 with RSA, and one for ssh2 with DSA) then a man in the middle attack can be implemented by forcing a client to use a different key type - see Stealth’s article in Phrack for the details [5]. So it seems that we should remove support for anything other than SSHv2 with RSA keys. To remove such support from the ssh server edit /etc/ssh/sshd_config and make sure it has a line with “Protocol 2“, and that the only HostKey line references an RSA key. To remove it from the ssh client (the important thing) edit /etc/ssh/ssh_config and make sure that it has something like the following: Host *
Protocol 2
HostKeyAlgorithms ssh-rsa
ForwardX11 no
ForwardX11Trusted no You can override this for different machines. So if you have a machine that uses DSA only then it would be easy to add a section: Host strange-machine
Protocol 2
HostKeyAlgorithms ssh-dsa So making the default configuration of the ssh client on all machines you manage has the potential to dramatically reduce the incidence of MITM attacks from the less knowledgable users. When skilled users who do not have root access need to change things they can always edit the file ~/.ssh/config (which has the same syntax as /etc/ssh/ssh_config) or they can use command-line options to override it. The command ssh -o “HostKeyAlgorithms ssh-dsa” user@server will force the use of DSA encryption even if the configuration file requests RSA. Enrico Zini describes how to use ssh-keygen to get the fingerprint of the host key [6]. One thing I have learned from comments on this post is how to get a fingerprint from a known hosts file. A common situation is that machine A has a known hosts file with an entry for machine B. I want to get the right key in machine C and there is no way of directly communicating between machine A and machine C (EG they are in different locations with no network access). In that situation the command “ssh-keygen -l -f ~/.ssh/known_hosts” can be used to display all the fingerprints of hosts that you have connected to in the past, then it’s a simple matter of grepping the output. Docunext has an interesting post about ways of mitigating such problems [7]. One thing that they suggest is using fail2ban to block IP addresses that appear to be trying to do brute-force attacks. It’s unfortunate that the version of fail2ban in Debian uses /tmp/fail2ban.sock for it’s Unix domain socket for talking to the server (the version in Unstable uses /var/run/fail2ban/fail2ban.sock). They also mention patching network drivers to add entropy to the kernel random number generator. One thing that seems interesting is the package randomsound (currently in Debian/Unstable) which takes ALSA sound input as a source of entropy, note that you don’t need to have any sound input device connected. When considering fail2ban and similar things, it’s probably best to start by restricting the number of machines which can connect to your SSH server. Firstly if you put it on a non-default port then it’ll take some brute-force to find it. This will waste some of the attacker’s time and also make the less persistent attackers go elsewhere. One thing that I am considering is having a few unused ports configured such that any IP address which connects to them gets added to my NetFilter configuration - if you connect to such ports then you can’t connect to any other ports for a week (or until the list becomes too full). So if for example I had port N configured in such a manner and port N+100 used for ssh listening then it’s likely that someone who port-scans my server would be blocked before they even discovered the SSH server. Does anyone know of free software to do this? The next thing to consider is which IP addresses may connect. If you were to allow all the IP addresses from all the major ISPs in your country to connect to your server then it would still be a small fraction of the IP address space. Sure attackers could use machines that they already cracked in your country to launch their attacks, but they would have to guess that you had such a defense in place, and even so it would be an inconvenience for them. You don’t necessarily need to have a perfect defense, you only need to make the effort to reward ratio be worse for attacking you than for attacking someone else. Note that I am not advocating taking a minimalist approach to security, merely noting that even a small increment in the strength of your defenses can make a significant difference to the risk you face. Update: based on comments I’m now considering knockd to open ports on demand. The upstream site for knockd is here [8], and some documentation on setting it up in Debian is here [9]. The concept of knockd is that you make connections to a series of ports which act as a password for changing the firewall rules. An attacker who doesn’t know those port numbers won’t be able to connect. Of course anyone who can sniff your network will discover the ports soon enough, but I guess you can always login and change the port numbers once knockd has let you in. Also thanks to Helmut for advice on ssh-keygen.

• [1] http://www.debian.org/security/2008/dsa-1571


• [2] http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html


• [3] http://changelog.complete.org/posts/714-Thoughtfulness-on-the-OpenSSL-bug.html


• [4] http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html


• [5] http://www.phrack.org/issues.html?id=11&issue=59


• [6] http://www.enricozini.org/2008/tips/ssh-host-key-fingerprint.html


• [7] http://www.docunext.com/blog/2008/05/14/my-security/


• [8] http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki


• [9] http://www.ducea.com/2006/07/05/how-to-safely-connect-from-anywhere-to-your-closed-linux-firewall/

Share This

(tl;dr: if you have a few minutes, please add information here) Joss, the problem with the new package formats is that there is nothing that actually uses the additional information in a way that adds significant new functionality, so the net result of the change was that we throw away the information at a different layer in our software stack, and one of the interfaces got a lot more complicated in the process. One possible application would be a "poor man's patch tracking" inside the BTS, perhaps with a new state "fixed in patch". I can see two ways of implementing that:

1. by extending the interface of the "new" package formats that Debian,Ubuntu bug numbers are attached to the actual patch files and having the archive maintenance software extract and process that information (reject packages that add a patch for a bug without closing it in the changelog, notify the BTS), or
2. by leaving the package format untouched and simply adding a regex matching "Fixes: #nnnnnn" that is reported to the BTS as "we have added a patch", so the submitter is notified that the bug is gone for him/her; the bug is then closed in the changelog of the upload removing the patch.

The former approach also allows us to link to patches from BTS pages, which the latter doesn't, so there could be actual benefit here if we believe it is worth the additional complexity. (Update: Rapha l thinks it is. I like the idea of a package format with separate patches a lot more in this context than I did without it, but still my fear that it will actually be perceived as sanctioning large patchsets still remains.) About mandatory co-maintenance: the problem isn't "helping". We have plenty of people with commit access to packages they don't even remotely understand who are really helpful (not). The problem is that someone needs to actually read all the commit logs and understand what the changes do in this context. In most cases, that person or group would be upstream, not a DD. My first impression after reading the patch was "adding uninitialized data to the entropy pool is pointless/harmful as it is not random, so this patch makes sense", because the loop around it was not contained in the patch. Obviously I'm not an OpenSSL developer. There is nothing Debian could have done internally to verify the correctness of this patch that would properly scale to the entire archive, even if we put "more emphasis on security". The only solution I see is reporting every patch to upstream immediately and getting affirmation that it is correct. This, however means that we need to produce patches that upstream can accept. For obvious code bugs, that is simple, but for integration patches like paths it is not sufficient to replace one string with another, but rather make it configurable in some place that can be reached from debian/rules. In an ideal world, we end up with very few Debian specific patches, so essentially we are talking about adding functionality to dpkg that we don't want to use. I've started a page in the Debian Wiki, Getting Packaged with an outline of a possible document aimed at upstream developers that should list the typical problems we run into and how to avoid them.

Romain, you might just want to check 471263 where there is disagreement over how this lintian test should or should not behave towards generated files. In particular, if a package contains a patch in debian/patches that causes upstream files to be modified indirectly (e.g. because upstream is old / quiet and hasn't updated the autotools stuff for years, any patch that affects Makefile.am or configure.in ac is going to cause changes in generated files and these changes should not be wrapped into yet more patch files because of the inevitable build failures when any of the tools used to generate those files are updated.

Your stats may also be out because of this problem - it is hard to see how lintian can resolve the problem cleanly without carrying a long list of "possibly generated files" and risking the list going stale.

There is more to the contents of .diff.gz than may meet the eye.

There is an article on TechCrunch on Windows on the OLPC. This article started out as a comment below lots of comments that were missing the point, but eventually grew too large. The entire discussion circles around the question whether it would be beneficial to give the users the same view and behaviour that is on 90% of machines worldwide, so they can start out prospective jobs with a minimum of training. Learning your way around the UI is only a significant part of training if that actual work you will do is trivial — so this argument basically boils down to "I don't expect the African kids to do anything but grunt work during their lifetime anyway, so we better start training them early", which is the wrong approach not only to education. To make a bad car analogy, roads are usually made of several layers, from the foundation providing the stability up to the paint defining lanes. Operating systems are similarly layered, with a core that applications (cars) never touch directly, and several other layers on top of that that are not really required for basic functionality, but that add safety (process separation) or comfort (standard functions). The minimum standard of things is a "platform definition", which all car (or application) makers can expect — all roads have a minimum width and there are no dangerous spikes (if that is not true, you can get a steamroller or respectively format your harddisk). Railways use the same kind of foundation (operating system), but the platform (heh) is quite different. You cannot drive a car on a railway, or a train on a road, just as you cannot run a Windows application on a Linux system or vice versa (there are special wagons you can place your car on, and special trucks with rails on them if you feel like it, but these are heavier and need more energy to pull). Now in this discussion, people have been comparing Windows (the platform) to Linux (the operating system). That doesn't work. On Linux, there are several platforms available, the most prominent being GNOME and KDE for the desktop and POSIX utilities on the command line, but there are lots of others as well. Part of most platform definitions is an user interface, which abstracts what is really happening to something comprehensible to the user, using analogies (a tachometer displays our speed as an angle usually, but other representations are possible). The "desktop" idiom happened to be the first graphical UI some thirty years back, and was perpetuated into today's computers (just like the width of roads hasn't changed from the days of the Roman empire, where it was "two horses and then some"), however this doesn't mean it is the best choice available — it's just what we are used to. If you look at the screen contents on the day traders' computers (lots of that on the TV right now thanks to the market crisis), you will notice the vast majority does not use overlapping windows or standardized "rising-edge" buttons to click on, but rather, they have a tightly-packed grid layout with high-contrast information displays that also color-code certain messages. I think that is the most important point here: to achieve optimal results, the presentation idiom needs to be chosen in a task specific way. With children as the target audience, we lose one of the key requirements behind the adoption of the windowed view: the need for side-by-side presentation of data from multiple unrelated sources (which is also a problem given the lack of screen space). With the introduction of ad-hoc mesh networking and collaborative applications, the "desktop" analogy begins to break down. The project's mission also defines requirements on the platform. If we want to keep the requirement "users should be able to build and share their own stuff", then we want a framework where it is hard to make mistakes, especially those that can be spotted only after an interesting failure, and more importantly impossible to write code that makes unrelated components fail, because these components might be your way back out of the situation. Windows has an excellent event model with fairly good isolation of components (to the point where a problem in an event handler can be handled by the event loop rather than terminating the program, so for example Internet Explorer can shut down broken plugins rather than crashing), but the detail knowledge required to really work with the API (how to build a message loop that also runs queued I/O completion handlers correctly) leads to a fairly steep learning curve, and would teach implementation details rather than concepts. The normal "linuxy" approach of going low level whenever higher-level approaches fail is not the answer either as we want to truly empower people rather than just training them to be a cheap replacement for the tech support Indians (no offence), so it is vital that the "real" applications use the same framework that people implementing new things would use, and thus all the complexity that we want in our "official" applications needs to be taken care of by the platform, with all the safety features in place too. So no existing platform provides what we want. — hence Sugar. And that is the problem for Windows advocates: Sugar replaces those bits that make Windows a platform and not just a kernel, so porting Sugar to Windows doesn't make sense from a technical point of view, since we already replaced the bits that we didn't have free software for before. Other than that, the "Linux vs. Windows" kernel choice is secondary; in fact both kernels are very similar in design and function, the various advantages and disadvantages of either aren't that relevant really. The only technical reason in favour of Linux is the virtual memory management — the Windows VMM behaves erratically in the absence of a swap device, but I believe that is not something that cannot be fixed. The reason why I believe Linux is the better choice here is long-term support. Since these devices will be used in basic education (which hasn't changed that much in the past years as 1 plus 1 still equals 2), there is hardly any need for radical changes after the initial rollout — why add instability when you don't have to? With Microsoft as a for-profit company, there needs to be a business model sustaining that behind it, and I believe it will be very hard to find one. "Subscription" falls down in that it is a long-term recurring expense, which governments tend to be pretty wary of. The alternative is to upgrade several million computers' OS every few years. Lots of companies are skipping entire Windows releases because of the migration cost, and even with the "console bonus" (all hardware is the same) and bootloader support for software upgrades over a mesh network, this is still a massive endeavour. That each machine would have to reserve enough memory for the entire "upgrade pack" so it can transition "in one go" also makes this model unworkable. To summarize, using Windows on the OLPC does not make sense at all. If you use just the kernel, you don't gain anything over Linux, and if you use the entire platform (and by extension, the UI), you add unnecessary complexity that is not only not required for the actual task, but also distracting. If you add restrictions and extensions to make it work, you invent a new platform, which is precisely what Sugar did. The argument that it is important for pupils to use the same thing that the rest of the world is using to ease their entry into the workforce is bogus at best, and racist at worst.