[pacman-dev] Adding an expiry time to repo databases

Jonas Witschel diabonas at archlinux.org
Fri Dec 13 14:40:08 UTC 2019


On 2019-12-13 15:08, Eli Schwartz wrote:
> Wouldn't an airgapped computer also be updating (if it does update) from
> a known trusted database communicated via e.g. USB? So there is no need
> to specify an expiry time on the airgapped computer. The computer which
> generates updates will specify an expiry time, and if its database
> passes validity checks including the expiry timestamp, it rsyncs the
> *.db and pacman cache to some trusted external storage media, and then
> the airgapped system assumes that it was valid at the time it was created.

I agree, for complete system updates you ought to have access to a
recent database. My use case was more directed to something like
reinstalling a previously removed package that is still in the cache.
Certainly not a very important case, and it could be worked around by
specifying a very long expiry time, but I don't know why that should be
necessary:

I fail to see the point in checking the timestamp of the local database
every time it is used. It is not necessary for the "MITM serving
outdated databases to withhold critical updates" scenario, but it forces
users to refresh their databases from time to time.
While it can be argued that this is actually a good thing when combined
with a system upgrade, my worry is that people will start using "-Sy"
even more if they only want to install a new package, potentially
leading to partial upgrades. In contrast, you currently at least have a
chance to install packages without a system upgrade using "-S
packagename" if they are still available on the mirrors.

It is certainly possible that I am missing some attack scenario that
makes it necessary to check the local database every time. If so, that
should be brought up here and documented in the threat model. Otherwise
I don't really see the point in an additional check and at least a
slight decrease in usability.

Cheers,
Jonas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20191213/9940975a/attachment.sig>


More information about the pacman-dev mailing list