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.
Hi @tmm1,
ACK'd. I'll open an update pull-request today.
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.
Thanks @cpu! Indeed, publicsuffix-goadvertises the following feature:
Ability to load an arbitrary list at runtime (e.g. you can feed your own list, or create multiple lists)
Updating the .dat directly sounds a lot of more straightforward. I'll poke around some more and see if I can figure out how to make that happen.
Thanks @cpu!
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?
We don't use Docker in prod, that's strictly for a more convenient dev environment and for easier CI integration. Staging and Prod are installed from an RPM generated with a Makefile/fpm.
For this case I think you should look at the way we load the RA's rate limit policy YAML file. There is a config parameter, rateLimitPoliciesFilename that gets read from the config file by the RA cmd and used to call a method on the RA instance that sets up a reloader instance with a handler function that loads the ratelimit file contents.
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
I created an issue with the same details: Support live-loading public suffix data at runtime · Issue #3132 · letsencrypt/boulder · GitHub If you're interested in working on this would you be so kind as to comment on the issue so that we can coordinate who's working on what? Thanks!
It already is, according to the status site. 
https://letsencrypt.status.io/pages/maintenance/55957a99e800baa4470002da/59dd2967429e4b04d909858a
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
You should be all set.