Crashes are already happening which means obviously I'm doing
something wrong. But what options do I have? Do I have it at all?
чт, 5 сент. 2019 г. в 09:37, Elvis Stansvik <elvst...@gmail.com>:
>
> Den tors 5 sep. 2019 01:22Alexander Ivash <elder...@gmail.com> skrev:
>>
>> Thank you for fast response, but my question is purely about QML. On
>> C++ side I have a lot of ways for nullifying / erasing sensitive
>> information *after* it is not needed (let say after particular QML
>> screen gets' closed). But on QML / JS side I have no any control at
>> all. Would be great if one of QML guys could step in and comment too.
>>
>> Here is the small example illustrating my issue (all I need is to make
>> 'Piter Pen' to disappear from memory dumps):
>>
>> <main.qml>
>>
>> import QtQuick 2.12
>> import QtQuick.Window 2.12
>>
>> Window {
>> visible: true
>> width: 640
>> height: 480
>> title: qsTr("Hello World")
>>
>> Component.onCompleted: {
>> var test = "Piter Pen";
>>
>> // uncommenting results in a crash
>> // backend.cleanup(test);
>>
>> // doesnt' nullify "Piter Pen"
>> // gc();
>>
>> // doesn't work either
>> /*
>> Qt.callLater(() => {
>> gc();
>> })
>> */
>> }
>> }
>>
>> <main.cpp>
>>
>> #include <QGuiApplication>
>> #include <QQmlContext>
>> #include <QQmlApplicationEngine>
>> #include <random>
>> #include <chrono>
>> #include <QString>
>> #include <QByteArray>
>> #include <QDebug>
>>
>> class Backend : public QObject
>> {
>> Q_OBJECT
>> public:
>> explicit Backend(QObject *parent = nullptr) {
>> QString str1 = "Piter Pen";
>> QString str2 = str1;
>> QString str3 = str2;
>>
>> qDebug() << "str1:" << str1;
>> qDebug() << "str2:" << str2;
>> qDebug() << "str3:" << str3;
>>
>> cleanup(str1);
>>
>> qDebug() << "str1:" << str1;
>> qDebug() << "str2:" << str2;
>> qDebug() << "str3:" << str3;
>> }
>>
>> Q_INVOKABLE void cleanup(const QString& str) {
>> std::mt19937
>> eng(std::chrono::system_clock::now().time_since_epoch().count());
>> std::uniform_int_distribution<ushort> distribution;
>>
>> QChar* data = const_cast<QChar*> (str.constData());
>>
>> for(int i = 0; i < str.length(); ++i) {
>> data[i] = distribution(eng);
>> }
>
>
> Just a word of caution: Even if you had not gotten a crash, like Thiago said
> you need to be very careful here: A smart compiler could possibly decide that
> since the memory pointed to by data is not used after this, it can optimize
> this entire loop of yours away.
>
> Not saying that's going to happen, but you need to be very careful. I think
> there are platform specific memory-zeroing functions that could be used that
> are written with that in mind. At least I know OpenBSD has something like
> that.
>
>> }
>> };
>>
>> int main(int argc, char *argv[])
>> {
>> QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
>>
>> QGuiApplication app(argc, argv);
>>
>> Backend backend;
>> QQmlApplicationEngine engine;
>> const QUrl url(QStringLiteral("qrc:/main.qml"));
>> QObject::connect(&engine, &QQmlApplicationEngine::objectCreated,
>> &app, [url](QObject *obj, const QUrl &objUrl) {
>> if (!obj && url == objUrl)
>> QCoreApplication::exit(-1);
>> }, Qt::QueuedConnection);
>> engine.rootContext()->setContextProperty("backend", &backend);
>> engine.load(url);
>>
>> return app.exec();
>> }
>>
>> #include "main.moc"
>>
>> чт, 5 сент. 2019 г. в 01:32, Thiago Macieira <thiago.macie...@intel.com>:
>> >
>> > On Wednesday, 4 September 2019 14:46:09 PDT Alexander Ivash wrote:
>> > > Is there any mechanism for cleanup sensitive data like passwords etc
>> > > from QML? This issue is that gc() doesn't seem to even nullify memory
>> > > (at least in release on Windows) so all the sensitive information
>> > > stays in memory.
>> >
>> > Write in C++ and manage your memory VERY carefully. Remember that memset()
>> > before free / delete or going out of scope is removed by the compiler.
>> >
>> > Don't use new or malloc. Instead, mmap() your chunk of memory yourself and
>> > mlock() it properly.
>> >
>> > Of course, to display such information you need to accept that it is no
>> > longer
>> > secure. It'll go to QML, then to the text engines, then the pixels will be
>> > transferred to the display server or the GPU, etc.
>> > --
>> > Thiago Macieira - thiago.macieira (AT) intel.com
>> > Software Architect - Intel System Software Products
>> >
>> >
>> >
>> > _______________________________________________
>> > Interest mailing list
>> > Interest@qt-project.org
>> > https://lists.qt-project.org/listinfo/interest
>> _______________________________________________
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
