PoC: Tap 14 #2114

mnm678 · 2022-09-22T17:47:25Z

supersedes #2049

This pr is the proof of concept for TAP 14 for the TAP approval process. It should not be merged until that TAP is finalized.

Please fill in the fields below to submit a pull request. The more information
that is provided, the better.

Fixes #2040

Description of the changes being introduced by the pull request:

Please verify and check that the pull request fulfills the following
requirements:

The code follows the Code Style Guidelines
Tests have been added for the bug fix or new feature
Docs have been added for the bug fix or new feature

Removed the folders "metadata.staged" and "metadata" and added all the metadata inside the "1.0.0" and "2.0.0" Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Updated the spec version inside the metadata files inside the "2.0.0" folder Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Added the all the metadata files alongside the "1.0.0", "2.0.0" and "targets" folders Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Reverted the directory structure to keep all metadata inside "metadata.staged" and "metadata" folders Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Created a new "TAP 14" folder wherein I added all the metadata inside the "1.0.0" and "2.0.0" folders and added the "targets" folder Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Added the test case which checks for the TAP 14 folder Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Added a test function that check the contents inside the TAP 14 folder. Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Added a function to select specification version folder to download metadata from Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Added the logic for the new client update process inside tuf/ngclient/updater.py. Added test functions for the new process inside tests/test_updater_ng.py. Also made changes to some test files. Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Worked upon adding better tests in test_updater_ng.py and worked on the code structure for updater.py Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Made changes to _get_repository_versions() to read the supported-versions file and also removed _look() from fetcher.py and requests_fetcher.py Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Made changes to updater.py and config.py Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Added some more changes adhering to the reviews. Also worked on cleaning the code in the test file. This is the last pull request as part of GSoC'22 Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Signed-off-by: Marina Moore <mnm678@gmail.com>

coveralls · 2022-09-22T17:49:55Z

Pull Request Test Coverage Report for Build 3362649524

94 of 97 (96.91%) changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 97.926%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
tuf/ngclient/updater.py	82	85	96.47%

Totals
Change from base Build 3089293137:	-0.2%
Covered Lines:	1435
Relevant Lines:	1454

💛 - Coveralls

Signed-off-by: Marina Moore <mnm678@gmail.com>

znewman01 · 2022-09-26T12:04:07Z

tests/test_updater_ng.py

+            [
+                Root.type,
+                Snapshot.type,
+                "spec_version",


obligatory "we should probably make a type for spec_version" 🙂

znewman01 · 2022-09-26T12:05:11Z

tuf/ngclient/updater.py

@@ -122,12 +131,80 @@ def refresh(self) -> None:
            RepositoryError: Metadata failed to verify in some way
            DownloadError: Download of a metadata file failed in some way
        """
+        try:


probably worth refactoring into its own method

znewman01 · 2022-09-26T12:05:44Z

tuf/ngclient/updater.py

@@ -122,12 +131,80 @@ def refresh(self) -> None:
            RepositoryError: Metadata failed to verify in some way
            DownloadError: Download of a metadata file failed in some way
        """
+        try:
+            version_bytes = self._load_local_metadata("spec_version")
+            self._spec_version = json.loads(version_bytes.decode("utf-8"))[


move this line into an else clause?

znewman01 · 2022-09-26T12:07:18Z

tuf/ngclient/updater.py

+            target_bytes = self._fetcher.download_bytes(
+                url, self.config.supported_versions_max_length
+            )
+            repository_versions = json.loads(target_bytes)


I would love to pull the parsing/types/etc. out into a SupportedVersions type that could be tested independently

That's probably a more natural home for e.g. _get_spec_versions

I also thought about moving some of this into the metadata api, especially if we finalize the decision to sign this file in theupdateframework/taps#158

znewman01 · 2022-09-26T12:08:14Z

tuf/ngclient/updater.py

        self._load_timestamp()
        self._load_snapshot()
        self._load_targets(Targets.type, Root.type)

+    def _get_repository_versions(self) -> List[str]:


List[str] may be an out-of-date type now

znewman01 · 2022-09-26T12:17:57Z

tuf/ngclient/updater.py


-        self._load_root()
+        def filter_fn(a):


Can we give this a more meaningful name?

znewman01 · 2022-09-26T12:18:06Z

tuf/ngclient/updater.py


-        self._load_root()


Preference to pull this out into its own method.

znewman01 · 2022-09-26T12:19:06Z

tuf/ngclient/updater.py

+    repository_versions: List[str],
+    spec_version: str,
+    supported_versions: List[str],
+) -> Tuple[str, Optional[str]]:


Might be nice to introduce a SpecVersion class (basically a version/path tuple)

This would make the int conversion lines a little more bulletproof

I think I agree with @znewman01 if there are other use cases where you will need that tuple, but it seems as here the tuple doesn't mean versions/path, but version/warning where warning is even optional.

Honestly, not sure why we return the warning and not directly print it.
This will save us from the need to return it, make a variable, etc.

znewman01 · 2022-09-26T12:21:18Z

tuf/ngclient/updater.py

-                # 404/403 means current root is newest available
-                break
+        for next_version in range(lower_bound, upper_bound):
+            for version_repo in supported_version_repos:


I think that as-written this would accept /1.root.json, /2/2.root.json, 3.root.json which feels wrong.

Maybe we want to say:

for next_version in range(lower_bound, upper_bound): while supported_version_repos: if it's in supported_version_repos[0]: handle it! break else: supported_version_repos.pop()

Just added a test, this does ignore 3.root.json in your example. The complication is that both the supported_version_repos look and the next_version loop have to break early in some (different) cases, which is where the additional complexity comes in. I'm happy to simplify if there's an easier way to represent this.

znewman01 · 2022-09-26T12:26:10Z

tuf/ngclient/updater.py

+            json.dumps({"version": spec_version}).encode("utf-8"),
+        )
+
+        self._load_root(ordered_version_paths)


