This adds a simple hardened systemd-based module for g3proxy, a generic
purpose forward proxy.
Change-Id: I8c6e5d2cc8a9faa2aea8c5df3af56756ffed542d
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Co-authored-by: Elias Coppens <elias.coppens@ens.fr>
g3proxy is an alternative forward proxy to squid or tinyproxy, written
in Rust, relying on modern cryptography stacks like partially verified
AWS LC and RustTLS.
AWS LC library is vendored because of how the Rust ecosystem is, but we
should look into unvendoring this like unvendoring OpenSSL is usually
done.
Change-Id: Id7f2d8b59307c5306e178a38a165c19f426ad8de
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Co-authored-by: Elias Coppens <elias.coppens@ens.fr>
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
The previous patch was impure, because native-tls and its dependencies
weren't locked, and so Cargo would fetch the latest possible versions
from the network. This meant that the gg-jj.cargoDeps FOD was broken
since the first time native-tls or one of its dependencies released a
new version. To do this reproducibly we need to include all the added
dependencies in the lockfile.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
This reverts commit e3967be411.
The 3.3.2 tag appears to have been deleted before Hydra had a chance
to fetch it. Revert to a version that we can actually build. (An
attempt to update to 3.3.3 is currently stuck with failing CI.)
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Upstream sadly decided to fix the incorrect Cargo.lock we were
applying a patch for by rewriting the tag. :(
Diff of sources before and after:
diff --git 1/nix/store/yh0jcja9psq44dlis8jw93s62bfah5ys-source/Cargo.lock 2/nix/store/0l9wq5fxgxhaq0pp7p0yd38815x8rbqy>
index f01f824..e00d079 100644
--- 1/nix/store/yh0jcja9psq44dlis8jw93s62bfah5ys-source/Cargo.lock
+++ 2/nix/store/0l9wq5fxgxhaq0pp7p0yd38815x8rbqy-source/Cargo.lock
@@ -328,7 +328,7 @@ dependencies = [
[[package]]
name = "swayws"
-version = "1.1.1"
+version = "1.2.0"
dependencies = [
"clap",
"env_logger",
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
