Tag Archives: koji

CVE-2014-7169 updates on Fedora.

CVE-2014-7169 is an additional security issue in the GNU bash shell that emerged after researchers discovered the fixes for CVE-2014-6271 did not completely solve the vulnerabilities they had identified. Fedora Magazine has a very useful story that tells you why these issues are important.

Since I already published a story on how to deal with CVE-2014-6271, I might as well do a quick followup here for my readers on how to deal with the additional vulnerability.

These instructions will allow you to quickly get packages from the Fedora Koji package build system to address both CVEs, without having to wait for them to propagate to Fedora’s worldwide mirror system.

Fedora 21 Alpha

Run these commands:

su -c "yum -y install koji"   # provide root password...
koji download-build --arch=$(uname -m) bash-4.3.25-2.fc21
su -c "yum localinstall bash-4.3.25-2.fc21.$(uname -m).rpm"   # provide root password again...

Fedora 20

Run these commands:

su -c "yum -y install koji"   # provide root password...
koji download-build --arch=$(uname -m) bash-4.2.48-2.fc20
su -c "yum localinstall bash-4.2.48-2.fc20.$(uname -m).rpm"   # provide root password again...

Fedora 19

Run these commands:

su -c "yum -y install koji"   # provide root password...
koji download-build --arch=$(uname -m) bash-4.2.48-2.fc19
su -c "yum localinstall bash-4.2.48-2.fc19.$(uname -m).rpm"   # provide root password again...

Hope this helps!

CVE-2014-6271 updates on Fedora.

IMPORTANT: Refer to this update for revised instructions.

What is CVE-2014-6271?

CVE-2014-6271 is a GNU bash vulnerability that permits specially-crafted environment variables to inject shell commands. This is a fairly serious issue. If you don’t want to wait out the hours until stable updates are issued to fix your Fedora system, here’s what you can do. (The Fedora Project may choose to issue some official guidance, this is just my own helpful hint.)

Fedora 21 Alpha

Run these commands:

su -c "yum -y install koji"   # provide root password...
koji download-build --arch=$(uname -m) bash-4.3.22-3.fc21
su -c "yum localinstall bash-4.3.22-3.fc21.$(uname -m).rpm"   # provide root password again...

Fedora 20

Run these commands:

su -c "yum -y install koji"   # provide root password...
koji download-build --arch=$(uname -m) bash-4.2.47-4.fc20
su -c "yum localinstall bash-4.2.47-4.fc20.$(uname -m).rpm"   # provide root password again...

Fedora 19

Run these commands:

su -c "yum -y install koji"   # provide root password...
koji download-build --arch=$(uname -m) bash-4.2.47-2.fc19
su -c "yum localinstall bash-4.2.47-2.fc19.$(uname -m).rpm"   # provide root password again...

Hope this helps!

Finding old test packages in Koji.

After I answered a question on the devel list today about getting one’s hands on an old testing package for Fedora that had been obsoleted or removed, Josh Boyer one-upped me by providing some easy instructions. I figured I would tip my fedora to him by building a blog post on his work. Nice one, Josh!

When someone builds an official Fedora package, whether it ultimately gets moved to stable or not, there’s a record for it in Koji, the Fedora package build system. You can use the search bar on the Koji website to find the package or build you’re inerested in. In the resulting page, you’ll find the build is labeled with the git commit from which the build came — it’s the long checksum in the “Task” line.

The package may not be there anymore, but that git label is all you need. It represents the position in the repository history from which the packager built that package. You can find that point in history and re-execute the same steps. You can then clone the package’s git repository, reset the HEAD to the proper commit, and send a scratch build to the Koji builder. Once the build is done, you can download the results.

Caveat: It’s possible that other package changes in Fedora might make a build of that exact point in history difficult later. Be aware this solution isn’t perfect, and you may simply want to find an alternate build in Koji that still exists and suits your purpose, or use the latest updates-testing or stable package instead. But in the hopes people find it useful, here are the commands, assuming the package name is “foobar” on Fedora 16 and the git commit of interest in starts with “0123abcd” (and let’s hope I do better than in the last post in which I gave tips):

su -c 'yum install fedora-packager'
cd /tmp
fedpkg clone foobar
cd foobar
fedpkg switch-branch f16
git reset --hard 0123abcd
fedpkg scratch-build
The URL that comes back to your console is the task for that build, and you can use that to drill down into the individual package build tasks as needed later. Remember, scratch builds are not retained for very long, so if you want the package, try to download it relatively soon after you build it.

Here’s another hint: the git reset command above rewrites your index and your working tree, so essentially you “lose” the later history of the repository. However, git is so awesome that this is not a permanent condition. If you really need to reset the git repository back to its original path, you can use git reflog to find the reference to the checkout you did of the “f16” branch, and reset to it (probably something like this):

git reset --hard HEAD@{1}
Once again, it’s important to point out that the above is not for the faint of heart. If you don’t understand the ramifications of trying withdrawn, obsolete, or deleted packages on your Fedora machine, or packages intended for testing, don’t use them. That being said, testing packages is a really helpful activity, and there are all sorts of easy ways to keep testing contained on your system, such as using virtual guest machines. So the intrepid needn’t be shy!

Odds and ends, no. 55.

  1. Mike Bonnet has a very useful script for downloading koji scratch builds here.
  2. The meetbot will congenially let you chair someone who’s not in a meeting — i.e. the wrong IRC nick. This can be embarrassing when that person takes over chair duties, and not only doesn’t know that action items aren’t being recorded, but also can’t end the meeting.

These items both lead me to believe that there’s no automated substitute for Knowing What You’re Doing. 😉