firefox-main/dom/crypto
Name Description Size Coverage
CryptoBuffer.cpp 4364 0 %
CryptoBuffer.h 1655 -
CryptoKey.cpp 48373 0 %
CryptoKey.h The internal structure of keys is dictated by the need for cloning. We store everything besides the key data itself in a 32-bit bitmask, with the following structure (byte-aligned for simplicity, in order from least to most significant): Bits Usage 0 Extractable 1-7 [reserved] 8-15 KeyType 16-27 KeyUsage 28-31 [reserved] In the order of a hex value for a uint32_t 3 2 1 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~~~~~~~| Usage | Type |~~~~~~~~~~~~~|E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thus, internally, a key has the following fields: uint32_t - flags for extractable, usage, type KeyAlgorithm - the algorithm (which must serialize/deserialize itself) The actual keys (which the CryptoKey must serialize) 7563 100 %
KeyAlgorithmProxy.cpp 8588 0 %
KeyAlgorithmProxy.h 3965 96 %
moz.build 819 -
test -
WebCryptoCommon.h 14487 92 %
WebCryptoTask.cpp 136144 0 %
WebCryptoTask.h The execution of a WebCryptoTask happens in several phases 1. Constructor 2. BeforeCrypto 3. CalculateResult -> DoCrypto 4. AfterCrypto 5. Resolve or FailWithError 6. Cleanup If any of these steps produces an error (setting mEarlyRv), then subsequent steps will not proceed. If the constructor or BeforeCrypto sets mEarlyComplete to true, then we will skip step 3, saving the thread overhead. In general, the constructor should handle any parsing steps that require JS context, and otherwise just cache information for later steps to use. All steps besides step 3 occur on the main thread, so they should avoid blocking operations. Only step 3 is guarded to ensure that NSS has not been shutdown, so all NSS interactions should occur in DoCrypto Cleanup should execute regardless of what else happens. 8448 85 %