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

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

[Alejandro Colomar]

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

Cc: Matthew House <mattlloydhouse@gmail.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
 CONTRIBUTING | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 475244c13..7b85e7375 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -56,6 +56,29 @@ 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
+        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.
+
+        There are many ways you can sign your patches, and it depends on
+        your preferred tools.  You can use git-send-email(1) in
+        combination with mutt(1).  For that, do the following.
+
+        In <~/.gitconfig>, add the following section:
+
+            [sendemail]
+                sendmailcmd = mutt -H - && true
+
+        And then, patch mutt(1) to enable encryption in batch and mailx
+        modes, which is disabled in upstream mutt(1).  You can find a
+        patch here:
+        <https://gitlab.com/muttmua/mutt/-/merge_requests/173>.
+
    Patches
        If you know how to fix a problem in a manual page (if not, see
        "Reporting bugs" below), then send a patch in an email.
-- 
2.42.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[G. Branden Robinson]

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

Hi Alex,

At 2023-11-22T14:47:58+0100, Alejandro Colomar wrote:
> +   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
> +        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.

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.

Such a practice is important for long-term project governance because
that way your successors know at whose discretion the advice can/should
be updated.  While it does sometimes happen that a project changes
ownership into hands that are reckless and produce senseless churn such
that careless retention of old advice is actually preferable, in my
experience, it is at least as common for them to pass to people who are
uncertain of the motivations behind certain decisions, or cannot tell
which decisions were made with deliberation (as opposed to "going along
to get along") or following a recommended best practice that has become
invalidated by the passing decades.

The recent conversations about string copying on this list reflect just
how complex and frustrating such matters can be in another domain.
"Everybody" assumed for decades that copying strings in C was a
trivial matter.[1]  Now, we look back over three decades of our brethren
crucified upon CVE crosses along the Appian Way to a better C standard
library, and realize that Seventh Edition Unix probably should have some
offered something like a string_copying(7) document.

> +        There are many ways you can sign your patches, and it depends on
> +        your preferred tools.  You can use git-send-email(1) in
> +        combination with mutt(1).  For that, do the following.
> +
> +        In <~/.gitconfig>, add the following section:
> +
> +            [sendemail]
> +                sendmailcmd = mutt -H - && true
> +
> +        And then, patch mutt(1) to enable encryption in batch and mailx
> +        modes, which is disabled in upstream mutt(1).  You can find a
> +        patch here:
> +        <https://gitlab.com/muttmua/mutt/-/merge_requests/173>.

I find it awkward to "strongly recommend" a best practice that isn't
easily facilitated by _any_ readily available tool without further
hacking.

That you have to dispense this advice suggests to me that the status quo
has not yet caught up with your ambitions.  I would soften the strength
of your recommendation and explicitly concede that better tooling
support is necessary to advance the state of the art.

I "manually" sign my messages to this list (that is, via keyboard-driven
menu selections in neomutt(1)).  But I don't produce patches in
sufficient volume that this tedium rises to a serious annoyance.  So
what you might do for the time being is to focus on advice to similarly
situated users, and concede that, for people who are high frequency
patch generators, technology is lacking at present.

Regards,
Branden

[1] I encourage anyone with either a reverential or heretical turn of
    mind to review §5.5 of the 2nd edition of _The C Programming
    Language_ and consider it light of our string_copying(7)
    discussions.  I would attend particularly to what is implied by the
    recommendation of Exercise 5-5 to implement strncat(3), strncmp(3),
    and strncpy(3) from scratch.  (A Kernighan & Ritchie idolator might
    claim that they perceived all of the conceivable problems in 1988,
    and offered the exercise as an elliptical means of warning the
    sufficiently savvy reader that the standard library had gone astray.
    Personally, I think such an inference is inconsistent with Ritchie's
    own expressed opinions about obscurantism.[2]  But if there's one
    thing brogrammers are free with, it is negative assessments of
    others' intellects.

    I recently read an ACM oral history interview with the designer of
    the Pentium Pro.[3][4][5]  He passed along some excellent advice to
    anyone who has to endure a toxic working environment.

    "...if some human mind created something then your human mind can
    understand it.  You should always assume that, because if you assume
    it, it throws away all the doubts that are otherwise going to bother
    you, and it's going to free you to just concentrate on 'what am I
    seeing, how is it working, what should I do about it, what am I
    trying to learn from this'.  Never, ever think that you're not smart
    enough; that's all nonsense." -- Robert P. Colwell

[2] https://web.archive.org/web/20150218135530/http://cm.bell-labs.com/cm/cs/who/dmr/odd.html
[3] https://www.sigmicro.org/media/oralhistories/colwell.pdf

[4] Only one point concerns me about it.  There's a clash between
    Colwell's assertion that Intel had employed formal methods to
    validate the original Pentium's floating point unit, and accounts
    I've received from other sources (independently of but consistently
    with the Wikipedia article about the processor) that Intel had
    consciously _foregone_ such methods for that chip (presumably due to
    expense or deadline pressure).  The result was the infamous FDIV bug
    and, so I hear, a resolution to never again skip formal verification
    of the FPU.  I wonder if Colwell was mistaken here.

[5] Colwell's assessment of and stories about the ill-fated i432
    architecture are also worth reading.  The popular conception of that
    CPU constitutes a negative lesson like the one commonly expressed by
    Linux hackers who thoughtlessly traffic in Torvalds quotations about
    microkernels (as shibboleths of their clubhouse memberships?), in
    which we can observe the imprudence of parroting claims about why a
    technology failed.  If we accept Colwell's account, the compiler
    group tasked with supporting i432 was effectively a resistance
    movement against the chip architecture, and deliberately sandbagged
    the machine's performance.  That it was "stupid" to try to support
    the Ada programming language in a CPU, and to design it such that
    access checks were supported in a robust and hierarchical way, is
    the _wrong_ lesson to draw from i432's failure--just as
    "microkernels are inherently inefficient, hurr hurr" is precisely
    the wrong one to take from a single example, Mach, not being
    performant in the 1990s.

    But don't despair.  We can combat the claims of the ignorant by
    gathering and evaluating objective empirical measurements.  And then
    your management will select the wrong ones, to the exclusion of all
    others.

    Masaki Kobayashi warned us--there's no escaping the human condition.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar]

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

Hi Branden,

On Wed, Nov 22, 2023 at 10:25:57AM -0600, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2023-11-22T14:47:58+0100, Alejandro Colomar wrote:
> > +   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
> > +        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.
> 
> 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>
 
         There are many ways you can sign your patches, and it depends on
         your preferred tools.  You can use git-send-email(1) in

> Such a practice is important for long-term project governance because
> that way your successors know at whose discretion the advice can/should
> be updated.  While it does sometimes happen that a project changes
> ownership into hands that are reckless and produce senseless churn such
> that careless retention of old advice is actually preferable, in my
> experience, it is at least as common for them to pass to people who are
> uncertain of the motivations behind certain decisions, or cannot tell
> which decisions were made with deliberation (as opposed to "going along
> to get along") or following a recommended best practice that has become
> invalidated by the passing decades.

+1

> 
> The recent conversations about string copying on this list reflect just
> how complex and frustrating such matters can be in another domain.
> "Everybody" assumed for decades that copying strings in C was a
> trivial matter.[1]  Now, we look back over three decades of our brethren
> crucified upon CVE crosses along the Appian Way to a better C standard
> library, and realize that Seventh Edition Unix probably should have some
> offered something like a string_copying(7) document.
> 
> > +        There are many ways you can sign your patches, and it depends on
> > +        your preferred tools.  You can use git-send-email(1) in
> > +        combination with mutt(1).  For that, do the following.
> > +
> > +        In <~/.gitconfig>, add the following section:
> > +
> > +            [sendemail]
> > +                sendmailcmd = mutt -H - && true
> > +
> > +        And then, patch mutt(1) to enable encryption in batch and mailx
> > +        modes, which is disabled in upstream mutt(1).  You can find a
> > +        patch here:
> > +        <https://gitlab.com/muttmua/mutt/-/merge_requests/173>.
> 
> 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
non-interactive mode, and that neomutt(1) even removed mailx mode[1]

[1]:  <https://github.com/neomutt/neomutt/pull/2385>

I also find it awkward that when patatt(1) (and b4(1) wrapping it)
decided to make signing patches easy, they didn't patch a MUA to support
signing emails in a header field, and instead wrote a new program that
creates something that no MUA understands, and so one can only know if a
patch has been signed with patatt(1) by using patatt(1) (or b4(1)
wrapping it).

I also find it awkward that MUAs (or actually anybody) don't seem to be
interested in fixing this situation.

> That you have to dispense this advice suggests to me that the status quo
> has not yet caught up with your ambitions.  I would soften the strength
> of your recommendation and explicitly concede that better tooling
> support is necessary to advance the state of the art.

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.  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).

> menu selections in neomutt(1)).  But I don't produce patches in
> sufficient volume that this tedium rises to a serious annoyance.  So
> what you might do for the time being is to focus on advice to similarly
> situated users, and concede that, for people who are high frequency
> patch generators, technology is lacking at present.
> 
> Regards,
> Branden
> 
> [1] I encourage anyone with either a reverential or heretical turn of
>     mind to review §5.5 of the 2nd edition of _The C Programming
>     Language_ and consider it light of our string_copying(7)
>     discussions.  I would attend particularly to what is implied by the
>     recommendation of Exercise 5-5 to implement strncat(3), strncmp(3),
>     and strncpy(3) from scratch.

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?

