[kdeconnect] [Bug 485323] New: Underscore in deviceID shall be sanitized in SNI before sending ClientHello

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=485323

Bug ID: 485323
   Summary: Underscore in deviceID shall be sanitized in SNI
before sending ClientHello
Classification: Applications
   Product: kdeconnect
   Version: unspecified
  Platform: Apple App Store
OS: iOS
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: ios-application
  Assignee: lucas.w...@tuta.io
  Reporter: taoky1...@gmail.com
  Target Milestone: ---

***
If you're not sure this is actually a bug, instead post about it at
https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY

In LanLinkProvider.m didReadData(), deviceId received from computer is directly
used in tlsSettings. For implementations following
https://invent.kde.org/network/kdeconnect-meta/-/merge_requests/4, the deviceId
would contain underscore. However, gnutls does not accept names with underscore
(),
and implementations using that would report "A disallowed SNI server name has
been received" to users.

I did not test with official KDE connect server implementation. Testing with
https://github.com/andyholmes/valent (main branch) reports me this and takes me
some time to read code.

STEPS TO REPRODUCE
1. Install KDE Connect from iOS App Store on an iPhone
2. On computer, compile valent and run. Start wireshark and capture
3. Try pair

OBSERVED RESULT

Both sides show nothing. Wireshark shows the TCP connection FINs after the
Client Hello from iPhone, with SNI equals to deviceID sent from server which
contains underscore.

EXPECTED RESULT

SNI in ClientHello does not contain characters that gnutls does not accept, and
connects successfully.

