Updates to https://github.com/zmap/zcrypto/commit/ea3fdbd5ea270b7309385ea8a4148ba27a110e2a ahead of cutting a minor release.

Diff since current version (efd761a7b7b0): https://github.com/zmap/zcrypto/compare/efd761a7b7b0..master

dyn Connection was my original plan but AFAICT I can't downcast a dyn Connection to ServerConnection or ClientConnection. If I'm wrong about that, that'd be great!

Example in the Rust playground that (I think) implements the same behavior as these methods. It works with unsafe, but don't pass the Miri checks. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8cb8a4507c42d86f6efd8a81d31f89d6

Came here to file the same issue for process_vm_readv, which has the same problem. IANA expert, but I started digging into this when I was writing a wrapper for process_vm_readv, and found I couldn't have it take &&mut [u8] without using unsafe to coerce pointers, and doing so would cause Miri to flag it as UB.

The language docs on interior mutability seem pretty clear that the current implementation is UB. https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#interior-mutability

... for certonly and renew. Other verbs aren't affected.

I don't think the Could not choose appropriate plugin: ... message adds any meaning to the error.

certonly before:

certonly after:

renew before:

renew after:

While reasoning through this I realized that I only yanked this from the writeup that @jcjones did because I wanted a future engineer to avoid introducing the off-by-one error present in the original query. However, we've got tests for that. We can just get rid of this.

@jcjones should probably be the one to address why this query is safe / acceptable though.

Nope. Just make sure SRE treats the whole config as a secret when they deploy it.

What would you like to be added

Per https://github.com/smallstep/certificates/blob/5a6517ca5b963e09e5d9cc66b66521cc71c6483e/authority/provisioner/oidc.go#L34 and https://github.com/smallstep/certificates/blob/5a6517ca5b963e09e5d9cc66b66521cc71c6483e/authority/provisioner/oidc.go#L195 a jwks_uri needs to be provided.

Why this is needed

Current OIDC provider does not provide jwks_uri in OIDC well-known endpoint, and only supports HS256 (can't be switched to RS256 either).

The well-known endpoint from oidc provider returns:

{
    "issuer": "https://example.com/",
    "authorization_endpoint": "https://example.com/login/oauth/authorize",
    "token_endpoint": "https://example.com/login/oauth/access_token",
    "response_types_supported": [
        "code",
        "id_token"
    ]
}

PS, ❤️ Thanks for Smallstep suite of OSS that you publish.

		`SELECT SQL_BIG_RESULT
		        cert.registrationID AS id,
			name.reversedName AS hostname

This comment is confusing because the "previous version" is not visible here. In general when putting a comment in place for the long haul, rather than phrase things in terms of what used to be, it's better to phrase them in terms of "here's why we can't do it X way." In other words, think of the mental state of your future reader: They're not thinking about what the previous query looked like. They're thinking about how else they might implement it.

Also "undefined behavior" is pretty scary! Can you provide an explanation of why it's safe enough to use here?

I did a little more digging and there are in fact specific functions which can retrieve the trusted settings. (See here)

alias (friendlyName) -> X509_alias_get0 keyid (localKeyID) -> X509_keyid_get0

In particular X509_alias_get0 is already included in cryptography so as a temporary hack @felixfontein it would be possible to do the following:

from cryptography.x509 import load_pem_x509_certificate
from cryptography.hazmat.primitives.serialization.pkcs12 import load_key_and_certificates
from cryptography.hazmat.primitives.serialization import Encoding

with open('./any_pkcs12_file', 'rb') as p12:
    pkcs12 = load_key_and_certificates(
        p12.read(),
        password='password'.encode('UTF-8'),
    )

_, cert, _ = pkcs12

print(
    cert._backend._ffi.string(
        cert._backend._lib.X509_alias_get0(
            cert._x509, cert._backend._ffi.new("int *")
        )
    )
)

We should make sure to update the rate-limits page and do an API Announcement before updating the config in prod.

I wanted to add that a few months back I submitted a PR against the website for a complete overhaul of the rate-limits page (https://github.com/letsencrypt/website/pull/1167) that received a pretty good amount of review and revision. I closed it because I figured things were too hectic and there might be drastic changes needed later. Though I cannot reopen it, I still have the complete text ready to go. If you let me know the upcoming error-wording, I can incorporate this new rate limit and submit a new PR to have a shiny new limits page to go with the shiny new rate limit.