Introducing the Humongous Merged Packages File From Hell Suppose you want to build some service that requires information about all packages in all architectures. Like, for example, the debtags web tagging interface. If that is the case, then you may be interested in the Humongous Merged Packages File From Hell. It contains a merge of all Packages and Source files of etch, lenny, sid and experimental, for main, contrib and non-free, in all architectures. The merge is done according to completely arbitrary criteria of mine:

• One record per (package, version) couple found; multiple record per (package, version) are merged together
• Size and Installed-Size are the average of all values found
• MD5sum, SHA1, SHA256, Filename, Files, Directory, Checksums-Sha1, Checksums-Sha256, Binary are thrown away
• Information (such as Homepage, Vcs* fields, Uploaders) found in the Sources file is repeated for every binary package
• All other packages get as value a list of all the values found, with duplicates removed

It's there in case anyone other than me may find it useful.

You can approach debconf translation work in two ways: you can be active and seek out packages to translate and update, or you can be reactive and translate and update packages when someone requests it to be done. Usually, nobody takes a purely active or reactive stance; for example, lately I used to react to calls for translation updates, but when I had some spare time I would go translate a couple of new packages. When you work actively, the web page whose URL you need to know is http://www.debian.org/intl/l10n/po-debconf/. There you have links to all languages for which there are translations. Click on yours, and you’ll see a page listing the state of every source package’s debconf template translations for your language. First, you see the partially-translated packages, then the fully translated packages, and finally a list of packages which are not translated to your language. For each package in the first two sections you can download the .POT and .PO files; the names of the packages in the last section just link to a big webpage from which you can download every package’s .POT file. In the top part of the page you have links to other useful pages. An interesting one is the ranking page, which lists all the languages in order of completeness. For working reactively, you need to subscribe to the debian-i18n mailing list, because when there is a call for updates or for translations it is always sent to that mailing list. Also, if there already is a translation for your language, another email will be sent to the translation group’s mailing list, as well as to the file’s latest translator. Calls for translations include information on the deadline and the package maintainer’s preferred methods for submitting the translation. There may also be some notes from the package maintainer. Finally, the .POT file is attached to the call for translations sent to debian-i18n, while the old .PO file is attached to the call for translations sent to the group and the latest translator. Calls for translations can be sent by the package maintainer when the debconf templates have been modified and the translations need to be updated, but they can also be sent by other people for many other reasons. For example, for the last months there’s been a campaign to upload packages for which there were newer translations that hadn’t been uploaded yet, so NMUs for these packages (non-maintainer uploads) were announced, including a call for translations. Also, there was a campaign to review all packages’ debconf templates, make them more consistent, improve their grammar, etc., and a call for translations was issued for every package after the review.

Running the Galician debconf template translation as an one-man show has an obvious problem: translations don’t get reviewed. Being only one, I would only catch typos, and the odd thinko, which is not very useful. The real use of reviews is to see if the grammar is sound, see if the translation sounds natural or forced, etc., and it has to be someone else who does it. If I review my own translations, of course they’ll be perfect. When someone else picks those translations up after I stop doing them, it would be useful to make a full review. Fortunately, I’ve been keeping a compendium of (almost) all debconf template translations, so doing the review is as simple as downloading that single file and reading it. I’d recommend that one single person read the full document and makes notes of grammatical/orthographic mistakes, common patterns, vocabulary choices, etc., and then those notes should be used to go through the compendium again and fix and update everything. The result would be useful for two things: First, it is a very big collection of examples you can point people to when they don’t know what style to use to translate. So, when someone asks in the mailing list about the best way to translate Couldn’t create temporary file , you can search for similar sentences, see how they were translated and suggest the same solution. Second, you can use that compendium to apply the results of the review to all translated packages very quickly. The idea is to regenerate the .PO file from the compendium. You can do it actively (see what packages have had their debconf templates translated into Galician, download .POT files, apply compendium, upload .PO files) or reactively (when you have to update a .PO file, download the .POT instead and apply the compendium, then update the resulting .PO file).

