Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

2020-11-30 Thread Rene Engelhard 
Hi,

On Fri, Nov 27, 2020 at 07:25:19PM +0100, Jörg Sommer wrote:
> Rene Engelhard schrieb am Fr 27. Nov, 16:48 (+0100):
> > > Package: libreoffice
> >
> > No, libreoffice does not contain anything except dependencies. Do you mean 
> > libreoffice-core?
>
> I don't know which package contains this functionality. And it shouldn't
> matter. I file a bug report to a *project* and I'm really don't know which

No, you file it against a *package*. If there was no libreoffice dummy package
reporing it against libreoffice would simply result in a bug for 
"unknown-package",
there is no "filing against a project" in Debians BTS. :)

> You might view a bug report as an incident in a component

That's what "bug" implies, yes... And you filed it as a "normal" bug :)

> and would like to organize all bug reports.

Exactly.

> > How it is a bug when LO does what it's supposed to do in case people want to
> > sign their documents (with S/MIME, gpg is something else) *and which is
> > documented*?
>
> I didn't touch anything that had to do with signing. I've got a document
> as a mail attachment and hit enter. I use LibreOffice four or five times
> per year.

Me too :)

Anyways, that probably means it initializes xmlsecurity/nss and thus acesses 
this.

> To be fair I don't look at my logs.

You wrote in your initial report "I'm seeing many entries like these in my 
log:".

> But I get AppArmor messages via mail. That's why I've spotted this (and
> other) problems.
>
> > > operation="open" profile="libreoffice-soffice" 
> > > name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> > > comm="soffice.bin" requested_mask="wc" denied_mask="wc" fsuid=1000 
> > > ouid=1000
> > > operation="file_lock" profile="libreoffice-soffice" 
> > > name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> > > comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000
> >
> > Access to the Mozilla profile is completely expected in how it's
>
> Yes, that's what you expect, but a) the AppArmor rules expect something
> else

They (apparently) miss key4.db, yes. Otherwise they allow "r" access.

"w" or "c" access shoudn't be allowed and yes, upstream acknowldeges it should 
probably
just be open "r"ead-only. (which is included in the IRC logs I sent in my other 
reply)

If you read what I wrote in my initial reply: I didn't deny that the profie 
might need
adaptions.

That doesn't change that you say in this bug that this access shouldn't happen 
at all,
which somewhat can agree with but as long as they use nss and don't want 
~/.pki/nssdb
because there is no (GUI) key management tool for this this discussion is moot.

It's not Debians "job" to replace something integral like this which also 
probably affects
file format and standards by something else.

> and b) from a generic point of view, I as a software developer
> wouldn't expect any project accessing the internal files of another
> project. This makes any change very difficult, because you have to
> consider all possible external users if you touch anything. That's
> horrible.

Internal details are handled by the nss security library.

Which knows the format because it's it's native format.
(That's why the mozilla profile is used in the first place anyway, LO
just initializes possible locations.)

> > Key *management* is something LO should not do and cannot do anyway. (same 
> > with gpg)
>
> Yes, indeed. Why doesn't it use helper tools like openssl?

See my other reply. They care more about end-users with no clue
instead of "openssl" or "certutil" for that matter...

> It requests the tools for it.

... and LO doesn't do any key management either. It just initializes the XML
signing library, which uses nss. (and not openssl, which is IMHO bad,
I agree.)

> At least, I can tell (but this is another problem) LibreOffice crashes
> with gpg using tofu.
>
> apparmor="DENIED" operation="open" profile="libreoffice-soffice//gpg" 
> name="/home/joerg/.gnupg/tofu.db" pid=708430 comm="gpg" requested_mask="wc" 
> denied_mask="wc" fsuid=1000 ouid=1000
>
> If you don't care about it drop this. I've fixed it for me, so it doesn't
> bother me any more.

Again that "tofu" gpg thingy...

Is there any website or so recommending to set this?

This is not default and "normal" gpg just works. See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955271 where this already
was reported.

If you change options you also need to change other stuff if needed.

> … by using a private key store. So, you are telling me it's difficult,

Anything needing to sign stuff needs to access the private key store, wherever
that lies. Whether ~/.pki/nssdb or the firefox profile.

