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
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.
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
*** Bug 81859 has been marked as a duplicate of this bug. ***
*** Bug 81839 has been marked as a duplicate of this bug. ***
*** Bug 81866 has been marked as a duplicate of this bug. ***
*** Bug 82015 has been marked as a duplicate of this bug. ***
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.
*** Bug 82037 has been marked as a duplicate of this bug. ***
*** Bug 82178 has been marked as a duplicate of this bug. ***
Adding this as a regression as this behaviour didnt happen with 4.2 with odt files and now does.
@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.
*** Bug 82554 has been marked as a duplicate of this bug. ***
*** Bug 82944 has been marked as a duplicate of this bug. ***
*** Bug 83000 has been marked as a duplicate of this bug. ***
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
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.
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
Is this fixed or are parts missing? Assigning Maxim.
(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.
(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.
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.
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.
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
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.
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.
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
*** Bug 83231 has been marked as a duplicate of this bug. ***
*** Bug 83447 has been marked as a duplicate of this bug. ***
*** Bug 83425 has been marked as a duplicate of this bug. ***
*** Bug 84050 has been marked as a duplicate of this bug. ***
*** Bug 84247 has been marked as a duplicate of this bug. ***
*** Bug 84397 has been marked as a duplicate of this bug. ***
*** Bug 84453 has been marked as a duplicate of this bug. ***
*** Bug 84547 has been marked as a duplicate of this bug. ***
*** Bug 85074 has been marked as a duplicate of this bug. ***
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.
(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.)
In this case unfortunately no: it's a completely new document with an unique name. Never had a document named like the one.
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
(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.)
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
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?
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?
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.
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.
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.
*** Bug 87307 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]