Thinking about this: it's totally possible that v2 root format will look totally different, so it seems wrong to try to load them the same way.

I've thought about implementing TAP-14 as a wrapper around the Updater. Basically, it would expose the same interface and keep a dict of {MajorVersion: Updater}.

Then, its job is to (1) parse the supported-versions and (2) delegate appropriately. This keeps the complexity of TAP-14 out of the Updater itself, and provides a more natural way to support a very-different v2.

I agree in general, but _load_root is unique in that it has to look in directories for multiple supported versions in order to ensure that no root metadata is missed. If the root format is changed, then this function could be updated as part of the client update to use the correct format for the current root file that is being checked.

I've thought about implementing TAP-14 as a wrapper around the Updater. Basically, it would expose the same interface and keep a dict of {MajorVersion: Updater}.

This is a great idea. Legacy python-tuf implemented TAP 4: Multiple repository consensus on entrusted targets (mapping file) support with a wrapper around the updater (see MultiRepoUpdater). It could be useful to experiment with multiple wrappers around the updater and how they would interact, so that we can determine whether we need to come up with another pattern so that TAP implementations aren't mutually exclusive.

That's a great point. We're hoping to take that approach in go-tuf for TAP 4 as well!

Interactions sound a little tricky...I think we're okay, we'd put the TAP-4 wrapper as the outermost layer?

We can cross that bridge when we come to it.

Yeah, my hunch is that ordering with TAP 4 at the outermost layer makes sense for TAP 4 + TAP 14.

Signed-off-by: Marina Moore <mnm678@gmail.com>

mnm678 · 2022-09-27T19:01:11Z

Thanks for the feedback! I made some changes. I'm going to do a larger refactor that creates types for SpecVersion and RepositoryVersions pending the discussion in theupdateframework/taps#158

JustinCappos · 2022-09-28T18:48:42Z

Does it make sense to have each piece of ?root? metadata on a repo always contain a list of the other spec_versions of metadata that are available on that repo? This way a client can better avoid being downgraded...

…

On Wed, Sep 28, 2022 at 6:17 AM Joshua Lock ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In tuf/ngclient/updater.py <#2114 (comment)> : > + ) + ) + if len(path) > 0: + ordered_version_paths.append(path[0]["path"]) + + for i in repository_versions_and_paths: + if i["version"] == spec_version: + self._spec_version_dir = i["path"] + + # persist the version number + self._persist_metadata( + "spec_version", + json.dumps({"version": spec_version}).encode("utf-8"), + ) + + self._load_root(ordered_version_paths) Yeah, my hunch is that ordering with TAP 4 at the outermost layer makes sense for TAP 4 + TAP 14. — Reply to this email directly, view it on GitHub <#2114 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD3GZ4T7CS52ATWBXALWAQLLZANCNFSM6AAAAAAQTJBUNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

mnm678 · 2022-09-28T19:00:10Z

Does it make sense to have each piece of ?root? metadata on a repo always contain a list of the other spec_versions of metadata that are available on that repo? This way a client can better avoid being downgraded...

