Feature request: self-update

[fw42]

urlscan-cli update to download the newest release of urlscan-cli and replace it with the current one (overwrite the current binary in place).

See https://pkg.go.dev/github.com/minio/selfupdate#section-readme for example.

Restic is an example of a Go program that has this feature and it's very convenient, imho.

cc @heipei

[fw42]

Claude uses it too:

It looks like your version of Claude Code (1.0.9) needs an update.
A newer version (1.0.24 or higher) is required to continue.
To update, please run:
    claude update
This will ensure you have access to the latest features and improvements.

[heipei]

Would be nice to have for sure!

[ninoseki]

I'm not a big fan of this idea since I want to do brew upgrade/winget upgrade to update all the packages at once.

Doing

tool_a update
tool_b update
tool_c update
...

is bothering.

Thus I think it's better to work on packaging (Homebrew, Winget, etc.) rather than self-update.

[fw42]

Why not both?

[ninoseki]

I haven't checked how the plugin manager works but does't it have a conflict?

brew install urlscan-cli
# doesn't it cause a conflict?
urlscan-cli udpate

Also I think self-update is almost meaningless if it's possible to update through a package manager.

[fw42]

Not everyone uses a package manager.

I thought the point of having this be a single go binary with no dependencies was that people can just download that binary from GitHub or whatever and NOT have to use a package manager. The whole point of package managers is to manage dependencies.

Not saying we shouldn't offer this through package managers to people who prefer to use it that way. But the person who just uses wget to get the binary onto some Linux box (that they might not even have root access on!) will be happy to have an auto-update feature.

[ninoseki]

Okay but I still think it's low priority & packaging is more important.

How about doing this after this once tool gets some installations & we start updating it constantly.

[heipei]

Sounds like a good plan!

[cdnsyseng]

If we have the binary support an update flag to self-update, then we should sign the binary builds and verify them. Otherwise this is ripe for a supply-chain compromise.

[ninoseki]

Yeah that's one of reasons I'm reluctant to do this.
selfupdate can have checksum verification but how to propagate valid checksums is a problem.
https://pkg.go.dev/github.com/minio/selfupdate#hdr-Checksum_Verification

[fw42]

Can you explain what the attack scenario is that you're worried about? If the binary is hosted on GitHub and being downloaded via HTTPS (but not doing any separate code signing or checksum verification), what's the threat?

I'd look at what restic does in their auto-update feature. I have a lot of trust in the author of that project (Jojo and me went to school with him) and he has probably thought through these kinds of things already.

[fw42]

Are you worried about someone getting access to our GitHub account and uploading compromised binaries to our GitHub repository? Isn't that already a problem without the selfupdate feature?

[cdnsyseng]

Can you explain what the attack scenario is that you're worried about? If the binary is hosted on GitHub and being downloaded via HTTPS (but not doing any separate code signing or checksum verification), what's the threat?

Sure, the attack scenario I have in mind is if someone has a DNS server responding with malicious github.com responses, or there is a BGP hijack to some of GitHub servers (not that likely, but it can and does happen). Package repositories typically have a signature file and packages are signed. If the package doesn't match what's in the keyring, it doesn't get installed.

For a cyber security company, we should try to [reasonably] harden our official client against these kind of attacks. Automatic updates are a gateway for someone to install malware on the client's computer and that's really bad news.

Are you worried about someone getting access to our GitHub account and uploading compromised binaries to our GitHub repository? Isn't that already a problem without the selfupdate feature?

If someone gains access to urlscan GitHub enough to publish a malicious urlscan-cli release, we have bigger problems (like, they just walked away with the entire org codebase).

[cdnsyseng]

Restic is verifying the signature of the downloaded file: https://github.com/restic/restic/blob/master/internal/selfupdate/verify.go

Check for the binary done here: https://github.com/restic/restic/blob/master/internal/selfupdate/download.go#L131-L150

So they're computing the sha256 of the binary and then signing the sha256sum file to prevent modification. They verify the signature of the sha256sum file and then verify the downloaded binary sha256 matches the hash in the file. The only way to defeat this check would be to find a sha256 collision or compromise their signing key.

[fw42]

How does a BGP or DNS attack get around not having a valid SSL cert for github.com?