IRC Logs for #crux-devel Friday, 2012-06-08

*** tilman has quit IRC03:04
*** tilman has joined #crux-devel03:05
*** sepen has joined #crux-devel04:05
*** teK__ has joined #crux-devel04:21
*** teK_ has quit IRC04:21
*** teK__ is now known as teK_04:28
sepenjue: ping04:50
teK_maybe we want to reconsider the use of md5 (related: flame malware analysis)05:54
juesepen: re06:34
jueteK_: for what?06:34
sepenjue: http://crux.nu/~sepen/tmp/mdev.notes.txt06:36
sepenjue: http://sepen.it.cx/crux/ports/crux-2.7/sepen/mdev/06:36
sepenXorg worked fine here, autoloading modules, etc. anyways there are some dependencies from mesa3d to libudev, etc.06:37
juethe evdev xorg driver works for you?06:38
sepenah, and no problems with loading firmware06:38
sepenjue: I tried with input-mouse input-keyboard installed06:38
sepenbut I could do a try now06:38
juebtw, I was able to build libdevmapper without udev06:39
sepennice06:40
sepenso all dependent should work too06:40
sepenlilo, etc.06:40
teK_http://news.softpedia.com/news/Experts-Name-Flame-s-MD5-Chosen-Prefix-Collision-Attack-Unknown-274218.shtml06:40
sepenjue: without mouse/keyboard I have the issue which you're able to see the desktop but can't move the mouse or type anything06:41
sepenjue: can't autoload evdev06:42
sepenmaybe via xorg.conf, no idea06:42
teK_206:42
sepenjue: note that 10-evdev.conf was removed as I noted06:43
*** mike_k has joined #crux-devel06:43
sepen"...The evdev driver configures your input devices, as needed, using HAL or udev. This allows for the X server to automatically detect the keyboard and mouse you're using for your input devices..."06:48
jueteK_: I'd say the fact that it's not possible to create a new tarball with the same md5sum as an already exiting one is still valid06:48
teK_i will read up and report again. md5 *will* break sooner or later06:49
juesepen: yep, that's the reson why the evdev driver doesn't work06:49
jueteK_: but not in a way that's relevant for us06:50
sepenjue: well, so far I've seen, I'm comfortable with mdev since I have only to set rc.modules and xorg.conf (as was the first time I tried CRUX)06:54
jueteK_: as long as debian is using md5 for it's sources I can sleep very well06:54
teK_debian and crypto.. haha -.-06:54
jueteK_: crypto?06:55
sepenopenbsd uses sha25606:55
teK_http://jblevins.org/log/ssh-vulnkey06:56
juehmm, I'm a bit wondering, the only purpose for our md5sum is to verify that a tarball is the same one the maintainer of the port had at build time06:57
sepenyep, and the same for releases06:58
sepen*iso releases06:58
juein that usecase I dont see a problem at all, and the whole thing isn't worth to be called crypto ;)07:00
teK_md5 shall guarantee integrity which it cannot do 100% reliably anymore07:00
jueteK_: have you read what I said above?07:00
teK_guess07:00
teK_;)07:00
teK_we had different opinions the lastthis issue came up and will stay the same this time :)07:01
jueof course upstream can fake us. If they build at the _same_ run two different tarballs, these tarballs can have both the same md5sum even if the content is not the same07:02
juebut a attacker, lets say a kind of man-in-the-middle, cannot do that07:03
jueteK_: that has nothing to do with opinions, if what I've said is no longer valid we have to do something, of course07:05
teK_http cannot be mitm'd?07:08
teK_people use mirrors (gentoo's etc.)07:09
teK_if it werenot that easy to support different hashalgos I'd say: deal with it the attack _is_ somewhat theoretical07:10
jueteK_: which attack?07:11
teK_If they build at the _same_ run two different tarballs, these tarballs can have both the same md5sum even if the content is not the same07:12
jueyeah, of course, but if upstream is doing that it's easier to put the faulty code into the sources at a different stage ;)07:13
jueor not?07:14
teK_anybody can do that by mitm-ing the http download or by cracking the mirrors07:14
jueno, he cannot, that's the whole point!07:14
teK_with nobody noticing because "checksums were  identical"07:14
jueteK_: you have to add some code to the original sources and replace that code later with something different07:16
Romsterthe whole md5 debate is a dead end i know it's insecure but no one seems to care, it's /good enough/ for file hashes.07:17
jueit's not insecure for our usecase07:17
Romsterpersonally i'd use sha256 as sha1 has shown signs of weakness too.07:18
Romstermd5 must be good enough till as ccache uses sh4 which is less expensive to compute and weaker again than md507:19
teK_jue: I will check that some time later07:19
Romsters/till/still07:19
jueRomster: same here, this weakness is only relevant for a different use07:19
Romstermd4 sorry not sh4...07:19
Romsteras in passwords etc that arn't salted.07:19
jueno, I meant your statement to sha1 above07:20
jueteK_: ok07:20
Romsteryeah sha1 has a different weakness than md5.07:20
juebut it is as good as md5 or sha256 for what we need it07:21
Romsterhmm have to find a solution to this novou in mesa3d ati driver and libdrm versions, any ideas?07:21
Romsteri was hoping mesa3d 8.0.3 would of fixed that.07:22
jueno, for nouveau to work we need 8.107:23
juethe whole nouveau thing is kinda broken currently07:23
Romsteri might just drop nouveau out of mesa3d for now then.07:24
jueyeah, do that07:24
Romstersad state.07:24
jueindeed07:24
Romsteri'm not using it yet but i would like to and a few others are probably using it.07:24
Romsterta for the suggestion07:25
Romsteri hope tilman picks up on my work :)07:25
jueteK_: read the first paragraph of the "Vulnerability analysis" section of the following paper -> http://www.win.tue.nl/hashclash/SoftIntCodeSign/07:31
teK_flame seems to utilize another attack07:32
teK_but I will07:32
juesepen: I think the mdev thing looks not so bad at all07:38
juefrom a current point of view it might be doable to replace udev with it07:39
juebut we should do some tests with a raid/lvm system07:39
* jue looks at Romster and teK_ 07:40
teK_I'd wait for the systemd devs to decide about the disable-option07:46
teK_and we have tocheck how muich effort/loss comes with using mdev07:46
jueteK_: sure, that's what sepen and me are trying to do currently07:47
jue;)07:48
juebut there's still no response to the patch at linux.hotplug.devel :(07:48
RomsterVulnerability analysis paragraph?07:49
jueyeah, it's somewhere in the middle of the document07:50
jueafter "Verification"07:50
teK_jue oh ok07:51
teK_gott go afk now, "brb" folks :P07:51
jueteK_: bye07:51
teK_cu07:51
Romsterlater teK_07:52
jaegerVolkerding's comments about systemd in that linked interview were entertaining08:19
Romstermust read that too08:34
juesepen: building util-linux-ng without having udev installed works for me08:53
Romsterbut it's a no deal for libdevmapper yet08:54
jueno, that works too08:55
*** c0x has quit IRC08:55
jueand no problems building lvm2 without udev08:56
juewell, at least for me, let's see what sepen finds out about his problems08:58
Romsteri was told that lvm2 only lightly uses udev09:06
Romsterfor node creation etc.09:06
frinnst15:53 <jue> sepen: building util-linux-ng without having udev installed works for me09:33
frinnstasdf09:33
* frinnst has the habbit of marking text as he reads along09:33
jue:)09:34
juesepen: forgot to say thanks for your mdev port, works nice09:34
frinnstwhere can one find that port?09:34
frinnsti need to break something!09:34
juehttp://sepen.it.cx/crux/ports/crux-2.7/sepen/mdev/09:35
juesepen: had to change two things in /etc/mdev.conf: I have no uucp group and the rule for console doesn't work because of ln errors09:36
frinnstutil-linux-ng also built for me with mdev, though nfs-utils doenst wanna play along without libdevmapper09:51
juejust builds fine for me09:53
jueFWIW, that's the modified libdevmapper I'm using -> http://db6e88d22e2ccf0f.paste.se/09:53
jaegerAnyone have a problem with text being invisible in gvim? This is only happening on my laptop with the intel GPU though I don't know if that's the problem10:07
Romsternever had that issue but i don't have anything with intel video10:08
juejaeger: my laptop has a intel chip, gvim works without issues here10:14
jaegerhrmm... perhaps it's an artifact caused by using an external monitor with the laptop screen disabled10:15
Romsterperhaps layering wrong with xranama or how ever it's spelled10:24
*** joe9 has joined #crux-devel10:26
*** jue has quit IRC10:54
*** jue has joined #crux-devel10:54
frinnstjue: ghostscript doesnt need to depend on cups12:21
*** sepen has quit IRC12:30
*** sepen_ has joined #crux-devel12:32
sepen_hey12:32
sepen_sorry I forgot irssi connected from the office12:32
sepen_don't have enough time today, but I planed to continue the research this weekend12:33
sepen_jue: nice to know about util-linux12:33
sepen_well sorry again, I should part12:33
sepen_see ya'12:33
*** sepen_ has quit IRC12:33
juefrinnst: yeah, I know12:40
juein the past I had two ports, with and without cups stuff, but that was too much work12:41
frinnstwell, here we go: rebooting to mdev12:56
frinnstevdev without udev is a no-go?13:34
frinnstseems ppl have got it working but i guess that was with older versions13:35
jaegeror with hal, maybe?13:36
frinnstit wont compile without libudev13:36
rmullAnybody here familiar with the USB protocol? I have a specific question13:37
rmullSay I have 4096 bytes to transmit to the USB host. Regardless of the transfer type (bulk, interrupt, whatever) there is a fixed data payload size.13:37
rmullMy data is bigger than that payload size. Do I need to wait until I am polled enough times to drain my buffer, or does it get sucked out all at once when I indicate that I have "data remaining" after the first transfer goes?13:38
rmullSorry for the OT :\13:39
frinnstwow, never realized i used that many modules14:05
frinnstand no lazy autoload with mdev :>14:05
frinnstasdf, impossible to find the mouse sensitivity i had with evdev !"¤¤14:08
frinnstnevermind, a restart seems to have solved it14:12
frinnsthttps://github.com/slashbeast/mdev-like-a-boss14:15
jaegerrmull: no idea there, sorry14:29
jaegerStill having the weird gvim issue, very funky14:58
jaegerI can see the text on the bottom line where commands and status are displayed15:05
jaegernone of the actual editing text, though15:05
jaegerNever mind, even that is inconsistent15:06
jaegerweird15:06
frinnstgpu?15:24
jaegerhd3000 I think15:39
jaegerit's the sandybridge mobile GT2+15:39
frinnstis that a amd gpu?15:42
frinnstworks for me with a hd5700 :(15:43
jaegerDamn it, it's fucking cairo again15:44
jaegerIt's intel15:44
jaegerI downgraded to cairo 1.10.2 and it works fine15:44
frinnsthmm, mdev daemon fails to launch15:49
frinnstfredrik@nibbler:~$ sudo mdev -s15:50
frinnstln: cannot remove '0': Operation not permitted15:50
frinnstln: cannot remove '1': Operation not permitted15:50
frinnstnot very informative15:50
*** mike_k has quit IRC15:59
*** mike_k has joined #crux-devel16:11
*** mike_k has quit IRC16:41
*** ___________mavri has quit IRC21:30
*** ___________mavr has joined #crux-devel21:31
*** c0x has joined #crux-devel22:18

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!