Hi, Thanks for all the feedback and comments. I tried to address all them below.
> The crash.sh script seems to set LD_LIBRARY_PATH. Is that actually > needed? I'd prefer something that doesn't need something like that, > since being able to crash apps if you load a broken library isn't very > hard. The purpose of the custom environment is to run the program with the same environment as it was set up when the program was analyzed with Mayhem. This is not necessary to reproduce most crashes however. I will remove the *LIBRARY_PATH from the environment, and re-confirm the crashes without it. > Since you're already running this under gdb, would you mind attaching a > full backtrace with debug symbols installed too? That is a good idea, but I'm afraid I cannot easily get the debug symbols. As far as I know, binaries from debian packages do not contain symbols. Additionally, for 91% of the packages where we found a crash, there isn't any associated -dbg package. It should be easy however for a developer that has a program with debug symbols to generate the backtrace. I could include a backtrace without symbols, but that does not seem particularly useful. What do you think? > Would it be possible to initially publish all the bug reports on your > web site under some random URL and then mail that to the maintainer > with a clearly indicated date when they will be made public? Good point. I will mail the maintainer the bug reports, and give them 1 week to prepare before submitting the bug to the Debian BTS. > Can one also access, even before you go and file bugs, information for other > packages? I cannot actually find any reports for the package listed in the > dd-list under my name in your Packages, Runs, nor Programs pages. (And the > fact > that the reported package is a transitional package does make this a little > suspicious.) The reports are not public yet. Since you are a developer included in dd-list, we will send you an email containing the crash information for the programs you are developing. You will receive the email 1 week before the crash is submitted to the BTS. Does that sound reasonable? > Have you considered adding Mayhem to Debian so > that it may be added to the usual battery of tests some developers run > before uploads? We are considering offering Mayhem as a web service as opposed to adding it to Debian. I'd love to see Mayhem check every package release automatically, so that (some) crashes are detected and fixed before the binary being released. Mayhem is however not open source, so I'm not sure people will be willing to make use of it. Let me know if you think otherwise, and we'll discuss how we can set this up. > Are you aware of the firehose project and format that Fedora and some > Debian folks have been working on? It is a standard machine-readable > format for defect finding tools to report their findings so that sites > like the Debian PTS can report those to developers. I was not aware of firehose. This is a cool project. It would be great to have a similar system for dynamic analysis of binaries, that allows non-free software to submit reports. Even though Mayhem is not open source, we still want to improve Debian's security and stability :) Thanks, The Mayhem Team Cylab, Carnegie Mellon Univeristy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caf1as2gcoduwuafkrwxp2hk1-jjze65rhomws+jczzmcdzo...@mail.gmail.com
