Pin jwt to 1.2.0 to avoid timing vulnerabilities in cryptography@2.9.2

[erikogan]

Description of change

Our security team flagged this as a vulnerability. jwt@0.6.1 depends on cryptography@2.9.2, which contains timing vulnerabilities. Upgrading to at least 1.1.0 will fix this. python-jwt does not have a CHANGELOG, but scanning the commits between 0.6.1 & 1.2.0 as well as the documentation shows that the API as used by tap-google-analytics has not changed.

QA steps

• automated tests passing
• manual qa steps passing (list below)

Risks

• jwt@1.1.0 (the earliest version that depends on a patched version of cryptography) also dropped support for Python < 3.6 (all of which are EoL).

Rollback steps

• revert this branch

[cmerrick]

Hi @erikogan, thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes.

[erikogan]

Hi, @cmerrick. Sorry for the delay getting back to you, we had a bit of a shuffle here figuring out who should be the actual signatory.

The contribution copyright is owned not by me personally, but us (One Medical), so we need our V.P. of Engineering to be the signatory. It looks like your heroku app is designed to handle contributions from individuals, and it builds an agreement tied to the contributor. How should we proceed?

Also: I’m going to have another, more substantial contribution shortly for a different component (singer-io/tap-eloqua). Is it safe to assume this agreement can cover both?

[erikogan]

@cmerrick Is there something I can do to get this question answered? I’d love to contribute both this micro change, and the tap-eloqua changes soon!

[erikogan]

@cmerrick I was just reminded of this issue. We’d love to contribute our changes to both this tap and tap-eloqua. How can we get a CLA that correctly names the organization as the copyright holder?