sarnoldi'd like to welcome everyone to today's uninet's presentations; our first presentation of the day is a second from the hard sciences to present at UMeet
sarnoldDr Jose Nazario has long studied 'network effects' -- how does the internet react as a whole to certain events
sarnoldhis latest study is on the dynamics of internet trust
sarnoldcomments and questions should be directed to #qc; jose will answer them here. :)
sarnoldspanish in #redes as usual; and today, unique, translation to french in #atei
sarnoldhow cool
sarnoldso please welcome dr jose nazario :)
jose_n_thanks sarnold :)
jose_n_heh .. those "network effects" seth speaks about are my forays into network investigation via perturbations, ie "inject some packets, forge some things, play :)".
jose_n_i have the text and slides up here: http://monkey.org/~jose/presentations/umeet02/
jose_n_i'll be referring to the slides from that set.
jose_n_INTRODUCTION
jose_n_[slide 1]
jose_n_This talk will be on a survey I did earlier this fall of over 2000 software
jose_n_archives with detatched signatures. Looking for undiscovered trojans, errors,
jose_n_and a general feeling of how well the system was working, I obtained and
jose_n_verified these archives and studied the data set I generated.
jose_n_A little bit about me. I'm a Ph.D. biochemist who left
jose_n_science to go work in software engineering. Years ago I
jose_n_founded Crimelabs as a way to share ideas and resources.
jose_n_My research interests include trust relationships (of which
jose_n_this research is a part), source code and software analysis
jose_n_techniques and tools, and network measurements and
jose_n_performance. I work at Arbor Networks in Ann Arbor, MI,
jose_n_USA.
jose_n_[slide 2]
jose_n_Very briefly, this talk will cover the research into looking
jose_n_for trojans on the Internet. We define a trojan as a modified
jose_n_binary, using the term "Trojan horse" to indicate an altered
jose_n_package which appears normal. I will briefly discuss the
jose_n_motivation behind this work, which compelled me to go
jose_n_looking for the prevalence of how many modified archives
jose_n_there are on the Internet. After a discussion of how I did
jose_n_this, I'll show you the raw results and then a discussion on
jose_n_that data set as well as the meta data I gathered in this
jose_n_research. Lastly, I'll describe some of the future work in
jose_n_this area, some of which I am hoping to work on.
jose_n_[slide 3]
jose_n_The whole approach to this study was to download and
jose_n_verify the archives. This is a rather simplistic approach, but
jose_n_it seems to have gotten the job done and provided some
jose_n_interesting results. Briefly, I identified signed archives
jose_n_available on the Internet, downloaded them and grabbed the
jose_n_corresponding PGP key, verified the archive, and then
jose_n_analyzed the data. Errors were, of course, investigated.
jose_n_[slide 4]
jose_n_This study was motivated by the series of high profile
jose_n_archive modifications which occured in 2002. Specifically,
jose_n_after the OpenSSH trojan this summer, I build a small tool
jose_n_to verify packages and started thinking about the wide
jose_n_scale analysis which would be needed on the Internet to
jose_n_discover how widespread this phenonmenon has become.
jose_n_Specifcally, this year saw packages such as Dug Song's
jose_n_tools dsniff, fragrouter, and fragroute trojanned, the
jose_n_OpenSSH source code was modified and injected into the
jose_n_mirror system, Sendmail suffered an interesting attack, and
jose_n_the latest was tcpdump and libpcap. This, of course, begs
jose_n_the question of how often this is happening.
jose_n_Also, PGP has been around for about 10 years. It's a big
jose_n_success in terms of use, and it would be interesting to see
jose_n_how well the web of trust is doing. The threat model in this
jose_n_analysis is simple: if someone were to alter a software
jose_n_package, the failure to verify correctly via a PGP signature
jose_n_should appear immediately. Furthermore, if a false key is
jose_n_injected into the web of trust, that should also be appearant
jose_n_from the failure to have the right relationships based on
jose_n_signatures.
jose_n_[slide 5]
jose_n_Briefly, doing this study is relatively easy. I identified
jose_n_software archives with detached signatures by using
jose_n_Google. I simply looked for the common terms used to name
jose_n_the signatures, such as '.tar.gz.sig' and '.tar.gz.asc'. This
jose_n_built a list of about 166 unique servers with over 2800
jose_n_archives. After the OpenSSH fiasco I built a small tool
jose_n_called `extract' which easily automatically performs the
jose_n_PGP check needed to verify an archive. I modified the tool
jose_n_for the purposes of this study to simply report on the
jose_n_success or failure of the verification process. I then
jose_n_downloaded these identified archives (using wget),
jose_n_checked them all, and then post processed the data.
jose_n_[slide 6]
jose_n_Extract is a small shell script wrapper for tar and gpg. It
jose_n_looks for the detached signature for an archive when you
jose_n_want to extract a file. Finding the archive, it then checks for
jose_n_the key on the local keyring. If the key exists, it continues.
jose_n_If the key doesn't exist, it fetches the key, adds it to the
jose_n_keyring, and then restarts. Once the key is present, the
jose_n_signature if verified with the key. If it checks out ok, the
jose_n_archive is extracted.
jose_n_Extract was designed to be small, efficient, and easy to
jose_n_use. While GPG has a relatively easy to use interface,
jose_n_compare:
jose_n_extract openssh-2.4p1.tar.gz
jose_n_...
jose_n_and how you would do it manually:
jose_n_gnupg --verify openssh-2.4p1.tar.gz.sig openssh-2.4p1.tar.gz
jose_n_gnupg --keyserver search.keyserver.net --recv-key (KEYID)
jose_n_gnupg --verify openssh-2.4p1.tar.gz.sig openssh-2.4p1.tar.gz
jose_n_tar -zxvf openssh-2.4p1.tar.gz
jose_n_That assumes you don't have the key locally and must fetch
jose_n_it as well. I really prefer tools that are streamlined in their
jose_n_use, and attempt to write tools that fit that model.
jose_n_[slide 7]
jose_n_The actual act of downloading the archives took about 3
jose_n_days on my cable modem. This was because the model I
jose_n_built operated only serially (only one archive was downloaded
jose_n_at any one time). By comparison's sake I was
jose_n_able to max it out by running 8 parallel fetches for the Linux
jose_n_kernel archives and complete it overnight, demonstrating the
jose_n_classic time-space tradeoff. The total storage required for the
jose_n_archives was about 9GB of disk.
jose_n_[slide 8]
jose_n_Briefly, here's a graph showing the impact of the traffic on
jose_n_my cable modem for a 1 day or so period. You can see that
jose_n_the traffic spikes really outshone my normal traffic, visible
jose_n_on the left. (this is from a firewall monitoring tool i built for
jose_n_my gateway.)
jose_n_[slide 9]
jose_n_The analysis, which occured in bulk, started with an empty
jose_n_GPG key ring. I wanted to see what ring characteristics
jose_n_emerged after this analysis. I modified `extract-0.1' to only
jose_n_report on the success or failure of the verification process,
jose_n_and in using extract (over gpg itself) I was able to fetch
jose_n_keys as neeeded. The process was driven by a small shell
jose_n_script wrapper which finds all of the archives in the
jose_n_directory and runs this modified extract tool on them. Data
jose_n_analysis took about 3 or 4 hours on my K6-2/300 machine,
jose_n_which I use for most of my data collection needs (it's
jose_n_currently mapping the Internet). All of the actions were
jose_n_logged, which was then postprocessed.
jose_n_[slide 10]
jose_n_The overall results are shown in this slide. Briefly, 2804
jose_n_archives were checked in this process, representing a total
jose_n_of 1426 archives. 166 unique servers were downloaded
jose_n_from, meaning that many act as a mirror server. Only 93
jose_n_keys were retrieved in the whole process, indicating many
jose_n_authors have many releases of their software.
jose_n_2799 archives were a success, they verified OK in this
jose_n_process. 5, however, failed to do so.
jose_n_[slide 11]
jose_n_Since these 5 were the really Interesting set for the first
jose_n_stage of analysis, I had to look at them.
jose_n_The first failure was due to a truncated download. A mirror
jose_n_site cut me off prematurely and an OpenSSH ditribution file
jose_n_was cut short, Hence, it didn't verify correctly.
jose_n_The next two were false negatives. I don't know why they
jose_n_failed, but they did. Manual reinspection showed that they
jose_n_were OK. Note that `extract' fails to a FAILURE mode, not
jose_n_a PASS mode.
jose_n_Failures 4 and 5 were legitimate failures. The author was
jose_n_contacted and the results were verified. It turns out that
jose_n_Alex Brennan uploaded a new archive but didn't fix the
jose_n_signature. As you would expect he appreciated the note.
jose_n_[slide 12]
jose_n_Some archives were a complete failure, however. The
jose_n_CMU-SNMP packages were signed using an old key. This
jose_n_old key format is incompatable with current standards
jose_n_based GnuPG tools. I haven't contacted the authors, but is
jose_n_a clear demonstration of a breakdown of the system. No
jose_n_valid keys were ever found.
jose_n_[slide 13]
jose_n_Now we begin the metadata analysis which forms the bulk
jose_n_of this paper. Basically this survey uncovered four
jose_n_weaknesses in the signed archive system:
jose_n_- inline key distribution
jose_n_- a risk of a compromise of the key itself
jose_n_- few signatures on some keys
jose_n_- and a lack of trust in some keys
jose_n_[slide 14]
jose_n_By inline key distribution I refer to the act of placing the
jose_n_PGP key used to sign the archives alongside the archives
jose_n_and signatures themselves. The problem lies in the
jose_n_temptation for the user to download the key as well as the
jose_n_archive. For an attacker, the setup is interesting: basically,
jose_n_when you modify the binary archive, you sign it using a
jose_n_forged key which you also upload to the site. When people
jose_n_download the archive and key pair, the signature will be
jose_n_valid but the archive will not be. Notable abusers of this
jose_n_include the OpenSSH portable team, SSH communications,
jose_n_the Cyrus team, and the GnuPlot team.
jose_n_[slide 15]
jose_n_Next, this study revealed that some keys are at risk of
jose_n_compromise by a determined adversary. Briefly, in the 93
jose_n_keys analyzed in this study, most were 3 or fewer years old.
jose_n_However, some were as old as 10 years. While an older key
jose_n_has been around longer and established more trust (you
jose_n_know what to expect), it is also around longer for an
jose_n_adversary to attack and factor. This also assumes that the
jose_n_older, original PGP software generates truly safe keys.
jose_n_Given how many weaknesses have been found in
jose_n_cryptographic software in the past 10 years, weaknesses
jose_n_are a likely possibility. Also, the sizes of the keys relates directly to
jose_n_this as well. A shorter key can be factored more easily.
jose_n_Most of the keys used to sign archives were 1024-bit RSA
jose_n_and DSA keys, but some were 512-bit keys. This is now a
jose_n_tractable size for an adversary who has an interest in
jose_n_factoring any RSA encryption key pair (see Simon Singh's
jose_n_Code Book and the resulting challenge).
jose_n_[slide 16]
jose_n_These key ages are shown here graphically. You can see
jose_n_that most are from the year 1999, but many are from prior to that.
jose_n_[slide 17]
jose_n_Shown here is the distribution of the key sizes in bits.
jose_n_Again, most are 1024-bit keys. Both RSA and DSA keys were grouped together for this graph.
jose_n_[slide 18]
jose_n_Lastly, when you correlate the age of keys and their sizes,
jose_n_you can see a generic trend towards larger keys as the
jose_n_software grows to support it. However, 1024-bit keys have
jose_n_always been present and will probably also be present for a
jose_n_long time to come. Perhaps it's time we change the default
jose_n_setting in gpg.
jose_n_[slide 19]
jose_n_The next two points in the analysis of the data retrieved in
jose_n_this study focus on the signatures on the key. The
jose_n_signatures form the basis of the web of trust in the PGP
jose_n_world. With fewer signatures on any key, it becomes harder
jose_n_to verify the veracity of the key (ie does the owner really
jose_n_own that key? is it who you think it is?). The first set of
jose_n_analysis I performed focused in the number of signatures.
jose_n_The average number of signatures per key was 21, while
jose_n_some keys had no signatures and two had 261 signatures
jose_n_per key. These last two are Debian developers and heavily
jose_n_participate in key signing events.
jose_n_[slide 20]
jose_n_The results of that analysis are shown here in this figure.
jose_n_The heavy bias to the left indicates that most keys have
jose_n_only a handful of signatures. Very few have no signatures,
jose_n_but most only have about 5 or 7 signatures.
jose_n_[slide 21]
jose_n_The next step in the analysis of the signatures on the key
jose_n_was to try and establish the owner of the key. This was
jose_n_inspired by a good set of conversations I have had with
jose_n_Niels Provos. Basically, what you do here is you examine
jose_n_the signatures on any given key and try and trace it back to
jose_n_something you know. In this case, I try and tie the keys
jose_n_back to the large, strong set identified by the initial analysis
jose_n_by the folks at Dtype.org. This strong set is a set of keys
jose_n_over 100,000 strong which are a self contained unit. Every
jose_n_key in that set somehow references every other key and
jose_n_nothing external to that set.
jose_n_Of the 93 keys analyzed here, about 2/3 could be mapped to
jose_n_the strong set. 36 keys failed to map back to the strong set
jose_n_(using the key path server at
jose_n_http://the.earth.li/~noodles/pathfind.html and the data from
jose_n_Jason Harris at http://keyserver.kjsl.com/~jharris/ka/). By
jose_n_tying a key back to the strong set we can safely assume
jose_n_that the owner is correctly indicated on the key.
jose_n_While this metric is considerably stronger than the mere
jose_n_analysis of the number of signatures on any key, it relies
jose_n_heavily on the motives of any signer. Some sign only with
jose_n_full knowledge of the key holder and the link between that
jose_n_person and the key, while others sign keys after a brief
jose_n_introduction. This is a classic contrast of a strong trust
jose_n_metric and a weak one. Using the weak links in the chain,
jose_n_one could subvert the system with enough signatures on
jose_n_any forged key.
jose_n_sarnold asked in #qc if it is sufficient to have your key signed by someone in the strong set to be brought into the strong set. the answer is "yes". the set is held together with these signatures.
jose_n_[slide 22]
jose_n_The links of the keys identified in this study to the keys at
jose_n_the center of the strong set (indicated in blue) are shown
jose_n_here. For a better graphic have a look at
jose_n_http://monkey.org/~jose/graphing/csw03/csw03.png .
jose_n_The data from the Noodles path server was used to generate this graphic, and their work on getting this server up recently is greatly appreciated.
jose_n_[slide 23]
jose_n_This foray into the web of trust and its use isn't the first of
jose_n_its kind, but I do think its the first to do a widespread
jose_n_survey of signed archives. The `extract' tool is related to
jose_n_Dug Song's `gzsig' tool and Marius' PGPwrap library.
jose_n_Marius wrote that library after finding the license terms of
jose_n_`GPGme' unacceptable (a typical monkey likes BSD code).
jose_n_The detached signatures are related to the BSD ports tree
jose_n_and the cryptographic checks made by the system. Briefly,
jose_n_any distribution file is hashed using three cryptographic
jose_n_hashes (MD5, SHA-1, and RMD160) to verify the intrigity
jose_n_if the download. Note that this is the system that caught
jose_n_most of the 2002 trojans, not the public keys system.
jose_n_[slide 24]
jose_n_So, while this study has shown that it appears that there
jose_n_are few widespread trojans lying in wait for people in the
jose_n_Internet, there are several weaknesses in the system which
jose_n_can be exploited by an attacker. Ideally, I'd like to continue
jose_n_to perform this check on a rolling basis. Right now I'm
jose_n_looking to find a research partner, I need more bandwidth
jose_n_and I need more storage space.
jose_n_Ideally everyone would be a part of that strong set. Right
jose_n_now there are a number of disconnected islands (note that
jose_n_I'm not in the strong set). This would aid, hopefully, in
jose_n_establishing the veracity of the keys. It would also be nice
jose_n_to see tools incorporated into the PGP model, such as
jose_n_'extract' or `mutt-sigtrace'
jose_n_(http://www.chaosreigns.com/code/mutt-sigtrace/) which
jose_n_can aid in the checking of keys. Next, more signed archives
jose_n_need to be out there, we need to know that this is what the
jose_n_author intended to upload. And lastly, the world needs a
jose_n_better system. There are simply too many holes in the
jose_n_current one, I think it's time to do better.
jose_n_[slide 25]
jose_n_I really need to acknowledge several people here. Beth let
jose_n_me destroy our cable modem's performance for a couple of
jose_n_days; Marius, Dug, Niels, Alex, and Seth all provided
jose_n_excellent feedback and ideas; the dtype.org people (the
jose_n_participants on the disucssion list, and Jason Harris) have
jose_n_been great in doing their work into the web of trust metrics;
jose_n_the Umeet organizers, thank you for having me speak.
jose_n_A big thanks to Mjesus, sarnold, Oroz, fernand0, and vizard (and so mnay others) for pulling this off. 100x for them!
jose_n_And of course you, I appreciate your interest. Thanks!
* MJesus sets mode: -m
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
jose_n_:)
sarnoldjose_n_: thanks :)
sarnoldclap clap clap clap clap
sarnoldclap clap clap clap clap
sarnoldclap clap clap clap clap
sarnoldclap clap clap clap clap
sarnoldclap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap
tarzeauclap
jose_n_lemme answer a question or two ..
viZardapplause applause applause applause
viZardapplause applause applause applause
viZardapplause applause applause applause
viZardapplause applause applause applause
viZardapplause applause applause applause
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
Aradorclap  clap clap clap clap clap clap clap clap clap clap clap
Aradorclap  clap clap clap clap clap clap clap clap clap clap clap
Aradorclap  clap clap clap clap clap clap clap clap clap clap clap
Aradorclap  clap clap clap clap clap clap clap clap clap clap clap
Aradorclap  clap clap clap clap clap clap clap clap clap clap clap
Aradorclap  clap clap clap clap clap clap clap clap clap clap clap
Aradorclap  clap clap clap clap clap clap clap clap clap clap clap
viZardapplause applause applause applause
raulclap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap
Aradorclap  clap clap clap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap
viZardapplause applause applause applause
Aradorclap  clap clap clap clap clap clap clap clap clap clap clap
viZardapplause applause applause applause
sarnoldjose_n_: hummm, the sigtrace website no longer has the signed.db.gz nor keynames.db.gz .. can you help? :)
Aradorplas plas plas plas plas pals plas plas plas plas plas plas plas
Aradorplas plas plas plas plas pals plas plas plas plas plas plas plas
Aradorplas plas plas plas plas pals plas plas plas plas plas plas plas
Aradorplas plas plas plas plas pals plas plas plas plas plas plas plas
Aradorplas plas plas plas plas pals plas plas plas plas plas plas plas
Aradorplas plas plas plas plas pals plas plas plas plas plas plas plas
jose_n_sarnold: are there any active 'projects' to try to map/close those disjoint sets? (speaking of the strong set, dtype.org analysis)
tarzeaujose_n_: do you have a homepage with other interesting works?
jose_n_:) so much applause!
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
jose_n_sarnold: yes, the dtype.org discussion lists have periodically identified the number of smaller sets and the links within the strong set. bridges, narrow bridges, etc... along with the density of it. some really cool analysis in the archives, a very bright group of people
viZardjose_n, how does a Signature and Certificate Autority emisor can validade a home made key and signature with itīs own part of signature?
jose_n_sarnold: i should have those files on my work laptop, i should upload them to my website
jose_n_tarzeau: jose_n_: do you have a homepage with other interesting works?
viZardletīs hope i well expressed that
jose_n_yeah, monkey.org/~jose/ has a lot of stuff
jose_n_vizard: tahts a very tough question, but ideally they would be able to answer a handful of important questions:
jose_n_a) is the key protected, ie is it safe from abuse by outsiders, and even insiders
jose_n_b) is the key representative of who it claims to be
jose_n_and c) is the key strongly unique, ie is it difficult to forge for an adversary (this includes attacks on the key itself as well as a forger)
jose_n_those seem to be the central questions answered more or less ad hoc by the web of trust system
viZardlet me put it this way, i just created a pgp key and a firm, and i want to that key to be validated by letīs say veriSign
viZardhow do they do that ? if it can be done
jose_n_a) is assumed, b) is enforced at signing time and c) is just plain hoped!
sarnoldviZard: i don't think verisign does pgp.. they just do x509
jose_n_vizard: i dont know, i haven't looked at that ... i thought it was just x509 stuff, too
viZardok, thanks Dr.
jose_n_although it looks like x509 is being incorporated into pgp tools ...
jose_n_(at least the commercial tools)
viZardsay Hello to Chelsea for me :-=)
jose_n_to "bridge the gap" if you will between the trust systems.
sarnoldhuh, i don't know if i like that or not :)
viZardWill GnuPG include that standard sooner or later?
jose_n_yeah, i'm kind of leary  too, but ... hopefully it wont be messed up ...
sarnoldjose_n_: x509. how can it _not_ be messed up? :)
jose_n_dunno, i dont keep track of gnupg development (too many politics for me)
jose_n_sarnold: heh .. how true ... so many fiascos
jose_n_by the way the prelim internet map from my house is on my site, as are some of the tools i used in this study. a draft of the paper is here: http://monkey.org/~jose/signed-archives/
jose_n_thank you again, everyone :)
fernand0thanks to you :)
jose_n_100x to the umeet organizers, plas plas plplas plas plas plas plas as plas plas plas
jose_n_MJesus: jose, and did you find any more trojans in all files downloaded ?
jose_n_nope, no more trojans. the only way one can be sure is with signatures.
jose_n_it would be nice to go through every archive and look for real subversions (ie uploaded sigs with a forged key) but thats hard to say
jose_n_i mean, some poor quality code sometimes looks like a trojan :-/
jose_n_tarzeau: jose_n_: that ASxxx map are these devices on the internet doing important stuff?
jose_n_(this is about my internet mapping projects)
jose_n_each AS is an autonomous system, a large network of networks under some administrative control
jose_n_i live in the blue box, AS22909. OARnet, for example, is AS600 (which includes my old school cwru.edu)
tarzeauhow can i find out in what AS i live?
jose_n_on the cheap: echo your network block (ie 129.22.0.0/16) into a netcat session with rr.arin.net port 43:
jose_n_echo 129.22.0.0/16 | nc rr.arin.net 43
jose_n_you'll get an answer like this:
jose_n_route:         129.22.0.0/16
jose_n_origin:        AS600
jose_n_...
sarnoldjose_n_: oh how cool!
jose_n_thats how tracepath does it
jose_n_but basically autonomous systems are the units used in global backbone routing, BGP
jose_n_ie "to get to some destination, go to autonomous system X, enter via address a.b.c.d"
jose_n_then the autonomous system has more fine grained routing information
jose_n_its how global routing tables (already millions of bytes large) are so "small"
jose_n_(otherwise they're be much, much lagrer than they already are)
jose_n_http://www.academ.com/nanog/feb1997/BGPTutorial/ <-- good ref slides
jaxpjose_n, do you accept silly questions?
jose_n_yes :)
fernand0a las 12 ?
jaxpjose_n, how was the monkey.org comprise done? dugsong said it was EPIC, gobbles said it wasn't...
jaxp(that's a silly one)
jaxps/comprise/compromise/
jose_n_*hrm* not really my place to say, but the official stance is yeah, irc client.
jose_n_we have full logs of the whole thing via some of our tools at arbor
jaxpjose_n, thanks for the answer :)
jose_n_gobbles ... is gobbles.
jose_n_we know who it was, we know what happened and ... *shrug* it sucked.
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
sarnoldviZard: some loser :)
fernand0do you know what is the next talk about sarnold ?
fernand0hehe
raulclap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap
fernand0hehe
raulclap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap
raulclap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap
fernand0plas plas plas plas plas plas plas plas
fernand0plas plas plas plas plas plas plas plas
fernand0plas plas plas plas plas plas plas plas
fernand0plas plas plas plas plas plas plas plas
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
MJesusclap clap clap clap clap clap clap clap clap clap
jose_n_:) thanks folks, its an honor to present in this company
fernand0thank you jose_n, and thank you to all for comming
sarnoldbonjour bug! :)
jaxpjose_n, thanks to you :)
MJesussarnold talk in 90 minuts, isn't ?
sarnoldMJesus: si
fernand0time to have dinner
sarnoldMJesus: maybe talks shouldn't be three hours apart!
fernand0and send to bed the daughther
fernand0hehe
fernand0mmmm
MJesus:)))
fernand0so
fernand0you are proposing we have no dinner?
sarnoldfernand0: better than me sitting at work for 1.5 hours on a sunday that I don't need to be here.... :)
fernand0you are true
fernand0maybe for your talk, next year
MJesusnext umeet, two hours ...
sarnoldfernand0 :)
fernand0Sundays are not good days to stay alone in front of the computer
fernand0you should have compelled the organizers to put your talk on a labor day
sarnoldfernand0: actually, i asked for sunday, so I wouldn't have to turn down any work requests....
fernand0ooooooooh
willyes, an excuse to convince the boss to be one day out
fernand0hehe
fernand0see you later
szicsore
fernand0see you later friends
MJesussee you fernnad0: at 21 UTC
unimauroBRavo
viZarduff, i finished the translation :-)
MJesusclap clap clap clap clap clap clap clap clap clap
jose_nvizard++
viZardapplause for Arador who translated the last part to french
jose_narador++
szicso:)
viZard:-)
viZardDr. say hello to Chelsea for me :-) she is invited to .do anytime
jose_nwill do :)
szicsowhich timezone is the UTC?:)
viZardyou can com too ;-)
viZardyou can come too ;-)
Session Close: Sun Dec 15 15:40:12 2002

Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!