Secure dependency management

Chris Piker chris at hoopjump.com
Mon Jan 6 03:04:40 UTC 2025


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.


More information about the Digitalmars-d-learn mailing list