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

--- Comment #20 from Henrik Fehlauer <rkflx@lab12.net> ---
Thanks for testing, your collection sounds impressive! You should run your
script regularly and report any new problems ;)

As for Okular, we (as in whoever contributes this) should extend
https://phabricator.kde.org/source/okular/browse/master/autotests/parttest.=
cpp;069a18b041ce3615ac9c6546c57399fe61481dc8$183
to also cover broken documents. Apart from that, it's not really Okular's j=
ob
to test synctex itself.

There is also <https://github.com/jlaurens/synctex/tree/2017/synctex test
files>, but this is nearly unusable without any buildsystem/testrunner. I
wonder if upstream is running all those test manually?

> Are you sure, this is not an expected behavior for old synctex files?
Well, screaming "! Error" and "ignoring records" is not something I would
expect ;) It was my first guess too yesterday, but looking at the upstream
commit you'll see that this line was there before (but commented out), it w=
as
only moved around and set active by default. This means the format errors c=
ould
have been there all along. Are they going away if you recompile those old
documents? Still, it looks like broken backwards compatibility.

Anyway, the only way to know for sure is to ask upstream, because I don't k=
now
a thing about this and also I have no access to the tex source to create the
synctex file in question (with an older texlive version?) in the first plac=
e=E2=80=A6
Worst that could happen is a WONTFIX, best a patch. Just try it, I'd say.


> Okular could just call the synctex command line tool
Interesting, might be worth thinking about. However, I'm not yet convinced
switching from a C API (with type checking and only breaking at compile tim=
e,
i.e. before reaching users) to a Bash API (passing strings over pipes and
runtime version checks breaking on user's machines) is a good idea.

> If the synctex cmdline tool crashes, it does not affect okular
As you noted, for exploits this point is irrelevant. For crashing in genera=
l,
decoupling is only worth the effort if it crashes very often, but again, th=
en
the crash should be fixed in the first place as we have access to the sourc=
e.

> After the first shift-click, the user could be asked for confirmation
Not sure about this one. I think this approach has been shown to fail where=
 it
is needed most: Non-technical users. For all others it is just an annoyance.
Would you like Gwenview to ask whether you trust a JPG? (We have dozens of
duplicate EXIV crasher bugs, but only two for synctex.)

> Okular would not depend on synctex.
Could also be achieved by runtime-loading synctex support as a plugin?

> Delaying to load the synctex file until the first shift-click is of course
> also an option if synctex is used as library.
This is an excellent idea! If only I had more time to work on such things=
=E2=80=A6

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