Nixpkgs patches many libraries to read certificate bundle mentioned in
NIX_SSL_CERT_FILE, and /nix/store is already present in the sandbox.
Related to https://github.com/NixOS/nixpkgs/issues/409848
* descends recursively to all nested volumes
* values are static, update on volume-rescan
* closes#634#1033#1390
Co-authored-by: Victor Phillips <victor.m.phillips@protonmail.com>
previously shelled out to system32/fsutil.exe; expensive and
pointless since all it does is call DeviceIoControl (ioctl)
this is not a security fix; just like most software on windows,
copyparty is still vulnerable to DLL hijacking, so this change
makes little-to-no difference security-wise; commit bb40804f2d
plus, the default config (sharing current folder read-write
without auth) was meant to be obviously insecure, intended for
quick shares on a small LAN rather than untrusted networks
famously, windows prefers cwd when resolving a binary to execute,
rather than a predefined PATH like linux / unix / every other OS
even worse, it also does this for DLLs, and mitigating *that*
is infeasible because it depends on variables we dont control
print a warning in case someone is unaware of this
the ui would still show the option to grant write-permission
when creating a fileshare; pointless since an existing file
can't be overwritten without the delete-permission
while this is obvious and nobody would intentionally create
a fileshare with write, avoid any confusion by hiding it
use libvips as last resort due to risk of OOM; example:
libvips defers to imagemagick for animated avif, and imagemagick
probably does an identify, iterating through each frame, itself
consuming 100+ MiB RAM, which libvips amplifies to 7+ GiB
similar behavior is observed with `identify a.mkv` in a shell