v1.1.1

A security fix to the attachment saver, from the marketplace listing review.

An attachment is placed without following what is already there

The saver picked its path with [ -e "$out" ] and then asked bw to write that
path. Neither half is safe on its own. -e follows symlinks, so a dangling
link sitting in the download folder read as a free name and the write created
the file the link pointed at instead. And a test that is true when it returns
says nothing about the moment after it returns, so a link dropped in between
the check and the write still won.

The bytes now land in a freshly made private directory inside the destination
folder, and the finished file claims its name with link(). That call never
follows the last component of the new path and fails outright if anything is
already there, so the existence test and the creation are a single operation
with no window between them: a symlink is stepped around rather than followed,
and an existing file still cannot be overwritten -- " (1)", " (2)" and so on go
before the extension until the name is free. Filesystems with no hard links
(FAT, exFAT, most phone mounts) have no symlinks either, so on those the
fallback is a plain no-clobber move.

Attachment downloads are bounded

Retrieval had no ceiling of any kind. The size the vault reports is the
server's word rather than proof, so it only buys an early and readable
refusal; the limits that hold when it lies are RLIMIT_FSIZE on what can be
written (512 MB, Bitwarden's own per-file ceiling), a 15 minute timeout on a
transfer that never ends, and a free-space check that keeps a download from
taking the last of the disk. Whichever limit trips, the staging directory goes
with it and nothing partial is left behind.

The decrypted file is no longer world-readable either: the saver runs under
umask 077, so the attachment is 0600 in staging and 0600 where it lands.