Move library code to its own repo and go module "stlib"
Some benefits of a separate library package (to be weighted against the cost of refactor):
- Keep stboot smaller, and make its dependencies easier to manage (assuming we can apply some hygiene also to indirect dependencies).
- Separate versioning of stboot and library packages. E.g, it may be confusing for users if we bump stboot version just because we're adding a library feature only needed by other st-related tools.
- We get a natural place to keep implementations and docs of st interfaces together.
There are a couple of known issues in the exported interfaces of the library parts of stboot (e.g., extra pointers in config types). If we're going to rework those parts, it's not that great extra cost to move the code out of stboot in the process.
What should be in stlib?
Mainly, the implementation of st interfaces, e.g., trust policy, host config and os packages. It's also tempting to put any shared utility code in this library, e.g., networking code needed by both stboot and stprov. To guide such decisions, consider if utilities really provide logic unique to stboot (rather than convenience wrappers for other packages), and design utilities so they really reduce the application's need to know st details.
We should be conservative in dependencies. When one st tool, e.g., stmgr, needs a large or complex dependency, try to not put stlib on the dependency path. If stlib needs to interact with something rather complex, e.g., if we keep the dependency on go-tpm for the measurements specified by st docs, consider defining an interface representing the needed facility, but leaving the implementation and its dependencies out of stlib.