feat: pin to working protos version, add lockfile #124

cprice404 · 2023-02-14T21:44:32Z

A patch release of the protos contained a breaking change, and
because we didn't pin to a specific version or have a Cargo.lock
file, this caused the build to break for this project and
consuming projects. This commit adds the Cargo.lock file,
and (for now) pins to a version of the client protos that this
library will compile successfully against.

A patch release of the protos contained a breaking change, and because we didn't pin to a specific version or have a Cargo.lock file, this caused the build to break for this project and consuming projects. This commit adds the Cargo.lock file, and (for now) pins to a version of the client protos that this library will compile successfully against.

kvcache · 2023-02-14T21:50:01Z

Cargo.toml

@@ -18,7 +18,7 @@ members = [
 exclude = [ "example" ]

 [dependencies]
-momento-protos = { version = "0.42" }
+momento-protos = { version = "=0.42.4" }


I don't really think it makes sense to pin to explicit versions like this. Semantically the SDK depends on momento protos 0.42, and the lockfile is the better tool for explicit versions.

I'm not going to block you on this and I will approve once the approvals are green but I don't agree with this style.

right now if i don't do this, it literally won't compile because 0.42.5 is not compatible.

you could put the version lock in the new cargo.lock file like this

[[package]] name = "momento-protos" version = "0.42.4"

i was not aware of / under the impression that it was fair game to make manual edits to that file.

One can edit any file one wishes to edit. It's certainly atypical, but it's also quite atypical to publish a library without a cargo.lock file :-(

As I said, I'm not going to block you but I disagree with this plan.

Prior to this commit we had a dep on a time library called chrono. In this PR we removed the Cargo.lock file from .gitignore, because without it we were picking up patch releases of dependencies that could cause the build of HEAD to break without any changes to our code. When Cargo.lock was re-added, github found a security vulnerability in the `time` library that `chrono` depended on. There is no new version of chrono that isn't pinned to a vulnerable version of `time`. We also don't really need to force a dependency on chrono on our users. To all of those ends, this commit removes the chrono dep in favor of the stdlib SystemTime.

cprice404 · 2023-02-15T02:35:32Z

@kvcache i pushed a commit that attempts to remove the chrono dep.

cprice404 · 2023-02-15T02:36:09Z

idk how to make the checks re-run

kvcache

Thanks for removing that chrono dependency! We'll figure out why the approval isn't running or I'll pull this down and independently verify tomorrow morning.

kvcache · 2023-02-15T02:55:16Z

Cargo.toml

@@ -27,7 +27,6 @@ jsonwebtoken = "8.0.1"
 rand = "0.8.5"
 serde = {version = "1.0", features = ["derive"] }
 serde_json = "1.0.79"
-chrono = {version = "0.4.19", features = ["serde"] }


kvcache · 2023-02-15T02:56:12Z

src/simple_cache_client.rs

-                    .expect("couldn't parse from timestamp"),
-                Utc,
-            ),
+            expires_at: SystemTime::from(UNIX_EPOCH + Duration::from_secs(res.expires_at)),


This is nice.

brayniac · 2023-02-15T02:57:11Z

I'm under the impression the cargo lock file in a library is ignored. So your users will still have an issue if you don't explicitly pin in the manifest

…

On Tue, Feb 14, 2023, 6:55 PM Kenny ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In Cargo.toml <#124 (comment)> : > @@ -18,7 +18,7 @@ members = [ exclude = [ "example" ] [dependencies] -momento-protos = { version = "0.42" } +momento-protos = { version = "=0.42.4" } One can edit any file one wishes to edit. It's certainly atypical, but it's also quite atypical to publish a library without a cargo.lock file :-( As I said, I'm not going to block you but I disagree with this plan. — Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACP6HF7R6G5EJYDBFL6L46LWXRARDANCNFSM6AAAAAAU4CU6UY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

kvcache · 2023-02-15T02:59:41Z

I'm under the impression the cargo lock file in a library is ignored. So your users will still have an issue if you don't explicitly pin in the manifest

That would be news to me, but I don't have a ton of cargo distribution experience. Thanks for your insight!

brayniac · 2023-02-15T03:02:37Z

Specifically, I think it'll work in the library when you build the library. But it is not honored by consumers of your library. It seems to still be advised to not commit a lock file in a library only project. Was just chatting with Sean about this the other day for another project

…

On Tue, Feb 14, 2023, 6:59 PM Kenny ***@***.***> wrote: I'm under the impression the cargo lock file in a library is ignored. So your users will still have an issue if you don't explicitly pin in the manifest That would be news to me, but I don't have a ton of cargo distribution experience. Thanks for your insight! — Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACP6HF47ZNGZXXW47WUMAGDWXRBCPANCNFSM6AAAAAAU4CU6UY> . You are receiving this because you commented.Message ID: ***@***.***>

src/simple_cache_client.rs

-                    .expect("couldn't parse from timestamp"),
-                Utc,
-            ),
+            expires_at: SystemTime::from(UNIX_EPOCH + Duration::from_secs(res.expires_at)),


