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
If I've just started buildArch task with weight 1.5 on builder with 1.5
capacity, it can pick another one, as it is not over the builder's
capacity. This is wrong as there is no real capacity behind.
Alternative DSN connection string fro connecting to postgres. Allow us
to specify e.g. sslmode without adding separate DB* options.
Fixes: https://pagure.io/koji/issue/2838
"malformed task" has been returned for everything unknown, but external
plugins can create completely valid tasks which we can't parse without
those plugins. In such case we want to return at least method/arch info.
Related: https://pagure.io/koji/issue/2904
We've replaced it with requests library some time ago, this code has no
better sensitivity than requests error checking, so we can drop it
completely.
Fixes: https://pagure.io/koji/issue/2752
In koji-1.22.0-129-g0ef3c751 I've changed the way how
site-packages directory is obtained. What I did not realize back
then is there can be multilib systems which will not search for
packages in /usr/lib64. But 64bit systems do look into /usr/lib.
Therefore, let's pick the location where both systems work.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1894261Fixes: #2578https://pagure.io/koji/issue/2578
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
