Add a QML example

[chriadam]

Note: the QML API is still experimental and subject to change.

[chriadam]

It's clear that the QML API is very much still work-in-progress, as even a simple example like this required some additions to the QML plugin API. (I tried writing the example due to a question from community member, see https://github.com/sailfishos/sailfish-secrets/issues/57)

[szopin]

It's clear that the QML API is very much still work-in-progress, as even a simple example like this required some additions to the QML plugin API. (I tried writing the example due to a question from community member, see #57)

I know gh is probably not the best place to ask but seeing how in your example code you are using two weird tricks (buffer -> uint8array and weird reading char by char and then the weird trick qt.btoa(qt.atob(string))) for some workaround against qt <5.8) how do you pass a cutout from html page in webview to decryptrequest.data? I am getting 'Failed to encrypt.' (best I got is 'Unexpected reply signature: got "(iiis)ayi, expected "(iiis)ay(i)" zero results anywhere about this type of error) no matter how I pass the "ciphertext". No amount of cutting out trailing '='s and/or Qt.atob'ing works, I maybe have to cut out CR/LFs? The console.log of privkey and the ciphertext do work in online decrypters but they probably do some extra tricks, I just don't know, would be really grateful for a hint

[chriadam]

I'm not sure what you mean by "a cutout from a html page" or what the issue might be there. From the point of view of the sailfish-secrets classes, it is just dealing with arrays of bytes, so the source of the data should not matter - but perhaps I am misunderstanding.

But, regarding the got (iiis)ayi, expected "(iiis)ay(i) one, this sounds like a bug. The error is from QtDBus, it's saying it expected data of the form:

struct containing (integer, integer, integer, string), followed by
array of unsigned byte, followed by
struct containing (integer)

but it got:

struct containing (integer, integer, integer, string), followed by
array of unsigned byte, followed by
integer

Note the missing struct around the final integer.

I expect that this is for: QDBusPendingReply<Result, QByteArray, CryptoManager::VerificationStatus> from DecryptRequest.

Note that serialization.cpp has the following:

QDBusArgument &operator<<(QDBusArgument &argument, const CryptoManager::VerificationStatus verificationStatus)
{
    argument.beginStructure();
    argument << static_cast<int>(verificationStatus);
    argument.endStructure();
    return argument;
}

which should be correct. However, it also has the following:

QDataStream& operator<<(QDataStream& out, const CryptoManager::VerificationStatusType &v)
{
    quint32 temp = static_cast<quint32>(v);
    out << temp;
    return out;
}

I suspect the wrong one is chosen in some codepath, resulting in the error. Perhaps the way we define the serialization for the VerifiedDataResult in the daemon code is incorrect?

If you do manage to find and fix the issue, please create a PR.

[szopin]

Thanks, beginning to think it's an issue with Qt.atob, if I try to do a round trip atob->btoa I'm getting: Before atob'ing: SRiHemgtOE9q+WhHsQ/4YDKq7qQN8jjO4huOii7c3lU6vzPb2Y1HGufnfgcS z7ZupXxZiYH6uLyMgxYuXn+03PjjPBh/mQrN9/Uq3HE12u28kZfLYMrF2pJq VMCkCKqEjT4wONtRWYl4Bk2p/szuYyPVDhRrPwFpo/GDEZf4RYPxsc1Bd9ls Eb2HXDt32EwveVwmT8xpTH39GIy/B4/55Ot6/6jBTkFkfKu9RCz+Q1TKfo5i Vg/gmMQXu+xPehOYGRGywE6htINyzf+esXvY3jC9S6al8ZOH3GzqGaWXRHZ0 C4DQhZ3Hvt31K2Jz0fF0WHaQPynFhzujhY6CTpTZTw== After atob/btoa: SRjvv716aC04T2rvv71oR++/vQ/vv71gMu+/ve+/ve+/vQ3vv70477+977+9G++/ve +/vS7vv73vv71VOu+/vTPvv73ZjUca77+977+9fgcSz7Zu77+9fFnvv73vv73vv73vv73vv73vv73vv 70WLl5/77+977+977+977+9PBh/77+9Cu+/ve+/ve+/vSrvv71xNe+/ve+/ve+/ve+/ve+/ve+/vWDv v73vv73akmpU77+977+9CO+/ve+/ve+/vT4wOO+/vVFZ77+9eAZN77+977+977+977+9YyPvv70OFGs /AWnvv73vv73vv70R77+977+9Re+/ve+/ve+/ve+/vUF377+9bBHvv73vv71cO3fvv71ML3lcJk/vv7 1pTH3vv70Y77+977+9B++/ve+/ve+/ve+/vXrvv73vv73vv71OQWR877+977+9RCzvv71DVO+/vX7vv 71iVg/vv73vv73vv70X77+977+9T3oT77+9GRHvv73vv71O77+977+977+9cu+/ve+/ve+/ve+/vXvv v73vv70w77+9S++/ve+/ve+/ve+/ve+/ve+/vWzvv70Z77+977+9RHZ0C++/vdCF77+9x77vv73vv70 rYnPvv73vv710WHbvv70/KcWHO++/ve+/ve+/ve+/vU7vv73vv71P I would expect them to look the same

On Monday, 8 November 2021, Chris Adams wrote:

I'm not sure what you mean by "a cutout from a html page" or what the issue might be there. From the point of view of the sailfish-secrets classes, it is just dealing with arrays of bytes, so the source of the data should not matter - but perhaps I am misunderstanding.

But, regarding the got (iiis)ayi, expected "(iiis)ay(i) one, this sounds like a bug. The error is from QtDBus, it's saying it expected data of the form:

struct containing (integer, integer, integer, string), followed by
array of unsigned byte, followed by
struct containing (integer)

but it got:

struct containing (integer, integer, integer, string), followed by
array of unsigned byte, followed by
integer

Note the missing struct around the final integer.

I expect that this is for: QDBusPendingReply<Result, QByteArray, CryptoManager::VerificationStatus> from DecryptRequest.

Note that serialization.cpp has the following:

QDBusArgument &operator<<(QDBusArgument &argument, const CryptoManager::VerificationStatus verificationStatus)
{
    argument.beginStructure();
    argument << static_cast<int>(verificationStatus);
    argument.endStructure();
    return argument;
}

which should be correct. However, it also has the following:

QDataStream& operator<<(QDataStream& out, const CryptoManager::VerificationStatusType &v)
{
    quint32 temp = static_cast<quint32>(v);
    out << temp;
    return out;
}

I suspect the wrong one is chosen in some codepath, resulting in the error. Perhaps the way we define the serialization for the VerifiedDataResult in the daemon code is incorrect?

If you do manage to find and fix the issue, please create a PR.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/sailfishos/sailfish-secrets/pull/173#issuecomment-96274654

-- Sent from my Jolla

[szopin]

Ok, finally managed to get it working using functions from solution 2 here: https://developer.mozilla.org/en-US/docs/Glossary/Base64#appendix_decode_a_base64_string_to_uint8array_or_arraybuffer Thank you for all the help!

On Monday, 8 November 2021, Chris Adams wrote:

I'm not sure what you mean by "a cutout from a html page" or what the issue might be there. From the point of view of the sailfish-secrets classes, it is just dealing with arrays of bytes, so the source of the data should not matter - but perhaps I am misunderstanding.

But, regarding the got (iiis)ayi, expected "(iiis)ay(i) one, this sounds like a bug. The error is from QtDBus, it's saying it expected data of the form:

struct containing (integer, integer, integer, string), followed by
array of unsigned byte, followed by
struct containing (integer)

but it got:

struct containing (integer, integer, integer, string), followed by
array of unsigned byte, followed by
integer

Note the missing struct around the final integer.

I expect that this is for: QDBusPendingReply<Result, QByteArray, CryptoManager::VerificationStatus> from DecryptRequest.

Note that serialization.cpp has the following:

QDBusArgument &operator<<(QDBusArgument &argument, const CryptoManager::VerificationStatus verificationStatus)
{
    argument.beginStructure();
    argument << static_cast<int>(verificationStatus);
    argument.endStructure();
    return argument;
}

which should be correct. However, it also has the following:

QDataStream& operator<<(QDataStream& out, const CryptoManager::VerificationStatusType &v)
{
    quint32 temp = static_cast<quint32>(v);
    out << temp;
    return out;
}

I suspect the wrong one is chosen in some codepath, resulting in the error. Perhaps the way we define the serialization for the VerifiedDataResult in the daemon code is incorrect?

If you do manage to find and fix the issue, please create a PR.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/sailfishos/sailfish-secrets/pull/173#issuecomment-96274654

-- Sent from my Jolla

[chriadam]

Yikes, interesting! Thank you for mentioning this, clearly the Qt methods aren't properly round-trip stable! I should update the example to use the methods you found instead...

[chriadam]

Yikes, interesting! Thank you for mentioning this, clearly the Qt methods aren't properly round-trip stable! I should update the example to use the methods you found instead...

The issue is that the Qt methods don't specify the appropriate Base64Options (QByteArray::KeepTrailingEquals and QByteArray::Base64UrlEncoding) so they are not round trip stable when dealing with URL encoded data, it seems. I've added some helper methods to the QML manager types to avoid this problem (and added another helper to directly convert a QByteArray to a QString, and used that one directly in the test).

[chriadam]

Merging this one, I think having the example is useful. The QML API isn't stable anyway, and the changes I made to that were additions.

[szopin]

I guess in 4.3.1 or 4.4 will be able to replace those ugly js functions with secretmanager ones (tobase64 and from), awesome, thanks again!

On Wednesday, 10 November 2021, Chris Adams wrote:

Yikes, interesting! Thank you for mentioning this, clearly the Qt methods aren't properly round-trip stable! I should update the example to use the methods you found instead...

The issue is that the Qt methods don't specify the appropriate Base64Options (QByteArray::KeepTrailingEquals and QByteArray::Base64UrlEncoding) so they are not round trip stable when dealing with URL encoded data, it seems. I've added some helper methods to the QML manager types to avoid this problem (and added another helper to directly convert a QByteArray to a QString, and used that one directly in the test).

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/sailfishos/sailfish-secrets/pull/173#issuecomment-96488715

-- Sent from my Jolla

[chriadam]

It will be 4.4 I think. Thank you for your investigations also, and for prompting me to add the examples.