chore(deps): bump handlebars from 4.1.2 to 4.7.7

[dependabot[bot]]

Bumps handlebars from 4.1.2 to 4.7.7.

Changelog

Sourced from handlebars's changelog.

v4.7.7 - February 15th, 2021

• fix weird error in integration tests - eb860c0
• fix: check prototype property access in strict-mode (#1736) - b6d3de7
• fix: escape property names in compat mode (#1736) - f058970
• refactor: In spec tests, use expectTemplate over equals and shouldThrow (#1683) - 77825f8
• chore: start testing on Node.js 12 and 13 - 3789a30

(POSSIBLY) BREAKING CHANGES:

• the changes from version 4.6.0 now also apply in when using the compile-option "strict: true". Access to prototype properties is forbidden completely by default, specific properties or methods can be allowed via runtime-options. See #1633 for details. If you are using Handlebars as documented, you should not be accessing prototype properties from your template anyway, so the changes should not be a problem for you. Only the use of undocumented features can break your build.

That is why we only bump the patch version despite mentioning breaking changes.

Commits

v4.7.6 - April 3rd, 2020

Chore/Housekeeping:

• #1672 - Switch cmd parser to latest minimist (@​dougwilson

Compatibility notes:

• Restored Node.js compatibility

Commits

v4.7.5 - April 2nd, 2020

Chore/Housekeeping:

• Node.js version support has been changed to v6+ Reverted in 4.7.6

Compatibility notes:

• Node.js < v6 is no longer supported Reverted in 4.7.6

Commits

v4.7.4 - April 1st, 2020

Chore/Housekeeping:

• #1666 - Replaced minimist with yargs for handlebars CLI (@​aorinevo, @​AviVahl & @​fabb)

Compatibility notes:

... (truncated)

Commits

• a9a8e40 v4.7.7
• e66aed5 Update release notes
• 7d4d170 disable IE in Saucelabs tests
• eb860c0 fix weird error in integration tests
• b6d3de7 fix: check prototype property access in strict-mode (#1736)
• f058970 fix: escape property names in compat mode (#1736)
• 77825f8 refator: In spec tests, use expectTemplate over equals and shouldThrow (#1683)
• 3789a30 chore: start testing on Node.js 12 and 13
• e6ad93e v4.7.6
• 2bf4fc6 Update release notes
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

[sezanzeb]

I think I wrote the macro system because I didn't want to bother with all the security implications

[jonasBoss]

I think I wrote the macro system because I didn't want to bother with all the security implications

That makes sense, but I think running as a different user should solve those issues. And we don't need to send all keys to the macro process, just the ones that trigger or release a macro.

---

currently my proof of concept has a different implementation for global variables:

User code:

global a

for _ in range(5):
    key("a")
    key(KEY_B)
    a = 5
    if a == 5:
        key("c")

After AST conversion:

for _ in range(5):
    key("a")
    key(KEY_B)
    shared["a"] = 5
    if shared.get("a") == 5:
        key("c")

I think using the global keyword is more natural.

---

How do you feel about bumping python to 3.10? Python 3.10 comes with structural pattern matching, which is super handy for inspecting the AST.

That would mean we are no longer compatible with ubuntu 20.04 (22.04 has a python 3.10 package).

[sezanzeb]

or if_tap could become

await next_event()
if is_tap():
    ...

is_tap looks at the most recent events to decide its return value

---

I want variables to be local by default, and shared only if explicitly needed

[sezanzeb]

I maybe would still sanitize it to remove all network and file-system calls. better safe than sorry

And assertions that check

• if M is really not running as root
• that the "Input-Remapper-Macro" user is not in any security group
• that the pipe P is not readable and writable by others.

If any of those fails, input-remapper refuses to work.

[jonasBoss]

I want variables to be local by default, and shared only if explicitly needed

That is the default python behavior. The user needs to explicitly declare a variable as global input-remapper mimics this default behavior of the global keyword by converting every access of a global variable to a lookup in the SharedDict.

---

I maybe would still sanitize it to remove all network and file-system calls. better safe than sorry

probably a good idea

---

If any of those fails, input-remapper refuses to work.

It is probably sufficient to kill M, log the issue and let all macros fail.

[sezanzeb]

That is the default python behavior. The user needs to explicitly declare a variable as global input-remapper mimics this default behavior of the global keyword by converting every access of a global variable to a lookup in the SharedDict.

What if a user needs global to work the way it works in regular python. I would not change the way pythons keywords work.

[sezanzeb]

Is there one macro process M per injection, or one running at all times once the service starts?

If there is only one process, then

• the SharedDict class could be simplified, using regular semaphores.
• M needs to keep track of configs and an identifier is sent to M each time a macro triggers to let it know which config to look up. The config is sent to M when the injection starts.
• Each message with an input-event sent to M needs to also contain that identifier, so that M knows for which macros this event is relevant
• There would only be one bidirectional pipe

If M is running per injection, then

• the config needs to be sent only in the beginning.
• there is one bidirectional pipe per injection
• the shared dict uses pipes

I tend to favor the second option

[sezanzeb]

When M receives an event, how does it make blocking async functions in the thread continue?

If multiple readers are on a pipe, will each reader read the message?

[jonasBoss]

Is there one macro process M per injection, or one running at all times once the service starts?

I was thinking just one M process. The M process runs a async event-loop and we convert all the macro scripts into async functions using some AST magic. So there is only one reader on the M side of the pipe.

I think I will work on it during the next days. I have multiple different ideas how it could work I just need to try out what works.

[sezanzeb]

That would mean we are no longer compatible with ubuntu 20.04 (22.04 has a python 3.10 package).

I would not be in favor

we convert all the macro scripts into async functions using some AST magic

Explain this a bit more please

[sezanzeb]

https://miro.com/app/board/uXjVPMFdVng=/?share_link_id=153119558080

I don't think there is any need for asyncio functionalities inside macros to provide anything the old system can do

[sezanzeb]

If this is not done right and ownership on pipes and processes is broken, or if sanitation has a flaw, it can be used to

• obtain passwords by exposing key events to a key-logger when pipe permissions are broken
• obtain passwords by writing input-events of the macro-thread to a file if sanitation is not flawless
• run arbitrary privileged code inside the macro when process ownership is broken
• inject arbitrary keystrokes via the pipe between "macro-runner" and "Macro Write", either because pipe permissions are broken, or because a macro changes the ownership of the pipe

Before something like this goes into a release, I would want more people to look at it and approve it.

I'm thinking about shipping the existing system (with the changes from #496) in 2.0 (and automatically migrating all old macros so that things continue to work without breaking anything)

A python-macro system would be a 3.0 version then, if this is a reasonably system at all from a security perspective

[sezanzeb]

I think Lua offers sandbox functionality out-of-the-box. If this is more secure than python for this or easier to implement in a secure way I'm in favor of using lua and against python as a macro language.

I don't know how good this sandbox mode is, maybe the proposed input-remapper-macro-service would be obsolete with it.

I have never written Lua and don't know how comfortable it is. I don't know how a python process would start a sandboxed lua script, I don't know anything except that sandboxing seems to exist.

If Lua is more complex to use than the existing custom language, maybe both can coexist and the user decides which one to use.

[sezanzeb]

• https://github.com/topics/embedded-scripting-language?o=desc&s=stars
• https://github.com/dbohdan/embedded-scripting-languages
• many languages for this purpose exist, but I haven't been able to find a list of scripting languages that can easily and safely be sandboxed
• lua is popular

[blob42]

Hi @sezanzeb thanks for this project. I am using it a lot and the scripting feature would be helpful to me. I am comfortable with both Python and Lua. I am willing to prototype something. Is there some draft code for the scripting feature ?