tls

It would be a nice addition to integrate Minimal windows service stub in Caddy (built for Windows).

At the moment, it is necessary to use for example NSSM to install Caddy as a service on Windows.

See how it becomes much more natural to [install the service and remove it in the case of another project (Gitea) with the Windows tools](https:

The crypto/bio/bss_dgram.c file has a number of strict aliasing problems. There are a number of definitions of a union:

    union {
        size_t s;
        int i;
    }

and a definition:

    union {
        unsigned __int64 ul;
        FILETIME ft;
    }

The concern is that the address is taken of a union member and this is passed to a function. This breaks th

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.

I've experienced intermittent issues with the k8s api-server reaching the cert-manager-webhook, or so I think. I wanted to understand and verify if the webhook received the requests or not, and sometimes it seems to work out.

The issue is that there is no logs for me to see this from the webhook pod, even with --v=6 set.

Which version are you referring to
3.1dev

We list not all RFCs in ~/doc/ which we refer to in testssl.sh.

List used RFCs: grep RFC -w ./testssl.sh | grep -v TLS_CIPHER | grep RFC | sed 's/^.*RFC/RFC/' | sort -u
List RFCs referred to: grep -w RFC doc/testssl.1

The recommendation is to set Cache-Control: private, no-store on any endpoint with sensitive information. Because while you can protect the traffic with TLS, you also need to keep sensitive information out of a client's (unencrypted) HTTP cache. I'm not sure how relevant this is to the API context of step-ca though—I've never seen an HTTP client library that caches content. But I guess the poi

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.