Ручные подписи транзакций не видны во время проверки (структура 1.4) - PullRequest
0 голосов
/ 23 февраля 2019

Предполагается, что мы сможем подписать транзакцию с несколькими удостоверениями, и это может быть требованием, настроенным в политиках.

Но я не могу заставить это работать, то есть у меня естьполитика требует нескольких подписей, поэтому я подписываю файл транзакции (.tx) последовательно с информацией MSP двух организаций, но когда я отправляю транзакцию, заказчик или одноранговые узлы отклонят ее, сказав, что " Подпись установленане удовлетворил политику ...".

И что странно в том, что эта проверка игнорирует другие подписи, которые я сделал, она просто будет считать подпись, сделанную автоматически командой, отправляющей транзакцию: обновление однорангового канала или одноранговыйЦепной код создает экземпляр , как будто эта последняя подпись делает недействительными подписи, которые я применял ранее вручную.

Некоторая идея о том, что мне не хватает?

Команды, которые я использовал:

Переменные, которые я изменил, чтобы сделать другую подпись:

  • CORE_PEER_LOCALMSPID
  • CORE_PEER_MSPCONFIGPATH

- отредактировано

Я работаю с first-network пример Fabric версии 1.4.0:

Это раздел Приложение в файле configtx.yamlфайл, в котором я обновил политику Writers с ANY Writers до MAJORITY Admins :

Application: &ApplicationDefaults

# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:

# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
#   /Channel/Application/<PolicyName>
Policies:
    Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
    Writers:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"
    Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"

Capabilities:
    <<: *ApplicationCapabilities

В контейнере cli я могу создатьканал без каких-либо проблем:

peer channel create --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file channel-artifacts/channel.tx

И после того, как я присоединюсь к пирам peer0.org1.example.com и peer0.org2.example.com без проблем.

Проблемы начинаются, когда япопробуйте отправить транзакции создания одноранговых узлов:

peer channel update --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file  channel-artifacts/Org1MSPanchors.tx

У меня есть сообщение об ошибке:

Ошибка: получен непредвиденный статус: FORBIDDEN - Не удалось достичь неявного порога 1 sub-политики, осталось 1: разрешение отклонено

Заказчик предоставляет более полные журналы: http://snippi.com/s/hlxkvl3

В журналах показано, что заказчик пытался выполнить эти действия для проверки подписейтранзакция:

  1. Строка 2: попытка оценить политику / Channel / Writers
  2. Строка 4: попытка оценить политику / Channel / Application / Writers
  3. Строка 6: попытка оценить политику / Channel / Application / Org1MSP / Admins
  4. Строка 20: набор сигнатур соответствует политике / Channel / Application / Org1MSP / Admins
  5. Строка 22: попыткадля оценки политики / Канал / Приложение / Org2MSP / Администраторы
  6. Строка 29: Набор подписей не удовлетворяет политике / Канал / Приложение / Org2MSP / Администраторы
  7. Строка 31: Ошибка оценки: была удовлетворена только 1 политика, но необходимо 2 из [Org1MSP.Admins Org2MSP.Admins]
  8. Строка 34: Оценка политики / Channel / Orderer / Writers
  9. Строка 43: Набор подписей не удовлетворяет политике / Канал / Заказчик / OrdererOrg / Writers
  10. Строка 48: Оценка не выполнена: были выполнены только 0 политик, но нужно 1 из [Application.Writers Orderer.Writers]

Когда я увиделэто ошибка, я сказал ОК, я сначала подпишу транзакцию с администратором Org1, а затем отправлю ее с подписью администратора Org2:

peer channel signconfigtx -f channel-artifacts/Org1MSPanchors.tx

CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.key
CORE_PEER_LOCALMSPID=Org2MSP
CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.crt
CORE_PEER_TLS_ENABLED=true
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
CORE_PEER_ID=peer0.org2.example.com
CORE_PEER_ADDRESS=peer0.org2.example.com:7051

peer channel update --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file  channel-artifacts/Org1MSPanchors.tx

Я получил сообщение об ошибке:

