Prior to this change, Koji would always send messages with a hard-coded
topic:// prefix.
This works fine for ActiveMQ 5 and Artemis, but RabbitMQ does not
support that syntax. Instead, RabbitMQ brokers expect clients to use
topic addresses with a "/topic/" prefix.
The RFE for RabbitMQ to support "topic://" prefixes is
https://github.com/rabbitmq/rabbitmq-server/issues/2583
In the meantime, allow users to specify "topic://" or "/topic/"
explicitly in their configuration.
For backwards-compatibility, if the user chose neither "topic://" nor
"/topic/", prepend the "topic://" string, preserving the plugin's
existing behavior.
(Note: ActiveMQ 5 advertises its expected topic:// prefix in the initial
connection properties, so we could read that value dynamically, but
RabbitMQ and Artemis do not send an expected topic prefix connection
properties, so we just make the user choose explicitly here.)
This supports packages which do not have the RPMv3 signature scheme
(over the full RPM header+payload), but instead only have signatures
over the header (v4 scheme).
For the v4 scheme, the signature is only stored in SIGTAG_RSA (or
SIGTAG_DSA).
Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>
This is a simple extention of `SCM.assert_allowed`
- `assert_allowed_by_policy` will set the default "use_common" to False which is different to the old behavior
- `channel`, `user_id`, `scratch` are passed in the `policy_data` with scminfo right now.
This is a prototype for this change, and there are some other solutions could be implemented too
- Use a scmpolicy plugin as `postSCMCheckout` callback, the pro is that we can do more checks after the source is initialized on builder, meanwhile, the con is that the source will be downloaded even it is denied by policy. It might be a potential risk?
- Do the scm check in hub's `make_task`, this looks straightforward, but may lack some builder's information
fixes: #2757
