lamili.blogg.se - Karabiner elements security

#Karabiner elements security how to#
#Karabiner elements security upgrade#
#Karabiner elements security code#
#Karabiner elements security download#

Just run your normal build and then extract all o files: I was able to get the reproducible builds on the same machine in this way. (As far as I can tell generating *.o files is already stable). I can not vouch that you would get the same result on multiple machines with these changes, or that you would need to standardize something additional, but I think I got stable linker step also on my computer. If you play around with linker you can get builds with stable shasum on a single machine. *.o files are deterministic as far as I can tell. Not sure what is linker pulling from there, maybe changed build.db, who knows. For some reason this also fails miserably.

You are using *.o files from the derived data dir to link the result file.

You would need to make sure users use the same path on their hard drive.

You are using xcodebuild that uses derived data as part of the compilation process.

I've tried to investigate a bit what is happening and there is a couple of sources of non determinism in your setup.

#Karabiner elements security code#

Debian is trying to make their builds reproducible and they have way more code than this project. I'm not a compiler expert but it seems like it should be possible.

Ignore serious issues on is your proposal possible?.

Attaching binaries in source code and using them to produce the artifacts rather than source code.In the make script check the sha of the result binary and if it matches attach the correct signature, otherwise report error.Create a kext signature for every release of Xcode that is supported (just supporting the last version of Xcode is more then sufficient for probably 99% of people).

#Karabiner elements security how to#

How to remedy this so that everyone is happy:

You are ignoring a really important issue that is keeping me from using this project anywhere.

I really love your product and I would rather give those 100$ to you than to Apple.

Like I said, I think that you are aware that Apple won't be giving those kext signing keys to developers for personal use, the risk for Apple would be too high. This is why Karabiner-Elements embed the signed kernel extension binary.

#Karabiner elements security upgrade#

Thus, normally you have to upgrade the Developer ID Certificate to be able to sign the kext. That doesn't mean that you should attach a signed kext binary and commit it as a part of source code and use it as a fallback. I understand why you need to sign the kext. Without it, you cannot load the kernel extension with SIP. However, macOS requires a special signing key for the kernel extensions. There is no indication that they would approve some else developer kext signing certificate for personal use. Apple rejected my request although I've paid them 100$. I've entered Apple developer program and asked for a signing key to sign my own kext contain in this library. There is approximately 0% chance that users can build and sign this on their own.Let people decide on their own their personal tradeoffs between security and convenience. Your releases don't contain binaries, but they are concealed in the source code itself. You are ignoring the usual release process. The normal publishing process on GitHub is to use release attachments for attaching binaries and git for building from source. There are two standard ways to distribute the product: git clone + make or attaching a binary.Using it in this form would be irresponsible and you are putting a lot of people who really love your product in an awkward position. Because of this I can't use this product in any kind of commercial environment.People are maybe using this in companies that have certain strict policies and you can get those people accidentally in a lot trouble.When I've shared this finding with some of my coworkers they were shocked because they were also deceived. Majority of users is probably not aware of this fact.This gives the user an impression that everything went smooth, when the expected action actually didn't happen. Even though the process fails because of signing issues, you ignore the entire build process and just use your home built and signed kext from somewhere and build the result dmg file successfully.

When a user is trying to build the binary from source files, because they care about security, you are presenting the built from sources progress to the user.

Build from source: What you see in the code is what you get.

#Karabiner elements security download#

Download binary: I would never use binary kext downloaded from somewhere that is intended to intercept all of my keystrokes, that's just insane).

There are two ways of distributing the code: Because of this I can't use this project anymore. This is also the reason why this is so frustrating. I really loved to use it, and it was almost indispensable to me. First of all I would say that I appreciate all of your giant effort to open source this tool.