From 346b87d64ca7ccb1a19422ec0800639242678cec Mon Sep 17 00:00:00 2001 From: Martijn van Beurden Date: Wed, 5 Oct 2022 19:59:26 +0200 Subject: [PATCH 1/3] Add handling of picture metadata block As discussed on #xiph IRC --- flac.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/flac.md b/flac.md index 1bd9b8d..bab3379 100644 --- a/flac.md +++ b/flac.md @@ -397,17 +397,17 @@ For CD-DA, an track index point number of 0 corresponds to the track pre-gap. Th ## Picture -The picture metadata block contains image data of a picture in some way belonging to the audio contained in the FLAC file. Its format is derived from the APIC frame in the ID3v2 specification. However, contrary to the APIC frame in ID3v2, the MIME type and description are prepended with a 4-byte length field instead of being null delimited strings. A FLAC file MAY contain one or more picture metadata blocks. +The picture metadata block contains image data of a picture in some way belonging to the audio contained in the FLAC file. Its format is derived from the APIC frame in the ID3v2 specification. However, contrary to the APIC frame in ID3v2, the media type and description are prepended with a 4-byte length field instead of being null delimited strings. A FLAC file MAY contain one or more picture metadata blocks. -Note that while the length fields for MIME type, description and picture data are 4 bytes in length and could in theory code for a size up to 4 GiB, the total metadata block size cannot exceed what can be described by the metadata block header, i.e. 16 MiB. +Note that while the length fields for media type, description and picture data are 4 bytes in length and could in theory code for a size up to 4 GiB, the total metadata block size cannot exceed what can be described by the metadata block header, i.e. 16 MiB. The structure of a picture metadata block is enumerated in the following table. Data | Description :---------|:----------- `u(32)` | The picture type according to next table -`u(32)` | The length of the MIME type string in bytes. -`u(n*8)` | The MIME type string, in printable ASCII characters 0x20-0x7E. The MIME type MAY also be `-->` to signify that the data part is a URL of the picture instead of the picture data itself. +`u(32)` | The length of the media type string in bytes. +`u(n*8)` | The media type string, in printable ASCII characters 0x20-0x7E. The media type MAY also be `-->` to signify that the data part is a URI of the picture instead of the picture data itself. `u(32)` | The length of the description string in bytes. `u(n*8)` | The description of the picture, in UTF-8. `u(32)` | The width of the picture in pixels. @@ -417,6 +417,8 @@ Data | Description `u(32)` | The length of the picture data in bytes. `u(n*8)` | The binary picture data. +The height, width, colour depth and 'number of colours' fields are for informational purposes only. Applications MUST NOT use them in decoding the picture or deciding how to display them, but MAY use them to decide to process a block or not (e.g. when selecting between different pictures blocks) and MAY show them to the user. In case a picture format has no concept for any of these fields (e.g. vector images do not have a height or width in pixels) or the content of any field is unknown, the affected fields MUST be set to zero. + The following table contains all defined picture types. Values other than those listed in the table are reserved and SHOULD NOT be used. There MAY only be one each of picture type 1 and 2 in a file. In general practice, many FLAC playback devices and software display the contents of a picture metadata block with picture type 3 (front cover) during playback, if present. Value | Picture type @@ -443,6 +445,13 @@ Value | Picture type 19 | Band or artist logotype 20 | Publisher or studio logotype +In case not a picture but an URI is contained in this block, the following points apply: + +- In case an URI does not include a protocol specifier, the URI is considered relative to the FLAC file being processed. Such URIs are retrieved with the same protocol as the FLAC file being processed, if the protocol has a concept of relative URIs. +- Applications MUST obtain explicit user approval to retrieve images via remote protocols, or when retrieving a file that is not in the directory of the FLAC file being processed. +- Applications supporting linked images SHOULD handle unavailability of URIs gracefully. They MAY report unavailability to the user. +- Applications MAY reject processing linked images for any reason, in particular for security or privacy reasons. + # Frame structure Directly after the last metadata block, one or more frames follow. Each frame consists of a frame header, one or more subframes, padding zero bits to achieve byte-alignment and a frame footer. The number of subframes in each frame is equal to the number of audio channels. From e126435db6c2125729657cdb4fdfe43ce1a66585 Mon Sep 17 00:00:00 2001 From: Martijn van Beurden Date: Thu, 6 Oct 2022 19:03:15 +0200 Subject: [PATCH 2/3] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Jérôme Martinez --- flac.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/flac.md b/flac.md index bab3379..9f8a7ee 100644 --- a/flac.md +++ b/flac.md @@ -447,10 +447,10 @@ Value | Picture type In case not a picture but an URI is contained in this block, the following points apply: -- In case an URI does not include a protocol specifier, the URI is considered relative to the FLAC file being processed. Such URIs are retrieved with the same protocol as the FLAC file being processed, if the protocol has a concept of relative URIs. +- The URI can be either in absolute or in relative form. In case an URI is in relative form, it is related to the URI of the FLAC content processed. - Applications MUST obtain explicit user approval to retrieve images via remote protocols, or when retrieving a file that is not in the directory of the FLAC file being processed. -- Applications supporting linked images SHOULD handle unavailability of URIs gracefully. They MAY report unavailability to the user. -- Applications MAY reject processing linked images for any reason, in particular for security or privacy reasons. +- Applications supporting linked images MUST handle unavailability of URIs gracefully. They MAY report unavailability to the user. +- Applications MAY reject processing URIs for any reason, in particular for security or privacy reasons. # Frame structure From 6f41d83696c35572b8054e4ff3a0d568bb4c2724 Mon Sep 17 00:00:00 2001 From: Martijn van Beurden Date: Thu, 6 Oct 2022 19:15:48 +0200 Subject: [PATCH 3/3] Apply suggestions from #xiph IRC --- flac.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/flac.md b/flac.md index 9f8a7ee..e6de593 100644 --- a/flac.md +++ b/flac.md @@ -417,7 +417,7 @@ Data | Description `u(32)` | The length of the picture data in bytes. `u(n*8)` | The binary picture data. -The height, width, colour depth and 'number of colours' fields are for informational purposes only. Applications MUST NOT use them in decoding the picture or deciding how to display them, but MAY use them to decide to process a block or not (e.g. when selecting between different pictures blocks) and MAY show them to the user. In case a picture format has no concept for any of these fields (e.g. vector images do not have a height or width in pixels) or the content of any field is unknown, the affected fields MUST be set to zero. +The height, width, color depth and 'number of colors' fields are for informational purposes only. Applications MUST NOT use them in decoding the picture or deciding how to display it, but MAY use them to decide to process a block or not (e.g. when selecting between different pictures blocks) and MAY show them to the user. In case a picture has no concept for any of these fields (e.g. vector images may not have a height or width in pixels) or the content of any field is unknown, the affected fields MUST be set to zero. The following table contains all defined picture types. Values other than those listed in the table are reserved and SHOULD NOT be used. There MAY only be one each of picture type 1 and 2 in a file. In general practice, many FLAC playback devices and software display the contents of a picture metadata block with picture type 3 (front cover) during playback, if present. @@ -445,10 +445,10 @@ Value | Picture type 19 | Band or artist logotype 20 | Publisher or studio logotype -In case not a picture but an URI is contained in this block, the following points apply: +In case not a picture but a URI is contained in this block, the following points apply: - The URI can be either in absolute or in relative form. In case an URI is in relative form, it is related to the URI of the FLAC content processed. -- Applications MUST obtain explicit user approval to retrieve images via remote protocols, or when retrieving a file that is not in the directory of the FLAC file being processed. +- Applications MUST obtain explicit user approval to retrieve images via remote protocols and to retrieve local images not located in the same directory as the FLAC file being processed. - Applications supporting linked images MUST handle unavailability of URIs gracefully. They MAY report unavailability to the user. - Applications MAY reject processing URIs for any reason, in particular for security or privacy reasons. @@ -740,6 +740,8 @@ When metadata is handled, it is RECOMMENDED to either thoroughly test handling o Various kinds of metadata blocks contain length fields or fields counts. While reading a block following these lengths or counts, a decoder MUST make sure higher-level lengths or counts (most importantly the length field of the metadata block itself) are not exceeded. As some of these length fields code string lengths, memory for which must be allocated, it is RECOMMENDED to first verify that a block is valid before allocating memory based on its contents. +Metadata blocks can also contain references, e.g. the picture metadata block can contain a URI. Applications MUST obtain explicit user approval to retrieve resources via remote protocols and to retrieve local resources not located in the same directory as the FLAC file being processed. + Seeking in a FLAC stream that is not in a container relies on the coded number in frame headers and optionally a seektable metadata block. It is RECOMMENDED to employ thorough sanity checks on whether a found coded number or seekpoint is at all possible. Without these checks, seeking might get stuck in an infinite loop when numbers in frames are non-consecutive or otherwise invalid, which could be used in denial of service attacks. It is RECOMMENDED to employ fuzz testing combined with different sanitizers on FLAC decoders to find security problems. To improve efficiency of this process, a decoder SHOULD, on decoding, ignore the results of CRC checks during fuzz testing.