Document AUTOBAHN_STRIP_XBR install-time option
See original GitHub issueThe 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:
-
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). -
Over time the demarcation point between the
xbr
modules andautobahn
may become less clear which increases the security audit complexity, already this seems to be starting to happen as there arexbr
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. -
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. -
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:
-
It cleanly separates out the
xbr
feature from the rest of autobahn so that one doesn’t need to audit the security of thexbr
side to ensure it can’t accidentally cause runtime side effects when using baseautobahn
functionality. -
It still allows for
xbr
andautobahn
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 uploadautobahn
andxbr
at the same time with matching versions). They will still share and install to the sameautobahn
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 thatautobahn
can be installed withoutxbr
. -
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 thexbr
components asxbr
would only ever be installed when all necessary dependencies are also installed.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:24 (24 by maintainers)
@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 usernameLightsword
.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.
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.
I use the WAMP functionality extensively.
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.
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.