koji-devel April 2018

koji-devel@lists.fedorahosted.org

6 participants
7 discussions

restricting build target based on source control branch
by Mátyás Selmeci 17 Apr '18

17 Apr '18

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

3 5

txkoji 0.2.0 available
by Ken Dreyer 09 Apr '18

09 Apr '18

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

1 0

Any issues with the updates?
by Michael McLean 05 Apr '18

05 Apr '18

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.

2 2

Koji CVE-2018-1002150
by Michael McLean 04 Apr '18

04 Apr '18

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/

1 0

Feedback requested: kojihub and large ints
by Michael McLean 02 Apr '18

02 Apr '18

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-s… 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.

1 0

Upcoming CVE-2018-1002150 for Koji
by Michael McLean 02 Apr '18

02 Apr '18

A new CVE for Koji will become public soon. We will announce the details on Wednesday, April 4th around 14:00 UTC. The announcement will go to the koji-devel and oss-security mailing lists: https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.… http://www.openwall.com/lists/oss-security/ <https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.…>

1 0

Koji Community Meeting Notes - Mar 7
by Yuli Wang 02 Apr '18

02 Apr '18

*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

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

koji-devel April 2018