aws / aws-sdk-js-crypto-helpers Goto Github PK

There's no build script in the root package.json of this repo, so it took some experimentation to figure out how to actually build. I'm still not sure I got the build steps right.

What's the sequence of commands that people who want to create PRs should use to build this project locally?

We're switching from preview to alpha versions for @aws-sdk/* packages
Tracking issue: aws/aws-sdk-js-v3#675

@aws-crypto can also:

• Switch channel for @aws-sdk/* dependencies from preview to alpha for example:
  

  aws-sdk-js-crypto-helpers/packages/crc32/package.json

  Line 25 in 30a3a34

  "@aws-sdk/util-utf8-universal": "^0.1.0-preview.1",

• [Optional] switch @aws-crypto/* to alpha channel once we release @aws-sdk/* in alpha

I've been watching releases of @aws-crypto/* packages as seen in the screenshot below:

However, I don't get notified of the new releases as releases happen per package.
Link: https://github.com/aws/aws-sdk-js-crypto-helpers/releases

Suggestion: Create a global GitHub release like one done by @aws-sdk/*
Example release v1.0.0-alpha.18 https://github.com/aws/aws-sdk-js-v3/releases/tag/v1.0.0-alpha.18

Is your feature request related to a problem? Please describe.

Not a problem, but FYI that support for Internet Explorer and Node.js 12.x can be dropped

The support is already dropped by AWS SDK for JavaScript as follows:

• Internet Explorer:
  • May 2022: Announcing the end of support for Internet Explorer 11 in the AWS SDK for JavaScript (v3)
  • Oct 2022: aws/aws-sdk-js-v3#4006
• Node.js 12.x:
  • May 2022: Announcing the end of support for Node.js 12.x in the AWS SDK for JavaScript (v3)
  • Nov 2022: aws/aws-sdk-js-v3#4123

Describe the solution you'd like

Drop support for Node.js 12.x and Internet Explorer:

• Testing can be removed from Node.js 12

  aws-sdk-js-crypto-helpers/.github/workflows/ci-unit-tests.yaml

  Line 16 in dc83f76

  - 12

• And engines field can be added in package.json to support only Node.js 14.x+
  • Example: https://github.com/aws/aws-sdk-js-v3/blob/d3ccee7cbe3a0cda64af32aff5a1485e3941daf9/clients/client-s3/package.json#L96-L98
• Code specific to IE11 can be removed.
  • Example:

    aws-sdk-js-crypto-helpers/packages/sha1-browser/src/crossPlatformSha1.ts

    Lines 14 to 16 in 45c50ff

    	} else if (isMsWindow(locateWindow())) {
    	this.hash = new Ie11Sha1(secret);
    	} else {

Describe alternatives you've considered

Continue supporting Node.js 12.x and Internet Explorer

All the subpackages here has a name of @aws/xxx but the published packages' org name is @aws-sdk.

BTW: Can you all add github repository link to your package.json? It will be helpful to find the repo from NPM package page.

Is your feature request related to a problem? Please describe.

The @aws-sdk/util-utf8-browser packages are deprecated in v3, as the code is merged in a new package @aws-sdk/util-utf8
PR for reference: aws/aws-sdk-js-v3#4372

Some packages in aws-sdk-js-crypto-helpers depend on @aws-sdk/util-utf8-browser
Code search link: https://github.com/search?q=repo%3Aaws%2Faws-sdk-js-crypto-helpers%20util-utf8-browser&type=code

Describe the solution you'd like

Replace usages of @aws-sdk/util-utf8-browser with @aws-sdk/util-utf8 and release 3.1.0

Describe alternatives you've considered

Continue using deprecated module @aws-sdk/util-utf8-browser

Is your feature request related to a problem? Please describe

The homepage field for the individual packages (if present) links to root of the monorepo.
The folks using the link and landing on GitHub have to go through monorepo structure, and find out the correct package.

For example, open @aws-crypto/crc32c on npm, and click on Homepage in the right sidebar.

The page opened will be https://github.com/aws/aws-sdk-js-crypto-helpers#readme

Describe the solution you'd like to see

The homepage config should link to folder where source code for the package is present.

For @aws-crypto/crc32c package, the URL stored in homepage should be https://github.com/aws/aws-sdk-js-crypto-helpers/tree/master/packages/crc32c

Describe alternatives you've considered

N/A

Via automated security updates, we were alerted to this issue with mem. The recommended mediation was to upgrade to 4.0.0, but we probably don't need this particular dependency at all.

WS-2018-0236 More information

Vulnerable versions: < 4.0.0
Patched version: 4.0.0
In nodejs-mem before version 4.0.0 there is a memory leak due to old results not being removed from the cache despite reaching maxAge. Exploitation of this can lead to exhaustion of memory and subsequent denial of service.

Is your feature request related to a problem? Please describe.

Not a problem. The Hash interface in @aws-sdk/types package is being deprecated and replaced by the new Checksum interface. (See PR for the new Checksum interface)

Several Hash implementations e.g. AwsCrc32, Sha256, etc are currently used in the aws-sdk-js-v3 repo. The Checksum work can not be proceeded unless they are updated to use Checksum.

Describe the solution you'd like

• Update all the existing Hash implementations to use Checksum instead e.g. AwsCrc32, Sha256, etc
• Keep existing update method if it contains encoding to maintain backward compatibility. E.g.

export class Sha256 implements Checksum {
  private readonly hash: Hash;

  update(data: Uint8Array): void;
  update(data: SourceData, encoding?: "utf8" | "ascii" | "latin1"): void {
    this.hash.update(data, encoding);
  }

}

Attempting to import @aws-crypto/[email protected] in an Angular 9 project produces an error in the browser console under both Chrome 79.0.3945.130 (Uncaught ReferenceError) & Safari 13.0.4 (ReferenceError: Can't find variable: Buffer):

Chrome:

Uncaught ReferenceError: Buffer is not defined
    at Object../node_modules/core-util-is/lib/util.js (util.js:103)
    at __webpack_require__ (bootstrap:84)
    at Object../node_modules/readable-stream/lib/_stream_readable.js (_stream_readable.js:67)
    at __webpack_require__ (bootstrap:84)
    at Object../node_modules/readable-stream/readable-browser.js (readable-browser.js:1)
    at __webpack_require__ (bootstrap:84)
    at Object../node_modules/stream-browserify/index.js (index.js:28)
    at __webpack_require__ (bootstrap:84)
    at Object../node_modules/hash-base/index.js (index.js:3)
    at __webpack_require__ (bootstrap:84)

Per @aws-sdk issue #3437, I believe a PR incorporated into @aws-sdk/*@3.54.1, which moved several types from @aws-sdk/shared-ini-file-loader into @aws-sdk/types, generated an incompatibility with aws-crypto packages depending on aws-sdk/types@^3.1.0, resulting in error TS2305 when running tsc on a project with the default tsconfig.json skipLibCheck: false.

In testing with a project dependent upon @aws-crypto/[email protected], forcing installation of @aws-sdk/types@latest prevents the TS2305 error. Can @aws-crypto packages be updated to a newer @aws-sdk/types compatible with the latest @aws-sdk releases?

This is similar to #525

util-utf8-browser was deprecated in favor of @aws-sdk/util-utf8 and then @smithy/util-utf8. However there are still runtime dependencies in sha1-browser and sha256-browser that still point to util-utf8-browser, which is problematic due to a files glob issue in its package.json . This trips up npm 9 packaging because it correctly interprets the specified glob whereas npm 8 and likely yarn happily behave incorrectly.

Code:

Node.js 14.x is going Active LTS on 2020-10-27: https://github.com/nodejs/Release#release-schedule

Attempting to install @aws-crypto/[email protected] under [email protected] & [email protected] fails with No matching version found for @aws-sdk/types@^0.1.0:

 npm install --save-exact @aws-crypto/[email protected]

npm ERR! code ETARGET
npm ERR! notarget No matching version found for @aws-sdk/types@^0.1.0.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.
npm ERR! notarget 
npm ERR! notarget It was specified as a dependency of '@aws-crypto/sha256-browser'
npm ERR! notarget 

TravisCI is one of the most popular CI tool on GitHub https://travis-ci.org/
Travis is used by many aws repositories https://travis-ci.org/organizations/aws/repositories

The Usage example in the sha256-universal package shows the following import path:

import {Sha256} from '@aws-crypto/crypto-sha256-universal'

However, when installing @aws-crypto/[email protected], no such directory is created innode_modules The library is under node_modules/@aws-crypto/sha256-universal.

Is your feature request related to a problem? Please describe.

The AWS SDK for JavaScript (v3) has a new requirement for using SHA1 checksum algorithm in the browser.
The SHA256 implementation is available in @aws-crypto/sha256-browser. There is no equivalent @aws-crypto/sha1-browser implementation.

Describe the solution you'd like

Provide @aws-crypto/sha1-browser implementation.

Describe alternatives you've considered

• Use SHA1 implementation in sha1
• Write our own SHA1 implementation in @aws-sdk/ scope.

As per offline discussion, my suggestion is to switch to yarn workspaces so that there’s a single yarn.lock file in the root to view all dependencies.

Recommendation for:

• We at aws/aws-sdk-js-v3 been using lerna for couple of years now. We switched to yarn ~6 months ago, and have been very happy with it.
• About dependabot, example workshop code repo:
  • we didn’t use workspaces before, so dependabot used to create PR for each package http://bit.ly/2ZYS6M1
  • after moving to yarn workspaces, dependabot started updating dependencies globally http://bit.ly/2QTF26u

I've been trying to track down a bug we're seeing on IE where there's an Array.from polyfill in place (for other code).

I think it's related to the following code (from #221):

packages/util/src/uint32ArrayFrom.ts :

// IE 11 does not support Array.from, so we do it manually
export function uint32ArrayFrom(a_lookUpTable: Array<number>): Uint32Array {
  if (!Array.from) {
    const return_array = new Uint32Array(a_lookUpTable.length)
    let a_index = 0
    while (a_index < a_lookUpTable.length) {
      return_array[a_index] = a_lookUpTable[a_index]
    }
    return return_array
  }
  return Uint32Array.from(a_lookUpTable)
}

The code appears to be checking for Array.from (which has been polyfilled), but then using Uint32Array.from (which hasn't) and throwing an error. At least, I think that's what happening, apologies if I've missed something.

Thanks,

Richard

I noticed that this project uses "Create a merge commit" while merging PRs.
This creates a merge commit, and all commits from PR (including experimental ones) are merged to master.

Commit history: https://github.com/aws/aws-sdk-js-crypto-helpers/commits/master

Merge commit and base commits for #26

Mixed commits between #19 and #25

Suggestion: Do the following in settings https://github.com/aws/aws-sdk-js-crypto-helpers/settings

• Disable "Allow merge commits" and "Allow rebase merging"
• Only enable "Allow squash merging"

Squash and merge will create one commit per PR, keeping the history clean.
Squash merging is used in https://github.com/aws/aws-sdk-js-v3/commits/master

Having older tslib versions causes webpack duplication and node module nesting to occur.

I noticed when I was bundling the AWS SDK JS v3 in webpack bundle analyzer as a size inspection.

Users can manually override with the following in webpack.config.js

  resolve: {
    alias: {
      tslib: path.join(__dirname, "node_modules", "tslib"),
    },
  },

Problem

When bundling with rollup, rollup provides with a warning coming from @aws-crypto/crc32.
It affects the resulting bundle size, as it harms tree shaking and depending on the use case might trigger a runtime error.

Full trace (report) is below:

Circular dependency: ../node_modules/@aws-crypto/crc32/build/index.js -> ../node_modules/@aws-crypto/crc32/build/aws_crc32.js -> ../node_modules/@aws-crypto/crc32/build/index.js
Circular dependency: ../node_modules/@aws-crypto/crc32/build/index.js -> ../node_modules/@aws-crypto/crc32/build/aws_crc32.js -> ../node_modules/@aws-crypto/crc32/build/index.js?commonjs-proxy -> ../node_modules/@aws-crypto/crc32/build/index.js

Request

Please remove the circular dependency issue

It's been 8 months since the last release of this repo's packages to the npm registry. When is the next released planned?

I'm asking because I've built a PR to fix various sourcemap problems with aws-amplify and along with fixes to that repo I also want to bump its other AWS dependencies like @aws-crypto to versions containing the sourcemaps fixes from #169 that was merged in this repo a few weeks ago.

We have @aws-crypto/sha256-js as a transient dependency and since it's package.json.dependencies are locked to update on any "minor" our lockfile (yarn.lock) keeps getting updated anytime we do yarn install.

I.e. https://github.com/elsaapp/aws-sdk-js-crypto-helpers/blob/61ed3814c1f11a9531bc75e394cfc651be2770a8/packages/sha256-js/package.json#L25-L26

"@aws-sdk/types": "^3.222.0",
"tslib": "^2.6.2"

As far as I can tell this repository doesn't make direct use of the automatic "minor" updates so I'm hoping that we can be stricter and either:

1. change from "minor" to "patch" version, i.e. ^ to ~
2. use exact versioning

I'm currently trying to add aws-amplify to my project, but one of its dependencies (@aws-crypto/sha256-browser) doesn't work with my build system, snowpack.
Snowpack is built around ES6 modules, but tries to compile commonjs modules to ES6 if an npm package doesn't ship ES6 module files. Unfortunately, this commonjs-to-ES6 conversion can only use heuristics (because commonjs "exports" are regular JS expressions and therefore not statically analyzable). This heuristic doesn't detect the commonjs version of export * from ..., so it doesn't get turned back into an ES6 export by snowpack. The missing export causes the runtime errorUncaught SyntaxError: The requested module '../_snowpack/pkg/@aws-crypto.sha256-browser.v2.0.0.js' does not provide an export named 'Sha256'.
For more details about the exact setup to reproduce my issue, please check out the issue I filed with snowpack: FredKSchott/snowpack#3819

One way to solve this issue would be to ship ES6 files in package @aws-crypto/sha256-browser, and announce them to modern build tools by adding an exports key to your package.json file. This would also be helpful for other tools that rely on ES6 module syntax, like rollup, esbuild or vite.

Node.js 8 was end-of-life on 2019-12-31: https://github.com/nodejs/Release#end-of-life-releases

We should determine how to drop support in this package.
Step 1 is to stop running tests against 8.x
(optional?) Step 2 is to block this package being used with 8.x

We should determine when these steps should be done

Does crypto-js has an ECCN classification?
https://en.wikipedia.org/wiki/Export_Administration_Regulations

Probably should replace this. PR coming shortly.

Is your feature request related to a problem? Please describe.

While going through the code base, I noticed several duplicate utility functions.

In future, these utility functions need to be reused when implementing Wrappers to be compliant with Hash interface in @aws-sdk/types. For example #204

If an application depends on multiple packages, the code is duplicated increasing the bundle size affecting the performance.

Describe the solution you'd like

Move utility functions to a new package - say @aws-crypto/utils

Describe alternatives you've considered

Continue depending on packages with duplicate code.

Background: aws/aws-sdk-js-v3#929

Currently, sha256-browser package doesn't work if ReactNative users enable the debug mode. This is because the package falsly detect the RN environment as browser invironment and try to utilize the Crypto.Subtle class that doesn't exist in the environment.

If you don't have plan to support RN use case soon, it's better to document in the README to use @aws-crypto/sha256-js indead.

/cc @seebees

Is your feature request related to a problem? Please describe.

The AWS SDK for JavaScript (v3) has a new requirement for using SHA1 checksum algorithm.
The SHA256 implementation is available in @aws-crypto/sha256-js. There is no equivalent @aws-crypto/sha1-js implementation.

Describe the solution you'd like

The SHA1 implementation is provided in following packages or equivalent:

• @aws-crypto/sha1-js
• @aws-crypto/sha1-browser
• @aws-crypto/sha1-universal

Describe alternatives you've considered

• Use SHA1 implementation in sha1
• Write our own SHA1 implementation in @aws-sdk/ scope.

Describe the bug
npmjs website of @aws-crypto packages links to aws-javascript-crypto-helpers repo which doesn't exist

To Reproduce

• Visit npmjs website of any @aws-crypto package (for example, @aws-crypto/crc32)
• Click on github link in the right sidebar, which links to aws-javascript-crypto-helpers repo which doesn't exist

Expected behavior
The github link in npmjs website links to aws-sdk-js-crypto-helpers

Screenshots

As of v3.18.2, as discussed in lerna/lerna#1998,
lerna will now force-add the package-lock.json file in each package
to git as part of the versioning workflow.
If these files are in our gitignore this will result in a confusing developer experience
and a failure of the lerna version command.

Further clearly identifying the version of all packages for a given commit will help with debugging.
package-lock.json was initially ignored because this is a library that is used by other developers
and the lock file is ignored when this package was published
and installed as a dependency.

Notice that there's no alpha tag under dist-tags:

$ npm view @aws-crypto/supports-web-crypto

@aws-crypto/[email protected] | Apache-2.0 | deps: 1 | versions: 6
Provides functions for detecting if the host environment supports the WebCrypto API
https://github.com/aws/aws-sdk-js-crypto-helpers#readme

dist
.tarball: https://registry.npmjs.org/@aws-crypto/supports-web-crypto/-/supports-web-crypto-1.0.0-alpha.0.tgz
.shasum: f9f2bed724caba3036be73e1f9bf25e01e5f6c42
.integrity: sha512-jVWjNCoEKY49NIWyU1ia1RvtupEZEzOTkYZ1kRH+Z0RqIg9DZksQ7PbSRvxtAv8rTBdyGSgQdEpbFtQtm/ZiRQ==
.unpackedSize: 24.8 kB

dependencies:
tslib: ^1.9.3 

maintainers:
- agray256 <[email protected]>
- amzn-oss <[email protected]>
- jpeddicord <[email protected]>
- seebees <[email protected]>

dist-tags:
latest: 1.0.0-alpha.0

For comparison with @aws-sdk/client-s3:

$ npm view @aws-sdk/client-s3

@aws-sdk/[email protected] | Apache-2.0 | deps: 42 | versions: 11
@aws-sdk/client-s3 client

dist
.tarball: https://registry.npmjs.org/@aws-sdk/client-s3/-/client-s3-1.0.0-alpha.1.tgz
.shasum: 6a96fcadcbf131b31fc67d1ce9abd9094f6fcb66
.integrity: sha512-SaYm1SBbI2VMOMLjpQ99UiRkNJiuTl0DPu9hF75Vu5dD1TYIE1FY0BACE5tdyki+3h7ebb1n/GTKu6agBBCsng==
.unpackedSize: 3.6 MB

dependencies:
@aws-crypto/sha256-browser: ^0.1.0-preview.1            @aws-sdk/hash-stream-node: ^1.0.0-alpha.0               @aws-sdk/middleware-expect-continue: ^1.0.0-alpha.0     @aws-sdk/middleware-signing: ^1.0.0-alpha.0             
@aws-sdk/config-resolver: ^1.0.0-alpha.1                @aws-sdk/invalid-dependency: ^1.0.0-alpha.1             @aws-sdk/middleware-host-header: ^1.0.0-alpha.0         @aws-sdk/middleware-ssec: ^1.0.0-alpha.0                
@aws-sdk/credential-provider-node: ^1.0.0-alpha.0       @aws-sdk/md5-js: ^1.0.0-alpha.0                         @aws-sdk/middleware-location-constraint: ^1.0.0-alpha.0 @aws-sdk/middleware-stack: ^1.0.0-alpha.1               
@aws-sdk/fetch-http-handler: ^1.0.0-alpha.1             @aws-sdk/middleware-apply-body-checksum: ^1.0.0-alpha.0 @aws-sdk/middleware-retry: ^1.0.0-alpha.1               @aws-sdk/middleware-user-agent: ^1.0.0-alpha.1          
@aws-sdk/hash-blob-browser: ^1.0.0-alpha.0              @aws-sdk/middleware-bucket-endpoint: ^1.0.0-alpha.0     @aws-sdk/middleware-sdk-s3: ^1.0.0-alpha.0              @aws-sdk/node-http-handler: ^1.0.0-alpha.1              
@aws-sdk/hash-node: ^1.0.0-alpha.1                      @aws-sdk/middleware-content-length: ^1.0.0-alpha.1      @aws-sdk/middleware-serde: ^1.0.0-alpha.1               @aws-sdk/protocol-http: ^1.0.0-alpha.1                  
(...and 18 more.)

maintainers:
- amzn-oss <[email protected]>
- aws-sdk-bot <[email protected]>
- trivikr-aws <[email protected]>
- zheallan <[email protected]>

dist-tags:
alpha: 1.0.0-alpha.11  latest: 1.0.0-alpha.1

This is not a big concern, as @aws-crypto/* packages are released less frequently and will graduate to stable sooner.

Cannot even start the app now

convertToBuffer.js:17 Uncaught ReferenceError: Buffer is not defined
at Object.52023 (convertToBuffer.js:17)
at webpack_require (bootstrap:19)
at Object.50007 (index.js:9)
at webpack_require (bootstrap:19)
at Object.52897 (webCryptoSha256.js:11)
at webpack_require (bootstrap:19)
at Object.52809 (crossPlatformSha256.js:11)
at webpack_require (bootstrap:19)
at Object.48464 (index.js:8)
at webpack_require (bootstrap:19)

Describe the bug
The @aws-crypto/crc32 implementation is not compliant with Hash interface in @aws-sdk/types

Version number
@aws-crypto/[email protected]

To Reproduce (observed behavior)
Dependencies:

    "@aws-crypto/crc32": "1.0.0",
    "@aws-crypto/sha256-js": "1.1.0",
    "@aws-sdk/types": "3.22.0"

Code:

// test.ts
import { Crc32 } from "@aws-crypto/crc32";
import { Sha256 } from "@aws-crypto/sha256-js";
import { HashConstructor } from "@aws-sdk/types";

// TypeScript throws following error:
// Type 'typeof Crc32' is not assignable to type 'HashConstructor'.
//  Construct signature return types 'Crc32' and 'Hash' are incompatible.
//    The types returned by 'digest()' are incompatible between these types.
//      Type 'number' is not assignable to type 'Promise<Uint8Array>'.
const crc32: HashConstructor = Crc32;

// TypeScript does not throw an error.
const sha256: HashConstructor = Sha256;

Output:

$ tsc --version
Version 4.3.5

$ tsc --lib "es2018" test.ts
test.ts:7:7 - error TS2322: Type 'typeof Crc32' is not assignable to type 'HashConstructor'.
  Construct signature return types 'Crc32' and 'Hash' are incompatible.
    The types returned by 'digest()' are incompatible between these types.
      Type 'number' is not assignable to type 'Promise<Uint8Array>'.

7 const crc32: HashConstructor = Crc32;
        ~~~~~


Found 1 error.

Expected behavior
The Crc32 implementation in @aws-crypto/crc32 must be compliant with Hash interface in @aws-sdk/types just like @aws-crypto/sha256-js

Error when calculating sha256 for files larger than 2g

example：https://codesandbox.io/s/mystifying-thunder-53gsf3?file=/src/App.js

This is a follow-up for this issue: aws/aws-sdk-js-v3#2292

When that error was fixed now I am able to unwrap the actual error. Here is the smallest code to reproduce:

import { Sha256 } from "@aws-crypto/sha256-browser";

const hash = new Sha256();
hash.update("");
hash.digest().then(
  function (result) {
    console.log("ok", result);
  },
  function (error) {
    console.log("fail", error);
  }
);

This code works (aka produces the hashed result) in all browsers (Chrome, Firefox, Safari) but not in IE 11.

On this page you can also see this demo live and here is the source code you can check out locally.

Background

Please see the original issue for @aws-sdk/client-sts here: aws/aws-sdk-js-v3#5305

Summary

When using @aws-sdk/client-sts as a bundleDependencies, npm pack resolves @aws-sdk/client-sts dependency on @aws-crypto/sha256-browser and @aws-crypto/sha256-js to 3.0.0 for compatibility with Node.js 14.x. Due to breaking changes in NPM 9+ to npm pack these older versions resolve to the deprecated package @aws-sdk/util-utf8-browser which has files omitted, leading to the error Cannot find module. npm pack does not work with overrides as a work-around.

Issue

Since all currently supported versions of Node.js use NPM 9+ we are looking to resolve this issue.

According to the original issue AWS SDK cannot drop support for Node.js 14.x until May 1, 2024 or later. Therefore changing the dependency version in use by @aws-sdk/client-sts on the main branch would require a version of @aws-crypto compaible with both NPM 9+ and Node.js 14.x which we were advised to request.

Please advise if this is possible or if any additional information is required.
Thank you for your time and assistance.

Describe the issue
git commit on this project shows following warning:

husky > pre-commit (node v10.22.0)
⚠ Some of your tasks use `git add` command. Please remove it from the config since all modifications made by tasks will be automatically added to the git commit index.

To Reproduce

1. Clone repo.
2. Make any code change.
3. Run git add . and git commit

Expected behavior
No warning shown when doing git commit

The AWS-SDK is preparing a release after merging this PR.

This will help Amplify-JS to successfully build the library as there is a current issue with @smithy/types braking TS<4.1

Is your feature request related to a problem? Please describe.

The AWS SDK for JavaScript (v3) has a new requirement for using CRC32C checksum algorithm.
The CRC32 implementation is available in @aws-crypto/crc32. There is no equivalent @aws-crypto/crc32c implementation.

Describe the solution you'd like

The CRC32C implementation is provided in @aws-crypto/crc32c

Describe alternatives you've considered

Use CRC32C implementation in junderw-crc32c

sha256-browser package currently only contains an async digest method which is breaking some edge cases in analytics. This feature request is to add another sync digest method to keep compatibility with what was provided by the javascript V2 sdk https://github.com/aws/aws-sdk-js/blob/master/lib/browserSha256.js#L149

Is your feature request related to a problem? Please describe.

Reference: https://github.com/lerna/lerna#fixedlocked-mode-default

1. Currently the SDK create a new tag for each new version each subpackage. This results in having too many tags to maintain.
2. Using independent versioning also adds some unnecessary complexity over the release system.
3. Most popular monorepos use fixed versioning, like Lerna, Babel

Describe the solution you'd like

Move the fixed versioning.

Additional context
aws-sdk-js-v3 switched to fixed versioning with their release candidate in aws/aws-sdk-js-v3#1248

Is your request related to a problem? Please describe.

Refs: https://github.com/trivikr/benchmark-crc32

Benchmarks in Node.js v16.4.0:

crc x 418,858 ops/sec ±0.33% (91 runs sampled)
crc-32 x 426,337 ops/sec ±0.25% (96 runs sampled)
buffer-crc32 x 318,404 ops/sec ±0.33% (94 runs sampled)
@aws-crypto/crc32 x 74,763 ops/sec ±0.90% (95 runs sampled)
Fastest is crc-32

Benchmarks in Firefox browser v78.10.1esr:

crc x 188,843 ops/sec ±0.48% (63 runs sampled)
crc-32 x 370,060 ops/sec ±0.85% (67 runs sampled)
buffer-crc32 x 80,874 ops/sec ±2.67% (64 runs sampled)
@aws-crypto/crc32 x 15,069 ops/sec ±1.78% (64 runs sampled)
Fastest is crc-32

Describe the solution you'd like

The @aws-crypto/crc32 implementation to be at par or close to other CRC32 implementations.

Please fill in the
Copyright [yyyy] [name of copyright owner]
in the appendix of the copyright notice. Otherwise it is difficult for enterprises to use this.