For a long time I have opposed single letter variable names. Often I see code which has a variable for a fixed purpose with a single letter name, EG “FILE *f;“, the problem with this is that unless you choose a letter such as ‘z‘ which has a high scrabble score (and probably no relation to what your program is doing) then it will occur in other variable names and in reserved words for the language in question. As a significant part of the time spent coding will involve reading code so even for programmers working on a project a useful amount of time can be saved by using variable names that can easily by found by a search program. Often it’s necessary to read source code to understand what a system does - so that is code reading without writing. With most editors and file viewing tools searching for a variable with a single character name in a function (or source file for a global variable) is going to be difficult. Automated searching is mostly useless, probably the best option is to have your editor highlight every instance and visually scan for the ones with are not surrounded by brackets, braces, parenthesis, spaces, commas, or whatever else is not acceptable in a variable name in the language in question. Of course if you have a syntax highlighting editor then it might parse enough of the language to avoid this. But the heavier editors are not always available. Often I edit code on the system where the crash occurs (it makes it easier to run a debugger). Installing one of the heavier editors is often not an option for such a task (the vim-full Debian/Lenny package for AMD64 has dependencies that involve 27M of packages files to download and would take 100M of disk space to install quite a lot to ask if you just want to edit a single source file). Incidentally I am interested in suggestions for the best combination of features and space in a vi clone (color syntax highlighting is a feature I desire). But even if you have a fancy editor, there is still the issue of using tools such as less and grep to find uses of variables. Of course for some uses (such as a loop counter) there is little benefit in using grep. Another issue to consider is the language. If you write in Perl then a search for \$i should work reasonably well. One of the greatest uses of single letter variable names is the ‘i‘ and ‘j‘ names for loop counters. In the early days of computing FORTRAN was the only compiled language suitable for scientific tasks and it had no explicit way of declaring variables, if a variable name started with i, j, k, l, m, or n then it was known to be an integer. So i became the commonly used name for a loop counter (the first short integer variable name). That habit has been passed on through the years so now many people who have never heard of FORTRAN use i as the name for a loop counter and j as the name for the inner loop in nested loops. [I couldn't find a good reference for FORTRAN history - I'll update this post if someone can find one.] But it seems to me that using idx, index, or even names such as item_count which might refer to the meaning of the program might be more efficient overall. Searching for instances of i in a program is going to be difficult at the best of times, even without having multiple loops (either in separate functions or in the same function) with the same variable name. So if there is to be a policy for variable names for counters, I think that it makes most sense to have multiple letters in all variable names to allow for easy grepping, and to have counter names which apply to what is being counted. Some effort to give different index names to different for/while loops would make sense too. Having two different for loops with a counter named index is going to make things more difficult for someone who reads the code. Of course there are situations where two loops should have the same variable, for example if one loop searches through an array to find a particular item and then the next loop goes backward through the array to perform some operation on all preceding items then it makes sense to use the same variable.

Share This

Since at least two months I wanted to write this blog post, as I have realised that I can't give debian-community.org the love it needs. But I have even been to busy to write this Request For Help... :-(

Since September 2007 three community planets (english, italian and german) exists and are used and (since a bit longer) there is a wiki, a mailinglist and an IRC channel (#debian-community on OFTC) and a server running this.

And then it got stalled, yet two out of three DPL candidates mentioned debian-community.org during the DPL IRC debate, believing it was alive and kicking. (Or at least not stalled as it was at that time.) The planets are alive, but that's it. Or rather that was it, there has been some activity recently! :-)

Last week, Andreas Putzo approached me and told me he wanted to spend some of his holidays to work on the long proposed email and jabber services. And by now he already did so! Yay.

Still, please consider this request for help (or invitation ;) still to be valid. For example, mail+jabber work now, but there is no documentation on our wiki...

There are many ways you can help, the best is to take initiative. If you want to, please join the IRC channel or send a mail to the list. I'll still hang around, but probably not much more. I certainly don't plan to stand in the way, rather the opposite. And of course, should you attend DebConf8, I'd also love to talk to you :-)

So much for now, now I'll continue with other pre-Argentina todo entries :-)

Hah. Forgot one link: if you haven't seen it yet, please take a 30 sec. look at join.fedoraproject.org. Very well done. I'd like to see debian-community.org to become a bit like that :-)

There should be a word for those silly little ways you can fool your body & brain. For example recently I've been having trouble with my boiler - so getting hot water is a challenge. I find myself doing the crazy thing:

• Turn on hot tap(s)
• Stick my hands under them to see if the water is hot.
• Think to myself "Hey it is getting warmer..".
• Realise actually I just imagined it.

