mholt

#!/bin/bash
# *As root*

cd ~
killall caddy
rm -rf ~/caddy
mkdir caddy && cd caddy
curl -SL 'https://caddyserver.com/download/build?os=linux&arch=amd64&features=hugo' > caddy.tgz
tar xzf caddy.tgz 

mholt

Date: Mon, 5 Oct 2015 16:34:03 -0700

Apache caches an OCSP response for one hour by default. Unfortunately, once the hour is up, the response is purged from the cache, and Apache doesn't attempt to retrieve a new one until the next TLS handshake takes place. That means that if there's a problem contacting the OCSP responder at that moment, Apache is left without an OCSP response to staple. Furthermore, it caches the non-response for 10 minutes (by default), so for the next 10 minutes, no OCSP response will be stapled to your

mholt

On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.

1. Support for keeping a long-lived (disk) cache of OCSP responses.

   This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server

mholt

// This program was used to build Caddy up to (but not including) v0.10.
// On April 20, 2017, it was replaced by a new releaser script that
// integrates with the autonomous build server. It bundles assets into
// an archive format that best fits the target OS. It could use `go build`
// to compile, but the way I configured it was to run the build.bash
// script that ensured the Caddy binary had proper version information
// embedded.
//
// I'm posting this here because it is no longer available in the Caddy
// repository and maybe you will find it useful for your own (simple?)

mholt

example.com

# specifying an empty root is not strictly necessary but not a bad
# idea if all you are serving on this site is the backups
root empty_www/

# authentication is required when using the Caddy plugin;
# this line assumes all requests are protected
basicauth / user pass

mholt

#!/bin/bash
FILES=$(find . -name "*.go" -not -path "./vendor/*" -type f)
 
for f in $FILES
do
	echo "processing: $f"
ed -s $f << EOF
0a
// Copyright YEAR YOU
//

mholt

// Package main is a sample macOS-app-bundling program to demonstrate how to
// automate the process described in this tutorial:
//
// https://medium.com/@mattholt/packaging-a-go-application-for-macos-f7084b00f6b5
//
// Bundling the .app is the first thing it does, and creating the DMG is the
// second. Making the DMG is optional, and is only done if you provide
// the template DMG file, which you have to create beforehand.
//
// Example use:

mholt

// checkPasswordPwned checks if the password is "pwned" according
// to the API offered by https://haveibeenpwned.com/. (The password
// is not sent to their servers to do the check.)
//
// This function returns the number of times the password appears in
// their data set. A password is pwned, or compromised, if the return
// value is greater than 0.
//
// API Docs: https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByRange
//

mholt

package main

import (
	"github.com/kardianos/service"
	"log"
	"flag"
)

type Service struct {}

mholt

Caddy 2 HTTP handlers come in two flavors: middleware and responders.

• Middleware are in the middle of a request chain; i.e. they have a next handler to invoke.
• Responders are content origins, at the end of a request chain; i.e. there is no next handler. Any handlers defined after it would not be invoked.

Caveat: Sometimes a handler's role is ambiguous. For example, a caching handler would be middleware on a cache miss (it needs to invoke the upstream handlers for a response, then cache it), but on a cache hit it would be a responder, since no further handlers would be invoked (it would simply write the response).