Open ruabmbua opened 5 years ago
I can also help with MacOS. I would suggest switching to circleci and requesting build machines for macos (https://circleci.com/pricing/#faq-section-os-x). Travis mac builds are very slow.
It`s not just for CI. I need something to develop on. I guess setting up macos in a conventional VM should do the trick?
I understood that. I can help with the mac development. My suggestion was to add CI too. Given that you are the owner of the project, I was suggesting you contact circleci so you can get free a OSX builder for this repo.
Okay I got it. Anyway I will start with linux, but it might take some time. I will probably do some work on monday, I got lots of time on a train trip.
Note to myself: Do not forget to bring a hid device :sweat_smile:
I have some macOS bindings that I'm trying to find a place to upstream. I've got another (private) fork of these, where I'm trying to pull out the FIDO-specific bits and make it a little more featured, and have fixed up some bugs.
Relatedly, on recent versions of macOS, hidapi
triggers a requirement for "input monitoring" permission, because it it sets IOHIDManagerSetDeviceMatching(NULL)
, which is scary (or triggers alert fatigue). When an application sets a reasonable matching policy (for non-keyboard/mouse usages, or for a small set of VID/PIDs), then that permission is no longer required.
There's similar "device matching" rules available on Windows which could be made equivalent. UWP apps appear to have a similar permission gate around them, but it's not clear to me how that actually works (eg: does an AppxManifest cause those APIs to return filtered results with no further intervention).
I mention this as it'd mean expanding hidapi-rs
' API further to accommodate this.
I now notice there's #131; I've left some notes on there.
For this issue help is wanted. I have no experience at all with MacOS, and also no access to apple hardware.
Progress: