Replace CMake extension dependency with CMake Language Support #2267
Conversation
|
|
|
Thank you for submitting this PR! We'll do an evaluation of your extension and let you know if we have any feedback before making the switch. Please note that we are entering the holiday season in the US and this will impact how soon we can complete the evaluation. |
|
@bobbrow Any update? it's been a while. |
|
Just to set expectations, I don't have an ETA to get this in, but it could be a while before we make the switch. The main reason I asked you to start the PR was so that we don't lose it among all of the other issues. I'm sorry that these things take as long as they do. I did play around with your extension a bit and liked the better language server. But I also ran into a strange problem running our tests with your extension installed. I haven't had a chance to investigate it. |
|
@josetr, I was talking to the VS Code team about what happens when we change our The discussion then turned to whether we should use VS Code's "recommendations" as the venue for getting the language server extension instead. They asked me if you had any plans for making your extension open source and also wanted me to share that they are looking into integrating GitHub Sponsors into the extension listings to allow folks to easily monetize their extensions in the future. microsoft/vscode#107482 |
|
Tests failure report: (the ones that are crossed are failing without the extension installed as well) The unit test fails, these should be fine, just writing it here for my own reference : Successful-build test fails (locally), these should be fine, just writing it here for my own reference: Single-Root-test fails: |
|
Is it proper to recommend (actually, auto-download) a closed-source extension? I feel a little bit offended. Update: I'm not criticizing this extension or urging it to open source. It's totally OK for me that an extension is closed-source because I can choose whether or not to use it. But automatically downloading this extension means you distribute my trust in you (or Microsoft) to it. While it is neither widely used before nor backed by some well-known trusted organization/person. It is kinda out of my expected scope. |
|
I agree with @QuarticCat . Also the fact that this extension requires .NET runtime means it is annoying to install when using vscode's devcontainer functionality in linux. I'm of the opinion that it should be reverted to the previous extension bundle. |
|
Found this thread after seeing these errors and noticing that a new .NET extension had been installed without my knowledge:
It makes me realize that VS Code extension packs are probably dangerous to install in general, because the contents can be swapped out at any time. With all the work GitHub/MS is doing recently on preventing supply-chain attacks, it's somewhat surprising to me that these extension packs are so prevalent. (Edit: as @bobbrow said, I suppose that extension packs are not significantly "worse" in this regard than an individual extension with auto-updates enabled. Perhaps it's more a question of whether to disable auto-updates.) |
@QuarticCat, I'm sorry if we made a call that upset the community. The new extension is superior to the old one and after evaluating it we thought it provided better and faster language support than the previous extension and would be well received. We seem to have missed a few scenarios that are important to our users.
Thank you for the feedback. We didn't fully consider the impact this would have on devcontainers.
The .NET Install Tool extension is a Microsoft extension and should not be introducing security problems. I would contend that extension packs are not the problem. Any codebase can introduce security bugs at any time if they are not careful. Taking on a new node dependency runs a similar risk as an extension pack. Even adding new code in this extension itself is a risk. In any case, we've heard you and appreciate your feedback. We will roll back the change and put out a new release for now. |
|
For how terrible CMake is as a language, a proprietary language server doesn't strike me as the best idea, with all of the potential frustration implied by not being able to fork it when CMake shapeshifts into something else and the author of the language server abandons it, just like what happened to the twxs extension already (save for the fact that it's open source yet nobody bothered to fix it afaik) |
|
I fully undertand the decision that has been taken but I do hope that people understand that most of the security issues that have been mentioned do not go away when you use open source projects. The .NET Install Tool thing also fails when using VSCode + WSL. I was hoping that it would be fixed by now but I can provide alternatives in the meantime such as providing minimal support as a fallback that doesnt use the .NET runtime, and providing a way to configure the path to the .NET runtime directly. Also note that I do use CMake in a considerable number of projects, continue to do so, and is the reason why I will always mantain it. |
|
Not cool |
|
I appreciate the quick responses, and that both MS and @josetr are working on tools that benefit people like me for free. Thank you. From a security and trust perspective, I think some users (like myself) put more trust in the MS "blue check" extensions than in community extensions. When I first installed CMake Tools I do remember being confused and a bit concerned when the sketchier-looking one from
Of course as pointed out above it doesn't make any practical difference whether a third-party dependency is included with the user-facing That said, I would expect blue-check MS packages to have stricter requirements than the community extensions related to ensuring that dependencies have had their source code vetted and pinned, even if only internally by MS. (All of this is said while acknowledging that I know nothing about the internal processes and policies.) |
Open source obviously isn't a silver bullet against supply chain attacks. But it makes them much more detectable being able to look at the actual code. Reproducible builds are also in the question if the same source code will build bit-identical binaries as what you're distributing. The community, putting aside the fact that manpower is scarce and this doesn't happen often, at least has the option to pick up on your work in the event you go rogue or abandon the project. That's all besides the fact that there's no actual reason to keep it proprietary besides wishing to monetize your extension. I can only see practical benefits. It's ultimately up to you, but for the wider community, no one cares how presentable it is and how easy it is to contribute. As long as we can download a zip or tarball and start modifying it for our own purposes and send you patches, all is well. |
|
Just to provide closure from a release standpoint, we have published 1.11.26 (release) and 1.12.1 (pre-release) that have walked back the changes to the language support dependency. Folks are welcome to install whichever extension they like, but because we have an interest in providing language support and haven't been able to fund it natively in our extension yet, we will continue to bundle a support extension for the time being. |
|
The source code that is shown to the public does not protect you in any way. You will only "detect" what the bad guy wants you to detect. Unless that person wants to get caught really fast, he/she will continue pushing safe commits to the public repo while he/she uses a different branch to build and publish the actual extension. |
|
I would also like to mention that my original request was a simple suggestion to add my extension to the README files. Changing the dependency was @bobbrow's idea. I do hope that my original request can at least be fulfilled as I think my extension is good enough. As for changing the dependency, I can make it work in other environments such as devcontainers, but if that isn't enough to change the dependency, then it won't be a priority for me. By the way, thanks a lot for taking the time to review the extension. |
|
I did add it to the README in this commit: e5ea0cf |
|
@bobbrow Thanks a lot! |
|
Do you actually feel safer with an open-source extension such as the As I mentioned before, you may be using a build that was created using a branch that is not the one that is shown to the public and you may not even know it. It seems like VSCode extensions that are open-source are creating a false sense of security. |
@josetr Not true. We can build it from the source and compare it with the published version. Or, we can only use the one we built by ourselves. This kind of thing has actually happened before. A Chinese program called Mooc_Downloader distribute a different program on the release page and got caught. An article from a Chinese community exposed this behavior and got widespread and more than 4000 upvotes. Now this project has to indicate that it is no longer open source and loses a lot of trusts. This is why open source gives us faith. |
|
@QuarticCat But realistically speaking, you don't build your VSCode extensions, and 99% of the people don't either. Either way, by the time someone finds out by following this very tedious process, it's already too late. The number of people that will be safe following your process is very minimal, less than 1% if I had to guess. "Safe", assuming that they have also reviewed every inch of the source code. |
100% sure. If a program is open-source, it faces more risks when being evil. That is to say, I think being evil is less likely to happen for open-source software. I have seen so many cases where excellent closed-source software finally began to be evil. For example, Bandizip started to enforce upgrades and came with ads. Potplayer stated to bundle Avast. This so frequently happens that I have to be skeptical about software that insists on closed-source. Not to mention that open source gives us the chance to fork and continue maintenance in case of any accident. And this also happened multiple times. When Synergy turns to closed source, the community forked a version called Barrier. It is still under maintainance. When zdharma deleted all his ZSH plugins, the community continue maintain those plugins in a organization called zdharma-continuum. Again, this is why open source gives us faith. |
Of course. But that 1% will inform others and keep warning every open source author who wants to be evil, as the example I mentioned above. |
|
I am not rejecting any closed source software. I am also using Pylance and many Jetbrains products. But a closed source software naturally need to gain more trust compare to a open source software. This is what I want to express. |
|
@josetr What makes you insist on closed source? Before I left the first comment here, I had found an issue comment #93 (comment). In there you said that
But seven months have passed, and you haven't prepared all of these. I can speculate that you have a commercial motive or something else. This leads to uncertainty about the future of your extension. I don't want to be forced to accept some additional terms after I get used to it (such as payment or advertising, just for example). So closed source has reduced the attractiveness of your extension for me and possibly some other users. If you don't have other motivations, I don't want your excellent work to be regarded like this. |
|
@bobbrow FYI, a couple of years ago I made Flex+Bison based complete CMake language parser (source, article). It actually goes a bit further by supporting experimental feature I worked on but it's quite easy to go a step down to "normal" CMake language from that. Maybe it can be useful if in the future you would like to have a built-in language support. |
|
@QuarticCat Your definition of "evil" is not the same as mine. You are completely missing the point and diverging from it. I have never claimed that open-source projects don't have benefits. They obviously do. Most of my projects are open-source. But security-wise, when talking about VSCode extensions, an extension that is open-source is not going to save you from a bad publisher, unless as we mentioned, everyone builds their own VSCode extensions and reviews them all the time, which almost none does so it doesn't make a difference to the overall users. The biggest security concern is the publisher, that is the one you gotta trust, and in this case, your alternative, 'twjs', isn't any safer since according to you, it's not a "trusted organization / person" either. As for the "months have passed" comment, what happens to a project that I own depends on the priority that I assign it, and in this case, it was very low because this PR was stagnant and I didn't think it would be merged any time soon. It seems that I should have kept the extension to myself, as I did for a long time. The extra effort to improve the extension so that other CMake developers would benefit from it may not have been worth it. |
|
@josetr Your arguments fixate too much on immediate security benefits we will happily admit don't exist. And your assertion that an extension that is open-source won't save us from a bad publisher is patently false. Open VSX is a thing and they do not include extensions that depend on proprietary software. If they don't go far enough, you can look to every Linux distribution and F-Droid as an example of downstream curation where the "bad publisher" could theoretically become the package maintainers, but in practice, this has never happened in their respective official repositories. The point is faith in your extension. You're arguing that having the source code open won't protect us. On its own in an immediate sense, this is true. But the argument is about contingency, and security in general. A black box gives us none. Open source gives us options, and allows a downstream to even exist. |
|
@Cloudwalk9 I didn't know about Open VSX, but I do not understand how it protects you from a bad publisher. |
Fixes #2253