Add support for `AuthEvent` by wooorm · Pull Request #20732 · mozilla/pdf.js

wooorm · 2026-02-24T15:05:51Z

Hi!

This solves GH-20049, it’s an alternative to GH-20140. The analysis is a bit different. It builds on my comment in the other issue, and the fact that they are separate things.

To recap, it is possible to have a document plain text but have attachments encrypted. In that case, instead of prompting upfront, PDFs can prompt later with /AuthEvent /EFOpen. The default is /AuthEvent /DocOpen. Which is typical. So /AuthEvent is uncommon.

So, separate things:

encrypted attachments (regardless of /AuthEvent) ([Bug]: File Attachments do not open when they are encrypted #20139)
/AuthEvent /EFOpen (regardless of whether there are attachments) (this issue/PR)

This PR stops prompting for a password on doc open if there is an /AuthEvent /EFOpen. It also does not list delayed encrypted attachments in the sidebar. It does that to prevent an infinite loading screen in a known case but also so that there is a place marked in the code where future logic, after GH-20139, can support lazily decrypting attachments.

nicolo-ribaudo · 2026-03-03T10:26:29Z

+      // As it stands, we can at least avoid users getting to an infinite loader
+      // in the case of `decryptOnAttachmentOpen`.


Can we console.warn something like "there are encrypted attachments but they are not supported yet"?

Also, question about the PDF format: is it possible to have some encrypted attachments and some not? In this case we should probably still show the non-encrypted ones.

is it possible to have some encrypted attachments and some not? In this case we should probably still show the non-encrypted ones.

See the last 2 blockquotes from #20139 (comment).
As I understand it, pdf generators should make PDFs with all attachments encrypted.

There is also the case of encrypted attachments w/o AuthEvent.
I considered looking into it, indeed having a nice warning, but I think it’s better to spend that time into actually solving the issue #20139.

So this also relates to console.warn: this PR does not change encrypted attachment handling. Those are not detected and yield warnings already. This only honors when to ask for a password.

codecov-commenter · 2026-03-04T09:38:38Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.81%. Comparing base (909a700) to head (2fbf027).
⚠️ Report is 352 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #20732      +/-   ##
==========================================
+ Coverage   62.77%   62.81%   +0.03%     
==========================================
  Files         169      169              
  Lines      119824   119837      +13     
==========================================
+ Hits        75224    75274      +50     
+ Misses      44600    44563      -37

Flag	Coverage Δ
fonttest	`7.66% <ø> (+0.02%)`	⬆️
unittestcli	`62.78% <100.00%> (+0.03%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

This solves mozillaGH-20049, it’s an alternative to mozillaGH-20140. The analysis is a bit different. It builds on [my comment in the other issue](mozilla#20139 (comment)), and the fact that they are *separate* things. To recap, it is possible to have a document plain text but have attachments encrypted. In that case, instead of prompting upfront, PDFs can prompt later with `/AuthEvent /EFOpen`. The default is `/AuthEvent /DocOpen`. Which is typical. So `/AuthEvent` is uncommon. So, separate things: * encrypted attachments (regardless of `/AuthEvent`) (mozillaGH-20139) * `/AuthEvent /EFOpen` (regardless of whether there are attachments) (this issue/PR) This PR stops prompting for a password on doc open if there is an `/AuthEvent /EFOpen`. It also does not list delayed encrypted attachments in the sidebar. It does that to prevent an infinite loading screen in a known case but also so that there is a place marked in the code where future logic, after mozillaGH-20139, can support lazily decrypting attachments.

nicolo-ribaudo · 2026-03-04T09:49:34Z

/botio test

moz-tools-bot · 2026-03-04T09:49:37Z

From: Bot.io (Linux m4)

Received

Command cmd_test from @nicolo-ribaudo received. Current queue size: 1

Live output at: http://54.241.84.105:8877/98dfdbb8ea80820/output.txt

moz-tools-bot · 2026-03-04T09:49:37Z

From: Bot.io (Windows)

Received

Command cmd_test from @nicolo-ribaudo received. Current queue size: 1

Live output at: http://54.193.163.58:8877/d6a920f112a1e0b/output.txt

moz-tools-bot · 2026-03-04T11:02:04Z

From: Bot.io (Linux m4)

Failed

Full output at http://54.241.84.105:8877/98dfdbb8ea80820/output.txt

Total script time: 60.00 mins

moz-tools-bot · 2026-03-04T11:33:07Z

From: Bot.io (Windows)

Failed

Full output at http://54.193.163.58:8877/d6a920f112a1e0b/output.txt

Total script time: 71.67 mins

Unit tests: Passed
Integration Tests: FAILED
Regression tests: FAILED

  different ref/snapshot: 1

Image differences available at: http://54.193.163.58:8877/d6a920f112a1e0b/reftest-analyzer.html#web=eq.log

nicolo-ribaudo · 2026-03-04T12:27:55Z

The browser in the linux bot just crashed

/botio-linux test

moz-tools-bot · 2026-03-04T12:27:58Z

From: Bot.io (Linux m4)

Received

Command cmd_test from @nicolo-ribaudo received. Current queue size: 1

Live output at: http://54.241.84.105:8877/da34aa3b5bbce24/output.txt

moz-tools-bot · 2026-03-04T13:20:02Z

From: Bot.io (Linux m4)

Failed

Full output at http://54.241.84.105:8877/da34aa3b5bbce24/output.txt

Total script time: 44.10 mins

Unit tests: Passed
Integration Tests: FAILED
Regression tests: FAILED

  different ref/snapshot: 1

Image differences available at: http://54.241.84.105:8877/da34aa3b5bbce24/reftest-analyzer.html#web=eq.log

calixteman · 2026-04-27T08:49:41Z

+      // But it is at least possible to honour `/AuthEvent /EFOpen` by not
+      // asking for a password on document open.
+      this.decryptOnAttachmentOpen =
+        encrypt.get("CF")?.get("StdCF")?.get("AuthEvent")?.name === "EFOpen";


So here you're reading the encrypt dict without setting suppressEncryption which is in contradiction with the comment below.

It’s been a while, and I think the other PR landing first will require a rework of this PR anyway, but as I understand it:
This part that is read should not be encrypted.
The else branch (not setting things) prevents the trying-to-decrypt-things.
Otherwise, the trying-to-decrypt-things will prompt for the password on open.

calixteman · 2026-04-27T11:09:16Z

+      // But it is at least possible to honour `/AuthEvent /EFOpen` by not
+      // asking for a password on document open.
+      this.decryptOnAttachmentOpen =
+        encrypt.get("CF")?.get("StdCF")?.get("AuthEvent")?.name === "EFOpen";


You completely ignore the EFF value, right ? Is it a good idea ?

calixteman

I tried with a pdf with an encrypted attachment and it's fine no password prompt when opening the file, but there's nothing in the attachments view (the button is even disabled).
So overall it looks like a regression.

nicolo-ribaudo · 2026-04-27T11:17:29Z

but there's nothing in the attachments view (the button is even disabled).

The behavior today is that the attachments are shown but clicking on them does nothing. Do you think that behavior is more desirable than not showing the undownloadable attachment at all?

calixteman · 2026-04-27T11:25:52Z

but there's nothing in the attachments view (the button is even disabled).

The behavior today is that the attachments are shown but clicking on them does nothing. Do you think that behavior is more desirable than not showing the undownloadable attachment at all?

Yeah, you're right: it's fair.
Couldn't we try to figure out a good solution instead of replacing a bug by an other one ?
I'm ok to land the patch (maybe it's slightly better like you propose), but it should have a follow-up with a real fix.

nicolo-ribaudo · 2026-04-27T12:42:30Z

Yeah agree. There are two issues going on:

we do not support encrypted attachments at all ([Bug]: File Attachments do not open when they are encrypted #20139)
we ask for the attachment encryption password on open even if the PDF asks to do it on attachment open ([Bug]: PDF.js wrongly prompts for a password on attachment-only encrypted PDFs. #20049)

We should eventually fix both, and for now this PR only fixes 2.

Fixing (1) is a bit more complex because it requires showing the user a popup on attachment download, touching some paths that are currently synchronous.

wooorm · 2026-05-07T11:43:17Z

Okay, see GH-21234!

This PR is related to mozillaGH-20732, which is about `AuthEvent` (to delay promting for a password), but instead adds the actual support for encrypted attachments. “Encrypted attachments” means that the main things are plain text. Note that some PDF viewers, like Preview/QuickLook/Safari or Chrome, do not support attachments at all. Note that the file checked into the tests is the same as `output-no-auth-event.pdf` referenced in <mozilla#20139 (comment)>. Closes mozillaGH-20139.

wooorm · 2026-05-28T13:29:12Z

Closing, GH-21351 is a proper version.

Normally entire PDFs are encrypted (or not). But it is also possible to only encrypt attachments. It is then also possible to *only* prompt for a password when the user opens them. In the existing flow, prompting for passwords happens because things are decrypted. A specific error is thrown, caught, and the user is prompted. To keep this flow working, this PR changes to decrypting attachments on demand, instead of eagerly. This sounds logical: to not read attachments on startup. I’ve extensively tested this, not only with regular attachments, but also with outline items and attachments in annotations. This PR builds on mozillaGH-21234. It’s an alternative to the naïve mozillaGH-20732. Closes mozillaGH-20049.

timvandermeij added the core label Feb 24, 2026

nicolo-ribaudo reviewed Mar 3, 2026

View reviewed changes

wooorm force-pushed the wooorm/auth-event branch from e92ce0c to 2fbf027 Compare March 4, 2026 09:45

timvandermeij linked an issue Mar 5, 2026 that may be closed by this pull request

[Bug]: PDF.js wrongly prompts for a password on attachment-only encrypted PDFs. #20049

Closed

Aditi-1400 mentioned this pull request Mar 11, 2026

Avoid password prompt on attachment-only encryption with no attachments #20140

Closed

calixteman reviewed Apr 27, 2026

View reviewed changes

calixteman requested changes Apr 27, 2026

View reviewed changes

wooorm mentioned this pull request May 7, 2026

Add support for encrypted attachments #21234

Merged

wooorm mentioned this pull request May 28, 2026

[api-minor] Add support for /AuthEvent, on-demand decryption #21351

Merged

wooorm closed this May 28, 2026

		// As it stands, we can at least avoid users getting to an infinite loader
		// in the case of `decryptOnAttachmentOpen`.

Uh oh!

Conversation

wooorm commented Feb 24, 2026

Uh oh!

nicolo-ribaudo Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wooorm Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

codecov-commenter commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

nicolo-ribaudo commented Mar 4, 2026

Uh oh!

moz-tools-bot commented Mar 4, 2026

From: Bot.io (Linux m4)

Received

Uh oh!

moz-tools-bot commented Mar 4, 2026

From: Bot.io (Windows)

Received

Uh oh!

moz-tools-bot commented Mar 4, 2026

From: Bot.io (Linux m4)

Failed

Uh oh!

moz-tools-bot commented Mar 4, 2026

From: Bot.io (Windows)

Failed

Uh oh!

nicolo-ribaudo commented Mar 4, 2026

Uh oh!

moz-tools-bot commented Mar 4, 2026

From: Bot.io (Linux m4)

Received

Uh oh!

moz-tools-bot commented Mar 4, 2026

From: Bot.io (Linux m4)

Failed

Uh oh!

calixteman Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

wooorm May 14, 2026

Choose a reason for hiding this comment

Uh oh!

calixteman Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

calixteman left a comment

Choose a reason for hiding this comment

Uh oh!

nicolo-ribaudo commented Apr 27, 2026

Uh oh!

calixteman commented Apr 27, 2026

Uh oh!

nicolo-ribaudo commented Apr 27, 2026

Uh oh!

wooorm commented May 7, 2026

Uh oh!

wooorm commented May 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

nicolo-ribaudo Mar 3, 2026 •

edited

Loading

codecov-commenter commented Mar 4, 2026 •

edited

Loading