On Wed, Jan 17, 2018 at 12:13 AM, Theodore Ts'o <ty...@mit.edu> wrote: > On Tue, Jan 16, 2018 at 09:31:26AM +0100, Dmitry Vyukov wrote: >> On Tue, Jan 16, 2018 at 8:12 AM, Theodore Ts'o <ty...@mit.edu> wrote: >> > I just checked a recent report from the Syzbot, and it's not fixed. >> > The raw.log file still uses a Content-Type of >> > Application/Octet-stream. Worse the reproducer C source file has a >> > content type of Application/Octet-stream instead of the much more sane >> > Application/text. <Face palm> >> >> >> I will look into using a different mailing system which allows more >> control over email contents. >> A quick fix for raw.log will be to rename it to raw.log.txt. Not sure >> if text/plain repro.c.txt is better than application/octet-stream >> repro.c... > > My personal opinion is that if there is no way to force the content > type except by using magic extensions --- which is super-surprising to > me; that seems like a broken API and a feature request bug should be > filed against the relevant API --- using repro.c.txt would be the best > of bad alternatives. Someone is going to have to exit to a shell to > compile the repro, and renaming the filename isn't a big deal. The > Mail User Agent I use (mutt) allows me to specify the directory to > save the file, and gives me the opportunity to edit the filename, > before I save it. So at least for me, it really isn't a big deal for > you to use repro.c.txt.
Good. I've made such change, it's now raw.log.txt and repro.c.txt: https://github.com/google/syzkaller/commit/afcb994770d7e0f4b88c623bec76fbdce57d3910 I've also mailed a change to appengine that supports *.c, *.log and *.patch as text/plain extensions. There does not seem to be any major objects to it, but it will probably take some time to be deployed in prod. After that I will rename them back.
