Bug#888244: apparmor: Convert quilt patch series to per-topic subdirectories managed by gbp-pq
On 03/18/2018 09:24 AM, intrigeri wrote:
> Hi,
>
> Tyler Hicks:
>>> 3. Give me the go ahead and then I'll:
>>>
>>>- refresh the {debian,ubuntu}/gbp-pq branches
>>>- merge the {debian,ubuntu}/gbp-pq branches respectively into
>>> {debian,ubuntu}/master
>>>- push {debian,ubuntu}/master
>>>- release & upload to Debian sid
>>>- ask you to release & upload to Ubuntu
>
>> I've taken a quick look at the gbp-pq branches and it sounds like Steve
>> did, as well. I see the value there so you've got the go ahead. :)
>
> Done. So check the current ubuntu/master and if suitable, upload
> to Ubuntu.
I've finalized, tagged, and pushed ubuntu/master. I've also uploaded to
Ubuntu Bionic.
Tyler
signature.asc
Description: OpenPGP digital signature
Bug#888244: apparmor: Convert quilt patch series to per-topic subdirectories managed by gbp-pq
On 03/14/2018 10:46 PM, Tyler Hicks wrote: > On 02/28/2018 04:56 AM, intrigeri wrote: >> It would be great if we could do that before 18.04 LTS is too deeply >> frozen so you can benefit, in the next 5 years, from all the goodness >> ubuntu/master..debian/master has accumulated since your last merge >> from Debian. If that timing is not an option, we could of course >> postpone this to post-18.04-release but then you'll have to deal with >> two vastly different debian/ directories between your LTS and ongoing >> development branches, which I expect might be quite painful and >> error-prone. > > We are running late on getting this merge done. Let me know if you think > it'll be a bit before you can do all the steps you outlined in #3 above. > If that's the case, I should probably go ahead and upload what's in > ubuntu/master now and then do another small, incremental upload after > the gbp-pq changes are merged. I decided to finalize, tag, and upload 2.12-3ubuntu1 to Bionic without the gbp-pq changes so that it doesn't put intrigeri in the hot seat to make those changes. We'll be happy to do an additional upload that incorporates the packages changes needed for gbp-pq (as long as it isn't too late in the Bionic cycle). You'll find that the ubuntu/master branch is updated and the ubuntu/2.12-3ubuntu1 is pushed to salsa. Tyler signature.asc Description: OpenPGP digital signature
Bug#888244: apparmor: Convert quilt patch series to per-topic subdirectories managed by gbp-pq
On 02/28/2018 04:56 AM, intrigeri wrote:
> Hi,
>
> Steve Beattie:
>> Sorry, I've been swamped coping with Meltdown/Spectre. I took a brief
>> look at the topic git branches and it seems like a modest enough
>> organizational improvement to me[1].
>
> OK. To me being able to use gbp-pq is a life-changer and I hope it'll
> be the same for you once you get used to it, but I agree that at the
> end of the day we're still tracking patches in Git, which has a number
> of drawbacks including the ones you've mentioned :)
>
>> What would need to happen on the Ubuntu side to go forward?
>
> Thanks for asking!
>
> 1. Start using the ubuntu/* namespace on the Git repo on salsa for the
>Ubuntu packaging. I've already imported your work up to
>2.11.0-2ubuntu19 there.
Done! Thanks for giving us such a headstart on getting this set up.
>I did not import anything from your
>*-{security,updates} suites but DEP-14 should make it pretty easy
>to have dedicated branches for those. I'm happy to provide guidance
>if needed.
I'm not sure that we'll find importing *-{security,updates} to be very
useful. We'll probably just stick with ubuntu/master for now.
> 2. Merge the latest debian/2.12-* tag into ubuntu/master so you get
>2.12 and the many packaging improvements you folks have reviewed
>and that are in Debian already (otherwise the delta will remain so
>big we can't proceed with the big next step easily).
Done! I've pushed the resulting merge to ubuntu/master. What's there
right now is fully QA'ed and, IMO, ready to be uploaded to Bionic after
finalizing the changelog and tagging the release.
> 3. Give me the go ahead and then I'll:
>
>- refresh the {debian,ubuntu}/gbp-pq branches
>- merge the {debian,ubuntu}/gbp-pq branches respectively into
> {debian,ubuntu}/master
>- push {debian,ubuntu}/master
>- release & upload to Debian sid
>- ask you to release & upload to Ubuntu
I've taken a quick look at the gbp-pq branches and it sounds like Steve
did, as well. I see the value there so you've got the go ahead. :)
>
> It would be great if we could do that before 18.04 LTS is too deeply
> frozen so you can benefit, in the next 5 years, from all the goodness
> ubuntu/master..debian/master has accumulated since your last merge
> from Debian. If that timing is not an option, we could of course
> postpone this to post-18.04-release but then you'll have to deal with
> two vastly different debian/ directories between your LTS and ongoing
> development branches, which I expect might be quite painful and
> error-prone.
We are running late on getting this merge done. Let me know if you think
it'll be a bit before you can do all the steps you outlined in #3 above.
If that's the case, I should probably go ahead and upload what's in
ubuntu/master now and then do another small, incremental upload after
the gbp-pq changes are merged.
Thanks again for all your work on this!
Tyler
>
> And the following step of my secret evil plan is:
>
> 4. Check with Apertis what it would take to have them share our Git
>history (they're already using DEP-14 but with a different bzr→Git
>import that was done earlier) and possibly join the Salsa merge
>request fun so Debian and Ubuntu can benefit from the improvements
>Apertis made: a quick glance suggests that a few of their changes
>could be relevant for other distros :)
>
> Cheers,
>
signature.asc
Description: OpenPGP digital signature
Bug#877901: libseccomp: Test failures should cause the build to fail
Package: libseccomp Version: 2.3.1-2.1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu artful ubuntu-patch Dear Maintainer, While doing some work on libseccomp in Ubuntu, I noticed that the exit code of the `make check` target was being ignored despite the tests passing on all architectures we build on. I think we should make test failures be fatal for the build as the old issues that caused Debian bug 721292 seem to have been fixed. In Ubuntu, the attached patch was applied to achieve the following: * debian/rules: Make test failures cause the build to fail (LP: #1657425) To test the attached patch, I injected a fake test failure into tests/13-basic-attrs.py and verified that the subsequent build failed. Thanks for considering the patch. Tyler -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (400, 'xenial-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-96-generic (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru libseccomp-2.3.1/debian/rules libseccomp-2.3.1/debian/rules --- libseccomp-2.3.1/debian/rules 2016-11-17 17:23:10.0 + +++ libseccomp-2.3.1/debian/rules 2017-10-06 18:08:35.0 + @@ -29,9 +29,3 @@ "usr/lib/$(DEB_HOST_MULTIARCH)/libseccomp.so.*" \ lib/$(DEB_HOST_MULTIARCH) dh_install --remaining-packages --list-missing - -override_dh_auto_test: -ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) - make check 2>&1 | tee regression.out && \ - grep -q "^ tests failed: 0" regression.out || true -endif
Bug#840204: grub-pc: "GRUB! error: unknown filesystem" on ext4 with filesystem-level encryption
Eric Biggers has fixed this bug in the upstream GNU GRUB project: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=734668238fcc0ef691a080839e04f33854fa133a I prepared an upload to fix this issue in Ubuntu Artful and it required minor backporting of the test suite changes. Maybe you'll find the debdiff containing the backported patch useful: https://launchpadlibrarian.net/326938267/grub2_2.02~beta3-4ubuntu5_2.02~beta3-4ubuntu6.diff.gz Tyler signature.asc Description: OpenPGP digital signature
Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm
On 2015-07-29 15:36:42, Tyler Hicks wrote: > I've attached fixes for the master and 1.6 schroot branches. They fork > off a process that changes root to the chroot base path before calling > realpath(3) on the mount destination. > > Note that I'm still pretty confused by a part of the code in > resolve_path_chrooted() (which is mostly the old resolve_path()). I > don't understand the what is happening after the > "// Try validating the parent directory." comment but I left it since I > couldn't wrap my head around it. Any insight to what it is doing and > whether we can remove it now? Ping. I had another Ubuntu user hit this bug today. I'm wanting to push the fix before Ubuntu 16.04 is released but I'd prefer some feedback on the patch before then. Thanks! Tyler signature.asc Description: PGP signature
Bug#786566: schroot: Should mark bind mounts in the schroot as private
On 2015-08-12 21:08:33, Raphael Hertzog wrote:
> On Tue, 11 Aug 2015, Tyler Hicks wrote:
> > > Also recent mount allow you to specify mount options like "shared",
> > > "slave", "private" so we should respect this choice when
> > > the user has supplied them in the fstab... (or "rshared", "rprivate",
> > > "rslave").
> >
> > I made sure to preserve that functionality. Only the bind and rbind
> > mounts in the profile's fstab are being set to private. The mount
> > utility does not support having bind/rbind and a mount propagation mode
> > on the same line. If a user wants to set a custom mount propagation
> > mode, they'd have to do so with a new line in fstab. That's the case
> > with the mount utility and with my proposed patch to schroot.
>
> That's no longer the case. As I said, mount now accepts such options
> (even for bind mount), cf man mount:
>
> Since util-linux 2.23 the mount command allows to use several
> propagation flags together and also together with other mount
> operations. This feature is EXPERIMENTAL. The propagation flags are
> applied by additional mount(2) syscalls when the preceding mount
> operations were successful. Note that this use case is not atomic. It
> is possible to specify the propagation flags in fstab(5) as mount
> options (private, slave, shared, unbindable, rprivate, rslave,
> rshared, runbindable).
>
> I just tested this by changing one /etc/schroot/*/fstab to add a "slave"
> option on a bind mount and it worked as expected.
>
> Thus I believe that you should not call mount --make-private if one of
> those option is set in the fstab file.
Thanks. I've attached patches which do what you suggested.
Tyler
From b900010b54bee7a40f372fb3e88f32676354ba88 Mon Sep 17 00:00:00 2001
From: Tyler Hicks
Date: Tue, 27 Oct 2015 10:56:32 -0500
Subject: [PATCH] libexec-mount: Make bind mounts use private mount propagation
When creating a bind mount, on a Linux system, mark the target as
private. When creating a recursive bind mount, on a Linux system, mark
the target as recursively private.
This change fixes issues around shared mount points being bind mounted
into a schroot and then when the schroot session is tore down, the mount
point being unmounted in both the schroot and in the host environment.
For example, if the schroot fstab file contains the following line:
/home /home nonerw,rbind0 0
A user's home directory mounted at /home/$USER is unmounted in both the
schroot and host when the schroot sessions is ended without this change.
Signed-off-by: Tyler Hicks
---
libexec/mount/main.cc | 43 +++
libexec/mount/main.h | 10 ++
2 files changed, 53 insertions(+)
diff --git a/libexec/mount/main.cc b/libexec/mount/main.cc
index 9ea6e80..34c814b 100644
--- a/libexec/mount/main.cc
+++ b/libexec/mount/main.cc
@@ -21,6 +21,10 @@
#include
#include
+#if defined (__linux__)
+#include
+#endif
+
#include
#include
@@ -207,7 +211,46 @@ namespace bin
if (status)
exit(status);
}
+
+make_mount_private(entry.options, directory);
+}
+}
+
+void
+main::make_mount_private (const std::string& options,
+ const std::string& mountpoint)
+{
+#if defined (__linux__)
+ static schroot::regex bind("(^|,)(|r)bind(,|$)");
+ static schroot::regex propagation("(^|,)(|r)(shared|slave|private|unbindable)(,|$)");
+
+ if (regex_search(options, bind) && !regex_search(options, propagation))
+{
+ static schroot::regex rbind("(^|,)rbind(,|$)");
+ bool recursive = regex_search(options, rbind);
+
+ schroot::log_debug(schroot::DEBUG_INFO)
+ << boost::format("Making ‘%1%’ mount point %2%private")
+ % mountpoint
+ % (recursive ? "recursively " : "")
+ << std::endl;
+
+ if (!opts->dry_run)
+{
+ schroot::string_list command;
+ command.push_back("/bin/mount");
+ if (opts->verbose)
+command.push_back("-v");
+ command.push_back(recursive ? "--make-rprivate" : "--make-private");
+ command.push_back(mountpoint);
+
+ int status = run_child(command[0], command, schroot::environment());
+
+ if (status)
+exit(status);
+}
}
+#endif
}
int
diff --git a/libexec/mount/main.h b/libexec/mount/main.h
index c523bfe..a212b5a 100644
--- a/libexec/mount
Bug#797727: openssh should be built with audit support on Linux
Package: openssh Version: 1:6.9p1-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu wily ubuntu-patch Dear Maintainer, We've received a couple bugs in Ubuntu regarding the lack of support for Linux Audit login event support: https://launchpad.net/bugs/1319278 https://launchpad.net/bugs/1478087 The aulast and aureport tools do not work for sshd logins because openssh is not built with audit support. This means that AUDIT_USER_LOGIN events aren't logged by sshd so the Linux Audit tools do not find login information in the audit log. I've performed a test build of openssh, built with --with-audit=linux, and verified that AUDIT_USER_LOGIN events are correctly logged: type=USER_LOGIN msg=audit(1441160388.221:321): pid=5751 uid=0 auid=1000 ses=11 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.1.8.1 addr=10.1.8.1 terminal=/dev/pts/7 res=success' The aulast tool works as expected using the test openssh build: $ sudo aulast tyhicks pts/710.1.8.1 Tue Sep 1 21:19 still logged in I've attached a patch containing the simple changes needed to enable audit support on Linux. Thanks for considering the patch. -- System Information: Debian Release: jessie/sid APT prefers vivid-updates APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-26-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru openssh-6.9p1/debian/changelog openssh-6.9p1/debian/changelog diff -Nru openssh-6.9p1/debian/control openssh-6.9p1/debian/control --- openssh-6.9p1/debian/control 2015-08-20 04:34:45.0 -0500 +++ openssh-6.9p1/debian/control 2015-09-01 21:08:53.0 -0500 @@ -2,7 +2,7 @@ Section: net Priority: standard Maintainer: Debian OpenSSH Maintainers -Build-Depends: libwrap0-dev | libwrap-dev, zlib1g-dev (>= 1:1.2.3), libssl-dev (>= 0.9.8g), libpam0g-dev | libpam-dev, libgtk2.0-dev, libedit-dev, debhelper (>= 9~), dh-exec, libselinux1-dev [linux-any], libkrb5-dev | heimdal-dev, dpkg-dev (>= 1.16.1~), libck-connector-dev, dh-autoreconf, autotools-dev, dh-systemd (>= 1.4) +Build-Depends: libwrap0-dev | libwrap-dev, zlib1g-dev (>= 1:1.2.3), libssl-dev (>= 0.9.8g), libpam0g-dev | libpam-dev, libgtk2.0-dev, libedit-dev, debhelper (>= 9~), dh-exec, libselinux1-dev [linux-any], libkrb5-dev | heimdal-dev, dpkg-dev (>= 1.16.1~), libck-connector-dev, dh-autoreconf, autotools-dev, dh-systemd (>= 1.4), libaudit-dev XS-Testsuite: autopkgtest Standards-Version: 3.9.6 Uploaders: Colin Watson , Matthew Vernon diff -Nru openssh-6.9p1/debian/rules openssh-6.9p1/debian/rules --- openssh-6.9p1/debian/rules 2015-08-20 04:34:45.0 -0500 +++ openssh-6.9p1/debian/rules 2015-08-31 17:12:30.0 -0500 @@ -91,6 +91,7 @@ confflags += --with-ssl-engine ifeq ($(DEB_HOST_ARCH_OS),linux) confflags += --with-selinux +confflags += --with-audit=linux endif ifeq ($(DISTRIBUTOR),Ubuntu) confflags += --with-consolekit
Bug#786566: schroot: Should mark bind mounts in the schroot as private
On 2015-08-11 22:51:33, Raphael Hertzog wrote: > Hi, > > On Fri, 22 May 2015, Tyler Hicks wrote: > > That has worked pretty well for many filesystems that would be mounted > > at /home/$USER. However, I've recently had a lot of eCryptfs users > > reporting issues when using systemd as their init system since systemd > > uses shared mount propagation for mounts. > > Can you point me to some systemd documentation proving your assertion? http://www.freedesktop.org/software/systemd/man/systemd.exec.html Search for 'Defaults to shared'. > > I was not able to find the relevant documentation but you appear to be > right. On a wheezy system "/" is not marked as shared while on jessie > it is (you can see that in "cat /proc/self/mountinfo" in the 7th field > with the presence/absence of "shared:X"). > > Relevant documentation: > $ man proc > https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt > > But I don't understand why /home would also inherits from the shared > attribute by default... that said this appears to be the case for me here > too (not with /home in my specific case but another mount point). All mounts of my /etc/fstab file are being configured with shared propagation, not just '/'. > > > /home/$USER is unmounted in the host environment when schroot sessions > > are ended due to the unmount events being propagated outside of the > > schroot session's subdirectory. > > > > I believe that the best fix is to mark bind mount points, under the > > schroot session's subdirectory, as private. Also, rbind mount points > > will need to be marked as rprivate. > > Would it not be better to mark them as "slave" instead? That way > propagation from the host to the chroot works but not the other > way around? That's a possibility that I considered but I thought it would be best to simply restore the kernel's default mount propagation mode (private) to keep from surprising users. > Also recent mount allow you to specify mount options like "shared", > "slave", "private" so we should respect this choice when > the user has supplied them in the fstab... (or "rshared", "rprivate", > "rslave"). I made sure to preserve that functionality. Only the bind and rbind mounts in the profile's fstab are being set to private. The mount utility does not support having bind/rbind and a mount propagation mode on the same line. If a user wants to set a custom mount propagation mode, they'd have to do so with a new line in fstab. That's the case with the mount utility and with my proposed patch to schroot. > > Cheers, > > PS: Roger, Tyler forgot to CC you in his last reply, you might want to > check the bug report history. Thanks! Tyler signature.asc Description: Digital signature
Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm
Package: schroot
Followup-For: Bug #728096
Users have hit this issue in Ubuntu, too. I've triaged it and have
determined that Laurent is correct in Message #17 that the schroot mount
helper is using the host's filesystem to resolve symlinks in the chroot.
It is simply calling realpath(3) on the mount destination in the chroot,
from a process that is not chrooted, so realpath(3) is going to use the
host filesystem to resolve symlinks such as
'//dev/shm -> /run/shm'. It then tries to fixup the final
resolved path but appended the chroot basepath but it's too late at that
point, the host's filesystem has already been used to resolve the
symlink target.
We're actually getting filesystems mounted in the host filesystem in
Ubuntu (LP: #1438942) due to /run/shm existing in the host and pointing
back to /dev/shm.
Here's a simple test:
# Show that schroot's mount binary is using the host fs to resolve symlinks
$ mkdir -p /tmp/bug728096/dev
$ mkdir -p /tmp/bug728096/run/shm
$ ln -s /run/shm /tmp/bug728096/dev/shm
$ ls -ld /{dev,run}/shm
drwxrwxrwt 2 root root 120 Jul 29 14:07 /dev/shm
lrwxrwxrwx 1 root root 8 Jul 29 14:07 /run/shm -> /dev/shm
$ ls -ld /tmp/bug728096/{dev,run}/shm
lrwxrwxrwx 1 tyhicks tyhicks8 Jul 29 14:49 /tmp/bug728096/dev/shm ->
/run/shm
drwxrwxr-x 2 tyhicks tyhicks 4096 Jul 29 14:49 /tmp/bug728096/run/shm
$ echo "tmpfs /dev/shm/ tmpfs defaults 0 0" > /tmp/fstab
$ grep /dev/shm /proc/mounts
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
$ sudo ./libexec/mount/mount -v -f /tmp/fstab -m /tmp/bug728096
$ grep /dev/shm /proc/mounts
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
# Now reproduce Laurent's original bug report by removing the host's /run/shm
$ sudo umount /dev/shm
$ sudo rm /run/shm
$ sudo ./libexec/mount/mount -v -f /tmp/fstab -m /tmp/bug728096
E: boost::filesystem::create_directory: File exists: "/tmp/bug728096/dev/shm"
$ echo $?
1
I've attached fixes for the master and 1.6 schroot branches. They fork
off a process that changes root to the chroot base path before calling
realpath(3) on the mount destination.
Note that I'm still pretty confused by a part of the code in
resolve_path_chrooted() (which is mostly the old resolve_path()). I
don't understand the what is happening after the
"// Try validating the parent directory." comment but I left it since I
couldn't wrap my head around it. Any insight to what it is doing and
whether we can remove it now?
Tyler
From 86a39d878bc1b6ea59b4f354f03b635014b720a1 Mon Sep 17 00:00:00 2001
From: Tyler Hicks
Date: Tue, 28 Jul 2015 02:11:07 -0500
Subject: [PATCH] libexec-mount: Resolve mount destinations while chrooted
The mount binary was attempting to use realpath(3) from outside of the
chroot to resolve mount destination paths inside of the chroot. It would
then take the resolved path and prepend it with the path to the chroot
in an attempt to enforce that symlink resolution will always end up
inside of the chroot.
One example of why this approach isn't sufficient is that when
//dev/shm/ is the mount destination but it is a symlink to
/run/shm and the host's /run/shm is a symlink to /dev/shm. The resolved
path will end up being //dev/shm/ and, due to mount following
symlinks, the host's /dev/shm will be mounted over.
To fix the path resolution issue, this patch first resolves the path to
the chroot base path, then forks and calls chroot(2) on that path, then
resolves the path to the mount destination inside the chroot. Finally,
the resolved chroot base path and the resolved mount destination path
are combined to create the fully resolved path used for mounting.
Bug-Debian: https://bugs.debian.org/728096
Bug-Ubuntu: https://launchpad.net/bugs/1438942
Signed-off-by: Tyler Hicks
---
libexec/mount/main.cc | 141 ++
libexec/mount/main.h | 28 --
2 files changed, 141 insertions(+), 28 deletions(-)
diff --git a/libexec/mount/main.cc b/libexec/mount/main.cc
index 9ea6e80..bbf4a18 100644
--- a/libexec/mount/main.cc
+++ b/libexec/mount/main.cc
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -53,8 +54,14 @@ namespace schroot
{
{bin::schroot_mount::main::CHILD_FORK, N_("Failed to fork child")},
{bin::schroot_mount::main::CHILD_WAIT, N_("Wait for child failed")},
+// TRANSLATORS: %1% = directory
+{bin::schroot_mount::main::CHROOT, N_("Failed to change root to directory ‘%1%’")},
+{bin::schroot_mount::main::DUP,N_("Failed to duplicate file descriptor")},
// TRANSLATORS: %1% = command name
{bin::schroot_mount::main::EXEC, N_("Failed to execute “%1%”")},
+{bin::schroot_mount::main::PIPE, N
Bug#786566: [buildd-tools-devel] Bug#786566: schroot: Should mark bind mounts in the schroot as private
On 2015-07-15 19:19:23, Roger Leigh wrote: > On 15/07/2015 17:47, Tyler Hicks wrote: > >Hello - I'm sending a friendly poke in hopes that I can get a review for > >my proposed patch. The unpatched behavior is a considerable usability > >issue on systems that use systemd, schroot, and a filesystem mounted at > >/home/$USER. I'd prefer upstream review before I apply the patch to > >schroot in Ubuntu. Thanks! > > It looks reasonable for you to apply in Ubuntu, but I'm not yet sure if it's > safe to apply upstream. It might well be safe for Debian as well, but I > can't make that determination myself. Thank you for the review! > Is this safe to use on systems not using systemd? It should be safe on those systems. The mounts that are being bound into the chroot will most likely already be using private mount propagation since that is the default mount propagation mode. > Does it require a specific version of util-linux for the --make-[r]private > options to mount? If so, it probably needs a proper functional check for > them, and using those as conditionals rather than just __linux__. Good question. Support for --make-[r]private has been around since the following commit: https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=389fbea536e4308d9475fa2a89e53e188ce8a0e3 It was first released in util-linux 2.13, which happened on 28-Aug-2007: https://www.kernel.org/pub/linux/utils/util-linux/v2.13/v2.13-ReleaseNotes I don't think we need a functional check for something that has been around for so long. Tyler signature.asc Description: Digital signature
Bug#786566: schroot: Should mark bind mounts in the schroot as private
Hello - I'm sending a friendly poke in hopes that I can get a review for my proposed patch. The unpatched behavior is a considerable usability issue on systems that use systemd, schroot, and a filesystem mounted at /home/$USER. I'd prefer upstream review before I apply the patch to schroot in Ubuntu. Thanks! Tyler signature.asc Description: Digital signature
Bug#786566: schroot: Should mark bind mounts in the schroot as private
Package: schroot
Version: 1.7.2-2
Severity: important
Tags: upstream patch
Dear Maintainer,
Schroot users that have /home/$USER as a separate mount point usually
update the various schroot profiles' fstab to include:
/home /home nonerw,rbind0 0
That has worked pretty well for many filesystems that would be mounted
at /home/$USER. However, I've recently had a lot of eCryptfs users
reporting issues when using systemd as their init system since systemd
uses shared mount propagation for mounts. The biggest issue is that
/home/$USER is unmounted in the host environment when schroot sessions
are ended due to the unmount events being propagated outside of the
schroot session's subdirectory.
I believe that the best fix is to mark bind mount points, under the
schroot session's subdirectory, as private. Also, rbind mount points
will need to be marked as rprivate.
I'll attach a patch developed against schroot's master git branch (which
should apply to 1.7.2-2) and another developed against the schroot-1.6
branch.
Tyler
-- System Information:
Debian Release: jessie/sid
APT prefers vivid-updates
APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.19.0-16-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
From db5cbc9dd57fc3a13f3f1fb405aa2cc1d2d6d7d0 Mon Sep 17 00:00:00 2001
From: Tyler Hicks
Date: Fri, 22 May 2015 12:27:40 -0500
Subject: [PATCH] libexec-mount: Make bind mounts use private mount propagation
When creating a bind mount, on a Linux system, mark the target as
private. When creating a recursive bind mount, on a Linux system, mark
the target as recursively private.
This change fixes issues around shared mount points being bind mounted
into a schroot and then when the schroot session is tore down, the mount
point being unmounted in both the schroot and in the host environment.
For example, if the schroot fstab file contains the following line:
/home /home nonerw,rbind0 0
A user's home directory mounted at /home/$USER is unmounted in both the
schroot and host when the schroot sessions is ended without this change.
Signed-off-by: Tyler Hicks
---
libexec/mount/main.cc | 42 ++
libexec/mount/main.h | 10 ++
2 files changed, 52 insertions(+)
diff --git a/libexec/mount/main.cc b/libexec/mount/main.cc
index 9ea6e80..80b0236 100644
--- a/libexec/mount/main.cc
+++ b/libexec/mount/main.cc
@@ -21,6 +21,10 @@
#include
#include
+#if defined (__linux__)
+#include
+#endif
+
#include
#include
@@ -207,7 +211,45 @@ namespace bin
if (status)
exit(status);
}
+
+make_mount_private(entry.options, directory);
+}
+}
+
+void
+main::make_mount_private (const std::string& options,
+ const std::string& mountpoint)
+{
+#if defined (__linux__)
+ static schroot::regex bind("(^|,)(|r)bind(,|$)");
+
+ if (regex_search(options, bind))
+{
+ static schroot::regex rbind("(^|,)rbind(,|$)");
+ bool recursive = regex_search(options, rbind);
+
+ schroot::log_debug(schroot::DEBUG_INFO)
+ << boost::format("Making ‘%1%’ mount point %2%private")
+ % mountpoint
+ % (recursive ? "recursively " : "")
+ << std::endl;
+
+ if (!opts->dry_run)
+{
+ schroot::string_list command;
+ command.push_back("/bin/mount");
+ if (opts->verbose)
+command.push_back("-v");
+ command.push_back(recursive ? "--make-rprivate" : "--make-private");
+ command.push_back(mountpoint);
+
+ int status = run_child(command[0], command, schroot::environment());
+
+ if (status)
+exit(status);
+}
}
+#endif
}
int
diff --git a/libexec/mount/main.h b/libexec/mount/main.h
index c523bfe..a212b5a 100644
--- a/libexec/mount/main.h
+++ b/libexec/mount/main.h
@@ -70,6 +70,16 @@ namespace bin
action_mount ();
/**
+ * Make a bind mount use private mount propagation (Linux-specific).
+ *
+ * @param options the mount options
+ * @param mountpoint the mountpiont to make private
+ */
+ void
+ make_mount_private (const std::string& options,
+ const std::string& mountpoint);
+
+ /**
* Run the command specified by file (an absolute pathname), using
* command and env as the argv and environment
Bug#729704: audit: Init script should depend on $remote_fs for awk
Package: audit Version: 1:2.3.2-2 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu trusty ubuntu-patch Dear Maintainer, While merging the Debian package into Ubuntu, I was looking into the new augenrules feature. I noticed that it didn't work when USE_AUGENRULES was set to "yes" because the init script's PATH does not include /usr/bin/ but augenrules calls /usr/bin/awk. In Ubuntu, the attached patch was applied to achieve the following: * debian/auditd.init: The start command now requires $remote_fs to be started because it may call /bin/augenrules, which depends on /usr/bin/awk. $PATH must also be updated so that augenrules can find awk. Thanks for considering the patch. -- System Information: Debian Release: wheezy/sid APT prefers saucy-updates APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0-12-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru audit-2.3.2/debian/auditd.init audit-2.3.2/debian/auditd.init --- audit-2.3.2/debian/auditd.init 2013-08-29 01:38:31.0 -0700 +++ audit-2.3.2/debian/auditd.init 2013-11-15 13:52:14.0 -0800 @@ -1,7 +1,7 @@ #! /bin/sh ### BEGIN INIT INFO # Provides: auditd -# Required-Start:$local_fs +# Required-Start:$remote_fs # Required-Stop: $local_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 @@ -12,8 +12,7 @@ # Author: Philipp Matthias Hahn # Based on Debians /etc/init.d/skeleton and Auditds init.d/auditd.init -# PATH should only include /usr/* if it runs after the mountnfs.sh script -PATH=/sbin:/bin +PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="audit daemon" NAME=auditd DAEMON=/sbin/auditd
Bug#701144: ruby1.9.1: CVE-2012-4464 CVE-2012-4466
Package: ruby1.9.1 Version: 1.9.3.194-7 Severity: minor Dear Maintainer, The ruby1.9.1 package contains a fix for CVE-2011-1005 (20120927-cve_2011_1005.patch). I submitted that fix to upstream and Debian[1] when I discovered that Ruby 1.9.x failed a regression test for CVE-2011-1005, despite the original Ruby security advisory[2] stating that 1.9.x was not affected. After some discussion on the oss-security list, it turns out that Ruby 1.9.x was assigned[3] new CVE identifiers for this issue because of CVE assignment semantics. The issues in Ruby 1.9.x are assigned CVE-2012-4464 and CVE-2012-4466, *not* CVE-2011-1005. 20120927-cve_2011_1005.patch is complete and addresses all of the issues, it just happens to be named incorrectly. The "fix" for this bug is to simply rename the patch to avoid further confusion. There is also a revision[4] in the upstream 1.9.3 branch if you'd like to verify for yourself. Sorry for any confusion! Tyler [1] http://bugs.debian.org/689075 [2] http://www.ruby-lang.org/en/news/2011/02/18/exception-methods-can-bypass-safe/ [3] http://www.openwall.com/lists/oss-security/2012/10/03/9 [4] http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=37162 -- System Information: Debian Release: wheezy/sid APT prefers raring-updates APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.0-6-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ruby1.9.1 depends on: ii libc6 2.17-0ubuntu4 pn libruby1.9.1 ruby1.9.1 recommends no packages. Versions of packages ruby1.9.1 suggests: pn graphviz pn ri1.9.1 pn ruby-switch pn ruby1.9.1-dev pn ruby1.9.1-examples -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701142: ruby1.9.1: CVE-2012-4522.patch causes a build test error
Package: ruby1.9.1
Version: 1.9.3.194-7
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu raring ubuntu-patch
Dear Maintainer,
While merging 1.9.3.194-7 into Ubuntu Raring, I noticed a new error in
one of the build tests. test_open_nul throws a NoMethodError for
assert_file_not, which doesn't exist in 1.9.3. The upstream 1.9.3 tree
has a slightly different version of the test that works properly.
In Ubuntu, the attached patch was applied to achieve the following:
* debian/patches/CVE-2012-4522.patch: Adjust patch to fix build test error.
Use the version of the fix from upstream's 1.9.3 tree to fix the
NoMethodError for assert_file_not, which doesn't exist in 1.9.3. Adjust
the Origin patch tag accordingly.
Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers raring-updates
APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.8.0-6-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/CVE-2012-4522.patch ruby1.9.1-1.9.3.194/debian/patches/CVE-2012-4522.patch
--- ruby1.9.1-1.9.3.194/debian/patches/CVE-2012-4522.patch 2013-02-13 02:20:34.0 -0800
+++ ruby1.9.1-1.9.3.194/debian/patches/CVE-2012-4522.patch 2013-02-21 10:26:30.0 -0800
@@ -2,7 +2,7 @@
This is a fix for CVE-2012-4522.
Author: Nobuyoshi Nakada
Bug-Debian: http://bugs.debian.org/690670
-Origin: upstream, https://github.com/ruby/ruby/commit/7085db45e4f15a58f9a82c8815bcc31364e0fde1
+Origin: upstream, http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=37164
Reviewed-By: Antonio Terceiro
--- ruby1.9.1-1.9.3.194.orig/file.c
@@ -30,7 +30,7 @@
+ assert_raise(ArgumentError) do
+open(path + "\0bar", "w") {}
+ end
-+ assert_file_not(:exist?, path)
++ refute File.exist?(path)
+end
+ end
end
Bug#699933: audit: external libev-dev Build-Dependency is not used
Package: audit Version: 1:2.2.2-1ubuntu2 Severity: minor Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring ubuntu-patch Dear Maintainer, The upstream audit source embeds its own version of libev and the project's build system uses the embedded version rather than using an externally available libev. Therefore, a Build-Dependency on libev-dev is unnecessary. I have not had a chance to investigate why audit embeds its own libev or if audit can build against the system's libev. In Ubuntu, the attached patch was applied to achieve the following: * Remove libev-dev Build-Dependency - debian/control: The upstream audit sources embed and build against their own version of libev. This is not desirable, but there's no reason to list libev-dev as a build dependency at this time. Thanks for considering the patch. -- System Information: Debian Release: wheezy/sid APT prefers quantal-updates APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.0-23-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru audit-2.2.2/debian/changelog audit-2.2.2/debian/changelog diff -Nru audit-2.2.2/debian/control audit-2.2.2/debian/control --- audit-2.2.2/debian/control 2012-12-12 12:43:40.0 -0800 +++ audit-2.2.2/debian/control 2013-02-06 15:51:33.0 -0800 @@ -6,7 +6,6 @@ dpkg-dev (>= 1.16.1~), intltool, libcap-ng-dev, - libev-dev, libkrb5-dev, libldap2-dev, libprelude-dev,
Bug#690071: ecryptfs: corrupted files on a disk full event
On 2012-10-10 15:04:10, Sebastian Heinlein wrote: > Applying all 5 patches fixed all issues for me. Good to hear! > I see a lot of errors in dmesg, but these seem to be related to the full > disk write operation: This is just eCryptfs being too chatty in error situations. This is expected at the moment, but it is something that needs to be fixed in the future. Tyler signature.asc Description: Digital signature
Bug#689075: CVE-2011-1005: safe level bypass
On 2012-10-01 11:04:30, Tyler Hicks wrote: > I'll be sure to update this bug when they've applied the fix upstream. Ok, the fix is public: http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=37068 It ended up being more complicated than I initially thought. The vulnerability described in CVE-2011-1005 was reintroduced into the Ruby codebase in 1.9.3-p0. When upstream was developing their fix they found a new, but similar, issue that goes back to ruby1.8. My request for new CVE ids and a slightly more detailed explanation can be found here: http://www.openwall.com/lists/oss-security/2012/10/02/4 Tyler signature.asc Description: Digital signature
Bug#689075: CVE-2011-1005: safe level bypass
On 2012-09-30 17:47:30, Antonio Terceiro wrote: > Thanks for submitting this. Did you notify upstream of the fact that the > 1.9 series is actually affected by this issue? Yes, right after I filed this bug. After speaking with upstream, they will be applying a slightly different fix. You probably want to wait until their fix is public. I'll be sure to update this bug when they've applied the fix upstream. signature.asc Description: Digital signature
Bug#689075: CVE-2011-1005: safe level bypass
Package: ruby1.9.1
Version: 1.9.3.194-1
Severity: grave
Tags: patch security
Justification: user security hole
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch
Dear Maintainer,
While running some regression tests I discovered that 1.9.3.194-1 is
vulnerable to CVE-2011-1005, despite the Ruby advisory stating
otherwise:
http://www.ruby-lang.org/en/news/2011/02/18/exception-methods-can-bypass-safe/
You can use the reproducer in the advisory for verification. Just do a
'puts $secret_path' rather than the 'open($secret_path)' block.
In Ubuntu, the attached patch was applied to achieve the following:
* SECURITY UPDATE: Safe level bypass
- debian/patches/20120927-cve_2011_1005.patch: Remove incorrect string
taint in exception handling methods. Based on upstream patch.
- CVE-2011-1005
Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-15-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru ruby1.9.1-1.9.3.194/debian/changelog ruby1.9.1-1.9.3.194/debian/changelog
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/20120927-cve_2011_1005.patch ruby1.9.1-1.9.3.194/debian/patches/20120927-cve_2011_1005.patch
--- ruby1.9.1-1.9.3.194/debian/patches/20120927-cve_2011_1005.patch 1969-12-31 16:00:00.0 -0800
+++ ruby1.9.1-1.9.3.194/debian/patches/20120927-cve_2011_1005.patch 2012-09-28 00:09:06.0 -0700
@@ -0,0 +1,60 @@
+Description: Prevent untainted strings from being incorrectly tainted
+ This flaw allowed untainted strings to be tainted and modified, even in
+ safe level 4.
+Origin: backport, http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?revision=30903&view=revision
+Index: ruby1.9.1-1.9.3.194/error.c
+===
+--- ruby1.9.1-1.9.3.194.orig/error.c 2012-02-25 04:32:19.0 -0800
ruby1.9.1-1.9.3.194/error.c 2012-09-26 10:10:15.164576749 -0700
+@@ -569,7 +569,6 @@
+
+ if (NIL_P(mesg)) return rb_class_name(CLASS_OF(exc));
+ r = rb_String(mesg);
+-OBJ_INFECT(r, exc);
+ return r;
+ }
+
+@@ -854,10 +853,9 @@
+ if (NIL_P(mesg)) return rb_class_name(CLASS_OF(exc));
+ StringValue(str);
+ if (str != mesg) {
+- rb_iv_set(exc, "mesg", mesg = str);
++ OBJ_INFECT(str, mesg);
+ }
+-OBJ_INFECT(mesg, exc);
+-return mesg;
++return str;
+ }
+
+ /*
+Index: ruby1.9.1-1.9.3.194/test/ruby/test_exception.rb
+===
+--- ruby1.9.1-1.9.3.194.orig/test/ruby/test_exception.rb 2012-02-07 16:44:05.0 -0800
ruby1.9.1-1.9.3.194/test/ruby/test_exception.rb 2012-09-26 10:10:15.164576749 -0700
+@@ -333,4 +333,26 @@
+ load(t.path)
+ end
+ end
++
++ def test_to_s_taintness_propagation
++for exc in [Exception, NameError]
++ m = "abcdefg"
++ e = exc.new(m)
++ e.taint
++ s = e.to_s
++ assert_equal(false, m.tainted?,
++ "#{exc}#to_s should not propagate taintness")
++ assert_equal(false, s.tainted?,
++ "#{exc}#to_s should not propagate taintness")
++end
++
++o = Object.new
++def o.to_str
++ "foo"
++end
++o.taint
++e = NameError.new(o)
++s = e.to_s
++assert_equal(true, s.tainted?)
++ end
+ end
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/series ruby1.9.1-1.9.3.194/debian/patches/series
--- ruby1.9.1-1.9.3.194/debian/patches/series 2012-05-27 15:46:34.0 -0700
+++ ruby1.9.1-1.9.3.194/debian/patches/series 2012-09-28 00:32:14.0 -0700
@@ -16,3 +16,4 @@
110829-hurd_dirent_usage.patch
hurd-path-max.diff
20120517-r35434.patch
+20120927-cve_2011_1005.patch
Bug#689074: ruby1.9.1: RubyGems should use ca-certificates for SSL verification
Package: ruby1.9.1
Version: 1.9.3.194-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch
Dear Maintainer,
While I was preparing an Ubuntu ruby1.9.1 update for CVE-2012-2126, I
noticed that ruby1.9.1-1.9.3.194-1 included its own trusted CA
certificate bundle, rather than using the bundle from ca-certificates,
to do server certificate verification in the gem fetcher.
In Ubuntu, the attached patch was applied to achieve the following:
* Make the RubyGems fetcher use distro-provided ca-certificates
(LP: #1057926)
- debian/control: Add ca-certificates to libruby1.9.1 depends so that
rubygems can perform certificate verification
- debian/rules: Don't install SSL certificates from upstream sources
- debian/patches/20120927-rubygems_disable_upstream_certs.patch: Use
/etc/ssl/certs/ca-certificates.crt for the trusted CA certificates.
Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-15-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru ruby1.9.1-1.9.3.194/debian/changelog ruby1.9.1-1.9.3.194/debian/changelog
diff -Nru ruby1.9.1-1.9.3.194/debian/control ruby1.9.1-1.9.3.194/debian/control
--- ruby1.9.1-1.9.3.194/debian/control 2012-05-27 15:47:25.0 -0700
+++ ruby1.9.1-1.9.3.194/debian/control 2012-09-28 14:29:00.0 -0700
@@ -29,7 +29,7 @@
Package: libruby1.9.1
Section: libs
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ca-certificates, ${shlibs:Depends}, ${misc:Depends}
Conflicts: libdbm-ruby1.9.1, libgdbm-ruby1.9.1, libreadline-ruby1.9.1, libopenssl-ruby1.9.1, irb1.8 (<< 1.9.1.378-2~), rdoc1.8 (<< 1.9.1.378-2~)
Replaces: libdbm-ruby1.9.1, libgdbm-ruby1.9.1, libreadline-ruby1.9.1, libopenssl-ruby1.9.1, irb1.8, rdoc1.8
Provides: libdbm-ruby1.9.1, libgdbm-ruby1.9.1, libreadline-ruby1.9.1, libopenssl-ruby1.9.1
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/20120927-rubygems_disable_upstream_certs.patch ruby1.9.1-1.9.3.194/debian/patches/20120927-rubygems_disable_upstream_certs.patch
--- ruby1.9.1-1.9.3.194/debian/patches/20120927-rubygems_disable_upstream_certs.patch 1969-12-31 16:00:00.0 -0800
+++ ruby1.9.1-1.9.3.194/debian/patches/20120927-rubygems_disable_upstream_certs.patch 2012-09-28 00:09:07.0 -0700
@@ -0,0 +1,30 @@
+Description: Use the certificates maintained by the distro
+ Rather than using the certificates packaged in the upstream sources to verify
+ server SSL certificates, use the certificates provided by the ca-certificates
+ package.
+Author: Tyler Hicks
+Forwarded: not-needed
+Index: ruby1.9.1-1.9.3.194/lib/rubygems/remote_fetcher.rb
+===
+--- ruby1.9.1-1.9.3.194.orig/lib/rubygems/remote_fetcher.rb 2012-09-27 10:48:23.046684546 -0700
ruby1.9.1-1.9.3.194/lib/rubygems/remote_fetcher.rb 2012-09-27 10:48:42.590685014 -0700
+@@ -8,7 +8,7 @@
+
+ class Gem::RemoteFetcher
+
+- BuiltinSSLCerts = File.expand_path("./ssl_certs/*.pem", File.dirname(__FILE__))
++ BuiltinSSLCerts = "/etc/ssl/certs/ca-certificates.crt"
+
+ include Gem::UserInteraction
+
+@@ -354,8 +354,8 @@
+ end
+
+ def add_rubygems_trusted_certs(store)
+-Dir.glob(BuiltinSSLCerts).each do |ssl_cert_file|
+- store.add_file ssl_cert_file
++if File.file? BuiltinSSLCerts
++ store.add_file BuiltinSSLCerts
+ end
+ end
+
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/series ruby1.9.1-1.9.3.194/debian/patches/series
--- ruby1.9.1-1.9.3.194/debian/patches/series 2012-05-27 15:46:34.0 -0700
+++ ruby1.9.1-1.9.3.194/debian/patches/series 2012-09-28 00:32:14.0 -0700
@@ -16,3 +16,5 @@
110829-hurd_dirent_usage.patch
hurd-path-max.diff
20120517-r35434.patch
+20120927-rubygems_disable_upstream_certs.patch
diff -Nru ruby1.9.1-1.9.3.194/debian/rules ruby1.9.1-1.9.3.194/debian/rules
--- ruby1.9.1-1.9.3.194/debian/rules 2012-06-02 03:35:36.0 -0700
+++ ruby1.9.1-1.9.3.194/debian/rules 2012-09-28 00:09:07.0 -0700
@@ -170,7 +170,8 @@
for f in libruby-$(ruby_ver).so.$(ruby_ver) libruby-$(ruby_ver).so.$(ruby_ver_major); do \
echo usr/lib/$$f; \
done) | xargs dh_movefiles -p$(cdbs_curpkg)
- dh_movefiles -p$(cdbs_curpkg) $(ruby_libdir)
+ # Do not install the SSL certs bundled in the upstream source
+ dh_movefiles -p$(cdbs_curpkg) -Xssl_certs $(ruby_libdir)
cd $(DEB_SRCDIR)/ext && \
for dir in \
Bug#689069: rubygems: RubyGems should use ca-certificates for SSL verification
Package: rubygems
Version: 1.8.24-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch
Dear Maintainer,
While I was preparing an Ubuntu rubygems update for CVE-2012-2126, I
noticed that rubygems-1.8.24-1 included its own trusted CA certificate
bundle, rather than using the bundle from ca-certificates, to do server
certificate verification in the gem fetcher.
In Ubuntu, the attached patch was applied to achieve the following:
* Make the RubyGems fetcher use distro-provided ca-certificates
(LP: #1057926)
- debian/control: Add ca-certificates to rubygems depends so that
rubygems can perform certificate verification
- debian/rules: Don't install SSL certificates from upstream sources
- debian/patches/20120927-disable_upstream_certs.patch: Use
/etc/ssl/certs/ca-certificates.crt for the trusted CA certificates.
Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-15-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru rubygems-1.8.24/debian/changelog rubygems-1.8.24/debian/changelog
diff -Nru rubygems-1.8.24/debian/control rubygems-1.8.24/debian/control
--- rubygems-1.8.24/debian/control 2012-06-09 06:44:27.0 -0700
+++ rubygems-1.8.24/debian/control 2012-09-28 14:18:32.0 -0700
@@ -14,7 +14,7 @@
Package: rubygems
Architecture: all
XB-Ruby-Versions: ${ruby:Versions}
-Depends: ${misc:Depends}, ruby1.8
+Depends: ca-certificates, ${misc:Depends}, ruby1.8
Recommends: ruby1.8-dev, build-essential
Replaces: rubygems1.8 (<< 1.7.2-1~), rubygems-doc (<< 1.7.2-1~)
Conflicts: rubygems1.8 (<< 1.7.2-1~), rubygems-doc (<< 1.7.2-1~)
diff -Nru rubygems-1.8.24/debian/patches/20120927-disable_upstream_certs.patch rubygems-1.8.24/debian/patches/20120927-disable_upstream_certs.patch
--- rubygems-1.8.24/debian/patches/20120927-disable_upstream_certs.patch 1969-12-31 16:00:00.0 -0800
+++ rubygems-1.8.24/debian/patches/20120927-disable_upstream_certs.patch 2012-09-27 12:12:57.0 -0700
@@ -0,0 +1,30 @@
+Description: Use the certificates maintained by the distro
+ Rather than using the certificates packaged in the upstream sources to verify
+ server SSL certificates, use the certificates provided by the ca-certificates
+ package.
+Author: Tyler Hicks
+Forwarded: not-needed
+Index: rubygems-1.8.24/lib/rubygems/remote_fetcher.rb
+===
+--- rubygems-1.8.24.orig/lib/rubygems/remote_fetcher.rb 2012-04-27 16:15:17.0 -0700
rubygems-1.8.24/lib/rubygems/remote_fetcher.rb 2012-09-27 12:12:53.970805064 -0700
+@@ -8,7 +8,7 @@
+
+ class Gem::RemoteFetcher
+
+- BuiltinSSLCerts = File.expand_path("./ssl_certs/*.pem", File.dirname(__FILE__))
++ BuiltinSSLCerts = "/etc/ssl/certs/ca-certificates.crt"
+
+ include Gem::UserInteraction
+
+@@ -365,8 +365,8 @@
+ end
+
+ def add_rubygems_trusted_certs(store)
+-Dir.glob(BuiltinSSLCerts).each do |ssl_cert_file|
+- store.add_file ssl_cert_file
++if File.file? BuiltinSSLCerts
++ store.add_file BuiltinSSLCerts
+ end
+ end
+
diff -Nru rubygems-1.8.24/debian/patches/series rubygems-1.8.24/debian/patches/series
--- rubygems-1.8.24/debian/patches/series 2012-06-09 06:44:27.0 -0700
+++ rubygems-1.8.24/debian/patches/series 2012-09-27 12:23:22.0 -0700
@@ -5,3 +5,4 @@
fix-shebang.diff
20120608-fix-test_gem_platform.rb.diff
20120608-fix-assert_match.diff
+20120927-disable_upstream_certs.patch
diff -Nru rubygems-1.8.24/debian/rules rubygems-1.8.24/debian/rules
--- rubygems-1.8.24/debian/rules 2012-06-09 06:44:27.0 -0700
+++ rubygems-1.8.24/debian/rules 2012-09-27 20:37:45.0 -0700
@@ -25,6 +25,8 @@
override_dh_auto_install:
dh_auto_install
+ # Do not install the SSL certs bundled in the upstream source
+ rm -rf debian/rubygems/usr/lib/ruby/vendor_ruby/rubygems/ssl_certs
mv debian/rubygems/usr/bin/gem debian/rubygems/usr/bin/gem1.8
rm debian/rubygems/usr/bin/update_rubygems # not needed
# we don't want to share rubygems with 1.9.
Bug#687672: xmlrpc-c: Embedded Expat vulnerable to CVE-2012-0876, CVE-2012-1148
Package: xmlrpc-c
Version: 1.06.27-1
Followup-For: Bug #687672
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch
I've also backported the same changes to 1.06.27-1 for our Lucid
xmlrpc-c package. It looks to apply cleanly to the Squeeze package.
Here's the changelog:
* Run the tests as part of the build process
- debian/patches/FTBFS-tests.patch: Fix issues when running make check.
Based on upstream patches.
- debian/rules: Run make check after building
* SECURITY UPDATE: Denial of service via hash collisions
- debian/patches/CVE-2012-0876.patch: Add random salt value to
hash inputs. Based on upstream patch.
- CVE-2012-0876
* SECURITY UPDATE: Denial of service via memory leak
- debian/patches/CVE-2012-1148.patch: Properly reallocate memory.
Based on upstream patch.
- CVE-2012-1148
I hope it is of some help.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-14-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u xmlrpc-c-1.06.27/debian/changelog xmlrpc-c-1.06.27/debian/changelog
diff -u xmlrpc-c-1.06.27/debian/rules xmlrpc-c-1.06.27/debian/rules
--- xmlrpc-c-1.06.27/debian/rules
+++ xmlrpc-c-1.06.27/debian/rules
@@ -55,6 +55,7 @@
build-arch-stamp: config.status
dh_testdir
$(MAKE) CADD=-fPIC
+ $(MAKE) CADD=-fPIC check
touch build-arch-stamp
build-indep: build-indep-stamp
diff -u xmlrpc-c-1.06.27/debian/patches/series xmlrpc-c-1.06.27/debian/patches/series
--- xmlrpc-c-1.06.27/debian/patches/series
+++ xmlrpc-c-1.06.27/debian/patches/series
@@ -5,0 +6,3 @@
+FTBFS-tests.patch
+CVE-2012-0876.patch
+CVE-2012-1148.patch
only in patch2:
unchanged:
--- xmlrpc-c-1.06.27.orig/debian/patches/CVE-2012-0876.patch
+++ xmlrpc-c-1.06.27/debian/patches/CVE-2012-0876.patch
@@ -0,0 +1,556 @@
+Description: Prevent predictable hash collisions by using a random salt value
+ Backported from the upstream Expat sources to the embedded copy of Expat in
+ xmlrpc-c.
+Origin: backport, http://xmlrpc-c.svn.sourceforge.net/viewvc/xmlrpc-c?view=revision&revision=2391
+Index: xmlrpc-c-1.06.27/lib/expat/xmlparse/xmlparse.c
+===
+--- xmlrpc-c-1.06.27.orig/lib/expat/xmlparse/xmlparse.c 2012-09-06 14:54:24.144075962 -0700
xmlrpc-c-1.06.27/lib/expat/xmlparse/xmlparse.c 2012-09-06 14:54:26.416075915 -0700
+@@ -16,6 +16,8 @@
+ */
+
+ #include
++#include /* UINT_MAX */
++#include/* time() */
+
+ #include "xmlrpc_config.h"
+ #include "c_util.h"
+@@ -40,6 +42,8 @@
+ typedef char ICHAR;
+ #endif
+
++static
++int setContext(XML_Parser parser, const XML_Char *context);
+
+ #ifndef XML_NS
+
+@@ -256,12 +260,15 @@
+ static void normalizePublicId(XML_Char *s);
+ static int dtdInit(DTD *);
+ static void dtdDestroy(DTD *);
+-static int dtdCopy(DTD *newDtd, const DTD *oldDtd);
+-static int copyEntityTable(HASH_TABLE *, STRING_POOL *, const HASH_TABLE *);
++static int dtdCopy(XML_Parser oldParser, DTD *newDtd, const DTD *oldDtd);
++static int copyEntityTable(XML_Parser, HASH_TABLE *, STRING_POOL *,
++ const HASH_TABLE *);
+ #ifdef XML_DTD
+ static void dtdSwap(DTD *, DTD *);
+ #endif /* XML_DTD */
+-static NAMED *lookup(HASH_TABLE *table, KEY name, size_t createSize);
++static NAMED *lookup(XML_Parser parser, HASH_TABLE *table, KEY name,
++ size_t createSize);
++static int startParsing(XML_Parser parser);
+ static void hashTableInit(HASH_TABLE *);
+ static void hashTableDestroy(HASH_TABLE *);
+ static void hashTableIterInit(HASH_TABLE_ITER *, const HASH_TABLE *);
+@@ -370,6 +377,7 @@
+ enum XML_ParamEntityParsing m_paramEntityParsing;
+ XML_Parser m_parentParser;
+ #endif
++ unsigned long m_hash_secret_salt;
+ } Parser;
+
+ #define userData (((Parser *)parser)->m_userData)
+@@ -449,6 +457,7 @@
+ #define parentParser (((Parser *)parser)->m_parentParser)
+ #define paramEntityParsing (((Parser *)parser)->m_paramEntityParsing)
+ #endif /* XML_DTD */
++#define hash_secret_salt (((Parser *)parser)->m_hash_secret_salt)
+
+ #ifdef _MSC_VER
+ #ifdef _DEBUG
+@@ -527,6 +536,7 @@
+ parentParser = 0;
+ paramEntityParsing = XML_PARAM_ENTITY_PARSING_NEVER;
+ #endif
++ hash_secret_salt = 0;
+ ns = 0;
+ poolInit(&tempPool);
+ poolInit(&temp2Pool);
+@@ -546,20 +556,6 @@
+ XML_Parser
+ xmlrpc_XML_ParserCreateNS(const XML_Char *encodingName, XML_Char nsSep)
+ {
+- static
+- const XML_Char implicitContext[] = {
+-XML_T('x'), XML_T('m'), XML_T('l'), XML_T('='),
+-XML_T('h'), XML_T('t'), XML_T('t'), XML_T('p'), XML_T(':'),
+-XML_T('/'), XML_T('/'), XML_T('w'), XML_T('w'), XML_T('w'),
+-XML_T('.'), XML_T('w'), XML_T('3'),
Bug#687672: xmlrpc-c: Embedded Expat vulnerable to CVE-2012-0876, CVE-2012-1148
Package: xmlrpc-c
Version: 1.16.33-3.1
Severity: grave
Tags: patch security
Justification: user security hole
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* Run the tests as part of the build process
- debian/patches/FTBFS-tests.patch: Fix issues when running make check.
Based on upstream patches.
- debian/rules: Run make check after building
* SECURITY UPDATE: Denial of service via hash collisions (LP: #1048835)
- debian/patches/CVE-2012-0876.patch: Add random salt value to
hash inputs. Based on upstream patch.
- CVE-2012-0876
* SECURITY UPDATE: Denial of service via memory leak (LP: #1048835)
- debian/patches/CVE-2012-1148.patch: Properly reallocate memory.
Based on upstream patch.
- CVE-2012-1148
Because I had to backport the patch from upstream Expat to the forked
Expat in xmlrpc-c, I enabled the tests that are ran with 'make check' to
help ensure that I didn't introduce any regressions.
The fixes for the two CVEs have since been merged in upstream xmlrpc-c
(see the patch tags for links). Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-14-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u xmlrpc-c-1.16.33/debian/rules xmlrpc-c-1.16.33/debian/rules
--- xmlrpc-c-1.16.33/debian/rules
+++ xmlrpc-c-1.16.33/debian/rules
@@ -53,6 +53,7 @@
dh_testdir
$(MAKE) CADD=-fPIC
( cd tools && $(MAKE) CADD=-fPIC )
+ $(MAKE) CADD=-fPIC check
touch build-arch-stamp
build-indep: build-indep-stamp
diff -u xmlrpc-c-1.16.33/debian/changelog xmlrpc-c-1.16.33/debian/changelog
diff -u xmlrpc-c-1.16.33/debian/patches/series xmlrpc-c-1.16.33/debian/patches/series
--- xmlrpc-c-1.16.33/debian/patches/series
+++ xmlrpc-c-1.16.33/debian/patches/series
@@ -4,0 +5,3 @@
+FTBFS-tests.patch
+CVE-2012-0876.patch
+CVE-2012-1148.patch
only in patch2:
unchanged:
--- xmlrpc-c-1.16.33.orig/debian/patches/CVE-2012-0876.patch
+++ xmlrpc-c-1.16.33/debian/patches/CVE-2012-0876.patch
@@ -0,0 +1,541 @@
+Description: Prevent predictable hash collisions by using a random salt value
+ Backported from the upstream Expat sources to the embedded copy of Expat in
+ xmlrpc-c.
+Origin: backport, http://xmlrpc-c.svn.sourceforge.net/viewvc/xmlrpc-c?view=revision&revision=2391
+Index: xmlrpc-c-1.16.33/lib/expat/xmlparse/xmlparse.c
+===
+--- xmlrpc-c-1.16.33.orig/lib/expat/xmlparse/xmlparse.c 2012-09-06 09:54:29.920445233 -0700
xmlrpc-c-1.16.33/lib/expat/xmlparse/xmlparse.c 2012-09-06 11:42:34.792312153 -0700
+@@ -17,6 +17,8 @@
+
+ #include
+ #include
++#include /* UINT_MAX */
++#include/* time() */
+
+ #include "xmlrpc_config.h"
+ #include "c_util.h"
+@@ -211,6 +213,8 @@
+enum XML_Error * const errorCodeP,
+const char **const errorP);
+
++static
++int setContext(XML_Parser parser, const XML_Char *context);
+
+ #define poolStart(pool) ((pool)->start)
+ #define poolEnd(pool) ((pool)->ptr)
+@@ -314,6 +318,7 @@
+ XML_Char m_namespaceSeparator;
+ enum XML_ParamEntityParsing m_paramEntityParsing;
+ XML_Parser m_parentParser;
++ unsigned long m_hash_secret_salt;
+ } Parser;
+
+ #define userData (((Parser *)parser)->m_userData)
+@@ -391,6 +396,7 @@
+ #define namespaceSeparator (((Parser *)parser)->m_namespaceSeparator)
+ #define parentParser (((Parser *)parser)->m_parentParser)
+ #define paramEntityParsing (((Parser *)parser)->m_paramEntityParsing)
++#define hash_secret_salt (((Parser *)parser)->m_hash_secret_salt)
+
+
+
+@@ -564,6 +570,39 @@
+ return pool->start;
+ }
+
++static unsigned long
++generate_hash_secret_salt(void)
++{
++ unsigned int seed = time(NULL) % UINT_MAX;
++ srand(seed);
++ return rand();
++}
++
++static int /* only valid for root parser */
++startParsing(XML_Parser parser)
++{
++static
++const XML_Char implicitContext[] = {
++XML_T('x'), XML_T('m'), XML_T('l'), XML_T('='),
++XML_T('h'), XML_T('t'), XML_T('t'), XML_T('p'), XML_T(':'),
++XML_T('/'), XML_T('/'), XML_T('w'), XML_T('w'), XML_T('w'),
++XML_T('.'), XML_T('w'), XML_T('3'),
++XML_T('.'), XML_T('o'), XML_T('r'), XML_T('g'),
++XML_T('/'), XML_T('X'), XML_T('M'), XML_T('L'),
++XML_T('/'), XML_T('1'), XML_T('9'), XML_T('9'), XML_T('8'),
++XML_T('/'), XML_T('n'), XML_T('a'), XML_T('m'), XML_T('e'),
++XML_T('s'), XML_T('p'), XML_T('a'), XML_T('c'), XML_T('e'),
++XML_T('\0')
++};
++
++
Bug#682329: [xmlrpc-api-utils] This package should depend on libxmlrpc-c++4
Package: xmlrpc-c
Version: 1.16.33-3.1
Followup-For: Bug #682329
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* Fix dependencies of xmlrpc-api-utils
- debian/control: xml-rcp-api2cpp needs libxmlrpc_cpp.so.4, so depend on
libxmlrpc-c++4
Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-14-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u xmlrpc-c-1.16.33/debian/control xmlrpc-c-1.16.33/debian/control
--- xmlrpc-c-1.16.33/debian/control
+++ xmlrpc-c-1.16.33/debian/control
@@ -1,8 +1,7 @@
Source: xmlrpc-c
Priority: optional
Section: libs
-Maintainer: Ubuntu Developers
-XSBC-Original-Maintainer: Sean Finney
+Maintainer: Sean Finney
Build-Depends: autotools-dev, debhelper (>= 5), libcurl4-openssl-dev (>= 7.22.0) | libcurl3-openssl-dev (>= 7.22.0), quilt
Homepage: http://xmlrpc-c.sourceforge.net
Standards-Version: 3.9.1
@@ -103,8 +102,9 @@
Replaces: xml-rpc-api2cpp, xml-rpc-api2txt
Architecture: any
Section: devel
-Depends: libxmlrpc-core-c3 (= ${binary:Version}), libc6-dev,
- libfrontier-rpc-perl, ${misc:Depends}
+Depends: libxmlrpc-core-c3 (= ${binary:Version}),
+ libxmlrpc-c++4 (= ${binary:Version}), libc6-dev, libfrontier-rpc-perl,
+ ${misc:Depends}
Description: Generate C++ wrapper classes for XML-RPC servers
XML-RPC is a quick-and-easy way to make procedure calls over the Internet.
It converts the procedure call into an XML document, sends it to a remote
Bug#652996: t1lib: CVE-2011-0764
Package: t1lib
Version: 5.1.2-3
Severity: grave
Tags: patch security
Justification: user security hole
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0764
*** /tmp/tmpP7Dzmm
In Ubuntu, the attached patch was applied to achieve the following:
Prevents an invalid pointer from being dereferenced when using a
maliciously crafted font.
* SECURITY UPDATE: Arbitrary code execution via crafted Type 1 font
- lib/type1/type1.c: Only use ppoints when it is a valid pointer
- CVE-2011-0764
Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers oneiric-updates
APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500,
'oneiric')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-14-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- t1lib-5.1.2.orig/debian/patches/CVE-2011-0764.patch
+++ t1lib-5.1.2/debian/patches/CVE-2011-0764.patch
@@ -0,0 +1,31 @@
+Description: Don't lookup previous point if there isn't any
+Author: Marc Deslauriers
+
+Index: t1lib-5.1.2/lib/type1/type1.c
+===
+--- t1lib-5.1.2.orig/lib/type1/type1.c 2011-12-13 14:24:14.280965637 -0600
t1lib-5.1.2/lib/type1/type1.c 2011-12-13 14:25:25.893320747 -0600
+@@ -1700,6 +1700,7 @@
+ long pindex = 0;
+
+ /* compute hinting for previous segment! */
++ if (ppoints == NULL) Error0i("RLineTo: No previous point!\n");
+ FindStems( currx, curry, currx-ppoints[numppoints-2].x, curry-ppoints[numppoints-2].y, dx, dy);
+
+ /* Allocate a new path point and pre-setup data */
+@@ -1728,6 +1729,7 @@
+ long pindex = 0;
+
+ /* compute hinting for previous point! */
++ if (ppoints == NULL) Error0i("RRCurveTo: No previous point!\n");
+ FindStems( currx, curry, currx-ppoints[numppoints-2].x, curry-ppoints[numppoints-2].y, dx1, dy1);
+
+ /* Allocate three new path points and pre-setup data */
+@@ -1903,6 +1905,7 @@
+ FindStems( currx, curry, 0, 0, dx, dy);
+ }
+ else {
++if (ppoints == NULL) Error0i("RMoveTo: No previous point!\n");
+ FindStems( currx, curry, ppoints[numppoints-2].x, ppoints[numppoints-2].y, dx, dy);
+ }
+
