I'm managing a bunch of servers and they're running Caddy v2. The upgrade command works great for upgrading with the packages previously chosen. In the future, it's likely I'll want to add/remove packages from that list over time.

Would it make sense to add flags to add and remove packages from the caddy build on upgrade?

caddy upgrade --add-package github.com/caddy-dns/cloudflare

Just for RSA. Do encrypt and decrypt. Include a bold comment that this should not be used for bulk encryption.

It should be the current best practice (fetch), have proper error handling and resource allocation/deallocation and be in the style of a known answer test.

Right now in different places in the SE codebase there are references to /opt and then as well to /usr.

All SE code should reference one place only. Could someone please create a PR that fixes this.

This PR should also take PR #454 into consideration (no conflicts)

Is your feature request related to a problem? Please describe.

In order to address issue #3796, PR #3815 runs the e2e tests in series one after the other. It would be nice to run the tests in parallel again as that would lead to all the tests completing earlier.

Describe the solution you'd like

There's little information about what keys and values are in the output, what it means and how they are related to the screen output. In general that needs to be added. (special topics see #1675, #1674)

Problem:

A common pattern is:

GUARD(s2n_stuffer_skip_write(stuffer, bytes_to_write));
uint8_t* ptr = suffer->blob.data + stuffer->write_cursor - bytes_to_write;

which could be simplified.

Solution:

*ptr could be an *out parameter to s2n_stuffer_skip_write

• Does this change what S2N sends over the wire? No.
• Does this change any public APIs? No.

Description

If a provisioner cannot be accessed, e.g. OAuth server is down, allow step-ca to boot up with the remaining functioning provisioners. Probably this is already in the new management revamp but it's worth keeping an issue for this. @dopey could you confirm this?

Use case

This is part of my recent hiccups when bootstrapping a fully integrated server after a long power outag

In tests/suites/test_suite_gcm.function as of 8cad2e22fcfe0154f8f9d648cbec81e9fbd0d885 (which is on the way to 3.0, after #4342 but before #4567), the test function gcm_decrypt_and_verify only tests multipart operation if the expected result of decryption is a success. This is incomplete: it should also test multipart operation in the failure case.

We're still getting some coverage of multi