CoreDNS 1.11.2 Release

[chrisohaver]

Let's do a release soon.

Any currently open PRs that we want to push to get into the next release?

[SuperQ]

It looks like we have a bunch of golangci-lint issues to fix.

[chrisohaver]

Yes, they've been failing I think since November.

[chrisohaver]

I suspect perhaps a change in the linter?

[Tantalor93]

oh I think I know, why it fails, this should fix it #6456
usually Dependabot pull requests failed due to conflict in cache of setup-go and golangci-lint action

[SuperQ]

Here's the current list of non-chore changes:

• plugin/rewrite: add rcode as a rewrite option by @pschou in plugin/rewrite: add rcode as a rewrite option #6204
• Handle UDP responses that overflow with TC bit by @SriHarsha001 in Handle UDP responses that overflow with TC bit #6277
• Use the correct root domain name in the proxy plugin's TestHealthX tests by @tmthrgd in Use the correct root domain name in the proxy plugin's TestHealthX tests #6395
• plugin/cache: key cache on Checking Disabled (CD) bit by @gcs278 in plugin/cache: key cache on Checking Disabled (CD) bit #6354
• plugin/etcd: the etcd client adds the DialKeepAliveTime parameter by @journey-c in plugin/etcd: the etcd client adds the DialKeepAliveTime parameter #6351
• plugin/auto: warn when auto is unable to read elements of the directory tree by @chrisohaver in https://github.com/c
  oredns/coredns/pull/6333
• plugin/tls: respect the path specified by root plugin by @mariuskimmina in plugin/tls: respect the path specified by root plugin #6138
• rewrite: fix multi request concurrency issue in cname rewrite by @Amila-Rukshan in rewrite: fix multi request concurrency issue in cname rewrite  #6407

[cattyhouse]

what about this :
#6069

[jason-bivins]

Hey, we have a few customers waiting on the UDP overflow fix. Is there an ETA for the release yet?

[berks-slack]

Is there an estimated date on this? There are quite a few dependency vulnerabilities in 1.11.1

[chrisohaver]

The docker build/publish has failed due to authentication failure (in 2 attempts).

[chrisohaver]

I do not have push access to the coredns docker hub repo, so I cannot resolve the docker push auth failure.

[chrisohaver]

Update: we tried replacing the docker creds with known working set, and we continue to see the same build failure - an authentication failure when attempting to push the images to dockerhub. Get "https://registry-1.docker.io/v2/": unauthorized: incorrect username or password

[cdalvaro]

Do you have considered using GitHub Container Registry?

It would be a great addition in order to avoid Docker pull quota limitation

[zhangguanzhang]

missing image coredns/coredns:1.11.2

[pacoxu]

missing image coredns/coredns:1.11.2

https://github.com/coredns/coredns/actions/runs/8084880918 the release CI failed.
@chrisohaver

[chrisohaver]

Aware

[chrisohaver]

I have deleted the 1.11.2 release so we don’t have a 1/2 completed release. Will re-release once docker login issue is resolved.

[BenTheElder]

The go1.21.8 / 1.22.1 CVE patches seem like something worth picking up https://groups.google.com/g/golang-dev/c/o1I1Vv8Rfgs/m/Wr8tD1RlAgAJ

[chrisohaver]

Docker login issue doesn't appear to have progressed.

Is anyone with coredns docker write permissions quietly working on this?

If not, perhaps we should consider moving away from dockerhub and publishing to gcr instead?

[jason-bivins]

hey @chrisohaver, if you're using Docker Desktop can you file a ticket here https://hub.docker.com/support/desktop ? If not, send an email to support@docker.com so we can help you get the hub credentials issue resolved?
It looks like the last user that pushed was one of the owners of the coredns organization in docker hub
https://hub.docker.com/r/coredns/coredns/tags

[chrisohaver]

I suspect the original failure was due to a password change.
And the failures after moving to a new account I suspect due to special characters present in the password getting mangled by make.

Just suspicion since I don't know the actual passwords.

[s3than]

Would it be possible to delete the tag for 1.11.2?

It's flagging as a release in a few tools

[robbiezhang]

@chrisohaver, is there a release branch/tag we can check if all security patches are included in v1.11.2.

[chrisohaver]

@chrisohaver, is there a release branch/tag we can check if all security patches are included in v1.11.2.

It will be cut from whatever the latest commit of the master branch is when we release it.

[robbiezhang]

@chrisohaver, is there a release branch/tag we can check if all security patches are included in v1.11.2.

It will be cut from whatever the latest commit of the master branch is when we release it.

