Added the info that the service only works with pdfs when a specific parameter is passed with the request. This gives some protection that it's not directly exposed when we want to test it in production.

Please see update in the ticket explaining our deployment plan. Thanks!

Given PDFs are arbitrary binary input, we have application and infrastructure level security and reliability concerns that require consideration.
Application-side, we need a security review of the pdf-parse and backing pdfjs-dist libraries. This would also help determine the level of sandboxing necessary to consider a production deployment.
Infrastructure-side, we would want to isolate the PDF handling as much as possible. Ideally this would happen in a separate microservice that only does PDF handling, or at least in a separate citoid deployment, to mitigate potential vulnerabilities and resource exhaustion. Both solutions would also require a stronger sandbox than a standard container.

In T430305#12085268, @Clement_Goubert wrote:

Given PDFs are arbitrary binary input, we have application and infrastructure level security and reliability concerns that require consideration.
Application-side, we need a security review of the pdf-parse and backing pdfjs-dist libraries. This would also help determine the level of sandboxing necessary to consider a production deployment.
Infrastructure-side, we would want to isolate the PDF handling as much as possible. Ideally this would happen in a separate microservice that only does PDF handling, or at least in a separate citoid deployment, to mitigate potential vulnerabilities and resource exhaustion. Both solutions would also require a stronger sandbox than a standard container.

Thank you very much for that assessment. I just filed a request for a security review of the two dependencies. See T431716: Application Security Review Request : Citoid-Service adding pdf-parse and backing pdfjs-dist NodeJS dependencies. Furthermore we're evaluating an alternative approach T431688: Look into alternatives to parse PDF metadata not using NodeJS, but since that one also is not fully clear we would like to continue with both options.

Blocked by security review for now

Thank you for the update @MLechvien-WMF. I've updated the timelines as requested. The deployment plan itself is the same just, just the dates have been adjusted. We're now aiming to finalis the work and deploy in Q2 (WMF FY). As I understand things, this depends on two pieces of work:

1. The security review as you mentioned T431716: Application Security Review Request : Citoid-Service adding pdf-parse and backing pdfjs-dist NodeJS dependencies --> Security team
2. Buildign and deploying the service that processes the PDFs in a secure sandbox environment --> SRE.

For the second item, we're working on defining a secure concept and will create a phabricator task for it soon. What I am unclear about is how we will collaborate on this item with SRE? Any information or guidance would be highly appreciated.

I will also sync with @ppelberg on prioritization and we'll get back to you as soon as possible.

Thanks a bunch!

For the second item, we're working on defining a secure concept and will create a phabricator task for it soon. What I am unclear about is how we will collaborate on this item with SRE? Any information or guidance would be highly appreciated.

There are ongoing works to provide a standard secure sandboxing solution which I'd advise to follow: T435044

Besides that, we can continue discussing the design on this task post security review, but you can read the production expectations in SCROLL process.

perfect! Thank you very much!