[GCrypt] Add a Handle<> class to help with GCrypt object lifetime control
authorzandobersek@gmail.com <zandobersek@gmail.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 29 Mar 2017 18:44:57 +0000 (18:44 +0000)
committerzandobersek@gmail.com <zandobersek@gmail.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 29 Mar 2017 18:44:57 +0000 (18:44 +0000)
commit69b6d96402ad54b4cb91b9069a95f2510f9223ef
tree417628e1b3523de8cc5cd0ff23d428ad743b1ea0
parent2eb7f0abe47be7c81c62a821b37a8ebfd57c9757
[GCrypt] Add a Handle<> class to help with GCrypt object lifetime control
https://bugs.webkit.org/show_bug.cgi?id=170238

Reviewed by Michael Catanzaro.

Source/WebCore:

The platform-specific CryptoAlgorithmHMAC implementation is modified
to showcase the GCrypt::Handle<> use. HandleDeleter<gcry_mac_hd_t>
is added accordingly.

* crypto/gcrypt/CryptoAlgorithmHMACGCrypt.cpp:
(WebCore::calculateSignature):

Source/WebCore/PAL:

Add a GCrypt-specific Handle<> template class, inside the GCrypt namespace.
Objects of this class should be used as 'smart handles', cleaning up upon
destruction the GCrypt object that's represented by the handle they manage.

This mimics the std::unique_ptr<> idea, but is narrowly focused towards
how such handles are used in the libgcrypt API. A GCrypt::Handle<> object
can be consturcted from an existing handle or with the default null value.
It can be cleared upon request via clear(), and the managed handle can be
released via release().

The address of the managed handle can be retrieved through the address-of
operator. An implicit conversion operator is also added. This allows
frictionless use of GCrypt::Handle<> objects with existing libgcrypt APIs.

The negation operator is implemented to support testing the nullness of
the managed handle. The raw handle value is also retrieveable through
the handle() method.

The copy and move constructors and assignment operators are deleted.
They are not at the moment required anywhere in the work-in-progress
implementation of subtle crypto functionality.

As with other resource management classes, upon destruction, the
GCrypt::Handle<> object destroys the resource it manages. This is done
through objects of the HandleDeleter<> template class. Specializations
of this class have to implement the call operator that properly
releases the resource. Because the operator is deleted by default,
a compilation error will be thrown when deleting a resource of some
type for which the proper HandleDeleter specialization isn't provided.

std::unique_ptr<> could be used, but it could also be mis-used. I find
a mini-class with an interface that's specific to libgcrypt API
interactions to be preferrable to a std::unique_ptr<> with a custom
deleter.

* pal/crypto/gcrypt/Handle.h: Added.
(PAL::GCrypt::Handle::Handle):
(PAL::GCrypt::Handle::~Handle):
(PAL::GCrypt::Handle::clear):
(PAL::GCrypt::Handle::release):
(PAL::GCrypt::Handle::operator&):
(PAL::GCrypt::Handle::handle):
(PAL::GCrypt::Handle::operator T):
(PAL::GCrypt::Handle::operator!):
(PAL::GCrypt::HandleDeleter<gcry_mac_hd_t>::operator()):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214550 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore/ChangeLog
Source/WebCore/PAL/ChangeLog
Source/WebCore/PAL/pal/crypto/gcrypt/Handle.h [new file with mode: 0644]
Source/WebCore/crypto/gcrypt/CryptoAlgorithmHMACGCrypt.cpp