OK, I've looked through the other 50% of the original diff, (I've not looked
at the new one).
Comments in-line:
On Thu, Dec 22, 2022 at 06:31:23PM -0500, Paul Tagliamonte wrote:
> Index: lib/libssl/test/pkits-test.pl
> ===================================================================
> RCS file: /cvs/src/lib/libssl/test/pkits-test.pl,v
> retrieving revision 1.1.1.2
> diff -u -p -r1.1.1.2 pkits-test.pl
> --- lib/libssl/test/pkits-test.pl 13 Oct 2012 21:23:50 -0000 1.1.1.2
> +++ lib/libssl/test/pkits-test.pl 22 Dec 2022 21:14:14 -0000
> @@ -124,7 +124,7 @@ my @testlists = (
> [ "4.4.7", "Valid Two CRLs Test7", 0 ],
>
> # The test document suggests these should return certificate revoked...
> - # Subsquent discussion has concluded they should not due to unhandle
> + # Subsequent discussion has concluded they should not due to unhandle
> # critical CRL extensions.
> [ "4.4.8", "Invalid Unknown CRL Entry Extension Test8", 36 ],
> [ "4.4.9", "Invalid Unknown CRL Extension Test9", 36 ],
> @@ -749,7 +749,7 @@ my @testlists = (
> [ "4.14.29", "Valid cRLIssuer Test29", 0 ],
>
> # Although this test is valid it has a circular dependency. As a result
> - # an attempt is made to reursively checks a CRL path and rejected due to
> + # an attempt is made to recursively checks a CRL path and rejected due to
> # a CRL path validation error. PKITS notes suggest this test does not
> # need to be run due to this issue.
> [ "4.14.30", "Valid cRLIssuer Test30",
> 54 ],
If we're going to change it at all, we should fix the bad grammar at the same
time, checks -> check.
> Index: usr.bin/vi/docs/USD.doc/exref/ex.summary
> ===================================================================
> RCS file: /cvs/src/usr.bin/vi/docs/USD.doc/exref/ex.summary,v
> retrieving revision 1.6
> diff -u -p -r1.6 ex.summary
> --- usr.bin/vi/docs/USD.doc/exref/ex.summary 30 Jan 2004 23:14:26 -0000
> 1.6
> +++ usr.bin/vi/docs/USD.doc/exref/ex.summary 22 Dec 2022 21:15:30 -0000
> @@ -590,8 +590,8 @@ made; see the manual for details.
> T} T{
> .nf
> :\fB3p
> -\fRLine 3 contains a misstake
> -:\fBs/misstake/mistake/
> +\fRLine 3 contains a mistake
> +:\fBs/mistake/mistake/
> \fRLine 3 contains a mistake
> \*c
> .fi
This is an entirely intentional mis-spelling, as it is documenting the
substitute function of ex.
> Index: usr.sbin/smtpd/crypto.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/smtpd/crypto.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 crypto.c
> --- usr.sbin/smtpd/crypto.c 14 Jun 2021 17:58:15 -0000 1.10
> +++ usr.sbin/smtpd/crypto.c 22 Dec 2022 21:15:32 -0000
> @@ -375,7 +375,7 @@ main(int argc, char *argv[])
> /* uncomment below to provoke integrity check failure */
> /*
> * fpin = fopen("/tmp/passwd.enc", "a");
> - * fprintf(fpin, "borken");
> + * fprintf(fpin, "broken");
> * fclose(fpin);
> */
> fpin = fopen("/tmp/passwd.enc", "r");
Be careful. We shouldn't change borken to broken across the tree with a
simple search and replace.
Whist in this case it seems, (to me), to be a typo, the word 'borken' is
sometimes used as a derivative of 'borked', and understood to mean very much
broken, I.E. synonymous with 'fubar'.
> Index: usr.sbin/smtpd/mta_session.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/smtpd/mta_session.c,v
> retrieving revision 1.147
> diff -u -p -r1.147 mta_session.c
> --- usr.sbin/smtpd/mta_session.c 26 Sep 2022 08:48:52 -0000 1.147
> +++ usr.sbin/smtpd/mta_session.c 22 Dec 2022 21:15:32 -0000
> @@ -635,7 +635,7 @@ again:
> else if (s->relay->secret) {
> log_debug("debug: mta: %p: not using AUTH on non-TLS "
> "session", s);
> - mta_error(s, "Refuse to AUTH over unsecure channel");
> + mta_error(s, "Refuse to AUTH over insecure channel");
> mta_connect(s);
> } else {
> mta_enter_state(s, MTA_READY);
This seems like change for change's sake, as 'unsecure' is a perfectly valid,
if slightly antiquated alternative.
Whilst I agree that correcting spelling and grammar is important, (especially
as it affects searching of the source tree), any changes need to be extensively
manually reviewed.
I would like to point out to the list that just because I have read through
this massive diff and highlighted some issues does not mean that I am
supporting the rest of the changes.
