Re: [Cbor] Robert Wilton's No Objection on draft-ietf-cbor-file-magic-11: (with COMMENT)

[Michael Richardson <[e-mail]>]

Rob Wilton \(rwilton\) <rwilton=[e-mail]> wrote:
    >> > if C often does use strcpy (or even strncpy), then avoiding the zero
    >> byte isn't the only problem, it also has the risk of capturing
    >> arbitrary extra bytes which would presumably make the magic number
    >> check less reliable?
    >>
    >> That is easily avoided by using strncpy(dst, buf, 8).  But that is
    >> advice we maybe don’t want to give (see below).

    > My thought was that if a prefix of those bytes were fixed with the real
    > magic number and the remainder were arbitrary then the magic number for
    > a given file isn't fixed since it is potentially picking up contents
    > that could change with the definition of the file.  But perhaps the
    > algorithm for checking against magic numbers is designed to cope with
    > this, e.g., find the longest prefix match.

If you use Tag wrapped, then your magic number is 8 bytes, which is the
55799(4byte(  prefix.  The Sequence method is really just doing the
same thing to the content h'424f52' (BOR).
So the numbers are fixed, but you are right that some kind of longest prefix
match might make sense here.

I don't really care if we say to avoid null bytes or not.
It's just a suggestion.

I think that it makes life easier for people trying to use/find objects based
upon magic numbers.   It has been years since I've had to sit with a hex dump
and search it for evidence/rescue data.
It's slightly easier for the human with a hex dump tool to search for
sequences that have no nulls in them.  Yes, I'm talking about... in emacs with hexl-mode.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide