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:

unoconv --user-profile /tmp/tmpf_yreswi -f pdf --port 2002 test.txt

NOTE: It's your responsibility to give --port a unique value, but that's not too hard: if you use a thread pool to launch the unoconv processes, then you can add the thread index to a base port and that will give you a unique port.

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:

• platforms: handling Windows as well, not only Linux/macOS
• operations: handling signing as well, not only verification
• formats: cover all of ODF, OOXML and PDF

Let's see what has happened:

• Linux, ODF, sign: we had hardcoded RSA algorithm when generating a signature, now we infer the sign algorithm from the signing cert algorithm (commit)

• Linux, OOXML, sign: same problem with hardcoded RSA (commit)

• Windows, PDF, sign: the certificate chooser had to be ported to from CryptoAPI to CNG (commit)

• Windows, ODF, verify / sign: this was the largest problem, this required a whole new libxmlsec backend (interface, implementation, all in C90) and also required conditionally using that new backend in LibreOffice (commit)

• Windows, OOXML, sign: this was almost functional, except that the UI recently regressed, now fixed (commit)

• Finally now that everything is ported on Windows to use CNG, I could enable it by default yesterday.

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

• Linux:

• Windows:

(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. :-)