stix2 icon indicating copy to clipboard operation
stix2 copied to clipboard

Object ID changes not handled

Open wrbrant opened this issue 1 year ago • 2 comments

Currently, I don't see anything in place to update an object's ID correctly if need be. For example, if I want to add a hash to an existing File object, I must regenerate the UUIDv5 manually according to the STIX 2.1 standard, since the old UUIDv5 is no longer applicable. However, this change is not populated up. If I were to call *Collection.Get(file.GetID()), it would return nil because this new ID is not in the collection's private 'objects', as seen here:

// Collection is a collection of STIX objects. This object is not part of the
// STIX specification.
type Collection struct {
	objects map[STIXType]map[Identifier]interface{}

	// Options
	noSort        bool
	order         []Identifier
	dropCustom    bool
	customHandler map[STIXType]func([]byte) (STIXObject, error)
}

It would be nice if there was something in place that

  • wouldn't require me to manually update an object's UUIDv5
  • would account for changes in IDs in the collection

Re-adding the object is not a valid work-around. Adding an object creates duplicate objects in the collection because *Collection.Add() uses the ID string, not an object's pointer, to determine if the object ought to be added.

wrbrant avatar Feb 13 '25 16:02 wrbrant

I think the easiest solution is to just add a remove method to the collection. That way, if you need to "update" an SCO you can create a new object using the NewFile function with data from the old. After that, just remove the old object from the collection.

TcM1911 avatar Feb 23 '25 13:02 TcM1911

That would be a good change. It would be nice to have an "update" method as well as a "remove". Perhaps you wouldn't even need to make the new file, you could just remove the old file from the collection, change the ID, and then add it back into the collection.

wrbrant avatar Feb 28 '25 15:02 wrbrant