Re: [PATCH v1 00/19] man/man2/*: Update history of syscalls A-CH

[Alejandro Colomar <alx@kernel.org>]

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

Hi Seth,

On Wed, Jan 21, 2026 at 11:14:34AM +0000, Seth McDonald wrote:
> Hi Alex,
> 
> On Tue, Jan 20, 2026 at 02:50:22AM +0100, Alejandro Colomar wrote:
> > Hi Seth,
> > 
> > On Mon, Jan 19, 2026 at 11:54:29AM +0000, Seth McDonald wrote:
> [...]
> > > And on another note, I think I've found a way to stop Proton Mail from
> > > corrupting patches.  So my patches should henceforth all be PGP-signed,
> > > assuming my workaround is sufficient.
> > 
> > Yup; that worked!  All patches were correctly signed, and none were
> > corrupted (or at least I didn't notice).  Out of curiosity, what was the
> > workaround?
> 
> tl;dr: The solution was surprisingly simple: just always use
> quoted-printable or base64 for the email's transfer encoding.
> 
> Because I did not want to associate my Gmail address with my PGP key(s)
> (I very rarely use it), I spent a good while trying to figure out why
> Proton Mail was corrupting my patches.  And specifically, I continually
> experimented with different patches to see if I could predict exactly
> when and where any corruption would occur (scientific method ftw!).
> 
> This included trying out different combinations of options for
> git-send-email(1), including those which I previously had no
> understanding of.  And I eventually found that, given the same email,
> executing git-send-email(1) with the --transfer-encoding option set to
> '7bit' or '8bit' would produce the same corrupted patch, but with it set
> to 'quoted-printable' or 'base64' the patch would remain intact.
> 
> I also found that the mangling was deterministic.  The same email is
> always mangled the same way.  And the mangling always occurs via the
> insertion of line breaks into the email contents.
> 
> Not only that, but (and this is the weirdest part) if we treat line
> breaks as two characters (i.e. as CRLF), then every line break is
> inserted exactly every 1000 characters.  If you go back to the first
> corrupted patch I sent in and count from the start of the text/plain
> contents, you should find two out-of-place line breaks both 1000
> characters apart (again, counting line breaks as two characters).
> 
> After doing some research with this information, my guess as to what's
> happening is Proton Mail is getting an email from an external source,
> and checking it to ensure it conforms to the semantics of the specified
> content transfer encoding.  Including that lines are no longer than 998
> characters and line breaks use CRLF when using 7bit or 8bit encodings.
> But may not correctly reset its line length/character count to zero when
> encountering an LF and changing it to CRLF.  And so thinks that the
> email is one giant line, and inserts line breaks every 1000 characters
> to "fix" it.
> 
> This is just a guess though.  And regardless of the actual cause, I've
> reported the bug with this information (and more) to Proton.  So
> hopefully it'll be fixed sometime.

Wow!  Nice analysis!  I hope they fix it.  :)

> > And how did you sign the patches?  Was it with neomutt(1)?  
> 
> The way I set up my email workflow is with Proton Mail Bridge, which
> creates a local SMTP server I can use to send emails via mutt(1),
> git-send-email(1), etc.  I have it configured to by default sign all
> emails I send with the corresponding PGP key.  That way, any email I
> send with mutt(1) or git-send-email(1) should be automatically signed.
> 
> Now, yes, I am aware that a third party (Proton) having access to an
> (encrypted w/ my password) store of the private key I use can arguably
> defeat the purpose of using PGP.  After all, only *I* should ever have
> access to it.  And in principle I 100% agree.  But since my personal
> threat model currently doesn't include being a state target, I don't
> see the need to change my workflow.  (But who knows, seeing how the US
> is currently going, I may be compelled to change that...)
> 
> Besides, I also have a separate PGP key I keep *only* on a physical
> security key which I use for most non-email situations.  Such as
> encrypting documents and signing commits.  If I ever need extra
> assurance for authenticity or encryption, this is the key I use.

Thanks!  I'll keep that in mind for special situations.  For now, if
it's more comfortable to you, I guess what you're corrently doing is
relatively fine.  But as you say, it might not be a good idea in the
long term.  ;)


Cheers,
Alex

> -- 
> Take care,
> 	Seth McDonald.
> 
> On-list:  2336 E8D2 FEB1 5300 692C  62A9 5839 6AD8 9243 D369
> Off-list: 82B9 620E 53D0 A1AE 2D69  6111 C267 B002 0A90 0289

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

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