Replies: 4 comments 14 replies
-
|
They are not, and it is not feasible for us. If you trust us, just strip the "downloaded" attribute from the release archive (as explained on the releases page). |
Beta Was this translation helpful? Give feedback.
-
It might be feasible, we could use a service like vim does: https://github.com/vim/vim-win32-installer?tab=readme-ov-file#signed-builds However I see that #11011 (comment) mentions another problem. |
Beta Was this translation helpful? Give feedback.
-
|
It's a problem that I expect to become more pronounced as https://www.youtube.com/watch?v=HUEvRyemKSg plays out |
Beta Was this translation helpful? Give feedback.
-
|
A wise man once said "concern is the mind killer". There's no indication that Apple is moving towards locking down the BSD subsystem -- they know that developers are a core audience for their shiny (and expensive) thinking rocks. As long as we're not trying to distribute a GUI through their App Store, we don't have to worry about this. |
Beta Was this translation helpful? Give feedback.
-
|
I can't comment on the difficulty, complexity, or viability of signing through Apple, however I think it is something that should be explored. If signing though Apple isn't feasible for whatever reason, you could explore self signing. Obviously signing through Apple would be the best way, as GateKeeper would not need to be disabled, which scares potential users off, and I believe it has other benefits (seeing the "Apple has not checked this application for malware" is a bad look. The next best thing would be to self sign, with something like OpenSSH (opposed to GPG for security and convenience reasons ((OpenSSH is preinstalled of Mac/Windows unlike GPG)). Users would still have to bypass GateKeeper with this method, however they would have reassurance that they have a genuine copy by verifying it themselves. Me personally, I have swore off using unsigned code (because I can't audit it myself and won't blindly trust other people to do so). It's unfortunate because I have to pass on so many cool projects like neovim. |
Beta Was this translation helpful? Give feedback.
-
|
PR welcome; then we can discuss whether the complexity is worth it. (And I recall that "bypassing GateKeeper" is as simple as |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I don't know how to do that. I'm not a programmer, I just wanted to see if releases were signed. The technical aspects of this kind of stuff is way over my head. *Edit - Found This |
Beta Was this translation helpful? Give feedback.
-
|
Coincidentally, github just announced Artifact Attestations:
Not sure if that fully solves the problem for macOS specifically, but it seems like a step that would set us up for a long-term solution. |
Beta Was this translation helpful? Give feedback.
-
|
The Homebrew .pkg installer is now signed similar AFAICT to the link you posted. The PR is #15743 if you want to check it out. I believe they automate it through GitHub. I think this addresses the issue clason brought up of NV being a CL tool, which Homebrew is. Also, as I mentioned above, even if going through Apple is too much (despite it being preferred), signing with GPG or (maybe even better) OpenSSH would at least allow people who care to manually verify and get some reassurance before bypassing Gatekeeper. I don't know if having GitHub auto-sign is the most secure thing, but I could be wrong. |
Beta Was this translation helpful? Give feedback.
-
PR 15743 in which repo? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, my bad Homebrew/brew#15743 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
I don't exactly understand the threat model here -- you already trust us fully by running a binary which we build and you can't vet. You can already verify corrupted downloads (or man in the middle attacks) from our releases page by comparing the provided hash. What would signing provide on top of that? Do you expect that a personal signature from one of the maintainers (which?) is more trustworthy than that? Why? As far as you know, we are all just random internet clowns -- if you can't trust the releases we provide via Github, why would a signature change that? |
Beta Was this translation helpful? Give feedback.
-
|
Obviously, outside of personally code auditing the project with each release, you must place trust in the devs, that part I am not disputing. The threat model issue is simple. What is the point of posting a hash right next to the release file? What does that prevent? Lets say a malicious actor were to upload a malicious copy of NV. If a user were to download the NV release and check the hash, they would be a mismatch and the user wouldn't trust it. The issue is, you only post the hash in one place, AFAIK, and it's right next to the release file. If someone can replace the release file with a malicious copy, what is stopping them from posting the matching malicious hash? Nothing. Therefore, if you download the malicious file and check the hashes, they would match. You would think that everything is all good, when in reality you just verified a malicious file with a malicious hash. There is literally no reason to post the hash the way you do, it serves zero purpose. Compare that to singing. In order for someone to ship a malicious version, they would have to compromise the signing key, which, presumably, the signer would be extra careful to secure/protect. As far as I can tell there is two options to verify authenticity. Sign the files or mass distribute the hash across multiple secured platforms with each release. Signing is more convenient and secure. The fact that signing files is even a thing and widely used should suggest that it is worth wile. Mac has a built in signature verification system for a reason. And I want to make one thing clear, I am only bringing this up with the intent on making software more secure for people. I think the while XZ debacle should make people reconsider a lot of common practices. |
Beta Was this translation helpful? Give feedback.
-
And how exactly would they do that? If they can, they have maintainer access to Neovim and can just have their copy signed by the workflow. The attack model for the hash is not against Github -- if that is compromised, all bets are off anyway -- but against a man in the middle attack (rerouting your download, or you downloading from a third-party altogether).
You do realize that this debacle started with bad-faith actors hectoring the maintainer about their practices? And I don't believe Neovim is subject to the same threat model as a fundamental library that affects virtually every network traffic in pretty much every server world-wide. |
Beta Was this translation helpful? Give feedback.
-
Very true, that is why the workflow option may not be all that good.
You're right and I do. What I was getting at was the fact that the whole "audit the code" and "it's open source so people will notice nefarious code" has been disproved. Let's be real, no one audits the code and it is just blindly trusted by everyone. Distros just pull in the updates and let it be. Just because the update comes from the official GitHub doesn't mean anything.
It's definitely doesn't, the XZ thing was very clever and deliberate with a mass intent. NV is very popular and could be enticing to attack. I just think signing releases would help mitigate any threats. I don't see how people can just bank on a project being FOSS for security anymore. It's about trusting as few people/things as possible. You always will have to trust the dev, but you don't have to trust GitHub, your browser, the servers, ect. If a dev can't protect signing keys then I don't see how you can trust them with anything. Plus I think it makes sense to leverage Apple's dedication to trying to ensure authentic apps. They provide a built in mechanism to do this, and yes, it may be a pain to do, but it works and works well. It's there for a reason |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I'm sorry, but I don't see a positive benefit to effort ratio here. (Have you actually checked the hoops you have to jump through for Apple to sign, let alone notarize---which Gatekeeper requires now!---your software? That's completely infeasible for a cross platform CLI tool like ours. And flattering as it would be, Neovim is by several orders of magnitude not relevant enough to merit a state sponsored attack.) In the end, this is a human problem, and solved by humans not software (unless you are selling blockchain to unsuspecting people). |
Beta Was this translation helpful? Give feedback.
-
|
Okay, fair enough. I'll just leave it on this. If notarization is too much, you could use something like OpenSSH to sign releases. The files would still be verifiable. You would still have to bypass Gatekeeper, however you will have manually verified it and would be confident in bypassing Gatekeeper. I respect and appreciate the consideration and debate. I concede it is your project and your prerogative to do as you wish. I will duck out now. Thanks |
Beta Was this translation helpful? Give feedback.
-
Are the Mac releases signed for GateKeeper? If not, would it be possible to start signing them so Mac users don't have to bypass GateKeeper since there is no other means to verify neovim?
Beta Was this translation helpful? Give feedback.
All reactions