(lockhunter) Checksum outdated again

[corbob]

Checklist

• I have checked the moderation queue that no new version has been submitted (only visible when logged in), or the submitted package version has failed the automated checks.

Please navigate to the following link to view the moderation queue.

• I have verified that the new version is a stable release.
• I have looked to see if there are any Bug reports that prevents a new version being submitted and that no existing Outdated Reports have been created.
• I have verified the new version has a Windows binary (EXE or MSI installer, Zip or other archive, etc).

New Software Version

3.4.3

Download location

No response

Package Page

https://community.chocolatey.org/packages/lockhunter

[corbob]

The new checksum appears to be: CE9A8B33BC156E00F7FEA7EF40049A7DA0D4531243E7511A29B36D416B904914

This appears to need an update similar to #2228.

[corbob]

Actually, it looks like pauby already got this checksum, but it didn't push to Chocolatey Community Repository. I've pushed up a commit that if I'm understanding correctly will push the update next time it runs in about 45 minutes. I'll follow up with it tomorrow if it doesn't push today.

[AdmiringWorm]

The package had been pushed previously. However, it had been rejected, as such the push you attempted previously probably failed. I'll attempt to push this again.

[corbob]

Thanks for doing that @AdmiringWorm I looked, but didn't see the rejected version when I was logged in with my account. It looks like the install is timing out now. I have verified on chocolatey-test-environment locally that if I run vagrant winrm default -c 'choco install lockhunter --version 3.4.3.20230609' it too times out. Looking in Task Manager, I see a lockhunter.exe and two lockhunter_setup processes running. When I end process on the lockhunter.exe the setup processes then close. When I try it locally at the console, I end up with an Internet Explorer window opened to a "thanks for installing" page, but then it finishes installing. I suspect this is what's trying to happen when run under winrm, but not entirely sure.

Leaving this comment here partly because I can't leave a moderation comment on the package here

[AdmiringWorm]

@corbob the launching of the web browser is a common problem with lockhunter, but it has always been a non-blocking thing. Even through winrm (from what I can tell).

We would need more investigation on this one to figure out what is going on.

[corbob]

The behaviour is the same every way I try to replicate this, and when I remove Chocolatey from the mix. If I'm working from a headless session (WinRM or SSH), the LockHunter setup launches LockHunter.exe. It then sits around until it's terminated, in which case the setup exits. If I'm working interactively then setup launches the executable which seems to launch the default browser (IE on the Chocolatey Test Environment, and Edge on the Windows 10 VM I'm testing with). I can't say if this is something that's new with this version, or if it's always been there (the gists are gone, and I can't see the moderation comments for previous versions), but I can say that it has been consistent for me with this version.

[corbob]

Some discussion was had with the team. After that discussion, I attempted the same test with chocolatey-test-environment version 2.0.0 and 3.0.0. Under 2.0.0 (Windows Server 2012), there is no issue. But under 3.0.0 (Server 2019), this behaviour exists. It would appear to either be a change to chocolatey-test-environment, or a change to Windows itself.

[pauby]

This doesn't make sense to me. If it was a change to both of those, a lot more (all?) packages would be affected? Why just this one?

(I'm not suggesting you're wrong, just that it makes no logical sense.)