25 ms·

One of its coolest features (just added in the latest release) is Gist Desktop Apps: https://sharpscript.net/docs/gist-desktop-apps https://sharpscript.net/doc

by mythz 7y ago

One of its coolest features (just added in the latest release) is Gist Desktop Apps: https://sharpscript.net/docs/gist-desktop-apps 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 https://youtu.be/FlKeaav0gt8

kevin_thibedeau 7y ago
I'll stick with the tried and true "curl attack_vector | sh".
- mythz 7y ago
  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.
  - merlincorey 7y ago
    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.
    - mythz 7y ago
      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
      - merlincorey 7y ago
        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?
        mythz 7y ago
        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.
        merlincorey 7y ago
        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`.
- merlincorey 7y ago
  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.
  - mythz 7y ago
    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-offline 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 [1] https://sharpscript.net/docs/gist-desktop-apps#github-sharp-app-commands https://sharpscript.net/docs/gist-desktop-apps#github-sharp-...
    - newacctjhro 7y ago
      The difference is that web apps are on a tight sandbox.
      - mythz 7y ago
        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.

by mythz 7y ago

kevin_thibedeau 7y ago

I'll stick with the tried and true "curl attack_vector | sh".

mythz 7y ago
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.
- merlincorey 7y ago
  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.
  - mythz 7y ago
    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
    - merlincorey 7y ago
      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?
      - mythz 7y ago
        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.
        merlincorey 7y ago
        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`.
merlincorey 7y ago
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.
- mythz 7y ago
  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-offline 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 [1] https://sharpscript.net/docs/gist-desktop-apps#github-sharp-app-commands https://sharpscript.net/docs/gist-desktop-apps#github-sharp-...
  - newacctjhro 7y ago
    The difference is that web apps are on a tight sandbox.
    - mythz 7y ago
      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.