Lather, rinse, repeat. Similarly there are times when you can imaging all kinds of bodily sensations. More than once I've been walking out, or sat at home, convinced that my mobile phone vibrated in my pocket. And it hadn't at all. I remember, random, conversations with people who agreed they sometimes believe their phones are vibrating when they are not. Seems to be a common thing. Which begs the question, is this a modern thing? Ten years ago if you had something vibrating against your body you damn well knew about it ... because you were doing it deliberately! It is only recently that it was possible to have something semi-randomly vibrating against you, without your explicit control. Right? (OK that sounds rude. It'll be our little secret.) ObQuote: Godfather (Pt.1)

Michael Janke has written an interesting article about data flows in networks [1], he describes how data from the Internet should be considered to have low integrity (he refers to it as “untrusted”) and that as you get closer to the more important parts of the system it needs to be of higher integrity. It seems to me that his ideas are very similar in concept to the Biba Integrity Model [2]. The Biba model is based around the idea that a process can only write data to a resource that is of equal or lower integrity and only read data from a resource that is of equal or higher integrity, this is often summarised as “no read-down and no write-up“. In a full implementation of Biba the OS would label all data (including network data) as to it’s integrity level and prevent any communication that violates the model (except of course for certain privileged programs - for example the file or database that stores user passwords must have high integrity but any user can run the program to change their password). A full Biba implementation would not work for a typical Internet service, but considering some of the concepts of Biba while designing an Internet service should lead to a much better design (as demonstrated in Michael’s post). While considering the application of Biba to network design it makes sense to also consider consider the Bell LaPadula model (BLP) [3]. In computer systems designed for military use a combination of Biba and BLP is not uncommon, while a strict combination of those technologies would be an almost insurmountable obstacle to development of Internet services I think it’s worth considering the concepts. BLP is a system that is primarily designed around the goal of protecting data confidentiality. Every process (subject) has a sensitivity label (often called a “clearance”) which is comprised of a sensitivity level and a set of categories and every resource that a process might access (object) also has a sensitivity label (often called a “classification”). If the clearance of the subject dominates the classification of the object (IE the level is equal or greater and the set of categories is a super-set) then read access is permitted, if the clearance of the subject is dominated by the classification of the object then write access is permitted, and the clearance and classification have to be equal for read/write access to be permitted. This is often summarised as “no write-down and no read-up“. SGI has published a lot of documentation for their Trusted Irix (TRIX) product on the net, the section about mandatory access control covers Biba and BBLP [4]. I recommend that most people who read my blog not read the description of how Biba and BLP works, it will just give you nightmares. The complexity of either Biba or BLP (including categories) is probably too great for consideration when designing network services which have much lower confidentiality requirements (even the loss of a few million credit card numbers is trivial compared to some of the potential results of leaks of confidential military data). But a simpler case of BLP with only levels is worth considering. You might have credit card numbers stored in a database classified as “Top Secret” and not allow less privileged processes to read from it. The data about customers addresses and phone numbers might be classified as “Secret” and all the other data might merely be “Classified”. One way of using the concepts of Biba and BLP in the design of a complex system would be to label every process and data store in the system according to it’s integrity and classification/clearance. Then for the situations where data flows to processes with lower clearance the code could be well designed and audited to ensure that it does not leak data. For situations where data of low integrity (EG data from a web browser) is received by a process of high integrity (EG the login screen) the code would have to be designed and audited to ensure that it correctly parsed the data and didn’t allow SQL injection or other potential attacks. I expect that many people who have experience with Biba and BLP will be rolling their eyes while reading this. The situation that we are dealing with in regard to PHP and SQL attacks over the Internet is quite different to the environments where proper implementations of Biba and BLP are deployed. We need to do what we can to try and improve things, and I think that the best way of improving things in terms of web application security would involve thinking about clearance and integrity as separate issues in the design phase.

• [1] http://lastinfirstout.blogspot.com/2008/07/presumed-hostile-your-application-is.html


• [2] http://en.wikipedia.org/wiki/Biba_Integrity_Model


• [3] http://en.wikipedia.org/wiki/Bell-LaPadula_model


• [4] http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_EndUser/books/TCMW_UG/sgi_html/ch02.html

Share This

GNOME-Mud 0.11 was released yesterday. This was probably something unexpected to those who follow the mailing list, as it's the first release in over three years. Back in 2006, Les Harris started contributing to the project and started a major rewrite of the program. Things looked very promising, with the program being ported to newer GNOME technologies and standards and being basically rewritten from ground up. However, Les got hit by Real Life and being the project's only real hacker, development basically stopped for nearly two years. On June, I was tempted to remove my irssi subscription to #gnome-mud; all I did was idling or telling people who popped by that nothing was being done and that wouldn't change unless someone rolled up their sleeves and finished up the nearly ready 0.11 release. A few days after considering declaring GNOME-Mud dead, Les joined IRC after more than a year of no contact, recovered his GNOME account password and started to commit the missing bits at an awesome pace. A few weeks later, 0.11 was done, with even more features than originally planned (support for more advanced MUD protocols like MSP or ZMP, for example) and I finally found the time to make a tarball and publish it. Les has lots of plans for the next release, and I hope my old wish of seeing GNOME-Mud becoming a MUD client that is comparable to the classic zMud will soon be a lot closer. The foundation set by this release certainly will make it easier to accomplish. As always, if you want to contribute, we'll be happy to help you out on #gnome-mud at GIMPnet, or in gnome-mud-list@gnome.org.

One of long standing things on my todo list was to make synchronisation work from my cell phone (Sony-Ericsson K750i) to some PIM application on Linux side (as a GNOME user Evolution is the natural choice). I tried it several times but it never actually worked. Today I gave it yet another try and I finally succeeded on first attempt :-). As a first step I just wanted to make a backup of all things. Gammu can do it quite well and it's the tool I trust for this purpose:

