Debian Bug report logs - #755740
qemu-system-x86 - 9p mapped-* security model infos architecture specific

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: qemu-system-x86 - 9p mapped-* security model infos architecture specific

Date: Tue, 22 Jul 2014 23:15:00 +0200

Package: qemu-system-x86
Version: 2.0.0+dfsg-6+b1
Severity: important

The local 9p support supports two security modules that map the
information to either extended attributes or files.

The mappes xattr support dumps all information as raw bytes in the host
endianes, without any normalization.  This makes the information not
portable and may lead to privilege escalation in the guest.

Bastian

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu           1.0.0+git-20131111.c3d1e78-2
ii  libaio1             0.3.109-4
ii  libasound2          1.0.28-1
ii  libbluetooth3       4.101-4.1
ii  libbrlapi0.6        5.0-2+b1
ii  libc6               2.19-7
ii  libcurl3-gnutls     7.37.0-1+b1
ii  libfdt1             1.4.0+dfsg-1
ii  libgcc1             1:4.9.0-7
ii  libglib2.0-0        2.40.0-3
ii  libgnutls-deb0-28   3.2.15-3
ii  libiscsi2           1.11.0-4
ii  libjpeg8            8d1-1
ii  libncurses5         5.9+20140118-1
ii  libpixman-1-0       0.32.6-1
ii  libpng12-0          1.2.50-1
ii  libpulse0           5.0-2
ii  librados2           0.80.1-2
ii  librbd1             0.80.1-2
ii  libsasl2-2          2.1.26.dfsg1-11
ii  libsdl1.2debian     1.2.15-10
ii  libseccomp2         2.1.1-1
ii  libspice-server1    0.12.5-1
ii  libssh2-1           1.4.3-3
ii  libtinfo5           5.9+20140118-1
ii  libusb-1.0-0        2:1.0.19-1
ii  libusbredirparser1  0.7-1
ii  libuuid1            2.20.1-5.8
ii  libvdeplug2         2.3.2-4
ii  libx11-6            2:1.6.2-2
ii  libxen-4.3          4.3.0-3+b1
ii  libxenstore3.0      4.3.0-3+b1
ii  qemu-keymaps        2.0.0+dfsg-6
ii  qemu-system-common  2.0.0+dfsg-6+b1
ii  seabios             1.7.5-1
ii  zlib1g              1:1.2.8.dfsg-1

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  2.0.0+dfsg-6+b1

Versions of packages qemu-system-x86 suggests:
ii  kmod     18-1
pn  ovmf     <none>
pn  samba    <none>
pn  sgabios  <none>
pn  vde2     <none>

-- no debconf information

Message #12 received at 755740@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>, Qemu Development List <Qemu-devel@nongnu.org>

Cc: 755740@bugs.debian.org

Subject: Re: 9p mapped-* security model infos are architecture-specific

Date: Mon, 25 Aug 2014 15:15:04 +0400

I haven't noticed this email - which is almost a month old now - until today.
So replying now...

30.07.2014 21:43, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> 
>> Michael Tokarev <mjt@tls.msk.ru> writes:
>>
>>> Apparently the the mapped-* security models results in a raw bytes
>>> being dumped to host without any architecture normalization (in
>>> host byte order).  This may even lead to security issues in guest
>>> when the same files are served from another host for example.
>>>
>>> This bug has been initially submitted against debian qemu package, see
>>> http://bugs.debian.org/755740
>>>
>>
>> Thanks for reporting the bug. Yes we do have issue with
>> mapped-xattr. But mapped-file should be ok. We record the uid/gid as
>> string in the file.
> 
> What would be the best way to fix this in a backward compatible way ?
> Considering most of the users will be little endian host, we could do "always
> store in little endian format" which of-course will break big-endian
> hosts. We could possibly ask them to update xattr using external tools ?

If there's no way to _detect_ the used format (maybe doing some guessing, --
if that's possible to do in a reliable way, it should be good), that's
one of 2 possible options as I see it: that or introduce a new format
entirely, maybe with another attribute name.

It might not be even required to use an external tool for conversion.
Again, if qemu is able to detect "wrong" endiannes, it might just
update things itself, or print a warning and switch to an old format,
or something like that.

