Index ¦ Archives ¦ RSS > Tag: libreoffice

odfsig: an Open Document Format (ODF) digital signatures tool

Estimated read time: 1 minutes

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

Custom user profiles with unoconv

Estimated read time: 2 minutes

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

Improved ECDSA handling in LibreOffice

Estimated read time: 2 minutes

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

ECDSA support in xmlsec-nss, bundled by LibreOffice

Estimated read time: 2 minutes

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:

  • an attribute type in the signature that had no official abbreviation was described as "UNDEF" instead of the dotted decimal form

  • RFC3279 specifies that an ECDSA signature value in general should be ASN1-encoded in general, but RFC4050 is specific to XML digital signatures and that one says it should not be ASN1-encoded. The bugdoc was initially ASN1-encoded.

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. ;-)

LibreOffice / openSUSE Conference 2012 in Berlin / Prague

Estimated read time: 1 minutes

I spent the last two weeks on two conferences:

  • LibreOffice Conference in Berlin, where I gave a talk

  • openSUSE conference in Prague, where I just attended.

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

A few fun facts I discovered during the conference:

  • Armin is referred in the source tree as AW due to… well, it’s easy to find out once you heard about OD’s ORW reincarnation. :-)

  • solver stands for "solar version", it does not solve anything (read Michael Stahl’s talk for details)

  • I just discovered this presentation of Thorsten, slide 15 mentions a bug on x86, which is still the case on Android, 6 years later.. (even mentioned in Tor’s talk)

  • "Java? I hope that language dies" (Jan Engelhardt, openSUSE Sparc guy)

  • "Browser: we’re there; Office: with LibreOffice — even if it’s not perfect, we’re getting there. Groupware: we’re weak here" (Georg Greve, Kolab guy)

  • Don’t try to change EUR to CZK in the Prague main station, they have ridiculously bad rates

A few pictures here.

LibreOffice Conference 2011

Estimated read time: 1 minutes

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!

Positions in RTF font tables

Estimated read time: 1 minutes

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.

© Miklos Vajna. Built using Pelican. Theme by Giulio Fidente on github.