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>
      53de0781
  2. 27 Oct, 2017 1 commit
  3. 20 Sep, 2017 1 commit
  4. 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>
      8a87b8ae
  5. 09 May, 2017 1 commit
  6. 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>
      f30fc741
  7. 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>
      fc95c06c
  8. 25 Apr, 2017 1 commit
  9. 27 Feb, 2017 1 commit
  10. 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
      https://jira.hyperledger.org/browse/FAB-583
      
      
      
      Change-Id: Icc5892976aeec1d4fdca736234355833d04bd4c8
      Signed-off-by: default avatarAngelo De Caro <adc@zurich.ibm.com>
      32668825
    • 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
        numbers.
      
      Change-Id: I0208cd6a4b9da462c29d06126fa651f4c0dcd2fc
      Signed-off-by: default avatarLuis Sanchez <sanchezl@us.ibm.com>
      e49f25fc
  11. 03 Feb, 2017 1 commit
    • manish's avatar
      Move Blockstorage code under /fabric/common package · 2a16532c
      manish authored
      https://jira.hyperledger.org/browse/FAB-2022
      
      
      
      This changes introduced by this CR
      - Moves the block storage code from package
      core/ledger/blkstorage to common/ledger/blkstorage
      
      - Splits the ledger_interface.go so as to move common interfaces
      and data type to common/ledger package
      
      - Moves some of the util functions to common/ledger package
      
      - Moves core/ledger/ordererledger package to orderer/ledger/fsledger
      orderer folks can futher rename/refactor this as seems suitable to them
      
      Change-Id: I759e16f00dc2ec9bb62196121083cf48eae76948
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      2a16532c
  12. 25 Jan, 2017 1 commit
  13. 11 Jan, 2017 1 commit
    • Jason Yellick's avatar
      Move core/util to common/util · 289b1a29
      Jason Yellick authored
      
      
      As a matter of policy, the only imports a package should have outside of
      its base dir are protos/ vendor/ and common/.  The core/util package was
      referenced all over the code, so moving it to common seems like the best
      option.
      
      Change-Id: Ic7d797be6a1b44634480a361ae7469b794685762
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      289b1a29
  14. 01 Dec, 2016 1 commit
  15. 30 Nov, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-1230 - use **TEST_CHAINID** for tests and skeleton · f7b3336d
      Srinivasan Muralidharan authored
      https://jira.hyperledger.org/browse/FAB-1230
      
      
      
      Orderer sets the stage for multichain by forcing brodcast
      and deliver clients to specify ChainID. The solo orderer
      provides a default chain called **TEST_CHAINID** to continue
      development with.
      
      It would have been easy to hard code **TEST_CHAINID** in
      the lower most utility calls to continue work - basically
      inside protos/utils/ functions.
      
      However, this changeset takes the next step fo moving to
      using multichain by exposing chainID in core APIs thus
      forcing higher layers to deal with chains. Currently these
      high layers are unit tests, CLI and SDK.
      
      CLI accepts chain ID via the "-C" param which when not provided
      defaults to **TEST_CHAINID**.
      
      Change-Id: I0d7894c8f17ce8fae6fe075c9865afae58499005
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      f7b3336d
  16. 28 Nov, 2016 1 commit
  17. 27 Nov, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-1198-rm old pb.Transaction, pb.Block · 61affa05
      Srinivasan Muralidharan authored
      NOTE - Removing of old proto.Transaction is the cause for
      the large change set. It affects chaincode framework and
      all users of the framework such as endorser, system chaincodes,
      unit tests etc.
      
      Transaction2 is renamed to Transaction.
      Response2 is renamed to Response.
      Message2 is renamed to Message.
      
      The changes are fully described in
          https://jira.hyperledger.org/browse/FAB-1198
      
      
      
      Summary
      =======
         . Remove old Transaction and rename Transaction2
         . Cleanup of Chaincode protobuf message
         . Add TxID for SDK and higher layers to optionally
           set (currently errors if not set)
      
      ChaincodeMessage removes QUERY and QUERY_CHAINCODE enums.
      
      Shim interface does not enforce Query or QueryChaincode.
      
      chaincode_example02 and 05 implement Query function via
      the Invoke implementation.
      
      The "noop" system chaincode is removed
         . it was using Transaction which is not an endorser
           artifact any longer
         . there are many system chaincodes to that thoroughly
           test sys chaincode functions
      
      Change-Id: Ib77b7e5a6756eac47e888309816076580ae505e7
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      61affa05
  18. 23 Nov, 2016 1 commit
    • Alessandro Sorniotti's avatar
      TX proposal/endorsement/validation flow (+MSP) · 16fa08e2
      Alessandro Sorniotti authored
      
      
      This change set contains a set of functions to generate a transaction (from
      proposal, endorsements and a signing identity) and validate it (given a set
      of root CAs). The validation code will be used by the committer. The tx
      assembling code should be helpful for the SDK team to understand how
      transactions should be assembled. Additionally, it has changed the type of
      messages exchanged everywhere to be of the proper type and with signatures
      (obtained from a fixed identity for now). Finally, it contains an initial
      implementation of VSCC with unit tests (which is however not yet called by
      the committer).
      
      Change-Id: I375ecc7e61516f3c4ab8fd874aa564e99cc720fb
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
      16fa08e2
  19. 15 Nov, 2016 1 commit
  20. 11 Nov, 2016 1 commit
  21. 01 Nov, 2016 1 commit
  22. 28 Oct, 2016 2 commits
  23. 26 Oct, 2016 1 commit
  24. 29 Sep, 2016 1 commit
  25. 15 Sep, 2016 1 commit