xmouse-controls
xmouse-controls copied to clipboard
joelpurra
Package manager publishing?
I would love it if there were a package in Chocolatey (or any other Windows package manager) for X-Mouse Controls.
If you have no objection, I'd be willing to figure out how to create and publish one. If I do so, would you want to be listed as a maintainer? I assume the only maintenance would be an update to the package to reflect new versions of the software itself, which I can do myself if you have a way for me to subscribe to release updates. (It looks like updates are currently only listed on your website, so I can't subscribe to GitHub notifications or similar.)
P.S. Thanks for writing X-Mouse Controls; I've found it very useful! One could even say I've grown addicted; I don't install it on Windows accounts I share with my family, and am occasionally caught off-guard by not having it.
@BatmanAoD: sure, package manager support would be nice. Used Chocolatey a few years ago, and it's pretty convenient.
Scrolled through Chocolately's website. Seems they support multiple maintainers, as well as a separate author. I am not interested in actively maintaining recipe(s); how about you and/or the community become package maintainers, and I get listed as author? Seems like a common setup, and I could take over if needed in the future.
- https://community.chocolatey.org/packages/putty.install
- https://docs.chocolatey.org/en-us/community-repository/maintainers/package-maintainer-handover
- https://docs.chocolatey.org/en-us/community-repository/users/package-triage-process#i-want-to-take-overhelp-with-package-maintenance-for-my-software
Regarding releases: watching the repository here on github should work, right? There have been a grand total of 4 published X-Mouse Controls versions during the past 14 years (birthday a few days ago! šš) so the chance of you missing something is quite low ;)
@joelpurra That sounds fine! I didn't notice at first that your releases are tagged in Git despite not showing up in the "releases" view here on GitHub, but now that I see the tags, yes, monitoring GitHub should be entirely sufficient.
@BatmanAoD: FYI, I've just created Github releases from all published versions.
Am currently treating these releases merely as a backup for the project website downloads. The entire https://joelpurra.com/ domain recently went down for over a month (hardware failure), so felt it was needed.
No new version of X-Mouse Controls is planned, but updating the website a little bit while I'm at it.
I have to admit that I completely forgot that the ball was in my court for this š¤¦š»
I'm setting up the package now. In case you'd like a preview, here is what I've got so far.
@BatmanAoD: oh, cool! There's no rush or anything; as mentioned, the Github releases were only triggered by the recent website downtime...
As I'm sure was the case for you when you wrote the software, the only rush is that I want to use the choco package myself!
@BatmanAoD: ran a quick test with the latest package (not the --pre testing package):
choco install xmouse-controls --version 1.1.0.0
The executable found in c:\ProgramData\chocolatey\bin\ works as expected, so no problems there. There was no start menu shortcut installed though (unsure why), so had to navigate to the bin folder "manually". Is that because of some local (choco?) settings on my machine perhaps?
@joelpurra I kept the installer minimal; it just puts the exe on the PATH. It doesn't even change the name, so in PowerShell, typing X-M<tab>, I get & 'X-Mouse Controls.exe'. This is exactly what I wanted, but I can also add a start-menu shortcut and/or change the executable name in the install script.
@BatmanAoD: as X-Mouse Controls is a GUI tool, I would say that the (or at least my) expectation is that a start menu shortcut is created. (Was now reminded of #22, for any scripting needs.) Yes, please, keep the original executable name.
Seems the choco approval process is quite detailed. Hope it gets fully verified soon =)
@joelpurra Chocolatey requests that packages include instructions for manual signature verification, but I'm actually having trouble with the x-mouse_controls_2018-10-06T1730Z_release.zip.asc file. The contents "look" right to me (though I know practically nothing about PGP signatures), but I can't get gpg to acknowledge them. Any suggestions?
Here's what I get (both on Windows using gpg4win and on WSL):
$> gpg --show-keys --with-fingerprint ~/tmp/x-mouse_controls_2018-10-06T1730Z_release.zip.asc
gpg: no valid OpenPGP data found.
@BatmanAoD: your gpg command mixes concepts, which is understandable; much of the criticism against openpgp/gnupg/gpg revolve around usability and terminology.
The .zip.asc signature file (BEGIN PGP SIGNATURE) does not contain the gpg public keys (BEGIN PGP PUBLIC KEY BLOCK). You're seeing a "no valid data" error because --show-keys is for inspecting a user's public keys. Pubkeys need to be downloaded separately to your local gpg keyring (and verified!) first; this is to keep track of your "trust" in these public keys (or rather in the cryptographic identities of the respective private key holders).
You can find the pubkey with fingerprint 4C47B4FF173AE6ED0DB733946DF6890D2A977668 on my contact page. Note that that is the (long-term/stable) primary key fingerprint; I rotate signing/encryption/authentication subkeys yearly, so you'll see a warning about the signature from 2018 coming from a superseded signing key.
Optional empty/test gpg keyring setup
Create a throwaway gpg home directory and set the GNUPGHOME path temporarily in the current terminal. Delete and recreate ./gnupg-home at will.
mkdir --mode 0700 ./gnupg-home
export GNUPGHOME="${PWD}/gnupg-home"
gpg --list-keys
First, have gpg import my public key.
gpg --recv-key 4C47B4FF173AE6ED0DB733946DF6890D2A977668
gpg --list-key --with-subkey-fingerprint 4C47B4FF173AE6ED0DB733946DF6890D2A977668
Second, verify the .zip file signature. (The .zip filename can be guessed from the .zip.asc filename, so the last argument is optional but more explicit for scripting.)
gpg --verify x-mouse_controls_2018-10-06T1730Z_release.zip.asc x-mouse_controls_2018-10-06T1730Z_release.zip
Didn't try this using gpg4win, only on linux (gpg v2.2.35). Do these steps work for you and/or Chocolatey?
@joelpurra Thanks for the explanation! Sorry, I was essentially blindly copying gpg commands from StackOverflow, and the "no valid OpenPGP data" message didn't give me any hint that I should be looking for a different key on your page. Though I probably should have figured that out just based on the fact that PGP uses key-pairs!
This doesn't need to be scriptable, I just want to make sure I can do the verification myself so that I can write up the instructions to include in the Chocolatey package.
It looks like key importing worked, but for some reason gpg isn't associating the asc file with the newly imported public key:
PS C:\Users\batma> gpg --list-key --with-subkey-fingerprint 4C47B4FF173AE6ED0DB733946DF6890D2A977668
pub rsa8192 2013-12-26 [SC]
4C47B4FF173AE6ED0DB733946DF6890D2A977668
uid [ unknown] Joel Purra <[email protected]>
uid [ unknown] Joel Purra <[email protected]>
uid [ unknown] [jpeg image of size 4521]
sub rsa4096 2023-03-14 [A] [expires: 2024-04-07]
A3D6BC73549C1B2B84CBBA1BD4D7146E17366870
sub rsa4096 2023-03-14 [E] [expires: 2024-04-07]
1F9664AD9E23CA4A24ED0666C64E0DE7F2A0641C
sub rsa4096 2023-03-14 [S] [expires: 2024-04-07]
03B5B1B312D624DF6C001264B9F144AA4BA349FA
PS C:\Users\batma> gpg --verify .\Downloads\x-mouse_controls_2018-10-06T1730Z_release.zip.asc .\chocoxmouse\xmouse-controls\tools\x-mouse_controls_2018-10-06T1730Z_release.zip
gpg: Signature made 10/6/2018 11:43:48 AM Mountain Daylight Time
gpg: using RSA key F1180AC410DF506C1BA92C041D9F8BDB0CEFA940
gpg: Can't check signature: No public key
Do I have to explicitly tell it which imported public key to be checking against?
...oh, do I need to mark the imported key "trusted" somehow?
Edit: that doesn't seem to work; after running gpg --edit-key --with-subkey-fingerprint 4C47B4FF173AE6ED0DB733946DF6890D2A977668, selecting trust, and assigning 4, the --verify command still failed, with the same error.
@BatmanAoD:
Do I have to explicitly tell it which imported public key to be checking against?
No need to be explicit; file verification should look for the public (sub)key in your keyring.
The public key listing looks correct. The signing subkey F1180AC410DF506C1BA92C041D9F8BDB0CEFA940 is correct (although superseded). Not sure why gpg can't match the two together. Did you run both these commands in the same terminal session?
The public key consists of multiple (somewhat independent) "packets"; perhaps old keys were "optimized away" somehow? You can verify that you have the old ("unusable") subkey in your keyring.
gpg --list-keys --with-subkey-fingerprint --list-options show-unusable-subkeys 4C47B4FF173AE6ED0DB733946DF6890D2A977668
If some subkeys are missing, you could try to import the pubkey another way; any new data (packets) will be merged into what you already have. (There are several ways to "discover" pubkeys from various services/servers, and because they are independent not all of them contain the exact same packets.)
# NOTE: use a specific retrieval method/keyserver.
gpg --keyserver 'hkps://keys.openpgp.org/' --recv-key 4C47B4FF173AE6ED0DB733946DF6890D2A977668
# NOTE: if you have curl, download the latest pubkey from my website.
curl 'https://joelpurra.com/key/mig-at-joelpurra.se-4C47B4FF173AE6ED0DB733946DF6890D2A977668.pgp.pubkey' | gpg --import
# NOTE: manual download; may lead to outdated keys.
gpg --import mig-at-joelpurra.se-4C47B4FF173AE6ED0DB733946DF6890D2A977668.pgp.pubkey
This doesn't need to be scriptable, I just want to make sure I can do the verification myself so that I can write up the instructions to include in the Chocolatey package.
Good, that should make it easier.
...oh, do I need to mark the imported key "trusted" somehow?
Defining a per-pubkey trust level is not required for file verification.
Okay, yeah, specifying keyserver worked! And for some reason, using gpg on WSL worked without any additional steps; I'm not sure if the issue was with gpg4win or if there was a breaking change to gpg itself (my WSL version is 2.2.27, while my gpg4win version is 2.4.0).
I'll just include the keyserver argument in the instructions, to be safe.
@BatmanAoD: thanks for verifying -- glad it works, and hope Chocolatey agrees.
It's a bit of an annoyance that data received from keyservers differ, with regards to old subkeys. There's a reason for this though.
- https://unix.stackexchange.com/questions/668870/gpg-no-more-signatures-of-a-fresh-imported-key
Basically, public keyservers were attacked and flooded with bogus data a few years ago. As a response, keyservers started "cleaning up" all pubkeys to be able to serve at least the bare minimum. It seems the default server used by gpg4win (perhaps hkps://keyserver.ubuntu.com/?) handles it differently from hkps://keys.openpgp.org/. I hadn't noticed any practical difference until now.
The pubkey self-hosted on my website remains unaffected, so that's good. It's "minimized" though, meaning that it doesn't include web-of-trust signatures from others (which the keyservers used to provide). Will have to investigate if I can do something to improve my own pubkey (it's nearly a decade old, and may use outdated settings) and re-upload it to both my website and the public keyservers. Thank you again for calling this to my attention!
The package is approved! https://community.chocolatey.org/packages/xmouse-controls/1.1.0.0
One of the maintainers clarified:
FYI, Chocolatey displays checksums (MD5, SHA1, SHA256 and SHA512) on the package web page - that's what a user would want to compare against, not PGP.
...I'm not sure what the point of this is; I thought the intent of the verification instructions was so that users and maintainers could check against something published by the software author, especially in cases like this where the packager and author are not the same person. In any case, I won't worry about that unless you update X-Mouse and I update the package.
@BatmanAoD: yay, good job! =)
...I'm not sure what the point of this is; I thought the intent of the verification instructions was so that users and maintainers could check against something published by the software author, especially in cases like this where the packager and author are not the same person. In any case, I won't worry about that unless you update X-Mouse and I update the package.
As you point out, checksums don't have any identity information -- which is particularly important when distributing compiled binaries. Then again, who downloads source packages and reads all source code? Including all dependencies, of dependencies?
Checksums (by themselves) are for protecting against the odd broken download rather than malicious actors. Keeping "verified good checksums" separate from the file download location (on my website or otherwise) may help raise flags if there's a mismatch though.
As an added measure, even if Chocolatey doesn't have procedures for it, you could sign the packaging scripts/files (in https://github.com/BatmanAoD/xmouse-choco-pkg) using either standalone gnupg signature files and/or signed git tags/commits.
Anyhow, who can really say that I am trustworthy? There are some "false positives" in the virus checks, which can probably be ignored... right? How deep does the rabbit hole go? ;)
- Added a sha256 checksum to each zip file, both as separate files (edit: also on github releases) and inline on the website. Now Chocolatey users can verify it against the package manually if needed.
- Added
choco install xmouse-controls, both in theREADME.md, plus on the website by the big download button and the historic downloads. - Added a thank you note for the packaging, and a link to https://github.com/BatmanAoD/xmouse-choco-pkg in case users have input.
I'll close this issue now. If there are new releases (published on github) to be packaged I guess you'll be notified, but none are planned a the moment.
Thank you very much for making the effort to get X-Mouse Controls into Chocolatey, am happy to see it =)
It's been a little over a month since choco's approval, and the package already has nearly 100 downloads (excluding the test version). Nice!
While the convenience of package managers is the norm on linux systems, I'm a bit surprised to see so many (in relative terms) windows/choco downloads for such a niche utility. Debian plus derivatives publish their (optional) package popularity contest usage statistics. In raw numbers, ignoring operating system user-base differences and opt-in bias, the xmouse-controls package rank would be circa 12,500 of nearly 200,000 (top ~6.5%) among packages sorted by number of users in the past 30 days ("votes").
For reference, the most popular download on https://github.com/joelpurra/xmouse-controls/releases has had 13 downloads in the past three months.
While it would have been interesting to compare, I unfortunately don't have (recent) statistics for downloads from the X-Mouse Controls project website. That server has been on a stability rollercoaster lately; luckily users have the above alternatives =)
Iām interested in a msstore package (or, if that is not possible, at least a winget one). winget can be used to install things from msstore and msstore will automatically provide updates (not that there will be many updates forthcoming). I should find time to play with that and see if that requires any buildsystem work.
@binki: sure!
Have no experience using winget (did use choco before), but since it's an official microsoft tool it seems like a good idea. I also do not have experience with msstore (only know it from reading tech news), so which would fit best is up to you.
To reiterate:
I am not interested in actively maintaining recipe(s); how about you and/or the community become package maintainers, and I get listed as author? Seems like a common setup, and I could take over if needed in the future.
Ease of maintenance seems like a reasonable goal, in particular noting that various proprietary "application stores" have a tendency to update their policies/submission expectations over time.
If you decide to go ahead, please consider opening a new issue and/or pull request for further discussion.