Missing validation around ObjectId and LibraryId

[GrabYourPitchforks]

According to the MS-NRBF spec, ObjectId and LibraryId values must be positive 32-bit integers. Currently these values are read with no validation.

Additionally, the current behavior for the reader is that if it encounters multiple objects / libraries with the same id in the serialization stream, any records which appear later in the stream override records which appear earlier in the stream. This is an example of an opinionated behavior. Is this intentional? What are the consequences of allowing this?

[adamsitnik]

ObjectId and LibraryId values must be positive 32-bit integers

This was my initial assumption, but it turned out that ObjectIds that are referenced by other objects can be negative ;)

SafePayloadReader/System.Runtime.Serialization.BinaryFormat/SafePayloadReader.cs

Lines 191 to 194 in cfb7ac5

	// From https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nrbf/0a192be0-58a1-41d0-8a54-9c91db0ab7bf:
	// "If the ObjectId is not referenced by any MemberReference in the serialization stream,
	// then the ObjectId SHOULD be positive, but MAY be negative."
	if (record.ObjectId != SerializationRecord.NoId)

I've hit that case when implementing some more sophisticated test.

I'll carefully study the spec for each record type and add the validation

[adamsitnik]

any records which appear later in the stream override records which appear earlier in the stream

If an object with given Id has been already recorded, the Add method is going to throw:

SafePayloadReader/System.Runtime.Serialization.BinaryFormat/SafePayloadReader.cs

Lines 196 to 197 in cfb7ac5

	// use Add on purpose, so in case of duplicate Ids we get an exception
	recordMap.Add(record.ObjectId, record);

I need to write tests for invalid inputs to have it covered.