Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure lockfiles are files #1202

Closed
wants to merge 1 commit into from
Closed

Ensure lockfiles are files #1202

wants to merge 1 commit into from

Conversation

cd-work
Copy link
Contributor

@cd-work cd-work commented Aug 17, 2023

This patch introduces a metadata check for lockfile and manifest paths to ensure that they're files instead of directories.

Closes #1177.


This is in part somewhat of a request for comments, since I'm not entirely sure which approach we want to take here. In the CLI we can certainly always read the metadata, but I'm not sure if the same applies to the GitHub app?

Is this check beneficial in general, or are we maybe just introducing another point of failure that doesn't really matter in practice?

One alternative I have thought of myself is to check that the metadata is not a directory. This would still work if the file doesn't exist at all, but it does technically still try to read the path's metadata.

This patch introduces a metadata check for lockfile and manifest paths
to ensure that they're files instead of directories.

Closes #1177.
@cd-work cd-work requested a review from a team as a code owner August 17, 2023 12:47
@cd-work cd-work requested review from maxrake and kylewillmon August 17, 2023 12:47
Copy link
Contributor

@maxrake maxrake left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks fine to me...with the exception of lockfile/src/csharp.rs, which is treated differently than the rest.

We'll want to update #1200 with the same changes made here, for the new lockfile/src/cyclonedx.rs (CC: @ejortega). A comment has been added to that review already.

The changes were tested locally and appear to work as expected. Automatic discovery of lockfiles will no longer include directories. Plus, the manual submission of a directory as a lockfile has better (less noisy) error messages:

../cli/delme  2  0 on  lockfile_is_file [✘!?]
❯ l
total 0
drwxr-xr-x   4 maxrake  staff   128B Aug 17 10:07 .
drwxr-xr-x  37 maxrake  staff   1.2K Aug 17 10:10 ..
drwxr-xr-x   2 maxrake  staff    64B Aug 17 10:07 Cargo.lock
drwxr-xr-x   2 maxrake  staff    64B Aug 17 10:07 requirements.txt

../cli/delme  2  0 on  lockfile_is_file [✘!?]
❯ ../target/debug/phylum parse requirements.txt
❗ Error: Is a directory (os error 21)

../cli/delme  2  0 on  lockfile_is_file [✘!?]
❌ 1 ❯ ../target/debug/phylum parse Cargo.lock
❗ Error: Is a directory (os error 21)

One suggestion is to provide a bit more context in that error message by including the name of the directory that was submitted as a lockfile/manifest. Something like: Error: Cargo.lock is a directory but a file was expected.

Marking as "request changes" just to ensure the outstanding questions are answered before continuing.

@@ -47,7 +47,7 @@ impl Parse for PackagesLock {
};

// Accept both `packages.lock.json` and `packages.<project_name>.lock.json`.
file_name.starts_with("packages.") && file_name.ends_with(".lock.json")
file_name.starts_with("packages.") && file_name.ends_with(".lock.json") && path.is_file()
}

fn is_path_manifest(&self, path: &Path) -> bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was the && path.is_file() check for manifest files left off here intentionally? If so, why is it treated differently?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just missed it.

@maxrake maxrake mentioned this pull request Aug 17, 2023
5 tasks
maxrake added a commit to phylum-dev/phylum-ci that referenced this pull request Aug 17, 2023
The change ensures that lockfiles that are not files are filtered out before processing. This change aligns with the corresponding one made in the CLI (phylum-dev/cli#1202). It is done separately here because #244 (Replace lockfile detection with `phylum status`) has not been implemented yet. Plus, this allows for a fix without changing the minimum supported CLI version.
@cd-work
Copy link
Contributor Author

cd-work commented Aug 18, 2023

Closing because #1177 (comment).

@cd-work cd-work closed this Aug 18, 2023
@cd-work cd-work deleted the lockfile_is_file branch August 18, 2023 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Directories detected as lockfiles
2 participants