libgsf issues
https://gitlab.gnome.org/GNOME/libgsf/-/issues
2023-07-15T02:35:38Z
https://gitlab.gnome.org/GNOME/libgsf/-/issues/31
Using gsf_doc_meta_data_write_to_msole with corrupt file doesn't report errors
2023-07-15T02:35:38Z
Geoffrey Campbell
Using gsf_doc_meta_data_write_to_msole with corrupt file doesn't report errors
If you try to add metadata to a corrupt document with gsf_doc_meta_data_write_to_msole, the file that gets written does not have metadata. Additionally, gsf doesn't report any errors and gsf_doc_meta_data_write_to_msole returns true, ind...
If you try to add metadata to a corrupt document with gsf_doc_meta_data_write_to_msole, the file that gets written does not have metadata. Additionally, gsf doesn't report any errors and gsf_doc_meta_data_write_to_msole returns true, indicating the call succeeded, even though there's no metadata on the doc. Additionally, when you call gsf_doc_meta_data_read_from_msole to get the metadata, that call also reports success but this line does appear in the logs: msole_prop_read: assertion 'len < 0x10000' failed
https://gitlab.gnome.org/GNOME/libgsf/-/issues/30
"at_scale_size_prepared_cb: assertion 'width > 0 && height > 0' failed" on so...
2023-04-23T12:27:44Z
Daniel Rusek
"at_scale_size_prepared_cb: assertion 'width > 0 && height > 0' failed" on some document files
Fedora 38, nautilus-44.0-1.fc38.x86_64, libgsf-1.14.50-1.fc38.x86_64.
When gsf-office-thumbnailer generates thumbnails, it returns this failed assertion on some of my document (ppt) files although all the files seem to be correct:
```
...
Fedora 38, nautilus-44.0-1.fc38.x86_64, libgsf-1.14.50-1.fc38.x86_64.
When gsf-office-thumbnailer generates thumbnails, it returns this failed assertion on some of my document (ppt) files although all the files seem to be correct:
```
(gsf-office-thumbnailer:14711): GdkPixbuf-CRITICAL **: 12:27:28.933: at_scale_size_prepared_cb: assertion 'width > 0 && height > 0' failed
(gsf-office-thumbnailer:14711): GLib-GObject-CRITICAL **: 12:27:28.933: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
```
Also, the generated thumbnail looks broken:
![thumbnail](/uploads/d060b276bda476256a2ae8b63342fb25/thumbnail.png)
(But that may be a different problem since it happens only in some cases.)
[Here](/uploads/2b321fe1f2d7ccd3008749f721e3c6c8/fm.ppt) is one of the files as an example.
https://gitlab.gnome.org/GNOME/libgsf/-/issues/29
gsf-office-thumbnailer crashes on specific ppt file
2023-04-22T16:57:50Z
Daniel Rusek
gsf-office-thumbnailer crashes on specific ppt file
Fedora 38, nautilus-44.0-1.fc38.x86_64, libgsf-1.14.50-1.fc38.x86_64.
Browsing a directory with with thousands of photos, videos, ppt/pdf and other multimedia/document files often causes gsf-office-thumbnailer to crash in `g_type_check_...
Fedora 38, nautilus-44.0-1.fc38.x86_64, libgsf-1.14.50-1.fc38.x86_64.
Browsing a directory with with thousands of photos, videos, ppt/pdf and other multimedia/document files often causes gsf-office-thumbnailer to crash in `g_type_check_instance_is_fundamentally_a()`. However, although this happens a lot, it happens very randomly.
Here is a stack trace of the crash from systemd-coredump:
```
dub 16 14:31:39 desktop systemd-coredump[33268]: [🡕] Process 33265 (gsf-office-thum) of user 1000 dumped core.
Module libblkid.so.1 from rpm util-linux-2.38.1-4.fc38.x86_64
Module liblzma.so.5 from rpm xz-5.4.1-1.fc38.x86_64
Module libselinux.so.1 from rpm libselinux-3.5-1.fc38.x86_64
Module libmount.so.1 from rpm util-linux-2.38.1-4.fc38.x86_64
Module libpcre2-8.so.0 from rpm pcre2-10.42-1.fc38.1.x86_64
Module libffi.so.8 from rpm libffi-3.4.4-2.fc38.x86_64
Module libjpeg.so.62 from rpm libjpeg-turbo-2.1.4-2.fc38.x86_64
Module libpng16.so.16 from rpm libpng-1.6.37-14.fc38.x86_64
Module libgmodule-2.0.so.0 from rpm glib2-2.76.1-1.fc38.x86_64
Module libbz2.so.1 from rpm bzip2-1.0.8-13.fc38.x86_64
Module libz.so.1 from rpm zlib-1.2.13-3.fc38.x86_64
Module libxml2.so.2 from rpm libxml2-2.10.3-3.fc38.x86_64
Module libgio-2.0.so.0 from rpm glib2-2.76.1-1.fc38.x86_64
Module libglib-2.0.so.0 from rpm glib2-2.76.1-1.fc38.x86_64
Module libgobject-2.0.so.0 from rpm glib2-2.76.1-1.fc38.x86_64
Module libgdk_pixbuf-2.0.so.0 from rpm gdk-pixbuf2-2.42.10-2.fc38.x86_64
Module libgsf-1.so.114 from rpm libgsf-1.14.50-1.fc38.x86_64
Module gsf-office-thumbnailer from rpm libgsf-1.14.50-1.fc38.x86_64
Stack trace of thread 2:
#0 0x00007fe8f9e03bf1 g_type_check_instance_is_fundamentally_a (libgobject-2.0.so.0 + 0x39bf1)
#1 0x00007fe8f9dec9c2 g_object_unref (libgobject-2.0.so.0 + 0x229c2)
#2 0x00007fe8f9e089c8 g_value_unset (libgobject-2.0.so.0 + 0x3e9c8)
#3 0x00007fe8f9e6b3cf gsf_doc_prop_free (libgsf-1.so.114 + 0x133cf)
#4 0x00007fe8f9cc8d9a g_hash_table_remove_all_nodes.part.0.lto_priv.0 (libglib-2.0.so.0 + 0x47d9a)
#5 0x00007fe8f9cca1e0 g_hash_table_remove_all (libglib-2.0.so.0 + 0x491e0)
#6 0x00007fe8f9cc8a8a g_hash_table_destroy (libglib-2.0.so.0 + 0x47a8a)
#7 0x00007fe8f9e6c059 gsf_doc_meta_data_finalize (libgsf-1.so.114 + 0x14059)
#8 0x00007fe8f9decbca g_object_unref (libgobject-2.0.so.0 + 0x22bca)
#9 0x000055b05a61b820 main (gsf-office-thumbnailer + 0x2820)
#10 0x00007fe8f9ac9b4a __libc_start_call_main (libc.so.6 + 0x27b4a)
#11 0x00007fe8f9ac9c0b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x27c0b)
#12 0x000055b05a61ba35 _start (gsf-office-thumbnailer + 0x2a35)
ELF object binary architecture: AMD x86-64
```
https://gitlab.gnome.org/GNOME/libgsf/-/issues/28
Licensing question: would an addition of the LGPL "any later version" clause ...
2023-03-02T01:54:04Z
Lovell Fuller
Licensing question: would an addition of the LGPL "any later version" clause ("LGPL-2.1-or-later") be considered?
Hello, firstly thank you for all the time and effort that goes into libgsf. I help maintain libvips and it is invaluable for us when generating image pyramids. Many of those Deep Zoom images you see on the web were created by libgsf.
In...
Hello, firstly thank you for all the time and effort that goes into libgsf. I help maintain libvips and it is invaluable for us when generating image pyramids. Many of those Deep Zoom images you see on the web were created by libgsf.
In March 2003, almost 20 years ago, libgsf was re-licensed from GPL v2 to LGPL v2.1.
https://mail.gnome.org/archives/gnumeric-list/2003-May/msg00024.html
It looks like this did not include the "any later version" clause, so I think this makes libgsf currently "LGPL-2.1-only" and therefore a bit of an outlier in the GNOME ecosystem where "LGPL-2.1-or-later" is more common.
Do we know if the lack of the "any later version" clause was intentional, or a mistake, or perhaps something else?
Would there be any interest by the maintainers to add the "any later version" to the source headers to allow for wider compatibility and consistency with other GNOME projects? Permission from all contributors might be necessary, which could be an onerous task.
By preventing the use of (L)GPL v3, libgsf is incompatible with a few other open source licences, primarily GPL-3.0-only, GPL-3.0-or-later, Apache-2.0, BSD-4-Clause and FTL (Freetype). My understanding is that this can prevent the the libgsf shared library being used by a process also using other shared libraries with incompatible licences. For example, curl is partly BSD-4-Clause so software that uses both it and libgsf in the same process may be affected.
As an aside, I took a quick look at various package managers to see how the libgsf licence is currently reported.
* The SPDX licence identifier in the Debian Linux builds is "LGPL-2.1", which doesn't map to a currently-valid value.
https://gitlab.gnome.org/GNOME/libgsf/-/blob/master/debian/copyright#L19
* Fedora Linux has "LGPLv2", with no mention of v2.1.
https://src.fedoraproject.org/rpms/libgsf/blob/rawhide/f/libgsf.spec#_5
* Homebrew confusingly states both "GPL-2.0-or-later" and "LGPL-2.1-only" apply.
https://github.com/Homebrew/homebrew-core/blob/2d11c0ec532057c5ada218a57d086efaa3382a05/Formula/libgsf.rb#L6
* Alpine Linux uses "LGPL-2.1-only".
https://github.com/alpinelinux/aports/blob/d27e4f249ea22c75978a8c834fdb5b458e6c3b91/community/libgsf/APKBUILD#L8
Thank you.
https://gitlab.gnome.org/GNOME/libgsf/-/issues/27
Infinite loop in gsf_outfile_msole_close_root
2022-07-15T18:39:24Z
k-bren
Infinite loop in gsf_outfile_msole_close_root
The recalc_bat_bat goto loop will never exit in certain circumstances. If a failure occurs when calling gsf_output_write or gsf_output_close (Returns false) it can hit this issue.
The recalc_bat_bat goto loop will never exit in certain circumstances. If a failure occurs when calling gsf_output_write or gsf_output_close (Returns false) it can hit this issue.
https://gitlab.gnome.org/GNOME/libgsf/-/issues/26
ole file is overriden with single stream
2022-02-25T07:46:53Z
Sagi Lowenhardt
ole file is overriden with single stream
I'm trying to create a sample app for reproducing one of the open issues.
As the file is closed, its content are replaced by the SummaryInfo stream I've created although I'd expect the file content to stay the same except for this stre...
I'm trying to create a sample app for reproducing one of the open issues.
As the file is closed, its content are replaced by the SummaryInfo stream I've created although I'd expect the file content to stay the same except for this stream.
The `file.doc` is a valid ole (compound file)..
Code:
```c++
#include <cassert>
#include <stdio.h>
#include <iostream>
#include "gsf/gsf-output-stdio.h"
#include "gsf/gsf-outfile.h"
#include "gsf/gsf-doc-meta-data.h"
#include "gsf/gsf-msole-utils.h"
#include "gsf/gsf-utils.h"
#include "gsf/gsf-input-stdio.h"
#include "gsf/gsf-infile.h"
#include "libgsf/include/glib/gmacros.h"
#include "gsf/gsf-output-impl.h"
#include <gsf/gsf-outfile-msole.h>
const std::string GSF_META_NAME_TITLE = "dc:title";
const std::string GSF_META_NAME_SUBJECT = "dc:subject";
void updateProperties(GsfOutput* output) {
auto newSummaryInfo = gsf_doc_meta_data_new();
const std::string titleValueStr = "× ×¡×™×•×Ÿ";
auto titleValue = g_new0(GValue, 1);
g_value_init(titleValue, G_TYPE_STRING);
g_value_set_string(titleValue, titleValueStr.c_str());
gsf_doc_meta_data_insert(newSummaryInfo, g_strdup(GSF_META_NAME_TITLE.c_str()), titleValue);
const std::string subjectValueStr = "subject";
auto subjectValue = g_new0(GValue, 1);
g_value_init(subjectValue, G_TYPE_STRING);
g_value_set_string(subjectValue, subjectValueStr.c_str());
gsf_doc_meta_data_insert(newSummaryInfo, g_strdup(GSF_META_NAME_SUBJECT.c_str()), subjectValue);
const auto success = gsf_doc_meta_data_write_to_msole(newSummaryInfo, output, false);
assert(success == true);
g_object_unref(G_OBJECT(newSummaryInfo));
}
int main(int argc, char* argv[])
{
gsf_init();
GError* error = g_error_new(1, 0, "");
g_clear_error(&error);
const std::string filePath = "file.doc";
auto storage = gsf_output_stdio_new(filePath.c_str(), &error);
assert(storage != nullptr);
auto oleStorage = gsf_outfile_msole_new(storage);
gsf_output_set_name(GSF_OUTPUT(oleStorage), "Root");
assert(oleStorage != nullptr);
try {
const std::string streamName = "\05SummaryInformation";
auto summaryStream = gsf_outfile_new_child(GSF_OUTFILE(oleStorage), streamName.c_str(), false);
assert(summaryStream != nullptr);
updateProperties(summaryStream);
gsf_output_close(summaryStream);
g_object_unref(G_OBJECT(summaryStream));
gsf_output_close(GSF_OUTPUT(oleStorage));
g_object_unref(G_OBJECT(oleStorage));
}
catch (const std::exception& ex) {
std::cout << ex.what() << std::endl;
}
}
```
https://gitlab.gnome.org/GNOME/libgsf/-/issues/25
Zip64 archives are corrupted?
2021-12-05T20:08:56Z
Sagi Lowenhardt
Zip64 archives are corrupted?
I'm still trying to figure this one out but it looks like zip archives which are over 4gb (ZIP64) are created corrupted.
I've tried to clone an existing large archive to a new one and it came corrupted too
Looking on the header of th...
I'm still trying to figure this one out but it looks like zip archives which are over 4gb (ZIP64) are created corrupted.
I've tried to clone an existing large archive to a new one and it came corrupted too
Looking on the header of the first entry, it looks like the difference starts in the `frExtraField` field
The left is the original zip, the right is the cloned using `libgsf`, we can see the `frExtraField` was split to an array and the value has changed from `EH_WinGrowth` to `EH_extTimestamp` (in the array 2nd cell)
![image](/uploads/d3c49fc1e457a75b9424a6fa7a8a8188/image.png)
I was thinking this is related to the `zip64` property set on the `GsfOutfileZip` file as it's set to `-1` (as expected) and maybe not detecting the ZIP64 in a proper way?
I wasn't able to find how this property can be set to explicitly set the output file as zip64.
The zip creation uses the following api's:
1. `output = gsf_output_stream_new(outputStream)`
2. `outfile = gsf_outfile_zip_new(output)`
3. Copying entries from the source zip to the target zip using `gsf_input_copy`
```
void CloneDirEntry(
const shared_ptr<MipContext>& mipContext,
GsfInfile* input,
GsfOutfile* output,
const string& path,
map<string, vector<uint8_t>>& entries) {
int n = gsf_infile_num_children(input);
for (int i = 0; i < n; i++) {
int level;
gboolean is_dir;
char const* name = gsf_infile_name_by_index(input, i);
unique_ptr<GsfInfile, GsfInfile_deleter> child(GSF_INFILE(gsf_infile_child_by_index(input, i)));
if (!child) {
auto msg = "Failed to get entry from zip, not continuing to copy so the zip will be corrupted";
SET_EVENT_ERROR_PROPERTIES(mipContext->GetRawTelemetryManager(), msg);
throw ZipException(msg);
}
is_dir = gsf_infile_num_children(child.get()) >= 0;
g_object_get(G_OBJECT(child.get()), "compression-level", &level, nullptr);
int zip64;
unique_ptr<GsfOutfile, GsfOutfile_deleter> outputPtr(GSF_OUTFILE(
gsf_outfile_new_child_full(output, name, is_dir, "compression-level", level, nullptr)));
string newPath(path);
if (!newPath.empty())
newPath.append("/");
newPath.append(name);
Clone(mipContext, child.get(), outputPtr.get(), newPath, entries);
}
}
```
My assumption that here we are missing a call to something like `g_object_get(G_OBJECT(child.get()), "zip64", &zip64, nullptr);` and later passing this as part of the `gsf_outfile_new_child_full` args.
When I tried adding `g_object_get(G_OBJECT(child.get()), "zip64", &zip64, nullptr);`, the `zip64` was never set property, in addition, I've tried creating the new stream with `zip64` set to `1` but the result is the same:
```
unique_ptr<GsfOutfile, GsfOutfile_deleter> outputPtr(
GSF_OUTFILE(gsf_outfile_new_child_full(output, name, is_dir, "compression-level", level, "zip64", 1, nullptr)));
```
Is there any example for how a ZIP64 should be created/cloned using gsf?
https://gitlab.gnome.org/GNOME/libgsf/-/issues/24
How to close fd created by Gsf.InfileMSOle / Gsf.InputStdio
2021-10-06T09:36:07Z
Amit Aggarwal
How to close fd created by Gsf.InfileMSOle / Gsf.InputStdio
Observing fd leak as Gsf.InfileMSOle / Gsf.InputStdio has no close method.
Creating the object in the following manner -
```
_gsf_inputstdio = Gsf.InputStdio.new(file_path)
_gsf_infilemsole = Gsf.InfileMSOle.new(_gsf_inputstdio)
```
A...
Observing fd leak as Gsf.InfileMSOle / Gsf.InputStdio has no close method.
Creating the object in the following manner -
```
_gsf_inputstdio = Gsf.InputStdio.new(file_path)
_gsf_infilemsole = Gsf.InfileMSOle.new(_gsf_inputstdio)
```
Any help is appreciated.
https://gitlab.gnome.org/GNOME/libgsf/-/issues/23
thumbnailing for .docx and .doc does not work.
2020-09-03T18:46:05Z
Hussam Al-Tayeb
thumbnailing for .docx and .doc does not work.
The thumbnailer file claims it supports those files but:
$gsf-office-thumbnailer -i Document1.docx -o aaa.png -s 128
error: Could not find thumbnail in zip file
This happens both with files created using MS Office online and libreoffice.
The thumbnailer file claims it supports those files but:
$gsf-office-thumbnailer -i Document1.docx -o aaa.png -s 128
error: Could not find thumbnail in zip file
This happens both with files created using MS Office online and libreoffice.
https://gitlab.gnome.org/GNOME/libgsf/-/issues/22
libgsf MinGW compilation emits PE that triggers security scan
2020-07-18T03:03:01Z
Michael C. Fanning
libgsf MinGW compilation emits PE that triggers security scan
The libgsf MinGW cross-compilation is flagged by tools such as https://github.com/microsoft/binskim due to apparently not enabled safe execption handlers, DEP and ASLR security options. Any thoughts on how to create a more secure compila...
The libgsf MinGW cross-compilation is flagged by tools such as https://github.com/microsoft/binskim due to apparently not enabled safe execption handlers, DEP and ASLR security options. Any thoughts on how to create a more secure compilation?
https://gitlab.gnome.org/GNOME/libgsf/-/issues/21
MinGW build errors
2020-05-03T01:26:27Z
Greg Hellings
MinGW build errors
Introduction of the explicit exported symbols has caused MinGW build errors a link time:
```
/bin/sh ../libtool --tag=CC --mode=link i686-w64-mingw32-gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-siz...
Introduction of the explicit exported symbols has caused MinGW build errors a link time:
```
/bin/sh ../libtool --tag=CC --mode=link i686-w64-mingw32-gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -Wall -Werror=init-self -Werror=missing-include-dirs -Wsign-compare -Werror=pointer-arith -Wchar-subscripts -Wwrite-strings -Wdeclaration-after-statement -Wnested-externs -Wmissing-noreturn -Werror=missing-prototypes -Werror=nested-externs -Werror=implicit-function-declaration -Wmissing-declarations -Wno-pointer-sign -Werror=format-security -Wstrict-prototypes -Wno-error=format-nonliteral -D_BSD_SOURCE -version-info 114:47:0 -export-symbols ../../gsf/libgsf.syms -no-undefined -export-symbols lib.def -no-undefined -o libgsf-1.la -rpath /usr/i686-w64-mingw32/sys-root/mingw/lib gsf-utils.lo gsf-priv.lo gsf-libxml.lo gsf-doc-meta-data.lo gsf-docprop-vector.lo gsf-msole-utils.lo gsf-open-pkg-utils.lo gsf-opendoc-utils.lo gsf-timestamp.lo gsf-zip-utils.lo gsf-input.lo gsf-input-bzip.lo gsf-input-gzip.lo gsf-input-http.lo gsf-input-iochannel.lo gsf-input-memory.lo gsf-input-proxy.lo gsf-input-stdio.lo gsf-input-textline.lo gsf-infile.lo gsf-infile-msole.lo gsf-infile-msvba.lo gsf-infile-stdio.lo gsf-infile-tar.lo gsf-infile-zip.lo gsf-output.lo gsf-output-bzip.lo gsf-output-csv.lo gsf-output-gzip.lo gsf-output-iconv.lo gsf-output-iochannel.lo gsf-output-memory.lo gsf-output-stdio.lo gsf-outfile.lo gsf-outfile-msole.lo gsf-outfile-stdio.lo gsf-outfile-zip.lo gsf-shared-memory.lo gsf-structured-blob.lo gsf-blob.lo gsf-clip-data.lo gsf-input-gio.lo gsf-output-gio.lo version.lo -L/usr/i686-w64-mingw32/sys-root/mingw/lib -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lxml2 -lz -lbz2
libtool: error: more than one -exported-symbols argument is not allowed
```
https://gitlab.gnome.org/GNOME/libgsf/-/issues/20
gsf_input_mmap_new introspection issue
2020-07-18T08:05:40Z
Marc-André Lureau
gsf_input_mmap_new introspection issue
GIR recognize it has being constructor of GsfInput, which is abstract. So we have warnings in GIR/vala etc:
Gsf-1.gir:2141.7-2143.21: warning: Creation method of abstract class cannot be public.
I can't find a way to annotate the symbo...
GIR recognize it has being constructor of GsfInput, which is abstract. So we have warnings in GIR/vala etc:
Gsf-1.gir:2141.7-2143.21: warning: Creation method of abstract class cannot be public.
I can't find a way to annotate the symbol to move it under the GsfInputMemory class.
Other solutions I can think of would break API.
https://gitlab.gnome.org/GNOME/libgsf/-/issues/19
NULL dereference in datetime_from_filetime at gsf-infile-msole.c:292
2020-03-01T13:39:47Z
Anatoly Trosinenko
NULL dereference in datetime_from_filetime at gsf-infile-msole.c:292
The `gsf-office-thumbnailer` crashes on NULL dereference when processing the attached fuzzed file.
## How to reproduce
```
$ git clone https://gitlab.gnome.org/GNOME/libgsf.git # commit 9e5266c1d
$ cd libgsf
$ ./autogen.sh
$ ./configur...
The `gsf-office-thumbnailer` crashes on NULL dereference when processing the attached fuzzed file.
## How to reproduce
```
$ git clone https://gitlab.gnome.org/GNOME/libgsf.git # commit 9e5266c1d
$ cd libgsf
$ ./autogen.sh
$ ./configure CFLAGS="-O0 -ggdb3" --disable-shared
$ make
$ ./thumbnailer/gsf-office-thumbnailer -s 32 -o /dev/null -i /tmp/office-thumbnailer-null.bin
(gsf-office-thumbnailer:9000): libgsf:msole-WARNING **: 13:47:46.604: There are not supposed to be any blocks in the small block allocation table, yet there is a link to some. Ignoring it.
Segmentation fault
$ strace -e none -e signal=SIGSEGV -k ./thumbnailer/gsf-office-thumbnailer -s 32 -o /dev/null -i /tmp/office-thumbnailer-null.bin
(gsf-office-thumbnailer:9005): libgsf:msole-WARNING **: 13:48:15.048: There are not supposed to be any blocks in the small block allocation table, yet there is a link to some. Ignoring it.
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.1(g_date_time_add+0x10) [0x372d0]
> /tmp/libgsf/thumbnailer/gsf-office-thumbnailer(datetime_from_filetime+0x9d) [0x21d91]
> /tmp/libgsf/thumbnailer/gsf-office-thumbnailer(ole_dirent_new+0x338) [0x220df]
> /tmp/libgsf/thumbnailer/gsf-office-thumbnailer(ole_init_info+0x935) [0x23156]
> /tmp/libgsf/thumbnailer/gsf-office-thumbnailer(gsf_infile_msole_new+0x111) [0x2407c]
> /tmp/libgsf/thumbnailer/gsf-office-thumbnailer(read_thumbnail_and_write+0x9f) [0xbfc6]
> /tmp/libgsf/thumbnailer/gsf-office-thumbnailer(main+0x103) [0xc1d1]
> /lib/x86_64-linux-gnu/libc-2.30.so(__libc_start_main+0xf3) [0x271e3]
> /tmp/libgsf/thumbnailer/gsf-office-thumbnailer(_start+0x2e) [0xb83e]
+++ killed by SIGSEGV +++
Segmentation fault
```
The warning seems to be introduced by minimization and is most probably unrelated.
## Analysis
```
$ gdb -q --args ./thumbnailer/gsf-office-thumbnailer -s 32 -o /dev/null -i /tmp/office-thumbnailer-null.bin
Reading symbols from ./thumbnailer/gsf-office-thumbnailer...
(gdb) r
Starting program: /tmp/libgsf/thumbnailer/gsf-office-thumbnailer -s 32 -o /dev/null -i /tmp/office-thumbnailer-null.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
(gsf-office-thumbnailer:9010): libgsf:msole-WARNING **: 13:48:32.700: There are not supposed to be any blocks in the small block allocation table, yet there is a link to some. Ignoring it.
Program received signal SIGSEGV, Segmentation fault.
g_date_time_add (datetime=0x0, timespan=768030) at ../../../glib/gdatetime.c:1705
1705 ../../../glib/gdatetime.c: No such file or directory.
(gdb) up
#1 0x0000555555575d91 in datetime_from_filetime (ft=3472328296227680304) at gsf-infile-msole.c:292
292 res = g_date_time_add (dt, (ft % 10000000u) / 10);
(gdb) p dt
$1 = (GDateTime *) 0x0
(gdb) p/x ft
$2 = 0x3030303030303030
```
Looks like fuzzer have corrupted some time field, so that `g_date_time_new_from_unix_local` returns `NULL`, and the [`datetime_from_filetime`](https://gitlab.gnome.org/GNOME/libgsf/blob/9e5266c1dbec430d0f441249b1765442ab3b0a65/gsf/gsf-infile-msole.c#L292) does not handle that case correctly. I have GLib 2.62.1-1 on my Ubuntu system. According to **current** master branch sources, it returns `NULL` implicitly when
```cpp
if (t > G_MAXINT64 / USEC_PER_SECOND)
return NULL;
```
and this seems to be the case here.
[office-thumbnailer-null.bin](/uploads/ae6cb8472863463385160adec702aef0/office-thumbnailer-null.bin)
https://gitlab.gnome.org/GNOME/libgsf/-/issues/18
building a conda-forge package
2019-08-14T16:24:02Z
Ghost User
building a conda-forge package
Hi,
I would like to build a conda-forge package for libgsf.
To build from source, I am grabbing release version 1.14.46 from github and doing:
```
./autogen.sh
```
However, I bump into:
```
automake: error: cannot open < gtk-doc.make:...
Hi,
I would like to build a conda-forge package for libgsf.
To build from source, I am grabbing release version 1.14.46 from github and doing:
```
./autogen.sh
```
However, I bump into:
```
automake: error: cannot open < gtk-doc.make: No such file or directory
autoreconf: automake failed with exit status: 1
```
`gtk-doc` is not available as a conda package. Is there a way I can build libgsf without `gtk-doc` as a dependency?
Sorry this might be a silly question!
Best regards,
Sebastian.
https://gitlab.gnome.org/GNOME/libgsf/-/issues/17
Non English characters issue
2022-02-28T19:30:25Z
Ghost User
Non English characters issue
I think it's a libgsf issue, after writing non-English metadata properties to file the properties are shown as empty strings.
**Flow:**
1. Writing non-English (and not empty) characters using - gsf_doc_meta_data_insert
2. gsf_doc_meta_d...
I think it's a libgsf issue, after writing non-English metadata properties to file the properties are shown as empty strings.
**Flow:**
1. Writing non-English (and not empty) characters using - gsf_doc_meta_data_insert
2. gsf_doc_meta_data_write_to_msole
3. gsf_output_close
When opening the file (word for example) the properties are empty strings.
**Before (Hebrew):**
![image](/uploads/59a2218c419eeba329704426c02f779d/image.png)
**After:**
![image](/uploads/7130a430dac69d57abd8fec68c2cf1c0/image.png)
Thank you!
Tali
https://gitlab.gnome.org/GNOME/libgsf/-/issues/16
1.14.44: check fails
2019-09-01T22:48:01Z
Tomasz KÅ‚oczko
1.14.44: check fails
Looks like two valgrir test are failing
<pre>FAIL: t8000-valgrind-zip.pl
make[3]: Leaving directory &apos;/home/tkloczko/rpmbuild/BUILD/libgsf-1.14.45/tests&apos;
make[3]: Entering directory &apos;/home/tkloczko/rpmbuild/BUILD/libgsf-1.1...
Looks like two valgrir test are failing
<pre>FAIL: t8000-valgrind-zip.pl
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libgsf-1.14.45/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libgsf-1.14.45/tests'
FAIL: t8020-valgrind-ole.pl
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libgsf-1.14.45/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libgsf-1.14.45/tests'
PASS: t9999-epilogue.pl
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libgsf-1.14.45/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libgsf-1.14.45/tests'
============================================================================
Testsuite summary for libgsf 1.14.45
============================================================================
# TOTAL: 9
# PASS: 7
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
Please report to https://gitlab.gnome.org/GNOME/libgsf/issues
============================================================================
</pre>
[test-suite.log](/uploads/9969d493a72328a61f9e86edd762a469/test-suite.log)
https://gitlab.gnome.org/GNOME/libgsf/-/issues/15
gsf-vba-dump crashes after reporting errors
2019-02-04T17:39:36Z
Hanno Böck
gsf-vba-dump crashes after reporting errors
/usr/bin/gsf-vba-dump $(seq 1 2000)
segfaults.
/usr/bin/gsf-vba-dump $(seq 1 2000)
segfaults.
https://gitlab.gnome.org/GNOME/libgsf/-/issues/14
OLE file corruption
2019-02-04T18:46:47Z
Sagi Lowenhardt
OLE file corruption
I'm not sure what exactly is the content of the GSF_META_NAME_DOCUMENT_PARTS property in the attached file but it was created using Power Point and is valid.
The application gets input compound file and creates an output compound file w...
I'm not sure what exactly is the content of the GSF_META_NAME_DOCUMENT_PARTS property in the attached file but it was created using Power Point and is valid.
The application gets input compound file and creates an output compound file with altered properties on the DocumentSummaryInfo stream.
**Flow:**
* Copy all streams besides for DocumentSummaryInfo stream
* Copy the input DocumentSummaryInfo stream to a temporary stream
* Add/Remove properties from the temporary stream
* Write the temporarty stream to the output file
This is the code (It's actually spread through some files so I hope I didn't miss anything)
```
file = gsf_output_istream_new(mStream.get(), error.GetCleanError());
storage = gsf_outfile_msole_new(GSF_OUTPUT(file));
gsf_output_set_name(GSF_OUTPUT(storage), "Root");
// get the DocumentSummaryInfo stream content from the input file to a temporary stream
auto infile = gsf_infile_child_by_name(GSF_INFILE(storage), "\05DocumentSummaryInformation");
temp_stream = unique_ptr<GsfDocMetaData, GsfDocMetaData_deleter>(gsf_doc_meta_data_new());
gsf_doc_meta_data_read_from_msole(temp_stream.get(), infile)
// append/remove properties to the temp stream
auto out_stream = GSF_OUTPUT(gsf_outfile_new_child(GSF_OUTFILE(storageOutput), "\05DocumentSummaryInformation", false));
// gsf_doc_meta_data_insert(temp_stream.get(), g_strdup(name.c_str()), gvalue.release()); // writing some property, but the bug reproduces even without this line
// Write the temp stream to the output stream
gsf_doc_meta_data_write_to_msole(temp_stream.get(), out_stream, true); // this line corrupts the file
```
If GSF_META_NAME_DOCUMENT_PARTS is removed prior to writing the metadata:
```
const auto extraPropertiesToRemvoe = string(GSF_META_NAME_DOCUMENT_PARTS);
gsf_doc_meta_data_remove(temp_stream.get(), extraPropertiesToRemvoe.c_str());
```
(or by using CFX for example), the output is valid, hence the assumption the issue is this property.
Besides for this specific issue the application performs great and we didn't encounter any other issue so far with adding/removing properties from files using the library.
[before_corruption.ppt](/uploads/2242d7d18d0dbf2bc3f7b0e0279ca3c1/before_corruption.ppt)
https://gitlab.gnome.org/GNOME/libgsf/-/issues/13
valgrind test failures on some architectures
2018-10-10T13:28:50Z
Jeremy Bicha
valgrind test failures on some architectures
The valgrind tests fail on some Ubuntu architectures.
https://launchpad.net/ubuntu/+source/libgsf/1.14.43-1ubuntu1
Click the architecture for the build log.
The valgrind tests fail on some Ubuntu architectures.
https://launchpad.net/ubuntu/+source/libgsf/1.14.43-1ubuntu1
Click the architecture for the build log.
https://gitlab.gnome.org/GNOME/libgsf/-/issues/12
tests are skipped
2018-09-14T18:49:06Z
Jeremy Bicha
tests are skipped
I want to run the build tests during the build on Ubuntu and I want the build to fail if the tests fail.
But for some reason, the tests are being skipped without a clear explanation of why.
Now, I see that one problem is that I need to...
I want to run the build tests during the build on Ubuntu and I want the build to fail if the tests fail.
But for some reason, the tests are being skipped without a clear explanation of why.
Now, I see that one problem is that I need to have valgrind installed but that doesn't end up changing the results.
Build log excerpt
-----------------
```
make check-TESTS
make[3]: Entering directory '/<<PKGBUILDDIR>>/tests'
make[4]: Entering directory '/<<PKGBUILDDIR>>/tests'
SKIP: t1000-zip-single.pl
SKIP: t1001-zip-multiple.pl
SKIP: t1002-zip-aaaa.pl
SKIP: t1003-zip-noise.pl
SKIP: t1004-zip-zip64.pl
SKIP: t1005-zip-nonseekable.pl
SKIP: t8000-valgrind-zip.pl
SKIP: t8020-valgrind-ole.pl
SKIP: t9999-epilogue.pl
============================================================================
Testsuite summary for libgsf 1.14.44
============================================================================
# TOTAL: 9
# PASS: 0
# SKIP: 9
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
```
Full build log
--------------
https://launchpad.net/ubuntu/+source/libgsf/1.14.43-1/+build/14831268
cc/ @welinder (in case you're not subscribed here yet)