Secure dependency management

[evilrat]

On Monday, 6 January 2025 at 03:04:40 UTC, Chris Piker wrote:
> Here's what I ended up doing in case it's either useful for 
> others, or a really bad idea and serves as an anti-example.
>
> 0) For context, the working directory has roughly this setup 
> (after git submodule calls):
> ```
> git-root
>  |-- main_project
>  |-- deps/
>  |    |-- vibe-serialization
>  |    |-- ... more here
>  |
>  |-- makefile
> ```
>
> 1) Add dependencies as git submodules, for example:
> ```bash
>    git submodule add 
> https://github.com/vibe-d/vibe-serialization 
> deps/vibe-serialization
>    # more here
> ```
>
> 2) In the top level build file (makefile in my case) the 
> following happens:
> ```bash
>    dub add-local vibe-serialization 1.0.7
>    # More locals added here
>
>    cd main_project && dub --skip-registry=all build
>
>    dub remove-local vibe-serialization
>    # more locals removed here
> ```
>
> 3) On a regular basis:
> ```bash
>    rm -r $HOME/.dub
> ```
>   You never know what could be hiding in there.
>
> A person can just `cd main_project && dub build` and standard 
> things will happen, i.e. dependencies will be downloaded from 
> the internet.  However in a production setting `make` is run 
> from the top level and only the dependencies specified in the 
> sub modules are used.
>
> This should work *unless* two builds are happening at the same 
> time in the same account since `add-local` and `remove-local` 
> are **user-wide** and affect an entire user's home directory at 
> a time.  Not too bad if the user is a real person, *terrible* 
> if it's the account used by a build host.
>
> It works, but I'm sure there's a better way.


There is nothing wrong with your example, having two ways to 
build artifacts maybe confusing but this is just fine, except 
maybe that you should clearly state your intentions and name 
scripts/makefile accordingly (e.g. build_prod.sh/build_dev.sh or 
something, meaning that is it only going to work in specific 
environment because this is a part of specific procedure)

There is a problem with `dub add-local` though, it is only useful 
for developer on that same machine while tinkering with 
problematic packages. But this is an extra step that is easily 
can be forgotten leading to confusion.
I think it can be avoided entirely by simply setting explicit 
paths to dependencies in `dub.selections.json` (not suitable for 
library projects as you can't freeze version for your users), not 
sure if it will actually work with relative paths but I guess it 
should.

__dub.selection.json__:
```json
{
	"fileVersion": 1,
	"versions": {
		"godot-dlang": {"path":"C:/godot/bin/godot-dlang"},
		"intel-intrinsics": "1.11.18",
		"pyd": "~master"
	}
}
```