parallaxsecond / parsec-client-go Goto Github PK

View Code? Open in Web Editor NEW

12.0 12.0 5.0 405 KB

Parsec Go client

License: Apache License 2.0

Go 94.37% Makefile 1.55% Dockerfile 0.32% Shell 3.75%

parsec-client-go's People

Contributors

Stargazers

Watchers

Forkers

daxmc99 paulhowardarm jn9e9 hasheddan isabella232

parsec-client-go's Issues

nil checking for wire interface conversions

there are a number of places where wire interface objects could be nil in conversion routines, but these are not always tested before dereferencing- could lead to panics

CI Test no longer works

Since april, parsec service and related CI test docker file have moved on, which means that go client ci test scripts cannot compile parsec service and likely won't work anyway.

complete e2e testing of public api

Ensure we have coverage of success for all supported operations, and ensure that unsupported operations on each provider return appropriate failure codes.

Add native go style api wrapper to basic client

Basic client follows the parsec wire api operations closely. We need an implementation that wraps this in a much more natural go wrapper. the go crypto library (https://golang.org/pkg/crypto/) may provide a good start, but further research is probably needed.

This API could be part of this library, or could be its own library altogether.

unit test for protobuf level serialisation/deserialisation

tests for wire interface header serialisation, as well as individual parsec calls in operations_client.go

fix test error uploading code coverage results to codecov

Remove this stage or set up appropriate access token

Add clients (list, delete) and admin functionality to go client

including unit & e2e tests

Make server connection read/write robust to partial message read/write

currently interfaces/operations/operations_client.go Client.operation() assumes that the whole of a request is successfully written to the output writer in one go, whereas the write api allows for only part of the buffer to be written in any one transaction.

On the read side, for the response, it also assumes that the whole of the response is received in one go. It also does not copy with resynchronisation to find a new header magic number if it finds itself in a confused state

Add direct authentication support

including unit and ci testing

unit testing for public interface code

especially the conversions to/from protobuf interface types, e.g. algorithm package, as well as keyinfo, keytype

fuzz testing of interface

Definitely need fuzz to test resilience to rogue responses from parsec daemon - allows clients to protect themselves.
Fuzz testing from public api will assist in robustness of api

Protoc instructions and makefile not correct

The README.md does not include instructions for installing protoc tools, and the makefile assumes the dev environment is under GOPATH/src in fully qualified folder, which is not necessarily true as we use go modules.

Fix protoc file generation and readme.

Change e2e tests to use common parallaxsecond docker image

I think it's fine to remove those Dockerfile and directly run ghcr.io/parallaxsecond/parsec-service-test-all in your test script.

Originally posted by @hug-dev in #32 (comment)

Add automatic crypto provider and authenticator selection

In the Rust BasicClient, during the constructor we automatically choose the default provider and authenticator. See here.

They are choosen from the first entry of the ListProviders and ListAuthenticators commands. That way, once client have successfully generated on instance of the basic client, they can already start making secure crypto operations without any set-up needed 👌

It would be nice to have something similar in the Go client! I believe all the pieces are there, it would just need some logic.

remove static analysis/lint errors from codebase

actions are currently reporting a large number of static analisys errors (mostly relating to non-documentation of public api elements.

Refactor code to reduce number to zero (nolint directives as last resort)

Add shellcheck test to bash scripts in ci and makefile and ensure those are clean

Wireheader improvements to prepare for potential wire header changes

Note that the first four fields:

magic number
header size
major version number
minor version number

will always have the same width and position on every Parsec request/response header, no matter the wire protocol version. It would then make sense to either separate them in their own structure or not include them in the wireHeader structure, which will be the one that is versioned. In the Rust interface, we put the rest in its own wire_header_1_0 module to make it easy to write the logic selecting the correct wire header format. Though we did not implement that logic yet, at least we have the building blocks 😋 you have some more info here

Originally posted by @hug-dev in #28 (comment)

Also consider this comment: #28 (comment)

Add timeout to unix socket connection

rust client has a timout on the unix socket connection (of configurable length) which allows the client application to recover (i.e. detect failure and compensate if possible) if the parsec daemon is not responding. Go client needs same functionality - default of 1s likely sensible.

complete unimplemented methods

there are still a couple of unimplemented methods (operations_client.go, hash.go)- fix these and ensure we have unit tests for the methods and related methods

Allow for configuration of unix socket path

currently fixed to /run/parsec/parsec.sock, should be modifiable, possibly config file support?

get ci test working again

based on current parsec ci test
add periodic build to ensure breakage does not go unnoticed again

Zeroise memory used for sensitive data

mostly on the operations data (for encrypt decrypt ops), but also consider direct auth

Documentation published somewhere?

Would it be possible to publish the Go client somewhere so that its documentation is visible? Something like that?

Give jn9e9 the Write role

Hi @jn9e9!

I would like to propose you to have the Write role for both parsec-client-go and parsec-mock. With that role you will be able to help us maintain those repositories by being able to approve and merge pull-requests. Find here a more complete description of what the Write role permits.

More than fair since all of this code is yours 😄
Thanks for your work!!

Add OpCode method to autogenerated operation types

In order to reduce chance of picking incorrect opcode in the operations_client.go, define it in an OpCode method attached to each request type.
Would it be possible to deduce the opcode from the type of request? As in have a method on each type of request to return the corresponding opcode? That would remove one parameter to operation

Originally posted by @hug-dev in #28 (comment)

Fix shellcheck errors in e2etest/scripts/ci.sh

File was copied from parsec e2e tests and contains a number of shellcheck errors - fix

add provider specific e2e testing

ci testing follows same format as rust client in that it allows an end to end suite for all providers and individual test suites for each provider in turn.

Currently ci testing only supports the all providers variant - expand to do other providers individually.

Docker files and scripts are in place, but e2etest/scripts/ci.sh does not support yet, and we probably need to use build tags to control which tests to include.

The docker build now pulls from a common e2e image that is used for parsec. We could parameterise the go client local image to specify the required features to reduce the number of docker files in the e2e go client tests