Dra checks latest version installed

[chad-betamax]

I dunno if this is getting away a little from what dra is intended to be,,,

Could there be logic that looks to see if the binary is already installed?

Ideally dra would check the installed version was the latest version.... but the only two ways I can think right now to do this
would be
a) check timestamps on the binary - simple, foolproof but not very accurate
b) run the binary with --version flag and compare - accurate but now dra is executing the binary. Plus we can't guarantee it would have a --version flag (most would surely?)

[chad-betamax]

So after some googling.... there's firejail and bubblewrap. Both of which might be a whole other thing. Using a container doesn't feel right either.
All we need to do is grab the string that --version should put out. What about binaries we don't trust?

[devmatteini]

Hi! This was discussed in #207 if you want to check it out.

Can I ask you why do you need this behavior? What is your workflow when you use dra?

I'd like to gather more information to better understand the problem and how to develop a good solution

[chad-betamax]

My use case is broadly similar to #207 - I'm standing up my workstation with a command runner (https://github.com/casey/just)
and use dra within that process.

I'm looking to make the dra portion of this idempotent.

Something like
a) dra looks to see if binary is already installed
b) dra queries the binary for its version number and compares to what is on Github
c) dra decides to skip/proceed with downloading and installing

So I have x3 stanzas (of commands) in my just file (similar to a Makefile)

apt installs ... idempotent (apt uses caches)
curl installs - rust, just, dra ... idempotent (is the dra installer? can't remember) (these are installing known binaries)
dra installs - various stuff from various authors

however because dra is installing unknown binaries it means unknownbinary --version has the potential to be destructive.

I'm not sure it is reasonable/feasible to ask dra to guard against hostile binaries. It could be done but it would be a lot of work to do properly. Feel free to correct me.

The approaches used by apt (caching) or the rust installer (known binary) are not suited to dra (again feel free to correct me) as they would detract from dra's simplicity.

I could live with a) and c) ... would that be doable?

[devmatteini]

dra ... idempotent (is the dra installer? can't remember)

The installer will download dra each time.

however because dra is installing unknown binaries it means unknownbinary --version has the potential to be destructive.

This is not an option in my opinion as it's not secure to execute binaries like this. Also many tools do not follow the same CLI conventions of -V/--version.

The safest option I can think of is to keep track of the downloaded release of tools and compare them before downloading the asset.
Also, there should be some kind of --force/--yes CLI flag to override that mechanisms.

[chad-betamax]

This is not an option in my opinion as it's not secure to execute binaries like this. Also many tools do not follow the same CLI conventions of -V/--version.

Yes, agreed

The safest option I can think of is to keep track of the downloaded release of tools and compare them before downloading the asset.

Ok so that's a caching approach which would work. I think the functionality would be useful (certainly in my use case) - but does it fit in with the intent of dra, a simple downloader-installer (where simplicity is a feature/strength)

[devmatteini]

Ok so that's a caching approach which would work. I think the functionality would be useful (certainly in my use case) - but does it fit in with the intent of dra, a simple downloader-installer (where simplicity is a feature/strength)

Yeah, this is exactly the point. That's why I didn't implement it for now.

But I also think that it would be a good default feature to have.