report in python, a first version
jralls at ceridwen.us
Wed Nov 16 20:57:27 EST 2016
> On Nov 16, 2016, at 2:19 PM, Sébastien de Menten <sdementen at gmail.com> wrote:
> Still hoping *complexity* is not considered a feature ;-)
> > It's the html string that I'm particularly worried about, because that gets you to a well-known library with lots of well-known and well-documented vulnerabilities  and it's well-known that we we use an obsolete version. That's a very easy and tempting target.
> Am I wrong or any guile report is already able to send explicitly any html string ? Isn't this vulnerability already there today ? The fact that the html string is generated by guile in scheme or by guile after having called an external process doesn't make a difference to me ... or I am missing the elephant in the room ?
> > I'm utterly agnostic about what format the report-config file is, but since Guile already knows how to read XML  and the fewer dependencies the better, I'd lean towards that.
> Indeed, I had no success in using guile json but am no guile expert.
> > Yes, having a Guile interpreter is also a security hole, though less well known and with a much smaller attack surface than WebKit. I'll be very happy indeed when it's no longer central to GnuCash.
> As written, the vulnerabilities are both in guile (as it can execute any command in your system) and in the report approach that will accept any html string (and use a webkit vulnerability)
Not a feature necessarily, but in many cases reasonable because GnuCash addresses a complex set of problems and strives to make them easier for the user to deal with. Avoiding that complexity because it's "too hard" just creates a simplistic solution that doesn't blend with the rest of the program and fails to address the user's needs.
I don't know if it's an elephant, but regardless of the vulnerabilities already present in GnuCash you're proposing to open another one.
More information about the gnucash-devel