How do I verify my LO installer? Where are the public keys?

Updating this question to reorganize relevant information:

I’ve downloaded the MSI installer, ver. 6.3.4, for Windows 10 (64bit), as well as the keys and offline help installer from the LibreOffice downloads page.

  • Windows MSI installer file size matches what is stated on the downloads page.
  • The MSI hashes match:


“>certutil -hashfile LibreOffice_6.3.4_Win_x64.msi sha256


SHA256 hash of LibreOffice_6.3.4_Win_x64.msi:


94b2b86b5688685233479d594e5760ce24d5b9a00e33058f4b86dffd08b54574


CertUtil: -hashfile command completed successfully.”

My question is, how do I verify the integrity of the keys before importing them (so that I can verify the download using gpg)? I expected to find some reference to the output I should see once I verified the file. I could not find anything saying what I should expect; I’ve searched through a variety of sources including Googling the RSA key, but no luck:

This was my output prior to importing the key (I forgot to do that before verifying, sorry)

“>gpg --verify LibreOffice_6.3.4_Win_x64.msi.asc LibreOffice_6.3.4_Win_x64.msi


gpg: Signature made 12/10/19 05:32:29 Eastern Standard Time


gpg: using RSA key C2839ECAD9408FBE9531C3E9F434A1EFAFEEAEA3


gpg: Can’t check signature: No public key”

This was my output after importing it (which is what I was expecting)

">gpg --verify LibreOffice_6.3.4_Win_x64.msi.asc LibreOffice_6.3.4_Win_x64.msi


gpg: Signature made 12/10/19 05:32:29 Eastern Standard Time


gpg: using RSA key C2839ECAD9408FBE9531C3E9F434A1EFAFEEAEA3


gpg: Good signature from “LibreOffice Build Team (CODE SIGNING KEY) build@documentfoundation.org [unknown]


gpg: WARNING: This key is not certified with a trusted signature!


gpg: There is no indication that the signature belongs to the owner.


Primary key fingerprint: C283 9ECA D940 8FBE 9531 C3E9 F434 A1EF AFEE AEA3”

I know that my question may seem unecessarily pedantic, but how do I verify the integrity of the RSA key if the host doesn’t provide some reference to what I expect? For example, some sites may say something like “the key will end in F434 A1EF AFEE AEA3” but I can’t seem to find anything. How do I know the key is authentic?

1 Like

Please next time, when you feel you actually need a wall of text, still try to put some crucial information to the top. Of course, it’s important to note that you tried to search; it’s important to explain your expectations; but what’s most important is steps you made and results you got. I.e.: you are using [this OS]; you downloaded installer from [here]; you also got SHA hashes and PGP signature from [there]; you used [this] command to verify the download using [this software]; you got [this result] - while you expected [this]; the question is [this]. And then - that you googled and found those results; why you feel it’s important; … whatever you feel necessary. That would allow reader to grasp the problem quickly, and not need to re-read several times to understand the actual problem. Remember that not everyone here is native English speaker. Thanks.

Remember that not everyone here is native English speaker.

I’d estimate that most of those who give meaningful answers here are not native speakers. Just to emphasize Mike’s point.

I want to apologize for the mess of a question. I have bad forum etiquette that I need to improve, and I ramble. I hope the changes make the problem more clear (which, in essence, is an exercise in paranoia and integrity checking).

I also want to apologize for rambling, because I was frustrated and trying to convey what I was looking for, I didn’t think of users who are nonnative-english speakers. This is something I will keep in mind in the future. Thank you.

Hi GCobbe,

I don’t know what changes you made to your post, but as of 2022-01-17, your post that started this discussion thread is pretty clear to me. I found it because I was searching for a solution to the exact same problem you had: how can I trust a signed file when the signer failed to also publish his/her public key?

In short, I found your question useful, so thanks for posting it. I’m sure there are A LOT of other people who are - or have been - in the same boat as I am in right now.

P.S. I registered with this message board just to reply to your post, and now that I see what I wrote, I’m wondering why pressing the enter key twice did not result in a space between paragraphs.

Using Kleopatra, when you have the result screen having “With unavailable certificate:” text, you can Search for the certificate:

image description

Thank you very much, Mike. First I didn’t know you could embed gifs in comments, that’s really helpful.

This is actually what I had done when importing the key, instead of importing the *.asc that I downloaded from the info page using the cmd shell.

For all intents and purposes, this is an acceptable solution to my problem. On the other hand, I don’t know how to verify that the key is correct. Using Kleopatra is probably proof enough, but in trying to exercise best practices I want to make an attempt to verify the key before importing it.

I should also make a note here, I understand that integrity checks and verification can be an absurd practice of severe paranoia all the way up the chain of custody, but I try to cut off my own pursuit of verification at the public/private key level (for the sanity of myself and others).

1 Like

I was thinking the exact same thing as you, GCobbe: if we make the mistake of downloading a fraudulent/counterfeit signing key like “LibreOffice_7.1.8_Win_x64.msi.asc,” how can we be sure that the name of the RSA Key/Public key we retrieved from inside the signing key is legitimate?
If someone published a fraudulent signing key, that fraudster would likely alter the signing key so that it points to their own fraudulent public key - not the legitimate public key of the software’s original author.

When I tried using Kleopatra without already having the code signing key, Kleopatra is unable to find the certificate. Attempting to open the .asc file, Kleopatra didn’t tell me the key ID, but GNU Privacy Assistant did.

So:

  1. Download libreoffice installer and matching .asc file.

  2. Run Kleopatra (Windows). File>[Lookup on Server] Find:“LibreOffice Code”. (Or Find: “AFEEAEA3”) Import the “LibreOffice Build Team (CODE SIGNING KEY)”.

  3. Use Kleopatra. File>[Decrypt/Verify] Filename: “xxxxxxxx.asc”.

On OSX, I have found it easy to use Terminal:

$ gpg --keyserver hkp://keys.gnupg.net --recv-keys AFEEAEA3

$ gpg --verify xxxxxxxx.asc

(IIRC, gpg --verify will identify the missing public key ID just like GNU Privacy Assistant.)

How would you know to search for “AFEEAEA3” unless you assume that the data inside the signing file is already legit? If a hacker uploaded a phony signing key onto the publisher’s website, the hacker would change the KEY ID listed in the phony signing key. The only people who would know the new signing key is false are those who already got the legit KEY ID or public key from the real publisher.