GUACAMOLE-1495: add pl_pl_qwerty to ca translation
GUACAMOLE-1495: add pl_pl_qwerty to cs translation
GUACAMOLE-1495: add pl_pl_qwerty to de translation
GUACAMOLE-1495: add pl_pl_qwerty to es translation
GUACAMOLE-1495: add pl_pl_qwerty to fr translation
GUACAMOLE-1495: add pl_pl_qwerty to it translation
GUACAMOLE-1495: add pl_pl_qwerty to ko translation
GUACAMOLE-1495: add pl_pl_qwerty to nl translation
GUACAMOLE-1495: add pl_pl_qwerty to no translation
GUACAMOLE-1495: add pl_pl_qwerty to pt translation
GUACAMOLE-1495: add pl_pl_qwerty to zh translation
GUACAMOLE-1495: correct typo in no.json
The Fetch API allows us to read HTTP responses as true streams, without
building an in-memory string. We can the buffer things ourselves as we
see fit, including as a Blob that can dynamically leverage disk storage
for larger data.
An SSH server record in KSM has an associated "KeyPair" field, but this
field need not be set. If unset, the current logic ignores the rest of
the record and assumes there is no private key at all. Instead, the
standard fallbacks of locating an attached PEM file, locating an
alternative password field, etc. should be used.
The clipboard service previously and incorrectly resynced the internal
clipboard with itself. This had the effect of forcing a resync of the
internal clipboard contents to the external, local clipboard, clearing
that clipboard of whatever was copied before.
A previous iteration of the whitespace-trimming changes involved an
additional constructor variation. After removing that portion, the
original constructor for PropertiesGuacamoleProperties was not restored
correctly, and now recursively invokes itself.
When retrieving a contextual field like "passphrase", which does not
have a typed representation different from "password" or "hidden", the
contexts where the field's identity is truly known should be preferred
("password" field of a record with a "keypair" field, which MUST be the
key passphrase). When venturing outside well-known contexts, custom
fields should be preferred when their standard counterparts would
already have well-established meanings that differ from the requested
secret (again: "password" of a record with "keypair").
If this is not done, things like retrieving the private key from a
"Login" record fail, as one of the possible storage mechanisms for a
private key is a hidden or password field, which pulls the user's
password instead of their key. In this case, the correct behavior is
to pull the typed value ("keypair") if available, and use custom fields
ONLY otherwise, as those fields have labels that can establish context.
In no other case would it be reliable to assume that a hidden/password
field actually contains a private key.
Doing otherwise would mean that a particular user would never be able
to be associated with a specific password/key by their username if they
have any explicit server-specific account.
Simply calling getPassword() does not currently work correctly, as the
implementation of getPassword() assumes there will be at least one
value if the field is present. This results in an
ArrayIndexOutOfBoundsException for records with empty passwords:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:659)
at java.util.ArrayList.get(ArrayList.java:435)
at com.keepersecurity.secretsManager.core.KeeperRecord.getPassword(SecretsManager.kt:134)
...
