Installation - 1234max/multivendorbitcoinmart GitHub Wiki

CAUTION: MultiVendorBitcoinMart is not ready to be used in production environments, especially not in security-critical environments. Some features are missing (see ToDo), the Bitcoin integration was only tested using testnet (although it should work fine since there is no testnet-specific code) and further precautions should be taken when using the application productive:

Production environments

LAMP

We recommend to run MultiVendorBitcoinMart on a LAMP stack:

  • Use a hardened Linux distribution of your choice
  • Use a stable Apache (i.e. 2.2) from the distribution's package manager, disable all modules except PHP and upgrade the packages automatically (i.e. using nightly cron) to not have to worry about security issues on this level. Configure it securely!
  • Since we use a stripped down version of PHP, you should avoid use the PHP version of the distribution. Use phpbrew to compile the packages (on a different system, you wouldn't want compilers on your production system), secure the configuration, watch the PHP security list and upgrade promptly!
  • Pre-package the application on a different system and copy the package to the productive system, so you don't have to install the composer requirements on your productive host.
  • Secure your MySQL installation

ImageMagick

Currently, the application invokes ImageMagick binaries directly as the same user (used for file upload and captcha generation). For higher security, consider modify the source (File upload, Captchas) to invoke the commands as a different user with less privileges.

PGP

The used GnuPG-Library for PHP uses the current user's keyring for its actions. To make sure we always have a pristine keyring, prior to every action a new keyring is created in sys_get_tempdir(). Although there is a locking mechanism implemented, it should be tested before for any concurrency issues (Source).

Tor hidden service

The application was never tested to serve as a hidden service (although it should work fine). Since running a hidden service requires an entirely different set of security mechanisms, only use it as a hidden service if you now what you're doing. Otherwise, it will quickly lower the security of the whole marketplace.

Bitcoin daemon

MultiVendorBitcoinMart was developed using the bitcoin daemon locally. You do not want to do that (at least not because it's possible to correlate the uptime of the web page and the bitcoin peer). We don't have any experience with it and do not know the optimal solution, but such an architecture must be well-thought-out to not defeat the security of the complete system.

ToDo

Some features are missing and should be implemented before going productive:

  • Implement the bitcoind alert hook (Bitcoin wiki): It should set the marketplace in maintenance mode that could be reenabled by admins only.
  • Set up notifications on errors: Errors, that are thrown in production, are silently swallowed at the moment. For the web application, the errors should be further handled, i.e. sent as email (Starting Point). For the CLI-Parts, error handling is even more crucial (i.e. if bitcoin transaction procession fails and nobody notices). Could be done here: cli.php
  • PGP-Auth: Once the user has defined a PGP public key (already implemented), the login system could easily be extended to offer optional PGP auth to end users
  • Commissions & setup fees: Neither commissions on orders (complete order price goes to vendor) nor vendor registration fees are implemented, so there is currently no way to make money administrating the market. Starting points to implement fees: Creation of payout transaction, Becoming vendor
  • Payout addresses: Currently, vendors supply a payout address on each order. It should be possible for vendors to define a pool of payout addresses in their profile or derive payout addresses from a BIP32 key (as soon as it's clear how clients adopt this).
  • Multiple admin accounts: Since the admin interface is secured with a single bitcoin public key, multiple admins would have to possess the private key. This could be improved by using a PGP auth with multiple admin public keys stored in the marketplace.