Document some best practices related to vendor import:

[delphij]

Summary

• Verify the source code comes from a trustworthy source.
• Always review the diff before importing.
• Run configure scripts and alike in an isolated environment.
• Perform tests inside chroot, jail or in VM first.

[emaste]

documentation/content/en/articles/committers-guide/_index.adoc

1130

Let's make this more explicit and prescriptive: "Always verify these signatures before proceeding."

1136

"weird" might not be sufficient - a well-crafted malicious payload probably won't look weird. I'm not sure of a better phrase though.

The OpenSSH upgrade instructions (in the tree) state:

11) Diff against the vendor branch:

    $ git diff --diff-filter=M vendor/openssh/X.YpZ HEAD:crypto/openssh

    Review the diff for any unexpected changes.

1191–1192

Again let's be more explicit -- maybe "These should be run in ..."
(I'm fine with a "should" here absent a more prescriptive approach / tooling that handles the build process.)

1198

indeed - it's important to do this for correctness, not just security.

1201

again let's just go with "your changes, run them in ..."

[delphij]

Address reviewer comments.

[imp]

I generally like this, a few comments.

documentation/content/en/articles/committers-guide/_index.adoc

1135

You may want to note here that looking for signatures and verifying them is required. Ideally, if there's multiple ways to verify (say by a signed git tag / commit and also by a src tarball that's signed by someone else). I don't good suggested wording for this.

1135

Oh, I'd also verify them when merging them into the FreeBSD tree. One should always be doing that to make sure that expected differences with upstream are retained, if they are still relevant.

It may also be good to state somewhere that we strive to keep the deltas to upstream small, etc. I'm currently working with the acpica code to make the changes auditable (they are kinda hard now due to too much noise).

1199

The jail is also useful for building after the configure. While the last "war" was fought with a configure script, the next one may be fought with a build system craziness.

[emaste]

documentation/content/en/articles/committers-guide/_index.adoc

1135

Keeping diffs small is good advice, but likely a different spot in this section.

[emaste]

I'm fine with this version, or with some updates for @imp's notes.

[delphij]

Address additional comments.