On Sat, Jan 23, 2021 at 09:35:12AM +0200, Wouter Verhelst wrote: > Currently, there are two merge requests open[3] for repositories on > which my script fails while trying to verify the InRelease file. > > It turns out that these repositories return data for the InRelease file > -- i.e., a file that has checksums and is signed by some tool -- but the > signature is invalid. The repository also has a Release/Release.gpg > pair, where the signature *is* valid. Merge request 66 repository results in this 'apt update' output for me: | […] | Err:3 https://adoptopenjdk.jfrog.io/adoptopenjdk/deb buster InRelease | The following signatures were invalid: ERRSIG 8AC3B29174885C03 | Reading package lists... | W: GPG error: https://adoptopenjdk.jfrog.io/adoptopenjdk/deb buster InRelease: The following signatures were invalid: ERRSIG 8AC3B29174885C03 | E: The repository 'https://adoptopenjdk.jfrog.io/adoptopenjdk/deb buster InRelease' is not signed. | N: Updating from such a repository can't be done securely, and is therefore disabled by default. | N: See apt-secure(8) manpage for repository creation and user configuration details. So please give us the actual configuration and output apt produces for you if you suspect a bug (reportbug should help you with that). Merge request 65 repository is a fun one as apt actually accepts the InRelease as valid, even though throwing it directly at gpg does indeed indicate a bad signature – gpg is not telling what is bad about this signature through: The class of this signature. The signature is of the binary class, which clearsigned text is not by definition. apt doesn't feed the InRelease file to gpg directly though: It first splits the file in two – creating files akin to Release and Release.gpg – and passes those to gpg. A signature for a binary file is valid in that context – and successfully passes verification by gpg. We do this as we work with the Release internally and we want to be sure that the data we see is what was signed as we run the risk of either us or gpg being tricked into parsing the InRelease differently and hence seeing and acting on [unsigned] different data (it happened before). (apt isn't the only client which does that. I think e.g. debootstrap does the same, but I haven't checked any clients. It depends a bit on if you are able to use the rather recent gpgv --ouput or not I presume). Sidenote: I presume the repo maintainer is generating the Release + Release.gpg pair first and then constructs a InRelease file out of it. While that should be possible, its a bit harder still than the reverse. Both seem like unneeded pain through given you have the key to just sign them both and be done… > Apt should probably produce a warning (if not an error) on such > repositories; it currently does not seem to do that. We could implement a check for that I presume, but I am not particular keen on parsing the different signature packet formats out of the base64 encoding just so we can complain about something that is technically no problem for us even if that is of course not a supported interface but a reliance on an implementation detail which could change any minute (in theory at least) and is likely a problem for clients with a different implementation. That seems more like the job of a linter… There are btw reasons a seemingly invalid InRelease file is ignored and we continue on to use a Release + Release.gpg pair without producing an error or a warning (except an Ign line in update output): Some servers e.g. send file not found pages with "200 OK". Also, your indication that apt would drop support for the twin files is a bit aggressive. I guess I shouldn't say it too loud as one will appear then, but so far there exists no plan to do this. I kinda doubt all existing clients support it or that all repositories have one – after all, its a rather new addition in terms of Debian stable releases, too, as producing an InRelease file can be hard work if you e.g. want two independent signatures on the data and the benefits of InRelease only really appear if you have mirrors of some sort (and then there are those who want apt to deal with arbitrarily historic repos so I don't see such a plan appear without at least some opposition regardless of the timeline). Anyway, I don't think this bug is actionable in this state: Either add moreinfo for the 66 case or move it to your more linter-like tool in case of 65. Otherwise I might close it in the future. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature