Conversation
| // As it stands, we can at least avoid users getting to an infinite loader | ||
| // in the case of `decryptOnAttachmentOpen`. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 Report✅ All modified and coverable lines are covered by tests. 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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
wooorm
force-pushed
the
wooorm/auth-event
branch
from
e92ce0c to
2fbf027
Compare
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @nicolo-ribaudo received. Current queue size: 1 Live output at: http://54.241.84.105:8877/98dfdbb8ea80820/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @nicolo-ribaudo received. Current queue size: 1 Live output at: http://54.193.163.58:8877/d6a920f112a1e0b/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/98dfdbb8ea80820/output.txt Total script time: 60.00 mins |
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/d6a920f112a1e0b/output.txt Total script time: 71.67 mins
Image differences available at: http://54.193.163.58:8877/d6a920f112a1e0b/reftest-analyzer.html#web=eq.log |
|
The browser in the linux bot just crashed /botio-linux test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @nicolo-ribaudo received. Current queue size: 1 Live output at: http://54.241.84.105:8877/da34aa3b5bbce24/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/da34aa3b5bbce24/output.txt Total script time: 44.10 mins
Image differences available at: http://54.241.84.105:8877/da34aa3b5bbce24/reftest-analyzer.html#web=eq.log |
5 participants
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/AuthEventis uncommon.So, separate things:
/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.