We have been using FPDF on our AWS EC2 instances for many years and for some of the documents, we use the SetProtection script to encrypt them, allowing only "print" as the possible option.
We are in the process of migrating our systems from Amazon Linux 2 to Amazon Linux 2023 and have discovered that SetProtection behaves differently on this system. Instead of allowing the document to be opened normally, it now demands a password, despite none being set.
I've tracked it done to a function called RC4 that uses openssl_encrypt for some purpose (which is installed and used elsewhere fine). That code (documented at http://www.fpdf.org/en/script/script37.php) offers a php-only fallback for when openssl_encrypt is not available, which works a treat, when used instead. This is what leads me to believe that there is something in the OpenSSL piece that is being odd. Equally, it could be the later version of PHP that has changed the behaviour.
There are no errors in the log at the time the PDF is being created.
Update
Not sure if this information will be helpful, however I have discovered that the code return openssl_encrypt($data, 'RC4-40', $key, OPENSSL_RAW_DATA);, which is in the SetProtection script, returns nothing at all on the new system and "stuff" on the old. I have fiddled about with different cipher methods to no avail (which is not surprising, given that I really don't have a clue ...)
Some versions of OpenSSL no longer support RC4 encryption (see for example here).
The script can be fixed like this to correctly detect RC4 support:
if(function_exists('openssl_encrypt') && in_array('rc4-40', openssl_get_cipher_methods()))
{
function RC4($key, $data)
{
return openssl_encrypt($data, 'rc4-40', $key, OPENSSL_RAW_DATA);
}
}
else
{
function RC4($key, $data)
{
// Fallback implementation
// ...
}
}