Open mjmacleod opened 4 years ago
VectorSource and/or VectorSink cannot compile when passed a vector that takes a custom allocator. In my case I have a codebase that uses a secure allocator for all sensitive information...
In your use case, you should probably use a SecBlock<MyType>
. The SecBlock<T>
class uses a secure allocator and provides the cleanup.
I'm not really sure there is much to gain on my side from switching to SecBlock
it behaves essentially the same as the codebases existing securely allocated vector/string classes and would only serve to make the codebase more tightly coupled to cryptopp instead if the dependency being smaller. The codebases securely allocated classes are also used in various other places that otherwise have absolutely no relation to cryptopp... However I will think about it some more, thanks.
That aside, I still think it would be ideal (and a very small change) to modify VectorSource
/VectorSink
to alllow for custom allocators.
VectorSource and/or VectorSink cannot compile when passed a vector that takes a custom allocator. In my case I have a codebase that uses a secure allocator for all sensitive information and have to re-implement parts of the cryptopp codebase due to VectorSource/VectorSink not taking an allocator.
VectorSink is just a typedef so this is easily worked around in user code by just using
CryptoPP::StringSinkTemplate<MyType>
VectorSource is an actual class (though quite a simple one) so has to be 'duplicated' into my codebase e.g.:
This is not ideal, because I then have to check that this doesn't break for every library upgrade. It would be preferable if VectorSource were just templated inside cryptopp itself such that it can take any allocator. It would also be nice (but not as important) if VectorSink could do the same.