[openpgp] Re: on discarding Literal Data Packet metadata [ was: Analysis document]

Daniel Kahn Gillmor <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <[email protected]>
On Sat 2025-07-12 10:48:02 +0100, Andrew Gallagher wrote:
> On 10 Jul 2025, at 22:05, Daniel Kahn Gillmor <[email protected]> wrote:
>
>> Can you (or anyone following this discussion) identify such a workflow?
>> I'm asking literally, not rhetorically.  We should be developing the
>> protocol based on at least reasonably well-understood use cases.
>
> The best I can do is this mail from Nickolay [1]. I think the only
> person who can definitively answer this is someone who uses the
> library he references. I doubt we will ever get such an answer
> though...
>
> [1] https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000019.html

Thanks for this pointer.  i'm including it here for reference:

Nickolay Olshevsky writes:

> I cannot say about the exact number but during my experience on some
> commercial OpenPGP library we had a lot of clients, including banking,
> financial and even military, who used to transfer data via automated and 
> semi-automated processes, and it included usage of filename/mtime in the 
> literal data packet. And even in the 2008-2010 those processes were 
> already running for years and I doubt that something would rapidly 
> change there if change at all.

Clearly, all these "automated and semi-automated" processes are broken,
to whatever extent they're relying on integrity and authenticity of the
filename/mtime information.  If we can't even identify them, i don't
know how we can provide fixes to the protocol that will be meaningful at
an application layer.

   --dkg

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.