lcert_verify.serve

An HTTP verification service — standard library only, no dependencies.

Some teams will not add a Python dependency to a signoff flow but will call an endpoint. This is that endpoint. It runs the same verifier, reaches nothing but the request body, and writes nothing outside a temporary directory it deletes.

The status code carries the verdict, so a naive caller cannot misread it. That is the whole design. A service that returned 200 with {"verdict": "UNVERIFIED"} would let if response.ok: treat an abstention as a pass — the exact failure this project exists to prevent, in HTTP form. So:

=========================== ====== =============================================== Verdict Status Why that code =========================== ====== =============================================== VERIFIED, VERIFIED-VACUOUS, 200 the check was made and it stood INTERNALLY-CONSISTENT UNVERIFIED 428 Precondition Required — the anchor is a missing precondition, not a failure of the bundle REFUTED, VACUOUS 422 Unprocessable Content — the artifact was read and does not hold up too large / malformed 413/400 not a verdict at all =========================== ====== ===============================================

428 is deliberate rather than 4xx-generic: RFC 6585 defines it for a request that must be made conditional, and supplying the out-of-band fingerprint is exactly that condition.

Endpoints:

GET /health liveness, and the version GET /scope what is and is not checked, verbatim POST /verify a bundle, as a zip (the whole directory) or as a bare bundle.json. Bundles with payload files must be zipped, because a single document cannot carry them; posting one bare then fails its own manifest, and the reply says so.

MAX_BODY = 268435456
STATUS = {'VERIFIED': 200, 'VERIFIED-VACUOUS': 200, 'INTERNALLY-CONSISTENT': 200, 'UNVERIFIED': 428, 'VACUOUS': 422, 'REFUTED': 422}
def status_for(verdict: str) -> int:
class Handler(http.server.BaseHTTPRequestHandler):

HTTP request handler base class.

The following explanation of HTTP serves to guide you through the code as well as to expose any misunderstandings I may have about HTTP (so you don't need to read the code to figure out I'm wrong :-).

HTTP (HyperText Transfer Protocol) is an extensible protocol on top of a reliable stream transport (e.g. TCP/IP). The protocol recognizes three parts to a request:

  1. One line identifying the request type and path
  2. An optional set of RFC-822-style headers
  3. An optional data part

The headers and data are separated by a blank line.

The first line of the request has the form

where is a (case-sensitive) keyword such as GET or POST, is a string containing path information for the request, and should be the string "HTTP/1.0" or "HTTP/1.1". is encoded using the URL encoding scheme (using %xx to signify the ASCII character with hex code xx).

The specification specifies that lines are separated by CRLF but for compatibility with the widest range of clients recommends servers also handle LF. Similarly, whitespace in the request line is treated sensibly (allowing multiple spaces between components and allowing trailing whitespace).

Similarly, for output, lines ought to be separated by CRLF pairs but most clients grok LF characters just fine.

If the first line of the request has the form

(i.e. is left out) then this is assumed to be an HTTP 0.9 request; this form has no optional headers and data part and the reply consists of just the data.

The reply form of the HTTP 1.x protocol again has three parts:

  1. One line giving the response code
  2. An optional set of RFC-822-style headers
  3. The data

Again, the headers and data are separated by a blank line.

The response code line has the form

where is the protocol version ("HTTP/1.0" or "HTTP/1.1"), is a 3-digit response code indicating success or failure of the request, and is an optional human-readable string explaining what the response code means.

This server parses the request and the headers, and then calls a function specific to the request type (). Specifically, a request SPAM will be handled by a method do_SPAM(). If no such method exists the server sends an error response to the client. If it exists, it is called with no arguments:

do_SPAM()

Note that the request name is case sensitive (i.e. SPAM and spam are different requests).

The various request details are stored in instance variables:

  • client_address is the client IP address in the form (host, port);

  • command, path and version are the broken-down request line;

  • headers is an instance of email.message.Message (or a derived class) containing the header information;

  • rfile is a file object open for reading positioned at the start of the optional input data part;

  • wfile is a file object open for writing.

IT IS IMPORTANT TO ADHERE TO THE PROTOCOL FOR WRITING!

The first thing to be written must be the response line. Then follow 0 or more header lines, then a blank line, and then the actual data (if any). The meaning of the header lines depends on the command executed by the server; in most cases, when data is returned, there should be at least one header line of the form

Content-type: /

where and should be registered MIME types, e.g. "text/html" or "text/plain".

server_version = 'lcert-verify/1.0.0'
def do_GET(self):
def do_POST(self):
def log_message(self, fmt, *args):

Log an arbitrary message.

This is used by all other logging functions. Override it if you have specific logging wishes.

The first argument, FORMAT, is a format string for the message to be logged. If the format string contains any % escapes requiring parameters, they should be specified as subsequent arguments (it's just like printf!).

The client ip and current date/time are prefixed to every message.

Unicode control characters are replaced with escaped hex before writing the output to stderr.

def make_server( host: str = '127.0.0.1', port: int = 8080) -> http.server.ThreadingHTTPServer:
def main(argv=None) -> int: