Bug 125579 - Redaction function against TSCP protected file losses watermark in final PDF file
Summary: Redaction function against TSCP protected file losses watermark in final PDF...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 126082 (view as bug list)
Depends on:
Blocks: Redaction
  Show dependency treegraph
 
Reported: 2019-05-29 13:05 UTC by Drew Jensen
Modified: 2020-05-30 08:00 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Absolute simplest case - empty .odt marked as Confidential (13.00 KB, application/vnd.oasis.opendocument.text)
2019-05-29 13:05 UTC, Drew Jensen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2019-05-29 13:05:30 UTC
Created attachment 151761 [details]
Absolute simplest case - empty .odt marked as Confidential

test system Ubuntu 18.04.1 with Version: 6.3.0.0.alpha1+
Build ID: 40e2a0d7039eee9c5377996da3949680903e1016
CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: kde5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-22_13:55:35
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded


Steps to reproduce:

1 - Open the attached file in Writer.

2 - Select Tools->Redact

Result: 
.odg file opened in Draw does not have the water mark 'confidential' in the background, though there is a bit of a 'C' there.

Expected result:
The .odg file would maintain the water mark appropriate for the TSCP classification.
Comment 1 Drew Jensen 2019-05-29 13:13:22 UTC
I linked in the developer:

To be honest I'm not sure if this is an issue or a feature. I can't remember how this was handled in "Orange Book Compliant" systems I worked on in the past, but I kind of think the watermarks stay.
Comment 2 Muhammet Kara 2019-05-29 13:46:58 UTC
Hmm. Having the C there is a symptom of a bug. We should either preserve the confidential background or not. No partial remnants.

I wonder if it behaves the same way maybe before d5b59b8d9d798b884dbcf0c97f403d739b01e1cc
Comment 3 raal 2019-06-01 07:31:49 UTC
This seems to have begun at the below commit.

f9801f37701bc53faec64c1fdb85da27a4d16e36 is the first bad commit
commit f9801f37701bc53faec64c1fdb85da27a4d16e36
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Mon May 6 19:00:37 2019 +0200

    source sha:2ff22c0bf4c23c4bed9ccfcfa79dff848086650d

author	Muhammet Kara <muhammet.kara@collabora.com>	2019-05-03 22:07:59 +0300
committer	Muhammet Kara <muhammet.kara@collabora.com>	2019-05-06 16:49:16 +0200
commit	2ff22c0bf4c23c4bed9ccfcfa79dff848086650d (patch)
tree	5b33fca87caa56c093b6dcca3575855aa73480ee
parent	e2c2136dccbf2f4800ca4adc04911b6258a179fe (diff)
tdf#125135: Standardize content placement for redaction
Correct the position & size by roundtrip conversion
from/to wmf as a temporary solution.
Comment 4 Muhammet Kara 2019-06-01 07:36:35 UTC
(In reply to raal from comment #3)
> This seems to have begun at the below commit.
> 
> f9801f37701bc53faec64c1fdb85da27a4d16e36 is the first bad commit
> commit f9801f37701bc53faec64c1fdb85da27a4d16e36
> Author: Jenkins Build User <tdf@pollux.tdf>
> Date:   Mon May 6 19:00:37 2019 +0200
> 
>     source sha:2ff22c0bf4c23c4bed9ccfcfa79dff848086650d
> 
> author	Muhammet Kara <muhammet.kara@collabora.com>	2019-05-03 22:07:59 +0300
> committer	Muhammet Kara <muhammet.kara@collabora.com>	2019-05-06 16:49:16
> +0200
> commit	2ff22c0bf4c23c4bed9ccfcfa79dff848086650d (patch)
> tree	5b33fca87caa56c093b6dcca3575855aa73480ee
> parent	e2c2136dccbf2f4800ca4adc04911b6258a179fe (diff)
> tdf#125135: Standardize content placement for redaction
> Correct the position & size by roundtrip conversion
> from/to wmf as a temporary solution.

That's what I was suspecting. Thank you for confirming!
Comment 5 Muhammet Kara 2019-06-01 07:39:49 UTC
Please note that it will take a while to fix this because it is result of a workaround for another (bigger) problem.
Comment 6 Drew Jensen 2019-06-02 14:22:17 UTC
(In reply to Muhammet Kara from comment #5)
> Please note that it will take a while to fix this because it is result of a
> workaround for another (bigger) problem.

Understood. 

Thinking about this further and using the tool a bit more, just to let you know there is a rfe in my mind regarding TSCP and Redaction Preview rendering. But that is something that would best be done I suppose by starting a conversation about it, as a future upgrade. An email on the dev ml about that first then, just to give you heads up.
Comment 7 raal 2019-06-25 20:41:38 UTC
*** Bug 126082 has been marked as a duplicate of this bug. ***
Comment 8 Muhammet Kara 2019-08-06 09:36:36 UTC
Has been in the assigned state for too long. I am busy with other parts of the redaction feature, so if anyone feels like taking a look at this, don't hesitate to assign it to yourself, but please keep in touch with me to avoid conflicts.