On Wed, Jan 27, 2021 at 9:27 PM Noah Meyerhans <
noahm@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!
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, Jan 27, 2021 at 9:27 PM Noah Meyerhans <<a href="mailto:
noahm@debian.org">
noahm@debian.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
The signed metadata includes cryptographic checksums of the package<br> contents. Thus, package contents can't be modified in storage on the<br> mirror or in transit to your system without invalidating the checksum,<br>
and the checksums can't be updated in the repository metadata without<br> invalidating the signature.<br></blockquote><div><br></div><div>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.</div><div>Â <br></div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
>Â Â I do know that [I can tamper with .deb pkg on my computer prior to installation without triggering warnings].<br>
That's correct; the validation happens during retrieval. Once the<br> package is on your computer, you are free to tamper with it however you<br> want.<br></blockquote><div><br></div><div>Thanks! It's a relief that the validation occurs elsewhere.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:
rgb(204,204,204);padding-left:1ex">>Â Â And finally, it seems that even wikipedia says that package signatures<br>
>Â Â aren't being checked on most systems<br>
>Â Â ([3]<a href="
https://en.wikipedia.org/wiki/Deb_%28file_format%29#Signed_packages" rel="noreferrer" target="_blank">
https://en.wikipedia.org/wiki/Deb_%28file_format%29#Signed_packages</a>).<br>
That's correct; package validation is done as described above. You left<br>
out the part of the wikipedia article that states [...]<br></blockquote><div><br></div><div>Here's the full text (minus footnote anchors):</div><div><br></div><div>"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."</div><div><br></div><div>I'm still struggling with this paragraph. Let me see if I can break it down sensibly. </div><
<br></div><div>"Debian-based distributions support GPG signature verification of signed Debian packages, but most (if not all) have this feature disabled by default."</div><div><br></div><div>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.</div><div><br></div><div>"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."</div><div><br></div><div>Again, I'd love to see one of these release files, so I could see:</div><div>a) what data, exactly, is being checksummed</div><div>b) what sort of hash algorithm is involved</div><div><br></
<div>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.</div><div><br></div><div>"Currently there are two different implementations for signing individual packages..."</div><div>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!</div><div><br></div><div>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!</div><div><br></div></div></div></div></div></div></
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)