I don't want to require anything of existing v1 implementations, but this is something we could explore for v2++. Another, similar idea discussed in theupdateframework/taps#158 is to have the supported-versions.json, which lists the supported versions on the repo file signed by root keys.

All of this is just to ensure that clients can find new versions as soon as they are available. The client won't downgrade spec versions once they use a higher spec version with a given repo.

trishankatdatadog · 2022-09-28T19:02:01Z

I'm still not convinced that there is a use case for clients dynamically choosing which major spec version they want to support.

JustinCappos · 2022-09-28T19:17:54Z

I'm still not convinced that there is a use case for clients dynamically choosing which major spec version they want to support.

I read the linked comment. Are you arguing that a client should support exactly one spec version or that a client should not decide per repo?

I would say that a client supporting multiple spec versions may be necessary if it interacts with different repos that use different versions. I do agree with the latter, that a client should always use the latest version.

trishankatdatadog · 2022-09-28T20:14:45Z

I would say that a client supporting multiple spec versions may be necessary if it interacts with different repos that use different versions.

Is there such a client? Why design for a need that does not yet exist? I think we should be careful not to overgeneralise.

MVrachev

I have reviewed the core TAP 14 logic in updater.py and in config.py.
I will review the test files next week.

MVrachev · 2022-09-30T13:17:56Z

tuf/ngclient/updater.py

@@ -85,6 +91,8 @@ def __init__(
        fetcher: Optional[FetcherInterface] = None,
        config: Optional[UpdaterConfig] = None,
    ):
+        self._spec_version = None  # spec_version is the last used version by the client to get metadata


Nit: Please provide a type for _spec_version as I suspect that mypy won't be happy.
Something like:
self._spec_version: Optional[str] = None

MVrachev · 2022-09-30T13:35:56Z

tuf/ngclient/updater.py

        self._load_timestamp()
        self._load_snapshot()
        self._load_targets(Targets.type, Root.type)

+    def _set_spec_version(self) -> List[str]:
+        try:
+            version_bytes = self._load_local_metadata("spec_version")


Where can we have a look into an example spec_version.json file?

MVrachev · 2022-09-30T13:38:00Z

tuf/ngclient/updater.py

+        """Returns a list of all the repository versions and paths."""
+
+        try:
+            url = f"{self._metadata_base_url}supported-versions.json"


Are there recommendations or documentation somewhere on what format will the supported-versions.json file have?

MVrachev · 2022-09-30T13:41:27Z

tuf/ngclient/updater.py

+        return ordered_version_paths
+
+
+    def _get_repository_versions(self) -> List[object]:


Actually, you know the exact format of your return type (as we see below in the except cause) and I think it will be better if you describe it as:
List[Dict[Any]]

MVrachev · 2022-09-30T13:44:09Z

tuf/ngclient/updater.py

+
+        repository_versions_and_paths = self._get_repository_versions()
+
+        repository_versions = [


Nit, but still makes it more readable:

Suggested change

repository_versions = [

repository_versions: List[str] = [

MVrachev · 2022-09-30T13:52:18Z

tuf/ngclient/updater.py

+    repository_versions: List[str],
+    spec_version: str,
+    supported_versions: List[str],
+) -> Tuple[str, Optional[str]]:


I think I agree with @znewman01 if there are other use cases where you will need that tuple, but it seems as here the tuple doesn't mean versions/path, but version/warning where warning is even optional.

MVrachev · 2022-09-30T13:53:22Z

tuf/ngclient/updater.py

+    repository_versions: List[str],
+    spec_version: str,
+    supported_versions: List[str],
+) -> Tuple[str, Optional[str]]:


Honestly, not sure why we return the warning and not directly print it.
This will save us from the need to return it, make a variable, etc.

MVrachev · 2022-09-30T13:55:58Z

tuf/ngclient/updater.py

+        ordered_version_paths = []
+
+        for version in sorted(repository_versions):
+            path = [i["path"] for i in repository_versions_and_paths if version <= int(spec_version) and i["version"] == version]


I think this is too complicated to be a one-liner.

MVrachev · 2022-09-30T13:56:57Z

tuf/ngclient/updater.py

@@ -296,7 +376,7 @@ def _persist_metadata(self, rolename: str, data: bytes) -> None:
                    pass
            raise e

-    def _load_root(self) -> None:
+    def _load_root(self, supported_version_repos) -> None:


Annotation is needed for supported_version_repos.

MVrachev · 2022-09-30T15:26:20Z

tuf/ngclient/updater.py

-                )
-                self._trusted_set.update_root(data)
-                self._persist_metadata(Root.type, data)
+        save_repo_version_dir = self._spec_version_dir