But the guessing idea might not be as bad really.  I haven't looked
closely which information is stored in there, -- but it is possible
that some fields should have zeros in some bytes for example, and
if these aren't zero but becomes zeros after endianness conversion
that might be a good indicator.

I'm not sure the runtime code should be able to work with both formats
at the same time.  Actually, I'm not sure this is a big issue to
start with -- indeed, you said it already, majority of users of 9pfs
should be little endian hosts, -- are there any big endian hosts
using this, at all? :)  How about trying to detect (preferrable at
init time) and refusing to start if old/wrong format is detected.

Maybe have a compile-time define to use native or little endian
format is a good idea too.

Bastian, since you discovered this issue, you might be using
a host with "uncommon" endianness, what do you think?

Thanks,

/mjt

> diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
> index 3b0b6a9b1d7d..cd662410420e 100644
> --- a/hw/9pfs/virtio-9p-local.c
> +++ b/hw/9pfs/virtio-9p-local.c
> @@ -135,17 +135,17 @@ static int local_lstat(FsContext *fs_ctx, V9fsPath *fs_path, struct stat *stbuf)
>          mode_t tmp_mode;
>          dev_t tmp_dev;
>          if (getxattr(buffer, "user.virtfs.uid", &tmp_uid, sizeof(uid_t)) > 0) {
> -            stbuf->st_uid = tmp_uid;
> +            stbuf->st_uid = le32_to_cpu(tmp_uid);
>          }
>          if (getxattr(buffer, "user.virtfs.gid", &tmp_gid, sizeof(gid_t)) > 0) {
> -            stbuf->st_gid = tmp_gid;
> +            stbuf->st_gid = le32_to_cpu(tmp_gid);
>          }
>          if (getxattr(buffer, "user.virtfs.mode",
>                      &tmp_mode, sizeof(mode_t)) > 0) {
> -            stbuf->st_mode = tmp_mode;
> +            stbuf->st_mode = le32_to_cpu(tmp_mode);
>          }
>          if (getxattr(buffer, "user.virtfs.rdev", &tmp_dev, sizeof(dev_t)) > 0) {
> -                stbuf->st_rdev = tmp_dev;
> +            stbuf->st_rdev = le64_to_cpu(tmp_dev);
>          }
>      } else if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE) {
>          local_mapped_file_attr(fs_ctx, path, stbuf);
> @@ -255,29 +255,29 @@ static int local_set_xattr(const char *path, FsCred *credp)
>      int err;
>  
>      if (credp->fc_uid != -1) {
> -        err = setxattr(path, "user.virtfs.uid", &credp->fc_uid, sizeof(uid_t),
> -                0);
> +        uint32_t tmp_uid = cpu_to_le32(credp->fc_uid);
> +        err = setxattr(path, "user.virtfs.uid", &tmp_uid, sizeof(uid_t), 0);
>          if (err) {
>              return err;
>          }
>      }
>      if (credp->fc_gid != -1) {
> -        err = setxattr(path, "user.virtfs.gid", &credp->fc_gid, sizeof(gid_t),
> -                0);
> +        uint32_t tmp_gid = cpu_to_le32(credp->fc_gid);
> +        err = setxattr(path, "user.virtfs.gid", &tmp_gid, sizeof(gid_t), 0);
>          if (err) {
>              return err;
>          }
>      }
>      if (credp->fc_mode != -1) {
> -        err = setxattr(path, "user.virtfs.mode", &credp->fc_mode,
> -                sizeof(mode_t), 0);
> +        uint32_t tmp_mode = cpu_to_le32(credp->fc_mode);
> +        err = setxattr(path, "user.virtfs.mode", &tmp_mode, sizeof(mode_t), 0);
>          if (err) {
>              return err;
>          }
>      }
>      if (credp->fc_rdev != -1) {
> -        err = setxattr(path, "user.virtfs.rdev", &credp->fc_rdev,
> -                sizeof(dev_t), 0);
> +        uint64_t tmp_rdev = cpu_to_le32(credp->fc_rdev);
> +        err = setxattr(path, "user.virtfs.rdev", &tmp_rdev, sizeof(dev_t), 0);
>          if (err) {
>              return err;
>          }
> @@ -630,21 +630,17 @@ static int local_fstat(FsContext *fs_ctx, int fid_type,
>          mode_t tmp_mode;
>          dev_t tmp_dev;
>  
> -        if (fgetxattr(fd, "user.virtfs.uid",
> -                      &tmp_uid, sizeof(uid_t)) > 0) {
> -            stbuf->st_uid = tmp_uid;
> +        if (fgetxattr(fd, "user.virtfs.uid", &tmp_uid, sizeof(uid_t)) > 0) {
> +            stbuf->st_uid = le32_to_cpu(tmp_uid);
>          }
> -        if (fgetxattr(fd, "user.virtfs.gid",
> -                      &tmp_gid, sizeof(gid_t)) > 0) {
> -            stbuf->st_gid = tmp_gid;
> +        if (fgetxattr(fd, "user.virtfs.gid", &tmp_gid, sizeof(gid_t)) > 0) {
> +            stbuf->st_gid = le32_to_cpu(tmp_gid);
>          }
> -        if (fgetxattr(fd, "user.virtfs.mode",
> -                      &tmp_mode, sizeof(mode_t)) > 0) {
> -            stbuf->st_mode = tmp_mode;
> +        if (fgetxattr(fd, "user.virtfs.mode", &tmp_mode, sizeof(mode_t)) > 0) {
> +            stbuf->st_mode = le32_to_cpu(tmp_mode);
>          }
> -        if (fgetxattr(fd, "user.virtfs.rdev",
> -                      &tmp_dev, sizeof(dev_t)) > 0) {
> -                stbuf->st_rdev = tmp_dev;
> +        if (fgetxattr(fd, "user.virtfs.rdev", &tmp_dev, sizeof(dev_t)) > 0) {
> +            stbuf->st_rdev = le64_to_cpu(tmp_dev);
>          }
>      } else if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE) {
>          errno = EOPNOTSUPP;
> 
> 

Message #17 received at 755740@bugs.debian.org (full text, mbox, reply):

From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>

To: Michael Tokarev <mjt@tls.msk.ru>, Qemu Development List <Qemu-devel@nongnu.org>

Cc: 755740@bugs.debian.org

Subject: Re: 9p mapped-* security model infos are architecture-specific

Date: Tue, 26 Aug 2014 11:40:25 +0530

Michael Tokarev <mjt@tls.msk.ru> writes:

> I haven't noticed this email - which is almost a month old now - until today.
> So replying now...
>
> 30.07.2014 21:43, Aneesh Kumar K.V wrote:
>> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
>> 
>>> Michael Tokarev <mjt@tls.msk.ru> writes:
>>>
>>>> Apparently the the mapped-* security models results in a raw bytes
>>>> being dumped to host without any architecture normalization (in
>>>> host byte order).  This may even lead to security issues in guest
>>>> when the same files are served from another host for example.
>>>>
>>>> This bug has been initially submitted against debian qemu package, see
>>>> http://bugs.debian.org/755740
>>>>
>>>
>>> Thanks for reporting the bug. Yes we do have issue with
>>> mapped-xattr. But mapped-file should be ok. We record the uid/gid as
>>> string in the file.
>> 
>> What would be the best way to fix this in a backward compatible way ?
>> Considering most of the users will be little endian host, we could do "always
>> store in little endian format" which of-course will break big-endian
>> hosts. We could possibly ask them to update xattr using external tools ?
>
> If there's no way to _detect_ the used format (maybe doing some guessing, --
> if that's possible to do in a reliable way, it should be good), that's
> one of 2 possible options as I see it: that or introduce a new format
> entirely, maybe with another attribute name.
>
> It might not be even required to use an external tool for conversion.
> Again, if qemu is able to detect "wrong" endiannes, it might just
> update things itself, or print a warning and switch to an old format,
> or something like that.

I was not able to come up with a way to detect "wrong" endianness. 

>
> But the guessing idea might not be as bad really.  I haven't looked
> closely which information is stored in there, -- but it is possible
> that some fields should have zeros in some bytes for example, and
> if these aren't zero but becomes zeros after endianness conversion
> that might be a good indicator.


No, they are 32 bit numbers and we can't make any assumptions w.r.t
upper half/lower half being zero


>
> I'm not sure the runtime code should be able to work with both formats
> at the same time.  Actually, I'm not sure this is a big issue to
> start with -- indeed, you said it already, majority of users of 9pfs
> should be little endian hosts, -- are there any big endian hosts
> using this, at all? :)  How about trying to detect (preferrable at
> init time) and refusing to start if old/wrong format is detected.
>
> Maybe have a compile-time define to use native or little endian
> format is a good idea too.
>

That would confuse further. It also impact the interoperability of
export path across different build of qemus.


> Bastian, since you discovered this issue, you might be using
> a host with "uncommon" endianness, what do you think?
>

-aneesh

Message #24 received at 755740-close@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 755740-close@bugs.debian.org

Subject: Bug#755740: fixed in qemu 2.1+dfsg-6

Date: Mon, 03 Nov 2014 15:34:48 +0000

Source: qemu
Source-Version: 2.1+dfsg-6

We believe that the bug you reported is fixed in the latest version of
qemu, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 755740@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated qemu package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 03 Nov 2014 18:07:48 +0300
Source: qemu
Binary: qemu qemu-system qemu-system-common qemu-system-misc qemu-system-arm qemu-system-mips qemu-system-ppc qemu-system-sparc qemu-system-x86 qemu-user qemu-user-static qemu-user-binfmt qemu-utils qemu-guest-agent qemu-kvm
Architecture: source amd64
Version: 2.1+dfsg-6
Distribution: unstable
Urgency: medium
Maintainer: Debian QEMU Team <pkg-qemu-devel@lists.alioth.debian.org>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Description:
 qemu       - fast processor emulator
 qemu-guest-agent - Guest-side qemu-system agent
 qemu-kvm   - QEMU Full virtualization on x86 hardware
 qemu-system - QEMU full system emulation binaries
 qemu-system-arm - QEMU full system emulation binaries (arm)
 qemu-system-common - QEMU full system emulation binaries (common files)
 qemu-system-mips - QEMU full system emulation binaries (mips)
 qemu-system-misc - QEMU full system emulation binaries (miscelaneous)
 qemu-system-ppc - QEMU full system emulation binaries (ppc)
 qemu-system-sparc - QEMU full system emulation binaries (sparc)
 qemu-system-x86 - QEMU full system emulation binaries (x86)
 qemu-user  - QEMU user mode emulation binaries
 qemu-user-binfmt - QEMU user mode binfmt registration for qemu-user
 qemu-user-static - QEMU user mode emulation binaries (static version)
 qemu-utils - QEMU utilities
Closes: 747636 755740 760949 765075 765496
Changes:
 qemu (2.1+dfsg-6) unstable; urgency=medium
 .
   * mention closing of CVE-2014-3615 by 2.1.2 (2.1+dfsg-5)
   * 9p-use-little-endian-format-for-xattr-values.patch (Closes: #755740)
   * mention closing of #760386
   * mention closing of more CVEs by 2.1+dfsg-1
   * recognize ppc64el in qemu-debootstrap (Luca Falavigna) (Closes: #760949)
   * use dpkg-vendor to let derived distros to use our d/rules
   * use /usr/share/dpkg/architecture.mk to get DEB_HOST_* and DEB_BUILD_*
     variables.  This restores cross building support.
   * use /usr/share/dpkg/buildflags.mk for CFLAGS LDFLAGS &Co
   * pass -DVENDOR_{DEBIAN,UBUNTU} to compiler
   * do not treat ppc* and ppc*le as compatible for binfmt registrations
   * mention ACPI SLIC to RSDT id copying if slic table is supplied,
     thank you Tim Small for the patch (Closes: #765075)
   * apply 5 patches from upstream to fix a security issue in
     vmware-vga (Closes: #765496 CVE-2014-3689)
   * apply two patche from upstream to make qemu to work with samba4
     (Closes: #747636)
Checksums-Sha1:
 e68b0c1d77a89cd1dd110b3e0bdc5e38d2b6ac90 5152 qemu_2.1+dfsg-6.dsc
 6a57b4e2b513bc0e196edaefd695c9cb5f231961 81560 qemu_2.1+dfsg-6.debian.tar.xz
 ec1508bfaedb2ff2b223bfe5644fd088f5ddb55c 119682 qemu_2.1+dfsg-6_amd64.deb
 e7e6516893a33c878f6e760d8c6f5265246d8a25 48538 qemu-system_2.1+dfsg-6_amd64.deb
 9d2319f4af81c6f2cd4ea019fc08fc46515e7246 278666 qemu-system-common_2.1+dfsg-6_amd64.deb
 9817c13585bf9e1b24faa7ea964e6da9a0e75d35 5183470 qemu-system-misc_2.1+dfsg-6_amd64.deb
 6003fd59f5796d6312f22ad2ca621559fafd9c67 2227250 qemu-system-arm_2.1+dfsg-6_amd64.deb
 9231ba84f341eadffbb1fd9ff6ef1c94ca72cc35 2556076 qemu-system-mips_2.1+dfsg-6_amd64.deb
 9068a7e2e99a797466e93962fbb625e3c92b5c4b 2820706 qemu-system-ppc_2.1+dfsg-6_amd64.deb
 184f27345b19b0b6fe282692f4dc2bdddff4459a 1665768 qemu-system-sparc_2.1+dfsg-6_amd64.deb
 66e7727bb69350e0f4fbc042e366ab989c1e2c0c 2040342 qemu-system-x86_2.1+dfsg-6_amd64.deb
 7e144c145642857d1aec846f5e0e709ab80101ff 4907988 qemu-user_2.1+dfsg-6_amd64.deb
 bcbdb00088b407c2ee47aa3453f28a2985bdbdbf 6904450 qemu-user-static_2.1+dfsg-6_amd64.deb
 8d7c76d247c373b57af57ac4715ed75c859c1fcf 2652 qemu-user-binfmt_2.1+dfsg-6_amd64.deb
 7579cf2a382c9fcec20620e2c17240df7b4bd61e 478684 qemu-utils_2.1+dfsg-6_amd64.deb
 5e7d91eb315e0f8a6b97436d54dc5ee65637a2e4 133326 qemu-guest-agent_2.1+dfsg-6_amd64.deb
 c2d5a776d6d64cd14a2ae77c4c00819d0d3aac08 49558 qemu-kvm_2.1+dfsg-6_amd64.deb
Checksums-Sha256:
 ccb5ef340215528f33b9bdec54199ddabcf005e3573ff40c1b2e0467b899e187 5152 qemu_2.1+dfsg-6.dsc
 625c68c0f7c02dcd2decf93fad4694985a09d2ff49d55c0dac931432646d52ea 81560 qemu_2.1+dfsg-6.debian.tar.xz
 7340b3a3be5131d6478915ae46f9966c12879e5b0a5738e6ea5d44439d8577e4 119682 qemu_2.1+dfsg-6_amd64.deb
 d3ba0d00ac25a9ee6d964c103476b57ee44f52d5d4d609edc5f0273f608bb3e2 48538 qemu-system_2.1+dfsg-6_amd64.deb
 c26f30f3418da6102f604cf03f1f64ee56b187c4d9cc7d8e4277bf7206975bde 278666 qemu-system-common_2.1+dfsg-6_amd64.deb
 c75301916d9e8e2f62925026fdc97b394ff964c3c56b06166e496a9292cc2085 5183470 qemu-system-misc_2.1+dfsg-6_amd64.deb
 40f25b41ea7d688566d5f319269c2705f3cbc3d8cc56878d482264f3cbf6fdc6 2227250 qemu-system-arm_2.1+dfsg-6_amd64.deb
 acc65ad2ef7bac65f3a1689e9db1e831052a070294639b1a1c161beae5ef5777 2556076 qemu-system-mips_2.1+dfsg-6_amd64.deb
 014e8be956153ba784483f8b4fcc42ff2ff4d1406ba62075f808be56d78bb8b4 2820706 qemu-system-ppc_2.1+dfsg-6_amd64.deb
 6554cf7cc2b041056c22a078cc15fa3ce5be34b80200e0cb71eef44d2d88aac7 1665768 qemu-system-sparc_2.1+dfsg-6_amd64.deb
 a175462a2769e3ea2fa9da96b618e4846f505ed491cfa94f41be5321ebd42249 2040342 qemu-system-x86_2.1+dfsg-6_amd64.deb
 e2bd0cb5dd391ca3025bd54dc0e4d0cfe5479ee42207caf348d9f07cbe210cc1 4907988 qemu-user_2.1+dfsg-6_amd64.deb
 c17e6128281453e2af3970891c7e1aad7881aef1fb9bffdf1002321b99b378a7 6904450 qemu-user-static_2.1+dfsg-6_amd64.deb
 031459df5b9b09da64563fe31c62faa0ff5a3f5b829699390f37b2a105066245 2652 qemu-user-binfmt_2.1+dfsg-6_amd64.deb
 a6f29e930a82a9150bed34a6140896bacca787f73e156b221e3e21e22292dce1 478684 qemu-utils_2.1+dfsg-6_amd64.deb
 bac19bd49fb884d34b65ee104e8c43aac99d9b045157808878583e6c6a5c65f7 133326 qemu-guest-agent_2.1+dfsg-6_amd64.deb
 ba3b5c839c892886d7a716ad140d08b0ff498a43b4e9b3d87bcec0955010e6ab 49558 qemu-kvm_2.1+dfsg-6_amd64.deb
Files:
 c8d8ac62dfb374a0f602900d490556bb 5152 otherosfs optional qemu_2.1+dfsg-6.dsc
 e9cf94cf26abd215fcd1f67bcb68a0f5 81560 otherosfs optional qemu_2.1+dfsg-6.debian.tar.xz
 c3a7a87854f2a09ee644f00dd1e867ad 119682 otherosfs optional qemu_2.1+dfsg-6_amd64.deb
 e53f4dfb5ddfc40471595e21f716caa3 48538 otherosfs optional qemu-system_2.1+dfsg-6_amd64.deb
 8b35ba6ec6e5207c7ccc638b9f606fea 278666 otherosfs optional qemu-system-common_2.1+dfsg-6_amd64.deb
 d93f243000b9a5b1af78c14d462070e3 5183470 otherosfs optional qemu-system-misc_2.1+dfsg-6_amd64.deb
 71846a06fdc007f87aab21232438f289 2227250 otherosfs optional qemu-system-arm_2.1+dfsg-6_amd64.deb
 874888c99b376168803626769bafcf6c 2556076 otherosfs optional qemu-system-mips_2.1+dfsg-6_amd64.deb
 e06709d84f87c8483b3259167786acd9 2820706 otherosfs optional qemu-system-ppc_2.1+dfsg-6_amd64.deb
 56cb2c3ac4dabd995424c7350280bf7a 1665768 otherosfs optional qemu-system-sparc_2.1+dfsg-6_amd64.deb
 cc2b899895119f8ccb3ab0c824e15f4e 2040342 otherosfs optional qemu-system-x86_2.1+dfsg-6_amd64.deb
 5c0feeeb73bbd573e238843f73062e9d 4907988 otherosfs optional qemu-user_2.1+dfsg-6_amd64.deb
 8b73a5a59e873e47dd9018e04a5d0e60 6904450 otherosfs optional qemu-user-static_2.1+dfsg-6_amd64.deb
 01b44bb51855e3f6a64813c86754b2b7 2652 otherosfs optional qemu-user-binfmt_2.1+dfsg-6_amd64.deb
 cffeb540cd9e89828025d6d36898e265 478684 otherosfs optional qemu-utils_2.1+dfsg-6_amd64.deb
 470224d6a85a069347de6344240214f8 133326 otherosfs optional qemu-guest-agent_2.1+dfsg-6_amd64.deb
 c3e8ac98c88ed2a3d92e6d55c76a3221 49558 otherosfs optional qemu-kvm_2.1+dfsg-6_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUV53oAAoJEL7lnXSkw9fbSEUH/i+zS1b291hembnaBuQCpd2n
0T+FzAZBG5Lihts1KFl3AuAwWj6XqGEe29yg69QP7dF1YMt8awkuP8lhCj/BOTlt
C5GcxfSTBKTp5mHxMKdVtFsMaavw8tw+EJlN+wP+/jcGhD4KocXQCOCTbrMhU3yN
p23CxvjC0sMqXnQf9pcviuZekZPJn+6PvN4LQMvWkrQ+34s+Lvwq7Ufh8uPXi+Ry
OSsMTb7cZMPRMGVVVGhuXAzytk550mBf3C4n1XpM8iJ46FDmJuQZO2L5W43yLINt
u9JV1+YxBQ8nEqdU0yd91ZgxpiVN8OQx97sF7nLP14FgiD2ekBm/kJHfyRF/P0k=
=L1tY
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.