SharpScript(sharpscript.net)
sharpscript.net
SharpScript
https://sharpscript.net
52 comments
I'll stick with the tried and true "curl attack_vector | sh".
I imagine people are downvoting this because it's a joke, but aside from being a pretty good joke, it's actually surfacing a relevant security issue.
Is it really safe that these gists are "always up to date", meaning they can be updated without you necessarily being informed.
Essentially this is a `pad-left` situation all over again - micromodules controlled by other people can be deleted or changed at any time, and some of these micromodules may become very widely distributed and relied upon.
Is it really safe that these gists are "always up to date", meaning they can be updated without you necessarily being informed.
Essentially this is a `pad-left` situation all over again - micromodules controlled by other people can be deleted or changed at any time, and some of these micromodules may become very widely distributed and relied upon.
left pad is a transitive dependency issue, running an "Always up-to-date" version is no different to visiting a Website that can be shutdown at anytime, except once you've run a Gist App once, you can run it locally offline indefinitely:
https://sharpscript.net/docs/gist-desktop-apps#run-apps-offl...
So you have the flexibility of both options [1]:
https://sharpscript.net/docs/gist-desktop-apps#run-apps-offl...
So you have the flexibility of both options [1]:
web open App # downloads and runs latest version
web run App # runs local offline version
The difference is that web apps are on a tight sandbox.
The issue with leftpad was that it was a transitive dependency that was yanked and broke everyone depending on it. Gists don't have any dependencies, their encapsulated within the Gist where all code is easily inspectable and publicly verifiable, maintained by a verified GitHub User and all changes have a public audit trail.
Yes the sandbox is the difference between Desktop Apps and Web Apps, which is the point, Desktop Apps can do things Web Apps can't do and when you're running a Desktop App you're trusting the publisher just like you are with every other process running on your System.
Yes the sandbox is the difference between Desktop Apps and Web Apps, which is the point, Desktop Apps can do things Web Apps can't do and when you're running a Desktop App you're trusting the publisher just like you are with every other process running on your System.
What's the difference to running any installed software?
Except when running from a public Gist you can inspect all the Source code before running it, know which verified User Account the software is released under and have a public audit trail of all changes made to the Gist App.
Except when running from a public Gist you can inspect all the Source code before running it, know which verified User Account the software is released under and have a public audit trail of all changes made to the Gist App.
As stated in my sibling comment, the issue is akin to the Javascript pad-left fiasco.
Package systems (which this essentially is, just at the function level, so to speak) that do not enforce immutable versions are just waiting for exploitation by deletion or update-in-place.
Package systems (which this essentially is, just at the function level, so to speak) that do not enforce immutable versions are just waiting for exploitation by deletion or update-in-place.
Replied in sibling comment, you can run your local version and never update, you can also run a specific released version that is immutable:
https://sharpscript.net/docs/gist-desktop-apps#plugins
https://sharpscript.net/docs/gist-desktop-apps#plugins
Thanks for the update in the sibling comment, sounds like some of the concerns are already met.
Does the specification format describing which gist and version is a dependency I want to download using the versioned values by default, or does that require a specific switch / manual edit?
Also, what happens if the gist is deleted?
Does the specification format describing which gist and version is a dependency I want to download using the versioned values by default, or does that require a specific switch / manual edit?
Also, what happens if the gist is deleted?
Not sure what you mean by version dependency, Gist Apps don't have any dependencies, each Gist App is self-contained within its own Gist.
You can run a previous version of a "Released" App when it's published to a GitHub Repo by just opening the GitHub Release .zip URL.
You'll only be able to review the changes made to a Gist App, to run a previous version, you'll need to fork the Gist and revert the changes made to it up to the version you want to run. This is also how you want to ensure the Gist App is around forever, just fork the Gist and run your forked version (same also applies to Sharp Apps in GitHub Repos).
If the Gist is deleted you wont be able to "open" the latest version obviously, but you can still use "run" to run your previously run local version.
You can run a previous version of a "Released" App when it's published to a GitHub Repo by just opening the GitHub Release .zip URL.
You'll only be able to review the changes made to a Gist App, to run a previous version, you'll need to fork the Gist and revert the changes made to it up to the version you want to run. This is also how you want to ensure the Gist App is around forever, just fork the Gist and run your forked version (same also applies to Sharp Apps in GitHub Repos).
If the Gist is deleted you wont be able to "open" the latest version obviously, but you can still use "run" to run your previously run local version.
Thanks for making it clear the intended workflow is to fork a gist. I might recommend making that actually part of the application suite, even.
I guess I need to look deeper into how SharpScript does things to get the proper terminology going, but, by way of explanation, I use Python in my day job.
As such, I was thinking along the lines of "how do I deploy a SharpScript Gist App with several Gist dependencies?".
In Python-land this would minimally be a Python script in a file and a requirements.txt file.
The requirements.txt file typically is a line-delimited file that has package names (or URLs, importantly) with optional version specifiers.
Since the Python Package Index is immutable, if I specify package "foo==1.2.3", I can be relatively certain that I will retrieve that package and that version, even if there are newer versions or the author deletes their upstream source control repository.
Anyway, I'm basically wondering what the SharpScript Gist Application approach will be to say "This script depends upon these gists with these versions".
I'm advocating for the default method to always specify a particular immutable version of a gist, otherwise, you will run the risk of these "always updated" gists changing in unexpected ways including malicious ones that perhaps check to see if they are on a CI server and steal credentials, etc.
Circling back to the top, I think if the only route to be sure that you have a permanent and immutable copy of a Gist Application is to fork it, then I further advocate that the SharpScript tooling should make this as easy as `sharp fork url-to-gist`.
I guess I need to look deeper into how SharpScript does things to get the proper terminology going, but, by way of explanation, I use Python in my day job.
As such, I was thinking along the lines of "how do I deploy a SharpScript Gist App with several Gist dependencies?".
In Python-land this would minimally be a Python script in a file and a requirements.txt file.
The requirements.txt file typically is a line-delimited file that has package names (or URLs, importantly) with optional version specifiers.
Since the Python Package Index is immutable, if I specify package "foo==1.2.3", I can be relatively certain that I will retrieve that package and that version, even if there are newer versions or the author deletes their upstream source control repository.
Anyway, I'm basically wondering what the SharpScript Gist Application approach will be to say "This script depends upon these gists with these versions".
I'm advocating for the default method to always specify a particular immutable version of a gist, otherwise, you will run the risk of these "always updated" gists changing in unexpected ways including malicious ones that perhaps check to see if they are on a CI server and steal credentials, etc.
Circling back to the top, I think if the only route to be sure that you have a permanent and immutable copy of a Gist Application is to fork it, then I further advocate that the SharpScript tooling should make this as easy as `sharp fork url-to-gist`.
So Sharp Apps don't have any external dependencies, your App on load can fetch any additional external resources if it needs to, but that's independent to Sharp Apps. They're effectively run assuming everything is on Disk, the difference is that the files are sourced from a Gist and loaded in Memory.
One nice thing about Gists are that it scales nicely to support small fileset snapshots where all content is returned in the public API resource request, as well as supporting larger fileset snapshots where the contents of the gist are truncated and its contents are instead downloaded from its raw_url in an alternative HTTP Request. When you launch a Gist Apps it downloads all files (inc. truncated contents).
I don't intend to build forking gists into the App, it's not something I'd expect will get used a lot as most people are going to want to run the latest version of the App and get new features and bug fixes as soon as they're added. Those they want can fork Gists using GitHub's UI or APIs.
One nice thing about Gists are that it scales nicely to support small fileset snapshots where all content is returned in the public API resource request, as well as supporting larger fileset snapshots where the contents of the gist are truncated and its contents are instead downloaded from its raw_url in an alternative HTTP Request. When you launch a Gist Apps it downloads all files (inc. truncated contents).
I don't intend to build forking gists into the App, it's not something I'd expect will get used a lot as most people are going to want to run the latest version of the App and get new features and bug fixes as soon as they're added. Those they want can fork Gists using GitHub's UI or APIs.
I'm still kinda confused about what the purpose is, it at first sounded like it was a vba-replacement for any .net app but the examples all treat it like a regular scripting language.
It's multi-purpose: https://news.ycombinator.com/item?id=20742459
Is there a license page? I can't see one which is a shame.
It says on the home page that it's part of ServiceStack.Common, and covered by the same terms: https://servicestack.net/terms
Unfortunately, this appears to mean it is not free software (though it is gratis for some use cases).
Unfortunately, this appears to mean it is not free software (though it is gratis for some use cases).
The actual Project repo https://github.com/ServiceStack/ServiceStack appears to be AGPL3 with some exceptions, which probably explains why the info is buried
The Exceptions are for OSS projects, where it can be used as the OSS license for that project.
Regardless it's completely free to use for both commercial/non-commercial usage.
Regardless it's completely free to use for both commercial/non-commercial usage.
If that's your intent (free, in perpetuity), why not release it under Apache or GPL or something?
If I make project Foo, which leverages #Script, and make Foo MIT-licensed, by your statement #Script is now also MIT licensed in this project. So then Company Blah wants to use Foo, which happens to just be thin wrapper/modification around #Script, and is now permitted to take it and fork it into closed-source repos, yes? That is what this statement implies.
Regardless, this is why getting clever with software licenses, and giving guarantees in the form of comments instead of actual license legalese, is problematic. The intention might be clear, but the governance is only by law, and this appears to be in conflict with your statements.
Regardless, this is why getting clever with software licenses, and giving guarantees in the form of comments instead of actual license legalese, is problematic. The intention might be clear, but the governance is only by law, and this appears to be in conflict with your statements.
More broadly, "clever" software licenses really hamper adoption. Even if it's not exactly AGPL and it has lots of exceptions, the mere mention is enough to scare off many developers and companies.
Then forget this OSS license option even exists, which you're never going to use unless you build a custom distribution of ServiceStack without a commercial license. The AGPL/FLOSS license exists to allow free usage in OSS projects without needing to pay for a commercial license.
Regardless #Script is unrestricted and free under the commercial license, which is what all official ServiceStack NuGet packages are released under.
Regardless #Script is unrestricted and free under the commercial license, which is what all official ServiceStack NuGet packages are released under.
ServiceStack's usage in OSS projects is covered in its License: https://github.com/ServiceStack/ServiceStack/blob/master/lic...
i.e. It can be used as AGPL as-is, in addition it can be used in OSS projects under that license (to enable compatibility with the project) provided that the OSS Software remains OSS and provides complete source code for any additions. Although this AGPL/FLOSS Exception License only applies when you're creating your own distributions of ServiceStack from source code (i.e. very rare). This dual license option was added to allow OSS projects to use ServiceStack for free without paying for a commercial license, if that's not you, you can ignore this license option even exists.
All ServiceStack packages on NuGet are released under the commercial license [1] of which only requires a developer license when it exceeds the free usage quotas [2] which are only in ServiceStack commercial products namely the ServiceStack Web Service Framework, OrmLite [3], ServiceStack.Redis [4] and PocoDynamo [5]. All other ServiceStack Software inc. all client libraries, inc. Serialization and ServiceStack.Common (containing #Script) are unrestricted libraries which can be used for free without a commercial Developers license in both commercial/non-commercial projects.
[1] https://servicestack.net/terms
[2] https://servicestack.net/download#free-quotas
[3] https://github.com/ServiceStack/ServiceStack.OrmLite
[4] https://github.com/ServiceStack/ServiceStack.Redis
[5] https://github.com/ServiceStack/PocoDynamo#pocodynamo
i.e. It can be used as AGPL as-is, in addition it can be used in OSS projects under that license (to enable compatibility with the project) provided that the OSS Software remains OSS and provides complete source code for any additions. Although this AGPL/FLOSS Exception License only applies when you're creating your own distributions of ServiceStack from source code (i.e. very rare). This dual license option was added to allow OSS projects to use ServiceStack for free without paying for a commercial license, if that's not you, you can ignore this license option even exists.
All ServiceStack packages on NuGet are released under the commercial license [1] of which only requires a developer license when it exceeds the free usage quotas [2] which are only in ServiceStack commercial products namely the ServiceStack Web Service Framework, OrmLite [3], ServiceStack.Redis [4] and PocoDynamo [5]. All other ServiceStack Software inc. all client libraries, inc. Serialization and ServiceStack.Common (containing #Script) are unrestricted libraries which can be used for free without a commercial Developers license in both commercial/non-commercial projects.
[1] https://servicestack.net/terms
[2] https://servicestack.net/download#free-quotas
[3] https://github.com/ServiceStack/ServiceStack.OrmLite
[4] https://github.com/ServiceStack/ServiceStack.Redis
[5] https://github.com/ServiceStack/PocoDynamo#pocodynamo
#Script is not a product that's for sale. It's gratis for all use-cases.
It's completely free to use as mentioned at the bottom of the home page: https://sharpscript.net/#free
The source code for ServiceStack.Common is inside the https://github.com/ServiceStack/ServiceStack repo
The sharpscript.net website itself (written in #Script Pages) is at https://github.com/ServiceStack/sharpscript
The source code for ServiceStack.Common is inside the https://github.com/ServiceStack/ServiceStack repo
The sharpscript.net website itself (written in #Script Pages) is at https://github.com/ServiceStack/sharpscript
For now. That's how all of ServiceStack used to be. They don't have any problem changing the license for all future versions whenever they feel like it.
That’s how it will always be. You can’t retract an OSS license, and the old ServiceStack v3 you're referring to continues to be available 6 years later:
https://github.com/ServiceStackV3/ServiceStackV3
https://github.com/ServiceStackV3/ServiceStackV3
[deleted]
Mentions it at the bottom, but looks like you need to go here: https://www.nuget.org/packages/ServiceStack.Common
SS is a problematic extension from historical point of view...
Not the first use of this file extension:
https://filext.com/file-extension/SS
https://filext.com/file-extension/SS
Can this interface with nuget libs to crrate desktop apps as well? Can i use it with , say, sdl and create a pong game?
Yeah it's an embeddably dynamic scripting language that can be used within .NET Core / .NET Framework Apps:
https://sharpscript.net/docs/introduction
To use any library you just need to provide a script method exposing the functionality you want available in your #Script:
https://sharpscript.net/docs/methods
https://sharpscript.net/docs/introduction
To use any library you just need to provide a script method exposing the functionality you want available in your #Script:
https://sharpscript.net/docs/methods
That's fantastic! Color me interested.
Just want to point out that the maintainers should make this aspect more prominent in the home page as at a quick glance I thought SS is good only for creating apis/web servers.
Just want to point out that the maintainers should make this aspect more prominent in the home page as at a quick glance I thought SS is good only for creating apis/web servers.
Thx for the tip, made the feature more prominent in the home page: https://sharpscript.net
Is there any benefit to this over PowerShell?
Did you have a look at the features on https://sharpscript.net ?
The only time it compares with PowerShell is when it's used to execute Sharp Scripts [1] which is only 1 of its use-cases. You can embed it inside .NET/Core Apps [2], build entire Web Apps with #Script [3], run those Apps from a Gist on-the-fly without an install [4], deploy it on the Server without any CI [5], use it as a replacement to Razor [6], use it to develop Web APIs [7], use it to render emails [8], live documents [9], query Databases, HTTP APIs, AWS/Azure File Storage [1]. All with a familiar JS-expression syntax [10] that's highly extensible [11] and can run in a user-defined sandbox [12] where all functionality available to Scripts running in each Context can be controlled.
[1] https://sharpscript.net/docs/sharp-scripts
[2] https://sharpscript.net/docs/introduction
[3] https://sharpscript.net/docs/sharp-apps
[4] https://sharpscript.net/docs/gist-desktop-apps
[5] https://sharpscript.net/docs/deploying-sharp-apps
[6] https://sharpscript.net/docs/sharp-pages
[7] https://sharpscript.net/docs/sharp-apis
[8] https://sharpscript.net/usecases/email-templates
[9] https://sharpscript.net/usecases/live-documents
[10] https://sharpscript.net/docs/syntax
[11] https://sharpscript.net/docs/introduction#net-usage
[12] https://sharpscript.net/docs/sandbox
The only time it compares with PowerShell is when it's used to execute Sharp Scripts [1] which is only 1 of its use-cases. You can embed it inside .NET/Core Apps [2], build entire Web Apps with #Script [3], run those Apps from a Gist on-the-fly without an install [4], deploy it on the Server without any CI [5], use it as a replacement to Razor [6], use it to develop Web APIs [7], use it to render emails [8], live documents [9], query Databases, HTTP APIs, AWS/Azure File Storage [1]. All with a familiar JS-expression syntax [10] that's highly extensible [11] and can run in a user-defined sandbox [12] where all functionality available to Scripts running in each Context can be controlled.
[1] https://sharpscript.net/docs/sharp-scripts
[2] https://sharpscript.net/docs/introduction
[3] https://sharpscript.net/docs/sharp-apps
[4] https://sharpscript.net/docs/gist-desktop-apps
[5] https://sharpscript.net/docs/deploying-sharp-apps
[6] https://sharpscript.net/docs/sharp-pages
[7] https://sharpscript.net/docs/sharp-apis
[8] https://sharpscript.net/usecases/email-templates
[9] https://sharpscript.net/usecases/live-documents
[10] https://sharpscript.net/docs/syntax
[11] https://sharpscript.net/docs/introduction#net-usage
[12] https://sharpscript.net/docs/sandbox
And which of these things cannot be done with PowerShell?
if the author is reading, be aware that `.ss` is used by a lot of Scheme implementations.
He should have used '.sh'
Or the actual Sharp symbol. The plain octothorpe (#) is reserved and unavailable for filenames, but most Unicode-capable file systems should be fine with the Sharp symbol, and I'm sure that wouldn't be confusing at all
http://www.fileformat.info/info/unicode/char/266f/index.htm
ETA: Of course HN's own Unicode eater doesn't like the Sharp symbol in posts.
http://www.fileformat.info/info/unicode/char/266f/index.htm
ETA: Of course HN's own Unicode eater doesn't like the Sharp symbol in posts.
‘.ss’ is the most obvious ext for “SharpScript”, but that only applies for stand-alone scripts where you can also use .html extension since most of time it’s used as a template language inside HTML pages that’s embedded inside a .NET/Core App to provide dynamic scripting, in which case ‘.ss’ is never used.
When are we going to open up to `.s#`
The basic `#` is a reserved character in most shells (for comments, typically), and reserved in both POSIX file naming and Windows file naming conventions.
The similar looking Unicode Sharp, however is available.
The similar looking Unicode Sharp, however is available.
FWIW, in bash you can "vim hello.s#" without issue (for # to be a comment, it must be preceded by whitespace).
Could use 'sscr' perhaps? (although close to scr for screensaver files)
Unfortunate file extension name IMO, but I'm probably just old.
Hamburg’s car plates all start with HH and nobody cares (or at least I didn’t find anybody who does).
I knew a guy in Stuttgart who wanted a license plate “S-S” and got rejected.
https://sharpscript.net/docs/gist-desktop-apps
Where Sharp Apps can also be published to Gists where they can be run on-the-fly without installation, they're always up-to-date, have tiny footprints are fast to download and launch that can also run locally, off-line and cross-platform across Windows, macOS and Linux OS's.
YouTube demo: https://youtu.be/FlKeaav0gt8