During tests of weird keys [0] it was found out that OpenPGP.js does not
handle keys without valid UIDs well.
There are two issues that this change corrects, first one is adding
filtering of user IDs in `getPrimaryUser` such as only users with self
certifications are considered. Without that change using
`getPrimaryUser` on a key without valid UIDs would throw an exception
(`Cannot read property 'verified' of undefined` [1]).
Second issue is correcting condition whether to throw if no UID was
found. Previous condition checked for `userId` variable, but this is
initialized by default and as such is almost always set. This causes
`key.getPrimaryUser()` (without condition) to throw `Could not find user
that matches that user ID`. The condition has been modified to match the
filter condition (checking if any property of `userId` has been
initialized).
[0]: https://gitlab.com/sequoia-pgp/weird-keys/tree/master/openpgpjs
[1]: 576ed08a54/openpgpjs/results/no-bound-uid.pgp.txt
This bug caused all signersUserIds strings to be prefixed with `"null"`
string. Changed to use only the last value for this packet type.
Previous implementation probably assumed that there will be more than one
signersUserId packet but I haven't been able to generate such signature
using gpg (only last user id was embedded). Moreover signature
serialization function `write_all_sub_packets` writes only one value of
this packet as a UTF-8 string.
This change implements Web Key Directory lookup using user's e-mail
address. The target host is the same as the e-mail's domain and the
local-part is hashed with SHA-1 and encoded using Z-Base32 encoding.
Implemented is basic flow of version 06 of OpenPGP Web Key Directory
draft [0].
It was necessary to update node-fetch package to allow returning array
buffers from HTTP responses.
If openpgpjs is used in the browser all keys retrieved from Web Key
Directory should have `Access-Control-Allow-Origin` header set to `*`
(including 404 Not found responses).
[0]: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/
- In anticipation of streaming decryption
- Firefox 34 does not support chunk_size_byte > 24
256KiB is almost as fast as no chunks (although both of those can be up to
~1.5x slower than optimally using threads for very large message sizes).
The optimal chunk size would be something like:
max(data.length / navigator.hardwareConcurrency, 128KiB)
But we don't do so currently because
- We don't know the hardwareConcurrency of the decrypting machine
- Smaller chunk sizes are better for streaming decryption
