Arch Linux User Repository

@Freso We don't actually return a 403 Forbidden anywhere in the route handlers for that api. We also have no blocklist of Tor nodes or other such things. The best I can imagine is that DigitalOcean has some IPs blocked that may also be Tor Nodes which we can't influence.

@BigBrainAFK I’d love to switch to using your API for this! Is there a chance you’d stop 403’ing requests from Tor exit nodes (at the very least for this endpoint)?

That version query parameter seems a lot nicer to me than directly accessing the S3 bucket. At the very least it's obviously trustworthy while reading the PKGBUILD with no verification needed. Thanks @BigBrainAFK!

I'd personally vote for changing the URL in the PKGBUILD to the api.wooting.io one.

@Freso / @shaybox, thoughts?

@Micha @Freso @shaybox

Not entirely sure who to tag here but our API does support fetching specific versions of Wootility without a raw AWS URI.

You can use the query parameter version to specify which version you want from our API. This way you don't have to use some AWS URI that people can only verify by curl-ing or downloading it themselves from us at Wooting and then checking if the AWS URIs match or not.

For example: https://api.wooting.io/public/wootility/download?os=linux&branch=lekker&version=4.6.20

Another example https://api.wooting.io/public/wootility/download?os=linux&branch=lekker&version=4.6.6

@Micha Wooting stores their AppImage inside a S3 bucket, you can verify it yourself by following the link from their website. e.g. curl -i https://api.wooting.io/public/wootility/download?os=linux&branch=lekker

Why does this download the AppImage from https://s3.eu-west-2.amazonaws.com? The official website points to https://api.wooting.io/public/wootility/download?os=linux&branch=lekker.

I've verified that the files downloaded (at the time of writing) are identical, but it still seems kinda sketchy. I'm personally hesitant to install this package because I don't feel comfortable trusting a random S3 bucket.

Could you move the systemd unit file to the standard location for packaged units: /usr/lib/systemd/system/.

Updated

@shadybox it looks like this is missing the new Wooting Two HE (ARM)

From their help: https://help.wooting.io/en/article/wootility-configuring-device-access-for-wootility-under-linux-udev-rules-r6lb2o/

Wooting Two HE (ARM)

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1230", MODE:="0660", GROUP="input" SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1230", MODE:="0660", GROUP="input"

Wooting Two HE Alt-gamepad mode

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1231", MODE:="0660", GROUP="input" SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1231", MODE:="0660", GROUP="input"

Wooting Two HE 2nd Alt-gamepad mode

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1232", MODE:="0660", GROUP="input" SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1232", MODE:="0660", GROUP="input"

Wooting Two HE (ARM) update mode

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="123f", MODE:="0660", GROUP="input"

I just got one and adding these to my own udev rules works, but including them here would be wonderful when you get a chance.

I was dumb and didn't check the rules file and I spent some time figuring out why wootility won't detect the keyboard.

Rules expect for the user to be in "input" group, a notice during installation would be great.

This v3 works fine with the first Wooting One, only via USB 2.0 though, on USB 3.0 the utility lags as crazy and can't save settings anyway.