Packaging scripts for PowerShell 7 and .NET Core - feedback

Anything you want to tell us? Praise? Criticism? Post it here. Please keep it professional and constructive.
Forum rules
Do not post any licensing information in this forum.
This topic is 3 years and 1 week old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked
User avatar
ALIENQuake
Posts: 112
Last visit: Mon Jan 29, 2024 7:35 am
Has voted: 4 times

Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by ALIENQuake »

Big thanks for you commitment in order to solver PS-related problems!
Microsoft’s release cycle is not supportable at this time. ... We also seriously doubt that any corporation or government entity will update its entire network to a new PowerShell version every month. Please let us know in the comments what your position on this is.
Agreed. At the same time, the ability to package scripts with new minor PS version allows for overcoming the limitation of system-wide PS. Right now, it's possible to have PS LTS as system-wide and for every new script/solution, the sysadmin can choose to package script as 'standalone'.
... a runtime installer can be found in the “Redistributable” folder. All PowerShell 7 applications packaged with this build will look for this runtime first before checking on a PowerShell 7 install folder.
Could you decouple this special PS Redistributable into separate 'component' in order to update it with new PS version? So you products can use newly provided "PS Redistributable" without need to update itself?
You can even deploy your PowerShell 7 applications with this runtime to computers that do not have PowerShell 7 installed at all.
This is very nice idea. Deploying packaged script/app will not alter system-wide PowerShell. I cannot stress enought how great this feature is.

But right now, users of PS-based GUI apps need to do following:
1.download and install "PS Redistributable Package"
2.download and extract zip file with "PS-based GUI" application

So how about one step further, for fully-flaged PowerShell Forms application:
Instead of downloading and installing "PS Redistributable Package", would it be possible to take the content of the "PS Redistributable Package" and put it directly (or with extra folder like "pwsh") into the folder with packaged app, as post-compile step? Then, the only thing which user needs to do is to extract zip file with application and that's it. Possible?
KFlaer
Posts: 16
Last visit: Fri Jan 13, 2023 5:09 am

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by KFlaer »

I am having the same concern/issue.

I do not see a means to include, or especially automatically install, those redistributables. All I get as a user is "Error: Cannot locate PowerShell 7 install folder".

Any guidance would be helpful.
User avatar
Alexander Riedel
Posts: 8479
Last visit: Thu Mar 28, 2024 9:29 am
Answers: 19
Been upvoted: 37 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by Alexander Riedel »

The installer is located in the re-distributable folder as indicated.
How you roll that or PowerShell 7.0.3 out across your network is something you should have control over.
If we were to include the runtime with each application we would simply recreate the scenario we have been trying to avoid in the first place.

I cannot stress enough that we created this option as a means to avoid a powershell 7 version dependency and to avoid having to include the entire PowerShell 7 folder (around 220 MB) with each application.
It is by no means required that you use the runtime. You can still simply install PowerShell 7.0.3 at any target machine and leave it at that.

If you do not want to roll out PowerShell 7.0.3 across your network and you do not want to roll out the runtime across your network, for whatever reason, you will not be able to use PowerShell 7 packaged executables. Or scripts for that matter as they obviously require a functioning PowerShell 7 install.

If you create an MSI installer for your packaged application, as you probably should, you can check in a custom action if the runtime or PowerShell 7 is installed and install it from a network location if needed.
The packaged exe itself will not do so and is not able to do that. It's a case of the egg has to be there before the chicken, so to speak.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
Alexander Riedel
Posts: 8479
Last visit: Thu Mar 28, 2024 9:29 am
Answers: 19
Been upvoted: 37 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by Alexander Riedel »

"So how about one step further, for fully-flaged PowerShell Forms application:
Instead of downloading and installing "PS Redistributable Package", would it be possible to take the content of the "PS Redistributable Package" and put it directly (or with extra folder like "pwsh") into the folder with packaged app, as post-compile step? Then, the only thing which user needs to do is to extract zip file with application and that's it. Possible?"

While this is possible, I am not quite understanding the reasoning behind it. It appears to be designed to avoid installing anything and simply zip deploy applications with their own full and private Powershell version.
Aside from a colossal waste of disk space, it also creates huge security implications. PowerShell is a powerful tool that is already used in many malware attack vectors. Bypassing installers, which usually require elevation and thereby admin access, just creates more back doors to exploit. I hope you understand that we are VERY hesitant to create any mechanism that can then be exploited easily for attacks.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
ALIENQuake
Posts: 112
Last visit: Mon Jan 29, 2024 7:35 am
Has voted: 4 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by ALIENQuake »

