Log message:
Revbump all Go packages after go122 update

Log message:
Revbump all Go packages after update

Log message:
Revbump all Go packages after go122 security update

Log message:
caddy: update to 2.8.4

v2.8.2

A few more fixes of reported bugs related to ARI, try_files with the root path
(/), and Caddyfile adapter detection on the CLI. See 2.8.0 release notes for
details on 2.8.

v2.8.4

Hotfix for the Caddyfile detection regression in v2.8.2. The v2.8.3 tag was
mistakenly made on the wrong commit and is skipped.

Log message:
Revbump all Go packages after go122 update

Log message:
caddy: update to 2.8.1

v2.8.1

Quick fixes for a few users related to directory permissions and matcher
parsing.

v2.8.0

Caddy 2.8 is here! With hundreds of improvements, Caddy is more scalable and
capable than ever before. Featuring ACME Renewal Information (ARI) support,
HTTP/3 to proxy backends, and so much more than we can list in a sentence, we
are pleased to bring you one of the biggest Caddy updates yet. Documentation on
our website will be updated in the coming days.

We've implemented a ton of improvements, fixes, and awesome new features based
on your feedback. While some of them aren't particularly visible changes, they
allow Caddy to scale better and be more reliable in demanding deployments. Many
of the changes are quality-of-life improvements we hope you'll appreciate. Then
there's improvements to ACMEz, CertMagic, and other dependencies which make
Caddy better that may not show up in this list.

There was a lot of code that had been documented as deprecated in place for a
long time, so this version introduces a few more breaking changes than usual;
please review the notes below.

As with any server upgrades, please be sure to test and validate your
configurations in a staging or test environment before deploying to production.
Thank you and have a great day!

Breaking changes:

  * ZeroSSL (this is one overall change, but requires some explanation):
      + Up to now, Caddy used both Let's Encrypt and ZeroSSL by default to get
        certificates without any configuration. In 2.8, this is changing
        slightly. Due to upcoming changes to ZeroSSL accounting policies,
        ZeroSSL now requires your email address to be able to access their free
        ACME endpoint.
      + As such, Caddy will only implicitly add the ZeroSSL issuer to your
        config if you provide an email address in your Caddyfile using the
        email global option. (We have already recommended this for years.) If
        you already do this, you don't have to make any changes and you'll
        still get Let's Encrypt and ZeroSSL automatically as defaults.
      + If you use JSON to configure certificate automation policies, you will
        need to ensure you use the acme issuer with your email filled out, and
        the ca field set to ZeroSSL's ACME server URL.
      + The zerossl issuer module is no longer ACME-capable and is now
        exclusively for the ZeroSSL API. An API key from your ZeroSSL account
        is required. (The ZeroSSL ACME server can still be used with the acme
        module pointed to ZeroSSL's ACME server. You can provide your account
        email and/or EAB as well.) If you were using the ZeroSSL issuer with an
        API key, it will now start using ZeroSSL's API, which was probably the
        expected behavior anyways. The API has several advantages over the ACME
        endpoint, but may require payment:
          o Faster response times
          o IP certificates
          o Management tools in your ZeroSSL account dashboard
          o Technical support
      + To clarify, Let's Encrypt is still a default issuer even if you don't
        provide an email address (but we have always strongly recommended to do
        so).
      + You can still use ZeroSSL's ACME endpoint with your own External
        Account Binding (EAB) credentials.
  * Removed support for the lego_deprecated DNS provider module. It has been
    deprecated for 4 years. Use caddy-dns modules instead; there are over 50 to
    choose from already. They are more flexible, compile much leaner, and are
    easier to implement and support. If yours is not supported it can be easily
    implemented. Sponsors at or above the Business tier can request to have
    their provider implemented for free.
  * On-demand TLS: The ask option in the JSON has been deprecated in favor of a
    permission module (Caddyfile unchanged), and Caddyfile support for
    permission modules is added
  * Admin API: Etag (used for concurrency control) is now a header, not a
    trailer. This is less efficient, but still virtually no clients properly
    implement trailer support.
  * For consistency, the basicauth Caddyfile directive has been renamed to
    basic_auth, and skip_log has been renamed to log_skip. The old names will
    continue to work for now, with a deprecation warning in the logs.
  * The basic_auth handler no longer supports scrypt (deprecated for nearly two
    years)
  * The forwarded option has been deprecated for a long time and has now been
    removed from the remote_ip matcher. Use the client_ip matcher instead.
  * Reverse proxy: The buffer_requests, buffer_responses, and max_buffer_size
    settings have been removed after being deprecated for 14 months. Use
    request_buffers and response_buffers instead if you need buffering.
  * Go API: If you called caddy.Context.AppIfConfigured(), it now returns an
    error, as part of a bug fix.

Log message:
Revbump all Go packages, default Go version is now 1.22.

Log message:
caddy: Use upstream PR to fix SunOS build.