Am Wed, Dec 18, 2024 at 07:30:02PM +0100, schrieb yogg:
> I tried to setup a local file repository.
> After this worked I tried to bypass some of the security measures and realized that I can modify the "Packages" file without an error.
Yes, it is as you say, but this is intended. file:/ uses the files as
present in the (remote) directory – if you look into /var/lib/apt/lists
you will see a symlink pointing to the Packages (and most other) files
(The notable exception here being the Release file for reasons I am not
quiet sure, but oversight might very well be the main one as those repos
tend to not be signed or have a Release file at all)
The files did validate at the point they were read by 'apt update', but
everything symlinked can be modified at the remote side and is hence also
directly picked up by later apt calls without another update call
(except Release info which directly affects pinning, so that might be
one relatively good reason to copy that file)
The intend is here to be extremely light on disk usage: A single
uncompressed Packages file from Debian main sid clocks in at roughly
56 MB per architecture alone for example.
This is clearly at the expense of security: If you don't trust your
remote side to be friendly, you can't be using it as storage and so you
would need to use copy:/.
There is a potential middle-ground, a method that would copy the index
files, but not the individual deb packages, which is what I suppose is
what you thought would happen – it would at least solve your security
concern. While we have no direct support for it, you can implement such
a method yourself with the mirror transport. The second example in the
man page actually hints at it: Your mirror file would contain something
like this:
| copy:/srv/local/mirror/ type:index
| file:/srv/local/mirror/ type:deb
and as an URI in the sources entry you would be using something like:
| mirror+file:/etc/apt/local-mirror.lst
(untested, but should™ work)
d-i is unconcerned in any case as a) the way cdrom:/ works is actually
the middle-ground (so you can browse packages on all CDs/DVDs/… and
shuffle into the drive the correct one(s) at install time only) and
b) CDs & co are usually (if not to say always) *NOT* signed.
(The CDs themselves are, but the repository they contain is not. That
might even have a practical reason as the repository is not created by
the ftpmasters, so the archive keyring can't be used, nor the release
key as the repository isn't produced by the Release team, but by the CD
team and "only" signed off by the former, but I am not involved in the
creation at all, so that are just very wild guesses from my PoV)
If you want to create testcases for apt, have a look at test/integration/
in apt sources, just saying. The reason your second "apt update" call
isn't failing is that it sees an unmodified InRelease file and hence
assumes that everything is current ("Hit"). It just does an existence
check for the Packages file here (in case your config changed). For
other reasons it might be a good idea to slightly extend this check to
also check e.g. the mod time and/or filesize to detect anomalies, but
that doesn't really change much for your case (and it isn't always
possible without additional work, e.g. if we store indexes compressed).
So, closing as not a bug but working as intended.
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature