Within here it appears that there's an OpenSSL version distributed:
C:\Program Files\OpenVPN\bin
OpenSSL> version
OpenSSL 1.1.0j 20 Nov 2018

According to https://www.openssl.org/news/vulnerabilities-1.1.0.html , this seems to be relatively old, and 1.1.0 seems to be out of support.

Is this something that could do to be updated, or have I got hold of the wrong end of the stick and the openssl.exe in "OpenVPN\bin" isn't coming from here?

I'm guessiing that this might get resolved as part of #14 and chocolatey-community/chocolatey-package-requests#1024 (comment) , but am mentioning it just in case.

Hi!
Please find my issue below, pretty much it says all:
`Chocolatey v0.10.15

DEPRECATION NOTICE - choco update is deprecated and will be removed or
replaced in version 1.0.0 with something that performs the functions
of updating package indexes. Please use choco upgrade instead.
Upgrading the following packages:
openvpn
By upgrading you accept licenses for the packages.

You have openvpn v2.4.6.20190116 installed. Version 2.4.7 is available based on your source(s).
openvpn not upgraded. An error occurred during installation:
Already referencing a newer version of 'chocolatey'.
openvpn package files upgrade completed. Performing other installation steps.
The upgrade of openvpn was NOT successful.
openvpn not upgraded. An error occurred during installation:
Already referencing a newer version of 'chocolatey'.
Unsuccessful operation for openvpn.`

The OpenVPN project will release OpenVPN 2.4.2 and 2.3.15 the upcoming Thursday (11th May) at 16:00 CEST. These two releases will contain important security fixes and we hope that you could update the Chocolatey package fairly quickly after the release.

can you please update to the neu Version 2.5.x

Hi,

We at the OpenVPN project are going to start distributing our Windows installers using Chocolatey. The goal is to allow easy upgrades for users, as well as for our CI systems. The details are not set yet, so I'm contacting you before moving forward. For Debian/Ubuntu we have a fairly wide range of repositories (source):

• stable: stable releases only - no alphas, betas or RCs
• testing: latest releases, including alphas/betas/RCs
• release/2.3: OpenvPN 2.3 releases
• release/2.4: OpenVPN 2.4 releases, including alphas/betas/RCs

For Windows we're planning on having two repositories initially:

• stable: stable releases only - no alphas, betas or RCs
• snapshots: packages based on latest Git "master" code

It looks like your release strategy on chocolatey.org is very close to stable, and I don't think it makes sense for the OpenVPN project to create its own repository where it would distribute an openvpn package which is essentially identical to what you distribute on chocolatey.org.

So, would you be willing to co-operate with us on the stable OpenVPN Windows releases? Besides working together on code in this repository, I would like to see new, stable OpenVPN versions getting into chocolatey.org on the release day (if possible).

Thoughts?

I installed with:

choco install openvpn --params "'/SELECT_LAUNCH=0' /SELECT_PATH=1" --force

Then I run refreshenv or I go into a new terminal. The openvpn.exe is not added to PATH at all. The executable exists in C:\Program Files\OpenVPN\bin though.

On a new machine with a fresh Chocolatey install attempting to install openvpn 2.4.6.20180710 fails due to a failure to import the PGP key. Below is an excerpt of the relevant lines from chocolatey.log:

