ssl

Checklist

• Dependencies installed
• No typos
• Searched existing issues and docs

Issue Description

When using the RateLimiter Middleware with a rate between 0 and 1 all events will be rejected instead of applying the specified rate. E.g.: e.Use(middleware.RateLimiter(middleware.NewRateLimiterMemoryStore(0.5)))

I am not saying that it is a common use case to have

Context and Description

The READMEs and any example code in all projects should be updated to reflect the move from the IBM-Swift organization to the Kitura organization.

If anyone wants to take on all or part of this, please comment here so other's know what you're working on and submit PR's. :-)

Thanks!

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)

When closing the browser after a successful user sign in, the session is still alive for the time the oauth2-proxy cookie has not expired and tokens in session are still valid.

Expected Behavior

There could be an additional "browser session enabled" configuration. When the browser is closed (or when the browser defines the "current session" ends), the oauth2-proxy user session should also

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.

Suggested enhancement

When MBEDTLS_USE_PSA_CRYPTO is enabled, a new API function, mbedtls_pk_setup_opaque() is made available to allow the user to wrap a private key held by PSA into a PK context - this allows passing the PSA-held key to existing TLS and X.509 APIs that expect a private key (as a PK context, not a PSA key identifier) without modifying those APIs.

That feature current