>  (A Kernighan & Ritchie idolator might
>     claim that they perceived all of the conceivable problems in 1988,
>     and offered the exercise as an elliptical means of warning the
>     sufficiently savvy reader that the standard library had gone astray.
>     Personally, I think such an inference is inconsistent with Ritchie's
>     own expressed opinions about obscurantism.[2]  But if there's one
>     thing brogrammers are free with, it is negative assessments of
>     others' intellects.

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.

< 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).

Cheers,
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[G. Branden Robinson]

[-- 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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar]

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

Hi Branden,

On Wed, Nov 22, 2023 at 12:50:59PM -0600, G. Branden Robinson wrote:
> Hi Alex,

> > <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!

Thanks!

> 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.

Makes sense.

> 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?)

Nope; you're right.  But doesn't the "... it's not mandatory ..."
clarify that in you opinion?

> In fact, you might explicitly state how your handling process differs

I can do that in a mail, but if I try to write that in CONTRIBUTING, it
could take a huge part of the file, and I don't want to hide other info
with that.

> for unsigned vs. signed patches.

If I see a small patch that is obvious, I'll review it visually, and
decide upon that.  There's no difference between signed and unsigned
patches in those cases, which hopefully should be most of them.

However, from time to time, there are patches that I'm unable to review,
usually because I don't understand them.  A case you know is MR.sed.
There's no way I'll understand that script, and I don't even want to.
In other cases, people with deep specific knowledge, like kernel
maintainers, or for example, Paul Eggert for certain libc functions,
send patches about their stuff.

