Bug 86780 - LibreOffice Signed binaries appear to have been time stamped incorrectly after certificate expires
Summary: LibreOffice Signed binaries appear to have been time stamped incorrectly afte...
Status: RESOLVED MOVED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: ci-infra (show other bugs)
Version:
(earliest affected)
4.3.4.1 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL: http://msdn.microsoft.com/en-us/libra...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-27 10:37 UTC by charlie.quinnpub
Modified: 2015-02-19 09:58 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing issue (62.82 KB, image/jpg)
2014-11-27 10:37 UTC, charlie.quinnpub
Details

Note You need to log in before you can comment on or make changes to this bug.
Description charlie.quinnpub 2014-11-27 10:37:29 UTC
Created attachment 110122 [details]
Screenshot showing issue

If you look at the Digital Signature Details for LibreOffice binaries after a certificate has expired it shows that the required certificate is not within its validity period even though the file was correctly signed before the certificate has expired.

This is not usual and can lead to issues within the Windows environment (see below).

I think this is because when these binaries are signed the “Lifetime Signing” EKU is set.

You can tell this is happening by looking at the Countersignatures. Timestamp which always shows the current time (see attached screenshot).


This can cause poor performance when the LibreOffice is operating and although unlikely could potentially cause some anti-malware vendors to incorrectly classify LibreOffice binaries as malware.
Comment 1 Robinson Tryon (qubit) 2014-12-09 20:16:00 UTC
(In reply to charlie.quinnpub from comment #0)
> If you look at the Digital Signature Details for LibreOffice binaries after
> a certificate has expired it shows that the required certificate is not
> within its validity period even though the file was correctly signed before
> the certificate has expired.
> 
> I think this is because when these binaries are signed the “Lifetime
> Signing” EKU is set.

Do you have a suggestion on how we should configure the signing environment to avoid this problem?
Comment 2 Christian Lohmaier 2014-12-09 21:50:26 UTC
this is more or less a wontfix.

Of course we cannot fix the already released builds, and not sure whether TDF will switch certificates... (nothing needs to be changed in the code though)

The problem is not wrong way of signing, but as it turns out the certificate (we use Class 2 code-signing certificate from StartCom) actually has a flag that limits the validity of the signature to that of the certificate (doh!)

I didn't know of that flag, so I (and I guess everyone else) assumed that timestamping the builds will take care of things..

Our certificate has the 
1.3.6.1.4.1.311.10.3.13 - Microsoft's OID "szOID_KP_LIFETIME_SIGNING" defined.

We'd need an "Extended Validation" type that doesn't have that restriction (but of course also costs more)...

Anyway, confirmed.