Also gnupg needs to access their own key store (and so does LO if signing a 
document with
gpg - via libgpgme -, also only in "r" mode;).

You are suggesting not to access any key store => no signing at all. (INSIDE the
document), not something like gpg --detach-sign.
And no, LO has no business of

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

2020-11-27 Thread Jörg Sommer 
Rene Engelhard schrieb am Fr 27. Nov, 16:48 (+0100):
> Hi,

Hi,

> > Package: libreoffice
> 
> No, libreoffice does not contain anything except dependencies. Do you mean 
> libreoffice-core?

I don't know which package contains this functionality. And it shouldn't
matter. I file a bug report to a *project* and I'm really don't know which
component implements what. That's a question how the project organizes the
internal structure and I'm not a developer.

> Sorry, that it hits you, but why can't people just file against the
> correct package? "libreoffice" clearly says it's a dummy package.

I think the problem comes from the different views: as a user I see a
problem and want to report it. I also could have addressed the bug to
libreoffice-writer, because I saw it there. But the only thing I wanted to
tell is, that I've seen something that relates to the project. As long as
it reaches the project that's fine. It's not lost like all these bugs
someone observes and rants about, but doesn't tell the project about it.

You might view a bug report as an incident in a component and would like
to organize all bug reports.

So, I think, it's more a problem of the bug tracker that sets the bar so
high to “know the right package”, “know the right severity” and so on.
From a users point of view you don't know a project organizes it's bug
reports.

> > Severity: normal
> 
> Sigh.

That's why I keep the severity on normal. I'm not in the position to rate
the bug. And you know, there are enough fights about the right severity
“normal vs. wish”.

I'm using so many projects and if I see something and would like to tell
them about it, it should be easy to. Otherwise I drop it.

And I'm sorry, now, but my impression is, it's better not to send bug
reports to the libreoffice package.

> How it is a bug when LO does what it's supposed to do in case people want to
> sign their documents (with S/MIME, gpg is something else) *and which is
> documented*?

I didn't touch anything that had to do with signing. I've got a document
as a mail attachment and hit enter. I use LibreOffice four or five times
per year. I don't know about all the features of LibreOffice.

> That's what it is for. Signing documents with S/MIME.
> 
> > I'm seeing many entries like these in my log:
> 
> If you look at your logs (which is good) I would also expect you being
> able to do a basic resarch (see above) instead of filing a "bug" which
> then will linger around until eternity :-(

To be fair I don't look at my logs. I'm no other than an ordinary user.
But I get AppArmor messages via mail. That's why I've spotted this (and
other) problems.

> > operation="open" profile="libreoffice-soffice" 
> > name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> > comm="soffice.bin" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000
> > operation="file_lock" profile="libreoffice-soffice" 
> > name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> > comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000
> 
> Access to the Mozilla profile is completely expected in how it's

Yes, that's what you expect, but a) the AppArmor rules expect something
else and b) from a generic point of view, I as a software developer
wouldn't expect any project accessing the internal files of another
project. This makes any change very difficult, because you have to
consider all possible external users if you touch anything. That's
horrible.

> (The apparmor profiles allow "r", not "w". (Have to lookup what "c" is.)
> which is correct since

c is create and handled by w(rite).

> Key *management* is something LO should not do and cannot do anyway. (same 
> with gpg)

Yes, indeed. Why doesn't it use helper tools like openssl? I'm using
neomutt and it manages PGP and S/MIME signing, encryption and verification
by use gpg and openssl. Neomutt doesn't provide these features by itself.
It requests the tools for it.

> I guess I need to check whether signing works when the profile is in
> enforcing again...

At least, I can tell (but this is another problem) LibreOffice crashes
with gpg using tofu.

apparmor="DENIED" operation="open" profile="libreoffice-soffice//gpg" 
name="/home/joerg/.gnupg/tofu.db" pid=708430 comm="gpg" requested_mask="wc" 
denied_mask="wc" fsuid=1000 ouid=1000

If you don't care about it drop this. I've fixed it for me, so it doesn't
bother me any more.

> > LibreOffice tries to access the key storage of Firefox, which is really
> > strange.
> 
> No, it isn't.

From the point of view how LibreOffice look at this problem. But from a
generic point of view you what to have separation of domains. That's why
no process can access the memory of another process and so on. That's all
about encapsulation. And if two projects share something in common they
should place it outside of *both* projects.

> > Isn't it possible to use the keys in /etc/ssl?
> 
> a) as said it uses nss instead of the "standard" openssl, and has to

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