2018-11-20 18:21:22,414 10724 [DEBUG] - Importing PGP key 'C:\ProgramData\chocolatey\lib\openvpn\tools\openvpn_public_key_new.asc' in the temporary keyring (C:\ProgramData\chocolatey\lib\openvpn\tools\591b7b5d-bccb-4a33-bddd-195a756dc932\pubring.gpg)...
2018-11-20 18:21:22,477 10724 [INFO ] - VERBOSE: gpg: keyblock resource '/c/Users/administrator/C:\ProgramData\chocolatey\lib\openvpn\tools\591b7b5d-bccb-4a33-bddd-195a756dc932/pubring.kbx': No such file or directory
2018-11-20 18:21:22,478 10724 [INFO ] - VERBOSE: gpg: pub  rsa4096/12F5F7B42F2B01E7 2017-02-09  OpenVPN - Security Mailing List <[email protected]>
2018-11-20 18:21:22,479 10724 [INFO ] - VERBOSE: gpg: key 12F5F7B42F2B01E7: 22 signatures not checked due to missing keys
2018-11-20 18:21:22,479 10724 [INFO ] - VERBOSE: gpg: no writable keyring found: Not found
2018-11-20 18:21:22,480 10724 [INFO ] - VERBOSE: gpg: error reading 'C:\ProgramData\chocolatey\lib\openvpn\tools\openvpn_public_key_new.asc': General error
2018-11-20 18:21:22,481 10724 [INFO ] - VERBOSE: gpg: import from 'C:\ProgramData\chocolatey\lib\openvpn\tools\openvpn_public_key_new.asc' failed: General error
2018-11-20 18:21:22,481 10724 [INFO ] - VERBOSE: gpg: Total number processed: 0
2018-11-20 18:21:22,485 10724 [ERROR] - ERROR: Unable to import PGP key 'C:\ProgramData\chocolatey\lib\openvpn\tools\openvpn_public_key_new.asc' in the temporary keyring (C:\ProgramData\chocolatey\lib\openvpn\tools\591b7b5d-bccb-4a33-bddd-195a756dc932\pubring.gpg).

This package hasn't been update in nearly 3 years. Is it abandoned?

Hi @wget! I saw your package on Chocolatey.org, and I found a few errors in the nuspec. Specifically, the list of install args in the package description is very confusing to read. It seems that the flags on the left don’t match the explanations on the right. Example:

/SELECT_SHORTCUTS=1 : Install the OpenSSL Utilities (used for generating public/private key pairs)
/SELECT_LZODLLS=1 : Add OpenVPN shortcuts to the current user's Start Menu

In this case, the description for the SELECT_LZODLLS parameter is really meant to be the description for the SELECT_SHORTCUTS parameter. Nor is this the only example: Every flag in the description (except for SELECT_OPENVPN as far as I can tell) has the wrong description. I would prepare a PR that fixes this, except that I am not familiar with this piece of software, so I am not certain that I would match the flags with descriptions 100% correctly. Thanks!

Received a request from the Chocolatey messaging system:

When the 2.4.7 update was pushed to our PC's via scheduled task it broke OpenVPN for anyone who was running the "openvpn-gui.exe" regardless if they were connected to vpn or not.

They would get a .dll error. Would it be possible to have chocolatey verify the openvpn exe's are not running before it tried to update.

I understand this may be a one time thing regarding what was changed on OpenVPN's end but files shoulden't be open and upgraded.

This is something I plan to add for the forthcoming OpenVPN release.

Silent install not possible for the time being.

When working on Puppet code that needs to run on Windows 10 ARM64 I noticed that the Chocolatey OpenVPN package is still at 2.4.7. That means that the bundled tap-windows6 driver is also old, has some already fixed security issues and does not have ARM64 support.

The current 2.4.8 installers have up-to-date drivers which work across all Windows versions:

• Windows 7/8/8.1/Server 2012r2 installer
• Windows 10/Server 2016/Server 2019 installer

Would it be possible to update the Chocolatey package to 2.4.8?

GPG signature checking is only performed at install time to verify the OpenVPN installer, therefore it may be a good idea to include a standalone gpgv executable in the package and get rid of dependency on gpg4win-vanilla.

(Actually the bigger problem is that gpg4win-vanilla and the full-fledged Gpg4win package do not play well and interfered with each other's software registry on my system. Ideally we should have Gpg4win depend on gpg4win-vanilla and provide by itself only the delta, but a standalone gpgv in this package should be beneficial nevertheless.)

Clearly, the gpg check causes issues to pop up occasionally. Also, I'm not a fan of polluting explorer.exe context menus with additional stuff almost no OpenVPN users are likely to want or expect.

So, what exactly is the threat-model that gpg is intended to protect against here? I mean, you're already downloading from a trusted source via https, after all. The number of attackers that can upload to the openvpn binaries but not gain access to the signing certificate (i.e. they didn't hack a dev, and the signing certificate isn't on whatever deploy machine or webserver the attacker did gain access to) seems rather small.

Additionally, by depending on gpgwin, you're adding attack surface, because now anybody that hacks the gpgwin infrastructure or openvpn (and technically choco and this package, and the gpg package) can gain access to downloaders' machines. And as it happens, gpg4win-vanilla is currently unmaintained.

So... is this check really doing anything at all? Isn't best to just dump it?