-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
I'll be working on QSP-6 |
Taking QSP-8 |
Taking QSP-10 and QSP-11 |
Working on QSP-9 |
Taking QSP-58 and QSP-59 |
Taking QSP 13 and QSP 16 |
taking QSP-20 |
Working on 42 |
Workin on 61 |
working on QSP-14 |
Working on 35 |
Working on |
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. |
@nisdas for QSP-32, how do you think we should handle it? Basically:
However, the deadline is set to: // 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? |
|
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
(even more encompassing solution in [Tracking] Peer scoring service #6622 - it involves peer scoring on GossipSub, p2p req/resp, and synchronization level)
Beacon state trie management
Core processing
DB
P2P networking
Infra set up:
UX:
Others:
The text was updated successfully, but these errors were encountered: