You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Tilman Hausherr <TH...@t-online.de> on 2015/07/11 19:44:53 UTC
calling protect() after setAllSecurityToBeRemoved(true)
Yesterday user Roberto had a problem where a file wasn't saved with
encryption. The cause turned out to be that he had called
setAllSecurityToBeRemoved(true)
and then
protect(...)
I didn't find it by looking at his code, only after debugging in save().
Although the javadoc of both calls is clear, I see a risk that this
happens again, e.g. when people combine existing code.
What should be do? Options:
1. nothing
2. mention the risk in javadoc
3. if allSecurityToBeRemoved is true in protect(), call LOG.warn("call
setAllSecurityToBeRemoved(false) before saving or file won't be
encrypted");
4. if allSecurityToBeRemoved is true in protect(), throw an
IllegalStateException
5. set allSecurityToBeRemoved to false when protect() is called
I'm for options 3 or 4.
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org
Re: calling protect() after setAllSecurityToBeRemoved(true)
Posted by Andreas Lehmkühler <an...@lehmi.de>.
Hi,
> Maruan Sahyoun <sa...@fileaffairs.de> hat am 11. Juli 2015 um 19:56
> geschrieben:
>
>
> Hi
>
> > Am 11.07.2015 um 19:44 schrieb Tilman Hausherr <TH...@t-online.de>:
> >
> > Yesterday user Roberto had a problem where a file wasn't saved with
> > encryption. The cause turned out to be that he had called
> >
> > setAllSecurityToBeRemoved(true)
> >
> > and then
> >
> > protect(...)
> >
> > I didn't find it by looking at his code, only after debugging in save().
> >
> > Although the javadoc of both calls is clear, I see a risk that this happens
> > again, e.g. when people combine existing code.
> >
> > What should be do? Options:
> >
> > 1. nothing
> > 2. mention the risk in javadoc
> > 3. if allSecurityToBeRemoved is true in protect(), call LOG.warn("call
> > setAllSecurityToBeRemoved(false) before saving or file won't be encrypted");
> > 4. if allSecurityToBeRemoved is true in protect(), throw an
> > IllegalStateException
> > 5. set allSecurityToBeRemoved to false when protect() is called
> >
> > I'm for options 3 or 4.
>
> I'd go for option 5 together with a warning as the call to protect() shows the
> intention and add that to the javadocs.
+1
BR
Andreas
> BR
> Maruan
>
>
> >
> > Tilman
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> > For additional commands, e-mail: dev-help@pdfbox.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org
Re: calling protect() after setAllSecurityToBeRemoved(true)
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi
> Am 11.07.2015 um 19:44 schrieb Tilman Hausherr <TH...@t-online.de>:
>
> Yesterday user Roberto had a problem where a file wasn't saved with encryption. The cause turned out to be that he had called
>
> setAllSecurityToBeRemoved(true)
>
> and then
>
> protect(...)
>
> I didn't find it by looking at his code, only after debugging in save().
>
> Although the javadoc of both calls is clear, I see a risk that this happens again, e.g. when people combine existing code.
>
> What should be do? Options:
>
> 1. nothing
> 2. mention the risk in javadoc
> 3. if allSecurityToBeRemoved is true in protect(), call LOG.warn("call setAllSecurityToBeRemoved(false) before saving or file won't be encrypted");
> 4. if allSecurityToBeRemoved is true in protect(), throw an IllegalStateException
> 5. set allSecurityToBeRemoved to false when protect() is called
>
> I'm for options 3 or 4.
I'd go for option 5 together with a warning as the call to protect() shows the intention and add that to the javadocs.
BR
Maruan
>
> Tilman
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org