Decode mixed eol #12
Open
Decode mixed eol #12
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
January 9, 2025 21:24
The strategy is, to not change user supplied eols when decoding. If an encoded eol was found, use it. If not, go with the one the user gave us.
mbeijen
force-pushed
the
decode-mixed-eol
branch
from
87d0f13 to
6adf664
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MIME::QuotedPrint::qp_decode destroys the signatures of signed PDF files with mixed line endings (some encoded, some not, some "\n" some "\r\n") and is therefore not usable in professional workflows. It does so, by enforcing some “standard” on EOLs that does not really exist (or that is badly defined and prone to misunderstandings).
The first commit on this branch adds a test to demonstrate the problem, the second one implements the fix. The module now goes with the EOL the users supplied (and therefor intended), if in doubt (i.e. no encoded EOL was found on that line). And, as a result, saves the electronic signatures from deterioration (which is a widely known problem).
Just for the fun of it: This is the bug report I submitted quite a while ago: https://rt.cpan.org/Public/Bug/Display.html?id=128456
Note, that the fix is installed on secure-Mail servers in production since quite a while now (in fact, I had to implement some quirky workaround to replace the buggy qp_decode: https://gitlab.com/ChipsBarrier/mime-quotedprintmscompat). In that environment, signed content is part of about 50% of the mails going through the system. The fix stopped the customer complaints for good.
Destroying user content is a Bug.
Outlook attaches PDF files quoted printable encoded. That's another bug, but we cannot fix it.
A third bug is the way electronical documents are normalized before signing/verification. We cannot fix that either.