src/simple_cache_client.rs

-                        .expect("couldn't parse timestamp from signing key"),
-                    Utc,
-                ),
+                expires_at: SystemTime::from(UNIX_EPOCH + Duration::from_secs(signing_key.expires_at)),


kvcache · 2023-02-15T17:22:39Z

Specifically, I think it'll work in the library when you build the library. But it is not honored by consumers of your library. It seems to still be advised to not commit a lock file in a library only project. Was just chatting with Sean about this the other day for another project

Okay, so re-reading documentation on this yet again it appears I was exactly backwards on what I remembered and confidently gave the opposite guidance of the correct best practice. 🤦 Thank you.

I remembered this page clearly and opposite of what it is in reality: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries We should not check in a lockfile to this repo.

…ssues" This reverts commit 667226e.

cprice404 · 2023-02-15T21:30:09Z

I've put the lock file back into .gitignore.

cprice404 requested a review from kvcache February 14, 2023 21:44

kvcache reviewed Feb 14, 2023

View reviewed changes

cprice404 added 2 commits February 14, 2023 13:51

fix: try upgrading chrono to get rid of vulnerable time dep

8647814

cprice404 requested a review from kvcache February 15, 2023 02:35

kvcache reviewed Feb 15, 2023

View reviewed changes

cprice404 mentioned this pull request Feb 15, 2023

feat: pin to working protos version, add lockfile, remove chrono dependency #125

Closed

fix: linting

7f9b17b

github-advanced-security bot found potential problems Feb 15, 2023

View reviewed changes

fix: clippy

80c1e38

cprice404 added 4 commits February 15, 2023 09:25

fix: clippy

07b0e46

chore: run on ubuntu 20.04 instead of latest due to network issues

667226e

chore: put the cargo.lock file back into .gitignore

1afc464

Revert "chore: run on ubuntu 20.04 instead of latest due to network i…

14f1c06

…ssues" This reverts commit 667226e.

cprice404 requested a review from kvcache February 15, 2023 21:30

kvcache approved these changes Feb 15, 2023

View reviewed changes

cprice404 merged commit 77e254d into main Feb 15, 2023

cprice404 deleted the fix-proto-dep branch February 15, 2023 21:44

nand4011 mentioned this pull request Feb 15, 2024

RUSTSEC-2020-0159 #50

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: pin to working protos version, add lockfile #124

feat: pin to working protos version, add lockfile #124

cprice404 commented Feb 14, 2023

kvcache Feb 14, 2023

cprice404 Feb 14, 2023

kvcache Feb 14, 2023

cprice404 Feb 15, 2023

kvcache Feb 15, 2023

cprice404 commented Feb 15, 2023

cprice404 commented Feb 15, 2023

kvcache left a comment

kvcache Feb 15, 2023

kvcache Feb 15, 2023

brayniac commented Feb 15, 2023 via email

kvcache commented Feb 15, 2023

brayniac commented Feb 15, 2023 via email

kvcache commented Feb 15, 2023

cprice404 commented Feb 15, 2023

feat: pin to working protos version, add lockfile #124

feat: pin to working protos version, add lockfile #124

Conversation

cprice404 commented Feb 14, 2023

kvcache Feb 14, 2023

Choose a reason for hiding this comment

cprice404 Feb 14, 2023

Choose a reason for hiding this comment

kvcache Feb 14, 2023

Choose a reason for hiding this comment

cprice404 Feb 15, 2023

Choose a reason for hiding this comment

kvcache Feb 15, 2023

Choose a reason for hiding this comment

cprice404 commented Feb 15, 2023

cprice404 commented Feb 15, 2023

kvcache left a comment

Choose a reason for hiding this comment

kvcache Feb 15, 2023

Choose a reason for hiding this comment

kvcache Feb 15, 2023

Choose a reason for hiding this comment

brayniac commented Feb 15, 2023 via email

kvcache commented Feb 15, 2023

brayniac commented Feb 15, 2023 via email

kvcache commented Feb 15, 2023

cprice404 commented Feb 15, 2023