search

tkhq / qos

QuorumOS is a computation layer for running applications inside Trusted Execution Environments (TEEs)
GNU Affero General Public License v3.0
5 stars 2 forks source link

Update vulnerable openssl package #480

Closed zkharit closed 3 months ago

zkharit commented 3 months ago

Summary & Motivation (Problem vs. Solution)

Update vulnerable openssl package info here: https://github.com/tkhq/qos/security/dependabot/40

How I Tested These Changes

Pre merge check list

r-n-o commented 3 months ago

@zkharit how did you do this update? Typically Cargo.lock isn't edited in isolation, it's paired with an update of a Cargo.toml file (sort of like package.json and pnpm-lock.yaml in the JS world)

zkharit commented 3 months ago

I used cargo update openssl since its not a new package it only updated the lock file

r-n-o commented 3 months ago

@zkharit interesting. So yeah we don't depend on openssl directly: https://github.com/tkhq/qos/blob/19c23c681226bed4b0ace693db14a9f94234a880/src/qos_enclave/Cargo.toml#L10-L11

So...I guess that's the only way to do it then? Update the lock file directly? Discussions online about this are confusing: https://users.rust-lang.org/t/inconsistent-cargo-patch-for-transitive-dependencies/90942, https://users.rust-lang.org/t/transitive-dependencies-breakage/105151/8 😵‍💫

zkharit commented 3 months ago

@r-n-o Yeah I think so, i attempted to use [patch] but pointing it at crates.io like [patch.crates-io] gives this error:

error: failed to resolve patches for https://github.com/rust-lang/crates.io-index

Caused by: patch for openssl in https://github.com/rust-lang/crates.io-index points to the same source, but patches must point to different sources

I found cargo update, and that looked like it did the trick

r-n-o commented 3 months ago

Cool! Makes sense. Thanks for the details!