-
-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resurrect dedyn.io registrations #1014
Conversation
e60918c
to
362a348
Compare
After this is deployed, the plan is to send out messages like the following (with bullet points included as appropriate):
|
Updates the requirements on [django](https://github.com/django/django) to permit the latest version. - [Commits](django/django@5.1.4...5.1.5) --- updated-dependencies: - dependency-name: django dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
Updates the requirements on [psycopg[binary]](https://github.com/psycopg/psycopg) to permit the latest version. - [Changelog](https://github.com/psycopg/psycopg/blob/master/docs/news.rst) - [Commits](psycopg/psycopg@3.2.3...3.2.4) --- updated-dependencies: - dependency-name: psycopg[binary] dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
457d9f6
to
e6cba2b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some concerns around policy. Nits on code style.
I've addressed all comments, except one (pls continue conversation). Would also be interested in your opinion on #1014 (comment) (including "no opinion"). |
For the email you propose - I'm afraid it will take a while to craft the emails and it might generate a bulk of support workload. I was going to propose to silently remove or fix these but Sec. 4 of the Terms mentions there "may be" a removal warning. If you share my concern, I think fixing without warning is an acceptable way forward. I don't think we need to support dysfunctional (or slow) resolution of certain names. Removing without warning is also a possibility but perhaps a bit of a stretch of the terms (which could be clarified in this regard). If you do not share the concern (or think the benefits outweigh), my only comment on the text is that I believe most users that are affected aren't well-trained in DNS things. To ease their understanding, I'd suggest to simplify the language and shorten it. |
Previously, the serializer would fall back to the default empty subname. On non-apex records, this resulted in an attempt to change the subname value, which previously was rejected (with a different error). For apex names, the operation would continue (because the default subname would mean no change).
This reverts commit 477b6c8. Deployment should be accompanied by a corresponding change in the DESECSTACK_API_REGISTER_LPS variable in the Docker environment.
This reverts 607a007, because Let's Encrypt is ending OCSP support (https://letsencrypt.org/2024/12/05/ending-ocsp).
2e63541
to
64c7f77
Compare
I already have a script for that, which works off a database query CSV output.
I'm prepared to take that :)
Ack
I'd rather not do apply that retroactively.
I'll try, but if I don't have good ideas I'll leave (nearly) as is. I'll add a link to the forum so people can gather there and don' have to repeat their questions. |
(the push was just an autosquash) |
No description provided.