1. 17 Jul, 2018 1 commit
  2. 07 Jul, 2018 1 commit
    • Jason Yellick's avatar
      FAB-11094 Fix deadlock in block iterator · 375995ea
      Jason Yellick authored
      The deliver service used to not close ledger iterators until after a
      block had been committed.  With FAB-10799, the Deliver service more
      proactively cleans up ledger resources.  This leads to a more likely
      contention between the block iterator's Close() function and the Next()
      These two code paths acquire the same two mutexes, but in different
      orders.  The Next() path always acquires the itr.mgr.cpInfoCond.L first,
      then the itr.closeMarkerLock, while the Close() path inverts this order.
      If both Next() and Close() are invoked at the same time by goroutines,
      this can result in a deadlock where both mutexes lock and never unlock.
      This further prevents all blocks from committing and begins to leak
      memory resources.
      Change-Id: I99180fec2639a62cdf1cd9a6ce8b33f91ce498b9
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  3. 02 Jul, 2018 1 commit
  4. 08 Jun, 2018 1 commit
    • manish's avatar
      [FAB-8557] Fix overwriting txid in block index · f6c97e0f
      manish authored
      This CR fixes the current behavior of block store index.
      In the current implemetation, the indexes that maintain
      different pieces of information by txid are overwritten
      by a duplicate txid (if any). This CR reverses this behavior
      and keeps the first appearance of txid in the index. The future
      duplicate txids will not overwrite it.
      Though, either of these behaviors (keeping the first tx or
      keeping the last tx) are not fully justified, primarily because
      the problem itself is a paradox - in the sense that the ids
      (that are supposed to be unique by definition) are duplicated.
      However, the justification of moving from the current behavior
      to the proposed behavior is that, its easy for someone to replay
      the transaction or simply use an existing txid in a bogus transaction
      just to exploit the current behavior of overwriting the block storage
      index and preventing the legitimate user to query about the status
      of their transactions.
      Change-Id: I3b81ae61c756ef78253b58a94644778716fb0e16
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
  5. 04 Jun, 2018 1 commit
  6. 24 May, 2018 1 commit
  7. 21 May, 2018 1 commit
    • Chris Elder's avatar
      [FAB-7779] CouchDB indexes for private data · 9a3b1811
      Chris Elder authored
      Any couchdb indexes defined for a chaincode will be deployed in
      the chaincode state database.  Indexes for collections of private
      data should be applied in the chaincode's collection state database
      rather than in the chaincode state database.
      Added support for HandleChaincodeDeploy event to common_storage_db.  This
      will now process the event from chain code deploy.  The move was necessary
      for handling the private data namespace mapping.
      Added new function to statecouchdb for processing index creation.
      Added new interface to statedb for IndexCapable.  This allows the
      common_storage_db to detect that the state database will accept index
      creation events.
      Updated index validation to allow for indexes under collections directories.
      Change-Id: Icfda923c584d953ce5886023f7411bbddb59d595
      Signed-off-by: default avatarChris Elder <chris.elder@us.ibm.com>
  8. 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>
  9. 17 Apr, 2018 1 commit
  10. 16 Apr, 2018 1 commit
  11. 03 Apr, 2018 1 commit
  12. 01 Mar, 2018 1 commit
  13. 07 Dec, 2017 2 commits
    • Will Lahti's avatar
      [FAB-7273] Update deliver to facilitate usage on peer · c39d69bd
      Will Lahti authored
      This CR updates the deliver functionality to facilitate its usage on
      a peer as well as an orderer.
      This required:
      - modifying the signal logic for when a new block is available due to
       the difference in addition of blocks to the ledger between the orderer
       and the peer. The signal logic is now handled using the iterator
       itself, which signals when it finds a new block
      - adding a policy variable to the deliver handler to ensure the peer
      and orderer each can control access to deliver
      Change-Id: Iebb6c25a8c5ac32d65f909eb0519f26bfde0dc31
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
    • Will Lahti's avatar
      [FAB-7048] Move deliver from orderer to fabric/common · 0dfe4f35
      Will Lahti authored
      This CR moves deliver from the orderer to fabric/common. This is being
      done to support the future implementation of deliver on the peer.
      Change-Id: If077f2c05b5a10fdeb4e6ac315111495304e4c5e
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
  14. 04 Dec, 2017 1 commit
  15. 15 Nov, 2017 1 commit
  16. 30 Oct, 2017 1 commit
    • manish's avatar
      [FAB-6779] Allow rebuilding block storage indexes · 1daabff7
      manish authored
      This CR allows building of block storage indexes.
      For rebuilding the indexes, existing index folder would need to be dropped.
      However, please note that this would drop (and rebuild) the indexes for all
      the chains because they share the underlying leveldb.
      Also, enabled the flush/synch of batch writting to leveldb (statedb, block indexes, and historydb).
      Change-Id: I6a926ab765df4bbb6543d6a3960359d95d60fd68
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
  17. 27 Oct, 2017 1 commit
  18. 20 Sep, 2017 1 commit
  19. 12 Sep, 2017 1 commit
  20. 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>
  21. 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>
  22. 01 Aug, 2017 1 commit
    • Baohua Yang's avatar
      [FAB-5194] Fix usage problems in code · 76c0dc56
      Baohua Yang authored
      This patchset helps clean up the code and docs:
      * Fix redundant parenthesese.
      * Fix mismatching params in func return.
      * Fix variable name collides with imported package name and builtin
        function or reserved words.
      * Fix word typos.
      Change-Id: I30304c233067ead7e74d18e3caf2604b3ed1490a
      Signed-off-by: default avatarBaohua Yang <yangbaohua@gmail.com>
  23. 26 Jul, 2017 1 commit
  24. 18 May, 2017 1 commit
  25. 09 May, 2017 1 commit
  26. 07 May, 2017 1 commit
  27. 05 May, 2017 1 commit
  28. 04 May, 2017 1 commit
  29. 02 May, 2017 1 commit
  30. 27 Apr, 2017 1 commit
    • jiangyaoguo's avatar
      [FAB-3330] validate chaincode version · f30fc741
      jiangyaoguo authored
      1. Add VsccOutputData struct to keep output of vscc.
      Vscc will return proposalResponsePayload(has verison info)
      bytes contained in ChaincodeAction.
      2. When committer validates transaction, check that the
      chaincode version in ProposalResponse matches the
      verision in lscc.
      3. Add new ValidateCode to distinguash two kinds of invalid
      reason because of chaincode upgrade.
      4. vsccValidatorImpl will return latest chaincodeInstance
      from lscc and vsccOutputData from vscc. So we can mock
      system chaincode in UT.
      5. Move ChaincodeInstance to sysccprovider to avoid
      cycle import.
      Change-Id: I45387f119054d64b57d28173cabda0194a9e3464
      Signed-off-by: default avatarjiangyaoguo <jiangyaoguo@gmail.com>
  31. 26 Apr, 2017 1 commit
    • jiangyaoguo's avatar
      [FAB-3329] set chaincode version in ProposalResponse · fc95c06c
      jiangyaoguo authored
      When endorser endorse proposal, set ChaincodeID field
      of ChaincodeAction with the ChaincodeID which was used
      to execute chaincode, especially the chaincode version.
      This CR add ChaincodeID to escc args and set it when
      endorsing proposal. Another CR will implement checking
      chaincode version of transaction matches latest chaincode
      version in commiiter side.
      Change-Id: I62d7a5d34e12ff9d3131aa52d1af428bb8d58f2e
      Signed-off-by: default avatarjiangyaoguo <jiangyaoguo@gmail.com>
  32. 25 Apr, 2017 1 commit
  33. 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>
  34. 11 Apr, 2017 1 commit
  35. 02 Mar, 2017 1 commit
  36. 27 Feb, 2017 1 commit
  37. 21 Feb, 2017 1 commit
    • Alessandro Sorniotti's avatar
      [FAB-1392] - Use bytes for headers · 011cd41b
      Alessandro Sorniotti authored
      This change set ensures that the protobuf representation for headers be in
      bytes. This makes sure that if ever protobuf marshalling is non-deterministic,
      we do not have problems because whenever we hash a header, we do that over
      the serialized version we receive.
      Change-Id: I838e0d5dec2f79f88fab63d92bdfb51d92c2f069
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
  38. 18 Feb, 2017 2 commits
    • Angelo De Caro's avatar
      Replay attack protection · 32668825
      Angelo De Caro authored
      This change-set enforces the field TxID of a
      proposal/transaction to be computed as the result
      of an hash function computed on nonce and creator.
      This is to be able to uniquely identity a proposal/transaction.
      In addition, the endorsers verify that a TxID is not duplicated
      by looking up the ledger as done by the committers.
      Before merging this change-set, the client-sdk
      needs to be modified to generate the TxID in the
      new expected way.
      This change-set comes in the context of
      Change-Id: Icc5892976aeec1d4fdca736234355833d04bd4c8
      Signed-off-by: default avatarAngelo De Caro <adc@zurich.ibm.com>
    • Luis Sanchez's avatar
      [FAB-2214] 1st block in chain is block 0, not 1 · e49f25fc
      Luis Sanchez authored
      Made the following changes to fsblkstorage provider:
      * Block numbers start at 0, not 1.
      * Blockchain height should be last block number + 1.
      * A block's Block.Header.Number should be equal to
        the Blockchain height when AddBlock() is called.
      * Updated ledger tests to use random temporary dir.
      * Update core endorser tests to generate valid block
      Change-Id: I0208cd6a4b9da462c29d06126fa651f4c0dcd2fc
      Signed-off-by: default avatarLuis Sanchez <sanchezl@us.ibm.com>