Bug Hunting Session
Bug 80755 - StartCenter displays thumbnails of password-protected files
Summary: StartCenter displays thumbnails of password-protected files
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.3.0.1 rc
Hardware: Other All
: highest critical
Assignee: Maxim Monastirsky
URL:
Whiteboard: BSA target:4.4.0 target:4.3.2
Keywords: bibisectRequest, regression
: 81839 81859 81866 82015 82037 82178 82554 82944 83000 83231 83425 83447 84050 84247 84397 84453 84547 85074 87307 (view as bug list)
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2014-07-01 09:59 UTC by eamonfitzpatrick
Modified: 2015-12-17 08:24 UTC (History)
27 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description eamonfitzpatrick 2014-07-01 09:59:40 UTC
The startcenter has started showing the content of password protected ODS, ODT and xlxs in the preview.

It seems to happen with all my documents.

These apreview is persistent after closing the app and reopening/rebooting as if its caching the imag on file open.

This behaviour only occurs after the document has been opened in 4.3.0.1

Obviously this is a major confidentiality issue

No real reason for attachments/images as the behaviour appears consistent.
              
Operating System: Mac OS X
Version: 4.3.0.1 rc
Last worked in: 4.2.5.2 release
Comment 1 ign_christian 2014-07-01 12:59:14 UTC
Confirmed in 4.3.0.1 - Ubuntu 12.04 x86. Just tried with ODS, XLS, XLSX.

I think it's not regression since doc preview it's just implemented in 4.3. 
But I raise the importance since it's about confidentiality.
Comment 2 V Stuart Foote 2014-07-01 14:29:12 UTC
If not honoring password set status, then possibly related to work for enhancement of fdo bug 61320 and http://cgit.freedesktop.org/libreoffice/core/commit/?id=0035b3218d8652652e62afe89eddfd28a9021b75
Comment 3 ign_christian 2014-07-29 04:39:42 UTC
*** Bug 81859 has been marked as a duplicate of this bug. ***
Comment 4 ign_christian 2014-07-29 05:37:14 UTC
*** Bug 81839 has been marked as a duplicate of this bug. ***
Comment 5 Maxim Monastirsky 2014-07-29 09:51:51 UTC
*** Bug 81866 has been marked as a duplicate of this bug. ***
Comment 6 manj_k 2014-08-01 15:45:23 UTC
*** Bug 82015 has been marked as a duplicate of this bug. ***
Comment 7 V Stuart Foote 2014-08-01 17:16:08 UTC
Isn't the issue here, rather than the generation of previews (suppression handled with an Expert Confuration stanza-- objstor.cxx -- bug 61320), that the LO defaults now are for a HistoryItem thumbnail preview to be written in base64 to the HistoryInfo for each element of the recent document list.

ref: unotools/historyoptions.hxx  HISTORY_PROPERTYNAME_THUMBNAIL

So, a thumbnail preview, in addition to being added to the ODF document (or not), is also being recorded for each document into each user's profile in the registrymodifications.xcu file,  and isn't that where the StartCenter preview is being pulled from?

So, if preview of Password protected documents in the StartCenter are not desiered, seems that should be handled with an Expert Configuration stanza to not store a base64 thumbnail with the HistoryInfo for those items.
Comment 8 ign_christian 2014-08-02 04:18:48 UTC
*** Bug 82037 has been marked as a duplicate of this bug. ***
Comment 9 Adolfo Jayme 2014-08-05 07:06:50 UTC
*** Bug 82178 has been marked as a duplicate of this bug. ***
Comment 10 Yousuf Philips (jay) (retired) 2014-08-05 07:17:40 UTC
Adding this as a regression as this behaviour didnt happen with 4.2 with odt files and now does.
Comment 11 Eike Rathke 2014-08-06 09:01:38 UTC
@Kendy:
Looks like http://cgit.freedesktop.org/libreoffice/core/commit/?id=e2eda70f2746f08376d8cdf5e5360df217335aef is causing this, it should not generate a thumbnail if a password is set.
Comment 12 Maxim Monastirsky 2014-08-13 12:09:01 UTC
*** Bug 82554 has been marked as a duplicate of this bug. ***
Comment 13 Maxim Monastirsky 2014-08-22 11:11:27 UTC
*** Bug 82944 has been marked as a duplicate of this bug. ***
Comment 14 Jean-Baptiste Faure 2014-08-24 08:26:44 UTC
*** Bug 83000 has been marked as a duplicate of this bug. ***
Comment 15 Jean-Baptiste Faure 2014-08-24 08:36:38 UTC
Setting priority to highest as this is a MAB. This is part of an effort to make
the importance of MAB reflected in priority too.

Best regards. JBF
Comment 16 Commit Notification 2014-08-24 10:41:46 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a75e0f8e4e5f0baa5805d01c5f8edc7b40fceb0f

