When a Relying Party encounters a "withdraw" element, or a
"publish" element where an object is replaced, in a delta that it
retrieves from a Repository Server, it MUST verify that the object
to be withdrawn or replaced was retrieved from this same
Repository Server before applying the appropriate action. Failing
to do so will leave the Relying Party vulnerable to malicious
Repository Servers instructing it to delete or change arbitrary
objects.
The URIs from the publish/withdraw RRDP elements shouldn't be "mapped" to the same directory tree at --local-repository; the proposal is to use some kind of workspace to locally store and read such elements.
Currently the RRDP resultant files are created and updated at the same level that the RSYNC repositories files (at
--local-repository
).Quoting RFC 8182 section 3.4.2:
Also, a reference from sidrops mail archive: [Sidrops] RRDP and rsync URIs
The URIs from the publish/withdraw RRDP elements shouldn't be "mapped" to the same directory tree at
--local-repository
; the proposal is to use some kind of workspace to locally store and read such elements.