While this is possible, I am not quite understanding the reasoning behind it. It appears to be designed to avoid installing anything and simply zip deploy applications with their own full and private Powershell version.
Aside from a colossal waste of disk space, it also creates huge security implications. PowerShell is a powerful tool that is already used in many malware attack vectors. Bypassing installers, which usually require elevation and thereby admin access, just creates more back doors to exploit. I hope you understand that we are VERY hesitant to create any mechanism that can then be exploited easily for attacks.
Yes, I want my app to use their own private PowerShell version, distributed along with application itself (similar to NET Core 'self-contained' model) but without extra 'install PS runtime' step (current solution). If there is a local, private PowerShell version, the global "PS Runtime" should be ignored.
The search order would be: Local PS > Global PS Runtime > Global PowerShell.

Not every script/app needs to have installer/msi and even when they do, they don't require admin rights. My app doesn't require admin rights.

Regarding seciurty: every Windows OS has global PowerShell. The "PS Runtime" is an extra PowerShell copy. How second "PS Runtime" can be huge security implication if there already one or two (or more) copies of PS?
User avatar
Alexander Riedel
Posts: 8479
Last visit: Thu Mar 28, 2024 9:29 am
Answers: 19
Been upvoted: 37 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by Alexander Riedel »

I understand that this is what you want, but you didn't really provide any business reason as to why. You don't have to if you don't want to of course.

Regarding security: Windows PowerShell is in the Windows System folder, PowerShell 7 is installed under program files, so is our runtime. All of these folders are protected folders, meaning that they cannot be modified by a regular user, it requires admin rights to add or modify to that.
Your request indicates you want to install full fledged copies of PowerShell in user modifiable folders. It creates a simple attack vector as it would allow to modify core powershell components to be modified without a users knowledge. All it has to do now is wait for the right time when an admin logs on and uses that app. Or it can try to pop up an elevation request for the real Powershell. Endless possibilities.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
ALIENQuake
Posts: 112
Last visit: Mon Jan 29, 2024 7:35 am
Has voted: 4 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by ALIENQuake »

Thank you for detailed clariffication. If that's the case, I will gladly follow more secure way of distribution.
KFlaer
Posts: 16
Last visit: Fri Jan 13, 2023 5:09 am

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by KFlaer »

Yes, same. Thank you for the clarification and highlight of the security concerns around that model. We'll pursue another direction less vulnerable.
User avatar
ALIENQuake
Posts: 112
Last visit: Mon Jan 29, 2024 7:35 am
Has voted: 4 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by ALIENQuake »

Last question:
If we were to include the runtime with each application we would simply recreate the scenario we have been trying to avoid in the first place.
It's possible to embedded in the executable itself and then executed internally. As far as I see it, it will solve security concerns which 'local extracted PS' has. But you wanted to avoid this scenario at any cost, even if it would be perfect for my user case. I guess a feature which wouldbe used by 1-2 devs is not worth the effort?
User avatar
Alexander Riedel
Posts: 8479
Last visit: Thu Mar 28, 2024 9:29 am
Answers: 19
Been upvoted: 37 times

Re: Packaging scripts for PowerShell 7 and .NET Core - feedback

Post by Alexander Riedel »

Apologies for the late reply, I did not see the new post until now.
For the .NET framework there was a tool that allowed you to pre-link all referenced assemblies into one humongous executable. Not that it was of much benefit, but it was an exercise in "Look what I can do".
I have no idea whatsoever if something like that exists or is planned for .NET Core.
We did not get many requests for this, you are correct and none of folks making that request has so far provided some business case for it other than "I just want one one executable file"
without any further plausible reason. (My apologies to anyone who sent one and I missed it)

The very idea collides with everything shared frameworks have accomplished.
As one example, if the .NET framework, Microsoft runtime, Microsoft Foundation Classes or .NET Core get updated via Windows update with the latest security patches, all applications using these frameworks instantly benefit from that.
Creating monolithic applications that include a specific version of any of these are counterproductive to security updates, because they do not participate in them.
Given the current state of affairs we would need more and better security rather than trying to navigate around them and disable what we have.

I hope you understand that this nothing personal, but I simply do not understand the desire or benefit of such a scheme. It just provides no benefit I can see and has so many drawbacks that work against it.

So I am sorry to tell you that it is quite unlikely that we would spend time developing something like that.
Alexander Riedel
SAPIEN Technologies, Inc.
This topic is 3 years and 1 week old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked