Crash during reading LFF fonts about librecad HOT 13 CLOSED

Can you upload the sample lff ?

from librecad.

the font is amiri-regular.llf (standard one)
If I'm correct, based on the debugger state as the assert occurs - it is for line with text [#1EE00] - reading line number 7204 within font file

from librecad.

Again, this is a real issue with lff font implementation:

QChar is for utf-16, so the range is 16bit, and we cannot pass any value beyond 16 bits but while using the int type.

Looks like we have to use the string::fromutf8() instead

from librecad.

Where is this LFF file from?
I checked branches, but I couldn't find a amiri-regular.llf with code [#1EE00].
All I found ended in line 7203, at code [FEFC].

I've checked all fonts for correctness a while ago and there was nothing added to fonts to my knowledge.

LFF format is limited to utf-16 yet and we could not accept contributions that exceed this limit.
Anyhow, of course LibreCAD should not crash with malicious LFF files.
This needs limit checks in rs_filterlff.cpp where the code is used without further proving.

from librecad.

well, it's a good question... I suppose I've picked it from fonts that are part of 2.2.0 - yet probably its old install, the date of font file on my machine is Dec 17, 2022 which is the same as build date

Version
Version: 2.2.0
Compiler: GNU GCC 12.2.0
Compiled on: Dec 17 2022
Qt Version: 5.12.11
Boost Version: 1.75.0
System: Windows 10 (10.0)

from librecad.

We can remove the limit of 16 bit now, since utf is supposed to be universal.

from librecad.

well, it's a good question... I suppose I've picked it from fonts that are part of 2.2.0 - yet probably its old install, the date of font file on my machine is Dec 17, 2022 which is the same as build date

My fix was 82e2c3e, Jul 29, 2023, reason for 2.2.0.2 bug fix release.
The fix was also applied to the master branch.

So any pre 2.2.0.2 version crash with this font and some others too.
I recommend to upgrade your regular instance with Bugfix release 2.2.0.2 or, at least use the current fonts from librecad/support/fonts from your local git repo.

I didn't consider, that newer binaries will use the old, malicious font files. But this probably only affects us developer. Old installations will crash anyhow and the common user, who upgrades with new installer packages, will have the fixed fonts.

We can keep this open, to track to make the LFF filter at least more bulletproof, and possibly also extend it to utf-32.

from librecad.

@lordofbikes

1, the file format itself is compatible with unicode beyond 16bit;
2, step by step, LibreCAD side can remove the 16bit limitation;
3, also need to fix ttf2lff. I assume it has the same limitation.

I am a little busy now. Wondering @sand1024 would like to help here.

I suggest we also back port the fix to 2.2.1 and 2.2.0, where no assertion is raised, potentially even more confusing to end users

from librecad.

I found these font issues by accident. It is no issue using the fonts for text entities, but opening them to modify letters graphically raised the issue.
As it was not reported before June 2023, I assume, that opening font files is a rarely used feature of LibreCAD. I suspect most font contributions were created with a text editor, copying and modifying existing letters. This also explains the existence of the malicious font files.

So we can't change or fix existing installations, and with the above said, I see no need, even if it was possible.
It is fixed in 2.2.0 with b6b7860 and thus fixed in our official stable release 2.2.0.2.
It was fixed in master with 82e2c3e and thus fixed in 2.2.1 already and of course 2.2.2_alpha too.

Thus no need for urgent actions currently.

from librecad.

Remembering #1687 I suggest some investigation before putting any efforts into this.
I think there is still a big mess out there, concerning OS platforms and their support for localized letter support. Issue #1687 is about discrepancies between input methods and local letter encoding.
There is Unicode, Codepage system and various UTF formats spread about our supported platforms.
So I'm not sure yet, if just supporting 32-bit letter codes solves any problems.
This might need some investigation in advance, e.g. about current unicode standard, truetype format or OS support for localization, to see if and how it can be useful at all.
Just to be sure not to open Pandora's box, with feeding 32-bit letter codes into our Text entities.

from librecad.

I feel it's a step by step process to remove artificial limitations due to our own implementation.

The current Unicode standard 15.1(2023) contains 149,813 characters.

16 bit is not even enough to have proper Chinese support, for example.

We don't handle locales graceful, but limiting it to 16 bit would leave some users no easy alternative within one locale setting.

The issue is probably limited to Chinese. Japanese only uses a subset of Chinese characters, so should be okay with 16bit limitation. I am not aware of any other languages extensively based on characters(instead of alphabet).

from librecad.

fixed in rs_font

need to check implementation in ttf2lff

from librecad.

tff2lff is already using uint32 for char code, so it doesn't have the limitation of 16 bit char code.

Closing this issue.

from librecad.