Gambit is a risky scheme

(puns about "scheme" names are mandatory)

Neat: New version 4.9.4 of Gambit Scheme is out and they have a web site again after like 3 years.

OK: So I start adapting my little module/how do you run example: here

Bad: Not only does the R7 library system not work, their version of this hello example
will load code from fucking github at runtime! NPM viruses & sabotage are baked into the system. See Modules in Gambit at 30

SIGH.

4 thoughts on “Gambit is a risky scheme”

  1. Thanks for replying, Marc! I've fixed the paste onto my site. If you have any ideas, let me know. I just want to be able to import libraries locally! Something close to this works fine in Chibi.

    I'm not a fan of opt-out for even one whitelist, but at least that's less dangerous. But it's very surprising!

    1. Hi!

      I assume that most users of Gambit will not do a full code review of the more than half a million lines of code before using it on their computer. So it is a fair guess that they implicitly trust that the code they got on the github.com/gambit account does not contain malicious code (by the way thank you for trusting the Gambit maintainers, currently only Brad Lucier and myself!). The code that might be automatically installed (if one uses the default configure settings) is code from that same account. As I said, this can be turned off in various ways if you are uncomfortable with trusting the Gambit maintainers. This decision can also be taken by the maintainers of the "gambit" package for your OS when they write their package build script.

      Concerning your module example there are a few problems with your code.

      Firstly, in main.scm you are doing a (import (maintest worker)) so the Gambit runtime system expects to find this module in the default module search order directories which are ~~lib, the Gambit installation lib directory that contains builtin modules, and ~~userlib, that usually maps to ~/.gambit_userlib. Here there are several options. You could install your (maintest worker) module in ~/.gambit_userlib (please read the manual to see how to do this with the gsi -install command). For development, an interesting option is to add the CWD to the module search order, by adding . on the gsi command line or by using the runtime option search=. (either on the gsi command line or in the GAMBOPT environment variable). For your specific example you could do GAMBOPT=search=. ./main.scm or use the shebang line #!/usr/bin/env gsi-script -:search=. or #!/usr/bin/env gsi-script .. It would be very wrong for Gambit (or any Scheme system) to always assume that the interpreter can search for modules in the CWD as this might execute the wrong (malicious?) code if you have done cd somewhere/else ; ../../main.scm. If you want the Gambit runtime system to find the modules in the mods subdirectory next to a compiled executable program you can also set search=~~execdir/mods. There is currently no ~~scriptdir however to locate modules relative to a script, but this might be a future addition to Gambit if there's a need.

      The second problem is that the imported module's name, (maintest worker), indicates that this is a module whose source code is stored inside a directory named maintest in one of the module search order directories. You have the option of storing the worker.scm file in maintest/worker/worker.scm (the preferred place) or in maintest/worker.scm. So to fix the issue you need to mkdir maintest ; mv worker.scm maintest and execute GAMBOPT=search=. ./main.scm or any of the other options in the previous paragraph or simply gsi . main.scm, which is what I typically use during development. The . on the command line is a reminder that the modules being used by the program are not just the installed modules (so an installation step will be required when the code goes into production).

      If you encounter this situation again (module not found), you can turn on a debug flag that will trace the steps of the module search algorithm like this: gsi -e '(##debug-modules?-set! #t)' main.scm. I'm considering a more concise command line option to do the same.

    2. By the way, I would appreciate if you could update your blog post to better reflect the state of Gambit's module system. The modules you wrote for Gambit have maintest in their name, but not the Chibi modules. In fact if you take the exact same Chibi modules and execute gsi . main.scm you will get the same output as Chibi (which unfortunately includes . in its module search algorithm by default, a security issue similar to including . in your shell's PATH). One of the important goals of the R7RS effort was to have a library system that would be portable to multiple implementations of Scheme and for the most part it achieves this. Lets not take the small issues and blow them out of proportion.

      You might want to use the link https://gambitscheme.org/4.9.4/manual/#Modules for those interested in the details of Gambit's module system.

      Finally, I don't mind the "risky scheme" part in the title. Security is an important issue and automatic installation of modules from github.com/gambit raises valid security concerns for which I would like a discussion. The automatic installation feature is particularly useful for transparent code migration in a distributed system, and also to share modules of code transparently with trusted colleagues or simply from your own github/gitlab account.

  2. Your here link is broken, so it is hard to know exactly why Gambit is not working with your code.

    Concerning the automatic installation of modules feature, please note that it only does that from trusted sources (whitelist) and initially the whitelist only contains github.com/gambit which is the github account that hosts the Gambit source code. Note that there are several ways to disable this feature: at "configure" time with --enable-module-whitelist=, or with the environment setting export GAMBOPT=whitelist=, or the runtime options -:whitelist=, or programmatically with (module-whitelist-reset!).

Comments are closed.