Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial client go sdk prototype #452

Merged
merged 1 commit into from
Oct 27, 2020

Conversation

mbrandenburger
Copy link
Contributor

Signed-off-by: bur [email protected]

What this PR does / why we need it:

  • initial go sdk extension for FPC that hides the FPC transaction flow
    from the user
  • integrate with test-network

Which issue(s) this PR fixes:

Fixes #289

Special notes for your reviewer:

Does this PR introduce a user-facing changes and/or breaks backward compatability?:

@mbrandenburger mbrandenburger requested a review from a team October 20, 2020 21:02
@mbrandenburger
Copy link
Contributor Author

Note that eecb1cd relies on a little modification at the go sdk. Opened a PR

@mbrandenburger
Copy link
Contributor Author

mbrandenburger commented Oct 22, 2020

Fabric go sdk PR was already merged!

@mbrandenburger mbrandenburger changed the title Add initla client go sdk prototype Add initial client go sdk prototype Oct 22, 2020
Copy link
Contributor

@g2flyer g2flyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general looks very nice regarding the user-facing API. I have a number of observations regarding implementation but most of the issue might be better addressed elsewhere (primary concern is that there are some issues like interface between c and go (issue #412) and encoding/decoding, formats of request/response we seem to make somewhat implicit which i think we should make a bit more explcit/consciously ...). For actual PR, assuming you are happy with my clickable suggestions, themain concern is that it doesn't build

go.mod Outdated Show resolved Hide resolved
Comment on lines 10 to 11
"crypto/sha256"
"encoding/hex"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These and below internal/protos cause me build problems until removed ...

internal/utils/utils.go Show resolved Hide resolved
client_sdk/go/fpc/contract.go Show resolved Hide resolved
client_sdk/go/fpc/lifecycle.go Show resolved Hide resolved
client_sdk/go/fpc/contract.go Outdated Show resolved Hide resolved
Comment on lines +45 to +59
credentials := &protos.Credentials{}
err = proto.Unmarshal(credentialsBytes, credentials)
if err != nil {
return fmt.Errorf("cannot unmarshal credentials: %s", err)
}
log.Printf("Received credentials from enclave: %s\n", credentials)

// perform attestation evidence transformation
credentials, err = attestation.ToEvidence(credentials)
if err != nil {
return err
}

credentialsBytes = protoutil.MarshalOrPanic(credentials)
credentialsBase64 := base64.StdEncoding.EncodeToString(credentialsBytes)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be worth "outsourcing" this in a separate function as a simply cmd-line utility wrapper would be exactly the transform you would need in the peer cli (i.e., only a single and simple implementation and also a simplification of the peer cli script ...

Comment on lines +1 to +13
package fpc

func Encrypt(input []byte, encryptionKey []byte) ([]byte, error) {
return input, nil
}

func KeyGen() ([]byte, error) {
return []byte("fake key"), nil
}

func Decrypt(encryptedResponse []byte, resultEncryptionKey []byte) ([]byte, error) {
return encryptedResponse, nil
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you assume we surface pdo crypto via cgo? As discussed in #412, i thought conceptually bridging at a higher-level (for arguments discussed there). The devil is in the details and what i propose might not work. However, i feel we should make a conscious decision on this interface. Right now it seems to me we end up making an implicit decision while not necessarily have considered the implication (maybe you did, but then i think we should reflect it in #412 and also resolve it there?)

To some extent it also seems to related on what exactly the semantics is of the "Transaction Crypto Library" boxes in mural?

client_sdk/go/fpc/contract.go Show resolved Hide resolved
client_sdk/go/fpc/contract.go Show resolved Hide resolved
@bvavala
Copy link
Contributor

bvavala commented Oct 23, 2020

but most of the issue might be better addressed elsewhere (primary concern is that there are some issues like interface between c and go (issue #412) and encoding/decoding, formats of request/response we seem to make somewhat implicit which i think we should make a bit more explcit/consciously ...).

I agree that these could be better addressed elsewhere, and I would add later after getting the next release out.

@g2flyer
Copy link
Contributor

g2flyer commented Oct 23, 2020

I agree that these could be better addressed elsewhere, and I would add later after getting the next release out.

If we don't agree on these encodings, interfaces and types (either explicitly or impliciltly) then there will be no next release?

@bvavala
Copy link
Contributor

bvavala commented Oct 23, 2020

I agree that these could be better addressed elsewhere, and I would add later after getting the next release out.

If we don't agree on these encodings, interfaces and types (either explicitly or impliciltly) then there will be no next release?

Interfaces and protobufs are already defined, there is no need (at least at this point) for additional details -- hopefully this matches with your definition of "implicit" agreement.
The components being implemented are already part of the next release, and match the design.

@g2flyer
Copy link
Contributor

g2flyer commented Oct 23, 2020

Interfaces and protobufs are already defined,

The interfaces i was referring to is regarding #421 which we haven't designed. Regarding protobufs, we forgot to define message format for (encrypted) fpc chaincode invocations (request and response). Our spec also omitted the encoding of messages between client and fpc_stub. We agreed in yesterday's call verbally on that encoding (i.e., base64-encoding of binary-serialization of protobuf objects), my point was only that we might also simply document that (and remove the misleading reference to json-protobuf). Anyway, i can do an AR on myself to create a PR which creates a proposal for the missing protobufs and does the small fix to interfaces.md regarding the encoding.

g2flyer added a commit to g2flyer/fabric-secure-chaincode that referenced this pull request Oct 27, 2020
- initial go sdk extension for FPC that hides the FPC transaction flow
  from the user
- integrate with test-network
- CreateEnclave requires target peer endpoint
- FPC invocations are invoked (queried) at a defined endpoint
- Update go sdk version and address review

Signed-off-by: bur <[email protected]>
Co-authored-by: Michael Steiner <[email protected]>
Copy link
Contributor

@bvavala bvavala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good overall.
I can see some discrepancies going forward -- mainly the client/chaincode protocol -- but that's fine. We'll reconcile these in upcoming PRs.

Copy link
Contributor

@g2flyer g2flyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, now make build test works and documented steps in README also all work. There is a bug in client-sdk test program but will fix that in separate PR and merge this one ...

@g2flyer g2flyer merged commit 57737a8 into hyperledger:flow-refactoring Oct 27, 2020
@mbrandenburger mbrandenburger deleted the go-sdk branch October 27, 2020 22:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants