Graham Smith (Jun 09 2021 at 23:31): Graham Smith (Jun 09 2021 at 23:31):I have two unregistered packages on Github, say Stripes.jl and Tigers.jl where the latter depends on the former. The way I'm dealing with this now is to have a Tigers/setup.jl script that you run to dev the Stripes.jl repo before you build Tigers.jl. With recentish Pkg updates I thought I'd automate this with deps/build.jl or similar, but I can't figure anything out. My naive approach is to dev Stripes.jl in build.jl, but apparently Stripes needs to be registered (or dev'd) before the build file is run-- no build log is even produced before the error pops up (ERROR: expected package Stripes [310cc8c8] to be registered).
I'm working around this by including Manifest.toml in the repo, but that doesn't seem like a "real" solution. Maybe there's just no real solution since packages shouldn't automatically depend on unregistered/implicitly untrusted git repos?
Fredrik Ekre (Jun 09 2021 at 23:58):The best way is to just document that you need to install them in that order. Something like:
### Installation
In order to install this package you first need to install Stripes.jl
```julia
pkg> add https://github.com/username/Stripes.jl
pkg> add https://github.com/username/Tigers.jl
```
The best solution from a technical point of view is to register the packages in a registry of your own. It doesn't help at all with the trust issue though since the users would then also need to trust your registry.
Graham Smith (Jun 10 2021 at 19:43):A personal registry is exactly the solution I wanted. For anyone looking to do this in the future, LocalRegistry.jl makes this super simple (https://github.com/GunnarFarneback/LocalRegistry.jl).
Graham Smith (Jun 10 2021 at 19:45):(I see you're the person who wrote that, @Gunnar Farnebäck ! Thank you!)
j-fu (Jun 14 2021 at 19:54):Gunnar Farnebäck said:
The best solution from a technical point of view is to register the packages in a registry of your own. It doesn't help at all with the trust issue though since the users would then also need to trust your registry.
Is there any experience/advice how to handle trust issues regarding private/user maintained registries besides writing a documentation to make things transparent ? E.g. a RegistryDocumenter.jl ?
In particular I envision an "n+1" attack: someone re-registers a package from General with some backdoor with a higher version in his/her own registry and triggers users to add it by providing another "cool" package. Is there some automatism to prevent this ?
(LocalRegistry.jl indeed is great!)
Gunnar Farnebäck (Jun 14 2021 at 20:53):That goes under the name "dependency confusion" attack and is exactly the trust issue with adding additional registries. There have been discussions about mechanisms to counteract it but it's all somewhat complicated by the fact that Pkg is designed to allow migration between registries. Note that the problem is slightly mitigated by the fact that instantiating a Manifest doesn't bring in a new version just because it exists in the registry. The danger comes when you do a package update.
Last updated: Oct 02 2023 at 04:34 UTC