| 00:52.53 | *** join/#uclibc tchan (n=tchan@lunar-linux/developer/tchan) |
| 01:11.03 | dalias | wow i just read the glibc version of strlen from uclibc's glibc-string-funcs dir |
| 01:11.08 | dalias | its an abomination |
| 02:38.31 | CIA-4 | 03landley * r15088 10busybox/ (coreutils/md5_sha1_sum.c include/libbb.h libbb/md5.c): (log message trimmed) |
| 02:38.31 | CIA-4 | Make md5 calculation always go through an the buffer so that A) we don't |
| 02:38.31 | CIA-4 | handle packets out of sequence if some data goes through the buffer and |
| 02:47.31 | dalias | :) |
| 02:52.01 | dalias | ashes, about what you were saying the other day... 15% difference seems really odd |
| 02:52.15 | dalias | if that happened it's probably a stupid bug/oversight in the tool chain building or something |
| 02:53.07 | ashes | i could be wrong, but i dont think so |
| 02:54.19 | ashes | 20% was my result |
| 02:54.47 | ashes | on 06/12/04 |
| 02:55.00 | ashes | a year and a half ago |
| 02:55.15 | ashes | and that's with nls disabled |
| 02:55.24 | ashes | and enabled in glibc |
| 02:55.51 | ashes | the performance may very well be better now |
| 02:56.15 | ashes | that was probably 0.9.27 |
| 02:56.37 | ashes | and glibc 2.3.4 |
| 02:58.12 | ashes | you can find yourself the bfbtester program, and run it on the same program.. one linked to uclibc and the other linked to glibc. bfbtester will run the program a few thousand times |
| 02:58.20 | ashes | and compare the times |
| 02:58.37 | ashes | run it three times for each library and compare the average |
| 02:59.09 | ashes | link bfbtester to uclibc too |
| 02:59.28 | ashes | so shared memory is used.. to make the test a bit more fair |
| 03:01.23 | ashes | the 20% difference i got was the time it took to compile binutils where the entire system was linked to either uclibc or glibc with the same cflags (-O2 in uclibc, not -Os) |
| 03:03.00 | dalias | yay |
| 03:03.10 | dalias | i just tested and my towupper/towlower impl seems complete |
| 03:03.39 | dalias | <PROTECTED> |
| 03:04.51 | ashes | im out of touch with latest developments. im trying to make time to get gcc-4.1 working with uclibc, with ssp, pie, fortify_source, and maybe libmudflap |
| 03:05.40 | ashes | last year when i tested libmudflap i found a 0% performance penalty, but im told this is impossible |
| 03:05.49 | dalias | ? |
| 03:05.57 | dalias | oh |
| 03:06.09 | dalias | yeah its impossible to avoid performance drop from pie and fortify |
| 03:06.27 | ashes | libmudflap is a bounds checking library. it should have some performance penalty |
| 03:06.39 | ashes | pie should have little or no penalty |
| 03:07.04 | ashes | if -fpie is used with ld -pie, there should be no noticable penalty |
| 03:07.15 | ashes | rather than using -fpic with ld -pie |
| 03:07.54 | ashes | i haven't read about fortify_source yet, but i think its just added compile-time checks |
| 03:08.03 | dalias | pie should have signifciant penalty |
| 03:08.11 | dalias | you lose a register and you corrupt the return stack |
| 03:08.30 | ashes | i never actually checked |
| 03:09.00 | dalias | personally i hate all that stuff |
| 03:09.21 | dalias | adding complexity to check for and block attacks is not the way to make a system secure |
| 03:09.34 | ashes | even if you don't personally use it, it helps the community have better source code |
| 03:09.38 | dalias | a system is made secure by making it so simple that any mistakes will be obvious to an auditor |
| 03:10.00 | ashes | it makes coding more strict |
| 03:10.17 | dalias | ah fortify might be, i dunno what it does |
| 03:11.53 | ashes | the real-world usefullness of ssp, and pie is not very well proven |
| 03:12.28 | ashes | im not aware of any exploit that ssp has saved anyone from.. since ssp was introduced |
| 03:12.46 | dalias | there are almost no stack smashing attacks anymore |
| 03:12.50 | ashes | but ssp has forced many software coders to code better |
| 03:13.01 | dalias | modern vulns are heap corruption based |
| 03:13.11 | dalias | especially integer overflow leading to heap corruption |
| 03:13.25 | dalias | mplayer was just hit by tons of them :( |
| 03:16.07 | ashes | libmudflap should be the best way to do runtime checking |
| 03:17.56 | ashes | there is a bounds checking option in glibc, but no offical gcc release supports it |
| 03:18.46 | dalias | heh |
| 03:18.51 | ashes | there's a branch in gcc's cvs, but it never made it into a release. gcc-2.97 or something like that |
| 03:18.59 | dalias | uhg :p |
| 03:20.15 | ashes | i wish uclibc would add blowfish |
| 03:21.01 | dalias | you mean for passwords? |
| 03:21.07 | dalias | why? |
| 03:21.32 | dalias | common lore has it that blowfish is fast but weaker |
| 03:22.19 | ashes | blowfish is slower than md5 or sha1 |
| 03:22.54 | dalias | personally i think a trivial crypt() that just performs strcpy would be fine |
| 03:23.05 | dalias | if someone can access the crypted passwords you're screwed anyway |
| 03:23.13 | dalias | they can always be cracked |
| 03:23.25 | dalias | thats why they're in a file thats only readable by root |
| 03:23.33 | ashes | blowfish didn't have a weakness as far as i know. md5 and sha1 do |
| 03:23.57 | ashes | a mathmatical weakness |
| 03:24.13 | dalias | i dont know any legit weakness against md5 or sha1 |
| 03:24.18 | dalias | md4 has a significant weakness |
| 03:24.33 | dalias | but even the md4 weakness does not apply to passwords |
| 03:25.40 | ashes | i read not long ago that a mathmatical weakness was found in sha1, by the university of china |
| 03:26.36 | ashes | the popular solution is to use sha256 or sha512, but the weakness remains. sha512 just buys more time |
| 03:29.34 | ashes | no one in their right mind will even attempt a brute force on sha1 or md5, but finding a weakness that eliminates 90% of possible passwords might make brute force feasable |
| 03:29.40 | dalias | this weakness does not apply to passwords |
| 03:29.50 | dalias | it's the same as the md4 weakness |
| 03:30.21 | dalias | and there's an md5 weakness of the same sort |
| 03:30.35 | dalias | what these vulns all allow you to do is the following: |
| 03:30.57 | dalias | given a known message (and of course its hash is also then known) |
| 03:31.12 | dalias | you can construct another message which has the same hash |
| 03:31.40 | dalias | so for instance, if the hash is being used to certify the authenticity of a file, you can make malicious corrupted files with the same hash |
| 03:35.44 | dalias | this vuln has nothing to do with passwords because it does not allow you to find all (or even one) message corresponding to a particular hash |
| 03:36.03 | dalias | it only allows you to find a second message with the same hash as the first already-known message |
| 03:37.35 | ashes | ok |
| 03:39.04 | dalias | imo hashing passwords is an irrational legacy practice from the old days when passwords were now shadowed and everyone could see the hashes in /etc/passwd |
| 03:39.27 | dalias | s/now/not/ |
| 03:39.39 | dalias | wow |
| 03:39.55 | dalias | i dunno whether that is incredibly cool or incredibly annoying :P |
| 03:55.02 | *** join/#uclibc monsieur_ (n=sieur@unaffiliated/monsieur) |
| 04:44.35 | *** join/#uclibc monsieur__ (n=sieur@unaffiliated/monsieur) |
| 05:13.30 | SpanKY | dalias: i'd say annoying |
| 05:13.41 | dalias | :) |
| 05:16.40 | dalias | btw |
| 05:16.42 | dalias | if anyone wants to see my casemapping code i checked it into my svn |
| 05:20.52 | dalias | at http://www.mplayerhq.hu/cgi-bin/viewcvs.cgi/libc/trunk/stdc/wctype/ |
| 05:20.58 | dalias | 868 bytes |
| 06:15.25 | *** join/#uclibc monsieur_ (n=sieur@unaffiliated/monsieur) |
| 06:50.41 | *** join/#uclibc monsieur_ (n=sieur@unaffiliated/monsieur) |
| 06:58.38 | *** join/#uclibc monsieur__ (n=sieur@unaffiliated/monsieur) |
| 07:02.59 | *** join/#uclibc blindvt__ (n=bf@M873P026.adsl.highway.telekom.at) |
| 07:17.09 | *** join/#uclibc monsieur_ (n=sieur@unaffiliated/monsieur) |
| 08:31.48 | *** join/#uclibc monsieur__ (n=sieur@unaffiliated/monsieur) |
| 11:17.24 | *** join/#uclibc keks (n=eisbaer@p548141E5.dip.t-dialin.net) |
| 11:20.13 | keks | hi, i'm trying to build uclibc using those instructions (http://www.nl.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter05/uclibc.html) and receive following error message when tying "make CROSS=i686-pc-linux-gnu- all" |
| 11:20.31 | keks | /bin/sh: i686-pc-linux-gnu-ld: command not found |
| 11:20.31 | keks | make[1]: Entering directory `/media/hda7/sources/uClibc-0.9.28/extra/config' |
| 11:20.31 | keks | gcc -O2 -Wall -I. -c conf.c -o conf.o |
| 11:20.31 | keks | gcc -O2 -Wall -I. -c zconf.tab.c -o zconf.tab.o |
| 11:20.34 | keks | gcc conf.o zconf.tab.o -o conf |
| 11:20.36 | keks | collect2: ld returned 1 exit status |
| 11:20.38 | keks | make[1]: *** [conf] Error 1 |
| 11:20.40 | keks | make[1]: Leaving directory `/media/hda7/sources/uClibc-0.9.28/extra/config' |
| 11:20.42 | keks | make: *** [include/bits/uClibc_config.h] Error 2 |
| 11:21.00 | keks | any ideas? |
| 12:00.51 | *** join/#uclibc sjhill (n=sjhill@eth13.com-link.com) |
| 12:33.25 | *** join/#uclibc sjhill (n=sjhill@eth13.com-link.com) |
| 12:53.24 | *** join/#uclibc prpplague (n=billybob@72.22.129.7) |
| 13:12.13 | *** join/#uclibc Kobus (n=Kobus@dsl-165-101-142.telkomadsl.co.za) |
| 13:12.51 | Kobus | hi |
| 13:14.40 | Kobus | I have no idea if im on the correct channel. But here goes: I'm doing a really small gentoo system. Building uclibc 0.9.28 and it says doing elfscan and hangs. Can any of you help me, point me in the direction/place I need to look? TNX |
| 13:15.58 | Kobus | Wait: I thing I should go ask at #gentoo-embedded. But tnx anyway |
| 13:16.03 | *** part/#uclibc Kobus (n=Kobus@dsl-165-101-142.telkomadsl.co.za) |
| 13:32.18 | *** join/#uclibc Zta (n=stephan@port572.ds1-arc.adsl.cybercity.dk) |
| 15:02.51 | prpplague | sjhill: ping |
| 15:04.22 | *** join/#uclibc blindvt_ (n=bf@M978P005.adsl.highway.telekom.at) |
| 15:32.34 | CIA-4 | 03landley * r15089 10busybox/miscutils/hdparm.c: Largeish cleanup patch from Tito, mostly if statement therapy. |
| 16:31.42 | *** join/#uclibc andersee (n=andersee@codepoet.org) |
| 16:52.17 | CIA-4 | 03landley * r15090 10busybox/ (4 files in 3 dirs): (log message trimmed) |
| 16:52.17 | CIA-4 | Rob Sullivan cleaned up the longstanding patch from Hideki IWAMOTO to add |
| 16:52.17 | CIA-4 | ibs and obs support to dd, and made it configurable. I cleaned it up a bit |
| 17:01.02 | *** join/#uclibc Zta (n=stephan@port572.ds1-arc.adsl.cybercity.dk) |
| 17:03.11 | *** join/#uclibc ignatoff (n=ignatov@c1-217-9.rrba.isadsl.co.za) |
| 17:10.21 | *** join/#uclibc ambroseL (n=bjb@router.fidus.ca) |
| 17:16.59 | sjhill | prpplague: pong |
| 17:19.34 | prpplague | sjhill: hehe, nm, just had a question and answered it myself, thanks anyway |
| 17:34.55 | sjhill | k |
| 18:05.44 | CIA-4 | 03vapier * r15091 10uClibc/Makefile.in: use cp -P instead of cp -d as pointed out by David DeHaven |
| 18:21.52 | *** join/#uclibc Zta (n=stephan@port572.ds1-arc.adsl.cybercity.dk) |
| 19:26.51 | *** join/#uclibc Zta (n=stephan@port572.ds1-arc.adsl.cybercity.dk) |
| 19:39.32 | *** join/#uclibc ulf_k__ (n=ulf_kypk@p54BD0CC1.dip0.t-ipconnect.de) |
| 20:57.17 | *** join/#uclibc tux1800 (n=eric@c66.110.147-33.clta.globetrotter.net) |
| 21:50.51 | *** join/#uclibc andersee (n=andersee@codepoet.org) |
| 22:01.45 | *** join/#uclibc andersee (n=andersee@codepoet.org) |
| 22:18.01 | *** join/#uclibc sjhill (n=sjhill@eth13.com-link.com) |
| 23:06.34 | *** join/#uclibc blindvt__ (n=bf@M835P018.adsl.highway.telekom.at) |
| 23:10.27 | *** join/#uclibc prpplague (n=dave@72.22.141.9) |