[Interest] QML and sensitive data

[Alexander Ivash]

Right, the whole approach is not something I'm really proud of. And of
course it has its limitations, but:

>> The string may get copied internally in many places

Under what conditions? I mentioned that Quick Controls 2 is a must to
make behaviour more deterministic. Unless I'm missing something just a
brief look list of public properties for each quick control used
should be enough to capture all the QString-s (including internal).

>> Bindings may be evaluated as JavaScript, necessitating a JavaScript string representation.

This sounds even more scaring. Under what conditions binding like 'a:
backend.b' (where 'a' is a QString of Quick Control 2, and 'b' is
QString C++ backend) may be evaluated as JavaScript?

>>  The visual representation of the string may be generated at some point, passing the string through layers of rendering code

For example?

>> The string has to be assembled from input somehow, potentially by re-allocating and expanding a buffer as you type.

I've been thinking about it too. Although haven't verify yet, the
solution could be in exposing QString with *just enough* buffer to
QML.

>> And obviously const_cast'ing and nullifying a string is not thread safe.

Could you please elaborate? The place where I'm doing this cleanup is
'Component.onDestruction'. Any rendering should be ceased by this
time, no? Moreover, even if it would be different place, I feel it
weird for renderer to query QML properties constantly in a loop. I
really hope it is implemented in a way that it rather listens for
changes from QML (which I never send because string gets touched only
internally and even if I would be willing to send it - it would be
done after updating shared QString's buffer, not during update!) than
polls it.

вт, 10 сент. 2019 г. в 09:54, Ulf Hermann <ulf.hermann at qt.io>:
>
> Hi,
>
> > Just in case if someone will be looking for solution - I've managed to
> > eliminate all the sensitive data from memory on closing particular QML
> > screen without sacrificing existing architecture. The secret is pretty
> > simple: just avoid situations when QString-s gets copied into JS
> > strings:
> >
> > 1. Do not use QJsonArray as the model for QML, use QVariantList as the
> > replacement instead. At least because QVariantList of QVariants of
> > QStrings allows an access to QString if required.
> > 2. Use Quick Controls 2 because they are implemented in C++ and thus
> > doesn't result in creation of JS strings
> > 3. On destruction of Quick Controls pass properties like 'text',
> > 'displayText' etc to C++ where const_cast and nullify
> > implicitly-shared buffer.
> > Bonus: QJsonDocument provides nice 'rawData' function allowing to
> > cleanup its internals if required.
>
> I can _not_ recommend this approach. The string may get copied
> internally in many places. Bindings may be evaluated as JavaScript,
> necessitating a JavaScript string representation. The visual
> representation of the string may be generated at some point, passing the
> string through layers of rendering code. The string has to be assembled
> from input somehow, potentially by re-allocating and expanding a buffer
> as you type. The old buffer will not be erased, and the input events may
> be allocated and deleted on the heap, without erasing them before
> deletion. You can _not_ be sure that the string is completely erased
> from memory after theses steps.
>
> And obviously const_cast'ing and nullifying a string is not thread safe.
> If you are running a threaded render loop, for example, you may just
> have created a race condition.
>
> regards,
> Ulf
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest