| | <<<Back 1 day (to 2018/02/01) | 20180202 |
| n35xdxb0 | just got introduced to mupdf. and like it a lot. was very happy to see it can read .epub. i'm using it from the terminal and was just wondering if it supports opening multiple pdfs at once | 00:22.21 |
| | as in mupdf *.pdf | 00:22.28 |
| | is there a keybinding to skip through files | 00:22.49 |
| tor8 | n35xdxb0: there is no such option, sorry. | 00:25.15 |
| n35xdxb0 | ok. will keep using it though. great work. i found a script online tht does more or less what i want, trying tht out now | 00:27.37 |
| | https://askubuntu.com/questions/563956/is-there-a-way-to-quickly-browse-multiple-pdfs-in-a-directory | 00:27.48 |
| | as an aside, it is interesting tht image readers include this function by default, often with options to delete an image within the viewer | 00:28.37 |
| | but pdf viewers often don't | 00:28.41 |
| sebras | wow... some of the knockout (and separation?) error handling in the draw device is severely lacking it seems. :-/ | 01:39.10 |
| | hopefully it is just me being clueless, but I don't that's the entire reason. | 01:39.31 |
| paulgardiner | tor8: are my signature commits okay to go now? | 12:18.57 |
| tor8 | paulgardiner: yes. all LGTM. | 12:20.52 |
| paulgardiner | Great thanks | 12:21.00 |
| titanous | sebras, tor8: will there be a security advisory and release fixing the OSS-Fuzz bugs? I need a link for the CVEs (it doesn't need to exist yet) | 16:32.14 |
| Robin_Watts | titanous: We release twice a year. Next release is in March. | 16:47.27 |
| titanous | Robin_Watts: can you give me a URL that will have a security advisory when that release comes out? | 16:48.16 |
| Robin_Watts | Nope. | 16:48.22 |
| | https://mupdf.com/news.html is where we put details of releases. | 16:49.18 |
| | We don't go into more detail than that. | 16:49.28 |
| | (or at least, if people want more detail, they can access the git logs themselves) | 16:49.41 |
| titanous | well, the git logs don't indicate the numerous security bugs that are being fixed and don't have CVEs or references to the OSS-Fuzz bugs | 16:50.18 |
| Robin_Watts | The git logs should contain bug numbers, I think. | 16:50.37 |
| titanous | for some but not all commits | 16:51.02 |
| Robin_Watts | shrugs. It is what it is. | 16:51.22 |
| sebras | titanous: I try to put references to the ghostscript bugs, and I do mention the oss-fuzz bugs I have fixed there. | 16:52.00 |
| | titanous: some of the oss-fuzz bugs were duplicates and I didn't bother to mention those (and the oss-fuzz bug reporting system automagically closed both). | 16:52.42 |
| titanous | okay, would you be willing to list the CVEs fixed in the March release announcement? | 16:52.43 |
| Robin_Watts | titanous: If a) someone supplied us with such a list, or b) such a list was trivially obtainable by looking at the git logs, yes. | 16:54.19 |
| titanous | I can give you a list | 16:54.34 |
| Robin_Watts | Then we can include that list in the release notes, sure. | 16:54.50 |
| titanous | okay, great | 16:55.02 |
| | thanks! | 16:55.04 |
| Robin_Watts | Thanks. | 16:55.07 |
| sebras | titanous: I'm not sure if it helps you but the oss-fuzz bugs what I believe I have fixed are: 5492 5494 9496 5501 5503 5505 5513 5521 5598 | 17:01.54 |
| titanous | sebras: did any of those not auto-close? the ideal option would be if you could comment on OSS-Fuzz with the link to the git commit and ghostscript bug each time you push a fix | 17:03.25 |
| sebras | titanous: I don't know, but I think they all autoclosed. | 17:04.07 |
| titanous | cool | 17:04.21 |
| sebras | I'm not sure why oss-fuzz reports several bugs for the same underlying issue, but I presume it is due to different backtraces. | 17:05.59 |
| titanous | very likely | 17:06.54 |
| | it does do a lot of deduping, but if the backtraces are completely different, it's not clear how it would dedupe | 17:07.14 |
| sebras | how often are bugs retested? | 17:07.49 |
| titanous | it looks like once every day or two? I haven't been tracking your commit log closely, but does that sound right? | 17:08.49 |
| sebras | titanous: I haven't yet noticed when things go from New -> Verified in monorail. | 17:09.32 |
| titanous | it'd be easier to track if you added a link to the fix commits to monorail, I sometimes can't figure out easily how they map to the bugs | 17:10.27 |
| sebras | titanous: btw, commit 4889fe51af274e0c158a0a8a2e6132c700937427 is a bug in the code that I found while fixing 5609. it was only later that I found that this issue was exhibited in 5604 as well. | 17:10.42 |
| | it is equally hard for me to know what issue are fixed and not fixed. because when I have fixed a single one several might be fixed. | 17:33.12 |
| | sometimes the bug reports have been closed before I had the opportunity to download it. | 17:33.30 |
| | its testcase. | 17:33.35 |
| titanous | sebras: thanks for doing that, I now have CVEs, I will add them to the closed issues later today | 19:11.37 |
| sebras | anthraxx: perhaps titanous and you can collaborate on the CVEs and whatever fixes are needed. as you might hav erealize titanous got mupdf as a project into oss-fuzz and several of the bugs stem that you may have seen stem from there. | 19:37.26 |
| anthraxx | titanous: can you give me a list of CVEs and their corresponding commits? | 19:39.19 |
| titanous | anthraxx: yes, I will be compiling that later | 19:39.37 |
| sebras | Robin_Watts: you around? | 20:47.23 |
| Robin_Watts | sebras: briefly. | 20:47.34 |
| sebras | Robin_Watts: I'm having questions about fz_draw_end_group() | 20:47.41 |
| Robin_Watts | ok. | 20:47.49 |
| sebras | my pdf causes the call to fz_convert_pixmap() to fz_throw(). | 20:48.06 |
| | so I have implemented a fz_try()/fz_catch() that frees the pixmaps from the state[1].pointers. | 20:48.36 |
| Robin_Watts | ok. | 20:48.51 |
| sebras | what I'm concerned about is that maybe fz_knockout_end() ought to be called in a fz_always() here. | 20:48.57 |
| | but I'm not entirely sure. | 20:49.00 |
| Robin_Watts | yes, it should. | 20:49.35 |
| | because it effectively is another 'pop'. | 20:49.44 |
| sebras | in that case I'll also move the DUMP_GRPOU_BLENDS at the end into the fz_try-block. | 20:50.11 |
| | and have the fz_knockout_end() call at the end of fz_always()). | 20:50.26 |
| Robin_Watts | ok. | 20:50.32 |
| | dumping the group blends probably doesn't make any sense if the group barfed. | 20:51.03 |
| sebras | I assume keeping the order fo the dropping of the pixmaps and calling fz_knockout_end() is crucial. | 20:51.06 |
| Robin_Watts | yes. | 20:51.16 |
| sebras | no, that part shouldn't be in fz_always of course. | 20:51.18 |
| Robin_Watts | gotta go, sorry. | 20:51.20 |
| sebras | np, that helped! | 20:51.28 |
| | Forward 1 day (to 2018/02/03)>>> | |
Log of #mupdf at irc.freenode.net.