RFC0018-Add-cmdlet-Get-StringHash

[iSazonov]

Committee voted to accept this RFC, moved to https://github.com/PowerShell/PowerShell-RFC/blob/master/2-Draft-Accepted/RFC0018-Get-StringHash.md

[iSazonov]

@SteveL-MSFT Could we rename the file to RFC0018-Get-StringHash.md ?

[SteveL-MSFT]

@iSazonov yes, sorry missed that

[SteveL-MSFT]

I expect a lot of usage of this cmdlet will be with rest APIs, but they expect the hash to be base64 encoded. We should add a -base64 switch to get the output as a string in base64 or perhaps add a base64 property to StringHashInfo.

[DerpMcDerp]

Instead of Get-StringHash why not:

1. Rename Get-FileHash to ConvertTo-Checksum and either remove Get-FileHash or add an alias to it.
2. Make ConvertTo-Checksum work like Format-Hex so it can accept all sorts of input formats.

[iSazonov]

@SteveL-MSFT We could add Base64 to algorithm strings and utilize -Algorithm parameter.
(If we could consider to support a dynamic hash names list in the cmdlet we would request the CoreFX to add Base64 to HashAlgorithmName Structure

@DerpMcDerp Thanks for your proposal! It is a breaking change, you can see comments in #3024.

[rkeithhill]

Following the monadic principles PowerShell was founded on, I believe rather than shoe-horn base64 support into this command, PowerShell really should have ConvertTo/From-Base64 commands. PSCX has had these commands for a long time. They, or something like them, should be ported to PowerShell. I expect this should be, along with ConvertTo-LineEnding (-CR, -LF, -CRLF or -Windows -Linux -Mac), standard PowerShell utility commands.

For instance, this is all in PSCX and this is what I do:

37:53ms> "Open Sesame" | Get-Hash -Algorithm SHA1 -StringEncoding ascii | % Hash | ConvertTo-Base64
+Uej3RwAtLK2bgX8FNLY4o4pRv4=

Admittedly, I'd rather not have to do the % Hash but Get-Hash came way after ConvertTo-Base64. :-)

[rkeithhill]

I think this command should take not only string input but byte[] as well - primarily because A) folks may have byte data that isn't a string and not in a file that they want hash and B) Get-FileHash doesn't make this scenario easy (either create a file from the data or drop down to .Net MemoryStream, blech).

If we decide this command should accept byte[] input as well, should we reconsider changing the name to Get-Hash? Or just accept it as a bit of a "quirk" that the Get-**String**Hash command also accepts byte arrays that do not correspond to a string. Also, the Encoding parameter should be ignored for byte[] input. And perhaps the InputString parameter changes to InputObject (of type PSObject)?

[DerpMcDerp]

I think the bigger issue here is that it's common to have a cmdlet that operates on streamed in binary [byte[]] blob data but you also sometimes want to add conveniences for:

-LiteralPath [string]
-Path [string]
-InputObject [IO.Stream]
-InputObject [string] -Encoding [Text.Encoding]
-InputObject [string] -Base64

And also have it be future proofed so that new conversion methods are automatically handled by all binary blob handling cmdlets.

PowerShell lets cmdlets written in C# handle this problem by having a base class cmdlet that takes care of the whatever to [byte[]] conversion and supplying it to the derived class which just works on streamed in [byte[]]s.

But scripters writing advanced functions in PowerShell have no easy way to do that so we all end up having to roll our own but in inconsistent ways. As an example, Get-FileHash and Format-Hex could have been derived from the same base if PowerShell worked differently but the programmers who wrote it were forced to do it manually in poor and incompatible ways rather than reusing code.

I should also mention that .NET has work in process items to make pipelined conversion operators more memory efficient and convenient:

New .NET APIs

Which should be of interest to PowerShell implementers.

[iSazonov]

@rkeithhill We could avoid ConvertTo-Base64:

"Open Sesame" | Get-Hash -Algorithm Base64 -Encoding ascii -HashOnly
+Uej3RwAtLK2bgX8FNLY4o4pRv4=

@DerpMcDerp @rkeithhill
When I was rewrite Get-FileHash cmdlet on C# I tried to expand it to support InputObject, but it was a breaking change. If we agree on a new Get-Hash cmdlet, then I guess it's really do and then convert Get-FileHash cmdlet on this base.

[rkeithhill]

Well I don't consider Base64 to be a "hash" algorithm. Base64 is just one (popular) way to encode bytes as a string.

[iSazonov]

Therefore, we should move Base64 from the cmdlet in encoding cmdlets.(?)

[rkeithhill]

Yup. Just like Linux has the base64 util, PowerShell should have ConvertFrom/To-Base64 commands. Handy if you want to base64 encode something bytes that have nothing to do with a hash.

[iSazonov]

We already have a request on encoding cmdlets. So partial conclusion is to move Base64 into something like ConvertTo-Base64 or ConvertTo-Encoding -FromEncoding ascii -ToEncoding Base64.

[rkeithhill]

I believe those should be separate commands: ConvertFrom/To-Base64 and Convert-Encoding. And yeah, both probably would be useful. :-)

[iSazonov]

Maybe we start new Issue for this cmdlets to create later relevant RFC?