[Interest] QML preprocessing
elderorb at gmail.com
Wed Apr 24 20:51:30 CEST 2019
The issue is that even if that function will be doing nothing, logging
data (which might be sensitive) can be captured via hooks / dump
analysis etc. I really need to pre-processes to eliminate not only
function call but also function parameters completely. Think about
In this case even if console.debug will be replaced with empty
will be executed anyway and as the result password will appear
somewhere in JS heap so after capturing dump it will be simpler to
In fact I would love to use logging category, but only for debug
builds. But I have some requirements to minimize risk of sensitive
data leak via logging. And to make a life of reverse engineers a bit
more complicated if you like. So ideally no logging-related functions
(and their parameters too!) should be visible in release build.
ср, 24 апр. 2019 г. в 21:27, Jérôme Godbout <godboutj at amotus.ca>:
> Maybe you can overload the functor directly into the code and import the file only if in debug mode (optional module):
> That could also be helpful to split the log into multiple receiver.
> -----Original Message-----
> From: Interest <interest-bounces at qt-project.org> On Behalf Of Alexander Ivash
> Sent: April 24, 2019 12:56 PM
> To: interestqt-project.org <interest at qt-project.org>
> Subject: [Interest] QML preprocessing
> I understand that this topic was raised a lot of times and that this is not QML-way. But, what options do I have in case of requirements to eliminate all the logging for release builds?
> Is there any hidden magic in qmake, like 'QMAKE_SUBSTITUTES' but more flexible to substitute all the 'console.debug....' with '// console.debug' right before adding qml into resources?
> p.s. Yea, I'm aware of selectors, but would like to avoid having both component-with-logging.qml and component-with-no-logging.qml
> Regards, Alexander
> Interest mailing list
> Interest at qt-project.org
More information about the Interest