Dear Maintainer,

The PDF files produced from cups-pdf always contains Author,
which is bad for security if the user wants to generate
sensitive PDF files.

The Author field is in the format of "(username)".
I confirmed this from LibreOffice writer, and Opera (browser),
and Chrome (browser).  When I tested LibreOffice, I specifically
switched off the inclusion of the user info in the document.

The PDF file produced by cups-pdf contains the "(username)" string
in two places.  One is as a regular PDF metadata, which you can
remove using a tool like pdftk.  But, I don't know how to delete
the other one, which takes the form of

<rdf:Description rdf:about='864de34d-855f-11ec-0000-eb4edbf2574'
xmlns:dc='http://purl.org/dc/elements/1.1/'
dc:format='application/pdf'><dc:title><rdf:Alt><rdf:li
xml:lang='x-default'>(Print -
Google)</rdf:li></rdf:Alt></dc:title><dc:creator><rdf:Seq><rdf:li>(furue)</rdf:li></rdf:Seq></dc:creator></rdf:Description>

In the above, "(furue)" is the string in question.

Regards,
Ryo

Greetings,

Does the issue you reported against printer-driver-cups-pdf still
apply to the 3.0.1-9 version currently shipping with Debian 11
(Bullseye)?

Martin-Éric

Greetings,

Does the issue you reported against printer-driver-cups-pdf still
apply to the 3.0.1-9 version currently shipping with Debian 11
(Bullseye)?

Martin-Éric

Dear Martin-Éric,

Sorry I no longer use Debian, and I don't have access to a Debian machine.

But, if this printer driver is still used today, you don't want to close
this bug without testing, because including the user name in the PDF file
without the user's knowledge isn't acceptable.  As far as I remember, I was
worried about this problem when I needed to submit an anonymized document.
Such needs still exist today.

To test this, you just open some document on a webbrowser and print it into
a PDF file and

$ strings generatedfile.pdf | grep -i <sensitiveinformation>

Also, I think there are tools to print PDF metadata.

When I did this on my current computer (macOS), the PDF file indeed didn't
include any user information as far as I can tell.

Regards,

Ryo

Dear Martin-Éric,

Sorry I no longer use Debian, and I don't have access to a Debian machine.

But, if this printer driver is still used today, you don't want to close
this bug without testing, because including the user name in the PDF file
without the user's knowledge isn't acceptable.  As far as I remember, I was
worried about this problem when I needed to submit an anonymized document.
Such needs still exist today.

To test this, you just open some document on a webbrowser and print it into
a PDF file and

$ strings generatedfile.pdf | grep -i <sensitiveinformation>

Also, I think there are tools to print PDF metadata.

When I did this on my current computer (macOS), the PDF file indeed didn't
include any user information as far as I can tell.

Regards,

Ryo

Dear Martin-Éric,

Sorry I no longer use Debian, and I don't have access to a Debian machine.

But, if this printer driver is still used today, you don't want to close
this bug without testing, because including the user name in the PDF file
without the user's knowledge isn't acceptable.  As far as I remember, I was
worried about this problem when I needed to submit an anonymized document.
Such needs still exist today.

To test this, you just open some document on a webbrowser and print it into
a PDF file and

$ strings generatedfile.pdf | grep -i <sensitiveinformation>

Also, I think there are tools to print PDF metadata.

When I did this on my current computer (macOS), the PDF file indeed didn't
include any user information as far as I can tell.

Regards,

Ryo

Revisiting the above issue, I notice that files printed by e.g.
Firefox to CUPS-PDF indeed include the creator and Author strings. I
don't see anything in CUPS-PDF source that would produce these. I'm
thus begining to wonder whether CUPS itself includes these fields by
standard? If yes, shall we reassign this bug to CUPS?

Martin-Éric