I created a toy project to experiment with a few technologies I wanted to try out (cmake, googletest, xmlsec outside LibreOffice, libzip and AppVeyor). The result is a tool with a similar interface as pdfsig from poppler (for PDF files), just for ODF: a cmdline executable to verify the digital signature(s) in an ODF document.

The source code now has CI on Linux and Windows, so perhaps in a shape that is interesting for others to have a look as well. And if not, then no problem, it was interesting to put together these building blocks and see them working as expected. :-)

Background: I was benchmarking Online vs jodconverter vs unoconv the other day for Collabora’s document conversion page. One problem with measuring unoconv performance was that it provided no ways to run multiple unoconv processes in parallel, while the underlying soffice binary obviously allows this.

So while unoconv is not capable of launching the soffice process in a chroot (improves security), nor is capable of forking an already pre-initialized soffice process (improves performance, both are things Online can do for you), there is no real reason why you should not be able to run multiple unoconv processes in parallel. The previously mentioned benchmarking would be quite unfair if even this kind of multiprocessing would be ignored, but unoconv had no way to specify a custom user profile, which has to be different for each soffice process.

So I filed a GitHub pull request on 1st Jun, and finally it was merged on 10th Aug.

Here is how you can use it for example:

So this is available in unoconv master (towards unoconv 0.8.2+1), you can grab the sources from git and try it out right now. :-)

I wrote about ECDSA handling in LibreOffice last year, back then the target was to be able to verify signatures using the ECDSA algorithm on Linux.

Lots of things happened since then, this post is meant to summarize those improvements. My personal motivation is that Hungarian eID cards come with a gov-trusted ECDSA (x509) cert, so handling those in LibreOffice would be nice. My goals were:

Let’s see what has happened:

I could test hardware-based signing after this, which was fine out of the box on both platforms. Some screenshots:

(There is no reason why this would not work on macOS, but I did not test that.)

Thanks Gabor Kelemen who helped me to get a sane card reader that has reasonable driver support on Linux.

All this is available in master (towards LibreOffice 6.2), or you can grab a daily build and try it out right now. :-)

Last month a LibreOffice bugreport was filed, as the ODF signature created with Hungarian citizen eID cards is not something LibreOffice can verify. After a bit of research it seemed that LibreOffice and NSS (what we use for crypto work on Linux/macOS) is not a problem, but xmlsec’s NSS backend does not recognize ECDSA keys (RSA or DSA keys work fine).

The xmlsec improvements happened in these pull requests:

After this the xmlsec code looked good enough. I had to request an update of the bugdoc in the TDF bug twice, as the signature itself looked also incorrect initially:

Finally a warning still remains: while trying to parse the text of the <X509IssuerName> element, the dotted decimal form is still not parsed (see this NSS bugreport). The bug is confirmed on the mailing list, but no other progress have been made so far.

Oh, and of course: Windows is still untouched, there a bigger problem remains: we use CryptoAPI (not CNG) there, and that does not support ECDSA at all. Hooray for open-source libs where you can add such support yourself. ;-)

I spent the last two weeks on two conferences:

In general, thanks for the organizers for these fantastic events!

A few fun facts I discovered during the conference:

A few pictures here.

I’ve been invited to the first LibreOffice conference in Paris to give a short talk about this year’s GSoC work of mine: the RTF import rewrite in Writer. (Here are the slides.)

It also allowed me to allocate some time on hacking, including:

Thank you for the invitation, it was great fun!

Tonight I worked on fdo#39337, and while the writerfilter-based RTF import filter almost handled the document in question correctly, the fonts were not correct.

It turned out that this was caused by the fact that RTF’s font table (a table where each row has an ID and it contains the font name, charset and other properties) does not require continuous ID’s (for example positions 0, 2, 3 are allowed, even if 1 is not set), but dmapper (the glue layer between the RTF tokenizer and the Writer UNO API) does.

I already sent the position of the entry to dmapper, but the position turned out to be ignored, so now I fixed the RTF tokenizer to send continuous ID’s.

A related improvement is that I just discovered the writerfilter::TagLogger::unoPropertySet() method, which can dump the properties of an UNO object, and now I’ve enabled dumping of shape properties, which can help a lot when something goes wrong there.