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. 27 Apr, 2018 2 commits
  3. 25 Apr, 2018 5 commits
  4. 24 Apr, 2018 1 commit
    • Jason Yellick's avatar
      [FAB-9688] Remove dangerous unused CCID.ChainID · addaee5a
      Jason Yellick authored
      The CCID struct has a ChainID field.  This field affects the output of
      GetName().  There is a comment in GetName() indicating that if unset,
      the chaincode must be a chainless system chaincode, however, this field
      is in fact never set.  If it were, the rest of the chaincode container
      logic would break, and we would spawn a container per chaincode per
      channel, instead of just per chaincode.
      This CR removes this unused field and the logic in GetName around it.
      Change-Id: I9f666d7f2c2942372a363bc301f275c56fe55228
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  5. 23 Apr, 2018 2 commits
  6. 11 Apr, 2018 1 commit
  7. 31 Mar, 2018 1 commit
    • Jason Yellick's avatar
      [FAB-9256] Change DEFAULT MSPID to SampleOrg · 649ceeac
      Jason Yellick authored
      Our users are frequently confused because the sample configurations
      set to the sample organization's MSP ID of 'DEFAULT'.  This leads to
      very misleading error messages, and it is not at all clear that
      'DEFAULT' should be changed to match their organization.
      Unfortunately, many of our 'unit tests' are actually integration tests
      which hardcode the string 'DEFAULT', so this CR (which should only be a
      few lines long) actually cascades through much of the code.  These tests
      should be updated to remove their external dependency on the sample
      configuration, but, that is outside the scope of this CR.
      Change-Id: Icf56924629b69400e0d70991a6ecfb3e831b0641
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  8. 20 Mar, 2018 1 commit
  9. 07 Mar, 2018 1 commit
  10. 21 Dec, 2017 1 commit
    • yacovm's avatar
      [FAB-6563] CLI support to specify collections · c0a2615b
      yacovm authored
      This change set adds a new option ('--collections-config') so that the
      chaincode developer can specify the configuration of a collection when
      deploying a new chaincode. The option expects a file name; the content of the
      file will be read and parsed as a JSON-formatted array of the following struct
      type collectionConfigJson struct {
      	Name              string `json:"name"`
      	Policy            string `json:"policy"`
              RequiredCount int32  `json:"requiredPeerCount"`
      	MaxPeerCount  int32  `json:"maxPeerCount"`
      Change-Id: Ifceed0db612b36c793937ef6704e8a179981413d
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
  11. 01 Dec, 2017 1 commit
    • Boliang Chen's avatar
      [FAB-7108] Refactor ccEpFunc to string · 8028eb4b
      Boliang Chen authored
      The main purpose of function ccEpFunc is to compute chaincode
      endpoint and return error if needed. It will be better to do
      all checks and computation during the node start up phase.
      The CR will do all the necessary checks in node/start.go and
      panic if unexpected error. Therefore, it will pass only the
      chaincode endpoint value (as string) to the follow up function.
      Also, the CR moves panic from createChaincodeServer to serve
      function and revises UT to cover all chaincode endpoint
      computation cases.
      Change-Id: Ie4802472f0dd04c3a3da1e1ac6e30f90463fb0b2
      Signed-off-by: default avatarBoliang Chen <cblsjtu@gmail.com>
  12. 26 Oct, 2017 1 commit
  13. 25 Oct, 2017 1 commit
  14. 16 Oct, 2017 1 commit
    • senthil's avatar
      [FAB-5080] Chaincode API Support for PrivateData · 16a92d5d
      senthil authored
      This CR adds the following 6 chaincode APIs which enable chaincode
      to acess/modify the partitioned private data. A collection name denotes
      a partition. These will only be included in experimental builds.
      1. GetPrivateData(collection, key)
      2. PutPrivateData(collection, key, value)
      3. DelPrivateData(collection, key)
      4. GetPrivateDataByRange(collection, startKey, endKey)
      5. GetPrivateDataByPartialCompositeKey(collection, objectType, []keys)
      6. GetPrivateDataQueryResult(collection, query)
      Changes have been made in both shim and peer side. For APIs 4 to 6,
      ledger support is not added yet.
      Enabled only TestQueries/TestQueriesPrivateData functions in
      exectransaction_test.go to perform end-to-end test (chaincode
      to ledger).  Earlier, all test functions in exectransaction_test.go
      was disabled as it was taking a lot of time to execute.
      Currently, TestQueries/TestQueriesPrivateData take less than
      15 seconds and hence can be enabled for e2e testing
      Also needed to modify core/chaincode/platforms/golang/platform.go
      in order to support building chaincode with the experimental tag.
      Change-Id: I6b026f0628c5c808776f05852c7910f60f4a99c4
      Signed-off-by: default avatarsenthil <cendhu@gmail.com>
      Signed-off-by: default avatarDavid Enyeart <enyeart@us.ibm.com>
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
  15. 29 Aug, 2017 1 commit
    • yacovm's avatar
      [FAB-5907] coordinator and transient decoupling · fad6ca2c
      yacovm authored
      This commit:
      - Decouples the coordinator from the state transfer
      and moves it to its own package.
      - Carves out the transient store from the ledger
      - Makes the endorser pass the private simulation results
      to the coordinator, for writing to the transient store
      and (in future commits) for dissemination
      Change-Id: Iadc8528915a0ce50dd44b17b0d0bdfa11487d600
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
  16. 18 Aug, 2017 1 commit
    • yacovm's avatar
      [FAB-5406] Mutual TLS in chaincode service-P3 · 7a26f1fe
      yacovm authored
      This change set makes golang CC run on a different port (7052)
      and at startup of a chaincode container - generate a TLS certificate
      and pass it as commandline options to the shim container.
      The full details are in the JIRA item
      Change-Id: I6d274a235f2a66b310e61ee878ec4b881d6c8f49
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
  17. 10 Aug, 2017 1 commit
    • manish's avatar
      [FAB-5654] SideDB - Tx simulation/validation/commit · 8a87b8ae
      manish authored
      This CR modifies the tranaction simulation, validation, and commit
      code and delivers the end-to-end transaction flow that treats the
      private data in a special manner. This CR mainly leverages the earlier
      submitted independent CRs for sidedb feature for accomplishing this behavior.
      This CR also allows ledger to receive the blocks and the pvt data from
      another peer on the same channel (i.e., a peer catching up via state)
      This CR is exceptionally large becasue of manily two reasons
      1) The way currently the code (and specially the tests) is organized in
      simulation/validation/commit flow, its not easy to submit such kind
      of changes independently that cuase the change in the whole transaction
      processing flow.
      2) This CR causes a change in the existing ledger APIs which are used widely
      across other packages (specially in the tests) and hence many files are included
      for fixing the broken dependencies
      Change-Id: Id29575176575f4c01793efd3476b68f8364cb592
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
  18. 23 Jun, 2017 1 commit
  19. 02 Jun, 2017 1 commit
  20. 30 May, 2017 2 commits
  21. 24 May, 2017 1 commit
  22. 10 May, 2017 1 commit
  23. 09 May, 2017 1 commit
  24. 08 May, 2017 1 commit
  25. 05 May, 2017 1 commit
  26. 28 Apr, 2017 1 commit
    • senthil's avatar
      [FAB-2183] fix RangeQuery key collision · 19d857c8
      senthil authored
      When we do a range query on simple keys, it returns composite
      keys too. This CR make sure that only simple keys are returned by
      GetStateByRange() API. In order to achieve that, we make the
      CreateCompositeKey() chaincode API to add a null character (0x00) as
      a first character in composite key. This creates a separate namespace
      for composite key. The simpleKey must not be an empty string as it is
      treated as 0x00 in levelDB which results in collision between simple
      and compositeKey. Hence, we do not allow empty string as key in PutState().
      Further, we need to ensure that a simple key does not start with a
      null character (0x00). Currently, we cannot impose this constraint on
      simpleKey as PutState() is being used for storing both <simpleKey, value>
      and <compositeKey, value> where the compositeKey must start with 0x00.
      Hence, we have only documented this constraint on simpleKey (note that it
      is unusual for a key to start with a null char). In future (post v1), we
      may introduce PutCompositeKey() API so that we can explicitly impose this
      constraint. Other approaches are listed in FAB-2183
      Change-Id: I28aee64d81e07f2a504580b3fe87a182c130d82e
      Signed-off-by: default avatarsenthil <cendhu@gmail.com>
  27. 26 Apr, 2017 3 commits
  28. 25 Apr, 2017 2 commits
    • manish's avatar
      [FAB-2676] Allow create-ledger with genesis block only · 722e790d
      manish authored
      This CR removes the option of peer ledger creation
      without genesis block
        - Changed the APIs in PeerLedgerProvider interface
          and ledgermgmt.CreateLedger function
        - Fixed the usage of the ledger creation API in peer code and tests
        - Marked one test (core/scc/qscc:TestQueryGetBlockByTxID) to skip
          which should be made to normal once
       is resolved
      Change-Id: Ife926c20226f45c5586b75b37881f374d42075d6
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
    • Balaji Viswanathan's avatar
      FAB-2462: Re-enable paging results for queries · 868a3e93
      Balaji Viswanathan authored
      Paging result sets is required in order to avoid failures
      related to large result sets.
      The Next() call on StateQueryIterator from Chaincode was failing
      in peer due to a corner case. This fix addresses the corner case (where
      the number of results is an exact multiple of shim batch size).
      This is done by keeping the HasMore flag in iterator accurate by
      pre-fetching the next batch of results when the last cached item
      from shim is accessed.
      This fix also adds the Namespace field to commonledger.KV type. The data
      returned to peer has namespace information. All state iterators return
       QueryResult with commonledger.KV type elements.
      Change-Id: Id872130db8a20ec5a59593b1fa004dce43ee36ac
      Signed-off-by: default avatarBalaji Viswanathan <balaji.viswanathan@gmail.com>
      Signed-off-by: default avatardenyeart <enyeart@us.ibm.com>
  29. 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>
  30. 23 Apr, 2017 1 commit