You are using an unofficial version of Debotnet.
ace2k opened this issue · 4 comments
I'm running nightly 0.6.221 and upon checking for updates, I get the error message:
You are using an unofficial version of Debotnet.
certUtil -hashfile output is:
certUtil -hashfile Debotnet.exe
SHA1 hash of Debotnet.exe:
e5e83d548768d4c4052cd7360326adf1da72c827
Is this intended behavior?
hmm, this is somehow strange.
The latest nightly build is 0.6.222 from yesterday 20:00 UTC. Please check again for updates an tell me whether you are informed about this new update.
Also be sure that you are on the nightly release channel if you perform a check for updates.
If you do the same on the stable channel (with a nightly release of 0.6.221), of course it would tell you that you are using "unofficial" release, because the latest stable is 0.6.2.
The channel was indeed set to nightly as shown on the screenshot.
Nevertheless I might have found the reason for that error message.
When I first downloaded Debotnet, I extracted it Desktop and ran it off %userprofile%\Desktop\debotnet-nightly, afterwards I renamed the folder and moved it to D:\Apps\Debotnet (as I expected it to be seemlessly portable) without modifying the settings, however OutputDir and WgetPath in debotnet-settings.txt were still pointing to the old nonexistent destination on the Desktop.
I deleted the [Wget] section from the config and restarted Debotnet, now the destination is correct for both vars and the check returns a positive result for a newer build.
It looks like the update check failure was caused by the invalid wget dir in the config, which begs the question, is there an actual reason to even change it? Do people prefer using their own build of wget located elsewhere instead, than the one delivered with Debotnet or what's the idea behind that particular config var?
Of course, this is also a reason 👍
Wget is the external downloader component of Debotnet and it also handles the update check,
If the path to Wget is no longer correct, then the update will not start correctly and unluckily reports that an unofficial version is used. Here is room for improvemet and yes you could set the wget config var to a location of your choice. E.g. you could put it to %windir%\system32 so it could be accessed globally.
E.g. you could put it to %windir%\system32 so it could be accessed globally.
That makes sense.
What do you think about a fallback to \bin\wget.exe when the custom location of wget returns a negative result?