restricting build target based on source control branch
by Mátyás Selmeci
Hi,
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?
Thanks,
-Mat
--
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
5 years, 1 month
txkoji 0.2.0 available
by Ken Dreyer
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
arithmetic.
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
- Ken
5 years, 1 month
Any issues with the updates?
by Michael McLean
I hope everyone running 1.12 to 1.15 was able to apply the updates
yesterday. Things went pretty well on our end.
If you did run into any issues, I'd like to hear about it.
5 years, 1 month
Koji CVE-2018-1002150
by Michael McLean
Dist repo call missing authorization check allowing filesystem manipulation
Summary
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.
Workaround
We strongly recommend that all Koji admins implement this workaround
immediately. This workaround will effectively disable dist-repo
functionality.
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:
1.
Move the repos-dist directory to another location (if it exists)
2.
Replace it with a plain text file warning of the situation. Do not skip
this step.
For example:
$ 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
repo.
Bug fix
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
fix:
-
1.15.1
-
1.14.1
-
1.13.1
-
1.12.1
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
take effect.
Links
Fixed versions can be found at our releases page:
https://pagure.io/koji/releases
Questions and answers about this issue
https://docs.pagure.org/koji/CVE-2018-1002150-FAQ/
5 years, 1 month
Feedback requested: kojihub and large ints
by Michael McLean
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
involved.
In Koji 1.14, we started accepting and returning i8 tags, an extension to
the xmlrpc standard.
https://docs.pagure.org/fork/mikem/koji/release_notes_1.14/#large-integer...
https://pagure.io/koji/pull-request/571
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:
https://pagure.io/koji/issue/750
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.
So...
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.
5 years, 1 month
Koji Community Meeting Notes - Mar 7
by Yuli Wang
*Meeting Purpose: * Improve the communication with upstream(community)
*Attendees: *ngomp, dgregor, sly, jdisnard, tkopecek, yzhu, Jana, Egor,
Brendan,mikem, yulwang
*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:
https://public.etherpad-mozilla.org/p/KojiMarch2018
*Meeting Notes:*
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:
- https://pagure.io/koji/issue/736
- 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)
2.Koji update:
- Koji 1.15 released on Dec 2017
https://docs.pagure.org/koji/release_notes_1.15/
- Fedora in process of upgrading to 1.15
- Koji 1.16 planning: Mar 28, 2018
https://pagure.io/koji/roadmap?status=all&milestone=1.16
- Koji 1.17 planning
3. Community feedback / input
- Mageia
- 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
building
- 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
- https://gitlab.com/mdklinux/mgapkg-koji
- 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
Thanks,
Yuli
5 years, 1 month
