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

Use GIT_EDITOR for editing and approving with cargo vet certify #180

Merged
merged 2 commits into from
Jun 14, 2022

Conversation

mystor
Copy link
Collaborator

@mystor mystor commented Jun 14, 2022

This is an alternative approach to the vet certify UX which uses the GIT_EDITOR in order to prompt and ask the user to input notes, and accept a statement while also showing the criteria descriptions.

In order to function more reliably on Windows, this code attempts to locate the git-for-windows install on the user's machine, and invokes the user's GIT_EDITOR through the git-for-windows' shell environment.

This does not attempt to replace the interactive prompt for selecting which criteria to certify for.

Fixes #165

This is an alternative approach to the `vet certify` UX which uses the
GIT_EDITOR in order to prompt and ask the user to input notes, and
accept a statement while also showing the criteria descriptions.

In order to function more reliably on Windows, this code attempts to
locate the git-for-windows install on the user's machine, and invokes
the user's GIT_EDITOR through the git-for-windows' shell environment.

This does not attempt to replace the interactive prompt for selecting
which criteria to certify for.

Fixes mozilla#165
@mystor mystor marked this pull request as ready for review June 14, 2022 15:46
@mystor
Copy link
Collaborator Author

mystor commented Jun 14, 2022

Example text file for `cargo vet certify indexmap 1.8.1` in the test project:
# Please read the following criteria and uncomment the statement below:

# === BEGIN CRITERIA "safe-to-deploy" ===
#
# This crate will not introduce a serious security vulnerability to production
# software exposed to untrusted input.
#
# Auditors are not required to perform a full logic review of the entire crate.
# Rather, they must review enough to fully reason about the behavior of all unsafe
# blocks and usage of powerful imports. For any reasonable usage of the crate in
# real-world software, an attacker must not be able to manipulate the runtime
# behavior of these sections in an exploitable or surprising way.
#
# Ideally, all unsafe code is fully sound, and ambient capabilities (e.g.
# filesystem access) are hardened against manipulation and consistent with the
# advertised behavior of the crate. However, some discretion is permitted. In such
# cases, the nature of the discretion should be recorded in the `notes` field of
# the audit record.
#
# For crates which generate deployed code (e.g. build dependencies or procedural
# macros), reasonable usage of the crate should output code which meets the above
# criteria.
#
# === END CRITERIA ===
#
# STATEMENT:

# I, Nika Layzell, certify that I have audited version 1.8.1 of indexmap in accordance with the above criteria.

# NOTES:

Copy link
Contributor

@Gankra Gankra left a comment

Choose a reason for hiding this comment

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

this all looks great!

src/editor.rs Outdated
}

// Trim off excess whitespace.
Ok(result.trim().to_owned())
Copy link
Contributor

Choose a reason for hiding this comment

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

i love this code because you trim as much as i do and it is such a relief

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I trim perhaps a bit more often than I should, but it seems to work here :p

assert!(
!line.starts_with('#'),
"Non-comment lines cannot start with a '#' comment character"
);
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm this is an interesting failure mode. I was initially worried this would create roundtripping issues but we never feed existing notes from a toml back into the editor, so the only weird case would be someone passing notes in on the CLI with an explicit # line and they'll get a very quick error so seems fine.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, I didn't love this as a failure case either. In git there's support for trying a sequence of comment characters and only falling over if all are used at the same time (https:/git/git/blob/9c897eef06347cc5a3eb07c3ae409970ab1052c8/builtin/commit.c#L669-L697), which I could add but it would require some changes to buffer the file in memory and only write it out with comments once it's been fully written.

The only place where this can come up right now though is if you pass a note on the command line which starts with a # character on some line, as we write the note from the command line out in the file for editing.

src/editor.rs Outdated
let file = BufReader::new(File::open(&path)?);
for line in file.lines() {
let line = line?;
if line.starts_with('#') {
Copy link
Contributor

Choose a reason for hiding this comment

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

confirming: a line that starts with a space and then a # is indeed not supposed to be treated as a comment? (both this code and add_comments seem to implicitly have this rule.

Copy link
Contributor

Choose a reason for hiding this comment

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

That said this is kind of weird because if you have leading space on a line we will trim it away afterwards, so that leading space being significant is strange...

I suppose relatedly, do we want someone to be able to have any kind of indentation in their notes? Because this code will absolutely just eat that indentation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think this code will only eat indentation at the start or end of the notes. IIRC I don't trim individual lines at all, so you can have leading whitespace for lines in the middle of your note.

The logic for comments is roughly copied from git's commitmessage, where IIRC only comment characters at the very start of the line are considered: https:/git/git/blob/74cc1aa55f30ed76424a0e7226ab519aa6265061/strbuf.c#L1135. I don't do all of the other fancy line cleanup stuff like removing trailing whitespace or collapsing extra newlines though :-)

Copy link
Contributor

Choose a reason for hiding this comment

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

You immediately trim the line just below: result.push_str(line.trim());

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oops, you're right. My bad

const LINE_ENDING: &str = "\r\n";

#[cfg(not(windows))]
const LINE_ENDING: &str = "\n";
Copy link
Contributor

Choose a reason for hiding this comment

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

NB Git does have some settings related to line endings and they are very annoying (this is fine for now though, especially since they're purely transient afaict) rust-lang/cargo#8523

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, I agree that git's work around newlines is very annoying. This was basically just added as a defensive measure for when opening the editor on Windows, as the windows newline has no risk of being preserved, and everything's normalized immediately after. If I didn't do this, I believe that the notepad fallback on older windows systems would break, because notepad didn't support unix line endings for the longest time.

// NOTE: This is probably not as reliably available as `vi`, but is easier to
// quit from for users who aren't familiar with vi.
#[cfg(not(windows))]
const FALLBACK_EDITOR: &str = "nano";
Copy link
Contributor

Choose a reason for hiding this comment

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

god bless

@mystor mystor merged commit 24d8d8d into mozilla:main Jun 14, 2022
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.

certify notes UX
2 participants