There are details in those patches that I give up trying to understand
and just trust that the sender knows better, and that if any issues come
up later, the sender will fix them.  Trusted contributors have certain
privileges with their patches.

In your case, all of your patches are signed, so I can verify that
you're consistently the same I talked to in every mail thread.  In the
case of Paul, for example, he doesn't sign any email, so I can't trust
with 100% certainty that every mail is actually sent from him.  I'm not
scared enough to send him a private email every time he sends a patch
asking him to sign it, because that is unlikely, and would hopefully get
caught by Paul himself if he reads the list, but there's always a small
chance.

Konstantin Ryabitsev wrote about this[1], and developed b4(1) and
patatt(1).  However, I think those programs are more complex than
patching mutt(1), and also offer less versatility (encryption is
problematic, so for patches fixing vulnerabilities, you need a different
method; I don't like that) than mutt(1).

IIRC (but can't find it), Greg KH also talked about why signing patches
is recommended.

[1]:  <https://people.kernel.org/monsieuricon/end-to-end-patch-attestation-with-patatt-and-b4>

I didn't recommend using b4(1), because I haven't yet learnt to use it
myself, so can't say it's easy.  With mutt(1), I can say it's easy:
2-line config + 1 line patch.  Ok, that's not the easiest it can be, but
it's the easiest I know of.

>  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.

There's a difference.  In untrusted patches, I am paranoic about
malicious contributors trying to misdocument features with the intention
of provoking vulnerabilities.  I don't do that for trusted patches.

> 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.

mutt(1) (and neomutt(1)) do:

	$ cat .config/mutt/gpg.muttrc 
	set crypt_autosign = yes
	set crypt_opportunistic_encrypt = yes
	set crypt_protected_headers_write = yes

	set pgp_self_encrypt = yes
	set pgp_default_key = A9348594CE31283A826FBDD8D57633D441E25BB5


	$ grep gpg.muttrc .config/mutt/muttrc 
	source ~/.config/mutt/gpg.muttrc

I never have to press any key for signing mail (nor for encrypting mail
to recipients whose keys I've signed).  Or do you mean in batch and
mailx modes?  (Regarding encryption, I think there should be a way to
tell mutt(1) to accept unsigned keys without asking --and maybe there is
and I don't know it--.)

> _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

My only reticence to do that is that I don't want that file to grow too
much.  And the only pages I know of that I could link to, are those of
b4(1) and patatt(1), but I don't want to suggest those tools.

> 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.

Yeah, I'll try adding a paragraph saying that MUAs don't help.

> 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.

And neomutt(1)'s Debian package has been dying for the last years.  It's
not getting the new versions from upstream.  So much that when I tried
neomutt(1) with a config suggested in <neomutt.org>, it didn't
understand some configurations.  There's a neomutt(1) contributor that
also contributes often to the Linux man-pages who maintains a Debian
package repository, and provides a more up-to-date package.
 
> > 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? ;-)

Nice!  :)

> > 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

Interesting; I only see 2 uses of strncat(3) in v7:

	$ grep -rn '\sstrncat *('
	usr/src/cmd/dumpdir.c:153:			strncat(prefix, dir.d_name, sizeof(dir.d_name));
	usr/src/cmd/login.c:107:	strncat(homedir, pwd->pw_dir, sizeof(homedir)-6);

Of these, the second is an abuse of this function, and a function that
gets the size of the dst buffer instead of the src buffer should have
been written.  strlcat(3) would have been more appropriate (although as
Paul said, it has DoS problems, so something like strtcat() could be
written that would return -1 on truncation).

strncpy(3) is similarly abused to open-code an strlcpy(3) (or strtcpy())
in several places.

> 
> 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?



-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Errata in K&R C v2, page 97 (was: [PATCH v2] CONTRIBUTING: Please sign your emails with PGP)

[Alejandro Colomar]

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

Hello Brian,

> On Wed, Nov 22, 2023 at 10:25:57AM -0600, G. Branden Robinson wrote:
> > [1] I encourage anyone with either a reverential or heretical turn of
> >     mind to review §5.5 of the 2nd edition of _The C Programming
> >     Language_ and consider it light of our string_copying(7)
> >     discussions.  I would attend particularly to what is implied by the
> >     recommendation of Exercise 5-5 to implement strncat(3), strncmp(3),
> >     and strncpy(3) from scratch.
 
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.  We didn't
find it in the existing list of errata[1], which Branden pointed to me.

[1]:  <https://www.cs.princeton.edu/~bwk/cbook.html>

Cheers,
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Errata in K&R C v2, page 97 (was: [PATCH v2] CONTRIBUTING: Please sign your emails with PGP)

[Brian Kernighan]

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

In the printed version of the C book, section 5.5 begins on page 104.
pmessage is indeed the one with two boxes and an arrow.

Are you looking at the real book or some mutated copy from the web?
I have had error reports in the past on imperfectly pirated copies.

On Wed, 22 Nov 2023, Alejandro Colomar wrote:

> Hello Brian,
>
>> On Wed, Nov 22, 2023 at 10:25:57AM -0600, G. Branden Robinson wrote:
>>> [1] I encourage anyone with either a reverential or heretical turn of
>>>     mind to review §5.5 of the 2nd edition of _The C Programming
>>>     Language_ and consider it light of our string_copying(7)
>>>     discussions.  I would attend particularly to what is implied by the
>>>     recommendation of Exercise 5-5 to implement strncat(3), strncmp(3),
>>>     and strncpy(3) from scratch.
>
> 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.  We didn't
> find it in the existing list of errata[1], which Branden pointed to me.
>
> [1]:  <https://www.cs.princeton.edu/~bwk/cbook.html>
>
> Cheers,
> Alex
>
> -- 
> <https://www.alejandro-colomar.es/>
>

Re: Errata in K&R C v2, page 97 (was: [PATCH v2] CONTRIBUTING: Please sign your emails with PGP)

[Alejandro Colomar]

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

Hello Brian,

On Sun, Nov 26, 2023 at 09:57:32AM -0500, Brian Kernighan wrote:
> In the printed version of the C book, section 5.5 begins on page 104.
> pmessage is indeed the one with two boxes and an arrow.
> 
> Are you looking at the real book or some mutated copy from the web?
> I have had error reports in the past on imperfectly pirated copies.

My real copy of the book is in Norway with my brother, very far from me.
Indeed, I read some online copy for the report.  It was something
converted to an ebook or something like that.  I'll try to find the
link.

Cheers,
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Errata in K&R C v2, page 97 (was: [PATCH v2] CONTRIBUTING: Please sign your emails with PGP)

[Alejandro Colomar]

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

On Sun, Nov 26, 2023 at 04:47:49PM +0100, Alejandro Colomar wrote:
> Hello Brian,
> 
> On Sun, Nov 26, 2023 at 09:57:32AM -0500, Brian Kernighan wrote:
> > In the printed version of the C book, section 5.5 begins on page 104.
> > pmessage is indeed the one with two boxes and an arrow.
> > 
> > Are you looking at the real book or some mutated copy from the web?
> > I have had error reports in the past on imperfectly pirated copies.
> 
> My real copy of the book is in Norway with my brother, very far from me.
> Indeed, I read some online copy for the report.  It was something
> converted to an ebook or something like that.  I'll try to find the
> link.

Here it is:
<https://venkivasamsetti.github.io/ebookworm.github.io/Books/cse/C%20Programming%20Language%20(2nd%20Edition).pdf>

> 
> Cheers,
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es/>



-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Errata in K&R C v2, page 97 (was: [PATCH v2] CONTRIBUTING: Please sign your emails with PGP)

[Brian Kernighan]

pirated (thanks, github) but inaccurately.  someone re-drew the diagrams
and got the labels wrong.

sigh.

brian

On Sun, 26 Nov 2023, Alejandro Colomar wrote:

> On Sun, Nov 26, 2023 at 04:47:49PM +0100, Alejandro Colomar wrote:
>> Hello Brian,
>>
>> On Sun, Nov 26, 2023 at 09:57:32AM -0500, Brian Kernighan wrote:
>>> In the printed version of the C book, section 5.5 begins on page 104.
>>> pmessage is indeed the one with two boxes and an arrow.
>>>
>>> Are you looking at the real book or some mutated copy from the web?
>>> I have had error reports in the past on imperfectly pirated copies.
>>
>> My real copy of the book is in Norway with my brother, very far from me.
>> Indeed, I read some online copy for the report.  It was something
>> converted to an ebook or something like that.  I'll try to find the
>> link.
>
> Here it is:
> <https://venkivasamsetti.github.io/ebookworm.github.io/Books/cse/C%20Programming%20Language%20(2nd%20Edition).pdf>
>
>>
>> Cheers,
>> Alex
>>
>> --
>> <https://www.alejandro-colomar.es/>
>
>
>
> -- 
> <https://www.alejandro-colomar.es/>
>