I see why you save the original content of self._spec_version_dir because you change self._spec_version_dir multiple times later, but I had to read it a couple of times.

I suggest instead passing the version_repo variable to download_metadata and with this you remove:

save_repo_version_dir variable

to_break flag

the if check for to_break at the end of the inner cycle and you can directly return after you add to supported_version_repos list

Signed-off-by: Marina Moore <mnm678@gmail.com>

mnm678 · 2022-10-03T18:21:03Z

I updated this pr to reflect theupdateframework/taps#158, and to address the mypy type errors.

There is one remaining mypy error that I can't seem to resolve, so I'd appreciate some advice from reviewers :)

znewman01

Enjoy the comments I left before I realized this hadn't been updated to match the new TAP 😛

I think for mypy you can manually annotate the type of test_cases:

test_cases: List[Tuple[List[str], str, List[str], str]] = ...

It kinda seems like a bug in mypy, though. Not sure where it's getting that shape for test_cases...

znewman01 · 2022-10-17T19:55:13Z

tests/repository_simulator.py

@@ -205,10 +205,15 @@ def _fetch(self, url: str) -> Iterator[bytes]:
        if path.startswith("/metadata/") and path.endswith(".json"):
            # figure out rolename and version
            ver_and_name = path[len("/metadata/") :][: -len(".json")]
+            # inside a version folder
+            if "/" in ver_and_name:
+                ver_and_name = ver_and_name.split("/")[1]


What happens if there's multiple nested folders? ver_and_name = "/foo/bar.json"

I like

>>> "foo/bar/baz.json".partition("/") ('foo', '/', 'bar/baz.json') >>> "foo/bar/baz.json".rpartition("/") ('foo/bar', '/', 'baz.json')

For making intent a little clearer there.

