Let me (as someone not heavily involved into pkgsrc and binary pkg building)
try to unriddle a few bits that I think get easily confused in this context.
When it comes to 3rd party packages, you have to trust:
(1) the original source of the package ("upstream") and its release policies.
Assuming that the released source has no bad things hidden, you then have
to trust:
(2) pkgsrc (or the commiters of the pkg and all its dependencies and all
patches involved) to not do anything bad
>From that point on we can help with various checks. When building a pkg
(locally or in a bulk build environment) pkgsrc verifies the distribution
file it downloaded does match the hashes recorded at (2). The result of
that build is a binary pkg, and if you did build localy, you are done here.
If this is a bulk build environment and the binary pkgs will be uploaded
to some server, it is good to be able to verify the pkg has not been altered.
For this there are mechanisms ("signed pkgs"), but currently they are not
widely deployed (see below).
The next steps are (3) upload to the server, (4) trusting the server
and its admins, and (5) your download.
Whether that download happens via http or https and whether the https
certificate is validated does not really matter - as long as the binary
pkg you downloaded still is untampered (matches its signature).
IIUC the original question was about trust in step 5, and the responses
tried to hint at 1-4 being insecure anyway, so 5 would not really matter.
So far the theory.
Unfortunately, as of now, there is no signing happening for most (all?) pkgs
created under TNF controll. I personally had hoped this would change for the
pkgs created for NetBSD 9.0, but right now it does not look like it.
I'll take this as a reminder and will start a thread on tech-pkg to see how
we can solve this issue ASAP.
Martin
