Download it now!
Bug 124609 - GPG errors when LO is in non-Latin folder
Summary: GPG errors when LO is in non-Latin folder
Status: RESOLVED MOVED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL: https://dev.gnupg.org/T4453
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-08 12:04 UTC by LOfan
Modified: 2019-04-12 11:23 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description LOfan 2019-04-08 12:04:22 UTC
Description:
LO 6 is shipped with kinda GPG. Even if GPG is not used at all, there are annoying GPG-related errors when LO is installed in a Cyrillic folder. But once LO is moved to a Latin folder, those errors vanish. In our age of Unicode there is no place for such discrimination, do you agree?

Steps to Reproduce:
1. Install LO to a folder with Cyrillic characters, e.g. D:\Входящие\LibreOffice\...
2. Open any previously created LO document, e.g. D:\text.odt or D:\table.ods
3. Go to File menu, then Properties.

Actual Results:
Multiple (usually six) error windows as follows https://i.imgur.com/CNXR75x.png

Expected Results:
No errors like that.



Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.2.2.2 (x64)
Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d
CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-GB
Calc: threaded
Comment 1 Mike Kaganski 2019-04-08 13:01:51 UTC
Reproducible with 6.1.5.2.

LibreOffice passes UTF-8 string to gpgme library code, when it expects ACP encoding.
Comment 2 Egor Pugin 2019-04-08 14:04:43 UTC
Related GPGME issue https://dev.gnupg.org/T4453
Comment 3 Mike Kaganski 2019-04-08 14:30:40 UTC
So - my assertion that it's LO passing utf-8 to gpgme is wrong. gpgme does not need external help to confuse itself, converting utf-60 to utf-8 in some places, and using the results in functions taking strings in Windows ACP in others...
Comment 4 Mike Kaganski 2019-04-08 14:31:01 UTC
*utf-16 of course
Comment 5 LOfan 2019-04-08 15:03:39 UTC Comment hidden (off-topic)
Comment 6 Mike Kaganski 2019-04-09 15:13:19 UTC
The upstream issue mentioned in comment 2 got fixed - thanks to Egor who raised it there, and Andre Heinecke, who fixed it. It will be available in the next release; also it has a combined patch if needed.
Comment 7 Mike Kaganski 2019-04-09 15:14:03 UTC
(In reply to Mike Kaganski from comment #6)
> It will be available in the next release

I mean next gpgme release, of course.
Comment 8 Xisco Faulí 2019-04-12 11:15:53 UTC
I guess we can close this as RESOLVED MOVED
Comment 9 Mike Kaganski 2019-04-12 11:20:17 UTC
(In reply to Xisco Faulí from comment #8)

Yes; still when someone learns that upstream has released a version with the fix, it's fine to leave a comment here; those who CCed to this issue, will get informed, and could act (update version used by LO) then. Thanks!