You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Prysm allows for both snappy compressed and regular ssz encoded messages via p2p. Our security audit concluded allowing these two options is a security risk that can result in a network partition of someone operates nodes without snappy and others operate nodes with snappy enabled. Is there still a need for non-snappy encoded messages in the networking spec, or should the spec enforce snappy-compressed only?
The text was updated successfully, but these errors were encountered:
So we certainly shouldn't have non-snappy in gossip.
We have in currently in the req/resp which shouldn't be a security risk, but I don't see a particular use case for this
Hi all,
Currently Prysm allows for both snappy compressed and regular ssz encoded messages via p2p. Our security audit concluded allowing these two options is a security risk that can result in a network partition of someone operates nodes without snappy and others operate nodes with snappy enabled. Is there still a need for non-snappy encoded messages in the networking spec, or should the spec enforce snappy-compressed only?
The text was updated successfully, but these errors were encountered: