Hacker News Reader

Comment by voltagex_ | Hacker News Reader

>iex (new-object net.webclient).downloadstring('https://get.scoop.sh')

>Note: if you get an error you might need to change the execution policy (i.e. enable Powershell) with set-executionpolicy unrestricted -s cu

The Windows equivalent of curl | sudo bash...

Please don't do this. Sign your Powershell scripts.

View on HN

Powershell really is crippled by default, unlike bash. Your equivalent is only equivalent (the sudo part) if you start powershell with 'run as administrator', which you probably shouldn't, but it's quite common practise because Windows doesn't have a good, convenient equivalent to sudo. Luckily you can install one with 'scoop install sudo'.

Note you don't need to run as admin to install scoop--it's all about installing stuff for your user account without requiring elevation.

You are right though that you probably shouldn't just run scripts like this if you don't trust them. I do it all the time because it's convenient and I'm not running elevated. You can always check the source if you're not sure.

PowerShell is designed for Windows/Exchange administrators and SQL Server DBAs, and not really any one else. It's powerful when used by those roles due to all the time spent by Redmond and others developing the commandlets for these specific process. Outside of this problem realm it sucks as a scripting language or a CLI environment.

In many organisations, the security advice is to force AllSigned via group policy - this script will never run.

My condolences to anyone reading HN who works for one of these organisations.

The iex [remote-script] probably will run in that case actually, just not the 'scoop' command. Which shows what a farce the PS execution policy is.

If I think about it tonight I'll build you a version that checks its own hash, then signs itself if possible. That way your script will have even more reach. No need to be dismissive

I'm impressed by your ability to ignore good advice and common sense.

I presume you haven't been in an organisation where all the hot new things come in and screw things up with this kind of thinking?

In general you just get that lot trained when the next wave are incoming...

Sounds like bad organizations to work for.

Or organisations that don't want Joe user (that includes Joe developer who thinks he understands security but does not) running random powershell scripts off the Internet written by god-knows-who that have access to COM, their AD and local file systems and might just POST it all to some remote web site. Or even ones that download packages off the Internet that may have licensing implications or malicious bundling.

I assume no one is old enough or so far away from reality that they don't remember the hell that was VBA and macros in the late 90's and early 00's?

They're very sensible organisations IMHO.

Theyre not oppressive and to be shunned. They just take data protection seriously.

If you read HN and your organisation treats you like 'Joe user', I'd say you probably feel pretty oppressed.

Scoop is aimed pretty squarely at HN readers, not so much at people that are ok with working at an organisation that doesn't trust them to run programs on their computer.

Some of us work in compliance based industries where its a necessity rather than a choice. We still use what could be considered a favourable stack on HN but we deal with masses of sensitive personal data. We're not oppressed: we're professionals. Big difference.

We trust people to run programs on their computer, just not ones that download other programs and ones that have dubious signing or security policies.

The prevailing attitude amongst startups and even big businesses of blasting everything carelessly with shotguns because it's the latest and greatest needs to die. Quality and therefore trust is suffering.

What about bat files? vbs? exes? they aren't dis allowed by default. If an organization has reason for being very paranoid it should try to ban all of those. But the os default should be to allow scripts to run.

I think you missed my point.

It's not the type of the file but the source of the file that is the issue.

It is also that these sorts of scripts are the source of many untrusted, unsigned and unverified files as well and you cannot necessarily trust the canonical source of them either.

If some random guy gave you some pain killers on the street, would you take them? Probably not. That's exactly what this problem is.

There has to be a balance. A lot of NuGet scripts aren't signed or are signed with a MS cert that's different from their normal code signing ones.

Yes and we don't allow use of NuGet due to this amongst other reasons.

Reply on news.ycombinator.com