Bug#203741: apt sigcheck patches
On Thu, Aug 21, 2003 at 01:51:32PM -0400, Colin Walters wrote:
> On Thu, 2003-08-21 at 12:13, Matt Zimmerman wrote:
>
> > It seems OK not to specify whether the source is secured, as long as
> > you're not rejecting insecure sources (maybe issuing a warning?).
>
> I'd get pretty annoyed at being prompted every time to ignore unsecured
> sources. And if we add an option to ignore unsecured sources, then people
> will just use that, and that kind of makes the whole thing pointless.
I would say that by default, it should go ahead and use the unsecured
sources, but display a warning to the user. This is a change from "expect
security only when explicitly requested" and "expect security by default".
Because most software does (and will continue to) come from Debian proper,
and thus will be signed, unofficial repositories will become the exceptional
case, and I think this strategy can work.
Currently, any one of these unofficial repositories could simply swap in a
trojan for a new <random essential package>; all they need to do is to
specify a higher version number. Since their source is listed as insecure
in sources.list, no verification is done and no warning is displayed.
If a user asks to install (or upgrade!) a package, and the selected version
is coming from an insecure source, I think apt should warn loudly about
this, and ask for confirmation. Because this will only happen when fetching
new packages from unofficial sources (which should be, by far, the less
common case), I don't think there is too much danger in users pressing the
"ignore" button.
If we don't expect security by default, mixing secure and insecure sources
doesn't provide much security, and the download indicator is the only way to
indication of whether a package comes from a trusted source.
> Say company has a setup with a bunch of Debian stable machines, using
> apt-secure. They of course use security.debian.org. However they also
> have a trusted server on their intranet that provides some packages, and
> all the other machines use it as an apt source. Because Debian doesn't
> have any standard scripts for generating a secured apt source, and since
> it's on their secure intranet, they don't bother checking the sigs on the
> Release file.
We should certainly provide tools for this; I expect that apt-ftparchive
could be extended to generate release files and sign them without too much
trouble.
> This company also has scripts to automatically upgrade all the machines on
> their intranet. They don't want to have any user interaction, so
> prompting is out.
A force option could be provided, but I think it would be better to make it
a no-brainer for a source to be secured.
> > Presumably, if you don't trust Debian unstable, you wouldn't have the
> > key for unstable in your list. Though, I guess if we use one key per
> > year rather than a key per release, this won't work (unfortunately).
>
> Right.
I think that per-release keys make more sense than per-year keys for this
reason.
--
- mdz
Reply to: