Re: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution

Dear Monks, don't know if I should continue here or ask a separate SOPW question, especially if it's not strictly about Perl. Should I completely drop support for (very obsolete and perhaps buggy) implementation of PDF Encryption in CAM::PDF, or continue to drag it along into my sub-class? Will anyone miss it, or should I restrict i.e. isolate this "encryption" from my new features, emitting warnings now and then "don't use it here, don't do that, etc."?

CAM::PDF claims to support 40-bit RC4 encryption to read-write, and 128-bit non-AES to read only. Nothing more modern. In my tests, it does open encrypted files of both kinds but only if owner and user passwords were the same; and for the 40-bit variant, it can also open a file with different O/U pair of passwords, but succeeds only if U/U pair of strings is provided to constructor. Weird.

When CAM::PDF is used to encrypt non-encrypted PDF files, for P/P (i.e. same O/U) passwords, the produced file is opened OK by Adobe Reader (or modern browsers) after requesting a password. For O/U (different pair), Reader accepts either "U" or "O" password but displays a blank page. Actually, the Reader always accepts either of the two, if another authoring app was used to encrypt (and displays a file correctly), so the comment in line 2951 is moot. "Perhaps a bug", indeed.

I can successfully run CAM::PDF's test suite, with "CAM::PDF" replaced with "PDF::CAMPDF::X" in test files. Some of the tests are about setting PDF permissions/passwords, then saving and re-reading scalars. But I'm unhappy because of compromises I had to make to keep functional what I consider obsolete and buggy, and not interested in. Also, my idea was to inherit the test suite (at least, for now); if "encryption/permissions" part is stricken out, it gets somewhat slim.

Personally, PDF encryption is source of confusion/irritation at best and misery at worst; and absolute taboo in my working life (pre-press). But I don't know, perhaps it's better not to be too hasty (throwing "encryption" away)? Is PDF encryption, modern or not, actually widely used in, eh-m, the "first world"? Considering the effort obviously put into development by CAM? Or is it a niche thing no one will miss?

Comment on Re: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution Select or Download Code

Replies are listed 'Best First'.
Re^2: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by hippo (Archbishop) on Oct 28, 2024 at 11:07 UTC
Is PDF encryption, modern or not, actually widely used IME, no. I suspect that this is largely because it suffers from the requirement to share the password with those others you wish to be able to read the document. And if you are going to share the password securely, why not just share the document securely? When I do have a need to share a PDF securely with someone I just encrypt it with their PGP public key. 🦛	[reply]
Re^3: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by ysth (Canon) on Oct 28, 2024 at 15:11 UTC
I don't know that there are good reasons to encrypt PDFs, but it does still happen. I once received an encrypted PDF in response to a FOIA request, and once was emailed a medical bill as an encrypted PDF. -- A math joke: r = \| \|csc(θ)\|+\|sec(θ)\| \|-\| \|csc(θ)\|-\|sec(θ)\| \|	[reply]
Re^4: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by hippo (Archbishop) on Oct 28, 2024 at 15:21 UTC
I once received an encrypted PDF in response to a FOIA request This is very likely to be the funniest thing I will read today - thanks for that! 🦛	[reply]


"be consistent"
	PerlMonks