Bug#954654: transition: hdf5
On 4/6/20 12:54 PM, Emilio Pozuelo Monfort wrote: > hdf5 is currently blocked from migrating to testing on mpich due to #954244. mpich migrated to testing. hdf5 will need some help to migrate, not all bad rdeps will be autoremoved eventually. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#956216: buster-pu: package systemd/241-7~deb10u3
Hi Michael, [Giving my opinion only, final word is obviously to the release team] On Wed, Apr 08, 2020 at 04:11:31PM +0200, Michael Biebl wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > Hi, > > I'd like to make a stable/buster upload for systemd fixing CVE-2020-1712 > https://security-tracker.debian.org/tracker/CVE-2020-1712 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950732 > > After talking to the security team (namely Salvatore), we decided to fix > this issue via a stable upload. > > The debdiff is a bit on the larger side, unfortunately. > Salvatore made a smaller backport avoiding some of the refactorings > that were done upstream > https://salsa.debian.org/systemd-team/systemd/-/merge_requests/69 > > I decided to go with the backport provided by upstream that was done for > the v241-stable branch mainly for two reasons: > - It makes potential future cherry-picks easier > - Doing our own backport has the potential to introduce Debian specific > bugs > > That said, if you prefer the more minimal backport from Salvatore, > please let me know and I'll redo the upload accordingly. While I did the work, I would as well strongly prefer to go rather the upstream route and be on safe side. I tried to diligently backport it but as upstream did provide their own approach to v241 branch I think this would be better by means of the two raised reasons from Michael above. Thank you Michael for working towards a fix for the issue for buster. Regards, Salvatore
Processed: Re: Bug#956216: buster-pu: package systemd/241-7~deb10u4
Processing control commands: > retitle -1 buster-pu: package systemd/241-7~deb10u4 Bug #956216 [release.debian.org] buster-pu: package systemd/241-7~deb10u3 Changed Bug title to 'buster-pu: package systemd/241-7~deb10u4' from 'buster-pu: package systemd/241-7~deb10u3'. -- 956216: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956216 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#956216: buster-pu: package systemd/241-7~deb10u4
Control: retitle -1 buster-pu: package systemd/241-7~deb10u4 Sorry, messed up the version in the Subject
Bug#956216: buster-pu: package systemd/241-7~deb10u3
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I'd like to make a stable/buster upload for systemd fixing CVE-2020-1712
https://security-tracker.debian.org/tracker/CVE-2020-1712
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950732
After talking to the security team (namely Salvatore), we decided to fix
this issue via a stable upload.
The debdiff is a bit on the larger side, unfortunately.
Salvatore made a smaller backport avoiding some of the refactorings
that were done upstream
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/69
I decided to go with the backport provided by upstream that was done for
the v241-stable branch mainly for two reasons:
- It makes potential future cherry-picks easier
- Doing our own backport has the potential to introduce Debian specific
bugs
That said, if you prefer the more minimal backport from Salvatore,
please let me know and I'll redo the upload accordingly.
The changes are available at
https://salsa.debian.org/systemd-team/systemd/-/commits/debian/buster-proposed/
The debdiff is attached.
udev should not be affected (I've CCed kibi for his review/ACK)
Regards,
Michael
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 1d263f7..f8b017d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+systemd (241-7~deb10u4) buster; urgency=medium
+
+ * polkit: when authorizing via PolicyKit re-resolve callback/userdata
+instead of caching it.
+This fixes a heap use-after-free vulnerability in systemd, when
+asynchronous PolicyKit queries are performed while handling DBus messages.
+(CVE-2020-1712, Closes: #950732)
+
+ -- Michael Biebl Wed, 08 Apr 2020 15:58:24 +0200
+
systemd (241-7~deb10u3) buster; urgency=medium
* core: set fs.file-max sysctl to LONG_MAX rather than ULONG_MAX.
diff --git a/debian/patches/Fix-typo-in-function-name.patch
b/debian/patches/Fix-typo-in-function-name.patch
new file mode 100644
index 000..4f3c521
--- /dev/null
+++ b/debian/patches/Fix-typo-in-function-name.patch
@@ -0,0 +1,77 @@
+From: =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?=
+Date: Tue, 4 Feb 2020 18:39:04 +0100
+Subject: Fix typo in function name
+
+(cherry picked from commit bc130b6858327b382b07b3985cf48e2aa9016b2d)
+(cherry picked from commit b4eb8848240c3540180e4768216a0b884a5ed783)
+(cherry picked from commit f14fa558ae9e139c94ee3af4a1ef1df313b2ff66)
+(cherry picked from commit dd8aa0871d9cafa60a916d4ec01dd82d64edf7ed)
+---
+ TODO| 2 +-
+ src/libsystemd/sd-bus/bus-message.h | 2 +-
+ src/libsystemd/sd-bus/sd-bus.c | 8
+ src/shared/bus-polkit.c | 2 +-
+ 4 files changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/TODO b/TODO
+index 462db57..327fead 100644
+--- a/TODO
b/TODO
+@@ -138,7 +138,7 @@ Features:
+
+ * the a-posteriori stopping of units bound to units that disappeared logic
+ should be reworked: there should be a queue of units, and we should only
+- enqeue stop jobs from a defer event that processes queue instead of
++ enqueue stop jobs from a defer event that processes queue instead of
+ right-away when we find a unit that is bound to one that doesn't exist
+ anymore. (similar to how the stop-unneeded queue has been reworked the same
+ way)
+diff --git a/src/libsystemd/sd-bus/bus-message.h
b/src/libsystemd/sd-bus/bus-message.h
+index 7fd3f11..849d638 100644
+--- a/src/libsystemd/sd-bus/bus-message.h
b/src/libsystemd/sd-bus/bus-message.h
+@@ -211,4 +211,4 @@ int bus_message_remarshal(sd_bus *bus, sd_bus_message **m);
+
+ void bus_message_set_sender_driver(sd_bus *bus, sd_bus_message *m);
+ void bus_message_set_sender_local(sd_bus *bus, sd_bus_message *m);
+-int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message *m);
++int sd_bus_enqueue_for_read(sd_bus *bus, sd_bus_message *m);
+diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
+index 94380af..c20adcf 100644
+--- a/src/libsystemd/sd-bus/sd-bus.c
b/src/libsystemd/sd-bus/sd-bus.c
+@@ -4145,7 +4145,7 @@ _public_ int sd_bus_get_close_on_exit(sd_bus *bus) {
+ return bus->close_on_exit;
+ }
+
+-int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message *m) {
++int sd_bus_enqueue_for_read(sd_bus *bus, sd_bus_message *m) {
+ int r;
+
+ assert_return(bus, -EINVAL);
+@@ -4157,9 +4157,9 @@ int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message
*m) {
+ if (!BUS_IS_OPEN(bus->state))
+ return -ENOTCONN;
+
+-
Bug#954422: transition: GNOME 3.36
On 2020-04-08 11:46:59 +0100, Simon McVittie wrote: > On 21/03/2020 13:17, Simon McVittie wrote: > > > It would probably make most sense to treat gnome-desktop3 and mutter as > > > a single transition, as we have often done in the past: upstream will > > > not have tested arbitrary mixtures of 3.34 and 3.36. > > Progress on this: > > After chasing regressions for the last few days, I think we have Shell > in a good state to consider doing this transition. This would involve > uploading the following experimental GNOME packages to unstable as a batch: > > * gnome-desktop3 > * gjs > * mutter > * gnome-shell > * gnome-shell-extensions > > Ubuntu have already done this transition for 20.04 'focal', so I hope > the Ubuntu people in the GNOME team can give us an idea of the level of > breakage without us having to do our own test-rebuild in Debian. > I'm told the only significant porting work needed in Ubuntu was in Unity. > > gnome-desktop3 ABI breaks have mostly been handled via binNMUs in the > past, without being particularly problematic. > > budgie will need rebuilding against the new mutter, but seems to have > already been patched to cope with either the old or new API/ABI. > > gnome-shell-xrdesktop (a "friendly fork" of gnome-shell with an > experimental 3D UI for VR headsets) will need either updating to 3.36.x > to match (#956147) or removing from testing for a while. I am not able > to test this, and I suspect the rest of the GNOME team are in the same > situation; I don't think we should let gnome-shell-xrdesktop (popcon: 0) > hold back gnome-shell (popcon: 37K votes). The xrdesktop stack is currently doing its own transition (libgulkan-0.13-0 -> libgulkan-0.14-0, libgxr-0.13-0 -> libgxr-0.14-0, and soon the same for libxrdesktop). It's currently blocked on xrdesktop in NEW. Cheers > Third-party GNOME Shell extensions are likely to regress (they do that > a lot, because they work by monkey-patching GNOME Shell internals). I > think we should remove any problematic extensions from testing rather > than let them hold up Shell. Of the three I maintain myself, I have > uploaded a fixed version of one to experimental, and confirmed that > the other two work acceptably as-is. Hopefully that's a reasonably > representative sample. > > My next upload of gnome-shell will hopefully add a workaround for > one major source of regressions in extensions, which is that the way > older extensions invoke a preferences dialog is no longer supported > (#956172 and similar bugs). Extensions will still need fixing for this > before 3.38 or for use on other distros, but the workaround removes the > immediate urgency. > > smcv > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#947351: package cloud-init
On Fri, 27 Mar 2020 15:59:47 -0700 Noah Meyerhans wrote: > Any feedback on this is welcome. Hi Noah, thank you very much for this update. It really helps with network configuration as it includes https://github.com/canonical/cloud-init/commit/a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81 That said, static IP address configuration does not work because the generated cloud-init network interfaces file configures DNS like this: dns-nameservers 172.22.3.1 dns-search bap.lan But the images miss resolvconf. I have opened a bugreport at https://salsa.debian.org/cloud-team/debian-cloud-images/-/issues/24 since I thought that would be the relevant place for it. Otherwise it works fine, thanks! signature.asc Description: OpenPGP digital signature
Bug#954422: transition: GNOME 3.36
On 21/03/2020 13:17, Simon McVittie wrote: > > It would probably make most sense to treat gnome-desktop3 and mutter as > > a single transition, as we have often done in the past: upstream will > > not have tested arbitrary mixtures of 3.34 and 3.36. Progress on this: After chasing regressions for the last few days, I think we have Shell in a good state to consider doing this transition. This would involve uploading the following experimental GNOME packages to unstable as a batch: * gnome-desktop3 * gjs * mutter * gnome-shell * gnome-shell-extensions Ubuntu have already done this transition for 20.04 'focal', so I hope the Ubuntu people in the GNOME team can give us an idea of the level of breakage without us having to do our own test-rebuild in Debian. I'm told the only significant porting work needed in Ubuntu was in Unity. gnome-desktop3 ABI breaks have mostly been handled via binNMUs in the past, without being particularly problematic. budgie will need rebuilding against the new mutter, but seems to have already been patched to cope with either the old or new API/ABI. gnome-shell-xrdesktop (a "friendly fork" of gnome-shell with an experimental 3D UI for VR headsets) will need either updating to 3.36.x to match (#956147) or removing from testing for a while. I am not able to test this, and I suspect the rest of the GNOME team are in the same situation; I don't think we should let gnome-shell-xrdesktop (popcon: 0) hold back gnome-shell (popcon: 37K votes). Third-party GNOME Shell extensions are likely to regress (they do that a lot, because they work by monkey-patching GNOME Shell internals). I think we should remove any problematic extensions from testing rather than let them hold up Shell. Of the three I maintain myself, I have uploaded a fixed version of one to experimental, and confirmed that the other two work acceptably as-is. Hopefully that's a reasonably representative sample. My next upload of gnome-shell will hopefully add a workaround for one major source of regressions in extensions, which is that the way older extensions invoke a preferences dialog is no longer supported (#956172 and similar bugs). Extensions will still need fixing for this before 3.38 or for use on other distros, but the workaround removes the immediate urgency. smcv
Bug#956183: transition: libwmf
Graham Inggs 于2020年4月8日周三 下午6:00写道： > > Please file bugs against these packages and mark them blocking this > bug (#956183). > Done.
Processed: gimp: remove old-style config script `libwmf-config'
Processing control commands: > block 956183 by -1 Bug #956183 [release.debian.org] transition: libwmf 956183 was blocked by: 956199 956183 was not blocking any bugs. Added blocking bug(s) of 956183: 956200 -- 956183: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956183 956200: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956200 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: wv: remove old-style config script `libwmf-config'
Processing control commands: > block 956183 by -1 Bug #956183 [release.debian.org] transition: libwmf 956183 was not blocked by any bugs. 956183 was not blocking any bugs. Added blocking bug(s) of 956183: 956199 -- 956183: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956183 956199: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956199 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: abiword: remove old-style config script `libwmf-config'
Processing control commands: > block 956183 by -1 Bug #956183 [release.debian.org] transition: libwmf 956183 was blocked by: 956200 956199 956183 was not blocking any bugs. Added blocking bug(s) of 956183: 956201 -- 956183: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956183 956201: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956201 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#956183: transition: libwmf
Hi On Wed, 8 Apr 2020 at 07:06, Yangfl wrote: > libwmf is released with package split, and old-style config script > dropped with pkg-config file introduced. There are three packages > needing patches against `libwmf-config': > > wv > gimp > abiword Please file bugs against these packages and mark them blocking this bug (#956183). Regards Graham
Bug#954661: marked as done (transition: dpdk)
Your message dated Wed, 8 Apr 2020 11:29:26 +0200 with message-id <45dbaffb-008d-8489-01eb-4bc62a81c...@debian.org> and subject line Re: Bug#954661: transition: dpdk has caused the Debian Bug report #954661, regarding transition: dpdk to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 954661: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954661 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: z...@debian.org pkg-dpdk-de...@lists.alioth.debian.org Dear Release Team, The new DPDK 19.11 LTS is ready for unstable/testing, and we wish to begin the transition. It was already uploaded to experimental: https://tracker.debian.org/pkg/dpdk The reverse dependencies are collectd and openvswitch: https://tracker.debian.org/pkg/collectd https://tracker.debian.org/pkg/openvswitch Collectd rebuilds without any changes. Openvswitch needs a new version, 2.13, which Thomas already uploaded to experimental and that is ready for unstable. There's no auto-transition tracker for some reason, if I understand the obscure syntax it should be something like: Affected: .build-depends ~ /libdpdk-dev/ Good: .depends ~ /librte-eal20.0/ Bad: .depends ~ /librte-eal18.11/ Thank you! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part --- End Message --- --- Begin Message --- On 27/03/2020 14:27, Luca Boccassi wrote: > On Fri, 2020-03-27 at 13:32 +0100, Emilio Pozuelo Monfort wrote: >> Control: tags -1 confirmed >> >> On 22/03/2020 13:31, Luca Boccassi wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> X-Debbugs-CC: z...@debian.org >>> pkg-dpdk-de...@lists.alioth.debian.org >>> >>> Dear Release Team, >>> >>> The new DPDK 19.11 LTS is ready for unstable/testing, and we wish >>> to >>> begin the transition. It was already uploaded to experimental: >>> >>> https://tracker.debian.org/pkg/dpdk >>> >>> The reverse dependencies are collectd and openvswitch: >>> >>> https://tracker.debian.org/pkg/collectd >>> https://tracker.debian.org/pkg/openvswitch >>> >>> Collectd rebuilds without any changes. Openvswitch needs a new >>> version, >>> 2.13, which Thomas already uploaded to experimental and that is >>> ready >>> for unstable. >>> >>> There's no auto-transition tracker for some reason, if I understand >>> the >>> obscure syntax it should be something like: >>> >>> Affected: .build-depends ~ /libdpdk-dev/ >>> Good: .depends ~ /librte-eal20.0/ >>> Bad: .depends ~ /librte-eal18.11/ >> >> There's no automatic tracker because librte-eal18.11 has no reverse >> dependencies. collectd only recommends it (via shlibs:Recommends, so >> we can >> binNMU it) and I don't see openvswitch having any kind of dependency >> on >> librte-eal18.11. Am I missing something? >> >> In any case you can go ahead already. >> >> Cheers, >> Emilio > > Uploaded to sid. Thomas, please go ahead and upload the new version of > OVS once the builds are done. > > OVS doesn't link directly to the libraries, but dlopen() them (or > something along those lines). It depends on the generic dpdk binary > package which pulls in everything that is needed for that. dpdk has migrated to testing, and since there's no tracker for us to follow progress, I'll assume this is done and am closing the report. If something is still missing and needs action from us (e.g. some binNMUs), please let us know and will look at it. Cheers, Emilio--- End Message ---
Bug#954661: transition: dpdk
On Wed, 2020-04-08 at 11:29 +0200, Emilio Pozuelo Monfort wrote: > On 27/03/2020 14:27, Luca Boccassi wrote: > > On Fri, 2020-03-27 at 13:32 +0100, Emilio Pozuelo Monfort wrote: > > > Control: tags -1 confirmed > > > > > > On 22/03/2020 13:31, Luca Boccassi wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: transition > > > > X-Debbugs-CC: z...@debian.org > > > > pkg-dpdk-de...@lists.alioth.debian.org > > > > > > > > Dear Release Team, > > > > > > > > The new DPDK 19.11 LTS is ready for unstable/testing, and we > > > > wish > > > > to > > > > begin the transition. It was already uploaded to experimental: > > > > > > > > https://tracker.debian.org/pkg/dpdk > > > > > > > > The reverse dependencies are collectd and openvswitch: > > > > > > > > https://tracker.debian.org/pkg/collectd > > > > https://tracker.debian.org/pkg/openvswitch > > > > > > > > Collectd rebuilds without any changes. Openvswitch needs a new > > > > version, > > > > 2.13, which Thomas already uploaded to experimental and that is > > > > ready > > > > for unstable. > > > > > > > > There's no auto-transition tracker for some reason, if I > > > > understand > > > > the > > > > obscure syntax it should be something like: > > > > > > > > Affected: .build-depends ~ /libdpdk-dev/ > > > > Good: .depends ~ /librte-eal20.0/ > > > > Bad: .depends ~ /librte-eal18.11/ > > > > > > There's no automatic tracker because librte-eal18.11 has no > > > reverse > > > dependencies. collectd only recommends it (via shlibs:Recommends, > > > so > > > we can > > > binNMU it) and I don't see openvswitch having any kind of > > > dependency > > > on > > > librte-eal18.11. Am I missing something? > > > > > > In any case you can go ahead already. > > > > > > Cheers, > > > Emilio > > > > Uploaded to sid. Thomas, please go ahead and upload the new version > > of > > OVS once the builds are done. > > > > OVS doesn't link directly to the libraries, but dlopen() them (or > > something along those lines). It depends on the generic dpdk binary > > package which pulls in everything that is needed for that. > > dpdk has migrated to testing, and since there's no tracker for us to > follow > progress, I'll assume this is done and am closing the report. > > If something is still missing and needs action from us (e.g. some > binNMUs), > please let us know and will look at it. > > Cheers, > Emilio Both openvswitch and collectd had new source uploads shortly after the dpdk upload, and the resulting binaries linked with the new version have migrated to testing for both reverse dependencies, so we are indeed all good. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: 10.4 planning
> - April 25th > - May 2nd > - May 9th I can currently do any of the above for ftp-team. Thanks, Mark -- Mark Hymers
Bug#956195: buster-pu: package cloud-init/18.3-6+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-CC: debian-cl...@lists.debian.org Dear release team, As discussed in #947351, this is a more targeted fix prepared for buster-pu. The updated debdiff is attached. Regards, Aron cloud-init_18.3-6+deb10u1.debdiff Description: Binary data
Bug#947351: package cloud-init
On Wed, 2020-04-08 at 16:08 +0800, Aron Xu wrote: > After a brief discussion with zigo@d.o I'm trying to prepare a > stable-pu update of cloud-init to address Bug #936030. > > I'm reusing the previous release.d.o bug report for 18.3-6 which > wasn't closed, please let me know if opening a new one is preferred. If people still want to try and progress the larger update, with this as a more targetted fix in the meantime, then a separate bug for the smaller change would make more sense. I've not reviewed the patch in any detail, but one note: + * Non-maintaiiner upload for buster-pu "maintainer". Regards, Adam
Processed: your mail
Processing commands for cont...@bugs.debian.org: > tags 947351 + patch Bug #947351 [release.debian.org] buster-pu: package cloud-init/18.3-6 Added tag(s) patch. > End of message, stopping processing here. Please contact me if you need assistance. -- 947351: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947351 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#947351: package cloud-init
Control: retitile -1 buster-pu: package cloud-init/18.3-6+deb10u1 Control: tags + patch Hi, After a brief discussion with zigo@d.o I'm trying to prepare a stable-pu update of cloud-init to address Bug #936030. I'm reusing the previous release.d.o bug report for 18.3-6 which wasn't closed, please let me know if opening a new one is preferred. Regards, Aron cloud-init_18.3-6+deb10u1.debdiff Description: Binary data
