> On Nov 15, 2016, at 9:24 AM, Sébastien de Menten <sdemen...@gmail.com> wrote: > > On Tue, Nov 15, 2016 at 4:17 PM, John Ralls <jra...@ceridwen.us> wrote: > > Sébastien, > > That's a bit more "external" than I had in mind. The plug/connect any process > part is a serious security issue. > > I don't understand the point of the json file. Users will want the report to > display and then to be able to open the report options dialog to make changes > like selecting a date range or modifying the accounts reported on, and expect > the report to regenerate when they click "Apply". ISTM to accomplish that the > report module needs to be in control and to pass to the Python report-builder > the options parameters. The second thing that won't work is using PyCash: The > user wants a report on what her book looks like in memory, not what it looked > like the last time she saved, so the report will need to use the python > bindings and connect to the current session. > > It looks to me from the Makefile.am that building guile-json requires > Guile-2.0, which you won't have if you're using the Guile in the GnuCash > Windows installation. You could try to simply copy the four .scm files into > share/guile/1.8/ and see if it works. It will only if the author didn't use > any Guile-2-only features. > > Regards, > John Ralls > > > On the security risk, it is no different than running the same process > outside GnuCash (in a terminal for instance), or is it ? > The json file is there to be able to specify the options for a report in a > better way than writing Scheme in an scm file. Currently, for a given python > report (report_test.py), I generate the Scheme code wrapping this python > report (report_test.scm) with: > - the proper Scheme code for the options defined in report_test.py > - the proper Scheme code to call the python process (ie "python > report_test.py") > Instead of having to generate scheme code, it would be better to have a json > file per report (report_test.json) that could be used to instantiate the > report in GnuCash. > > For piecash, there is no specific issue as the change in the book are > immediately serialised to the SQL backend. However, for the xml backend (that > piecash does not support anyway), the GnuCash file should be saved before. > But nothing forbids someone to use the official python bindings to connect to > the current session and do as you describe. However, how the python bindings > know to which session to connect if there are multiple files opened at the > same time ? and can they open a session in a separate process while GnuCash > has a lock on the file ? >
Sébastien, A process running outside GnuCash isn't pushing data into a running instance of GnuCash, so yes, it's significantly different. The ancient libwebkit we use has tons of known vulnerabilities that could be exploited by injecting malicious HTML or JavaScript. Maybe I misunderstand how the json file would work. Would it just initialize the options which can then be edited in the report's options dialog, or are the options in the json file the ones that the report gets and the user must edit the json file in order to change them? Does PyCash ignore the lock table in the database, then? To connect to the current session I think one would need to use the Python connection in src/python or the Scheme interpreter. No external process is going to be able to get at the running GnuCash instance's memory. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
