From: Michal H. <ms...@gm...> - 2008-09-17 01:57:44
|
On Wed, Sep 17, 2008 at 03:28:46AM +0200, Martin Petricek wrote: > > You can't get any password, because nothing like this is implemented in > > the Base::delinearize method... Although we can simply add password > > dialog, but there are 2 problems: > > - this will effectively allow writing decrypted content of > > document because we are _not_ writing objects in encrypted > > form. I am not sure whether this is legal. So attached > > This could be used to get around the "DRM" in PDF, but if you have ordinary > document with password (and not only encryption-because-of-drm), then it is > not a DRM problem. Also pdfedit won't know whether you are author of the > document and you are merely editing it or you are someone else and should > be denied access. Other packages more or less ignore these flags too ... > how does the Adobe Acrobat solve this problem if you create encrypted > document and then you want to edit it? Wasn't there something like owner > and user password? > > I am not sure about the laws about this. These differ by country, they'll > be different in Czech. Rep (where I live), Slovakia or in USA (I think > sourceforge is hosted mainly there). > Maybe we can do it so that copying pages from encrypted documents won't be > supported, but anybody can relatively easily write script/patch to do so if > interested. This way we won't make tool to break the DRM (if present) and > if someone does, then it is his problem whether he is author of the PDF or > whether his local laws permit that or not. Since pdfedit is opensource, no > matter what obstacles we would add, many people can easily overcome them by > writing a patch. I would like to prevent any further legal discussions, so encrypted -> unecrypted doesn't sound like a good solution. > > > delinearize_fail_for_encrypted.patch will cause failure of > > delinearization if a input document is encrypted. It will be a > > part of ask_for_password.patch[*]. Maybe we should add some > > big-fat-warning that this is not supported rather than just it > > failed. Martin, any idea? > > - we would need to remove encryption data from trailer in the > > current implementation. This is not a big deal but wrt. > > previous problem I think it is not worthy. > > Remove encryption from the document from which the pages are taken? Don't understand... > > > We can add support for delinearization later when encrypted content > > writing is enabled. > > > > Other solution, which comes to mind is to add password dialog but add an > > NotImplementedException to the Delinearizator::delinearize (proposed > > patch is delinearize_ask_for_passwd.patch[*]). Nevertheless I have one > > problem here too. GUI fails with SEGV when exception is thrown but I > > cannot see why. > > If we won't support it now, at least throw exception/error message instead > of crashing. Second patch _throws_ the NotImplementedException which leads in SEGV in gui. > > > Martin what do you think about that? > > > >> output file and click OK) and output file is empty after the crash. I > >> looked in base.cc but I found no obvious cause for this bug in my code there. > > > > The real (and not so obvious) reason for crash is that Delinearizator > > doesn't inherit from XRef but from the CXref and ~Delinearizator wasn't > > updated accordingly (in the patch 06) - XRef doesn't deallocate its > > stream so Delinearizator used to do it in the destructor. However CXref > > has to deallocate stream so it was double deallocated. > > Delinearizator uses protected inheritance and this have to be changed to > > public (so that setCredentials and needCredentials are available). > > I have updated appropriate patch patch but just the difference is > > attached as delinearizator_cannot_destroy_stream.patch[*]. > > Tried applying the patches, but got some rejects in base.cc, which I have > to apply manually (perhaps I applied the patches in wrong order ...? maybe > label them with numbers next time :)) delinearizator_cannot_destroy_stream.patch and ask_for_password.patch are _NOT_ compatible. Each one solves described solution by its own way. > > But when I compiled it, I got error when linking: > > /home/bilbo/pdfedit/src/kernel/libkernel.a(cxref.o): In function > `pdfobjects::CXref::setCredentials(char const*, char const*)': > cxref.cc:(.text+0x1189): undefined reference to `checkEncryptionCred(XRef*, > GString*, GString*, int&)' > cxref.cc:(.text+0x12d5): undefined reference to `setEncryptionCred(XRef*, > SecurityHandler*)' > > The patches needs fixing probably ... > > > Finally, there is also a minor issue with Delinearizator::delinearize > > return value. Documentation reads that it returns either 0 or errno > > which is used by GUI to display proper error message. However > > delinearize doesn't follow that and returns hardcoded -1 in some cases. > > delinearize_retval-consolidation.patch corrects that. I will commit this > > patch to the CVS separately after patchset is in. > > I think this issue is minor, but it could be fixed > > Martin Petricek > > -- > > > GPG/PGP Public key: http://www.petricek.net/petricm.pgp > Fingerprint 6AA8 FFCE C061 1CB2 55F0 A1F3 3AA9 EB4F BD50 C1B8 > /------------------------------------------------------------\ > | WWW: http://www.petricek.net/ | > \------------------------------------------------------------/ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Pdfedit-devel mailing list > Pdf...@li... > https://lists.sourceforge.net/lists/listinfo/pdfedit-devel -- Michal Hocko |