We'd like to prevent people from accidentally building into a target
from the wrong SVN branch (e.g. building into the osg-3.4 target from
the osg-3.3 branch). We have a wrapper script around "koji build" that
does this check, but it would be nicer if we could do it server side.
Is that something we can do?
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
I've updated https://github.com/ktdreyer/txkoji with several changes recently:
- Custom classes for Build, Task, Package
These classes have their own special helper methods to implement
things I found interesting, like datetime conversions for the
start/completion timestamps, or url properties for representing the
objects in Kojiweb.
- getAverageBuildDuration() returns a datetime.timedelta object
instead of a raw float, because this is more useful to do time
I've published my first cut of a dedicated Koji chat bot plugin that
uses this library, at https://github.com/ktdreyer/helga-koji
The bot can estimate the remaining time for ongoing builds, like:
< ktdreyer> helgabot: current ceph build
< helgabot> ktdreyer, ceph-12.2.1-1.el7 should finish building in 3
min 45 sec https://cbs.centos.org/koji/buildinfo?buildID=20348
Dist repo call missing authorization check allowing filesystem manipulation
This is a critical security bug.
From versions 1.12.0 to 1.15.0, the Koji hub did not perform proper access
checks for the hub.distRepoMove call. By passing carefully constructed
arguments to the call, an unauthenticated user can trick Koji into moving
content around that it should not. This could result in corrupting any
files that the httpd process can write to, or revealing any files that the
httpd process can read. If the user can authenticate (at any privilege
level), then they can use this mechanism to replace a file with one that
they have uploaded.
We strongly recommend that all Koji admins implement this workaround
immediately. This workaround will effectively disable dist-repo
Because use of the hub.distRepoMove call requires a valid dist repo that
exists on disk, exploitation can be blocked by ensuring that there are
none. There are many ways this might be done. We recommend the following:
Move the repos-dist directory to another location (if it exists)
Replace it with a plain text file warning of the situation. Do not skip
$ cd /mnt/koji
$ mv repos-dist repos-dist.old
$ echo "DO NOT REMOVE. CVE-2018-1002150" > repos-dist
$ ls -l /mnt/koji/repos-dist
-rw-r--r--. 1 root root 32 Mar 19 14:35 /mnt/koji/repos-dist
When applying this workaround, make sure to take both steps. If you do not,
then the system will recreate the directory if anyone creates a new dist
Note: because code fixes can take time to deploy, we strongly recommend
that all admins apply the above workaround first. The workaround can be
easily undone once the fix is in place.
We are releasing updates for each affected version of Koji to fix this bug.
The following releases <https://pagure.io/koji/releases> all contain the
Versions prior to 1.12.0 are not vulnerable because they do not have the
dist-repo feature. Also, the legacy-py24 branch is unaffected since it is
client-only (no hub).
For users who have customized their Koji code, we recommend rebasing your
work onto the appropriate update release. If this is not feasible, the
patch should be very easy to apply. Please see issue #850
<https://pagure.io/koji/issue/850> for the code details.
As with all changes to hub code, you must restart httpd for the changes to
Fixed versions can be found at our releases page:
Questions and answers about this issue
tl;dr -- if your Koji client code can't handle i8 tags, please speak up!
The baseline xmlrpc standard only supports 32bit signed integers. This has
been a problem for Koji over the years. Early on, we performed some
targeted string conversion on integers over the limit in the few places the
kept cropping up (file sizes generally). This worked using the encode_int
and decode_int functions. For users of the Koji python lib, things just
worked. Other users had to do a little more work if large ints were
In Koji 1.14, we started accepting and returning i8 tags, an extension to
the xmlrpc standard.
This was a much better approach. However, it did require that clients
understand the i8 tag. We knew that Python's xmlrpc lib did. However, we
weren't sure how broadly this extension was implemented elsewhere.
Because we weren't sure, we left the existing targeted string conversions
on the hub side alone. We filed this bug to track its eventual removal:
At this point, we're considering removing those workarounds and letting the
code just use the i8 tags for all our large ints. However, we don't want to
suddenly break any non-python code that is interacting with a Koji instance.
Do you have code that will break if the hub returns an i8 tag?
If so, how much work would it be to fix that?
Please comment on Issue 750 with your concerns.
*Meeting Purpose: * Improve the communication with upstream(community)
*Attendees: *ngomp, dgregor, sly, jdisnard, tkopecek, yzhu, Jana, Egor,
*Meeting Summary:*3 koji stakeholders besides Brew team joined our 2nd koji
community meeting. we mainly talked last meeting actions and Koji recent
update and get the feedback from community.
detail please check our meeting docs:
1.Review last action items
- "office hours" proposal - Every Tue/Thurs 10:00 - 11:00AM US/ET
（welcome your feedback in the meeting notes）
- koji-devel could be there
- which channel? #koji ? #fedora-releng (larger)
- Let's use #koji
- won't be active all the time, but when we have koji conversations
let's have them in #koji
- AI: Send an announcement to koji-devel@
- Research on how do external users use the Message bus plugins:
- Question from mikem: who might use it?
- AI: mark as deprecated in 1.16 and send out an announcement to speak
up if it's still needed(release note+ separate notification)
- Koji 1.15 released on Dec 2017
- Fedora in process of upgrading to 1.15
- Koji 1.16 planning: Mar 28, 2018
- Koji 1.17 planning
3. Community feedback / input
- bootstrap chroot is very important to Mageia. One challenge for koji
is that the repo used to bootstrap is likely different than the repo for
- Maybe use the same repos for both? We already do this for SRPM -> RPM
build chroots. Mock's current bootstrap feature works that way.
- issues around auto-generating the SRPM changelog. Questions around
how to integrate this prebuild script
- Variety of issues related to installing koji. messagebus plugin isn't
compiling. Some other things... (Neal, can you fill in?)
- Opportunity to use Mageia as a way of making installation easier, or
at least documenting it better
- Let's move this to office hours.
- Fedora Releng - Sly
- Schedule: https://fedoraproject.org/wiki/Releases/28/Schedule
- Beta Freeze was March 6
- In the middle of Fedora 28
- Currently no issues with koji
- Have not started Fedora 29 planning yet