Fixes #3236 - Adding Maven Central fallback for gradle

[zendern]

Fixes #3236

By following what Maven ecosystem is doing by always adding Maven Central repo to the list.

[zendern]

Also uniq it here. Not sure if that is necessary but felt like having multiple possibly same repos was the wrong thing to do.

[xlgmokha]

Thank you for demonstrating a bias for action and for your enthusiasm in getting this resolved. From a quick glance of the changes this looks like a great start.

I have a couple of questions that I'd like to discuss and to collect some additional feedback on such as:

1. Is there a way to detect name squatting collisions?
2. Should falling back to public registries be a default behaviour or an opt-in option?

[zendern]

Thank you for demonstrating a bias for action and for your enthusiasm in getting this resolved. From a quick glance of the changes this looks like a great start.

I have a couple of questions that I'd like to discuss and to collect some additional feedback on such as:

1. Is there a way to detect name squatting collisions?
2. Should falling back to public registries be a default behaviour or an opt-in option?

1. Please say more about this, I'll be honest I'm not sure I follow. Are you saying in one public repo (let's say jcenter for example) someone has taken a package name version set and hijacked it but in maven Central it's a valid package??

2. Sure I'm happy to make this opt in but should maven follow the same behavior then as well??

[xlgmokha]

1. Please say more about this, I'll be honest I'm not sure I follow. Are you
   saying in one public repo (let's say jcenter for example) someone has taken
   a package name version set and hijacked it but in maven Central it's a valid
   package??

Let me try to provide an example for clarification:

Private registry: (https://acme.example.org/)

• package name: acme-logger
• package version: 0.1.0

Public registry: (https://repo1.maven.org/maven2/)

• package name: acme-logger (malicious package not owned by acme corp)
• package version: 0.1.1

In the example above an internal company package named "acme-logging" is
hosted and served from a private package registry. At the same time a package
named "acme-logging" is also hosted on a public registry with the same name
but owned by an entity not belonging to acme corp.

In this example, falling back to the public registry would produce
a pull request from Dependabot that suggests installing a malicious
package.

My question is to see how we might be able to identify and prevent
this behaviour.

More info can be found in Substitution attacks.

2. Sure I'm happy to make this opt in but should maven follow the same
   behavior then as well??

I like consistency. So if this is what we're doing with Maven today
then it would be great to make sure we align the behaviour between
the two.

I raised the question of what the default behaviour
should be to make sure the default is the less risky option.
However, this might also mean adding a way to opt in or choose a specific
behaviour.
If this is the default behaviour for how mvn and gradle behave then
perhaps this is less of a concern.
I'll need some input from other colleagues on this one.

I might be over thinking this but I'd like to try to prevent introducing
risky packages if possible.

Also, thanks for taking the time to consider the
different security implications. I'd like to see if we can find a way
to cater to the scenario resolved in this PR while also providing safe
defaults for everyone.

What do you think?

[zendern]

@xlgmokha Thanks for clarification. That makes sense as far as the attack vector goes. And I agree if we can figure out a way to do that or at least make the behavior opt in that would probably better.

I did find this while researching substitution/brandjacking attacks.

https://blog.sonatype.com/malware-removed-from-maven-central

When a new publisher comes along requesting access to publish to Central, the requirements enforce that you can verify control of either the DNS for the Group ID, or for control over the account/repo for coordinates derived from platforms such as GitHub. As a part of this screening, users are asked to verify their GitHub account before they are assigned a Group ID, such as ‘com.github.codingandcoding’, as is the ID in this case.

Sounds like maven central might make it a little harder to do b/c of the way it validates and requires Group ID. Similar to the article you linked using scopes with npm packages can help protect you there.

In my case and maybe others packages look something like so

<groupId>com.bigcompany</groupId>
<artifactId>custom-package</artifactId>

So you would have to prove you have DNS access to com.bigcompany or rights to github. Probably doable still just harder to do.

Opt-in still feels like maybe the right choice. With the findings below about how the dependency managers work below it might make sense to have maven behave like gradle and not fallback to central unless you opt in.

---

More information on why dependabot probably works the way it does for maven vs gradle.

I started by creating this branch in my test repo.

https://github.com/zendern/private-repo-dependabot-fail/tree/default-repo-setup

Where maven and gradle both have no repositories or plugin repositories defined. In the maven case with nothing defined its behavior is to default to maven central. In the gradle case it throws an exception b/c no repositories are defined.

So I'm guessing the "defaulting/fallback" for maven was to simulate that. But maybe the maven code should only "default/fallback" if no repositories are defined instead of always doing it??

[xlgmokha]

So I'm guessing the "defaulting/fallback" for maven was to simulate that. But maybe the maven code should only "default/fallback" if no repositories are defined instead of always doing it??

I'm checking to see if there is a way to specify opt-in behaviour via the dependabot.yml or if there's another way to do this. Meanwhile, I'm also looping in friends from security to make sure I understand the impact of using this as a default. I'll keep you posted as much as I can. Thanks for your patience @zendern.

[xlgmokha]

A review from friends in #security suggests that it would be best to avoid falling back to the public registries by default due to recent naming/typo squatting.

However, our roadmap has some exciting features related to better support for private registries. I think this may also cover being able to specify public registries as a fallback mechanism.

I appreciate the effort made to ship this idea. Unfortunately, we wont be able to accept this contribution at this time.

Thank you very much @zendern and keep them coming.

[zendern]

@xlgmokha cool. That's fair and I understand. I will close this pr. I assume with the support of private registries there would have to be line of sight from GitHub to that registry??

[xlgmokha]

I assume with the support of private registries there would have to be line of sight from GitHub to that registry??

Yep, that's right. Dependabot would need to be able to resolve the IP address for the private registry host and be able to connect to it with or without credentials. More details to come soon.