Conversation
The C crypto module stores the cipher key as a raw pointer without copying it. If the std::string passed to aes_cbc()/legacy() went out of scope, the C module was left with a dangling pointer, causing decryption failures. Fix by having crypto_module own a heap-allocated copy of the key via std::shared_ptr<std::string>, and transferring that ownership to the pubnub::context through a new virtual cipher_key() method on the into_crypto_provider_ptr interface. Made-with: Cursor
Same fix as the C++ wrapper, but using Qt-idiomatic types: QSharedPointer<QByteArray> instead of std::shared_ptr<std::string>. The original Qt code had an even more severe bug where cipher_key.toStdString().c_str() created an immediately dangling pointer from a temporary. Made-with: Cursor
|
I'm not sure is it still relevant for us to support C++ 98? Some concepts like |
Good catch. I forgot about the compatibility of other versions but the Crypto module itself is no longer C++98 compatible. Should I make it compatible again? |
|
@Xavrax Do we actually need C++98 support? Event C99 currently exists mostly to support older toolchains for IoT devices but they already don't need it and can normally operate with latest standards. |
3 participants
feat: Allow users to select if they want to cache or consume the value of the cypher key depending on their crypto module implementation
Allow users to select if they want to cache or consume the value of the cypher key depending on their crypto module implementation