3 ms·

They mention shar in the readme: > shar (https://en.wikipedia.org/wiki/Shar https://en.wikipedia.org/wiki/Shar) - old school method that has the major security

by fwip 6y ago

They mention shar in the readme: > shar (https://en.wikipedia.org/wiki/Shar https://en.wikipedia.org/wiki/Shar) - old school method that has the major security flaw of potentially running any shell command

hnlmorg 6y ago
> has the major security flaw of potentially running any shell command Stamp has the major security flaw of potentially running any node.js module, which in turn could then invoke any shell command. Stamp has also seen more production usage as opposed to Stamp which is far from battle tested. So who knows what exploitable bugs lurk inside.
nulbyte 6y ago
Incidentally, this is exactly the behavior on which this project relies: > #! /usr/local/bin/node --use_strict /usr/local/bin/tree This has additional dependencies. I don't see much of a benefit here.
- fwip 6y ago
  Disclaimer: I've never used this tool, today is the first time I've heard about it. Reading the shebang of a stamp file is a lot easier than scanning a bash file for any sneaky obfuscations (including any custom logic that the author may have "helpfully" included). Alternately, the security-conscious can execute it directly as `node --use_strict /usr/local/bin/tree my.stamp`.
  - breck 6y ago
    > Reading the shebang of a stamp file is a lot easier than scanning a bash file for any sneaky obfuscations This. However, the feedback in this thread is right. Looking back over the past few years, I almost never used stamps as executables. Generally I always use it as a library, or via something like `unstamp someStampToExpand.stamp`. So the shebangs and executability of stamp files were stupid, and added a lot of complexity for almost no gain. I've just gone ahead and removed them. I think now it should be a little clearer how easy it is to write stamp functions in other langs.

3 ms·

They mention shar in the readme: > shar (https://en.wikipedia.org/wiki/Shar https://en.wikipedia.org/wiki/Shar) - old school method that has the major security

by fwip 6y ago

hnlmorg 6y ago
> has the major security flaw of potentially running any shell command Stamp has the major security flaw of potentially running any node.js module, which in turn could then invoke any shell command. Stamp has also seen more production usage as opposed to Stamp which is far from battle tested. So who knows what exploitable bugs lurk inside.
nulbyte 6y ago
Incidentally, this is exactly the behavior on which this project relies: > #! /usr/local/bin/node --use_strict /usr/local/bin/tree This has additional dependencies. I don't see much of a benefit here.
- fwip 6y ago
  Disclaimer: I've never used this tool, today is the first time I've heard about it. Reading the shebang of a stamp file is a lot easier than scanning a bash file for any sneaky obfuscations (including any custom logic that the author may have "helpfully" included). Alternately, the security-conscious can execute it directly as `node --use_strict /usr/local/bin/tree my.stamp`.
  - breck 6y ago
    > Reading the shebang of a stamp file is a lot easier than scanning a bash file for any sneaky obfuscations This. However, the feedback in this thread is right. Looking back over the past few years, I almost never used stamps as executables. Generally I always use it as a library, or via something like `unstamp someStampToExpand.stamp`. So the shebangs and executability of stamp files were stupid, and added a lot of complexity for almost no gain. I've just gone ahead and removed them. I think now it should be a little clearer how easy it is to write stamp functions in other langs.