An early version of the spec indicated that clients should process issuance
sequentially, following Link rel=next from an account URL to an authz URL, to a
new-cert URL. However, the spec has long since moved to putting these URLs in
the directory.
Certbot nominally supports either; This change consolidates on always using the
directory, simplifying things and making the transition to the latest ACME spec
easier.
* Revert "Revert "Remove Link rel=next for authzs and new-certs." (#4277)"
This reverts commit 11ec1eb911.
* Save new_authzr_uri with account for older clients.
* Add test that new_authzr_uri exists in regr.
* Restore backwards compatibility for new_authzr_uri.
* Fix account_test.
* Add test for deprecated URI argument to request_challenges.
* Review feedback.
* Fix test
* Add omitempty to new_cert_uri.
* Remove UnexpectedUpdate exceptions.
These exceptions trigger when the server sends the client back an object with a
field that doesn't exactly match what the client previously sent.
This causes unnecessary breakage in various cases, doesn't prevent any problems,
and isn't required by spec.
* Back out all UnexpectedUpdate removals except registration update.
* lineage_for_certname should return None if there is no existing renewal file
* add unit test
* add regression test to integration test
* revent boulder-start to boulder-fetch
* Refactor main to simplify logic
* Update tests and comments
* Correct main test
* increase timeout limit
* reset timeout limit
* call renew_cert in appropriate main test
* Update docstrings and revert signatures of _report_new_cert and _suggest_donation_of_appropriate
* replace renew_cert logic
* update tests
* rename _csr_obtain_cert and add a check to _report_new_cert
An early version of the spec indicated that clients should process issuance
sequentially, following Link rel=next from an account URL to an authz URL, to a
new-cert URL. However, the spec has long since moved to putting these URLs in
the directory.
Certbot nominally supports either; This change consolidates on always using the
directory, simplifying things and making the transition to the latest ACME spec
easier.
Per @pfg at https://community.letsencrypt.org/t/-/21318/2:
> This is not really true anymore - account recovery via email was planned to be added at some point, but has been removed from the spec since.
* use challenge type strings, not objectS
* Factor out parse_preferred_challenges
* restore pref_challs
* save pref_challs
* Make CheckCertCount more flexible
* improve integration tests
* Make pref_challs more flexible
* add py36 to tox
* Add Python 3.6 tests to Travis
* Provide real path to python stdlib during tests
* set logs_dir in config_test
* set *_dirs in DetermineAccountTest
* Fix TLSSNI01Test
* Fix RenewalTest
* fix test_ancient_webroot_renewal_conf
This includes two new tests in the integration test script to check that
boulder gets the correct code. The encoding is specified in RFC5280
5.3.1. The codes that boulder will accept are a subset of that,
specified in `boulder.revocation.reasons.go`.
Fixes#3996.
I'm pretty confident this PR solves the problem. I've audited all calls to IDisplay methods and the assertions done in certbot.display.util are now done in all our unit tests.
With that said, it wouldn't hurt to have someone else double check I didn't miss anything. The easiest way to do this is to grep for IDisplay in our code and ensure all calls to IDisplay methods are valid. This means every method call other than notification (because a notification call is always OK) either provides a value for default or force_interactive. This is defined in interfaces.py.
I've also been considering removing the assertion that's been causing us trouble here from our release. The only argument I have for not doing so is it may hinder 3rd party plugin development. When they use IDisplay, they have the same problem as we do with prompting users without a TTY. Not keeping this assertion in makes it more likely they won't notice the issue and Certbot will crash on an unsuspecting user.
With that said, none of our known 3rd party plugins use IDisplay at all.
* Provide force_interactive in _get_certname
* Use force_interactive when asking for webroot
* Factor IDisplay assertion into it's own function
* Add util.patch_get_utility()
* Allow custom path to patch_get_utiity
* Change GetEmailTest to use patch_get_utility
* Use new_callable to create new objects
* Modify tests to use patch_get_utility
* Improve FreezableMock documentation
* Add user facing error to TTY magic
* Comment out assert_valid_call
* Add test_input_assertion_fail2()
* Add better error handling for invalid FQDNs
Add explicit error handling for labels that are empty. Also add test
cases to test invalid domains.
* Add more thorough tests
