[pacman-dev] Adding an expiry time to repo databases
Hi all, I have made a start at adding an expiry time to repo databases. See the three patches here: https://patchwork.archlinux.org/bundle/Allan/repo_timestamp/ My question is, what should we do once a database is determined to be expired? Follow the example of a bad signature, and refuse to load it at all? Just refuse to install anything from it, but still enable searching etc? Just deciding "bad repo, don't use" will be much easier to implement... Comments? A
Em dezembro 13, 2019 8:39 Allan McRae escreveu:
Hi all,
I have made a start at adding an expiry time to repo databases. See the three patches here:
https://patchwork.archlinux.org/bundle/Allan/repo_timestamp/
My question is, what should we do once a database is determined to be expired? Follow the example of a bad signature, and refuse to load it at all? Just refuse to install anything from it, but still enable searching etc?
Just deciding "bad repo, don't use" will be much easier to implement...
Comments?
I'd go with, if expired, don't touch it *at all*. Even searching from then should not be allowed. Regards, Giancarlo Razzolini
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, 13 Dec 2019, Giancarlo Razzolini wrote:
Em dezembro 13, 2019 8:39 Allan McRae escreveu:
Hi all,
I have made a start at adding an expiry time to repo databases. See the three patches here:
https://patchwork.archlinux.org/bundle/Allan/repo_timestamp/
My question is, what should we do once a database is determined to be expired? Follow the example of a bad signature, and refuse to load it at all? Just refuse to install anything from it, but still enable searching etc?
Just deciding "bad repo, don't use" will be much easier to implement...
Comments?
I'd go with, if expired, don't touch it *at all*. Even searching from then should not be allowed.
I'm also in favour of this approach. We need some possibility to ignore the expiration anyways (e.g. change config option or more convenient: some command line flag to override the value from the config file), because otherwise it becomes impossible to install from an archived repository.
Regards, Giancarlo Razzolini
Regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl3zi2MACgkQCu7JB1Xa e1o4Dg//fQpcgXZlD5v3zSyEX3Nd6/CUQhpODypFK0F8Wzt/zi/LONoR9R/Z41Ww JZsrbDbkjux/8N1Ef2/rvR43TTVkNouiaEUQ5nPvTICdF/OT5ZD0Rsxxiv3ihAU/ csHB8ZPtzRbBIPDrtdvFD2O2sRzE7jQA8enm3tm74nI5XgWOgs0n36PAj23nA/Q8 H+OC2QHvhRPVL1KL4jJehBHA4c6sL21Kao8KWMbqiCloP5smTwtwQpwKgDZBPLu8 htFf2BLftJlqrI5TrbLbmrPsU+5sqqTxOvE6YP9fPfbFU4asnIZ5CrbJq7H9CvFI LuomryLYv9SS4xEHznCVOAU7WGajD6Squ2L7Naz+eWv5oBBeV7c1aibmb17CvFFd S3UYNli4S1X//L3FojTAnGoQHXQgBgCKWj3prowZjw9fHtTQyruwiMkdRs7KdyJG iwokGdYJg3xwK5Cz+HOY7vlfPQQ5fXX6U/r3FAKaEBx4SMSwPL5+JpD7HYA7BpFs L4vfbjKm+xijOwsQ5wzep7PbEBkHh63wWySPqNzcxHs5v2JY1/+HsvcXjnO7dHDe uYDofgslLOB8dvaAIEdhX/5NAwNXGmQwHZZs2vxcBahGV9a9m9oJ0cKu2TkI7TOE xLDFEjy/0Uwj/BtPKWw4UbO4ArPF/VB7cXTu9DNWCJ/AD3AyWA4= =S1BH -----END PGP SIGNATURE-----
On 13/12/19 11:00 pm, Erich Eckner wrote:
On Fri, 13 Dec 2019, Giancarlo Razzolini wrote:
Em dezembro 13, 2019 8:39 Allan McRae escreveu:
Hi all,
I have made a start at adding an expiry time to repo databases. See the three patches here:
https://patchwork.archlinux.org/bundle/Allan/repo_timestamp/
My question is, what should we do once a database is determined to be expired? Follow the example of a bad signature, and refuse to load it at all? Just refuse to install anything from it, but still enable searching etc?
Just deciding "bad repo, don't use" will be much easier to implement...
Comments?
I'd go with, if expired, don't touch it *at all*. Even searching from then should not be allowed.
I'm also in favour of this approach. We need some possibility to ignore the expiration anyways (e.g. change config option or more convenient: some command line flag to override the value from the config file), because otherwise it becomes impossible to install from an archived repository.
If you want to install from an archived repository, set the timeout to be super large, or just unset it... With my current patch, there is no way to unset a single repo with a global config value. I'll need to think about how to handle that. But you can have no global value and set all repos apart from the one you don't want to expire. Allan
On 12/13/19 6:39 AM, Allan McRae wrote:
Hi all,
I have made a start at adding an expiry time to repo databases. See the three patches here:
https://patchwork.archlinux.org/bundle/Allan/repo_timestamp/
My question is, what should we do once a database is determined to be expired? Follow the example of a bad signature, and refuse to load it at all? Just refuse to install anything from it, but still enable searching etc?
Just deciding "bad repo, don't use" will be much easier to implement...
Comments?
Offering to search a repo that you cannot then use, seems quite inconsistent. And people who configured a repo timestamp are implementing the same role as people configuring a gpg signature check -- they don't consider the repository to be valid or trusted without it, that repository is probably an MiTM if it cannot be refreshed. Let's mark it as so bad we don't even want to load it. -- Eli Schwartz Bug Wrangler and Trusted User
On 2019-12-13 12:39, Allan McRae wrote:
I have made a start at adding an expiry time to repo databases. See the three patches here:
https://patchwork.archlinux.org/bundle/Allan/repo_timestamp/
My question is, what should we do once a database is determined to be expired? Follow the example of a bad signature, and refuse to load it at all? Just refuse to install anything from it, but still enable searching etc?
In my opinion the timestamp only needs to be checked during a database refresh: in combination with signed database files, this provides security against a MITM serving an outdated database to withhold security updates, while leaving the timing of database updates under the user's control. As an example, air-gapped computers are expected to have an outdated database, while it would still be completely fine to install packages from the cache. In case the freshly downloaded database is expired, it shall not be copied and unpacked to /var/lib/pacman at all, instead the next available mirror should be tried to download a more recent copy. This also provides a bit of a usability improvement w.r.t. stale mirrors. Best, Jonas
On 12/13/19 8:39 AM, Jonas Witschel wrote:
As an example, air-gapped computers are expected to have an outdated database, while it would still be completely fine to install packages from the cache.
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.
In case the freshly downloaded database is expired, it shall not be copied and unpacked to /var/lib/pacman at all, instead the next available mirror should be tried to download a more recent copy. This also provides a bit of a usability improvement w.r.t. stale mirrors.
That sounds like an additional useful thing to do, but I'm not sure we do that currently if PGP signatures fail... -- Eli Schwartz Bug Wrangler and Trusted User
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
On 14/12/19 12:08 am, Eli Schwartz wrote:
In case the freshly downloaded database is expired, it shall not be copied and unpacked to /var/lib/pacman at all, instead the next available mirror should be tried to download a more recent copy. This also provides a bit of a usability improvement w.r.t. stale mirrors.
That sounds like an additional useful thing to do, but I'm not sure we do that currently if PGP signatures fail...
I have a WIP patch for that. Was just looking at it! A
participants (5)
-
Allan McRae
-
Eli Schwartz
-
Erich Eckner
-
Giancarlo Razzolini
-
Jonas Witschel