gammu backup /tmp/phonebook.vcf
gammu backup /tmp/calendar.vcs

Now it's time to play with OpenSync. We will use setup guide and SyncML guide as a starting point. As I had in past problems with both sides - both phone and Evolution failed with some random errors, I wanted to go step by step. So I started with setting up phone to files synchronisation:

msynctool --addgroup file2phone
msynctool --addmember file2phone file-sync
msynctool --addmember file2phone syncml-obex-client

Now we need to configure file storage, just tell it where it should store the data:

msynctool --configure file2phone 1

And change path in your editor to something like:

<?xml version="1.0"?>
<config>
  <!-- directory path for file-sync -->
  <path>/home/foo/phone-backup/</path>
  <!-- should care of subdirectories (TRUE or FALSE) -->
  <recursive>FALSE</recursive>
</config>

Now the more tricky part comes, we need to set up phone end:

msynctool --configure file2phone 2

Fortunately we can use example from the SyncML guide and just fill in Bluetooth address (you can get it using hcitool scan) and channel (sdptool browse 00:b0:0b:fa:ce:00):

<?xml version="1.0"?>
<config>
  <bluetooth_address>00:b0:0b:fa:ce:00</bluetooth_address>
  <bluetooth_channel>7</bluetooth_channel>
  <identifier>Sony Ericss</identifier>
  <version>1</version>
  <wbxml>1</wbxml>
  <username></username>
  <password></password>
  <type>2</type>
  <usestringtable>0</usestringtable>
  <onlyreplace>0</onlyreplace>
  <onlyLocaltime>0</onlyLocaltime>
  <recvLimit>0</recvLimit>
  <maxObjSize>0</maxObjSize>
  <contact_db>Contacts</contact_db>
  <calendar_db>Agenda</calendar_db>
  <note_db>Notes</note_db>
</config>

And now we should be able to synchronise whole phonebook from phone to selected directory:

msynctool --sync file2phone

Okay, this works, let's try more complicated thing - include Evolution in the chain. The steps are the same, config file for phone is the same, Evolution plugin has sane defaults you usually don't have to touch:

msynctool --addgroup phone2evo
msynctool --addmember phone2evo evo2-sync
msynctool --addmember phone2evo syncml-obex-client
msynctool --configure phone2evo 1
msynctool --configure phone2evo 2

But now comes the tricky thing - Sony-Ericsson phones usually have something broken around notes (or it is broken in OpenSync, I don't care, simply synchronisation fails without this step) and we have to avoid synchronisation of them. This can be done by changing filter file in group we've created above (usually in file ~/.opensync-0.22/group2/filter.conf):

<?xml version="1.0"?>
<filter>
  <note/>
</filter>

And finally we can start the synchronisation and it should work:

msynctool --sync phone2evo

You can also GUI multisync0.90 to do the configuration and start synchronisation, but it is not much different, you also still have to edit XML files.

Emma Jane Hogbin gave a presentation on the gender gap in free software at Lugradio Live this weekend. One of the central messages was that a great deal of how to avoid putting women off computing can be distilled down to "Don't be a dick". This ties in well with Mako's restatement of the Ubuntu code of conduct as "Be excellent to each other" (a wonderful phrasing which demonstrates that Bill and Ted's Excellent Adventure is the most philosophically worthwhile film that Keanu Reeves has ever appeared in, and certainly not The fucking Matrix) and led to my 5 minute rant on why I hate the Linux community slightly later in the day, but does leave a certain problem. What standards are used to define whether given behaviour is dickish or not? The comments here show that there's disagreement even within a single sub-community of the larger free software world. Ben suggests that the reaction to perceived inappropriate behaviour is perhaps even more discouraging than the original behaviour, suggesting that bitching about things that offend you is dickish behaviour in and of itself. How do we decide whether someone is being a dick or helping the community? Is lack of tolerance a form of exclusionary behaviour?