fdo#80755 Don't generate thumbnails for encrypted files



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 17 Jean-Baptiste Faure 2014-08-25 09:29:11 UTC
Thank you very much Maxim for this fix. It works for me on existing password protected files if I modify the file properties (menu File > Properties). It seems it is not enough to save again the document in the master.

Do you plan to backport your fix to the 4.3 branch ?

Best regards. JBF
Comment 18 retired 2014-08-25 10:50:55 UTC
Is this fixed or are parts missing? Assigning Maxim.
Comment 19 Maxim Monastirsky 2014-08-25 12:31:18 UTC
(In reply to comment #17)
> It works for me on existing password
> protected files if I modify the file properties (menu File > Properties).
Hmm... it doesn't work for me that way. As long as the file is in the recent list, it will show a thumbnail. Only doing Save As or clearing the recent list (or at least removing the individual file) would help.

> It seems it is not enough to save again the document in the master.
Actually in that case the last saved thumbnail will show (which doesn't necessarily reflect the current look of the document). No new thumbnail will be generated. The reason is that the current code doesn't overwrite existing thumbnail with an empty one. I can of course change this, but I wonder whether
it's a good idea?

> Do you plan to backport your fix to the 4.3 branch ?
Sure.
Comment 20 V Stuart Foote 2014-08-25 14:10:20 UTC
(In reply to comment #16)
> Affected users are encouraged to test the fix and report feedback.
On windows 7 sp1 64-bit, en-US with
Version: 4.4.0.0.alpha0+
Build ID: 32ce5ae15a8f156b4681c36d248b6731df3457c6
TinderBox: Win-x86@42, Branch:master, Time: 2014-08-25_01:27:12

The thumbnail view inserted on the Start Center is now the generic ODF icon by document type.  Verified with an ODT and ODG document, so looks correct.
Comment 21 retired 2014-08-25 14:46:00 UTC
verified on OSX 10.9.4 as well.

>> "the current code doesn't overwrite existing thumbnail with an empty one. I can of course change this, but I wonder whether it's a good idea?"

I'm unsure about that. Having a clean solution would be great. But on the other hand, this is now fixed and there's always the workaround of manually removing the files from the start center.

So instead of spending more dev time on this specific issue and potentially introduce other problems, I think it's best to go with the fix as is.
Comment 22 retired 2014-08-25 14:47:13 UTC
Oh and thanks for tackling this most critical bug. Depending on your environment this is a rather dangerous bug and users privacy and security should be taken serious. So it's great to see this bug go.
Comment 23 Jean-Baptiste Faure 2014-08-26 05:26:54 UTC
As this bug is a MAB for 4.3, shouldn't we wait for the backport and verification on 4.3 to mark it as verified fixed?

Best regards. JBF
Comment 24 retired 2014-08-26 07:26:23 UTC
Afaik there's no policy for that. Those waiting / pending states do not exist in bugzilla. So feel free to proceed as you like. But yes, since it's a critical fix, maybe should be tested on 4.3 as well as soon as the backport is there.
Comment 25 Commit Notification 2014-08-26 11:47:18 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a628ea1cd72585b889d591052680ebf79887dcef&h=libreoffice-4-3

fdo#80755 Don't generate thumbnails for encrypted files


It will be available in LibreOffice 4.3.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 26 Jean-Baptiste Faure 2014-08-27 04:22:28 UTC
Verified fixed in version 4.3.2.0.0+ (Build ID: ff518ba8a6d2ed88c7992ead856d7f7987a04919) build at home under Ubuntu 14.04 x86-64.

Thank you very much, Maxim !

Best regards. JBF
Comment 27 Maxim Monastirsky 2014-08-29 08:33:42 UTC
*** Bug 83231 has been marked as a duplicate of this bug. ***
Comment 28 Maxim Monastirsky 2014-09-03 17:32:55 UTC
*** Bug 83447 has been marked as a duplicate of this bug. ***
Comment 29 Maxim Monastirsky 2014-09-04 08:23:47 UTC
*** Bug 83425 has been marked as a duplicate of this bug. ***
Comment 30 raal 2014-09-18 16:29:20 UTC
*** Bug 84050 has been marked as a duplicate of this bug. ***
Comment 31 Jean-Baptiste Faure 2014-09-23 15:07:45 UTC
*** Bug 84247 has been marked as a duplicate of this bug. ***
Comment 32 Adolfo Jayme 2014-09-27 17:27:38 UTC
*** Bug 84397 has been marked as a duplicate of this bug. ***
Comment 33 Jean-Baptiste Faure 2014-09-29 08:50:38 UTC
*** Bug 84453 has been marked as a duplicate of this bug. ***
Comment 34 Jean-Baptiste Faure 2014-10-01 10:13:56 UTC
*** Bug 84547 has been marked as a duplicate of this bug. ***
Comment 35 m.a.riosv 2014-10-15 23:22:00 UTC
*** Bug 85074 has been marked as a duplicate of this bug. ***
Comment 36 Rudolf Kollien 2014-11-04 14:45:04 UTC
Still occurs in a little different behavour in 4.3.3.2. 
When you create a NEW document and save it password protected, than the created document is shown in the start center with as readable thumbnail! Only when you remove the thumbnail from the start center and reopen the document with "File->Open" it is recognized as a protected document an the thumbnail is iconized.
Comment 37 Maxim Monastirsky 2014-11-04 15:06:23 UTC
(In reply to Rudolf Kollien from comment #36)
> Still occurs in a little different behavour in 4.3.3.2. 
> When you create a NEW document and save it password protected, than the
> created document is shown in the start center with as readable thumbnail!
Can't reproduce with 4.3.3.2 under Fedora 20. Could you please try with a clean profile?

(One thing that could happen is that you had in the past some non-protected document with the same path. Each time you open the start center, it checks the availability of all the recent files. If some file is missing - it doesn't remove it from the list, but just hides it. So it's possible that the thumbnail actually left from an old file with the same name, that you had at some point in the past.)
Comment 38 Rudolf Kollien 2014-11-04 15:31:22 UTC
In this case unfortunately no: it's a completely new document with an unique name. Never had a document named like the one.
Comment 39 Stamatis 2014-11-04 17:49:44 UTC
I can confirm the following:

* If you open a NEW file and save it first time round with a password, then NO content is displayed in the thumbnail. (Desired behaviour)

* If you have a normal unprotected file already written before and you decide to save it with a password, then some content of the file (taken before the password implementation) is still visible in the thumbnail. (Can be undesired)

Version: 4.3.2.2.0+ Build ID: 430m0(Build:2) backport on Debian Wheezy
Comment 40 Maxim Monastirsky 2014-11-04 18:35:17 UTC
(In reply to Rudolf Kollien from comment #38)
> In this case unfortunately no: it's a completely new document with an unique
> name. Never had a document named like the one.
I'm repeating my request: Please try with a new profile. (You can backup your current profile, and put it in place after testing, so you won't lose any of your settings.)
Comment 41 Rudolf Kollien 2014-11-05 12:28:44 UTC
Can confirm this on 4.3.3.2 MacOSX.

Created NEW profile with NEW user and performed the described steps. Results as described by Stamatis. 

(In reply to Stamatis from comment #39)
> I can confirm the following:
> 
> * If you open a NEW file and save it first time round with a password, then
> NO content is displayed in the thumbnail. (Desired behaviour)
> 
> * If you have a normal unprotected file already written before and you
> decide to save it with a password, then some content of the file (taken
> before the password implementation) is still visible in the thumbnail. (Can
> be undesired)
> 
> Version: 4.3.2.2.0+ Build ID: 430m0(Build:2) backport on Debian Wheezy
Comment 42 Maxim Monastirsky 2014-11-05 14:04:58 UTC
So basically the issue now is with overwriting previously non-protected document, with a protected version? In that case it was kind of expected according to what I wrote in comment 19 (that we don't remove old thumbnail if there's no new one). but I thought it will be only an issue when upgrading to the non-affected version, and I definitely didn't take into account this particular use-case. So I would like to know, how common is this scenario / how much is this annoying?
Comment 43 Rudolf Kollien 2014-11-05 16:02:02 UTC
I think, it isn't so uncommon. When writing a new document, i always emphasize my users to strictly save the document before printing. Once the (new) document is finished, the user decides if the content is confidential and password protected or not.

The other point of view is: Shouldn't the thumbnail reflect the contents/layout of the document? In this case, i mean, the thumbnail must always be updated on closing/saving the document. At this point, password protection can be recognized and the thumbnail can be removed or simply updated as "confidental" or "secret" or something else. Or i'm wrong?
Comment 44 Stamatis 2014-11-05 17:32:08 UTC
I think that this scenario (retro-password protect an existing file) is quite common with users and I second the idea that once password is in place the thumbnail should become a generic one, independently of any previous instances.
Comment 45 Commit Notification 2014-11-09 20:00:12 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1166966eb4112fdf332c656eae5082d82a3ec2f2

Related: fdo#80755 Always update the thumbnail

It will be available in 4.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 46 Maxim Monastirsky 2014-11-09 20:06:59 UTC
Now the thumbnail is always updated, so resaving with a password will remove the old thumbnail. Please test it with 4.4 daily, and if there are no apparent regressions (like missing thumbnails in some cases), I think it should be possible to backport this to 4.3 as well.
Comment 47 Maxim Monastirsky 2014-12-14 20:09:21 UTC
*** Bug 87307 has been marked as a duplicate of this bug. ***
Comment 48 Robinson Tryon (qubit) 2015-12-17 08:24:52 UTC
Migrating Whiteboard tags to Keywords: (bibisectRequest)
[NinjaEdit]