Re: [Monotone-devel] Linking monotone with the official lua shared library as distributed by Debian

[Tomas Fasth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graydon Hoare skrev:
> the use of popen was a potential "security hole" in monotone's lua
> environment because we feed filenames into it which might contain
> un-escaped shell metacharacters. this means a malicious user could
> make a filename which executes shell code. it's an old and widely
> known family of potential vulnerabilities in any program which
> executes popen.

I understand the rationale behind your action. I just don't agree
with how you choose to work around the problem. For one, it do not
seem to conform very well with the principle of optimal use of
shared libraries in large distributions like Debian.

> we removed the binding from popen in the lua environment because we
> don't want users accidentally writing lua extension scripts for
> monotone that casually use popen. we provided a replacement which
> calls exec manually. this is very standard practise; many scripting
> environments have made this adaptation.

I do not question your concern for potential user errors. I just
wish we could find an alternative way to protect clueless users from
hurting themselves without the need to fork code.

The following was suggested by a fellow Debian developer Elrond:

"As I understand it, the changes are only to remove a function for
the interpreter, that basicly does system() (as in libc). So one
can't accidentally pass filenames with wildcards/backticks into the
shell. - Instead, one could just register a failing function by that
name into the interpreter."

Regarding your very standard practice, I'm not sure I can agree that
it is standard practice in open source communities to modify code
and not sending patches upstream so others can benefit from it.

> however, it is an adaptation one makes on their own. popen can be used
> safely if you care to be safe, or you're generating the input being
> fed to it. we just chose a cautious angle: remove popen entirely.

And if the suggestion by Elrond above is feasable, wouldn't it be
preferable to disable a function rather than removing it, especially
since it's just a potential risk, not a factual?

> there is no need to force all lua users in debian to drop popen; we
> just didn't want it in *our* bundled lua environment, because that
> environment uses a lot of user-provided (and often network-provided)
> data.

You could still have worked with upstream to make it optional at
runtime. That could very well have helped others who also link their
applications with the lua library.

> naturally I would appreciate if you did not link against the
> debian-provided lua library, as we have no way of performing QA on
> this library or customizing it to suit our needs. in this case you
> will be re-introducing a possible security hole; we will still not
> actually *use* popen in any of the scripts we provide, but it will be
> available to script authors and therefore more likely to be misused.
> we prefer to keep the lua environment we offer users very constrained
> by default.

I see. Again, I wish you could work with upstream developers if you
have additional needs outside the current set of funtionality. In
doing so you could bring your changes to a broader audience provided
that it is done in a compatible way.

> of course, being free software, I cannot really stop you from doing
> so. but I would appreciate if it you did not.

I have no intention to apply changes in Debian that is against the
will of upstream authors. Especially since the debian build files is
revision controlled within monotone's own repository.

But you, as an upstream developer, also need to understand that
there is a world outside the monotone community and that monotone
need to be distributed in a way that conform with requirements
created out of a wider perspective that just a single software project.

- --
Tomas Fasth <address@hidden>
GnuPG KeyId: 0x9FE8D504
Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC5NsQwYdzVZ/o1QQRAotWAJ9qCopp0iZ+8/aAAthaVjVAxGlLCACggCL4
m2mGc/ACj/sek/Y+5OcWRis=
=SFqi
-----END PGP SIGNATURE-----