Merge branch 'google:master' into fix_207

Author: wyqlxf

README.md

@@ -1,4 +1,4 @@
-Cross-Platform Web Cryptography Implemenation
+Cross-Platform Web Cryptography Implementation
 =============================================
 This package provides a cross-platform implementation of the
 [Web Cryptograph API][webcrypto-spec].

doc/design-rationale.md

@@ -24,7 +24,7 @@ cryptography implementation. This option comes with significant draw backs:
  * Custom implementations of cryptographic algorithms requires domain experts
    and extensive security reviews.
  * A Javascript implementation is unlikely to achieve performance comparable to
-   the native crytography algorithms shipped with the browser.
+   the native cryptography algorithms shipped with the browser.
  * A Javascript implementation would need to use WebWorker to off-load
    computation from the main-thread, while the browsers native implementation
    can do this for free.
@@ -38,7 +38,7 @@ for golang, this package will not provide low-level access to underlying
 primitives. However, most Dart developers are also unlikely to need such
 advanced features for using a modern Web API.
 
-Crytography is not simple, and should not be simplfied
+Cryptography is not simple, and should not be simplified
 ------------------------------------------------------
 This isn't entirely true of course, cryptography isn't so hard _if_ you know
 what you're doing. If you don't know what you're doing, then you shouldn't be
@@ -74,7 +74,7 @@ This does not follow `package:crypto` by implementing `Converter<S,T>`
 because `convert()` cannot be asynchronous as required by WebCrypto.
 
 Besides users (hint Flutter) would likely prefer to avoid heavy computations
-like crypto on the main-thread. Even if an initial implemention doesn't move
+like crypto on the main-thread. Even if an initial implementation doesn't move
 computation off-the-mainthread, it would be preferable to keep the option open
 by returning futures.
 

doc/webcrypto-parity.md

@@ -33,7 +33,7 @@ developers to harden their applications against accidental misuse of keys.
 
 If we wanted to support this feature we would introduce a `KeyUsages` enum, and
 allow all key import and generation methods to accept a set of usages, as well
-as an `extractable` bit. Various key opertions would then throw
+as an `extractable` bit. Various key operations would then throw
 `UnsupportedError` if the key capabilities is violated.
 
 This is not an unreasonable API design. However, this feature can also be
@@ -102,7 +102,7 @@ This also equivalent to decrypting the key and then importing the key.
 
 Similar to `deriveKey` this is useful when limiting a key to specific usages to
 prevent a key from accidentally being misused. If we wanted to support this
-feature we would also be introducing intermediate objets similar to the design
+feature we would also be introducing intermediate objects similar to the design
 outlined for `deriveKey`. Instead these would be `WrapKeyOptions` and
 `UnwrapKeyOptions<T>`, and keys that can be wrapped would have methods for
 creating these options with different encapsulated key-formats.

lib/src/impl_ffi/impl_ffi.rsa_common.dart

@@ -115,7 +115,7 @@ _EvpPKey _importJwkRsaPrivateOrPublicKey(
       checkJwk(jwk.d != null, 'd');
       final d = readBN(jwk.d!, 'd');
       // If present properties p,q,dp,dq,qi enable optional optimizations, see:
-      // https://tools.ietf.org/html/rfc7518#section-6.3.2
+      // https://www.rfc-editor.org/rfc/rfc7518#section-6.3.2
       // However, these are required by Chromes Web Crypto implementation:
       // https://chromium.googlesource.com/chromium/src/+/43d62c50b705f88c67b14539e91fd8fd017f70c4/components/webcrypto/algorithms/rsa.cc#82
       // They are also required by Web Crypto implementation in Firefox:
@@ -202,7 +202,7 @@ Map<String, dynamic> _exportJwkRsaPrivateOrPublicKey(
     ssl.RSA_get0_key(rsa, ffi.nullptr, ffi.nullptr, d);
 
     // p, q, dp, dq, qi is optional in:
-    // // https://tools.ietf.org/html/rfc7518#section-6.3.2
+    // // https://www.rfc-editor.org/rfc/rfc7518#section-6.3.2
     // but explicitly required when exporting in Web Crypto.
     final p = scope<ffi.Pointer<BIGNUM>>();
     final q = scope<ffi.Pointer<BIGNUM>>();

lib/src/impl_ffi/impl_ffi.utils.dart

@@ -489,7 +489,7 @@ int _numBitsToBytes(int numberOfBits) =>
     (numberOfBits ~/ 8) + ((7 + (numberOfBits % 8)) ~/ 8);
 
 /// Decode url-safe base64 witout padding as specified in
-/// [RFC 7515 Section 2](https://tools.ietf.org/html/rfc7515#section-2)
+/// [RFC 7515 Section 2](https://www.rfc-editor.org/rfc/rfc7515#section-2)
 ///
 /// Throw [FormatException] mentioning JWK property [prop] on failure.
 Uint8List _jwkDecodeBase64UrlNoPadding(String unpadded, String prop) {
@@ -508,7 +508,7 @@ Uint8List _jwkDecodeBase64UrlNoPadding(String unpadded, String prop) {
 }
 
 /// Encode url-safe base64 witout padding as specified in
-/// [RFC 7515 Section 2](https://tools.ietf.org/html/rfc7515#section-2)
+/// [RFC 7515 Section 2](https://www.rfc-editor.org/rfc/rfc7515#section-2)
 String _jwkEncodeBase64UrlNoPadding(List<int> data) {
   final padded = base64Url.encode(data);
   final i = padded.indexOf('=');

lib/src/jsonwebkey.dart

@@ -216,7 +216,7 @@ final class JsonWebKey {
 /// See also "oth" in [RFC 7518 Section 6.3.2.7].
 ///
 /// [1]: https://www.w3.org/TR/WebCryptoAPI/#JsonWebKey-dictionary
-/// [2]: https://tools.ietf.org/html/rfc7518#section-6.3.2.7
+/// [2]: https://www.rfc-editor.org/rfc/rfc7518#section-6.3.2.7
 final class RsaOtherPrimesInfo {
   String r;
   String d;

lib/src/testing/webcrypto/rsapss.dart

@@ -125,7 +125,7 @@ final _testData = [
   /// [2]: https://opensource.apple.com/source/CommonCrypto/CommonCrypto-60165.120.1/lib/CommonRSACryptor.c.auto.html
   /// [3]: https://opensource.apple.com/source/xnu/xnu-4570.41.2/EXTERNAL_HEADERS/corecrypto/ccrsa.h.auto.html
   /// [4]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
-  /// [5]: https://tools.ietf.org/html/rfc3447
+  /// [5]: https://www.rfc-editor.org/rfc/rfc3447
   /// [6]: https://tools.ietf.org/html/rfc3447#section-9.1
   /// [7]: https://bugs.webkit.org/show_bug.cgi?id=216750
   ...(nullOnSafari(_testDataWithLongSaltLength) ?? <Map>[]),

src/symbols.yaml

@@ -24,7 +24,7 @@
 # or OpenSSL that might be linked into the final application, because we only
 # expose the `webcrypto_lookup_symbol` symbol.
 #
-# On most platforms, like Android, the the BoringSSL sources and `webcrypto.c`
+# On most platforms, like Android, the BoringSSL sources and `webcrypto.c`
 # is compiled to a dynamic library `webcrypto.so`, in this case symbol conflicts
 # is unlikely (if loaded correctly).
 #