Execution Policy for running BurntToast: best practice

[Kallahan23]

Hi,

I'm coming from Windows Subsystem for Linux, and was trying to figure out a way to generate notifications in Windows. That's when I stumbled across BurntToast. Ideally, I could create an alias to this Powershell command in WSL in order to generate Windows notifications from Linux. Sounded good in theory.

However, when I installed BurntToast in Powershell using Install-Module and tried to run it, I found that the script could not be loaded. Turns out the default Execution Policy (restricted) doesn't allow scripts to run.

I set my Execution Policy to RemoteSigned and Unblocked BurntToast.psm1 and that seemed to work. However, I feel like there must be a better way to get this to work without having to mess with Execution Policies. Is there?

I'm coming from a Mac and Ubuntu background (hence my use of WSL) and don't have much experience with Powershell (I literally learned about Execution Policies 30 minutes ago). What is considered best practice here in terms of security? Or maybe is there a different tool I should be looking at entirely?

[Kallahan23]

For people using WSL like I am, I think I found a better solution to the problem. Rather than changing the Execution Policy in Powershell, the alias in WSL can be set to:

alias toast='powershell.exe -executionpolicy bypass -command New-BurntToastNotification'

This way, Powershell can stay restricted but WSL will still be able to call the script.

The original question still stands I guess for people using BurntToast inside Powershell itself.

[Windos]

Hey @Kallahan23, was just starting to type up a reply when your update came through. Glad to see it working for you now!

This is actually the first time I've seen someone try and use toast notifications from WSL, and it hasn't been something I'd tested before!

I'll be back in a little bit with an actual answer (if not just furthering the discussion)...

[Windos]

Welcome to PowerShell (and by extension Execution Policies). They are the first hurdle many, many, people run into with PowerShell.

By default on Windows 10 (at least Windows PowerShell, I need to double check with the open source variants on Windows) the execution policy is set to Restricted and the first time you go to run almost anything (that didn't ship with Windows) you'll hit the same error message you got.

On Windows server the default is RemoteSigned and on non-Windows platforms it's Unrestricted.

One thing that's important to know: Execution Policies aren't a Security Feature (Also see this tweet)

Personally, the first thing I do on all new Windows 10 machines I touch is set the execution policy to RemoteSigned. This allows me to run any modules installed from the PowerShell gallery with Install-Module, but does mean I have to unblock scripts downloaded via other means (if they aren't signed with a code signing cert).

As far as "best practice" goes, RemoteSigned would be my suggestion, I find it to be a good balance between not being an inconvenience and stopping "oops, I didn't mean to run that" moments.

I hope that answers the question? I can sometimes run off on tangents... feel free to ask followup questions!

[Kallahan23]

Thanks for the explanation! Good to know

[williscool]

Big hearts to both of you guys for the great explanations and solutions here @Windos and @Kallahan23

I wrote an example script I use in my own wsl scripts for those who are new to this

https://github.com/williscool/my_confs/blob/master/wsl-notification.sh

[Windos]

Hello, and thank you for your contribution to BurntToast.

Today marks the official release of BurntToast v1.0.0. As part of this major milestone and to ensure the project starts its next chapter with a clean slate, I am declaring "issue bankruptcy."

This decision is explained in more detail in the official announcement post: Ten Years Toasting: BurntToast Hits the Big v1!

As a result, I am closing all outstanding issues and pull requests (and discussions), including this one. Please do not interpret this as a lack of interest in the problem, suggestion, or topic you've raised. This is a necessary step to clear a very old backlog and focus development efforts on the current state of the module.

If this topic is still relevant to you:

1. Please open a new discussion. You are welcome to link back to this one for historical context.

I hope this reset will allow me to be more responsive to community feedback going forward.

Thank you for your understanding and for being part of the BurntToast journey.