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

[Mega tracking] - Audit Resolutions #6327

Closed
61 tasks done
terencechain opened this issue Jun 21, 2020 · 15 comments
Closed
61 tasks done

[Mega tracking] - Audit Resolutions #6327

terencechain opened this issue Jun 21, 2020 · 15 comments
Labels
Priority: High High priority item Tracking Gotta Catch 'Em All

Comments

@terencechain
Copy link
Member

terencechain commented Jun 21, 2020

Opening this mega tracking issue to track the overall resolution progresses of the latest Quantstamp Audit report.
For all medium & above risk issues. Each issue will have its own tracking issue.
For the rest of the issues (e.g. low risk, informational, undetermined). The tracking issues will be grouped by component, and consolidated under one tracking issue under that component.

🥇Medium and above risk issues

🥈 Low risk issues grouped by components

Sync

Beacon state trie management

Core processing

DB

P2P networking

Infra set up:

  • QSP-22 Boot nodes availability and centralization risks (this is more about just having more than one bootnode as a default, rather than any changes to Prysm itself)

UX:

  • QSP-36 Weak passwords allowed for validator accounts (completely revamped v2 of accounts is implemented - many closed PRs)
  • QSP-37 Minimal system requirements

Others:

@terencechain terencechain added Tracking Gotta Catch 'Em All Audit labels Jun 21, 2020
@terencechain terencechain pinned this issue Jun 21, 2020
@prestonvanloon prestonvanloon added this to the Diamond milestone Jun 22, 2020
@rauljordan rauljordan added the Priority: High High priority item label Jun 22, 2020
@0xKiwi
Copy link
Contributor

0xKiwi commented Jun 22, 2020

I'll be working on QSP-6

@terencechain
Copy link
Member Author

Taking QSP-8

@terencechain
Copy link
Member Author

Taking QSP-10 and QSP-11

@rauljordan
Copy link
Contributor

Working on QSP-9

@terencechain
Copy link
Member Author

Taking QSP-58 and QSP-59

@nisdas
Copy link
Member

nisdas commented Jun 23, 2020

Taking QSP 13 and QSP 16

@shayzluf
Copy link
Contributor

taking QSP-20

@rauljordan
Copy link
Contributor

rauljordan commented Jun 23, 2020

Working on 42

@rauljordan
Copy link
Contributor

Workin on 61

@shayzluf
Copy link
Contributor

working on QSP-14

@rauljordan
Copy link
Contributor

Working on 35

@farazdagi
Copy link
Contributor

farazdagi commented Jun 24, 2020

Working on QSP-45 and QSP-6 (adding static analysis checker to enforce crypto/rand)

@rauljordan
Copy link
Contributor

rauljordan commented Jun 26, 2020

QSP-40 is not a possible condition, as the buffer can never be nil. For example:

func (e SszNetworkEncoder) EncodeGossip(w io.Writer, msg interface{}) (int, error) {
	if msg == nil {
		return 0, nil
	}
	b, err := e.doEncode(msg)
	if err != nil {
		return 0, err
	}
	if uint64(len(b)) > MaxGossipSize {
		return 0, errors.Errorf("gossip message exceeds max gossip size: %d bytes > %d bytes", len(b), MaxGossipSize)
	}
	if e.UseSnappyCompression {
		b = snappy.Encode(nil /*dst*/, b)
	}
+	if b == nil {
+		return 0, errors.New("attempting to write to nil buffer")
+	}
	return w.Write(b)
}

Even with a test that may seem like it could trigger the conditional check for b == nil, the code path is actually never reached. Worst case scenario, the result of snappy.Encode will be a buffer with length 1.

func TestSszNetworkEncoder_EncodeGossip_NilBuffer(t *testing.T) {
	buf := new(bytes.Buffer)
	type emptyContainer struct{}
	msg := &emptyContainer{}
	e := &encoder.SszNetworkEncoder{UseSnappyCompression: true}
	_, err := e.EncodeGossip(buf, msg)
	if err != nil {
		t.Error(err)
	}
}

The test above passes.

@rauljordan
Copy link
Contributor

rauljordan commented Jun 26, 2020

@nisdas for QSP-32, how do you think we should handle it? Basically:

The P2P specification says that: “The requester MUST wait a maximum of TTFB_TIMEOUT for the first response byte to arrive (time to first byte—or TTFB—timeout). On that happening, the requester allows a further RESP_TIMEOUT for each subsequent response_chunk received.” According to specification TTFB_TIMEOUT is 5s. It is the maximum time to wait for the first byte of request response (time-to-first-byte).

However, the deadline is set to:
on L24 in beacon-chain/p2p/sender.go.

// Send a message to a specific peer. The returned stream may be used for reading, but has been
// closed for writing.
func (s *Service) Send(ctx context.Context, message interface{}, baseTopic string, pid peer.ID) (network.Stream, error) {
	ctx, span := trace.StartSpan(ctx, "p2p.Send")
	defer span.End()
	topic := baseTopic + s.Encoding().ProtocolSuffix()
	span.AddAttributes(trace.StringAttribute("topic", topic))

	// TTFB_TIME (5s) + RESP_TIMEOUT (10s).
	var deadline = params.BeaconNetworkConfig().TtfbTimeout + params.BeaconNetworkConfig().RespTimeout

Seems like we'll have to (a) be aware of how many chunks there are and (b) use that to extend the context deadline appropriately by the RESP_TIMEOUT value for each. How can we the number of chunks here?

@rauljordan
Copy link
Contributor

  • QSP-4 Insecure gRPC connection by default: won't fix, this is only a concern for users that are running on different machines, and it will be a significant UX constraint to force normal users to handle and deal with TLS certs when they might not need to
  • QSP-57 Undocumented Kafka topics: won't fix, as it is too low priority and not much importance given barely anyone is using our kafka support
  • QSP-37 Minimal system requirements: will fix via a log
  • QSP-38 Running out of disk space (BoltDB Freelist is not cleared up): needs to look into, will open as a separate tracking issue

@rauljordan rauljordan unpinned this issue Nov 10, 2020
@rauljordan rauljordan removed this from the Diamond milestone Nov 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: High High priority item Tracking Gotta Catch 'Em All
Projects
None yet
Development

No branches or pull requests

7 participants