Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forwarding user access tokens to mirrored private repos #2273

Open
traksag opened this issue Nov 2, 2024 · 1 comment
Open

Forwarding user access tokens to mirrored private repos #2273

traksag opened this issue Nov 2, 2024 · 1 comment
Labels
question Questions about project and how to use it

Comments

@traksag
Copy link

traksag commented Nov 2, 2024

Request details

Currently we're using Artifactory, but we're looking for an alternative that's lightweight, simple and less crashy. Reposilite seems like a good alternative, though it looks like we can't replicate our current setup with it. Our Artifactory setup is as follows:

  • Public repos that store public artifacts.
  • Private repos that store private artifacts.
  • A bunch of remote repos to mirror content from public external Maven repos.
  • The public virtual repo, let's call it all, that includes all of the above.

The point of the repo all is that we can slap it in the pom.xml of all our public and private projects to handle dependency management without any fuss. Artifactory will only allow access to our private artifacts if a user has valid credentials for the private repos, even if the artifacts are accessed through the repo all.

I've perused the documentation and other discussions on here, but it seems it's not possible to replicate this kind of setup in Reposilite? If I create a public repo in Reposilite that mirrors the private repos, it seems the private artifacts aren't available through it, even if a user with valid credentials for the private repos attempts to retrieve them. And if I set mirror credentials for the private repos, the private artifacts effectively become public through the mirroring repo.

In our case, users have access to all private repos or none, so I suppose we could create two separate repos all-private and all-public that mirror all private and public repos respectively. Then we can use those two repos in all our projects for dependency management. However, that's a bit less convenient than using a single all repo and also requires additional pom.xml editing if we ever add more fine-grained access control to the private repos.

It may also be worthwhile to note that some of our public projects depend on private artifacts. We're not legally allowed to host these private artifacts publically, but everyone can compile these JARs themselves. They're in a private repo so CI and our dev team don't need to compile them.

I don't know if there are plans to support this kind of setup or if you would be willing to support this kind of behaviour. I'm up for attempting a pull request that implements it. I've also noticed there's a plugin API, though I haven't really looked into it. Is it possible to implement this kind of thing with a plugin?

@traksag traksag added the triage label Nov 2, 2024
@dzikoysk dzikoysk removed the triage label Nov 23, 2024
@dzikoysk
Copy link
Owner

Currently, we don't support mirroring user's credentials. The reason behind it is quite simple - it's a relatively simple way to leak credentials to 3rd party repositories, and there's no straightforward workaround for that right now. Of course, in the mirror config, you can set credentials to the private repo that will be just shared between all users.

In general, I think it'd be safer if you'd just keep these repositories separated. As long as it might be not that convenient, it should be healthier from the security perspective.

I don't know if there are plans to support this kind of setup or if you would be willing to support this kind of behaviour. I'm up for attempting a pull request that implements it.

I'm currently shifting my priorities into 4.x, so I'll most likely not handle it on my own. If you'd like to explore it on your own, feel free to take a look at it. Even if it'll require too many changes on our side, you could just use your fork. We don't expect many changes in the 3.x, so it should be fairly simple to sync it with master from time to time.

I've also noticed there's a plugin API, though I haven't really looked into it. Is it possible to implement this kind of thing with a plugin?

Speaking about the plugin API - you can sneak in your own implementation, ResolvedFileEvent would be the first candidate there:

  • private fun findFile(accessToken: AccessTokenIdentifier?, repository: Repository, gav: Location): Result<Pair<DocumentInfo, InputStream>, ErrorResponse> =
    findDetails(accessToken, repository, gav)
    .`is`(DocumentInfo::class.java) { notFound("Requested file is a directory") }
    .flatMap { details -> findInputStream(repository, gav).map { details to it } }
    .let { extensions.emitEvent(ResolvedFileEvent(accessToken, repository, gav, it)).result }

Of course, in case of any API limitations, we can for sure add more events as it usually costs us nothing.

@dzikoysk dzikoysk added the question Questions about project and how to use it label Nov 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Questions about project and how to use it
Projects
None yet
Development

No branches or pull requests

2 participants