Closed prateekma closed 3 years ago
Hi @prateekma . We're looking into this. We have another certificate we can use that seems to support hardening, and are looking for a way to validate it (without an App Store account). Also, I'm not yet certain there wouldn't be licensing issues for a 3rd party distributing our extension.
@prateekma Would it be a feasible alternative for your application to trigger installation of our extension, by invoking the following command line? code --install-extension ms-vscode.cpptools
Unfortunately, our environment requires that everything be installable offline and without internet access.
@prateekma @Daltz333 Unfortunately, the license we publish the extension under, which is available in the License tab of our extension page in VS Code, indicates:
you may not extend the software by, among other things, loading or injecting into the software any non-Microsoft add-ins, macros, or packages
you may not:
e) share, publish, distribute, or lease the software (except for any distributable code, subject to the terms above), provide the software as a stand-alone offering for others to use ...
As such, I don't believe the scenario of publishing an application to the Mac Store that includes our extension, is supported. While the TypesScript component is Open Source and MIT licensed, the extension includes an IntelliSense component that is still private.
This issue, which I asked years ago, stated distribution for offline use was fine, assuming you were using the VSIX files from the releases page, and using them in official copies of VS Code.
https://github.com/microsoft/vscode-cpptools/issues/2274
When did that change? We do use the extension with official VS Code, it's just an offline method of installing into VS Code.
I'm going to need to defer to legal to address that question. We are currently doing so, in the context of: https://github.com/microsoft/vscode-cpptools/issues/5784 Inclusion within a Mac App Store application might introduce some nuances.
We can switch to a hardened cert. However, we do not publish via the Mac App Store, so addressing issues with notarization may not be something we can support and validate.
If the user must be connected to the internet to connect to the App Store, isn't that already contrary to the requirement that everything be installable offline and without internet access? Perhaps when installed via the App Store, it could use the command line install option instead, which would also insure the user gets the latest version?
We're not distributing through the App Store, but we want to be able to sign and notarize our app, which is a stricter requirement outside of the app store then inside of it. That notarization is failing with the above errors. We have no plans for app store distribution.
As for the license, both 2274 and 5784 have people saying the intent of the license is to only work with official VS Code. We are following that, and do only work with official VS Code. So for now, we're going to stick with the guidance given in 2274.
@ThadHouse Can you provide an example, other than inclusion in a Mac App Store application, which requires notarization, and cannot support online installation of our extension? So far, we have had no requirement to support notarization.
Yeah, we want to allow users to be able to distribute the .vsix, so I think that should be okay for now -- we noticed the license restriction in regards to sharing/distributing of the binaries later on (in thread https://github.com/microsoft/vscode-cpptools/issues/5784), but we've asked our legal team to clarify and/or modify the license a month ago, but we haven't gotten an answer yet.
Starting in macOS Catalina, if you distribute an App outside of the App Store, it must be notarized, or it will not be allowed to be ran.
We're basically building an installer that installs VS Code, installs some plugins into it, and installs a bunch of offline file dependencies, all for an offline robotics competition setup. To do this, the extension is included as a resource in the app, and all resources in the app must also pass notarization checks.
https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution See the note a little bit down the page.
So we're not actually running the extension, but even for users to be able to run our app, everything included in it must be signed and using the hardened runtime.
In addition, Apple does state that in a future release of macOS all binaries will have to be signed. It's better to be proactive about that rather then wait until you are forced to.
The 1.1.0-insiders3 vsix has cpptools/cpptools-srv mac signed with hardening https://github.com/microsoft/vscode-cpptools/releases/download/1.1.0-insiders3/cpptools-osx.vsix , the clang-format binary will have hardening for clang-format 11 (with the Developer Certificate, not the App Store Certificate...not sure if that matters), but I'm not sure when we'll release that yet.
The debugger binaries might take longer, and/or are externally built, such as mono. @WardenGnaw might have more to say.
@ThadHouse FYI, we're planning to update the license wording to allow redist/sharing of the offline vsix...just waiting to receive the new license.
For the debugger, we will not be signing the mono runtime binaries. That is an issue on the mono project. However, we are looking into moving to the dotnet runtime and those will be signed as of .NET 5.
Binaries in VSIXTest.zip/cpptools-osx.vsix/extension/debugAdapters/lldb
are only used for macOS High Sierra and lower. We do not plan on runtime hardening these binaries.
We will investigate adding a runtime hardened lldb-mi (VSIXTest.zip/cpptools-osx.vsix/extension/debugAdapters/lldb-mi/bin/lldb-mi)
Will you distribute a separate VSIX for macOS Mojave and higher without VSIXTest.zip/cpptools-osx.vsix/extension/debugAdapters/lldb
? Even including the binary in the VSIX will fail notarization; Apple has no way to check if it's being used.
Installing using the vsix from the market place will only download the correct version to use.
This is based on "versionRegex": "10\\.(1[0-3]|[0-9])(\\..*)*$"
We're depending on the vsix from the releases page, not the marketplace. So that doesn't help.
I could not find an official documentation about the end of life for High Sierra, but it is guessed to be EOL at the end of November 2020.
We can potentially remove it from the package but it is also dependent on how many users are still on that OS.
@ThadHouse We've updated our license to address the scenario you addressed: https://github.com/microsoft/vscode-cpptools/blob/main/RuntimeLicenses/cpptools-LICENSE.txt . Our next vsix's should have the updated language:
Further, you may install, use
and/or deploy these software copies via a network management system or as part
of a desktop image within your internal corporate network to develop and test
your applications.
Let us know if you think that language is insufficient.
Our next release should also have a dev signed and hardened lldb-mi.
We ship a disk image with the VSIX's publicly over a public GitHub Release page (https://github.com/wpilibsuite/allwpilib/releases/tag/v2021.1.2 the images here contain the VSIX's). So if you consider GitHub releases to be a network management system then that would work, but otherwise it likely would be insufficient for us.
Although, I don't see any redistribution limiting clause in the license at all anymore. The old one explicitly had one, so without it, I don't see anything blocking our use case anyway.
@ThadHouse Yeah, that sounds fine -- we'll update our license again, soon...
We think this has been addressed. If there are any remaining signing issues, please let us know.
Type: General
Some binaries in the VSIX are not signed (at all, with hardened runtime) for macOS notarization. We want to distribute a copy of the C++ VSIX with our application and this is causing notarization to fail.
Describe the bug
To Reproduce Include the VSIX file in a macOS Application and send it for notarization. An exhaustive list of binaries from the notarization service is below:
Expected behavior We expect the Apple notarization service to not error on any binaries related to the VSIX.