Hi @cpu, I’d like to request an update of the publicsuffix-go dependency in boulder.
I’m curious if the process of updating the dependency (along with running the tests, opening the PR, etc) has been automated? If not, I would be happy to help do that to make this easier in the future.
It hasn’t. We haven’t talked about it much within the team but I’m somewhat against the idea of automating the update of the library itself. It may be better to change the implementation to support live-reloading of new PSL contents on a fixed interval. We use godep right now to manage vendored dependencies and it can be extremely fickle even when used manually.
This is mostly one of those places where the pain of the awkward manual approach is infrequent enough that we haven’t been able to divert resources to fixing it compared to other things
When we initially switched from using the copy of the PSL in the Go standard lib to Weppos’ publicsuffix-go library one of the appeals (If I remember correctly) was that the library also supported transitioning to having a process where the raw PSL list can be updated alongside Boulder as a file on disk and live-reloaded by publicsuffix-go/Boulder. We haven’t made any progress towards implementing that and presently use the copy baked into the library. I feel like this path would be a better long-term solution.
I started a branch of boulder locally to try some things out. Am I right in assuming the docker container created is used to deploy into production? It looks like it contains an entire copy of the source tree.
I’m trying to figure out where to vendor a copy of the psl itself, and if there’s a stable path I can use during runtime to find it (which works in dev/test/production). One option would be to rely on GOPATH and read the file from $GOPATH/src/github.com/letsencrypt/boulder/psl/public_suffix_list.dat. Thoughts?
For dev/test you can put a test file in test/ somewhere like we do with the example rate limit YAML file. Our operations team manages config/Boulder state outside of the repo using their own process management systems and would update the config files used to point to wherever they decide to put the PSL data.
Does that make sense? I apologize because all of this should be in an issue on the Boulder repo instead of in my head