You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 15, 2022. It is now read-only.
Assume an adversary has the capacity to MitM HTTPS. Then they can add a line in the format of a linux kernel checksum before the signature block within the clearsigned sha256sums.asc file and the signature will still verify as good. They could also serve us their position as a MitM to serve a backdoored kernel. Then, when we grep for the linux kernel checksum line, we use this unsigned, maliciously-inserted signature, which matches the backdoor kernel's checksum (an actual attack would have to be a little more nuanced, taking into account how we pipe to cut the options we use, but certainly seems possible). Bad news.
So, after reading through the GPG man page for the bajillionth time and searching the web extensively, I've found no way to resolve this problem with GPG parameters alone. I propose that we make some assertions about the file before verifying:
The 1st line of the file is:
-----BEGIN PGP SIGNED MESSAGE-----
The last line of the file is:
-----END PGP SIGNATURE-----
Somewhere between the 2nd and last line of the file is the line:
-----BEGIN PGP SIGNATURE-----
No lines other than the three lines above start with:
-----
The text was updated successfully, but these errors were encountered:
Relevant to
fetch_linux_kernel_source.yml
:Assume an adversary has the capacity to MitM HTTPS. Then they can add a line in the format of a linux kernel checksum before the signature block within the clearsigned sha256sums.asc file and the signature will still verify as good. They could also serve us their position as a MitM to serve a backdoored kernel. Then, when we grep for the linux kernel checksum line, we use this unsigned, maliciously-inserted signature, which matches the backdoor kernel's checksum (an actual attack would have to be a little more nuanced, taking into account how we pipe to cut the options we use, but certainly seems possible). Bad news.
So, after reading through the GPG man page for the bajillionth time and searching the web extensively, I've found no way to resolve this problem with GPG parameters alone. I propose that we make some assertions about the file before verifying:
-----BEGIN PGP SIGNED MESSAGE-----
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
-----
The text was updated successfully, but these errors were encountered: