@osirisinferi pointed out [in chat](https://opensource.eff.org/eff-open-source/pl/y5whp5ny378wuedi8gd7995qbo) that the way this entry was written, suggested that `--new-key` might affect whether `--reuse-key` is set or not.
I think the second sentence was the main culprit, so I've nixed it and replaced it with a reminder about our other flags.
This maybe calls out more for a documentation section but let's fix this quickly before the release.
* Add message to account reg. error
* Changelog
* Remove forced lowercase first char
* Catch errors raised by acme library
* Fix mypy and add some comments
* Add some tests
* Move changelog entry to current version
* Address comments
* Address additional comments
Put everything in this commit instead of using the "Commit suggestion"
feat on Github, which would resolve in 4 different tiny commits.
* Skip ToS agreement question if ToS value is None
* Add changelog entry
* Typo in CHANGELOG
Co-authored-by: ohemorange <ebportnoy@gmail.com>
* Typo in CHANGELOG
Co-authored-by: ohemorange <ebportnoy@gmail.com>
Co-authored-by: ohemorange <ebportnoy@gmail.com>
* certbot-ci: fix challtestsrv address for boulder-v2
The port is no longer exposed on the Docker host.
* vary the challtestsrv URL by acme server
* fix mypy
* fix comment
Co-authored-by: ohemorange <ebportnoy@gmail.com>
Co-authored-by: ohemorange <ebportnoy@gmail.com>
* Remove cast for jose.fields.
https://github.com/certbot/certbot/pull/9073 references this.
* Some of them can't be removed, though.
* Fix josepy type hints of json
* Increase josepy pinning version.
Note that the repin scripts have not been used.
* Run repin scripts.
* Fix constraints
* Remove Windows 2016 environment, generate 64 bit installer
* Add note to changelog
* Use win_amd64 as installer suffix
* Bump PYTHON_BITNESS to 64
* Require 64 bit Windows for the installer_build job
* Update certbot install path
* update windows test name
* Base installer suffix on PYTHON_BITNESS again
* Update changelog to request users uninstall old version
* improve handling and ux of unexpected key type migration
* update unit tests
* update integration tests
* if --cert-name and --key-type are set, dont prompt
* Add challenge info to `--debug-challenges`
* Expand/add tests
* Add changelog entry
* Make tests Python 3.6 and 3.7 compatible
* Don't use `config.namespace`
* And don't use `config.namespace` in tests too
* Expand tests to check for token/thumbprint
* Add test for the DNS-01 challenge
Changed the Apache authenticator to the manual authenticator. Doesn't
seem to make a difference to the tests, but makes more sense if the
DNS-01 challenge is being used.
* Reword changelog entry
* Mention feature in --help output
* Better variable assignment in test
Co-authored-by: alexzorin <alex@zor.io>
* Better variable assignment in test
Co-authored-by: alexzorin <alex@zor.io>
* Remove unnecessary `verbose_count` assignment
Co-authored-by: alexzorin <alex@zor.io>
* Use terminology from RFC 8555
* Compress the two new tests into one
* s/world wide web/internet
* Move new code into separate function
* Remove superfluous newline with mixed challs
Co-authored-by: alexzorin <alex@zor.io>
I think test_apache2.sh still has value as it allows us to test our Apache plugin with the Apache layouts found on different OSes. Unfortunately, many of the OSes we're currently testing against don't have Python 3.7+ packaged yet we still support these OSes through things like snap where we bundle our own version of Python.
To allow us to continue testing on these OSes, I switched to installing Python through pyenv. I also took the opportunity to clean up the scripts, removing a lot of code, failing more quickly, and simplifying failure logic in test_apache2.sh.
The reason I want to do this is many of the targets of `test_sdists.sh` use Python 3.6 which [has reached its EOL](https://www.python.org/dev/peps/pep-0494/#lifespan). We could instead just stop running the test on these systems or install a newer version of Python 3 outside of OS packaging, but instead I decided to look into why we have these tests to begin with.
I introduced these tests many years ago in https://github.com/certbot/certbot/pull/4089 as a fix for https://github.com/certbot/certbot/issues/4044. Essentially the problem was the way packagers ran tests and the way we ran tests were slightly different. This difference could cause test failures when distros tried to run tests on our packages.
Since I did this, [we've switched to telling packagers to run tests using `pytest` like we do](5e76669c50/certbot/docs/packaging.rst (notes-for-package-maintainers)) and we've greatly reduced our reliance on OS packaging through things like `snap`.
Because of this, I think we should stop running this test, reducing our reliance on the heavy "test farm tests", and simplifying our CI pipeline. I think future problems here is quite unlikely and even if we have them, it should only affect tests on our non-primary distribution mechanisms which I think is a very minor concern.
When reviewing this PR, it's probably worth noting that I just replaced `targets.yaml` with the contents of `apache2_targets.yaml` since the Apache 2 tests are the only runs we're running with this change.
* Revert setuptools-rust pin
This was a temporary workaround to fix
https://github.com/certbot/certbot/issues/9111, but it looks like the
the issue resolved itself
* Make mypy happy
There was an unused ignore statement, and Validator.certificate was
unnecessarily casting strings as bytes for an X509 digest method.
* Pin setuptools-rust to prevent build-dep hiccups in the future