This topic is actually one of the issues discussed in the Geek Social Fallacies, but here's a nice easy example. Would tolerating planet posts encouraging the eradication of the Jewish population be inclusive or exclusive? I suspect that most people would agree that it wouldn't be acceptable behaviour, which leads us to the next question. Why? There's two obvious arguments here. The first is that at a community level we have some form of rough moral consensus that advocating genocide is Just Wrong, and so criticising Nazis is obviously the right thing to do. The second argument is more pragmatic than philosophical - alienating millions of people in order to avoid alienating hate groups could be considered to reduce our potential contributor base in an unfortunate way.

I'm a fan of the second argument. The example I gave is emotive and relatively recent history has resulted in people tending to be pretty uniform in considering genocide to be a bad thing, but many other cases aren't clear cut. What I consider to be objectification of women is seen by others as appreciation of natural beauty. What I think of as sexist jokes are perceived by others as acceptable humour. When I advocate intolerance of certain behaviour, people are going to see me not having enough tolerance. So we end up in a situation where people make the "We should all just get along and be tolerant of each other" argument, which sounds fine but is fundamentally flawed in one significant way.

Advocating tolerance excludes the intolerant.

The reason people fail to see this is that it doesn't sound like a flaw. If you ask people whether we need to support intolerance, the immediate answer is probably no. But by advocating exclusion of intolerance, you're excluding all those who have good reasons to be intolerant. You're excluding the women who don't want to feel that the community sees them as a pair of breasts attached to some legs. You're excluding the ethnic groups who would prefer to avoid racist slurs or ethnic stereotyping. Telling anti-fascism protestors that they're being intolerant isn't likely to endear you to them. Advocating tolerance is telling the intolerant that they're wrong and should just deal with whatever it is that makes them unhappy.

So, ironically, tolerating certain types of intolerance is probably required in order to avoid alienating many potential contributors. That means some way of deciding what kinds of behaviour are acceptable and which are unacceptable. In the absence of either pre-existing community consensus or some philosophical breakthrough that allows unambiguous determination of the "rightness" of a given action, I'm going to suggest that we look at it from a pragmatic viewpoint. How many potential contributors do we discourage by criticising a certain type of behaviour? How many do we discourage by tolerating it?

The fallacy of the completely inclusive community is the idea that it includes everyone. The reality is that a certain level of social exclusion is required in order to include a wider range of people. So don't criticise people purely for criticising someone else's behaviour - make an argument for why that behaviour benefits the community. And when you see behaviour that you think discourages others, call people on it. Even if nobody's behaviour changes as a result, you're sending a signal that not everyone in the community agrees. Sometimes all people want is to know that there'll be some people on their side.

But, above all, try not to be a dick.

I recently had to setup netconsole in order to diagnose some grsecurity-related suspend/resume problems. The idea is to have the broken machine send its kernel messages to a remote machine via the network.
As a prerequisite, the local machine (the one sending the console messages) must have the following kernel options turned on:

• CONFIGFS_FS
• NETCONSOLE
• NETCONSOLE_DYNAMIC

(The first and last ones are required in order to be able to configure netconsole after boot, through the configfs interface.)The remote machine should be told (using netcat) to listen on a specific UDP port (64001 in this example):

netcat -l -p 64001 -u -s 192.168.1.1 2>&1 tee /root/netconsole.log

Then, running this script on the local machine will turn netconsole on (don't forget to customize the appropriate parameters for your environment):

#!/bin/sh
modprobe configfs
umount /sys/kernel/config 2> /dev/null
mount -t configfs none /sys/kernel/config
modprobe netconsole
mkdir  /sys/kernel/config/netconsole/hostname
echo "xx:xx:xx:xx:xx:xx" >  /sys/kernel/config/netconsole/hostname/remote_mac
echo 192.168.1.1 >  /sys/kernel/config/netconsole/hostname/remote_ip
echo 64001 >  /sys/kernel/config/netconsole/hostname/remote_port
echo 192.168.1.2 >  /sys/kernel/config/netconsole/hostname/local_ip
echo 64001 >  /sys/kernel/config/netconsole/hostname/local_port
echo eth1 >  /sys/kernel/config/netconsole/hostname/dev_name
echo 1 >  /sys/kernel/config/netconsole/hostname/enabled
dmesg -n 8

That's all you need to start seeing messages on the remote machine's screen.
Interested readers may want to look at other ways to configure and use netconsole.

( I love acronyms :-D )

At this point, all of you should know and see how the H D Moore s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).
Introduction to EDHLet s put it in plain words (if you know what we are talking about, ignore this and jump to the next heading):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):

• The server selects a random prime p and a generator g of the field Z*_p (Let s ignore the mathematical properties of these values). So, the components p and g are public.
  
