Hi David, On Sun, Jan 24, 2021 at 05:17:14PM +0100, David Kalnischkies wrote: > 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).
Since I didn't actually enable that repository on my laptop, that wouldn't work :) But yeah, I suppose I should indeed have tried things out first. Sorry about that. Also, it looks like the repository has changed since; when I tried it before filing this bug, it would validate correctly if I skipped the InRelease file and only checked the Release/Release.gpg files. Can't help it if people break their stuff, of course ;-) (but then perhaps that might have been another case of the same issue as MR 66) > 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. Oh, I wasn't aware of that. Thanks for informing me. I guess that means I need to update my validation tool then :) > 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). Makes sense. [...] > > 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". In that case, gpgv will report gpgv: no valid OpenPGP data found gpgv: the signature could not be verified which is different from [GNUPG:] NEWSIG [GNUPG:] KEY_CONSIDERED ... [GNUPG:] BADSIG ... For clarity, what I mean to say is that if the signature exists but is invalid on the InRelease file (while the Release.gpg file contains a valid signature) then you have a repository that is signed both correctly and incorrectly. This is not the same thing as a repository that is signed correctly and that returns junk instead of some other possible signature. If the repository is signed both correctly and incorrectly, then which of the two is correct? You may have had an attacker who replaced software in your repository with an older, vulnerable, version of the same software, but was thrown out before they could complete their attack (or they messed up). I'm not saying that apt should always check that both versions of the Release data exist, but if it downloads something and fails to verify the signature, it should then not discard that information just because it so happens that there is also a valid signature on some other form of the data available. However, your explanation above as to why the validation fails in my tool while it works with apt makes sense, and if that is the reason (rather than apt falling back on Release/Release.gpg after seeing that the InRelease signature is invalid, which is what I thought was the case) then there isn't a problem. > 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. Oh? I vaguely remember some form of announcement from jak@ who mentioned that you guys were planning this. I guess that means I either misunderstood or dreamed it ;-) > 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. If the behavior that I thought was happening (i.e., apt falls back on Release.gpg if InRelease has a signature but it doesn't validate) is indeed not happening, then I agree that this bug should be closed. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard