On Sat, Oct 19, 2019 at 2:18 PM Wiktor Kwapisiewicz <wiktor@xxxxxxxxxxxx>
On 19.10.2019 08:42, Michael Stapelberg wrote:
There’s an exception to every rule :). I also run a few pieces ofcontainer.
vendor-supplied software directly, such as nginx via their docker
I guess this is a question on where to draw the line. Personally I like
packages that are as close to upstream as possible (my quick skim over
distri's packages seems to indicate this model) over excessive package
maintainer customization of upstream software in some other distros...
Currently, we just rely on a trusted link to the repository: the
repository is only ever accessed via TLS, so as long as you trust that,
you should be good.
Yes. Although currently http (without TLS) can also be used . This is
useful during testing though :)
I’m willing to accept contributions which add certificate pinning for
people who don’t trust the CA ecosystem, but that’s probably pretty
tedious with today’s fast-rotating certificates.
A middle ground is pinning public keys instead of certificates (like
HPKP ). This way even if the cert changes one can reuse public key
and the pin still works.
Additional code signing certificates (OpenPGP or X.509) allow signing
packages when the private key is stored on secure hardware (e.g.
Yubikeys). TLS requires private keys to be always available so the
attack vector is bigger.
I'm not proposing adding it right now, it's probably a low-prio item now.
I don’t have any big plans for signatures or other mechanisms. For what
I wanted to demonstrate, the current model suffices.