After signing, a .pdf.p7s file appears instead of .signed.pdf file

[DazeEnd]

Describe the bug
When signing a document using "click to sign", sometimes a filename.pdf.p7s file can be left behind. When this happens, the expected filename.signed.pdf file is never created. As a result, the signed version of the document cannot be opened or viewed (because it doesn't exist). When downloaded, the filename.pdf.p7s file is zero bytes (0 B).

To Reproduce
I cannot reproduce the issue, however my customer has encountered it twice. These are the steps he is following, as best as I can tell:

1. Log into Nextcloud as a user (which we will call "REQUESTING-USER").
2. Upload a document (which we will call "filename.pdf"), and request a signature from another user (which we will call "SIGNING-USER"). My customer was sending the signature request to a guest account created with the Guests app (https://apps.nextcloud.com/apps/guests), but I'm not sure if that is required to reproduce the issue.
3. Log out of Nextcloud.
4. Log into Nextcloud into any Nextcloud account that is not REQUESTING-USER or SIGNING-USER. We will call this account "THIRD-USER".
5. As THIRD-USER, open the signing link that was emailed to the signer. This will display a 404 error ("Invalid user"). (See screenshot 1, below.)
6. Log out of Nextcloud.
7. Open the signing link that was emailed to the signer. This should take you to a Nextcloud login screen.
8. Log into Nextcloud as SIGNING-USER.
9. Create a signature, if necessary, and sign the document.

Expected behavior

1. After signing the document, the confetti screen should be displayed.
2. When viewing the list of files in LibreSign, the signed file should appear in the "signed" state, and the icon used should be a PDF icon.
3. When validating the signature in LibreSign, clicking the "View" button should display the signed version of the file, with the signature displayed.
4. In the Files app, when viewing the directory that contained the original file, there should be both the original filename.pdf file, and a new filename.signed.pdf file that contains the signed document.

Actual behavior

1. After signing the document, the confetti screen is properly displayed.
2. When viewing the list of files in LibreSign, the signed file properly appears in the "signed" state, but the icon is just a plain gray icon. (See Screenshot 2, below.)
3. When validating the signature in LibreSign, clicking the "View" button downloads a file called filename.p7s instead of displaying the signed document. The filename.p7s file is zero bytes (0 B), and completely empty.
4. In the Files app, when viewing the directory that contained the original file, the original filename.pdf file is still present, but there is no file.signed.pdf file. Instead, filename.pdf.p7s file is present. The filename.pdf.p7s file is completely empty (zero bytes). (See Screenshot 3, below.)

Screenshots

1. 404 Error screen displayed after step 5.
   

2. Corrupted (?) signed files displayed with a gray icon:
   

3. The adam.PDF.p7s file was created as a result of signing adam.PDF. The adam.PDF.p7s file is completely empty.
   

4. Screen 1 of LibreSign settings.
   

5. Screen 2 of LibreSign settings.
   

6. Screen 3 of LibreSign settings.
   

Environment information (please complete the following information):

• Server OS: AlmaLinux 8.4
• Browser: Chrome (unknown version)
• LibreSign Version: v8.2.4
• Nextcloud Server Version: 28.0.8
• Logs (generated with cat nextcloud.log | grep -i libresign | grep "2024-10-10"): nextcloud.log

Additional context
My customer is experiencing this as he is testing out LibreSign, and trying to learn how it works. Essentially, he is sending signature requests to himself or a co-worker as a test. The problem seems to be appearing, because the recipient is already logged into another account when they click on the link in the email they receive. From my customer's experience, LibreSign is repeatedly failing during his tests, and this is causing the customer to mistrust the tool and become reluctant to rely on it for production use (even though this combination of events is unlikely to happen in a real-life scenario).

[vitormattos]

Follow some comments:

When signing a document using "click to sign," sometimes a file filename.pdf.p7s may be left behind.

LibreSign does not have official frontend support to handle p7s files. I have already implemented part of the code to handle p7s on the API side to enable signing files that are not pdf, but it is not complete and the code at API side can't be trigged.

My customer was sending the signature request to a guest account created with the Guests app (https://apps.nextcloud.com/apps/guests), but I'm not sure if that is required to reproduce the issue.

I have never tested this app in conjunction with LibreSign. Maybe this could generate some issues but I don't know wich ones.

As THIRD-USER, open the signing link that was emailed to the signer. This will display a 404 error ("Invalid user").

The link to sign the document should only be accessed by SIGNING-USER; if you try to access the link received from SIGNING-USER using a browser with THIRD-USER or the account of THIRD-USER, the expected behavior "Invalid user" is correct.

When viewing the list of files in LibreSign, the signed file properly appears in the "signed" state, but the icon is just a plain gray icon. (See Screenshot 2, below.)

There is an event in LibreSign that watch the deletion of pdf files; when it is a file from LibreSign, all data of this file is deleted from LibreSign as well to prevent an icon-less file from appearing removing the file fom list of files at LibreSign app. Files without an icon (with a gray icon) are those that, for some reason, LibreSign could not found on disk and a strange behaviour didn't trigged the event to delete all data from LibreSign tables at database.

When validating the signature in LibreSign, clicking the "View" button downloads a file called filename.p7s instead of displaying the signed document. The filename.p7s file is zero bytes (0 B), and completely empty.

This is a somewhat strange behavior since LibreSign does not handle p7s files. It appears that this file was manually uploaded by the Files app to this folder.

The described scenarios are a bit confusing. I think that don't will be possible reproduce. Can you provide a reproducible scenario?

[DazeEnd]

Just to be clear, I agree that what the user doing is extremely unusual. Especially the part where a third user is accessing the signing link. I also agree that this scenario is very unlikely to come up in actual use.

I don't know where the p7s file is coming from either. The customer says he is not uploading the p7s file, and that it is appearing after he signs the original PDF.

I cannot reproduce the issue. The customer cannot reliably reproduce the issue, but it happened to him three times yesterday. I am going to try to schedule a video call with him today so that I can watch what exactly he is doing. If I am able to collect more information, I will share it.

So I guess my main question right now is where is this p7s file coming from? Are you saying that LibreSign isn't creating it?

[vitormattos]

I am going to try to schedule a video call with him today so that I can watch what exactly he is doing. If I am able to collect more information, I will share it.

See if you can record the call; it would be good because if you can see the problem, we have a video that can give some light.

So I guess my main question right now is where is this p7s file coming from? Are you saying that LibreSign isn't creating it?

Is this, the only point at the code that could generate a p7s is this:

libresign/lib/Service/SignFileService.php

Lines 265 to 283 in 3863a4f

	public function sign(): File {
	$fileToSign = $this->getFileToSing($this->libreSignFile);
	$pfxFileContent = $this->getPfxFile();
	switch ($fileToSign->getExtension()) {
	case 'pdf':
	$signedFile = $this->pkcs12Handler
	->setInputFile($fileToSign)
	->setCertificate($pfxFileContent)
	->setVisibleElements($this->elements)
	->setPassword($this->password)
	->sign();
	break;
	default:
	$signedFile = $this->pkcs7Handler
	->setInputFile($fileToSign)
	->setCertificate($pfxFileContent)
	->setPassword($this->password)
	->sign();
	}

There is no way today in the frontend to request that a file that is not a PDF be signed, so I don't see how a p7s could have been created. Is it possible that this client of yours is using the Nexcloud Desktop Client and is signing the document with some other software and generating the p7s file?

[DazeEnd]

Is it possible that this client of yours is using the Nexcloud Desktop Client and is signing the document with some other software and generating the p7s file?

No, I am certain that he is not using the desktop client. I have blocked the desktop client for this Nextcloud installation by blocking its user agent.

[DazeEnd]

@vitormattos I had a Zoom call with my customer, and he was able to reproduce the problem during our call, so I now have a video showing the steps to reproduce. However, the document he signed has some personal information visible on the screen, so I don't want to post it on GitHub where it will be public.

I have emailed you at your librecode.coop email address. The email contains a link that you can use to download the video. Please download the video and let me know if you have any questions or need additional information.