beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-26 01:20:25 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Userland/Services/ImageDecoder/ConnectionFromClient.cpp

76 lines
2.6 KiB
C++
Raw Normal View History

ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
*/
ImageDecoder: Add missing <AK/Debug.h> include and use dbgln_if()
2021-04-21 18:08:03 +00:00
#include <AK/Debug.h>
Userland: Rename IPC ClientConnection => ConnectionFromClient This was done with CLion's automatic rename feature and with: find . -name ClientConnection.h | rename 's/ClientConnection\.h/ConnectionFromClient.h/' find . -name ClientConnection.cpp | rename 's/ClientConnection\.cpp/ConnectionFromClient.cpp/'
2022-02-25 10:18:30 +00:00
#include <ImageDecoder/ConnectionFromClient.h>
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
#include <ImageDecoder/ImageDecoderClientEndpoint.h>
#include <LibGfx/Bitmap.h>
#include <LibGfx/ImageDecoder.h>
namespace ImageDecoder {
LibCore: Move Stream-based sockets into the `Core` namespace
2023-02-08 22:05:44 +00:00
ConnectionFromClient::ConnectionFromClient(NonnullOwnPtr<Core::LocalSocket> socket)
Userland: Rename IPC ClientConnection => ConnectionFromClient This was done with CLion's automatic rename feature and with: find . -name ClientConnection.h | rename 's/ClientConnection\.h/ConnectionFromClient.h/' find . -name ClientConnection.cpp | rename 's/ClientConnection\.cpp/ConnectionFromClient.cpp/'
2022-02-25 10:18:30 +00:00
: IPC::ConnectionFromClient<ImageDecoderClientEndpoint, ImageDecoderServerEndpoint>(*this, move(socket), 1)
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
{
}
Userland: Rename IPC ClientConnection => ConnectionFromClient This was done with CLion's automatic rename feature and with: find . -name ClientConnection.h | rename 's/ClientConnection\.h/ConnectionFromClient.h/' find . -name ClientConnection.cpp | rename 's/ClientConnection\.cpp/ConnectionFromClient.cpp/'
2022-02-25 10:18:30 +00:00
void ConnectionFromClient::die()
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
{
ImageDecoder: Remove unnecessary client map ImageDecoder processes only serve a single client, so we don't need to keep a map of them.
2021-11-29 16:12:55 +00:00
Core::EventLoop::current().quit(0);
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
}
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
static void decode_image_to_bitmaps_and_durations_with_decoder(Gfx::ImageDecoder const& decoder, Vector<Gfx::ShareableBitmap>& bitmaps, Vector<u32>& durations)
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
{
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
for (size_t i = 0; i < decoder.frame_count(); ++i) {
auto frame_or_error = decoder.frame(i);
if (frame_or_error.is_error()) {
bitmaps.append(Gfx::ShareableBitmap {});
durations.append(0);
} else {
auto frame = frame_or_error.release_value();
bitmaps.append(frame.image->to_shareable_bitmap());
durations.append(frame.duration);
}
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
}
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
}
LibGfx: Re-work the abstractions of sending image for decoding over IPC Originally I simply thought that passing file paths is quite OK, but as Linus pointed to, it turned out that passing file paths to ensure some files are able to be decoded is awkward because it does not work with images being served over HTTP. Therefore, ideally we should just use the MIME type as an optional argument to ensure that we can always fallback to use that in case sniffing for the correct image type has failed so we can still detect files like with the TGA format, which has no magic bytes.
2023-01-20 01:27:10 +00:00
static void decode_image_to_details(Core::AnonymousBuffer const& encoded_buffer, Optional<DeprecatedString> const& known_mime_type, bool& is_animated, u32& loop_count, Vector<Gfx::ShareableBitmap>& bitmaps, Vector<u32>& durations)
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
{
VERIFY(bitmaps.size() == 0);
VERIFY(durations.size() == 0);
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
LibGfx: Re-work the abstractions of sending image for decoding over IPC Originally I simply thought that passing file paths is quite OK, but as Linus pointed to, it turned out that passing file paths to ensure some files are able to be decoded is awkward because it does not work with images being served over HTTP. Therefore, ideally we should just use the MIME type as an optional argument to ensure that we can always fallback to use that in case sniffing for the correct image type has failed so we can still detect files like with the TGA format, which has no magic bytes.
2023-01-20 01:27:10 +00:00
auto decoder = Gfx::ImageDecoder::try_create_for_raw_bytes(ReadonlyBytes { encoded_buffer.data<u8>(), encoded_buffer.size() }, known_mime_type);
LibGfx: Improve ImageDecoder construction Previously, ImageDecoder::create() would return a NonnullRefPtr and could not "fail", although the returned decoder may be "invalid" which you then had to check anyway. The new interface looks like this: static RefPtr<Gfx::ImageDecoder> try_create(ReadonlyBytes); This simplifies ImageDecoder since it no longer has to worry about its validity. Client code gets slightly clearer as well.
2021-07-26 23:12:53 +00:00
if (!decoder) {
dbgln_if(IMAGE_DECODER_DEBUG, "Could not find suitable image decoder plugin for data");
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
return;
LibGfx: Improve ImageDecoder construction Previously, ImageDecoder::create() would return a NonnullRefPtr and could not "fail", although the returned decoder may be "invalid" which you then had to check anyway. The new interface looks like this: static RefPtr<Gfx::ImageDecoder> try_create(ReadonlyBytes); This simplifies ImageDecoder since it no longer has to worry about its validity. Client code gets slightly clearer as well.
2021-07-26 23:12:53 +00:00
}
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
ImageDecoder+LibImageDecoder+LibWeb: Support animations in ImageDecoder The ImageDecoder service now returns a list of image frames, each with a duration value. The code for in-process image decoding is removed from LibWeb, an all image decode requests are sent out-of-process to ImageDecoder. :^) This won't scale super well to very long and/or large animations, but we can work on improving that separately. The main goal here is simply to stop doing any image decoding inside LibWeb. Fixes #5165.
2021-01-29 21:30:48 +00:00
if (!decoder->frame_count()) {
ImageDecoder: Add missing <AK/Debug.h> include and use dbgln_if()
2021-04-21 18:08:03 +00:00
dbgln_if(IMAGE_DECODER_DEBUG, "Could not decode image from encoded data");
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
return;
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
}
ImageDecoder: Actually set `is_animated` and `loop_count` variables Before 649f78d0a4475a640ad353e1e879a7bb27db222b, the is_animated and loop_count objects were set directly when making a return object. That commit moved the decode logic to a separate function but forgot to assign `is_animated` and `loop_count`. The compiler didn't throw an error about unused variables because we were also VERIFY()ing that these variables were zero-initialized at the beginning of the function.
2023-01-22 10:58:36 +00:00
is_animated = decoder->is_animated();
loop_count = decoder->loop_count();
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
decode_image_to_bitmaps_and_durations_with_decoder(*decoder, bitmaps, durations);
}
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
LibGfx: Re-work the abstractions of sending image for decoding over IPC Originally I simply thought that passing file paths is quite OK, but as Linus pointed to, it turned out that passing file paths to ensure some files are able to be decoded is awkward because it does not work with images being served over HTTP. Therefore, ideally we should just use the MIME type as an optional argument to ensure that we can always fallback to use that in case sniffing for the correct image type has failed so we can still detect files like with the TGA format, which has no magic bytes.
2023-01-20 01:27:10 +00:00
Messages::ImageDecoderServer::DecodeImageResponse ConnectionFromClient::decode_image(Core::AnonymousBuffer const& encoded_buffer, Optional<DeprecatedString> const& mime_type)
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
{
if (!encoded_buffer.is_valid()) {
dbgln_if(IMAGE_DECODER_DEBUG, "Encoded data is invalid");
return nullptr;
ImageDecoder+LibImageDecoder+LibWeb: Support animations in ImageDecoder The ImageDecoder service now returns a list of image frames, each with a duration value. The code for in-process image decoding is removed from LibWeb, an all image decode requests are sent out-of-process to ImageDecoder. :^) This won't scale super well to very long and/or large animations, but we can work on improving that separately. The main goal here is simply to stop doing any image decoding inside LibWeb. Fixes #5165.
2021-01-29 21:30:48 +00:00
}
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
bool is_animated = false;
u32 loop_count = 0;
Vector<Gfx::ShareableBitmap> bitmaps;
Vector<u32> durations;
LibGfx: Re-work the abstractions of sending image for decoding over IPC Originally I simply thought that passing file paths is quite OK, but as Linus pointed to, it turned out that passing file paths to ensure some files are able to be decoded is awkward because it does not work with images being served over HTTP. Therefore, ideally we should just use the MIME type as an optional argument to ensure that we can always fallback to use that in case sniffing for the correct image type has failed so we can still detect files like with the TGA format, which has no magic bytes.
2023-01-20 01:27:10 +00:00
decode_image_to_details(encoded_buffer, mime_type, is_animated, loop_count, bitmaps, durations);
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
return { is_animated, loop_count, bitmaps, durations };
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 19:35:22 +00:00
}
}
Reference in a new issue Copy permalink