Top
Best
New

Posted by birdculture 5 hours ago

Don't couple your Go code to GitHub(iain.rocks)
84 points | 42 commentspage 2
Meneth 1 hour ago|
You shouldn't be using fully qualified domains at all. Use relative paths instead, like sibling-hosted git submodules.
bionsystem 2 hours ago||
braid has been a treat for us to manage external dependencies. Much cleaner than submodules.
0xbadcafebee 2 hours ago||
Even better reason: you can later point this domain at an artifact registry. This not only gives you reliability and flexibility, it also secures your software supply chain. You don't need an SBOM or anything fancy to get started, just pull all your artifacts into a central source and improve it over time. Install an artifact registry anywhere you can run a container, use dumb static shared credentials, and start with "proxy mode". Later on you can pin or restrict versions, verify checksums, implement SSO, etc. This is going to become table stakes in the new security landscape.
prasadvara 2 hours ago|
You don't need an SBOM or anything fancy to get started

-- Curious how this avoids SBOM need?

skybrian 2 hours ago|
Not really convinced. I'd rather it stayed on Github so it doesn't disappear. Particular for businesses whose priorities might change.
racingmars 2 hours ago|
> I'd rather it stayed on Github so it doesn't disappear. Particular for businesses whose priorities might change.

People can delete projects from GitHub. Businesses whose priorities might change may not keep an old project set to public up on GitHub because they won't want people to continue contacting them for support, or they don't want to be responsible for updating security vulnerabilities for projects they are abandoning so they'd rather just pull it offline, etc.

Whether the library you're importing is hosted on GitHub or not, never assume it will be there tomorrow. *Always vendor your dependencies.*

skybrian 2 hours ago||
I believe they'd also be cached by proxy.golang.org? But companies should probably run their own proxy.