tls

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

As noted in #14464, the randomisation used does not need to be cryptographically secure. Any form of randomisation is sufficient.

The project could implement a low quality but fast RNG for the purposes generating this kind of blinding material. There is an existing low quality RNG in impl_cache_flush_cache() in crypto/property/property.c which could be used more widely. There is another

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.

While less common, some users would like to set different passwords for the unlocking a Java keystore and the private key contained within.

Requested in jetstack/cert-manager#4186.

Describe the solution you'd like
Upgrade https://github.com/pavel-v-chernykh/keystore-go to v4.
Add support f

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

There are advantages to grouping commonly-used fields in structures together. On Cortex-M0, an access to the first 128 elements of a structure (p->x when offsetof(t, x) / sizeof(x) < 128 where sizeof(x) is 1, 2 or 4) uses less code than an access beyond this boundary. On platforms with a cache, putting commonly-used fields in the same cache line optimizes cache use.

Anecdotal evidence sug