update version refrences to 0.8.x

[Marc-Gee]

Description

A few outdated 0.7.0 version references still existed in the ReadMe software verification instructions.
The outdated references tripped up some users. The '*' wildcard in the commands didnt cover it because it was still referencing a prior major version 0.7.x (not 0.8.x)

This pull request is categorized as a:

• New feature
• Bug fix
• Code refactor
• [x ] Documentation
• Other

Checklist

• I’ve run pytest and made sure all unit tests pass before sumbitting the PR

If you modified or added functionality/workflow, did you add new unit tests?

• No, I’m a fool
• Yes
• [ x] N/A

I have tested this PR on the following platforms/os:

• Raspberry Pi OS Manual Build
• SeedSigner OS on a Pi0/Pi0W board
• Other

Note: Keep your changes limited in scope; if you uncover other issues or improvements along the way, ideally submit those as a separate PR. The more complicated the PR the harder to review, test, and merge.

[kdmukai]

Since we're using wildcard asterisks anyway, why not just wildcard the whole version num?

gpg --verify seedsigner.*.sha256.txt.sig

[newtonick]

I agree with this. @Marc-Gee can you make this update to this PR?

[Marc-Gee]

Hi,
Today I tested the wildcard on the whole version number, and it does succeed when there is just one match to the wildcard. However I received a "BAD signature" reply from GPG verify when there are multiple version file sets in that directory which is my own default process for new SeSi version downloads. (Tested in Ubuntu 22.04)

Bad Signature result:

In my own workflow, I keep my previous version verified files in a seedsigner folder, and I download new version files into the same folder. If I was to now use a full wildcard as Keith suggested in the verify command, GPG verify now returns a "Bad Signature" result.

I assume that multiple matching signature files causes GPG to return the error on purpose because the user may not see that GPG verified a different version Sig file to what you expected it to, and then the user might then accidentally rely on an unverified Sig file. Which is unwanted behavior.

Hence I appreciate GPG's error result, (even though it displays the incorrect reason for the failure).

My typical process is to keep my prior SeSi version files in the same download folder for a few weeks until I am happy that the new version is working well. Hence after downloading the new version eg 0.8.0, the current version files (0.7.0) will still be in that same folder but the full wildcard verify command will result in the 'bad signature' result, and that is unwanted behavior.
The verify command functions as expected if the wildcard specified does not locate multiple matches.

To avoid GPG verify potentially finding multiple file matches (if other peoples process does follow my own) and thus producing an ill-described, false positive, and troubling error message ("BAD signature"), I suggest that we continue to use the current minor version number in the verify command. (gpg --verify seedsigner.0.8.*.sha256.txt.sig)

However, in further testing of Keiths idea, he has highlighted an additional impact for Version 0.8.5.
Since version 0.8.5 is the first release (in many years) to use x.x.5 version numbering (point release numbering), the GPG verify command will fail with 'Bad signature' if it finds both 0.8.0 and 0.8.5 files in the same download folder when executing --verify 0.8.* as there are now multiple matches to that wildcard.
This is new behaviour because it is the first time we are using the point release digit (x.x.5)
So I suggest that we need to remove the wildcard completely and specify the full current release/file version in the verify command (gpg --verify seedsigner.0.8.5.sha256.txt.sig).
This version specific method does require us to update the readme file for each point release in the future, but this is becoming easier to do as a specific 'find and replace'.

Anyone specifically targeting to run a prior software version is probably experienced enough to edit the verify commands by themselves, and so I feel the wildcard has now become unnecessary.

If our users have a different update process to mine, and they wont have their current version and the new version saved in the same download folder, then a full wildcard would work successfully, but I suspect many users will get the error if we use the full wildcard method because they will very likely have both/many versions downloaded into the same folder.

I remain open to any further suggestions.
Once we have made a decision on this specific wildcard, possibly there are 1 or 2 other wildcard references that should be edited also. I can then rapidly review if the wildcard should be kept/removed from anywhere else in the readme file.

M.

[newtonick]

My preference is to use the wildcard for both major and minor versions (ie seedsigner.*.sha256.txt.sig). I'm also okay with having the documentation being version specific (ie seedsigner.0.8.5.sha256.txt.sig). I don't think it makes sense to only have wildcards for minor versions.

[kdmukai]

ACK, though fully wildcarding the version num (mentioned above) seems preferable.