2020-11-27 Thread Jörg Sommer 
Jörg Sommer schrieb am Fr 27. Nov, 10:02 (+0100):
> Package: libreoffice
> Version: 1:7.0.3-4+b1
> Severity: normal
> 
> Hi,
> 
> I'm seeing many entries like these in my log:
> 
> ```
> operation="open" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> comm="soffice.bin" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000
> operation="file_lock" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000
> operation="open" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/key4.db" pid=486621 
> comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
> operation="file_lock" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/key4.db" pid=486621 
> comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000
> ```
> 
> LibreOffice tries to access the key storage of Firefox, which is really
> strange. Isn't it possible to use the keys in /etc/ssl?

How about using ~/.pki/nssdb? https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX


signature.asc
Description: PGP signature

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

2020-11-27 Thread Rene Engelhard 
Hi,

On Fri, Nov 27, 2020 at 04:48:22PM +0100, Rene Engelhard wrote:
> 16:41 < _rene_> is there any plan to be able to use /.pki/nssdb? (see
> https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX)
> 16:41 < _rene_> instead of the mozilla profile?
> 16:42 -!- hallnknight
> [~hallnknig@2401:4900:3b30:951d:983d:6f8:9c88:2aef] has joined
> #libreoffice-dev
> 16:42 < _rene_> (context:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975951 and
> https://bugs.documentfoundation.org/show_bug.cgi?id=119811)
> 16:42 < IZBot> bug 119811: LibreOffice-LibreOffice normal/medium NEW
> LibreOffice 6.0.6 spies on my Firefox keychain when opening MS documents
> 16:43 < mst___> _rene_, if there's some UI for users to add their certs
> to that location then sure
> 16:44 < _rene_> one can do so without a UI? not everything needs a UI?
> 16:44 < _rene_> at least make it honour that path in addition
> 16:45 < _rene_> mst___: users nowadays also don't use firefox :)
16:48 <@thorsten> _rene_: thought nss can only use one path?
16:49 < _rene_> no idea, can't one initialize nss two times and use one 
instance for firefox and the other for that one?
16:49 < _rene_> I mean, there must be more application not relying only on 
firefox?
16:50 <@thorsten> we had similar issues with thunderbird vs. firefox cert 
stores,
16:50 < _rene_> mmh
16:50 <@thorsten> IIRC the suggestion was for users to set the proper env var,
16:50 <@thorsten> and we're off the hook?
16:50 <@vmiklos> or just set their preferred path in LO, using tools -> options
16:51 < _rene_> but MOZILLA_CERTIFICATE_FOLDER if you mean that will expect a 
firefox profile and not work with ~/.pki/nssdb, will it?
16:52 <@vmiklos> you would have to check, possibly both just contain files like 
certX.db and keyY.db, so perhaps works out of the box
16:52 -!- OlegShtch [~Thunderbi@37.112.63.140] has joined #libreoffice-dev
16:52 < _rene_> ah, right, there's the "Options", didn't know
16:54 < _rene_> ok, related to this:
16:54 < _rene_> why does LO request w permissions?
16:54 < _rene_> r should simply suffice, shouldn't it?
16:55 < _rene_> or is this nss actually opening it? (I guess so...)
16:56 -!- hallnknight [~hallnknig@2401:4900:3b30:951d:983d:6f8:9c88:2aef] has 
quit [Ping timeout: 264 seconds]
16:56 -!- sberg [~sb...@dynamic-077-003-206-224.77.3.pool.telefonica.de] has 
quit [Quit: Leaving]
16:56 <@vmiklos> i guess ideally it should be read-only, right.
16:56 -!- hallnknight [~hallnknig@223.187.154.213] has joined #libreoffice-dev
16:57  * _rene_ writes that into 
https://bugs.documentfoundation.org/show_bug.cgi?id=119811
16:57 < IZBot> bug 119811: LibreOffice-LibreOffice normal/medium NEW 
LibreOffice 6.0.6 spies on my Firefox keychain when opening MS documents
16:57 < _rene_> (with the chat here cut'n'pasted)

So one can set ~/.pki/nssdb oneself (but then the apparmor profile should 
probably be adapted), but
the default will not change in LO (see above).

Regards,
 
Rene

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

2020-11-27 Thread Rene Engelhard 
Hi,

On Fri, Nov 27, 2020 at 02:31:08PM +0100, Jörg Sommer wrote:
> How about using ~/.pki/nssdb? https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX

Oh, didn't know about that one.

The reaction was predictable, though:

16:41 < _rene_> is there any plan to be able to use /.pki/nssdb? (see
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX)
16:41 < _rene_> instead of the mozilla profile?
16:42 -!- hallnknight
[~hallnknig@2401:4900:3b30:951d:983d:6f8:9c88:2aef] has joined
#libreoffice-dev
16:42 < _rene_> (context:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975951 and
https://bugs.documentfoundation.org/show_bug.cgi?id=119811)
16:42 < IZBot> bug 119811: LibreOffice-LibreOffice normal/medium NEW
LibreOffice 6.0.6 spies on my Firefox keychain when opening MS documents
16:43 < mst___> _rene_, if there's some UI for users to add their certs
to that location then sure
16:44 < _rene_> one can do so without a UI? not everything needs a UI?
16:44 < _rene_> at least make it honour that path in addition
16:45 < _rene_> mst___: users nowadays also don't use firefox :)

Regards,

Rene

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

2020-11-27 Thread Rene Engelhard 
severity 975951 minor
tag 975951 upstream
forwarded 975951 https://bugs.documentfoundation.org/show_bug.cgi?id=119811
retitle 975951 libreoffice tries to access files of firefox profiles
notfound 975951 1:7.0.3-4+b1
thanks

Hi,

> Package: libreoffice

No, libreoffice does not contain anything except dependencies. Do you mean 
libreoffice-core?

Sorry, that it hits you, but why can't people just file against the correct 
package? "libreoffice"
clearly says it's a dummy package.

> Severity: normal

Sigh.

How it is a bug when LO does what it's supposed to do in case people want to
sign their documents (with S/MIME, gpg is something else) *and which is 
documented*?

https://help.libreoffice.org/4.4/Common/Applying_Digital_Signatures
(of course also valid for later versions, this is just a result of googling.)


https://wiki.openoffice.org/wiki/How_to_use_digital_Signatures


That's what it is for. Signing documents with S/MIME.

> I'm seeing many entries like these in my log:

If you look at your logs (which is good) I would also expect you being able to 
do a basic resarch
(see above) instead of filing a "bug" which then will linger around until 
eternity :-(

> operation="open" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> comm="soffice.bin" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000
> operation="file_lock" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000

Access to the Mozilla profile is completely expected in how it's

(The apparmor profiles allow "r", not "w". (Have to lookup what "c" is.) which 
is correct since

LO should only be able to read the certs).

 
Key *management* is something LO should not do and cannot do anyway. (same with 
gpg)

> operation="open" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/key4.db" pid=486621 
> comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
> operation="file_lock" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/key4.db" pid=486621 
> comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000

Oh, that one's new.

I added the cert?.db ones once.

Since when does LO (and/or nss and or libxmlsec-nss) want key4.db, too?
(But I'd only allow r anyways.)

 
I guess I need to check whether signing works when the profile is in
enforcing again...

> LibreOffice tries to access the key storage of Firefox, which is really
> strange.

No, it isn't.

A few minutes' research would have shown you that it uses nss and the
certificates from Firefox (or Thundebird or SeaMonkey..):

https://www.google.com/search?q=libreoffice+firefox+profile=1C1GCEU_deDE843DE846=libreoffi=chrome.1.69i60j69i59j69i57j69i60l3j69i65j69i60.2319j0j7=chrome=UTF-8

Second and fourth hit.

(That also shows https://bugs.documentfoundation.org/show_bug.cgi?id=119811
where an other user just reports a "bug" because of something unexepctedly 
("no visiable reasons"...)

Yes, it's 
Marking as forwarded to this "bug" though.

> Isn't it possible to use the keys in /etc/ssl?

a) as said it uses nss instead of the "standard" openssl, and has to use
   what nss expects
b) how are you going to add signing certificates as user to /etc/ssl without
   being root?

How does a end-user know (s)he needs to add stuff there? There (ttbomk) 
unfortunately also is no standardized patch for certs in users' $HOMEs.

And (unfortunately) LO wants to cater for end-users with no clue instead of
doing the correct thing(tm).

Regards,

Rene

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

2020-11-27 Thread Jörg Sommer 
Package: libreoffice
Version: 1:7.0.3-4+b1
Severity: normal

Hi,

I'm seeing many entries like these in my log:

```
operation="open" profile="libreoffice-soffice" 
name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
comm="soffice.bin" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000
operation="file_lock" profile="libreoffice-soffice" 
name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000
operation="open" profile="libreoffice-soffice" 
name="/home/joerg/.mozilla/firefox/aelzkv52.dev/key4.db" pid=486621 
comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
operation="file_lock" profile="libreoffice-soffice" 
name="/home/joerg/.mozilla/firefox/aelzkv52.dev/key4.db" pid=486621 
comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000
```

LibreOffice tries to access the key storage of Firefox, which is really
strange. Isn't it possible to use the keys in /etc/ssl?

Regards Jörg


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice depends on:
ii  libreoffice-base1:7.0.3-4+b1
ii  libreoffice-calc1:7.0.3-4+b1
ii  libreoffice-core1:7.0.3-4+b1
ii  libreoffice-draw1:7.0.3-4+b1
ii  libreoffice-impress 1:7.0.3-4+b1
ii  libreoffice-math1:7.0.3-4+b1
ii  libreoffice-report-builder-bin  1:7.0.3-4+b1
ii  libreoffice-writer  1:7.0.3-4+b1
ii  python3-uno 1:7.0.3-4+b1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-2
ii  fonts-liberation1:1.07.4-11
pn  fonts-liberation2   
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-core 20201109-1
pn  fonts-noto-extra
pn  fonts-noto-mono 
ii  fonts-noto-ui-core  20201109-1
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:7.0.3-4
pn  libreoffice-nlpsolver   
pn  libreoffice-report-builder  
pn  libreoffice-script-provider-bsh 
pn  libreoffice-script-provider-js  
pn  libreoffice-script-provider-python  
pn  libreoffice-sdbc-mysql  
pn  libreoffice-sdbc-postgresql 
pn  libreoffice-wiki-publisher  

Versions of packages libreoffice suggests:
pn  cups-bsd
ii  default-jre [java8-runtime] 2:1.11-72
ii  firefox 83.0-1
ii  ghostscript 9.53.3~dfsg-5
ii  gnupg   2.2.20-1
pn  gpa 
ii  gstreamer1.0-libav  1.18.1-1
ii  gstreamer1.0-plugins-bad1.18.1-1
ii  gstreamer1.0-plugins-base   1.18.1-1
ii  gstreamer1.0-plugins-good   1.18.1-1
pn  gstreamer1.0-plugins-ugly   
ii  hunspell-de-de [hunspell-dictionary]20161207-8
ii  hunspell-en-gb [hunspell-dictionary]1:7.0.1-1
ii  hunspell-en-us [hunspell-dictionary]1:2019.10.06-1
ii  hyphen-de [hyphen-hyphenation-patterns] 1:7.0.1-1
ii  hyphen-en-gb [hyphen-hyphenation-patterns]  1:7.0.1-1
ii  imagemagick 8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick] 8:6.9.11.24+dfsg-1+b2
ii  libgl1  1.3.2-1
pn  libofficebean-java  
pn  libreoffice-gnome | libreoffice-plasma  
pn  libreoffice-grammarcheck
pn  libreoffice-help
ii  libreoffice-l10n-de [libreoffice-l10n]  1:7.0.3-4
pn  libreoffice-librelogo   
ii  libsane11.0.31-3
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
ii  mythes-de [mythes-thesaurus]20160424-3
ii  mythes-de-ch [mythes-thesaurus]