You can also assert len(ver_and_name.split("/") <= 2

znewman01 · 2022-10-17T19:55:32Z

tests/repository_simulator.py

-                self.root.consistent_snapshot and ver_and_name != Timestamp.type
+                self.root.consistent_snapshot
+                and ver_and_name != Timestamp.type
+                and ver_and_name != "supported-versions"


This isn't a thing anymore, right?

Signed-off-by: Marina Moore <mnm678@gmail.com>

mnm678 · 2022-10-24T13:48:12Z

Thanks @znewman01, this now reflects the latest version of the TAP.

Signed-off-by: Marina Moore <mnm678@gmail.com>

jku · 2024-04-23T08:07:38Z

TAP is now deferred.

I'll close this since there has been no action and it seems unlikely to get merged without major work. Please reopen if I'm being too hasty

abs007 and others added 16 commits September 22, 2022 10:26

Made the sample test repository

ce67fe4

Removed the folders "metadata.staged" and "metadata" and added all the metadata inside the "1.0.0" and "2.0.0" Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Updated spec versions inside 2.0.0

c8c3bb5

Updated the spec version inside the metadata files inside the "2.0.0" folder Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Updated the directory structure

2d830a0

Added the all the metadata files alongside the "1.0.0", "2.0.0" and "targets" folders Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Reverted to 6e20c31

1c507c3

Reverted the directory structure to keep all metadata inside "metadata.staged" and "metadata" folders Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Added the metadata under the newly created TAP 14 folder

ffbf4c4

Created a new "TAP 14" folder wherein I added all the metadata inside the "1.0.0" and "2.0.0" folders and added the "targets" folder Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Updated test_updater_ng.py file

66b52f8

Added the test case which checks for the TAP 14 folder Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Updated the test_updater_ng.py file

99a454e

Added a test function that check the contents inside the TAP 14 folder. Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Updated updater.py

3b2e29b

Added a function to select specification version folder to download metadata from Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Updated test functionality and code structure

8567160

Worked upon adding better tests in test_updater_ng.py and worked on the code structure for updater.py Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Updated updater.py

a70cc48

Made changes to _get_repository_versions() to read the supported-versions file and also removed _look() from fetcher.py and requests_fetcher.py Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Worked on reviews

04231c1

Made changes to updater.py and config.py Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Used the black formatter on updater.py

e3fda3d

Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Some more changes to updater.py and test_updater_ng.py

5814a2c

Added some more changes adhering to the reviews. Also worked on cleaning the code in the test file. This is the last pull request as part of GSoC'22 Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>

Rename TAP 14 directory 1.0.0 -> 1

cf3d41c

Signed-off-by: Marina Moore <mnm678@gmail.com>

TAP 14 fix tests

e0ddd4a

Signed-off-by: Marina Moore <mnm678@gmail.com>

mnm678 added 11 commits September 22, 2022 14:05

fix lint

3c7be68

Signed-off-by: Marina Moore <mnm678@gmail.com>

fix isort

78f5bfc

Signed-off-by: Marina Moore <mnm678@gmail.com>

fix style issues

d3b1493

Signed-off-by: Marina Moore <mnm678@gmail.com>

fix lint warnings

d65640b

Signed-off-by: Marina Moore <mnm678@gmail.com>

Add TAP 14 integration tests

250740d

Signed-off-by: Marina Moore <mnm678@gmail.com>

Update supported-versions.json to match TAP

1e7da4c

Signed-off-by: Marina Moore <mnm678@gmail.com>

add tap 14 root update order

2842d05

Signed-off-by: Marina Moore <mnm678@gmail.com>

fix lint

08b0c23

Signed-off-by: Marina Moore <mnm678@gmail.com>

fix lint

fa75d78

Signed-off-by: Marina Moore <mnm678@gmail.com>

fix pylint errors

fd3d4d7

Signed-off-by: Marina Moore <mnm678@gmail.com>

lint

2d6847c

Signed-off-by: Marina Moore <mnm678@gmail.com>

mnm678 requested a review from trishankatdatadog September 23, 2022 16:11

clean up tests

851b2d6

Signed-off-by: Marina Moore <mnm678@gmail.com>

mnm678 changed the title ~~Tap14~~ PoC: Tap 14 Sep 23, 2022

znewman01 reviewed Sep 26, 2022

View reviewed changes

simplify and refactor spec version checks

76567c6

Signed-off-by: Marina Moore <mnm678@gmail.com>

znewman01 mentioned this pull request Sep 30, 2022

Tap14 updates theupdateframework/taps#158

Merged

MVrachev suggested changes Sep 30, 2022

View reviewed changes

mnm678 added 4 commits October 3, 2022 11:46

Move repository supported-versions to root

515b4f2

Signed-off-by: Marina Moore <mnm678@gmail.com>

Fix typs

df2ecd4

Signed-off-by: Marina Moore <mnm678@gmail.com>

list -> List for python < 3.9

6b7cf5d

Signed-off-by: Marina Moore <mnm678@gmail.com>

fix pylint errors

f57bac7

Signed-off-by: Marina Moore <mnm678@gmail.com>

znewman01 reviewed Oct 17, 2022

View reviewed changes

mnm678 added 5 commits October 21, 2022 13:04

lint fix

4ffba95

Signed-off-by: Marina Moore <mnm678@gmail.com>

use supported_versions fields for root update

81c9718

Signed-off-by: Marina Moore <mnm678@gmail.com>

format tests

db67863

Signed-off-by: Marina Moore <mnm678@gmail.com>

remove flag not supported in python < 3.8

4b5bf7e

Signed-off-by: Marina Moore <mnm678@gmail.com>

clarify partition

a2e58e2

Signed-off-by: Marina Moore <mnm678@gmail.com>

mnm678 added 2 commits October 31, 2022 11:26

Add feature to supported versions

e77f033

Signed-off-by: Marina Moore <mnm678@gmail.com>

fix lint

d491d46

Signed-off-by: Marina Moore <mnm678@gmail.com>

lukpueh mentioned this pull request Nov 17, 2022

Tap 14 draft pr #2049

Closed

jku closed this Apr 23, 2024

		return ordered_version_paths


		def _get_repository_versions(self) -> List[object]:


		repository_versions_and_paths = self._get_repository_versions()

		repository_versions = [

PoC: Tap 14 #2114

PoC: Tap 14 #2114

Conversation

mnm678 commented Sep 22, 2022 • edited Loading

coveralls commented Sep 22, 2022 • edited Loading

Pull Request Test Coverage Report for Build 3362649524

💛 - Coveralls

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mnm678 commented Sep 27, 2022 • edited Loading

JustinCappos commented Sep 28, 2022 via email

mnm678 commented Sep 28, 2022

trishankatdatadog commented Sep 28, 2022

JustinCappos commented Sep 28, 2022

trishankatdatadog commented Sep 28, 2022

MVrachev left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mnm678 commented Oct 3, 2022

znewman01 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mnm678 commented Oct 24, 2022

jku commented Apr 23, 2024

mnm678 commented Sep 22, 2022 •

edited

Loading

coveralls commented Sep 22, 2022 •

edited

Loading

mnm678 commented Sep 27, 2022 •

edited

Loading

MVrachev left a comment •

edited

Loading