1. 01 May, 2018 1 commit
    • Alessandro Sorniotti's avatar
      [FAB-6381] Secure defaults for txsFilter · 53de0781
      Alessandro Sorniotti authored
      The aim of this change set is to apply the well-established "Secure by
      default" security principle to the way the validator validates transactions
      in a block.
      The current code behaves as follows: create an array of validation codes, set
      by default to "all transactions are valid"; then perform validation which may
      mark transactions as invalid. Furthermore, in other parts of the code, if no
      array of validation codes is yet persent in the block, a new one is
      indiscriminately created (again, marking all transactions as valid). This
      approach is a security anti-pattern because it opens up to attacks where an
      adversary may force the code through a path where the default "tx is valid"
      validation code is maintained even for invalid txes.
      This change set ensures that validation code arrays are created and set to a
      new value (TxValidationCode_NOT_VALIDATED) which ensures that a transaction
      that hasn't been validated cannot be mistaken for a valid one.
      Change-Id: I5dbb18dd77af3cd14b168042ae660e4e27bf29dd
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
  2. 16 Apr, 2018 1 commit
    • Matthew Sykes's avatar
      [FAB-9494] test package functions to load config · 1d8344d7
      Matthew Sykes authored
      - Add variadic argument for extra search paths to configtxgen/localconfig
        Load and LoadTopLevel functions. This is primarily intended to be used
        in tests.
      - Create configtxgentest package that loads configurations and profiles
        from the development sampleconfig directory.
      - Add method to configtest to setup and reset FABRIC_CFG_PATH.
      - Update tests to use configtxgentest and/or configtest as appropriate.
      Change-Id: I6a66491bfbc0048f5b38babf6a55fb918a439fe6
      Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
  3. 28 Dec, 2017 1 commit
  4. 13 Oct, 2017 1 commit
  5. 10 Sep, 2017 1 commit
  6. 30 Aug, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-5819] Combine old/new channelconfig · 0cd16262
      Jason Yellick authored
      This is a cleanup CR which consolidates the mixed references to the old
      channel config code and the new channel config code.  In general, either
      reference is simply changed to refer to fabric/common/channelconfig but
      there are some package names which need cleanup as well.
      Although large and scary looking, this is purely rearrangements of
      imports and package names, no actual code logic is changed in this one.
      Change-Id: Iddb2878782307ede3b2786f035673effe1425b86
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  7. 11 Aug, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-5646] Move channel config to config/channel · 8dc78833
      Jason Yellick authored
      This is the first CR in a series designed to split the conflation of
      configtx processing and channel configuration.  The bulk of the code in
      fabric/common/config is specific to this channel configuration, so, this
      CR moves the entirety of this directory to fabric/common/config/channel.
      Ultimately, the common pieces will be extracted and moved back, but in
      the interest of making things reviewable and minimizing the diff, it
      makes sense to do this bulk move in one CR, then the move back in
      Change-Id: I124d48b0cbc7fd482e5118177ba9d59a81241d27
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  8. 05 Aug, 2017 1 commit
  9. 24 Apr, 2017 1 commit
    • Gregory Haskins's avatar
      [FAB-3160] Provide config-relative path feature · 8ce10737
      Gregory Haskins authored
      The primary goal of this patch is to create the notion of a
      "config-relative" path reference.  For example, a configuration file
      "/etc/foo/bar.yaml" that contains a key "bat" with a value
      "baz/blaz/blamo" can be used to specify that "baz/blaz/blamo" should
      be considered relative to the configuration file itself.  In this case,
      it would be expected to be found at /etc/foo/baz/blaz/blamo.  FAB-2037
      does a much more thorough job of explaining the rationale on why
      config-relative is considered important/good-form.
      This is in stark contrast to what we have today, which is a jumbled
      mess of assumed GOPATH relative, CWD relative, ENVVAR absolute and
      sometimes even ENVVAR relative.  Therefore, an additional positive
      side-effect of this endeavor is that this patch also substantially
      cleans up some technical debt that had been accumulating in the tree
      for some time related to ad-hoc pathing, DRY violations, and just
      general inconsistencies in how configuration files were managed.
      Design Details
      This patch refactors the basic configuration system into the notion of
      a tree rooted at a configuration-path.  By default, this path is
      $GOROOT/..../fabric/sampleconfig during dev/test and
      /etc/hyperledger/fabric during runtime.  The root may be overridden
      at any time by specifying the environment variable FABRIC_CFG_PATH.
      (Note that this variable unifies and replaces the former PEER_CFG_PATH
      and ORDERER_CFG_PATH).
      The dev/test environment will operate out of the ./fabric/sampleconfig
      configuration root.  The build-system will package that root into
      /etc/hyperledger/fabric in the runtime context with the intention of
      the end-user/admin/deployer replacing parts or all of the sampleconfig
      to suit their application.
      Since configuration-relative paths are now possible, the configuration
      files may reference other relative files and they will behave
      appropriately regardless of the context in which they are executed.
      For example, consider the files ./sampleconfig/tls/server.[crt|key].
      A configuration file may contain a key "tls/server.key" and the system
      will properly resolve this relative file even at runtime. This is (IMO)
      far more natural than assuming a path is relative to the CWD of where
      the command is executed, which is how most of the system behaves today
      (or requires awkward and very specific ENVVAR overrides).
      This will be conducive to something like a package-installer
      (e.g. RPM/DEB) or a docker environment to augment/replace elements
      of the configuration root and to freely move the configuration around
      as the package/deployer sees fit.
      As an example, a deployment on Kubernetes might opt to volume mount
      /etc/hyperledger/fabric to replace the entire config, or it might just use
      a secrets mount on /etc/hyperledger/fabric/peer/tls.  An RPM packager
      might opt to install the configuration files in the default
      /etc/hyperledger/fabric, whereas an unprivledged user might install them
      in ~/hyperledger.  The point is, it shouldn't matter where they are and the
      user shouldn't need a PhD in CORE_* variables to get it to work.
      This is part of an overall effort to improve the user-experience as we
      march towards a v1.0 release.
      Fixes FAB-3169 as part of FAB-2037
      Change-Id: I5f47f554c2f956ec2e1afebd9bd82b0bbb62892a
      Signed-off-by: default avatarGreg Haskins <gregory.haskins@gmail.com>
  10. 22 Apr, 2017 1 commit
    • Will Lahti's avatar
      [FAB-2351] Update loggers to flogging.MustGetLogger · 7132dd54
      Will Lahti authored
      This CR updates all loggers throughout the code base to use
      `flogging.MustGetLogger`. This function wraps `logging.MustGetLogger`
      and tracks the logger modules defined in the system. This enables the
      ability to set log levels for modules using regular expressions.
      and make it easy to change the levels for any module and all its
      submodules with a single command (e.g. gossip, ledger, msp).
      Change-Id: If5d3229ea2312adb56fc21bfdafbed3d967cf1df
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
  11. 14 Apr, 2017 1 commit
    • Gregory Haskins's avatar
      [FAB-3112] Do not include configtx helper.go at runtime · bd14ee79
      Gregory Haskins authored
      The current code assumes, by virtue of the init() routine in helper.go,
      that an MSP configuration that is compatible with "DEFAULT"/"sampleconfig"
      will exist in all contexts (test, development, and runtime).  While this
      is true for test and dev, runtime is not likely to have the sampleconfig
      available (nor should it).  Therefore, we fix the assumption by removing
      the implicit init() code and only use the logic on demand.
      It should be noted that any attempts to run "peer channel create" without
      any file as input will panic under a "runtime" environment (e.g. installed
      on a system, not built from source).  This is true both before and after
      this patch.  This should probably be fixed as a separate issue.
      Change-Id: I33bcd7d5be716a695c65fc09ae96807a2769f1d9
      Signed-off-by: default avatarGreg Haskins <gregory.haskins@gmail.com>
  12. 11 Mar, 2017 1 commit
    • Gari Singh's avatar
      [FAB-2174] Populate TLS trust stores from config blocks · 4844ce83
      Gari Singh authored
      With this change, the peer now obtains the root
      certificates it needs to populate the server and
      client trust stores from config blocks.
      The following changes updates were made:
      - core/peer/peer.go - added structure to maintain
      per chain aggegate list of CAs for apps and orderers,
      callback function for the config mgr which will
      update the trust stores from config blocks, and
      a function to obtain the aggregate list of
      root CAs for the peer as a whole
      - msp - added methods to get the root and intermediate
      certs from an MSP instance.  We can revisit this if
      there is strong belief in not doing it this way, but it
      is better than parsing the protos multiple times
      - common/configtx/test - added helper function to
      generate a config block which accepts MSPConfigs
      - some cleanup and slight modifications to utility
      functions needed for the above
      Change-Id: I30668428a3c65702e1ebe2774668606ff4d78016
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
  13. 07 Mar, 2017 3 commits
  14. 22 Feb, 2017 1 commit
    • Volodymyr Paprotski's avatar
      [FAB-1647] Yaml used to configure BCCSP · 3ee03339
      Volodymyr Paprotski authored
      This time use Yaml files in peer and orderer to configure BCCSP
      The main three changes are for the two executables:
      - peer
      - orderer
      - chaincode shim
      They each have their own config yaml file, added a BCCSP section.
      The BCCSP is paired with the MSP configuration directory. The
      SW BCCSP Filestore takes over the keystore directory.
      Where it gets complicated are all the tests. The tests working
      against MSP were easy to fix (circa patch set 8)
      Patch set https://gerrit.hyperledger.org/r/#/c/6235/4
      more uses of BCCSP. Configuring those mostly to SW/nil, except
      need to find an appropriate location for InitFactories(nil). Either:
      - many/most test cases have function called SetupTestConfig()
      - TestMain() otherwise
      Since the TestMain() updates were getting unmanageable and
      unscalable (everyone writting unit tests would now need to know
      about InitFactories()), added a concept of bootBCCSP to
      bootBCCSP is meant to be used by test cases that only need keyless
      crypto operations (i.e. SHA) or where keeping keys does not matter.
      Change-Id: I084d7927550e7fad7a25cf2062dc20220cf81ccd
      Signed-off-by: default avatarVolodymyr Paprotski <vpaprots@ca.ibm.com>
  15. 18 Feb, 2017 1 commit
  16. 17 Feb, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-2312] configtx value handlers to own package · fee7c6cf
      Jason Yellick authored
      There used to be a single type for configuration, 'ConfigItem', but that
      has bifurcated into 'ConfigValue', 'ConfigGroup', and 'ConfigPolicy'.
      In order to handle the 'ConfigValue' and the 'ConfigPolicy' in similar
      ways, the 'ConfigValue' handling needs to be pushed out into its own
      package just like policy handling is.  This CR accomplishes that.
      This is in preparation for treating the PolicyHandler as more of a first
      class object and to eliminate the need for hacky importing.
      Change-Id: I690a33e09843eb4c29611319f2e3942baae2dfdb
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  17. 15 Feb, 2017 3 commits
  18. 14 Feb, 2017 2 commits
  19. 07 Feb, 2017 1 commit
  20. 05 Feb, 2017 4 commits
  21. 30 Jan, 2017 1 commit
  22. 27 Jan, 2017 1 commit
    • YACOVM's avatar
      [FAB-1883] Add CLI support to load anchor peers · 5c3e6dc6
      YACOVM authored
      This commit adds a flag (-a) that loads anchor peers from files.
      The files can be created easily using any text editor and
      they are in the following format:
      pem certificate
      The parameter of the anchor peer is a comma separated
      file list.
      Signed-off-by: default avatarYacov Manevich <yacovm@il.ibm.com>
      Change-Id: I59cda7b09251b1ef6e7475d70e975e3369915eff
  23. 20 Jan, 2017 1 commit
    • YACOVM's avatar
      Add AnchorPeers to ConfigurationBlock · 282ed86d
      YACOVM authored
      This commit:
      1) Adds anchor peers upon channel creation
      2) Extracts them at the peer side in the gossip layer
         and uses them.
      3) Changes an internal API of a method in gossip
         from GetTimestamp to SequenceNumber, because
         using sequence numbers is better than using
         timestamps, that are machine-specific in
         contrast to sequence numbers which are global.
      Signed-off-by: default avatarYacov Manevich <yacovm@il.ibm.com>
      Change-Id: Id080585a56a5083d9cd4911ce790e5be389cfa52
  24. 16 Jan, 2017 1 commit
    • Alessandro Sorniotti's avatar
      [FAB-1639] [FAB-1580] Rework validator · ae10d2b6
      Alessandro Sorniotti authored
      This change-set has removed calls to the txvalidator that were issued right
      after the peer (the leader) receives blocks from the orderers. The validator
      is now called to validate messages received from the gossip layer. In order
      to fix an import cycle, we have introduced the ChaincodeProvider interface
      in core/common/ccprovider/ccprovider.go, an implementation and a factory.
      This way, code that needs to use functions from the chaincode package
      without importing it can simply use (and possibly extend) the
      ChaincodeProvider interface and implementation.
      Furthermore, this drop has introduced protocol-level message validation for
      config transactions that was lacking before.
      Change-Id: I5906a6fe3da8410b05b5079dd7f0b9d28d20bb85
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
  25. 15 Jan, 2017 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-1547 initial create/join chain support · a93135b1
      Srinivasan Muralidharan authored
      With this change the fabric has basic support for create / join
      chain begun with the implementation of CSCC (configuraton system
      chaincode) in https://jira.hyperledger.org/browse/FAB-1022.
      Some todos remain for follow up CRs
        . docker based commands to channel-setup.md
        . CONFIGURATION_TRANSACTION validation - https://jira.hyperledger.org/browse/FAB-1639
        . further MSP integration (still uses default MSP)
        . absorption of deliver client management into gossip later - https://jira.hyperledger.org/browse/FAB-1580
        . adding specific configuration items to channel create - https://jira.hyperledger.org/browse/FAB-1642
      Steps to test chain create / join below. All commands assume shell
      in "fabric/" directory.
      Vagrant window 1 - start orderer
        cd orderer
        ORDERER_GENERAL_LOGLEVEL=debug ./orderer
      Vagrant window 2 - ask orderer to create a chain
        cd peer
        peer channel create -c myc1
        #on successful creation, a genesis block myc1.block is saved
        #in the same directory
      Vagrant window 3 - start the peer without **TEST_CHAINID**
                         (basically in a "chainless" mode)
        #to start with a clean env do "rm -rf /var/hyperledger/*"
        cd peer
        peer node start --peer-defaultchain=false
        #in "--peer-defaultchain=false" mode the peer has to join
        #chains to create leader and do transactions. It does not
        #have a default chain or ledger (the **TEST_CHAINID** chain)
      Vagrant window 4 - ask peer to join a chain
        cd peer
        peer channel join -b myc1.block
      At this point we can issue transactions
      Vagrant window 2 - deploy a chaincode to myc1
        cd peer
        peer chaincode deploy -C myc1 -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["init","a","100","b","200"]}'
        #note the use of "-C myc1"
        #wait for 10 secs or so
      Vagrant window 2 - query chaincode
        cd peer
        peer chaincode query -C myc1 -n mycc -c '{"Args":["query","a"]}'
      Change-Id: I7d1d04e8a207eb57597a1e6eb8b986e1080e7811
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
  26. 13 Jan, 2017 2 commits