| | <<<Back 1 day (to 2018/04/08) | 20180409 |
| simple | ok, i'll give that a shot tomorrow at work | 00:48.36 |
| tor8 | chrisl: sebras: another jbig2dec commit on ghostpdl tor/master (this one fixing the autoconf build that sebras noticed I broke) | 09:51.42 |
| sebras | tor8: works for me. | 12:05.17 |
| | chrisl: kens: did you see my weekend mumblings? opinions? | 12:09.19 |
| kens | Err, I probably saw them.... | 12:09.31 |
| sebras | kens: but no opinions? | 12:09.44 |
| | kens: if not, that's ok to. :) | 12:10.01 |
| kens | I think I missed one, I'm just looking now | 12:10.02 |
| | Technically these images are not illegal ? | 12:10.42 |
| sebras | nope. | 12:10.47 |
| kens | Then I'd be inclined to leave it | 12:10.57 |
| | If you send a broken image and it takes a liong time, then tough | 12:11.12 |
| sebras | kens: one of the issues I'm seeing is e.g. a symbol dictionary with 2**32 entries. | 12:11.19 |
| kens | Whereas if you send a *huge* legeal image and we barf on it, then people will complain | 12:11.27 |
| | sebras, but if its legal then throwing an error seems bad | 12:11.55 |
| sebras | kens: another example is the size of the grayscale(really?) image used in halftoning./ | 12:12.05 |
| kens | jbig2dec does haftoning ? | 12:12.24 |
| | And teh threshold array is effectively gray, yes, if that's what its using | 12:12.42 |
| sebras | apparently. I haven't read up on the details. | 12:13.10 |
| kens | Well i its using a threshold array that will be an array of values between 0 and 255, which you can construe as gray | 12:13.34 |
| | But I thougth jbig2 only allowed monochrome images, so obviously I've missed something there | 12:13.55 |
| | Possibly this isn't permitted in PDF, I only ever read enough of the spec to deal with PDF | 12:14.14 |
| sebras | I haven't seen taht this is limited. | 12:14.43 |
| kens | Personally I'm disinclied to break the decoder for legal (if mad) images, by throing an error when a field is unusually large, just beacuase broken files take a long time to work. | 12:14.59 |
| sebras | just how the JBIG2 bitstreams headers are organized. | 12:15.03 |
| kens | Its been a long time since I looked at JBIG2 | 12:15.18 |
| chrisl | If images of that size are allowed, then we can't really reject them. We should make sure we're not overflowing anywhere | 12:15.34 |
| tor8 | sebras: thanks. | 12:25.46 |
| sebras | tor8: is on master! :) | 13:40.28 |
| HenryStiles | do those bugzilla bugs belong to mozilla or us? I think mozilla | 15:01.24 |
| kens | has no idea | 15:01.39 |
| HenryStiles | I have been talking to corin about updating to 5 that might cure them but I'm not sure | 15:02.40 |
| chrisl | I doubt the people who report these care - our site, our problem.... | 15:02.55 |
| HenryStiles | something to discuss at the meeting tomorrow | 15:03.02 |
| kens | I'm not certain exactly what the problem is, not enough of a web-head to comprehend it. Also, not much inclined to btoher either..... | 15:03.07 |
| chrisl | I haven't really read the reports. | 15:03.41 |
| kens | Well I haven't watched the videos :-) | 15:03.54 |
| HenryStiles | exactly what we need in our attachment database, a bunch of mp3's | 15:04.21 |
| kens | But redirecting Bugzilla to another site sounds like its a) Obviously incorrect and/or b) not a problem really | 15:04.24 |
| | web 'security experts' love to send videos as proof | 15:04.47 |
| chrisl | Probably easy enough to fix the .gitignore one... | 15:07.39 |
| HenryStiles | s/mp3/mpg | 15:08.14 |
| chrisl | And we probably shouldn't still have a travis install, either | 15:08.57 |
| kens | Which one is .gitignore ? | 15:09.05 |
| | Yeah the travis one can just go | 15:09.11 |
| | I dount if its really 'sensitive' | 15:09.20 |
| chrisl | 699199 | 15:09.22 |
| kens | Ah I missed tha tone. Is the .gitignore file *really* a sensitive file ? | 15:10.00 |
| chrisl | The worry is if travis is still on their, it's another attack surface, probably not being updated | 15:10.01 |
| | s/their/there | 15:10.14 |
| kens | Yeah we should probably remove it. | 15:10.22 |
| | But neither file really looks sensitive to me | 15:10.30 |
| HenryStiles | chrisl: looks like you fixed travis.yml as well? I assume whatever permissions you changed will transfer over to the new aws installation. | 15:28.08 |
| chrisl | HenryStiles: travis.yml was in the same directory, so easy enough to resolve. I've no idea about the new install, but it's not like permissions are hard to change | 15:29.29 |
| HenryStiles | chrisl: if you're only change was in the bugzilla directory we are good | 15:33.07 |
| chrisl | Yeh, I actually changed a few files, just to avoid the inevitable follow up reports for those, too | 15:34.30 |
| HenryStiles | I see a mix of root and www-data in the same directory, that looks suspicius as well | 15:35.16 |
| | group wise | 15:35.24 |
| chrisl | Well, the git stuff makes sense to be root, and I think the others in the root group are travis related | 15:36.42 |
| | I'm guessing .bzrignore comes from bugzilla | 15:38.13 |
| | Forward 1 day (to 2018/04/10)>>> | |
Log of #ghostscript at irc.freenode.net.