William Casarin [ARCHIVE] on Nostr: š Original date posted:2018-06-27 š Original message:Hey Andrew, If I'm reading ...
š
Original date posted:2018-06-27
š Original message:Hey Andrew,
If I'm reading the spec right: the way it is designed right now, you
could create hundreds of thousands of zero bytes in the input or output
key-value arrays. As far as I can tell this would be considered valid,
as it is simply a large array of empty dictionaries. Is this right? I'm
worried about buffer overflows in cases where someone sends a large blob
of zeros to an unsuspecting implementation.
Also, the extensibility section reads:
> Additional key-value maps with different types for the key-value pairs
> can be added on to the end of the format.
"different types for the key-value pairs", is this referring to new
types beyond the current global, input and output types?
> The number of each map that follows must be specified in the globals
> section
Is this out of date? Since there is only one type in the global section
now (tx).
> so that parsers will know when to use different definitions of the
> data types
I'm not sure what this means.
Thanks!
Will
--
https://jb55.com
š Original message:Hey Andrew,
If I'm reading the spec right: the way it is designed right now, you
could create hundreds of thousands of zero bytes in the input or output
key-value arrays. As far as I can tell this would be considered valid,
as it is simply a large array of empty dictionaries. Is this right? I'm
worried about buffer overflows in cases where someone sends a large blob
of zeros to an unsuspecting implementation.
Also, the extensibility section reads:
> Additional key-value maps with different types for the key-value pairs
> can be added on to the end of the format.
"different types for the key-value pairs", is this referring to new
types beyond the current global, input and output types?
> The number of each map that follows must be specified in the globals
> section
Is this out of date? Since there is only one type in the global section
now (tx).
> so that parsers will know when to use different definitions of the
> data types
I'm not sure what this means.
Thanks!
Will
--
https://jb55.com