• The server picks a secret random number X_s and calculates Y_s=g^X_s mod p. Y_s is public and is sent to the client (just like p and g).
  
• The client does something similar, selecting a secret random number X_c and calculating Y_c=g^X_c mod p too. The client makes Y_c public by sending it to the server.
  
• The shared secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=Y_s^X_cmod p and for the server s=Y_c^X_smod p.
  
• With this shared secret the parties can encrypt all the following messages in a secure way.
  
• In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematically secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.
  

The exploit If an eavesdropper can explore the complete private key space (the all possible numbers for X_c or X_s), he/she will be able to get access to the shared secret. With it all the communication can be deciphered. That s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.

• The patch for Wireshark 1.0.2 can be downloaded from here.
  
• Debian packages with the patch applied can be found here.
  
• This is a list of all 2¹⁵ possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  
• An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD= getpid.so ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )

The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.
Issues that can be improvedWe (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, if you want to contribute with some code, start from these items and submit the patches to the Wireshark s bugzilla:

• When the packets are out-of-order the decipher with stop itself.
  
• The brute force attack should run in a background process (and with a progress bar)
  
• Check the length of the keys before trying to brute force them.
  
• The patch also implements the display of public DH parameters in the packet tree. It s incomplete.

CreditsPaolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

UPDATE Jul. 21st: See more and updated info here, especially this.

( I love acronyms :-D )

At this point, all of you should know and see how the H D Moore s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).
Introduction to EDHLet s put it in plain words (if you know what we are talking about, ignore this and jump to the next tittle):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):

• The server selects a random prime p and a generator g of the field Z*_p (Let s ignore the mathematical properties of these values). So, the components p and g are public.
  
• The server picks a secret random number X_s and calculates Y_s=g^X_s mod p. Y_s is public and is sent to the client (just like p and g).
  
• The client does something similar, selecting a secret random number X_c and calculating Y_c=g^X_c mod p too. The clients makes Y_c public by sending it to the server.
  
• The share secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=Y_s^X_cmod p and for the server s=Y_c^X_smod p.
  
• With this share secret the parties can encrypt all the following messages in a secure way.
  
• In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematicaly secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.
  

The exploit If an eavesdropper can explore the complete private key space (the all possible numbers for X_c or X_s), he/she will be able to get access to the share secret. With it all the communication can be deciphered. That s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.

• The patch can be downloaded from here.
  
• Debian packages with the patch applied can be found here.
  
• This is a list of all 2¹⁵ possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  
• An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD= getpid.so ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )

