Document AUTOBAHN_STRIP_XBR install-time option

The current behavior for autobahn is to install a bunch of xbr modules even when the user does not request them to be installed.

There are a number of reason this is a bad idea:

1. Packages should not install modules that are not relevant to the typical use case for the package without strong technical justification as this can significantly increase attack surface, especially for a package like autobahn which already has significant network attack surface(in one of my projects it’s effectively the only package doing any remote network communications over public networks other than the usual DNS/DHCP/VPN client daemons).

2. Over time the demarcation point between the xbr modules and autobahn may become less clear which increases the security audit complexity, already this seems to be starting to happen as there are xbr modules in multiple different autobahn paths. By splitting the modules into a separate package it becomes very obvious that they are not relevant to the typical use case and thus can be ignored when auditing security.

3. In regards to the security of xbr specifically, it is well known in the cryptocurrency community that the Ethereum project has a very poor track record in regards to security in general, in fact I have personally discovered security vulnerabilities in the design of some ETH network protocols in the past. Being able to fully remove potentially risky Ethereum project related code makes it easier to audit the security of autobahn.

4. The maintenance of the conditional loading of imports is more complex than using conditional installation of the xbr modules.

The approach I took in #1369 to splitting out the xbr package from autobahn has a number of advantages:

1. It cleanly separates out the xbr feature from the rest of autobahn so that one doesn’t need to audit the security of the xbr side to ensure it can’t accidentally cause runtime side effects when using base autobahn functionality.

2. It still allows for xbr and autobahn to be developed in a tightly coupled way, for example by always having both packages require exact versions of each other in the setup.py(you can just script the package version bump to always bump and upload autobahn and xbr at the same time with matching versions). They will still share and install to the same autobahn site-packages namespace as before and can be installed in the same way by the end user, the main difference is that the development tree and distribution packages have cleanly separated functionality and that autobahn can be installed without xbr.

3. It allows for simplification of the xbr parts of the codebase as one can entirely remove all the conditional dependency based import logic currently used throughout the xbr components as xbr would only ever be installed when all necessary dependencies are also installed.

[jameshilliard]

@oberstet OT: If you’re interested in chatting more about crypto use cases for autobahn I have a number of ideas/possible synergies with what I’m working on, I’m usually around in the #autobahn irc channel under the username Lightsword.

[jameshilliard]

there are many aspects here … one would be: in your app, you only need a strict subset of the code in autobahn. why not remove all code in autobahn that you don’t need in your app?

To a large degree I actually do this, I use buildroot which generates a heavily stripped down operating system image with only minimal dependencies, by doing that I can get my entire production OS image(bootloader+kernel+rootfs) including embedded web browser down to ~100MB compressed.

yes, we will evolve this together, as quite simply: XBR builds on top of WAMP which (can) build on top of WebSocket. All 3 are working as an integrated stack. hence we want close integration by design.

Yeah, that’s why I took this approach since it should still allow for that development model, ie by cross pinning xbr and autobahn versions in setup.py so that you then don’t have to worry about internal API breakage between the two.

if you don’t need WAMP, but only WebSocket, you can have a custom build step downstream that removes all files you don’t need

I use the WAMP functionality extensively.

further: if you think so, don’t use autobahn or any of my code then;)

Heh, I haven’t found any security flaws so far in autobahn, seeing a bunch of ethereum libraries kinda scares me though as I’ve seen the type of code written by Vitalik, I actually rewrote the transaction parsing code for a wallet project(joinmarket) that had unfortunately used vitalik buterin’s pybitcointools which had regexes in the transaction parser, that was not an easy rewrite.

Security wise, there surely had been issues, and there is learning required how to write secure contracts etc. expected, as this is breaking new land …

I’m quite skeptical writing a secure contract in with eth is possible for anything other than the most trivial one, especially when the company founded by the former ETH foundation CTO couldn’t even write a multisig wallet contract that didn’t get hacked, not once but twice.