Add a non-Eval alternative for Content Security Policy compatibility

[vldmr1986]

Refactoring: remove "eval" from library

• Bug Report: Content-Security-Policy

Prerequisites

• **Can you reproduce the issue?: YES
• **Did you search the repository issues?: YES
• **Did you check the forums?: no
• **Did you perform a web search (google, yahoo, etc)?: yes

Description

Steps to Reproduce

1.Server set header: Content-Security-Policy: default-src https:
2. Load vendor.js to the client
3. Trying to .parse() with pegjs:
Error(chrome dev tools): Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval'". Either the 'unsafe-inline' keyword, a hash ('sha256-NALaJ5yL9XVYFNSX8jAdayjJGG7VDRjzVeu1AYf0Kx0='), or a nonce ('nonce-...') is required to enable inline execution.

Software

• PEG.js: ^0.10.0
• Node.js: 8.12
• NPM or Yarn: 6.41
• Browser: Chrome 77, Safari, Firefox
• OS: Mac OS, Ubuntu

[YemSalat]

This does not look like an issue with pegjs.
Are you loading your scripts from an unsecure source (http?)

[vldmr1986]

I can reproduce this on the http and https protocols. It's all about security policy. If the code uses the eval function, then it will not be executed, the browser will block its execution
I have a workaround for that, but it is not secure.
More details about security policy:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

[YemSalat]

Your link is for http headers. You are in control of whatever headers you send on your server.

[vldmr1986]

Yes, this header is related to security, but which application in 2020 will not think about security. It's quite a common practice to use this approach in a modern web application.
I googled a bit and noticed that popular libraries have already made this update.
So, I do not think that many applications will ignore security in the future, and select appropriate tools that will be consistent with this.

[YemSalat]

Pegjs is a parser generator, it is a bit of a separate breed of JS libs,
How would JS inside grammar work without evaling it?

[bd82]

See: acornjs/acorn#90

[YemSalat]

I dont think that is a good solution for a parser generator. Performance is pretty important here after all.

[langpavel]

I'm missing context in this issue. Can anybody finger-point at piece of relevant code?

[futagoza]

I think it's worth adding a non-eval alternative for Content Security Policy compatibility; will see into this at some point before 0.12 by adding another bundle (maybe named dist/peg.csp.js) via a new entry file to be consumed by Webpack only

[StoneCypher]

Probably don't make it webpack only. This problem isn't webpack specific, and webpack is rapidly on the decline, in favor of rollup and parcel

[StoneCypher]

Honestly, there's no particular reason to leave eval in place if any alternative is provided. It's not like it's somehow faster, as oddly suggested above. Quite the opposite

[StoneCypher]

This should not be flagged not-a-bug. It is, in fact, a severe bug.

[roper79]

Dears, is there some solution looming? I now hit this problem hard with using peg.js for Chrome Extension development: Manifest V3 does not allow unsafe-eval any more...

[hildjj]

@roper79 can you try your use case on Peggy please? If it's still an issue there, we'll fast-track a fix if possible.

[roper79]

Thanks for your prompt and forthcoming answer, @hildjj! I did not know about this successor. Unfortunately, it is still an issue there, I will create a ticket there.