Page MenuHome GnuPG
Create Task
Maniphest T7722

GpgOL: Temp filename creation fails to choose proper extension
Testing, NormalPublic
Actions

Description

The get_tmp_outfile chooses everthing after the first "." as extension. It should choose everting after the last "."

Filename: "Report of meeting 02.04.25 regarding something.doc"
IS => Extension : "04.25 regarding something.doc"
SHOULD => "doc"

If the filename is very long and the dot early in the filename the temp filename could be longer than MAX_PATH.

Revisions and Commits

rO GpgOL
rObf5b303913df get_tmp_outfile fix

Related Objects

Event Timeline

mmontkowski triaged this task as Normal priority.Jul 14 2025, 4:39 PM
mmontkowski created this task.
mmontkowski changed the task status from Open to Testing.Jul 14 2025, 4:48 PM
mmontkowski moved this task from Backlog to WIP on the gpgol board.
mmontkowski moved this task from Backlog to WiP on the vsd33 board.
mmontkowski added a commit: rObf5b303913df: get_tmp_outfile fix.Jul 17 2025, 11:19 AM
• ebo added a project: gpd5x.Jul 17 2025, 2:14 PM
• ebo moved this task from Backlog to WIP on the gpd5x board.
• werner added a project: Bug Report.Jul 17 2025, 4:45 PM
• ebo renamed this task from Temp filename creation fails to choose proper extension to GpgOL: Temp filename creation fails to choose proper extension.Aug 5 2025, 9:09 AM
• ebo mentioned this in T7771: GpgOL: not selected signed mail with very long subject causes high CPU load.Aug 8 2025, 4:26 PM
timegrid added a subscriber: timegrid.Thu, Sep 4, 1:53 PM

How to test this? The follwing happens for an attachment of an encrypted mail on gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10:

  • Original filename with max length: long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.max.symmetric_encryption_gnupg_de.odt
  • Both displayed and downloaded filename is the same as the original one
  • Temporary filenames in C:\Users\g10\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook are
    • long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.with.some.dots.odt
    • long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.with.some.dots.in.it.long.filename.with.some.dots (002).odt
timegrid moved this task from WIP to QA on the gpd5x board.Tue, Sep 9, 3:53 PM
timegrid moved this task from QA to Done on the gpd5x board.Fri, Sep 12, 1:48 PM

Sorry, I just found out, that windows caps the filename earlier than max length, so my former tests were invalid.

I retried with the filename 123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.1.odt and the temporary filename is now attachment.odt or e.g. attachment (002).odt.

Possible improvements:

  • Use original filename on save (attachment.odt)
  • Use original filename on open

But as those long filenames are an edge case, I think it's ok. In any case, the extraction of the extension does now work now as intended, so I set this to done.