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