Thanks for the reply. Would you consider having a formal release branch(es) and schedule (monthly or quarterly release) for CoreDNS? There are quite a lot CVEs exploited recently, we'll need to address them ASAP.

[chrisohaver]

There's an open proposal in process to support release branches - one of the open PRs open currently. However, that doesn’t really relate to the unresolved build publishing issue.

[max-allan-cgr]

@chrisohaver do you know if the release will still be called 1.11.2 or will it skip to 1.11.3?

(And will it be soon? Not trying to put pressure on you to get it done, but an ETA of when you think it could be done would be useful. If you're busy say "a month" it's fine!)

[chrisohaver]

@chrisohaver do you know if the release will still be called 1.11.2 or will it skip to 1.11.3?

What do you think would be least painful and confusing for everyone? I’m not sure.

(And will it be soon?…

maybe? Will try a release again later this week with recent build fix if no other maintainers do.

[max-allan-cgr]

Myself, I'd prefer 1.11.3. There seems to be a bit more going into this release than was in the original 1.11.2, so it does make sense to up-version.

[chrisohaver]

Ok. We can close this and open a 1.11.3 release tracking issue.

[chrisohaver]

I can retag the original 1.11.2 commit without a release if that helps people not be confused. Or maybe that would be more confusing? I don’t know. Let me know folks. What do you all want.

[chrisohaver]

I'm going to try to do a release the originally attempted commit 01bded8

And then try to the docker build with latest fixes on that tag.

Will see how that goes. 🤞

[chrisohaver]

well that didn't work. the release workflow failed when trying to create the tag.

[chrisohaver]

Symptoms the same as this issue: softprops/action-gh-release#411

[chrisohaver]

still failing

[chrisohaver]

still failing

To clarify: The tag&release step of the release script is failing. The docker publish step is not executed because that process happens after a successful tag&release. The failures from a few weeks ago were in the docker publish step. The failure in the tag&release step is a new development.

[tedaford]

Try poking at your tag protection rules. Or, if you want to see if it's a permissions issue, maybe try permissions: write-all , scoped to the specific failing job.
It's been a few years, but I want to say I had to give my token more permissions than I first assumed, when setting up a CI pipeline to cut Github releases

[chrisohaver]

Thanks - no tag protection rules in place, and per https://github.com/softprops/action-gh-release?tab=readme-ov-file#permissions, only "write" is required, which we have set.

I'm wondering if it's something like dangling references to the old tag that GitHub fails to clean up after a tag deletion preventing a tag with the same name being created again. If so, then v1.11.2 may forever be cursed and we need to move on to v1.11.3.

[networkhermit]

I managed to get the action-gh-release printing some debug information running from my fork:

https://github.com/bikesheddev/coredns/actions/runs/8619349018/job/23623824499#step:6:17

👩‍🏭 Creating new GitHub release for tag v1.11.2 using commit "01bded8194be73ce4601ad608a0464166cee932a"...
⚠️ GitHub release failed with status: 403
HttpError: Resource not accessible by integration
retrying... (2 retries remaining)
👩‍🏭 Creating new GitHub release for tag v1.11.2 using commit "01bded8194be73ce4601ad608a0464166cee932a"...
⚠️ GitHub release failed with status: 403
HttpError: Resource not accessible by integration
retrying... (1 retries remaining)
👩‍🏭 Creating new GitHub release for tag v1.11.2 using commit "01bded8194be73ce4601ad608a0464166cee932a"...
⚠️ GitHub release failed with status: 403
HttpError: Resource not accessible by integration
retrying... (0 retries remaining)
❌ Too many retries. Aborting...
Error: Too many retries.

I don't know the root cause of this error. But using the master commit or my tmp commit as workflow input works:

https://github.com/bikesheddev/coredns/actions/runs/8619437305/job/23624118432

https://github.com/bikesheddev/coredns/actions/runs/8619449474/job/23624161952

I suggest to use another tag/commit for release.

Edited:

Set permissions: write-all doesn't work:

https://github.com/bikesheddev/coredns/actions/runs/8626020717/job/23643835286

[orsenthil]

Since this issue related to a broken tag, should a new release be made from 1.11.3?
Creating this early release will help us the upstream k8s can be use 1.11.3 for the K8s 1.31 before the release freeze timeline.

[tedaford]

That's what's happening.

[BenTheElder]

[ connecting the dots ... 1.11.3 is tracked in #6638 ]

P.S. thank you all, coreDNS is great :-)

[fcolista]

Any update on this?

[tedaford]

Not yet. The version bump PR was merged, now a new release has to be "cut". So, any time now, a new release should happen