| | <<<Back 1 day (to 2017/06/14) | 20170615 |
| sebras | chrisl: would it make sense to try to use OSS-fuzz? https://github.com/google/oss-fuzz#accepting-new-projects | 14:42.44 |
| | chrisl: after an initial wave I guess the issues might get fewer and fewer. | 14:43.19 |
| chrisl | sebras: It would make sense, in other circumstances. But we already have a roster of fuzzing type bugs and coverity issues that haven't had any action. I don't see the point in accumulating more stuff to ignore | 14:46.10 |
| sebras | chrisl: right, are these category of bugs bountiable? should they be? | 14:47.04 |
| kens | They aren't | 14:47.36 |
| | I'm not convinced they should be. | 14:47.51 |
| chrisl | sebras: since they will now come under the security classification, we can't really make them bountiable | 14:48.03 |
| sebras | chrisl: right, forgot about that. | 14:48.45 |
| chrisl | Hence Shelly, as a "trusted outsider" is looking at them now | 14:49.13 |
| sebras | chrisl: gs needs more trusted outsiders. :) | 14:49.47 |
| chrisl | sebras: I suspect that insufficiently supervised outsiders are where some of the more heinous problems originated | 14:50.35 |
| | Once we have pretty much all the existing ones done, the coverity issues sorted, and the cluster indeterminisms stamped out, then we should go looking for more | 14:50.54 |
| kens | has not yet noticed any Gloucester Old Spot in the Gatwick holding pattern | 14:52.26 |
| chrisl | Nevertheless, it seems pointless going in search of new issues when we have a sizable queue of issues we already know about | 14:53.55 |
| kens | Certainly, no argument there | 14:54.10 |
| | Fix the problems we know about first | 14:54.24 |
| sebras | chrisl: the only reason is if we suspect we'd find new items that we'd prioritize higher for some reason. | 14:55.16 |
| | chrisl: other than that I certainly agree. | 14:55.29 |
| chrisl | sebras: but you usually have investigate the problem to know how serious it is, and once you do, you can often just fix it, so..... | 14:56.20 |
| | And, although I've no idea of the technique used, Marcos did fuzz testing a few years ago, so we could add it to our internal on-going testing, if it was felt valuable | 14:56.50 |
| sebras | chrisl: right, though doing that might be taxing on the cluster, whereas doing the same on google's machines is not. | 14:57.53 |
| chrisl | It would be interesting to know how they generate the test cases | 14:58.18 |
| | Hmm, we also have to supply "good" test files for them to start from | 15:00.47 |
| | sebras: perhaps you could try OSS-fuzz with mupdf | 15:05.33 |
| sebras | chrisl: I'm considering it. | 15:11.45 |
| chrisl | sebras: assembling a solid set of tests could be a challenge | 15:25.03 |
| kens | All of our public PDF files ? :-) | 15:28.42 |
| chrisl | If there's an easy way to trawl them from bugzilla, that would work. We can't just pull them from compare_files | 15:30.00 |
| kens | Look for attachments with .pdf and no customer # ? | 15:30.32 |
| chrisl | I wouldn't want to volunteer to download each one manually...... | 15:31.13 |
| kens | quick search comes up with 197 bugs | 15:31.44 |
| | Probably just checking the bug number tehn pulling the relevant Bugxxxxxx.pdf from the repository would be fine I think | 15:32.04 |
| | better search came up with 3089 :-( | 15:33.06 |
| chrisl | There are also non-customer bugs with attachments we were asked to keep private. We'd have to filter those. It would be possible to compose some SQL which would poke the database directly - but not by me | 15:35.56 |
| | Forward 1 day (to 2017/06/16)>>> | |
Log of #ghostscript at irc.freenode.net.