The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.
Issues that can be improvedWe (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, If you want to contribute with some code, start from these items and submit the patches to the Wireshark s bugzilla:

• When the packets are out-of-order the decypher with stop itselft.
  
• The brute force attack should run in a background process (and with a progression bar)
  
• Check the length of the keys before trying to brute force them.
  
• The patch also implements the display of public DH parameters in the packet tree. It s incomplete.

CreditsPaolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

I’ve been writing a lot about Augeas and all the process i go through to get it included in debian/ubuntu. It seems that a lot of people was following it, but some of them don’t actually understand the whole picture and what is augeas for, so i’ve been asked to write a post explaining what it is, so here we go: From the upstream homepage:

Augeas is a configuration editing tool. It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files.

Actually, it is a library which does all that stuff and can be manipulated using its public API. But what does this actually means? I will explain it using augtool and /etc/hosts as an example. As you might know it has the information of the host names and their IP addresses, so let’s take this hosts as an example:

127.0.0.1 localhost localhost.localdomain host.domain

After parsing it on augeas we will end with:

/files/etc/hosts/
- - - - - - - - - - - 1/
- - - - - - - - - - - - ipaddr = 127.0.0.1
- - - - - - - - - - - - canonical = localhost
- - - - - - - - - - - - alias = localhost.localdomain
- - - - - - - - - - - - alias = host.domain

So, then we might want to change some values:

augtool> set /files/etc/hosts/1/alias[2] myhost.domain

Ending with:

/files/etc/hosts/
- - - - - - - - - - - 1/
- - - - - - - - - - - - ipaddr = 127.0.0.1
- - - - - - - - - - - - canonical = localhost
- - - - - - - - - - - - alias = localhost.localdomain
- - - - - - - - - - - - alias = myhost.domain

or add new values:

augtool> ins alias after /files/etc/hosts/1/alias[1]

what will turn into:

/files/etc/hosts/
- - - - - - - - - - - 1/
- - - - - - - - - - - - ipaddr = 127.0.0.1
- - - - - - - - - - - - canonical = localhost
- - - - - - - - - - - - alias = localhost.localdomain
- - - - - - - - - - - - alias
- - - - - - - - - - - - alias = myhost.domain

then we need to set a value since now it’s NULL:

augtool> set /files/etc/hosts/1/alias[2] myhost

ending like:

/files/etc/hosts/
- - - - - - - - - - - 1/
- - - - - - - - - - - - ipaddr = 127.0.0.1
- - - - - - - - - - - - canonical = localhost
- - - - - - - - - - - - alias = localhost.localdomain
- - - - - - - - - - - - alias = myhost
- - - - - - - - - - - - alias = myhost.domain

Then you can save it using:

augtool> save

Also you can add a new host, or whatever you want, just need to play with the tree. Ok, but how this Black Magic work and how can i expand it to read new configuration files? Augeas uses lenses which are a Meta Data type using regular expressions that is being used for parsing, reading and writing configuration files. If you want to play around with lenses you can check this step-by-step tutorial written by Raphael Pinson (Thank you!)

Last week (July 7-13) was basically hell on Earth, for me and for the group that somehow got the name Cabras locas, of which I am part since I joined the National Pedagogical University, where I worked full-time 2003-2005.
It was, yes, the first of my officially three weeks of Summer holiday at IIEc-UNAM, so no problems here. So, why hell on Earth? Because we were in charge basically of anything related with information flow, retrieval and manipulation at the 11th International Congress on Mathematical Education, in Monterrey.
What we thought would basically be one or two days of hard work followed by six days of relaxed vacations (we had even planned to have an internal seminar, showing off the shiny stuff each of us is working on) became... A mind-boggling eight day experience where we worked over 12 hours a day on being human replacements for Google, SQL engines, full-text parsers, report generators, printer watchdogs, and in general lines, just a bunch of unhappy firemen, ready to be called off for whatever task was necessary.
We did have, of course, several calm periods every now and then. We even had to learn how to look busy while doing something compeltely unrelated (that would explain, for example, a couple of low-hanging bugs I fixed for Debian, or some dozens of lines of code I could get off my head).
But my advice for whoever reads this: Don't trust people with long database-handling experience. Specially when they insist that hand-capturing a thousand registers is preferrable (i.e. less error-prone) than parsing three separate databases and discarding duplicates. And, of course, specially when this person is your boss, which is enough of an argument to have it his way.

---

Quick post: Please update your links pointing to maintainer.php

The new reports page is report.php and has a more DDPO-like params style.

Examples:
DEHS report for package lojban-common:
Old: htt p://dehs.alioth.debian.org/maintainer.php?name=lojban-common
New: http://dehs.alioth.debian.org/report.php?package=lojban-common

DEHS report for filippo:
Old: htt p://dehs.alioth.debian.org/maintainer.php?maint=filippo[at]debian.org
New: http://dehs.alioth.debian.org/report.php?login=filippo[at]debian.org
New2: http://dehs.alioth.debian.org/report.php?login=filippo

Note that the maintainer.php script will still work for some time but please update your links whenever you have a couple of minutes to do so.

Lenny general freeze is approaching, so I'm walking thru my packages bugs and I found this one reported against fdupes.

I got 4Gb of memory, so how to reproduce an OoM? Let's start with a rather large file base, but I need a script to generate it. With 4 cores and a fast Raptor hd, I want something to stess them while learning something: Python + ParallelPython was the answer!

I wrote a small script that takes 3 parameters: the destination directory, the number of dirs to create and the number of files (with random contents) to created inside each of the created dirs. I ran it with 1000 dirs and 1000 files, so it generated 1M files set to work on.

But even with so many files, fdupes ran fine... At that point I realized that ulimit could be my friend, and the "-v" option would have saved me some time, but without the fun to write the script :)

If you don't know pp, here is a little explanation of the main part of the script (I forgot to comment the script well enough):

• job_server = pp.Server() is the pp job server: with no parameter, it allocates execution slots for the number of cores/CPUs on your system (you can force more/less)
  
• jobs.append(job_server.submit(gen_dir_set, (dirname+'/'+str(i),fileno), (), ('random',))) appends to jobs list the function returned by job_server.submit: this command takes the function to execute, the parameters tuple, the functions called by the first one (here empty) and the tuple of needed modules for the called function (here random).
• for job in jobs: job() execute each item in jobs: they are functions that return the results for every jobs (here they are discarded, but you could aggregate them to obtain the final result)
• job_server.print_stats() prints some stats about jobs executions (I love stats :D )

ParallelPython is more powerful than this: for examples, it allows to send your jobs to job nodes, machine dedicated to execute tasks (while you keep your own machine as the administration one), and more! Give it a try ;)

