| | <<<Back 1 day (to 2017/10/09) | 20171010 |
| rnissl | Hi kens, I'd like to talk about http://bugs.ghostscript.com/show_bug.cgi?id=698652 | 09:43.49 |
| kens | OK | 09:43.54 |
| rnissl | I think this is an incompatbile change as ghostscript yields an error | 09:44.30 |
| kens | Yes, but it also tells you why and what to do about it | 09:44.42 |
| chrisl | rnissl: To be fair, I *should* have included it in the release notes, but it slipped - I apologise for that. | 09:47.27 |
| rnissl | chrisl, that's what I would have expected. Yesterday I read news.htm, upgraded ghostscript and then got complaints from my users that PDFMail is nolonger working. | 09:49.26 |
| | sure, I should have run a test either, but it didn't look like there will be a problem. | 09:50.06 |
| chrisl | rnissl: Frankly, using options with such *massive* security implications in a "production" environment is just a really bad idea | 09:50.45 |
| rnissl | I agree | 09:51.11 |
| | I've removed DELAYBIND and tested most of PDFMail's functionality and it looks like I don't need it at all | 09:52.15 |
| | looks like I was inspired by pstotxt, which used it. | 09:53.43 |
| chrisl | If you find cases where you do "need" it, we discuss it - there may be a more secure alternative solution, or we can consider reinstating the option. But we'd *really* like to get rid of it because of the aforementioned security implications. | 09:53.52 |
| | s/we discuss it/we can discuss it | 09:54.20 |
| kens | I'm pretty sure we removed pstotxt as well :-) | 09:54.23 |
| chrisl | Well, we have txtwrite now | 09:54.34 |
| rnissl | would you please be so kind an have a look at https://pastebin.com/Qxiy4UiL | 09:59.00 |
| | at the end of the file, I redefine some postscript operators to that I can analyse the printed text | 09:59.40 |
| | I wonder if any of these could require DELAYBIND | 10:00.37 |
| kens | Only if you then run PostScript which uses //show or similar I think | 10:01.08 |
| rnissl | what does that // mean? | 10:01.58 |
| kens | Which you could get around by definiing the procedures in gs_init.ps | 10:02.02 |
| | immediatley evaluated name | 10:02.47 |
| chrisl | I don't think it'll affect //show | 10:03.23 |
| kens | But as long as your dictionary is on the stack at the time you should be OK | 10:03.25 |
| rnissl | looks like I put my definitions in userdict | 10:04.10 |
| chrisl | The case that won't cover, with or without DELAYBIND is Postscript that does "systemdict /show get exec" | 10:04.10 |
| kens | That's just nasty | 10:04.22 |
| | You would have to alter gs_init.ps to get around that | 10:04.37 |
| chrisl | It's pretty rare, but does happen | 10:04.40 |
| kens | Define the procedures while systemdict is still writeable | 10:04.47 |
| rnissl | writeable systemdict -- I came to that conclusion too | 10:05.52 |
| chrisl | On, the lack of DELAYBIND will affect the results if your input is PDF | 10:06.48 |
| | s/On/Oh | 10:06.59 |
| kens | Hmm yes true | 10:07.04 |
| | Because hte PDF itnerpreter will have the existing definitions bound in | 10:07.17 |
| chrisl | Yeh :-( | 10:07.25 |
| kens | Not the redefinitions | 10:07.25 |
| rnissl | That's not a problem for now. Input is PS. | 10:08.00 |
| | where do I find gs_init.ps? | 10:08.20 |
| kens | In ghostpdl/Resource/Init | 10:08.30 |
| rnissl | so it is compiled into ghostscript? | 10:09.03 |
| kens | If you are using the ROM file system, yes | 10:09.14 |
| | Which I shold note, is the default | 10:09.35 |
| rnissl | well, so far I didn't touch any files of a ghostscript installation on win32 | 10:10.31 |
| kens | On Windows its always built in, and we don't currently supply the files in the installer. | 10:10.53 |
| | You can pick up the files from our Git reposotiry, and then use the -I switch to tell Ghostscript to use files from disk in preference to the ones built into the ROM file system | 10:11.25 |
| chrisl | IIRC, you can also define a GS_LIB environment variable with the search path, rather than add -I to every invocation | 10:13.10 |
| kens | Yes I think you are correct | 10:13.19 |
| rnissl | I've used -I anyway to specify the path to mailFilterText.ps for example | 10:14.51 |
| | so if I put that file (gs_init.ps) into that directory, it will replace the compiled in one? | 10:15.39 |
| kens | Hmmmmm | 10:15.51 |
| chrisl | You need the entire content of Resource/ IIRC | 10:16.28 |
| kens | Without checking I can't be certain, but I think its 'possible'you may need the entire resource structure. I'm not certain though, its not a configuration I generally deal with | 10:16.34 |
| chrisl | Or at *least* Resource/Init | 10:16.39 |
| rnissl | what do you think about using -dWRITESYSTEMDICT? | 10:16.49 |
| kens | Horrible security ciolation | 10:17.01 |
| chrisl | That's an even bigger security hole than DELAYBIND | 10:17.07 |
| rnissl | so I could put my implementations into systemdict | 10:17.14 |
| kens | Yes but any program could then write to systemdict, which really opens you up to malicious code if it becomes known | 10:18.28 |
| rnissl | agreed | 10:18.44 |
| | thanks for the talk so far -- I'll be off for lunch now | 10:19.25 |
| kens | I've a feeling we only preserved WRITESYSTEMDICT for some horribly hacky tool | 10:19.30 |
| rnissl | chrisl, if I feed my mailFilterText.ps as command line argument to ghostscript I assume, my operator redefinitions went into userdict | 11:01.24 |
| kens | If you do not specify a dicitonary they go into whatever dictionary is currently on top of the dictionary stack. When Ghostscript starst up, in common with all PostScritp interpreters, the current dictionary is userdict. | 11:02.15 |
| rnissl | so with or without DELAYBIND, "systemdict /show get" for example would never have returned my implementation | 11:02.39 |
| kens | Yes, correct | 11:02.48 |
| | That's what I meant when I said that was nasty :-) | 11:03.02 |
| rnissl | kens, you mean with nasty, that I didn't use my own dict? | 11:06.25 |
| chrisl | No, kens means "systemdict /show get" is nasty | 11:07.04 |
| kens | No sorry, I meant that the PostScript program in that case would be nasty. Its really not a good idea to deliberately pull definitions from systemdict. | 11:07.07 |
| chrisl | It's *very* much not in the spirit of how Postscript is intended to be used | 11:07.23 |
| rnissl | dict stack is the way to walk to resolve names, isn't it? | 11:08.09 |
| kens | You shuldn't need to resolve names yourself, the interpreter does that. It does it, as you imply, by searching the dictionaries on the dict stack. | 11:08.44 |
| rnissl | yeah, that's what I ment. | 11:09.07 |
| kens | But you *can* pull key/value pairs form a specific dictionary, without it being on the dictionary stack | 11:09.14 |
| chrisl | As I said, it's a rare construct, but not unheard of - and it can be useful for very specific debugging cases if you know what you are doing | 11:09.14 |
| | Actually, the main place I've seen it used is for showpage | 11:10.12 |
| rnissl | just to prove my understanding of DELAYBIND, all binds where delayed to .bindnow and at that time, all resolving used the dict stack at that point in time | 11:10.53 |
| kens | I'm not certain about how the names are resolved because, obviously, there's the possibility of binding being deferred for objects whose dictionary is removed from the dictionary stack before .bindnow | 11:12.29 |
| | I don't know if DELAYBIND copes with that, by deferring the removal of the dictionary, or throws an error. | 11:13.01 |
| | All of this confusion is one of the reasons we removed DELAYBIND | 11:13.14 |
| chrisl | Also, the *vast* majority of people who use DELAYBIND on the command line never actually call .bindnow - which makes it an even more horrific security nightmare | 11:14.27 |
| rnissl | for PDFMail, I feed ghostscript a couple of input files like mailFilterText.ps then -c .bindnow followed by -f input.ps | 11:15.03 |
| | the latter is the content of what the printer driver provided | 11:15.21 |
| kens | If you must use DLEYBIND then that is a reasonable way to proceed | 11:15.40 |
| rnissl | so in my case, DELAYBIND would have only an influence on the files given before .bindnow and not for input.ps | 11:17.55 |
| kens | Yes | 11:18.08 |
| rnissl | as I have full control about these files, then I don't need DELAYBIND | 11:18.39 |
| | I think, my understanding several years ago of DELAYBIND was, that I could poke that nasty construct to use my for example /showpage implementation | 11:20.10 |
| | but this never worked | 11:20.19 |
| | then | 11:20.28 |
| | so I conclude now, I don't need DELAYBIND ;-) | 11:21.25 |
| kens | Very likely, we couldn't think of many good resons for it | 11:21.50 |
| rnissl | another thing I'd like to talk about is -dSAFER | 11:22.10 |
| kens | That's *much* more complicated | 11:22.21 |
| rnissl | at the moment I rely on an implicit -dNOSAFER but docs tell me to explicitly specify -dNOSAFER or make the code work with -dSAFER | 11:23.42 |
| kens | Currently the default is still -dNOSAFER, despite the documentation, I don't think that's likely to change | 11:24.19 |
| chrisl | NOSAFER is the default, and will probably remain so | 11:24.20 |
| rnissl | I think -dSAFER wouldn't work for me, as I need to write some excerpt of the document processed by hooking the show operators into files | 11:26.13 |
| kens | Then you cannot run with SAFER | 11:26.31 |
| | Umm. | 11:26.36 |
| rnissl | but on the other hand, I'd like to run input.ps in a safe environment | 11:26.44 |
| kens | You can't realistically have it both wyas. PostScript allowed to write files, and at the same teim, not allowed to write files. | 11:27.16 |
| | chrisl I have a vague memory of the CWD being valid to write files when SAFER is true, but I am not certain ? | 11:28.01 |
| chrisl | Um, not sure.... it's a while since I looked into the rules. There's less flexibility with writing than reading, though | 11:28.43 |
| rnissl | I'd like to try -dNOSAFER combinded with save, .setsafe and .runandhide | 11:28.57 |
| kens | runandhide is gone | 11:29.13 |
| | You would have to edit gs_init.ps to briong it back | 11:29.24 |
| rnissl | kens, did you fix the link referencing it in Use.htm as well? | 11:30.38 |
| kens | I removed it from both HTML files | 11:30.49 |
| chrisl | We only check the SAFER permissions when opening the file, so if you opened the output file in your mailFilterText.ps file, then called .setsafe at the end of mailFilterText.ps, that *should* work | 11:31.49 |
| rnissl | thought about that too | 11:34.24 |
| | at the moment, the file is opened written and closed while processing input.ps whenever a hooked command is executed | 11:35.07 |
| | writing it after input.ps would require .runandhide to prevent input.ps to maliciously get access to the unsafe state | 11:37.10 |
| kens | Only if you do a save before you do .setsafe, all .runandhide does is make that save state inaccesible | 11:37.56 |
| rnissl | sure, as documented for 9.21 | 11:38.23 |
| kens | And as Chris says, if you open the file before calling .setsafe, then you can write to it as much as you like, provided you don't close it until you are done | 11:38.29 |
| rnissl | ahh, ok, after .setsafe, I cannot open new files in filesystem for writing | 11:40.46 |
| kens | Exactly | 11:40.54 |
| rnissl | opening the files early shouldn't be to complicated to change | 11:42.55 |
| | so thanks for the talk, I'll now try to implement what we discussed. | 11:45.18 |
| kens | No problem | 11:45.25 |
| chrisl | rnissl: Um, what license is PDFMail under? | 11:45.41 |
| rnissl | AGPL | 11:46.00 |
| chrisl | Oh, cool | 11:46.15 |
| | Sorry, there appears to be a commercial product of the same name | 11:46.38 |
| rnissl | it's a loose collection of script files so there is actually nothing to hide | 11:46.41 |
| kens | Yes we had this discussion a few bug reports back :-) | 11:46.52 |
| chrisl | Ah, sorry - sometimes get paranoid | 11:47.05 |
| kens | Well I wouldn't have remembered, but I happened to run across the old report | 11:47.28 |
| rnissl | yeah, I've googled for PDFMail when we discussed that several months ago | 11:48.05 |
| | there is actually a product with the same name | 11:48.24 |
| kens | lunches | 11:48.29 |
| chrisl | rnissl: The other thing I've considered is adding a writable directory list to the SAFER code (there's already a readable list). But so far, there's been no compelling reason | 11:48.40 |
| rnissl | chrisl, in the morning I was about filing a feature request for that | 11:49.29 |
| chrisl | rnissl: In every case, so far, there's been an alternative solution | 11:50.34 |
| rnissl | but it might get misused, if one can create arbitrary files in that location | 11:51.08 |
| chrisl | which is why I'd only implement it with a solid, compelling reason | 11:51.55 |
| rnissl | for me there is no need at the moment | 11:52.35 |
| | I've just again gooled for PDFmail | 11:52.44 |
| | my PDFmail behaves like their 'Search & Send' functionality | 11:53.43 |
| | that's the reason for mailFilterText.ps | 11:54.39 |
| | and storing the extracted text for sending an email after conversion to pdf | 11:55.19 |
| | I've started that kind of ps processing around 1998 | 11:56.59 |
| | I remember emails to l peter deutsch -- didn't it found ghostscript? | 11:57.33 |
| | s/it/he/ | 11:57.45 |
| kens | Peter originally wrote Ghostscript | 12:19.34 |
| devios | Hi | 13:35.24 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 13:35.24 |
| devios | Are there any MuPDF developers out here? | 13:35.39 |
| kens | You would do better in the #mupdf channel | 13:35.51 |
| devios | Ok will try there | 13:36.05 |
| asd | a | 22:26.07 |
| | Forward 1 day (to 2017/10/11)>>> | |
Log of #ghostscript at irc.freenode.net.