Re: [PATCH v2] CONTRIBUTING: Please sign your emails with PGP

G. Branden Robinson
2023-11-22T18:51:02Z

[-- Attachment #1: Type: text/plain, Size: 7952 bytes --]

Hi Alex,

At 2023-11-22T18:26:38+0100, Alejandro Colomar wrote:
> On Wed, Nov 22, 2023 at 10:25:57AM -0600, G. Branden Robinson wrote:
> > I think you should alter this advice to employ the active voice, not
> > the passive. When an authority is dispensing advice or direction,
> > people need to know who that authority is. In this case, it would
> > appear to be the Linux man-pages project maintainers. If there is
> > an external authority whose advice you are transmitting, then that
> > authority should likewise be cited by name.
>
> Both. I was advising, as you guessed, but gpg also does. How about
> the following?
>
>
> <diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 7b85e7375..bde085a63 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -57,13 +57,14 @@ Description
> help
>
> Sign your emails with PGP
> - It is strongly encouraged that you sign all of your emails sent
> - to the mailing list, (especially) including the ones containing
> + We strongly encourage that you sign all of your emails sent to
> + the mailing list, (especially) including the ones containing
> patches, with your PGP key. This helps establish trust between
> you and other contributors of this project, and prevent others
> impersonating you. If you don't have a key, it's not mandatory
> to sign your email, but you're encouraged to create and start
> - using a PGP key.
> + using a PGP key. See also:
> + <https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime>

LGTM!

> > I find it awkward to "strongly recommend" a best practice that isn't
> > easily facilitated by _any_ readily available tool without further
> > hacking.
>
> I find it awkward that mutt(1) disables crypto operations in
[...]
> I also find it awkward that when patatt(1) (and b4(1) wrapping it)
[...]
> I also find it awkward that MUAs (or actually anybody) don't seem to

Anaphora FTW! But don't stumble and fall into a chiasmus. ;-P

[...]
> I won't concede this. I strongly encourage everybody to sign mail and
> patches, and to encrypt whenever possible. And also strongly
> encourage everybody to press the powers that be (i.e., maintainers of
> MUAs) to make it easier. That present-day technology sucks doesn't
> lower the strength of my encouragement.
>
> > I "manually" sign my messages to this list (that is, via
> > keyboard-driven
>
> I find it really awkward that you need to do it manually. I suggest
> you to try and patch mutt(1), if you can.

I'm sure I _can_, with sufficient effort. A bear of very little brain
should be able to manage. But as a rule, I maintain local forks only of
projects that I frequently work on. Experience has taught me that when
I don't, and my upstream upgrades, it's too often a hard slog to
re-fork. I forget things and have to relearn them, and/or upstream has
refactored so much that I no longer recognize what I _need_ to patch.

MUA development is not an area I have yet found seductive.

I petition you to soften the language because I don't think you want to
give the impression that you'd prefer a patch go unsubmitted rather than
show up un-GPG-signed. (Am I mistaken?)

In fact, you might explicitly state how your handling process differs
for unsigned vs. signed patches. If there _is_ no difference--if there
is no queue penalty, or additional follow-up to authenticate the sender
that you undertake--then I suggest that what you're doing is turning
this aspect of the Linux man-pages contribution process into a platform
for editorializing about your preferences.

Now, far be it from me to rebuke anyone for expressing opinions:
practically every email I write is loaded with 'em. And in fact I
largely share your preference here, and have long (for 20+ years)
wondered why MUAs don't read your keyring and offer opportunistic
encryption of mails sent exclusively (To+Cc) to accounts in the keyring.

_But_ when you're employing the resources of a project X to pursue an
agenda with respect to projects W, Y, and Z (MUAs), I think it wise to
be forthright.

You might therefore articulate a concrete policy wherein you impose a
tax on unsigned patch submissions--or disclose the added costs that you
accrue when dealing with them. If you're not willing to do so, for
whatever reasons you can think of that make either one a bad idea, then
I repeat my advice to soften the language in the CONTRIBUTING.md file.
Or to redirect it: instead of inviting the patch submitter to infer that
the burden is on them to use tools that haven't yet been adequately
developed, you can express your grievance with MUAs in a paragraph or
two as an aside.

There's nothing inherently wrong with doing this. MUAs are obviously
relevant to a cooperative development process that is reliant on email.
You don't want to try the patience of your reader, but you do want to
alert them to a problem that has gone unsolved for a long time.

And I think that--as long as you don't make your editorial aside an
Invariant Section under the GNU FDL ;-)--people won't mind its presence.

> If you're unlucky, you'll be locked in some neomutt(1) features, in
> which case you're out of luck, as my suggested trick doesn't seem to
> work (but if it works, please let me know).

My continued use of neomutt is pure inertia. I gather that in the wake
of some contretemps in Debian regarding the naming of the mutt and
neomutt packages, mutt's upstream awakened and undertook active
development again. This is a good thing.

> I just found an erratum in K&R C v2 §5.5: In page 97, in the picture,
> 'amessage' and 'pmessage' are switched (IMO); pmessage should be the
> one with the two boxes and an arrow, since it's the pointer one. Is
> there a published errata for K&R C v2 so I can check this and report?

Yes...

https://s3-us-west-2.amazonaws.com/belllabs-microsite-dritchie/cbook/2ediffs.html

..via...

https://www.cs.princeton.edu/~bwk/cbook.html

...but the errata claim not to have been updated since October 2006.

Nevertheless your proposed erratum does not appear in that document, so
you might have a legit catch here. Time to email BWK and report it? ;-)

> And even the wording in the book shows that they didn't know that
> these functions are ill-designed (they are still useful in niche use
> cases, but I doubt they were designed with those cases in mind).
> Here's the quote.

I've seen the _original_ set of C string-handling functions attributed
to Nils-Peter Nelson (who was also in charge of DWB troff for a while).

Here they are, in the earliest form known to me:

https://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/include/string.h

(note the SCCS ident[1])

...but Nils-Peter probably cannot be blamed for directions this family
of functions took subsequently.

> < Write versions of the library functions strncpy, strncat, and
> < strncmp, which operate on at most the first n characters of their
> < argument strings
>
> To which of the args does 'n' apply? One (which?) or both?
> strncat(3) is not limited to 'n' characters in dst, so this 'n'
> applies to some random argument depending on the function: 1st for
> strncpy(3) (but kind of both), 2nd for strncat(3), both for
> strncmp(3).

If you want to have some fun reviewing code, let me point you here.

https://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/lib/libc/port/gen

Regards,
Branden

[1] ...likely a misnomer, but calling it the "SCCS 'what'" doesn't get
the idea across clearly. Incidentally the story behind SCCS vs.
RCS is an intriguingly ugly one. (AT&T being stereotypically dumb
about software licensing is not part of it.) We enlightened Git
users have nothing whatsoever to learn from it, do we?