Ошибка: получено непредвиденное состояние: FORBIDDEN - Не удалось достичь неявного порога 1 под-политики, требуется 1 оставшееся: разрешение отклонено

Журналы от заказчика: http://snippi.com/s/qjb7dlv

Журналы показывают, что на этот раз заказчик сначала не может найти подпись администратора Org1 (строка 28, например), а затем находит подпись администратора Org2 (строка 45).И ни одна из двух политик / Channel / Application / Writers и / Channel / Orderer / OrdererOrg / Writers не была соблюдена (строка 64).

Я вижу, чторазмер файла транзакции увеличивается, когда я подписываю его, как доказательство того, что файл хорошо изменен.Но почему эта подпись, ожидаемая, например, заказчиком во время контроля, кажется ему невидимой?

Просто для продвижения вперед, в качестве временного обходного пути, я использовал MSP администратора заказчика для отправки транзакций якоря.peers:

CORE_PEER_LOCALMSPID=OrdererMSP
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/Admin\@example.com/msp/

peer channel update --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file  channel-artifacts/Org1MSPanchors.tx

На этот раз команда сработала.Но, как ни странно, это сработало только потому, что я ранее подписал транзакцию с MSP-администратором Org1, то есть, если я попытался отправить транзакцию с MSP-администратором заказчика без предварительной подписи с MSP-администратором Org1, произойдет сбой.Еще раз странно, если я начну с подписания транзакции с администратором заказчика, а затем с подачи ее с администратором Org1, команда снова не будет выполнена.

У меня возникают примерно те же проблемы, когда я пытаюсь создать цепной код, как мыможно посмотреть в логах заказчика: http://snippi.com/s/324asxa

Было бы неплохо получить подробное руководство о том, как работает механизм подписи Fabric.

1 Ответ

0 голосов
/ 26 февраля 2019

Политики Readers and Writers должны удовлетворять одной подписи, поскольку формат транзакции допускает ровно одну подпись.

Политика Admins - это политика по умолчанию, используемая для управления мутацией конфигурации канала (например, изменение политик Readers или Writers).Мутация конфигурации канала поддерживает рабочий процесс с несколькими подписями через peer channel signconfigtx.


Предполагается, что мы сможем подписать транзакцию с несколькими удостоверениями, и это может быть требование, настроенное вполитики.

Некоторые транзакции, например транзакции обновления конфигурации, могут быть подписаны несколькими удостоверениями.Другие транзакции, такие как вызовы цепного кода (включая вызовы lscc, такие как peer chaincode instantiate), обычно могут иметь только одного подписывающего лица.

Но я не могу заставить это работать, то есть у меня есть политика, требующаямножественные подписи, поэтому я подписываю файл транзакции (.tx) последовательно с информацией MSP двух организаций, но когда я отправляю транзакцию, заказчик или одноранговые узлы отклонят ее, сказав, что «Набор подписи не удовлетворяет политике... ".

Если это обновление конфигурации, то было бы полезно вставить больше журнала.Чаще всего, если переменные CORE_PEER_LOCALMSPID и CORE_PEER_MSPCONFIGPATH установлены правильно, политики не выполняются, потому что удостоверение не удовлетворяет требуемому правилу (обычно «admin»).

Если это обычный цепной кодвызов, как и операция жизненного цикла, приводит к неправильной настройке сети, поскольку эти вызовы должны быть выполнены с помощью одной подписи отправителя.

https://hyperledger -fabric.readthedocs.io /ru / release-1.4 / commands / peerchannel.html # peer-channel-signconfigtx

Эта команда действительно предназначена для того, чтобы позволить вам собрать несколько подписей для обновления конфигурации.

https://hyperledger -fabric.readthedocs.io / ru / release-1.4 / commands / peerchaincode.html # peer-chaincode-signpackage

Эта командане особенно полезно, и, вероятно, немного вводит в заблуждение.Он добавляет подписи, чтобы администратор мог вручную проверить соглашение, но эти подписи не используются при оценке любых политик Fabric.

...