Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSM packaging #106

Merged
merged 19 commits into from
Jul 3, 2020
Merged

MSM packaging #106

merged 19 commits into from
Jul 3, 2020

Conversation

rozmansi
Copy link
Contributor

@rozmansi rozmansi commented Mar 9, 2020

This PR introduces MSM (Microsoft Installer Merge Module) packaging of the TAP-Windows6 driver.

MSM produced is a clone of the Wintun installer adapted for TAP-Windows6.

Features:

  • Reliable installing, upgrading, removing. Tested and real-world proven with Wintun deployment.
  • The installer built-in reference counting allows more applications deploy the TAP-Windows6 driver without uninstalling one would remove the driver used by others.
  • MSM is directly mergeable to the MSI package I am preparing in the openvpn-build repo.

The ARM64 platform is not supported at the time being. The source code and build process are mostly ARM64-ready, but the official WiX Toolset does not support it yet. Fortunately, they are working on it.

Note, this PR updates the README.rst file with the proposed new release workflow. As described in the updated documentation, we should no longer release the driver as an inf+cat+sys bundle or using the NSIS EXE installer. Those means do not have any reference counting and 3rd party vendors should not redistribute them.

MSI custom actions must not depend on MSVC RTL presence.

Signed-off-by: Simon Rozman <[email protected]>
Most of the project settings apply to all configurations and platforms.

Signed-off-by: Simon Rozman <[email protected]>
Signed-off-by: Simon Rozman <[email protected]>
Signed-off-by: Simon Rozman <[email protected]>
When RCDATA file path was authored using a defined constant the MSBuild
failed to resolve dependency. This skipped rebuilding the resources when
driver files changed.

Signed-off-by: Simon Rozman <[email protected]>
The .cat catalog file references .inf and .sys files. Therefore, we need
to use original driver filenames.

Signed-off-by: Simon Rozman <[email protected]>
TAP-Windows6 is using root-enumerated default HWID.

Signed-off-by: Simon Rozman <[email protected]>
The .sys file of the driver does not need to be digitally signed. It is
the .cat file that Windows is checking for complete driver .inf+.sys+
.cat bundle.

Signed-off-by: Simon Rozman <[email protected]>
Signed-off-by: Simon Rozman <[email protected]>
@mattock
Copy link
Member

mattock commented Mar 23, 2020

@rozmansi looks good afaics but did not test this yet. A couple of questions...

Was the removed of devcon build instructions intentional? I believe it should not be removed as we will have to keep maintaining NSIS installer process for 2.4.x[*] for some time and building devcon.exe (or using a pre-build binary) is still necessary there.

Also - now that we have this MSM - do we want to "rock the boat" by merging the NSIS installer changes you made earlier:

I'd say no, because the OpenVPN NSIS + tap-windows6 installers are working fine now for OpenVPN 2.4.x for all platforms (Win7/10 i386/amd64/arm64). That said, I may have forgotten some details by now. Based on the GitHub comments I don't think I ever got into testing the above PRs on my Windows 10 ARM64 laptop. I can do that if we decide merging them is worth it.

Btw. I noticed that the ARM64 issue you mentioned has been fixed and the fix is included in WiX v3.14.0.3910.

[*] Based on the lengthy discussion in PR OpenVPN/openvpn-build#141 it seems like the MSI could handle upgrades from NSIS cleanly, even from ancient OpenVPN versions, but for a stable 2.4.x release changing the packaging system seems excessive.

@rozmansi
Copy link
Contributor Author

Was the removed of devcon build instructions intentional? I believe it should not be removed as we will have to keep maintaining NSIS installer process for 2.4.x[*] for some time and building devcon.exe (or using a pre-build binary) is still necessary there.

I didn't realize you plan to keep using NSIS TAP-Windows6 installer. As I mentioned in the readme, all 3rd party vendors should switch to MSM/MSI if they are deploying the original unmodified "tap0901" driver - because of the reference counting. Otherwise, applications will interfere, each believing it holds the exclusive ownership of the installed resource: namely tap0901 driver.

Also - now that we have this MSM - do we want to "rock the boat" by merging the NSIS installer changes you made earlier:

* [installer: Refine the WoW64 decision logic](https://github.com/OpenVPN/tap-windows6/pull/98)

This one should make more appropriate arch detection (for the ARM64 platform). Should be tested on ARM64 to confirm it works.

* [installer: Select Win7/8/8.1 vs. Win10 driver at runtime](https://github.com/OpenVPN/tap-windows6/pull/99)

This patch makes things more convenient: it makes the TAP-Windows6 NSIS installer one-EXE-file-for-all-Windows-releases once again. Merge at your discretion.

* [installer: Add code signing certificate before installing the driver](https://github.com/OpenVPN/tap-windows6/pull/100)

This patch makes things more convenient too: it suppresses the trust prompt in Windows 7-8.1, Server 2008R2-2012R2. Merge at your discretion.

I'd say no, because the OpenVPN NSIS + tap-windows6 installers are working fine now for OpenVPN 2.4.x for all platforms (Win7/10 i386/amd64/arm64). That said, I may have forgotten some details by now. Based on the GitHub comments I don't think I ever got into testing the above PRs on my Windows 10 ARM64 laptop. I can do that if we decide merging them is worth it.

Your call.

Btw. I noticed that the ARM64 issue you mentioned has been fixed and the fix is included in WiX v3.14.0.3910.

True. However, I cannot give you an exact time when I will be able to look into it.

[*] Based on the lengthy discussion in PR OpenVPN/openvpn-build#141 it seems like the MSI could handle upgrades from NSIS cleanly, even from ancient OpenVPN versions, but for a stable 2.4.x release changing the packaging system seems excessive.

I've used 2.4.x versions in 2018 for MSI testing. As the file, folder and registry names are the same for 2.4 and 2.5, there is no change required to the MSI structure. In other words: MSI version is just a number - just make sure it matches the OpenVPN you are packaging.

tapinstall/devcon.exe creates tap0901 adapters, tapctl.exe creates root\
tap0901. Both use the same driver. Both adapters should upgrade when we
update the driver.

Signed-off-by: Simon Rozman <[email protected]>
@rozmansi
Copy link
Contributor Author

rozmansi commented Apr 4, 2020

Was the removed of devcon build instructions intentional? I believe it should not be removed as we will have to keep maintaining NSIS installer process for 2.4.x[*] for some time and building devcon.exe (or using a pre-build binary) is still necessary there.

I have removed the commit that did this.

@mattock
Copy link
Member

mattock commented Jul 3, 2020

MSM packaging works well with MSI. There may or may not be an issue with how Windows 10 ARM64 platform is handled, but I have not yet verified if it is a packaging problem or a genuine bug. Nevertheless, that can be fixed in a separate PR.

@mattock mattock merged commit fcba342 into OpenVPN:master Jul 3, 2020
@rozmansi rozmansi deleted the feature/msm branch September 18, 2020 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants