keeping fingerprints up to date

wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented 2 weeks ago

would it make sense to also save (copy the embedded fingerprints file) the fingerprints to ~/.config/subsnipe/ if possible (e.g. if not running in docker) and before exiting the program, verify that there is no newer fingerprints version?

or have some sort of logic like that, otherwise there is a risk of using out of date fingerprints and virtually no way of updating them (beyond version bumping and having users pull the new version).

wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented 2 weeks ago

the file could also be date-versioned (fingerprints-yyyy-mm-dd-hh-mm-ss) or something...

the application running in a container would:

either need to have a persistent volume available for writing (configurable via let's say SUBSNIPE_CONFIG_DIR - which could default to $HOME/.config/subsnipe - if $XDG_CONFIG_DIR was not available, which wouldn't be inside the usual container),
or keep trying to pull fresh fingerprints before each run, whichever is deemed better.

dub-flow commented 1 week ago

Yeah, the way the fingerprints work isn't great at the moment. I also realized this week that if you download the compiled binary from GItHub and fingerprints/can-i-take-over-xyz_fingerprints.json doesn't exist in the directory of the binary, then the tool would simply not work 😃. But I fixed this now.

I've also been thinking about a good way to keep the fingerprints file updated on clients' machines. As you're saying, the only time it's getting updated is if I push the latest version.

If the only reasonavble way is to check for updates every time the tool is run, then we should probably just get rid of the fingerprints file and just take the latest version from https://github.com/EdOverflow/can-i-take-over-xyz at the beginning of the program.

dub-flow commented 1 week ago

Ah right, I remember now why I didn't want to do this. I was worried about what would happen in the (unlikely) case where the maintainer of https://github.com/EdOverflow/can-i-take-over-xyz takes down the repository.

wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented 1 week ago

Ah right, I remember now why I didn't want to do this. I was worried about what would happen in the (unlikely) case where the maintainer of https://github.com/EdOverflow/can-i-take-over-xyz takes down the repository.

Hi, that's a reasonable scenario, which could be handled.

This could also be configurable - check by default, flag or config option to disable.

One thing though, it wouldn't probably hurt to inform the user briefly that the app is checking for latest fingerprints, and then that the check yielded no changes/new fprints/could not connect/repo down (404) or whatever the result.

On slow internet the informative message could improve UX dramatically.

And you could fall back to the saved/cached (in .cache/subsnipe or rather .local/share/subsnipe for persistence) version of the file if the check was either not successful or no new fingerprints were downloaded...

dub-flow commented 5 days ago

One thing though, it wouldn't probably hurt to inform the user briefly that the app is checking for latest fingerprints, and then that the check yielded no changes/new fprints/could not connect/repo down (404) or whatever the result.

True, need to add some proper logging around that.

On slow internet the informative message could improve UX dramatically.

And you could fall back to the saved/cached (in .cache/subsnipe or rather .local/share/subsnipe for persistence) version of the file if the check was either not successful or no new fingerprints were downloaded...

Hmm, the JSON file is around 30 KB, so I think it would be reasonable to just download it every time. I kinda want to try to avoid dropping files on disk if it's not absolutely required.

So the way it is now is that the fingerprints file is baked into the docker image and the compiled binary. I'm wondering if we even should check for a newer version when the tool is run via docker of the compiled binary. Maybe it's best to only check for the update if the tool is run by developers via go run .. And then, if a new version of the fingerprints file exists, it will be committed into the repo and shipped as part of the next release.

In the last half a year or so, the fingerprints file hasn't changed at all IIRC, so I think this might be reasonable. What do you think?

dub-flow / subsnipe

keeping fingerprints up to date #7