Downstream issue at https://github.com/lovell/sharp/issues/3910
https://nvd.nist.gov/vuln/detail/CVE-2023-38633 suggests this vulnerability has been scored "7.5 high" and the attack vector used in this calculation was "network". Given the input file must exist on the filesystem should this instead be "local"? If so, the score will be (approx) "6.2 medium".
Lovell Fuller (c26dd900) at 02 Mar 01:50
Lovell Fuller (c26dd900) at 27 Feb 14:30
Clarify that licensing is under terms of LGPL-2.1-only
Thank you very much Morten, that all makes sense, and I agree re-licensing is a hard problem.
Whilst investigating this, I spotted a few remnants of GPL2 wording in files in this repo, which I believe might be leading automated checkers to determine that GPL2 still applies. For example, all the source code headers say "See the GNU General Public License for more details." where the LGPL2.1 wording is "See the GNU Lesser General Public License for more details."
If LGPL-2.1-only
is the one true (SPDX) licence for all libgsf source code then I'd be happy to submit a merge request to update and help clarify the situation for packagers and downstream consumers.
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.
Thank you.
I was able to reproduce this with rsvg-convert
v2.51.4 as well as the latest code on the master
branch.
A slightly clearer example is:
<?xml version="1.0" encoding="utf-8"?>
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xml:lang="fa" direction="rtl" width="200" height="100">
<g font-family="Dana-FaNum" font-size="16" fill="red">
<text x="50%" y="50%"><tspan font-weight="bold">نام: </tspan><tspan>مهدی</tspan></text>
</g>
</svg>
Original SVG:
rsvg-convert 791.svg > out.png
produces:
Lovell Fuller (25b96ac7) at 29 Jun 08:06
Merge branch 'context-fill-stroke-tests' into 'master'
... and 366 more commits
Lovell Fuller (fb598296) at 29 Jun 08:06
WIP: Remove unused derive debug attribute
... and 367 more commits
libvips use librsvg for SVG rendering (thank you!), and for the sharp Node.js binary builds we create the most minimal version possible using the following settings:
export CARGO_PROFILE_RELEASE_DEBUG=false
export CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1
export CARGO_PROFILE_RELEASE_INCREMENTAL=false
export CARGO_PROFILE_RELEASE_LTO=true
export CARGO_PROFILE_RELEASE_OPT_LEVEL=z
export CARGO_PROFILE_RELEASE_PANIC=abort
Including SVG support via a statically-linked librsvg adds approximately 5MB to the overall binary size.
Based on my initial research, the single biggest improvement to reducing this further would be the replacement of #[derive(Debug)]
, which adds about 15KB per type. My back-of-an-envelope calculations suggest #[derive(Debug)]
might be the cause of around 20% of the resultant binary size.
libtock have run into this too - see https://github.com/tock/libtock-rs/issues/84 - their approach has been to vendor (and fix bugs in) the no-longer-maintained https://github.com/japaric/ufmt crate. There seems to be a desire by the libtock maintainers to support a modified ufmt, so adopting this code or a similar approach should help librsvg too.
Lovell Fuller (e5e77b9b) at 13 Apr 15:00
Hello, since commit e0abeb54 and v2.51.1, librsvg cannot be compiled on (or for) 32-bit platforms.
error[E0437]: type `Output` is not a member of trait `From`
--> /deps/svg/vendor/cast/src/lib.rs:192:21
|
192 | type Output = $dst;
| ^^^^^^^^^^^^^^^^^^^ not a member of trait `From`
...
364 | / promotion! {
365 | | i8 => f32, f64, i8, i16, i32, isize, i64;
366 | | i16 => f32, f64, i16, i32, isize, i64;
367 | | i32 => f32, f64, i32, isize, i64;
368 | | isize => f32, f64, i32, isize, i64;
369 | | i64 => f32, f64, i64;
370 | | }
| |_____- in this macro invocation
|
This is due to https://github.com/japaric/cast.rs/issues/29
Luckily upgrading from the "yanked" v0.2.4 to the latest v0.2.5 appears to fix this.
Lovell Fuller (e5e77b9b) at 13 Apr 08:38
Bump 'cast' dependency to ensure 32-bit ARM support
Lovell Fuller (e9431c80) at 13 Apr 08:38
Merge branch 'prepare-release' into 'master'
... and 4752 more commits