I got the following query in one of my Google hits today: "pipeline.Invoke() "Read-Host" Cannot invoke this function because the current host does not implement it."

I believe that this query was in reference to the lack of host functionality in the default settings for a runspace in Windows Powershell. I don't recall ever actually taking much about this, yet I am known for having abstracted the runspace API for use as a multi threading interface in Powershell. Now is a good time to talk some about this.

A runspace in Powershell is a big blob of information that pertains to a particular shell within Powershell. The runspace has several components within it, such as the cmdlets, aliases, functions, providers, etc. The host component specificly is ment to be used as an abstract interface to the console. The default host object used by a runspace doesn't have much functionality, so you may encounter error messages like the one above when you are using a generic host object.

It is possible to tell Powershell what host object should be used when the runspace is initialized. I do know that version 1.0 of powershell.exe will use a host that writes to the console used by the powershell.exe process. Since most other instances of Powershell don't have a console the host object will often be the default host object, that doesn't provide any functionality on its own, or a very simple host object, using only implementing a few methods in the PSHostUserInterface class.

From the query above it looks like this googler was trying to use Read-Host within an asynchronous runspace. The easy solution to this is to just not do so. It's easier, in most cases, to simply pass the needed information into the asynchronous runspace from the parent runspace. However, there are still some cases where you must use Read-Host from an asynchronous runspace. In that case you'll have to code and compile your own host class, and use that when initializing the runspace.

I finally added support for GnuPG to Library-StringCrypto. The previous functionality to encrypt strings in process is still present and continues to work as expected. Not a couple more parameters have been added to support symmetric and asymmetric encryption using GnuPG.
The new parameters are 'gnupg', to enable use of gpg.exe, and 'recipient', to identify the person the encrypted message is for. When using GnuPG passwords/passphrases may be supplied in 'password' parameter or via the console to the gpg.exe process.

To use symmetric encryption, with GnuPG just add the gnupg switch parameter.

Write-EncryptedString message secret -gnupg

You can also omit the password from the command line and enter it interactivly.

Write-EncryptedString message -gnupg

To use asymmetric encryption, omit the password and use the recipient parameter.

Write-EncryptedString message -gnupg -recipient 'John Doe'

Write-EncryptedString returns the ASCII armored version of the ciphertext. Read-EncryptedString will be able to detect the ASCII armor and automatically process it using gpg.exe. Decryption should just work as expected. The password parameter can be used for both symmetric and asymmetric encrypted messages. Also the passphrase may be interactively entered via the console to gpg.exe.

Usage notes: The command 'gpg' is expected to resolve to gpg.exe, so you may need to add a path entry or alias gpg to wherever your copy of gpg.exe is.
When the password is given via the password parameter, it is passed to gpg.exe as the first line of its standard input. This means the password will not show up in its command line. This also means that passphrases are limited to one line. No check is performed to ensure the password is not longer than one line. If the passphrase is longer than one line then only the first line will be used as key material, the rest will appear at the start of the decrypted message.

Some cryptanalytic stuff: Using GnuPG via this script should be no less secure than using GnuPG by any other method in Powershell. However, because this involves communication with another process, using GnuPG does have a larger attack surface for side channel attacks than simply performing the encryption using the CLR. i.e. Either your installation of the .NET Framework or your installation gpg.exe may be compromised, but gpg.exe alone being compromised does not effect the .NET Framework.

Download Library-StringCrypto.ps1 here.

Every time I hear about ACTA I become violently sick. The fact that it continues to be "negotiated" in secret makes it a violation of the sovereignty of any government that would sign it. I dearly hope that it never goes into effect.