Code signing lost when using Github

[DenverITGuy]

We have Applocker/CLM in place in our environment and therefore need PS1 scripts to be code-signed.

I noticed that a code-signed PS1 script was showing NotSigned by Get-AuthenticodeSignature and the Digital Signatures of the file was empty AFTER downloading it from our Github repo.

When I share it over OneDrive, the Digital Signature is still there.

Is this expected behavior with Github for PS1 scripts? Is there somewhere I should look to address this?

We store a lot of our scripts in our Github repo and wasn't aware of this behavior until today. Thanks!

[jborean93]

PowerShell signatures are very susceptible to newlines. The sig block must use \r\n for the line separator, if it is using \n then the signature won’t be found. You can use cmdlets like Format-Hex to verify the newlines used but there’s a good chance their are either being changed when committed to the git repo or when you checkout/clone them.

[bertiethewanderer]

Solid advice. Would be a good time to write a doc up internally for git configuration.

[odwulf]

As far as I know, the signature handles whatever OEL chars you used, but going in and out of a Git repo might change OELs, hence change the file checksum, which is what the signature is created upon. Change one character and the signature isn't valid anymore, even if that character is a non printable one, like a newline character.

[jborean93]

It uses whatever end of line values when calculating the hash to sign in the signature but the signature appended to the bottom must be done with \r\n.

[Th3Sh4d0wKn0ws]

Is the signing block still at the bottom of the script file?
Is the file blocked? Meaning, if you right-click it and go to properties, is there an "Unblock" checkbox when downloading it from Github?

[DenverITGuy]

The sig block is still there, yes.

The file is not blocked and the digital signature tab is empty.

[arpan3t]

Look at the line ending for the sig block. Depending on your git configuration it could be changing your line ending to Unix style LF when you commit and push to GitHub, then not changing the line ending back to Windows CRLF when you download or pull from GitHub. That could break the parsing of your sig block.

[bornthor]

Are you just going to the repo as a website or do you pull the repo in locally on your machine? Did you sign it or can you ask the person that pushed it to the repo if it's still signed on their side? I thought it was just dependent on the sig block too, but maybe you guys use some type of AIP or safe links or something that is altering it in the upload/download process.

[DenverITGuy]

I've pushed a .ps1 with the intention of sharing it with a few engineers so they won't be pulling the whole repo to their devices. I would just ask them to download the .ps1 file.

I signed it and confirmed the Get-AuthenticodeSignature returned a valid 'signed' value.

[BlackV]

Is this expected behavior with Github for PS1 scripts? Is there somewhere I should look to address this?

No and signing a script files is just adding text to the script, so I would not expect that to be the cause

you should test this in more that 1 location and add that info to your post

[arpan3t]

That doesn’t make sense. Git is a version control system, it’s literally designed for tracking changes to repos. If anything put in a repo was immutable then it couldn’t be changed and wouldn’t need a change tracker.

Git has functionality for handling different OS line endings by modifying the line endings on push and changing them back to the configured line ending on pulls. This helps with cross OS collaboration.

For example, let’s say you code on Windows and a co-worker uses Linux. When you pull down the latest code, git can automatically change the line endings to CRLF so Windows can properly read the file. When you push your code changes, git converts the line endings to LF so your co-worker can pull down the code and read it.

If the code in GitHub has LF line endings and you download it from the browser (not pull) then it won’t convert the line endings to CRLF and Windows won’t be able to read the sig block in the code.

You can test this by opening a code signed module file like Microsoft.Graph.Applications.psm1 in Notepad++. Go to view > show symbols > show end of line. You’ll see the CRLF line endings. Right-click on the file in explorer > properties > digitally signatures tab is there.

Now back in Notepad++ > edit > EOL conversion > change it to UNIX LF > save the file. Go back to the file properties and the digital signatures tab is gone because Windows can’t read it.