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:

quoted

Hi Seth,

On Mon, Jan 19, 2026 at 11:54:29AM +0000, Seth McDonald wrote:

[...]

quoted

quoted

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

quoted

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>