Thread overview
Dependency Confusion Attack - Dub affected?
Feb 11, 2021
Jacob Carlborg
Feb 11, 2021
Andre Pany
Feb 12, 2021
Kagamin
February 11, 2021
I recently read this [1] interesting article. Would Dub affected by this? Based on what I could find in the Dub documentation, it looks like Dub would **not** be affected. According to the documentation Dub will try custom registers first, is that correct?

[1] https://www.bleepingcomputer.com/news/security/researcher-hacks-over-35-tech-firms-in-novel-supply-chain-attack/

--
/Jacob Carlborg
February 11, 2021
On Thursday, 11 February 2021 at 13:05:33 UTC, Jacob Carlborg wrote:
> I recently read this [1] interesting article. Would Dub affected by this? Based on what I could find in the Dub documentation, it looks like Dub would **not** be affected. According to the documentation Dub will try custom registers first, is that correct?
>
> [1] https://www.bleepingcomputer.com/news/security/researcher-hacks-over-35-tech-firms-in-novel-supply-chain-attack/
>
> --
> /Jacob Carlborg

It is a good practice for companies to have all dub packages mirrored to an internal dub registry / maven repository and let the dub clients only connect to this internal registry.

In addition to security aspects, you can build your software even without an internet connection.

Kind regards
Andre
February 12, 2021
On Thursday, 11 February 2021 at 13:05:33 UTC, Jacob Carlborg wrote:
> According to the documentation Dub will try custom registers first, is that correct?

That's what most package managers do and it's not enough, see the author's post: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
February 12, 2021
On 2/11/21 8:05 AM, Jacob Carlborg wrote:
> I recently read this [1] interesting article. Would Dub affected by this? Based on what I could find in the Dub documentation, it looks like Dub would **not** be affected. According to the documentation Dub will try custom registers first, is that correct?

This is very interesting. There are many reasons to have alternate repositories for dependency management.

It would seem to me that the most logical way to fix this vulnerability is to specify in your dub config that all packages that start with "xyz_" or whatnot should only ever come from an internal server.

Perhaps a dependency can have a server prefix, and then if you don't have that server in your dub config, it errors. This way, your build system would have to opt in to finding those packages elsewhere.

-Steve