Skip to content

General

Originally posted 2019-04-10

What programs that I use were missing from the repo?

Here are some stats what packages that I use were missing from the community repo-

  • 130ish total programs eligible for the community repo (does not include software that does not have a public download such as games and whatnot)
  • 20ish of those 130 were missing, outdated or broken

of those 20ish

  • 8 now have community packages created by me
  • 3 have custom installers that are hard to automate
  • 3 are outdated but are still under active development so it is not worth the effort to keep them up-to-date
  • the rest I decided either that I did not need anymore or I created personal packages for them.

General experiences and observations about Chocolatey and the Chocolatey community

-

  • Chocolatey is owned by a business and is open core model, more on that later.
  • I have found the community in general to be helpful and has a number of very active volunteers.
  • The founder is active all over the internet, and is also active in development, so there is a good chance of support even if you are not a paying customer.
  • For development, they are very picky about formatting, commit messages, and signing a contributor license agreement (CLA). This also carries over to packages in the community repo to a certain extent.
  • They have everything that is non-proprietary on GitHub, including issue trackers, wikis and stuff, which is awesome for transparency.

More on open core

  • You are required to sign a CLA to contribute
  • To a certain extent I see a pattern frequently observed among open-core projects: almost every good feature added after the initial period is proprietary. So if Chocolatey is missing a feature right now, expect to pay for if it gets added.
  • The distributed Chocolatey package includes the proprietary shimgen.exe

Icon URL how to in community packages

The current instructions say to use Rawgit, but that is shutting down later this year. Here is how I use an alternative statically

  1. Get the icon png for the software you are making a package for
  2. Upload to Github repository
  3. Find url of the png in commit, not in master so if I later remove the png from master, it is still available at that commit url.
  4. Copy direct URL to staticaly
  5. Put the CDN link generated by staticaly in package.nuspec

How to quietly install non-WHQL driver(s)

There are some programs that add drivers during install that are not cross-signed by MS, so during install windows asks if you want to trust the cert. This is a problem since Chocolatey packages are supposed to be quiet (i.e. no user interaction required and no notifications displayed on the screen).

First off you can- A. Install the program and trust the cert somewhere, then open up certlm.msc, go to trusted publishers>certificates then export the installed cert and include it in the tools directory. B. Do something like this(source)

$driverFile = Join-Path $toolsDir 'driver.cat'
$outputFile = Join-Path $toolsDir 'cert.cer'
$exportType =[System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$cert = (Get-AuthenticodeSignature $driverFile).SignerCertificate;
[System.IO.File]::WriteAllBytes($outputFile, $cert.Export($exportType)

Then use

certutil -addstore -f "TrustedPublisher" $toolsdir\cert.cer 
Finally, if actually need to install a driver .inf manually, use
pnputil -i -a $toolsDir\driver.inf
I know this is the older deprecated syntax, but it is what works with windows 7.

The problem with shimgen.exe

Here are the facts as I understand them- 1. Chocolatey Open Source the package refers to not only the choco.exe main program but also some helper scripts and bundled 7-zip, checksum, and shimgen executables 2. choco.exe, checksum.exe, and 7z.exe are released under open source compatible licenses(Apache or LGPL) 3. shimgen.exe is included/released under a restrictive EULA that allows use ONLY with the official chocolatey client Source 4. Chocolatey Open Source the package(so not just choco.exe, but the whole .nupkg) is advertised as open source and under the Apache v2 license A. Official package location, see Software license link B. Pricing/comparison page, see comparison licensing and terms link

Here are my opinions on those facts. There are two issues here I see-

  1. It is incorrect to say that Chocolatey has an open source edition which is exclusively under Apache v2. Saying choco.exe is open source is fine, as it is, in fact, FOSS in the open source edition. But it kind of looks like they are trying to hide the fact that they include a non-FOSS binary that has a EULA. The lack of transparency could be fixed with a few website tweaks, and in fact, probably everyone who cares about this probably has done the digging and already knows about this.

  2. Having Shimgen be under a EULA is a VERY VERY strong discouragement from forking Chocolatey. Shimgen is, in my option an integral part of Chocolatey. Almost every portable package uses it and some install packages use it. Furthermore, I do not know of any other similar program, so it may be a large amount of work to reproduce the functionality. Even it was recreated, it almost certainly would not be a drop in replacement, so packages would need to be re-tested and possibly re-built.

    The ability to fork a FOSS program is one of the major freedoms in FOSS, and the presence of a program restricted by a EULA takes that ability away to a large extent. It is the kind of thing that gives open core a bad name.


If you have any thoughts on this, or I am incorrect in anything, please post below.


Chocolatey testing environment winrm authentication errors

If you are getting Vagrant winrm authentication errors, it may be related to the default port being already in use. Try this to change the port that Vagrant uses-

Change in the Vagrantfile

 config.vm.network :forwarded_port, guest: 5985, host: 5985, id: "winrm", auto_correct: true
to
 config.vm.network :forwarded_port, guest: 5985, host: 5995, id: "winrm", auto_correct: true
and add
config.winrm.port = "5995"
Halt and restart Vagrant and see if it works.



Last update: 2020-11-07