Support Gitea: Codeberg as repository for registering dub package.

[BoQsc]

https://codeberg.org/
https://about.gitea.com/

[WebFreak001]

since gitea support is implemented right now, this should be easy to add - however we don't actually have a way to use the same repository provider multiple times from the config yet. I think it shouldn't be too hard to add though + it should also support short-form host versions

[ArthaTi]

Will you add just Codeberg or any Gitea provider? I self-host Gitea on https://git.samerion.com

[0xEAB]

or any Gitea provider?

I think we should not allow repos from arbitrary forges.

First of all, their internet connections may vary (in speed and reliability) – compared to well-known forges which tend to have pretty good peering.
The other thing is that I’m worried about opening us to potential attacks. For one, an attacker could try to waste resources by throttling the connection speed of their forge. And also, it opens the doors to supply chain attacks where a malicious actor would detect connections originating from the registry (maybe by IP, maybe by its access patterns, maybe through something else) and serve different data, modified to contain malicious payload, to those.

[ichordev]

I think we should whitelist hosts on a by-request basis with a brief review process. An unreliable connection is not the end of the world—in fact DUB is already so slow that I doubt most small or self-hosted forges would be any slower; and hypothetical attackers are not likely to even know about the process in the first place. This would make it much more accessible for people to self-host packages, which is important because people shouldn’t be forced to host their code (and have an account) on a commercial platform.

[0xEAB]

This would make it much more accessible for people to self-host packages, which is important because people shouldn’t be forced to host their code (and have an account) on a commercial platform.

On the front, I’d suggest to decentralize the registry too.
I suppose we could add an option to DUB that allows package recipes to specify the registry to use for looking up a particular dependency package.

"dependencies": {
	"vibe-d": "~>0.10",
	"code.dlang.org/mysql-native": "~>3.2",
	"dub.example.org/example-lib-foo": "1.0.1"
}

Compatibility and usability:
Packages with no registry specifier would default to code.dlang.org.

Prior art

This isn’t new tech: OCI container management tools (e.g. Docker) already provide such a mechanism. In the case of Docker it defaults to docker.io for packages with no registry specified.

[ichordev]

This would make it much more accessible for people to self-host packages, which is important because people shouldn’t be forced to host their code (and have an account) on a commercial platform.

On the front, I’d suggest to decentralize the registry too. I suppose we could add an option to DUB that allows package recipes to specify the registry to use for looking up a particular dependency package.

"dependencies": {
	"vibe-d": "~>0.10",
	"code.dlang.org/mysql-native": "~>3.2",
	"dub.example.org/example-lib-foo": "1.0.1"
}

Compatibility and usability: Packages with no registry specifier would default to code.dlang.org.

Prior art

This isn’t new tech: OCI container management tools (e.g. Docker) already provide such a mechanism. In the case of Docker it defaults to docker.io for packages with no registry specified.

Sounds great too. If Linux package managers can do it then why can’t we?

[ichordev]

however we don't actually have a way to use the same repository provider multiple times from the config yet. I think it shouldn't be too hard to add though + it should also support short-form host versions

@WebFreak001 has any progress been made on this?