Bump cryptography from 38.0.4 to 39.0.1

[dependabot]

Bumps cryptography from 38.0.4 to 39.0.1.

Changelog

Sourced from cryptography's changelog.

39.0.1 - 2023-02-07

* **SECURITY ISSUE** - Fixed a bug where ``Cipher.update_into`` accepted Python
  buffer protocol objects, but allowed immutable buffers. **CVE-2023-23931**
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.0.8.
.. _v39-0-0:
39.0.0 - 2023-01-01

• BACKWARDS INCOMPATIBLE: Support for OpenSSL 1.1.0 has been removed. Users on older version of OpenSSL will need to upgrade.
• BACKWARDS INCOMPATIBLE: Dropped support for LibreSSL < 3.5. The new minimum LibreSSL version is 3.5.0. Going forward our policy is to support versions of LibreSSL that are available in versions of OpenBSD that are still receiving security support.
• BACKWARDS INCOMPATIBLE: Removed the encode_point and from_encoded_point methods on :class:~cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePublicNumbers, which had been deprecated for several years. :meth:~cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePublicKey.public_bytes and :meth:~cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePublicKey.from_encoded_point should be used instead.
• BACKWARDS INCOMPATIBLE: Support for using MD5 or SHA1 in :class:~cryptography.x509.CertificateBuilder, other X.509 builders, and PKCS7 has been removed.
• BACKWARDS INCOMPATIBLE: Dropped support for macOS 10.10 and 10.11, macOS users must upgrade to 10.12 or newer.
• ANNOUNCEMENT: The next version of cryptography (40.0) will change the way we link OpenSSL. This will only impact users who build cryptography from source (i.e., not from a wheel), and specify their own version of OpenSSL. For those users, the CFLAGS, LDFLAGS, INCLUDE, LIB, and CRYPTOGRAPHY_SUPPRESS_LINK_FLAGS environment variables will no longer be respected. Instead, users will need to configure their builds as documented here_.
• Added support for :ref:disabling the legacy provider in OpenSSL 3.0.x<legacy-provider>.
• Added support for disabling RSA key validation checks when loading RSA keys via :func:~cryptography.hazmat.primitives.serialization.load_pem_private_key, :func:~cryptography.hazmat.primitives.serialization.load_der_private_key, and :meth:~cryptography.hazmat.primitives.asymmetric.rsa.RSAPrivateNumbers.private_key. This speeds up key loading but is :term:unsafe if you are loading potentially attacker supplied keys.
• Significantly improved performance for :class:~cryptography.hazmat.primitives.ciphers.aead.ChaCha20Poly1305

... (truncated)

Commits

• d6951dc changelog + security fix backport (#8231)
• 138da90 workaround scapy bug in downstream tests (#8218) (#8228)
• 69527bc bookworm is py311 now (#8200)
• 111deef backport main branch CI to 39.0.x (#8153)
• 338a65a 39.0.0 version bump (#7954)
• 84a3cd7 automatically download and upload circleci wheels (#7949)
• 525c0b3 Type annotate release.py (#7951)
• 46d2a94 Use the latest 3.10 release when wheel building (#7953)
• f150dc1 fix CI to work with ubuntu 22.04 (#7950)
• 8867724 fix README for python3 (#7947)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

[iainelder]

The linting job failed for some reason.

https://github.com/connelldave/botocove/actions/runs/4120906018/jobs/7116097629

This seems to be the cause of the failure:

           RuntimeError: The Poetry configuration is invalid:
            - [extras.pipfile_deprecated_finder.2] 'pip-shims<=0.3.4' does not match '^[a-zA-Z-_.0-9]+$'

I have no idea what that really means, and I can't reproduce it locally.

When I run poetry run pre-commit run --all-files, everything passes.

[iainelder]

In my local development environment pre-commit is already initialized and so it's avoiding this problem.

I can reproduce the error in a docker container like this:

docker run -it ubuntu:20.04 bash -c '
apt -y update
apt -y install git python3-pip python3-venv curl
curl -sSL https://install.python-poetry.org | python3 -
export PATH="${PATH}:/root/.local/bin"
git clone https://github.com/connelldave/botocove.git
cd botocove
git checkout dependabot/pip/cryptography-39.0.1
poetry install
poetry run pre-commit run --all-files
'

It seems that the error occurs after pre-commit starts to initialize the environment for isort.

Before the stack trace, pre-commit prints this:

[INFO] Installing environment for https://github.com/pycqa/isort.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...

[iainelder]

To reproduce it in my usual environment, I need to clean pre-commit's cache.

poetry run pre-commit clean

Some else already ran into the problem and solved it by upgrading isort to 5.12.0.

This also solves it in my local environment.

It's just something that all the isort users have to deal with this week.

home-assistant/core#86892

PyCQA/isort#2083

I'll make a PR to fix isort.

[iainelder]

See #60 for a fix for the CI error.

[connelldave]

Good catch on the CI error.

Maybe I haven't had enough coffee, but I fixed a dependabot alert previously and wasn't sure it actually made any difference: given the library has no pinned deps, this must just be a lockfile issue - and that lockfile is basically just for local dev?

Is the correct solution here just not commiting a lockfile?

[iainelder]

Is the correct solution here just not commiting a lockfile?

I think it's normally a good idea to commit the lockfile for the sake of reproducibility With it we (you, me, other developers, the CI system) are all using exactly the same versions.

Poetry Basic Usage started by backing up my hunch:

Committing this file to VC is important because it will cause anyone who sets up the project to use the exact same versions of the dependencies that you are using. Your CI server, production machines, other developers in your team, everything and everyone runs on the same dependencies, which mitigates the potential for bugs affecting only some parts of the deployments. Even if you develop alone, in six months when reinstalling the project you can feel confident the dependencies installed are still working even if your dependencies released many new versions since then.

And then confused me again by stating the opposite without any reasons:

For libraries it is not necessary to commit the lock file.

Botocove is a library, so is it not necessary to commit the lock file? Why not?

Without a good reason not to, I'd still do it anyway for the sake of developers.

As a periodic housekeeping task (monthly or quarterly) the pre-commit dependencies and the lockfile dependencies could be upgraded to their latest versions to keep our dev tooling up to date.

[iainelder]

#60 got merged so I rebased this PR. Now the CI passes.

[iainelder]

Is the correct solution here just not commiting a lockfile?

I'm starting to think that, yes, in our case it might be easier just to omit the lock file.

Helpful insight from the Poetry maintainers:

keeping the lockfile locally is a trade-off: it's true that you get reproducibility, but it also means that if some new dependency has been released that breaks things for consumers of your library, you're likely to be the last to find out about it.

I guess either choice is legit, but the usual advice is for libraries not to commit lockfiles.

eg here's Rust saying the same thing about Cargo.lock https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

Cargo.lock serves the same purpose for Rust programs, and the docs here are more detailed.

As a periodic housekeeping task (monthly or quarterly) the pre-commit dependencies and the lockfile dependencies could be upgraded to their latest versions to keep our dev tooling up to date.

By discarding the lock file, we can get that behavior automatically at least for the lock file.

So I'd be fine with deleting the lock file to see if it makes our lives easier.

If we start to get bed behavior caused by version differences, we can bring it back.

[connelldave]

I've removed the lockfile and will cut a release for typed file :)

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.