Bug 99514

The producer is the library that generated the PDF. This is always cairo.

There are two reasons why we would like to be able to set this metadata:


1) There are libraries that use cairo internally: one example is libgxps which is used to convert xps to pdf and internally uses cairo: I think it would be more accurate to be able to set producer to gxps in that case

2) As Ignacio mentioned, there are cases where it would be better to not include any metadata at all. This was reported to us as a security concern, if you have a server application that generates a pdf an attacker can know that the server is using cairo for that specific function and explot known vulerabilities

(In reply to Paolo Borelli from comment #2)
> There are two reasons why we would like to be able to set this metadata:
> 
> 
> 1) There are libraries that use cairo internally: one example is libgxps
> which is used to convert xps to pdf and internally uses cairo: I think it
> would be more accurate to be able to set producer to gxps in that case

In this case you set the creator to gxps. The creator is the code that generated the PDF content. The producer is the code that generated the PDF structure.

> 2) As Ignacio mentioned, there are cases where it would be better to not
> include any metadata at all. This was reported to us as a security concern,
> if you have a server application that generates a pdf an attacker can know
> that the server is using cairo for that specific function and explot known
> vulerabilities

This is not a valid security concern. It is easy to determine the producer by comparing the PDF structure with sample output from various PDF producers.

> 
> This is not a valid security concern. It is easy to determine the producer
> by comparing the PDF structure with sample output from various PDF producers.

Well, clearly it will not stop from doing that but it will make it more difficult though. I do no not see such a problem adding the ability to set that field.

(In reply to Adrian Johnson from comment #3)
> (In reply to Paolo Borelli from comment #2)
> > There are two reasons why we would like to be able to set this metadata:
> > 
> > 
> > 1) There are libraries that use cairo internally: one example is libgxps
> > which is used to convert xps to pdf and internally uses cairo: I think it
> > would be more accurate to be able to set producer to gxps in that case
> 
> In this case you set the creator to gxps. The creator is the code that
> generated the PDF content. The producer is the code that generated the PDF
> structure.
>

Well, the creator would be the program that uses libgxps.

 
> > 2) As Ignacio mentioned, there are cases where it would be better to not
> > include any metadata at all. This was reported to us as a security concern,
> > if you have a server application that generates a pdf an attacker can know
> > that the server is using cairo for that specific function and explot known
> > vulerabilities
> 
> This is not a valid security concern. It is easy to determine the producer
> by comparing the PDF structure with sample output from various PDF producers.

Security is not black and white, it is about mitigating risk: reading metadata is much simpler than what you describe. It is unfortunate that we will need to strip the metadata in post processing...

It sounds like there are two distinct problems wanting addressed:

1.  A way to omit metadata entirely from generated PDFs
2.  A way to modify the Producer string in cairo-generated PDFs

Regarding the first point:  Like Adrian I'm skeptical of the actual value of omitting metadata for security protection (seems merely security-through-obscurity) -- I'd need to see a stronger case made to be convinced.  That said, I recall in Inkscape we had some interoperational/compatibility problems with SVG that included metadata, so provide a way for users to get stripped down "plain SVG" that excludes it.  I don't know if such problems are at all likely with PDF metadata, but if there are legitimate concerns here I wouldn't be opposed to allowing a toggle to omit it.

For the second point, again like Adrian says it appears that most cases where an app or library is using Cairo to produce PDFs they should list themselves as the Creator with Cairo as the PDF Producer.  Googling around seems to indicate Adobe and other PDF tools follow this same strategy.  There does seem to be demand for an ability to customize the Producer field, but from what I can tell it seems to be for branding purposes (or maybe even more nefarious reasons), which seem hardly compelling...

That said, it seems like it is easy enough to edit the generated PDF's metadata using other free software tools, and maybe it'd be better for Cairo to allow adding to the string so Cairo still gets tagged.  E.g. I'm thinking something more like:

... "   /Producer %s (cairo %s (http://cairographics.org))\n",
    ic->docinfo.producer, cairo_version_string ())

On the other hand, maybe the use case for this is small enough we could just direct folks that need to manipulate the metadata to the third party editing tools that they'd be using anyway?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/109.