UserPassword stopped working in 6.x series in Edge
PdfSharp 6.x series have a bug when setting UserPassword property. The document cannot be opened with Edge (🤦).
Working versions
- 1.50.5147, targeting net48
Broken versions used for reproducing
- 6.0.0, targetting net8.0
- 6.1.1, targetting net8.0 and net48
- 6.2.0-preview-3, targetting net8.0
The issue was reported to us by several independent customers.
Expected Behavior
Document can be opened in Edge with correct password.
Actual Behavior
Document does not open due to some password issue.
Steps to Reproduce the Behavior
- Create blank page PDF
Dim PDF As New PdfSharp.Pdf.PdfDocument
PDF.AddPage()
PDF.SecuritySettings.UserPassword = "1234"
PDF.Save("D:\_Temp\File.pdf")
or C# version from #253
var PDF = new PdfSharp.Pdf.PdfDocument();
PDF.AddPage();
PDF.SecuritySettings.UserPassword = "1234";
var filename = "File.pdf";
PDF.Save(filename);
- Open it with Edge
Or send it to some unfortuante user that's still using Edge 🤦
Side notes
It works in Acrobat and Chrome.
Tested with Edge 135.0.3179.98 64bit Tested with Edge 136.0.3240.50 64bit
This doesn't seem to be related to #253, as that one was TFM-specific. My wild guess is that some additional metadata is expected by Edge that was present in 1.50.5147 and removed in the migration.
We also had the issue, and were able to track it down to the edge pdf viewer specifically.
If using edge://flags, the integrated pdf viewer is disabled, then the PDF can be opened. If it is enabled then the file cannot be opened.
Putting back the encryption to
/V 2 / R 3 from the default is also working.
My wild guess is that some additional metadata is expected by Edge that was present in 1.50.5147 and removed in the migration.
Or maybe the difference is a different default encryption setting.
We cannot debug Edge to find what their problem is.
Did you report this to Microsoft?
Did you report this to Microsoft?
No, I have no idea how to do that.
As @Greybird mentioned above, disabling edge://flags/#edge-new-pdf-viewer works around the problem. Unfortunatelly, it's not acceptable solution for general nontechnical population.
This workaround also seems to work:
PDF.SecurityHandler.SetEncryptionToV2With128Bits()
I also had the issue.
The likely cause is that the /Length entry is missing from the encryption dictionary when encrypting with /V 4.
In most cases, this value is effectively superseded by the crypt filter settings, so it should not be necessary in practice. However, some environments treat its absence as an error; for example, inspecting such a PDF with qpdf --check detect an "unsupported key length" error.
Whether this is the correct solution or not, I confirmed that setting /Length to 128 resolves the issue in both Edge and qpdf.