SOFTWARE/OS VERSIONS
Windows: N/A
macOS: N/A
Linux/KDE Plasma: Arch Linux + GNOME 46
(available in About System)
KDE Plasma Version: N/A
KDE Frameworks Version: N/A
Qt Version: N/A
iOS client version: 0.3.0 (9)

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #1 from Keyu Tao  ---
* just tested under Wayland (QT_QPA_PLATFORM=wayland) and X (xcb) and this
issue exists in both platforms.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #3 from Keyu Tao  ---
(In reply to Albert Astals Cid from comment #2)
> Are you sure it's hung or just doing work?
> 
> How much time have you waited before declaring it hung?

3 minutes, with Okular process running with 100% CPU and 11G RAM.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #4 from Keyu Tao  ---
(In reply to Keyu Tao from comment #3)
> (In reply to Albert Astals Cid from comment #2)
> > Are you sure it's hung or just doing work?
> > 
> > How much time have you waited before declaring it hung?
> 
> 3 minutes, with Okular process running with 100% CPU and 11G RAM.

* The backtrace is captured just after okular is not responding, though.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #6 from Keyu Tao  ---
(In reply to Albert Astals Cid from comment #5)
> 3 minutes is obviously a lot, it works here in like 1 second.
> 
> Does this problem happen in every file or in one in particular?

I can reproduce this on all PDF files I could find. I'll try using a KDE Neon
VM to see if I could reproduce after I finish my dinner (as I only tested this
in GNOME environment)...

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #8 from Keyu Tao  ---
Created attachment 164505
  --> https://bugs.kde.org/attachment.cgi?id=164505&action=edit
fc-list

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #9 from Keyu Tao  ---
(In reply to Albert Astals Cid from comment #7)
> This may be related to the fonts you have installed.
> 
> Can you paste the output of fc-list ?

The fc-list stdout has been added to attachments list.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #10 from Keyu Tao  ---
(In reply to Keyu Tao from comment #6)
> (In reply to Albert Astals Cid from comment #5)
> > 3 minutes is obviously a lot, it works here in like 1 second.
> > 
> > Does this problem happen in every file or in one in particular?
> 
> I can reproduce this on all PDF files I could find. I'll try using a KDE
> Neon VM to see if I could reproduce after I finish my dinner (as I only
> tested this in GNOME environment)...

I could reproduce this with latest neon-developer-20231225-1605.iso livecd (KDE
5.91.90 with Okular 24.01.85, KDE Frameworks 5.248.0 and Qt 6.6.1).

Screen record and fc-list inside KDE Neon LiveCD would be attached later.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #11 from Keyu Tao  ---
Created attachment 164507
  --> https://bugs.kde.org/attachment.cgi?id=164507&action=edit
fc-list inside KDE Neon LiveCD

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #12 from Keyu Tao  ---
(In reply to Keyu Tao from comment #10)
> (In reply to Keyu Tao from comment #6)
> > (In reply to Albert Astals Cid from comment #5)
> > > 3 minutes is obviously a lot, it works here in like 1 second.
> > > 
> > > Does this problem happen in every file or in one in particular?
> > 
> > I can reproduce this on all PDF files I could find. I'll try using a KDE
> > Neon VM to see if I could reproduce after I finish my dinner (as I only
> > tested this in GNOME environment)...
> 
> I could reproduce this with latest neon-developer-20231225-1605.iso livecd
> (KDE 5.91.90 with Okular 24.01.85, KDE Frameworks 5.248.0 and Qt 6.6.1).
> 
> Screen record and fc-list inside KDE Neon LiveCD would be attached later.

The screencast is too large to put here (more than 4M), 
and I didn't find a better place to store this so I just uploaded it to
YouTube: https://www.youtube.com/watch?v=LUhQHRLHOnw.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #14 from Keyu Tao  ---
Created attachment 164516
  --> https://bugs.kde.org/attachment.cgi?id=164516&action=edit
thread apply all bt full from gcore dump (+ poppler debug symbols)

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #17 from Keyu Tao  ---
(In reply to Albert Astals Cid from comment #15)
> Ok, i can reproduce, it happens if i draw a very small square for the inline
> annotation

Oops, I didn't find the correct way to use inline note... I was just clicking
instead of dragging a rectangle out...

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #18 from Keyu Tao  ---
(In reply to Albert Astals Cid from comment #16)
> Not an okular bug, but a poppler bug.
> 
> https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1482

https://gitlab.freedesktop.org/poppler/poppler/-/commit/8a9f1d3a84a9f3d66cd353b7fe1aef0b65a37c08
does not seem to have this fixed.
I compiled the latest master branch poppler locally, LD_PRELOADed when running
okular, 
and I could still easily reproduce this bug.

Going to try debugging after lunch.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #19 from Keyu Tao  ---
(In reply to Keyu Tao from comment #18)
> (In reply to Albert Astals Cid from comment #16)
> > Not an okular bug, but a poppler bug.
> > 
> > https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1482
> 
> https://gitlab.freedesktop.org/poppler/poppler/-/commit/
> 8a9f1d3a84a9f3d66cd353b7fe1aef0b65a37c08 does not seem to have this fixed.
> I compiled the latest master branch poppler locally, LD_PRELOADed when
> running okular, 
> and I could still easily reproduce this bug.
> 
> Going to try debugging after lunch.

Very weird: even when Okular is responding, I find that one thread is already
in dead loop inside `drawMultiLineText()` (when it does not have enough space
and you type in non-ASCII chars): 

In this case `textLayouter.consumedText` is 2 and `text.hasUnicodeMarker()` is
true, thus it keeps `i += 0` and it could never leave the `while (i <
text.getLength())`.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #20 from Keyu Tao  ---
(In reply to Keyu Tao from comment #19)
> (In reply to Keyu Tao from comment #18)
> > (In reply to Albert Astals Cid from comment #16)
> > > Not an okular bug, but a poppler bug.
> > > 
> > > https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1482
> > 
> > https://gitlab.freedesktop.org/poppler/poppler/-/commit/
> > 8a9f1d3a84a9f3d66cd353b7fe1aef0b65a37c08 does not seem to have this fixed.
> > I compiled the latest master branch poppler locally, LD_PRELOADed when
> > running okular, 
> > and I could still easily reproduce this bug.
> > 
> > Going to try debugging after lunch.
> 
> Very weird: even when Okular is responding, I find that one thread is
> already in dead loop inside `drawMultiLineText()` (when it does not have
> enough space and you type in non-ASCII chars): 
> 
> In this case `textLayouter.consumedText` is 2 and `text.hasUnicodeMarker()`
> is true, thus it keeps `i += 0` and it could never leave the `while (i <
> text.getLength())`.

OK I have figured it out:

- `Annot::layoutText` first `*i = 2;` to skip UTF-16 BOM, then `*i += 2` in
while as it is unicode (UTF-16), and then as it meets new font needed, it `*i
-= unicode ? 2 : 1;`, thus finally `*i = 2`.
- In `HorizontalTextLayouter` constructor, `availableWidth` is a negative
number (as it is too small), so `consumedText` would just be `2` -- consumes
nothing but BOM.
- `drawMultiLineText` does not expect textLayouter eating no characters, thus
resulting a dead loop.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #22 from Keyu Tao  ---
(In reply to Albert Astals Cid from comment #21)

> How much do you know about programming? If i tell you do add some printf in
> the poppler code is that something you can do?

Yes, as I got this conclusion just by adding `std::cout` inside poppler code :)

> Also just to make sure, the problem doesn't happen if you draw a big
> rectangle, right?

Yes.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #24 from Keyu Tao  ---
(In reply to Albert Astals Cid from comment #23)
> (In reply to Keyu Tao from comment #22)
> > (In reply to Albert Astals Cid from comment #21)
> > 
> > > How much do you know about programming? If i tell you do add some printf 
> > > in
> > > the poppler code is that something you can do?
> > 
> > Yes, as I got this conclusion just by adding `std::cout` inside poppler code
> > :)
> 
> Ok, can you please print
>   rect->x2 
>   rect->x1
>   width
>   borderWidth
>   textwidth
>   da.getFontPtSize()
> before the call to
>   const DrawMultiLineTextResult textCommands = drawMultiLineText(*contents,
> textwidth, form, *font, da.getFontName().getName(), da.getFontPtSize(),
> quadding, 0 /*borderWidth*/);
> in
>   generateFreeTextAppearance()
> 
> 
> Also i'm guessing 
> 
> diff --git a/poppler/Annot.cc b/poppler/Annot.cc
> index b4c4a771..8a50225f 100644
> --- a/poppler/Annot.cc
> +++ b/poppler/Annot.cc
> @@ -3036,7 +3036,7 @@ public:
>  *availableWidth -= blockWidth;
>  }
>  
> -while (newFontNeeded && (!availableWidth || *availableWidth > 0)) {
> +while (newFontNeeded && (!availableWidth || *availableWidth > 0||
> (isUnicode && i == 2) || (!isUnicode && i == 0))) {
>  if (!form) {
>  // There's no fonts to look for, so just skip the characters
>  i += isUnicode ? 2 : 1;
> 
> 
> Will fix your problem too but i'd like to figure out how availableWidth gets
> to be negative

Var outputs:

===
rect->x2: 25.7253
rect->x1: 23.9537
width: 1.77165
borderWidth: 1
textWidth: -2.22835
da.getFontPtSize(): 10
===

And this patch is working: I could not reproduce the hang with the patched
while loop.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 370382] Using non-default size for custom stamp pixelates the stamp

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=370382

Keyu Tao  changed:

   What|Removed |Added

 CC||taoky1...@gmail.com

--- Comment #4 from Keyu Tao  ---
This looks like a bug related to QPixmap scaling and DPI stuffs. In
setPopplerStampAnnotationCustomImage() it calls
Okular::AnnotationUtils::loadStamp() with a rect size calculated from page size
and annotation size. However it looks like this code assumes that 1 pts = 1
pixel on screen (72 DPI?), then in Okular::AnnotationUtils::loadStamp() the
stamp is scaled too small, and results in a blurry result.
setStampCustomImage() stores the scaled image in PDF, so stamps saved by Okular
would also be blurry in other PDF readers.

A very dirty workaround is to enforce it to be at least 288 (=72*4) DPI in
setPopplerStampAnnotationCustomImage():

diff --git a/generators/poppler/annots.cpp b/generators/poppler/annots.cpp
index 20ad117ea..9d0680919 100644
--- a/generators/poppler/annots.cpp
+++ b/generators/poppler/annots.cpp
@@ -285,7 +285,7 @@ static void setPopplerStampAnnotationCustomImage(const
Poppler::Page *page, Popp
 const QSize size = page->pageSize();
 const QRect rect =
Okular::AnnotationUtils::annotationGeometry(oStampAnnotation, size.width(),
size.height());

-QImage image =
Okular::AnnotationUtils::loadStamp(oStampAnnotation->stampIconName(),
qMax(rect.width(), rect.height())).toImage();
+QImage image =
Okular::AnnotationUtils::loadStamp(oStampAnnotation->stampIconName(),
qMax(rect.width(), rect.height())*4).toImage();

 if (!image.isNull()) {
 pStampAnnotation->setStampCustomImage(image);


I don't think it's a nice fix that should be included in upstream, but at least
my signature image looks clear with this workaround.

-- 
You are receiving this mail because:
You are watching all bug changes.