GetByValue now shares code with GetById to elide the synthetic wrapper
objects for primitive values in strict mode.
Fixes 2 test-js tests in bytecode mode. :^)
With this, `pdf` can print info for CIPA_DC-003-2020_E.pdf
(from https://cipa.jp/e/std/std-sec.html), as well as all other
files I've tried.
CIPA_DC-003-2020_E.pdf is special because it quits this loop after
exactly 64 interations, at round_number 63.
While here, also update a comment to use the non-spec-comment style
I'm now using elsewhere in the file.
With this, AESV3 support is complete and CIPA_DC-007-2021_E.pdf
can be opened :^)
(CIPA_DC-003-2020_E.pdf incorrectly cannot be opened yet. This
is due to a minor bug in computing_a_hash_r6_and_later() that
I'll fix a bit later. But except for this minor bug, all AESV3
files I've found so far seem to work.)
try_provide_user_password() calls compute_encryption_key_r6_and_later()
now. This checks both owner and user passwords. (For pre-R6 files,
owner password checking isn't yet implemented, as far as I can tell.)
With this, CIPA_DC-007-2021_E.pdf (or other AESV3-encrypted files)
successfully compute a file encryption key (...and then hit the
TODO() in StandardSecurityHandler::crypt() for AESV3, but it's
still good progress.)
...for handlers of revision 6.
The spec for this algorithm has several quirks:
1. It describes how to authenticate a password as an owner password,
but it redundantly inlines the description of algorithm 12 instead
of referring to it. We just call that algorithm here.
2. It does _not_ describe how to authenticate a password as a user
password before using the password to compute the file encryption
key using an intermediate user key, despite the latter step that
computes the file encryption key refers to the password as
"user password". I added a call to algorithm 11 to check if the
password is the user password that isn't in the spec. Maybe I'm
misunderstanding the spec, but this looks like a spec bug to me.
3. It says "using AES-256 in ECB mode with an initialization vector
of zero". ECB mode has no initialization vector. CBC mode with
initialization vector of zero for message length 16 is the same
as ECB mode though, so maybe that's meant? (In addition to the
spec being a bit wobbly, using EBC in new software isn't
recommended, but too late for that.)
SASLprep / stringprep still aren't implemented. For ASCII passwords
(including the important empty password), this is good enough.
...for handlers of revision 6.
Since this adds U to the hash input, also trim the size of U and O to
48 bytes. The spec requires them to be 48 bytes, but all the newer PDFs
on https://cipa.jp/e/std/std-sec.html have 127 bytes -- 48 real bytes
and 79 nul padding bytes. These files were created by:
Creator: Word 用 Acrobat PDFMaker 17
Producer: Adobe PDF Library 15.0
and
Creator: Word 用 Acrobat PDFMaker 17
Producer: Adobe PDF Library 17.11.238
LibGfx's ScaledFont doesn't do this, but in ScaledFont m_x_scale and
m_y_scale are immutable once the class is created, so it can get away
with not doing it.
In Type1Font, `width` changes in different calls to
Type1Font::draw_glyph(), so we need to make it part of the cache key.
Fixes rendering of the word "Version" on the first page of
pdf_reference_1-7.pdf.
This is just something I spotted looking around the code, previously
the PassPipelineExecutable was passed by value to
generate_cfg_for_block, which generated the CFG then just dropped it on
the floor. Making this a reference results in the CFG actually getting
generated.
We can delete for_each_bound_name() because there is more generic
version of this function called for_each_bound_identifier() that gives
you identifier using which you can get both name and check if it is
local/global.
Bytes will implicitly cast to StringView, but not to ReadonlyBytes. That
means that if you call
`Audio::Loader::create_plugin(mapped_file->bytes())`
it will silently use the `create_plugin(StringView path)` overload.
Reading audio data does not require that data to be writable, so let's
use ReadonlyBytes for it and avoid the footgun.
Similar to the scoped continue and break, the only two differences
between these functions is the scope that is scanned for a matching
label, and the specific handling of a continue/break boundary.
This is a step towards AESV3 support for PDF files.
The straight-forward way of writing this with our APIs is pretty
allocation-heavy, but this code won't run all that often for the
regular "open PDF, check password" flow.
Rather than splitting the Iterator type and its AOs into two files,
let's combine them into one file to match every other JS runtime object
that we have.
This is a normative change in the Set Methods proposal. See:
f3d5206
Note that this is normative due to an IsCallable check being deferred to
some time after its previous invocation in the GetKeysIterator.
This is an editorial change in the ECMA-262 spec. See:
784fc65
Note we were already doing this for a nicer error message. This is also
what lets GetIteratorFromMethod accept the method parameter as a nonnull
pointer.
This is an editorial change in the ECMA-262 spec. See:
ff60140
In doing so, as the new name implies, callsites are updated to pass in
an IteratorRecord themselves, rather than an iterable value.
