On Wed, Jan 27, 2021 at 9:27 PM Noah Meyerhans <no...@debian.org> wrote:
> > The signed metadata includes cryptographic checksums of the package > contents. Thus, package contents can't be modified in storage on the > mirror or in transit to your system without invalidating the checksum, > and the checksums can't be updated in the repository metadata without > invalidating the signature. > This all sounds pretty promising! Thank you, Noah! Do you happen to know how to access this metadata? I'd love to be able to look at it and understand it better. > > > I do know that [I can tamper with .deb pkg on my computer prior to > installation without triggering warnings]. > > That's correct; the validation happens during retrieval. Once the > package is on your computer, you are free to tamper with it however you > want. > Thanks! It's a relief that the validation occurs elsewhere. > And finally, it seems that even wikipedia says that package signatures > > aren't being checked on most systems > > ([3] > https://en.wikipedia.org/wiki/Deb_%28file_format%29#Signed_packages). > > That's correct; package validation is done as described above. You left > out the part of the wikipedia article that states [...] > Here's the full text (minus footnote anchors): "Debian-based distributions support GPG signature verification of signed Debian packages, but most (if not all) have this feature disabled by default. Instead packages are verified by signing the repository metadata (i.e. Release files). The metadata files in turn include checksums for the repository files as a means to verify authenticity of the files. Currently there are two different implementations for signing individual packages. The first is done via the debsigs / debsig-verify toolset, which is supported by dpkg. The second is done through the dpkg-sig program which is not supported by dpkg, so the packages have to be manually checked with the dpkg-sig program. Both formats add new sections to the ar archive to store the signature information, but the formats are not compatible with one another. Neither of the modifications to the package format are listed in the official Debian handbook or man page about the binary package format." I'm still struggling with this paragraph. Let me see if I can break it down sensibly. "Debian-based distributions support GPG signature verification of signed Debian packages, but most (if not all) have this feature disabled by default." OK. That's straightforward enough. There's some infrastructure for GPG signature verification but it's disabled by default. That's not a problem in itself, if some other form of effective verification is happening. Just another sentence stating that in the wikipedia article would have made a world of difference to me. "Instead packages are verified by signing the repository metadata (i.e. Release files). The metadata files in turn include checksums for the repository files as a means to verify authenticity of the files." Again, I'd love to see one of these release files, so I could see: a) what data, exactly, is being checksummed b) what sort of hash algorithm is involved In my digging around so far, I found that the .deb file contains a control.tar.xz file, which has some md5 checksum information, but it has very patchy coverage of the files in the package. I hope that's just a holdover from a deprecated mechanism, and is not being used nowadays. "Currently there are two different implementations for signing individual packages..." I think this is referring to the GPG signature verification mechanisms that are disabled by default. I'm happy to not try to not go down the route of enabling GPG verification, since it seems to be poorly documented (I haven't found a single concrete example of how to do this), so long as I can feel that the metadata checksum method is sufficiently reliable. I think that looking at the Release files would go a long way to relieving my anxiety about this. Any help would be appreciated! I do wish there was an official document giving a high-level TLDR description of apt security, complete with caveats. As a bonus cherry-on-top wish, it would be awesome if it furthermore made clear what old mechanisms were deprecated and could be ignored!
