Re: [PATCH] Change attachment stamping to use stat st_mtime by default.

"Kevin J. McCarthy" <[email protected]> Sun, 23 Aug 2026 12:57:02 +0800

Newsgroups	gmane.mail.mutt.devel
Message-ID	<[email protected]>

On Sat, Aug 22, 2026 at 06:40:41AM +0200, Rene Kita wrote:
>On Fri, Aug 21, 2026 at 09:44:08PM +0800, Kevin J. McCarthy wrote:
>> On Fri, Aug 21, 2026 at 03:12:01PM +0200, Vincent Lefevre wrote:
>> > On 2026-08-21 11:00:58 -0000, Crystal Kolipe via Mutt-dev wrote:
>> > > On Fri, Aug 21, 2026 at 10:09:27AM +0200, Vincent Lefevre wrote:
>> > > > (actually, we want to know whether the file contents have changed).
>> > >
>> > > Then the correct and portable way to do it is to check file size,
>> > > and if that has not changed then check the actual contents.
>> >
>> > True. This is what *must* be done. Comparing the contents should be
>> > based on a cryptographic hash because the old contents are no longer
>> > available.
>> >
>> > The current Mutt behavior is buggy (on any platform): replacing
>> > an attachment (e.g. with "mv") by an one that isn't more recent
>> > is undetected by Mutt, while the goal of the test is to detect
>> > a replacement to ensure that the encoding is correct.
>>
>> I'm not strongly opposed to doing a hash.  But I think the original intent
>> was to protect the user against accidental trip-ups, not to provide a
>> fool-proof measure.  The user can just as easily override encoding and types
>> if they want to send something incorrect.
>
>What are real-world trip-ups that could happen and that this mechanism
>helps against?

Editing an attachment after attaching it (with a normal tool; recode is 
known to be an aberration).

Or editing the message, perhaps in a buffer still inside Emacs, after 
Mutt has control.  I think the latter is pretty hard to do though.  It 
won't work for $edit_headers, and Emacs kills the buffer when using 
server mode and exiting, at least by default.

Honestly, the protections offered have been minimal, but they've been 
that way for 30 years without any tickets or reported issues.  So, I'd 
need to be convinced this suddenly requires a redo using hashes.

If anyone has real experiences to share, please do so.  I've never 
personally had the warning trigger.

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA

signature.asc (application/pgp-signature, 833 B)