Bug#1003032: debootstrap: harden signature checking
Package: debootstrap Version: 1.0.126+nmu1 Severity: normal Tags: security Hey there. As far as I understood it, debootstrap defaults neither to --no-check-gpg nor to --force-check-gpg, but instead, if a keyring is speicified for some distribution and if that file is available, it uses (and verifies) these (and hopefully fails if anything fails later on). However, it also: - falls back to https (?) - correct me if I'm wrong, falls back to no verification if no key file was specified for the distribution or the file wasn't found That seems to make to too easy to accidentally install untrusted code. https is generally questionable, given the broken CA-model. There are some 150 CAs in the Mozilla CA bundle, and on top of these thousands of intermediate CAs. It seems far too easy for an attacker to fake a certificate if that's really desired. So my suggestion would be: - defaut to --force-check-gpg - add some --check-gpg-but-fallback-to-https option that is the current behaviour - if either the /usr/share/debootstrap/scripts/ for some distro doesn't name a keyring file or that file isn't readable, fail unless --no-check-gpg is given. Yes, that also includes failure if --check-gpg-but-fallback-to-https was given because likely the keyring file should be just there. Cheers, Philippe
Going ahead with non-free-firmware
Ansgar Burchardt wrote: > I think there was consensus to introduce the non-free-firmware > section > and move the non-free firmware blobs there. I'm wondering what we > need > to do next? While it's good that at least something happens it's really sad and kinda disturbing to see that a more narrow-minded solution is taken, while a better proposal lies on the table. Especially since the non-free-firmware seems to make it less likely, that a non-open could ever happen. When Debian is anyway about to add new suites and people will have to adapt to that, why not implementing a more powerful schema that not only allows to opt-in to closed-source firmware, but also allows to, at the same time, opt-out of other closed-source software, while allowing at the same time to opt-IN to non-free, but open software? It'll be just one further suite that needs to be added, gaining far more possibilities. - non-free (as the current non-free, excluding anything that would need to go to non-open) - non-open (everything from non-free for which there are no sources available) - non-open/firmware (firmware that would be in non-open) perhaps arguably a 4th one: - non-free/firmware (i.e.that would be firmware that is open but not e.g. freely distributable, but does that even exist?) Alternatively one could just have: - non-free (as the current non-free, excluding anything that would need to go to non-open) - non-open (everything from non-free for which there are no sources available) - firmware (any non-free or non-open firmware) So again, what's wrong with the proposal I've made few days ago in #809705? It doesn't seem to require much more technical work, just moving packages and it's a far more powerful solution. Sincerely, Philippe.
Re: Going ahead with non-free-firmware
And btw: Even if Debian doesn't want to do the non-open thing now or perhaps generally doesn't want to allow people to opt-out of closed source software while keeping other non-free software, then the name non-free-firmware seems to break the current naming, doesn't it? main contrib non-free These all give the "license status" of their packages. But non-free-firmware, would give license status and package type. Oh and since this has been brought up by someone. It seems better if packages wouldn't be in multiple suites. That's also what I'd have intended with non-open, in other words, a package that is in non-open is only there and not also in e.g. non-open/firmware (and vice versa). Thanks and regards, Philippe