Since the launch of Identi.ca a few weeks ago, I've had a very busy time. Not much sleep, but lots of fulfilling and exciting work. It's invigorating to work on something that is popular and that you believe in. And I'm glad that the Franklin Street Statement so succinctly encapsulates those beliefs. As some people may have read in my previous blog post about the motivations behind creating Identi.ca (see Journal/14 Messidor CCXVI), I was part of a group convened at the FSF to discuss the impact of the growth of software as a service on user autonomy. It was a very loose organization of hackers, activists, and scholars who come from different backgrounds but all share an interest in user rights online. As computing moves into "the cloud" (see cloud computing), what power does the user retain to control their own computing experience? As much of our social lives -- romance, family, work, friends -- becomes Web-enhanced, what can we do to assert our right to manage that data and its use? How can software developers and service providers gauge their own proper ethical behaviour, and how can users of services judge what is and is not acceptable to use? We didn't come up with any easy answers, but we've summarized our thinking in a new document: the Franklin Street Statement on Freedom and Network Services. In essence, we've tried to point a direction towards what software developers, service providers, and software users should think hard about when thinking about network services. Our group will continue to explore these issues on our new group blog, http://autonomo.us/ . We're going to concentrate on the effects of software services on user autonomy -- people's ability to make their own informed choices about their data and creative works and the software that processes them. It is a realm that as a society -- a cluster of societies -- we're only beginning to understand, and I think that there is still a lot of exploration to do. Autonomo.us includes a wiki where we'll be exploring some of these ideas, and the blog will feature guest submissions about the subject. We're a loose and unofficial group with some smiling benevolence but no sanction from the FSF or any related organization, so we're really going to dig into some of the gray areas of this issue without worrying about making official statements for any one organization. I'm looking forward to the coming months and I hope this issue captures the imagination of the Web's Open Source and Open Content communities. P.S. You can see the FSF press release about the statement and the launch of autonomo.us. tags: autonomy franklinstreet softwareasaservice

Open Service Definition On a related note, one of the first organizations to approach the issue of Open Services has been the Open Knowledge Foundation. Today they've launched the 1.0 version of the Open Software Service Definition (OSSD). I think the OSSD 1.0 is a great step. It's a bar against which we can start measuring Open Software Services. For example, I think that Identi.ca meets the requirements of the OSSD. Other sites, like Wikipedia, are also clearly compliant. Some services that I really like, such as OpenStreetMap and geonames.org, seem to be compliant. But are they? It's good to start this investigation. I think other kinds of services are on their way there. The announcement by Reddit that their code will now be Open Source is a great step for user autonomy in the social news arena. Now, Reddit needs to consider what an Open Content/Open Data policy would mean for their service... or see others implement it on other sites. I look forward to a rich ecology of open software services growing, now that we have a name for it and a clear community of people interested in the topic. tags: autonomy ossd openknowledge

'churro' is the name of the Debian i18n server (i18n.debian.net), hosted by the Extremadura region in Merida (IIRC). That server was setup back in september 2006, during the first Extremadura i18n meeting. Since then, a lot of hidden work happened on it, mostly moving all scripts that build statistics pages from Debian localization data, for instance the Central Debian translation statistics. Thomas Huriaux, then Nicolas Fran ois, have been the people building all this, with the help of Felipe Augusto van de Wiel for the system administration. Churro for instance has neat statistics pages, built by Nicolas Fran ois. These would just need to be packaged with nice web pages to give a great website for stats junkies(See that example showing how Swedish decreased over time, then revived recently....or that other one showing German reaching the 100% Grail). The DDTP also uses churro as server which is an important brick for having translated package descriptions (which is now an achieved lenny release goal). And now, since this week-end, I think we can say that Pootle is partly in production. The Pootle server is now hooked directly to the VCS of some parts of Debian-Installer related packages (including the core D-I itself) and, since last night, I am not the only one using it...:-) That small bit:

Author: pootle-guest
Date: Sun Jul 13 20:48:15 2008
New Revision: 54294
Log:
Commit from Debian/Pootle l10n server by user pi. 413 of 413 messages translated (0 fuzzy).
Modified:
   trunk/packages/po/sublevel3/eu.po

... indeed shows that Piarres Beobide Ega a, the Basque team coordinator, just committed an update to D-I SVN, through Pootle. We're still working on organizing all that scattered stuff, to finally turn churro into the central point for Debian localization and internationalization work but I think that the i18n team can really be proud of the achieved work, already. PS: as churro turned out to be hard to pronounce for German mouths, please note that it is also called 'spaetzle' :-)