CRUX

Welcome to CRUX bug tracking.
Tasklist

FS#1763 - pkgmk -cs doesn't report error for missing files in .signature

Attached to Project: CRUX
Opened by li (phi) - Tuesday, 27 August 2019, 13:03 GMT
Last edited by Tim Biermann (tb) - Sunday, 08 May 2022, 21:27 GMT
Task Type Bug Report
Category tools → pkgutils
Status Closed
Assigned To CRUX Developers (crux)
Operating System CRUX
Severity Low
Priority Normal
Reported Version 3.5
Due in Version 3.7
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Some ports have incomplete file list in .signature. This is the case for opt/mplayer that its main source signature is missing, what makes it bad is that it's also using the insecure http protocol (http://distfiles.serverop.de/mplayer-$version.tar.xz).

cd to /usr/pors/opt/mplayer, pkgmk -cs shows that the signature is ok.

I suggest patch pkgmk to print out errors in such case and re-check all ports, I believe there're more ports affected by this issue.
This task depends upon

Closed by  Tim Biermann (tb)
Sunday, 08 May 2022, 21:27 GMT
Reason for closing:  Won't fix
Additional comments about closing:  closed due to inactivity
Comment by Tim Biermann (tb) - Tuesday, 21 September 2021, 21:51 GMT
As of today, the only possibility where this could happen (correct me please) is with the likes of patches, that were used in the past, then weren't anymore, deleted from the source array but weren't actually deleted before pushing an update.

The mplayer port doesn't exist anymore, distfiles.serverop.de however was at least a trusted source as it has been teks space.

I understand the concern, but I also doubt that (using official or trusted repos) the problem is rather small. I am interested in other opinions about it please.

@li: if you are still around, you could help by actually naming other ports (within official repos) that show the same issue to get them cleaned up ;)
Comment by John McQuah (farkuhar) - Saturday, 12 February 2022, 15:51 GMT
I agree with Tim that this phenomenon is probably not very widespread in the ports tree. If you manually try to tamper with a signature file (by deleting the line with the SHA256sum for the main source tarball), then cryptographic verification will fail right away. If you try to create an incomplete signature file (by running `pkgmk -us` after deleting from the port directory or $PKGMK_SOURCE_DIR one of the files in the source array), then pkgmk will abort with an error.

Note that the absence of a footprint file is not enough to cause `pkgmk -us` to abort. In addition to Tim's possibility of an obselete patch still remaining in the ports tree after it has been taken out of the source array, you might have a signature file that omits the SHA256sum of the mandatory footprint. But that latter scenario is already detected by prtverify.

In short, I don't believe very many ports are affected by this issue. The existing tests are enough to detect the only type of incomplete port for which `pkgmk -us` proceeds with zero exit status. (I can't imagine how mplayer got to the state described in the original bug report, though.) Failure of `pkgmk -us` when a needed source file is not on disk, or `pkgmk -cs` when the signature file is tampered with, is enough to prevent the astute CRUX user from going ahead with the build.

In an attempt to find more examples of incomplete signatures, I ran `find /usr/ports/opt -name .signature -exec cat '{}' + > opt.sigs` and paged through the resulting output. I couldn't find any obvious instances of an omitted SHA256sum for the main source tarball. I agree with Tim that the burden of proof is on @li to provide names of the ports where this issue still persists.

Loading...