Build should not require the world

[mokraemer]

current build process requires a lot of packages and their subpackages. It should be possible to build only the needed backends and tools. E.g. if you never sync files to azure, or aws, why does it include all those services?

The classic configure/make command did check or make it available via command line switch to disable tools you don't want to. The compilation gets more complex and the number of errors rises.

[mokraemer]

At least the number of required packages should be revised. Please keep in mind, that this software is likely to be run with root priviledges. I wouldn't say all the requirements are trustworthy.

[MichaelEischer]

At least the number of required packages should be revised.

Except for a few small packages there is nothing we could remove without also removing functionality.

I wouldn't say all the requirements are trustworthy.

That is an interesting statement. How do you arrive at that assessment? What would be the point of keeping untrustworthy requirements in the code base?

[mokraemer]

Except for a few small packages there is nothing we could remove without also removing functionality.

True, but maybe you can make it optional. So building this package has options, e.g. remove aws, ... so just for local backups, the reuirements are much less. If you add more and more backup targets, the requirements increase, even if it is unused.

That is an interesting statement. How do you arrive at that assessment? What would be the point of keeping untrustworthy requirements in the code base?

Simple - it is too much code which might be executed with root priviledges and is not directly controlled by this software. As other packages have dependancies too. It would be a good idea to split up the backup and the transfer process. Just have minimal process gathering or writing back the files and drop priviledges for the transfer.

[fd0]

Thanks for the suggestion. While I agree in principle, I don't see that we have the resources to do this.

Here's an article explaining the difficulties arising with optional dependencies: https://michael.stapelberg.ch/posts/2019-05-23-optional-dependencies/

If you want to use less code, you can build restic yourself and remove all backends that you don't need. But this is something you would need to do yourself.

[mokraemer]

Thanks for that article, I'm aware of configure/make and ifdef's in c like environments.
In general that article is correct. If the configuration just enables/disables modules like backends, it is very unlikely this changes the behaviour or introduce many errors.

FYI: I've packaged 0.14 for a linux distro. but the latest release (0.15) has again more and more packages that needs to be imported just for compilation. And tbh I'm not familiar with go

[MichaelEischer]

It would be a good idea to split up the backup and the transfer process. Just have minimal process gathering or writing back the files and drop priviledges for the transfer.

Such a separation is sort of already available using the rclone backend. Using the -o rclone.program=... option you can specify a wrapper that could run rclone with reduced privileges.

Simple - it is too much code which might be executed with root priviledges and is not directly controlled by this software.

Except for code run on initialization, the code included by the libraries only runs when used.

I've packaged 0.14 for a linux distro. but the latest release (0.15) has again more and more packages that needs to be imported just for compilation.

0.15 has switched the Azure SDK and removed quite a few external libraries in the process. And the profiling library has introduced a few new dependencies, but those shouldn't be necessary for release builds. The overall increased length of the go.mod file is a result of changes in the go build system, but that is merely a different presentation of the already included dependencies. Besides that there are only a few smaller changes and lots of library updates.

I expect that the amount of library churn is less for the next release, but that is hard to know in advance.

[oregonpillow]

I don't see this as an issue. If you're unhappy with the amount of package dependencies and/or their trustworthiness, then create a Docker image with everything installed and build the binary in the container. Or instead of building it yourself, download the binary here and verify the SHA sums match. Restic provides a binary for pretty much all architectures.

[mokraemer]

that is not suiteable for build processes on e.g. linux distros.

And the main problem, you have to trust each repo and their dependencies is still present.

[greatroar]

And the main problem, you have to trust each repo and their dependencies is still present.

For Linux distros, that's not a problem because they'll mirror the packages anyway. Otherwise, the module proxies take care of this.