Hey.

It would be nice if the sources.list(5) manpage could clarify whether
file URI schema is secure (or not) when the archive is not under local
control by a trusted user.

From the manpage:
- at some point the file is verified (apt-secure)
- then read from the specified location directly (not from a cached copy)
  ... and installed

But wouldn't that also mean, that if the (local) user controlling that
location ... or e.g. the NFS owner, could replace the valid file with a
rogue version, right after it has been read the first time (for validation)?


Or is there another validation of the hashes, right when it's read in for
the actual installation?

Cheers,
Chris.

Few more further minor things in sources.list(5):

1) Check-Date, unlike all the other options, doesn't mention it's
default.



2) For:
       •   Valid-Until-Min (valid-until-min) and Valid-Until-Max
           (valid-until-max) can be used to raise or lower the time period in
           seconds in which the data from this repository is considered valid.

my understanding was the following:

The Release file has Date: and (possibly) Valid-Until: .
If I set Valid-Until-Max = 1 day, the regardless if what Valid-Until:
says in the release file, it would be valid at from the Release’s Date:
+ 1 day.

However, the description using the the terms raise/lower rather implies
that an existing value is raised/lowered, ... e.g. for the example
above, as if the Release file had a validity period of 1 week... it
would be 1 week + 1 day.

Similarly, the following is not clear, I guess:

If the Release file would say the validity period is effectively 1 day,
but Valid-Until-Max = 1 week,... which one wins? "-Max" kinda implies
it would be the maximum value, but a smaller Valid-Until would still be
enforced?


3) The EXAMPLES section seems to imply one can set multiple values in
Suites: (last example), but the "THE DEB AND DEB-SRC TYPES: GENERAL
FORMAT" seems to imply only one suite is possible:




Thanks,
Chris.

One more (yes I know, it's not really belonging to the original bug
report, but it seems stupid to open another one just for this):


apt.conf(5) references:
/usr/share/doc/apt/examples/configure-index.gz

but this is apparently no longer a .gz


Cheers,
Chris.

metadata like Packages files nor debs are copied anywhere; so they can
be replaced at any time and are not revalidated.

This has been the subject of much discussion the past weeks and I'm
leaning towards renaming it to `insecure-file` to make users explictly
(aware of, and) acknowledge the risks.

This means that file:/ URLs will create a warning saying that file
is insecure and to read a manual page and switch to copy or
insecure-file.

file is allowed, and which eventually defaults to disallow?


Or alternatively and perhaps even better:

An option that controls how file: works, default would be like copy:
... and an alternative mode would be like the current file: (i.e. no
copy), but that being documented as insecure on untrusted sources?

Probably that would then again need to be a per repo option, too.


The advantage with both would be not to encode a usage warning in the
schema name (like we don't use insecure-http://).

Th advantage of the 2nd would be that we could use the well recognised
file: schema.


Cheers,
Chris