Typical security issues in C++: why the GC isn't your enemy

[H. S. Teoh]

On Thu, Dec 15, 2022 at 03:19:12PM +0000, Siarhei Siamashka via Digitalmars-d wrote:
[...]
> Any serious organization relying on DUB packages would have their own
> local mirror of this stuff

How easy is it to create a DUB mirror?  Perhaps that's one area of
improvement. Ideally it should be as easy as `dub clone-repo`, though in
practice of course that would be much more involved than that.


> and also pin all dependencies to specific commit hashes rather than
> version tags (after reviewing the code, checking digital signatures,
> etc.).
[...]

Tying dependencies to commit hashes instead of version tags is a good
step forward.  It's not 100% foolproof, though, no thanks to the SHA-1
collision attack. (It's extremely unlikely, of course. But in theory
it's possible that a malicious actor could have generated a repo
containing the innocent half of a colliding pair and substituted it with
the malicious half afterwards. Though probably it's not worth thinking
about, unless your project happens to be a sensitive security-related
one where the risk of being targeted by a sophisticated attacker is
high. In which case you probably wouldn't be using random packages from
a DUB repo in the first place. :-P)

Having said that, though, if you're going to be tying dependencies to
specific hashes, might as well just graft the dependencies into your
source tree instead.  Then you could just `git checkout` some branch or
tag and be 100% assured that it will build successfully, and that the
build products will be 100% identical to the last time you built that
branch or tag.  Reproducibility is a critical factor in debugging --
nothing like trying to chase down a bug only to have it vanish from
under you because some random upstream repo decided to upgrade their
package in the middle of your debug session.


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth