Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.

FS#61497 - Add a timestamp file to repos

Attached to Project: Pacman
Opened by Allan McRae (Allan) - Tuesday, 22 January 2019, 02:19 GMT
Last edited by Allan McRae (Allan) - Friday, 13 December 2019, 13:18 GMT
Task Type Feature Request
Category General
Status Assigned
Assigned To Allan McRae (Allan)
Architecture All
Severity High
Priority Normal
Reported Version 5.1.2
Due in Version 6.0.0
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


Even with signed repos (come on Arch!), people could delay updates to keep vulnerabilities from being fixed.

Our repos should contain a .TIMESTAMP file, that pacman reads. Then a config option that gives the maximum amount of time a repo is considered valid for.
This task depends upon

Comment by Andrew Gregory (andrewgregory) - Tuesday, 22 January 2019, 02:35 GMT
What happens when the time has elapsed?
Comment by Allan McRae (Allan) - Tuesday, 22 January 2019, 02:44 GMT
Pacman no longer can use the repo. It is equivalent to a bad signature.
Comment by Andrew Gregory (andrewgregory) - Tuesday, 22 January 2019, 02:57 GMT
Are you expecting it to try other servers first, so the user can get the updated database? Just refusing to use the db still leaves them with outdated software.
Comment by Allan McRae (Allan) - Tuesday, 22 January 2019, 03:24 GMT
I'm assuming Arch would set the default timeout value at something like 10 days. A mirror that old can be dropped.

I have not considered whether pacman should automatically go to the next mirror, or whether the user should manually handle the removal of that mirror from the mirrorlist. Also up for question is whether an -Ss or -Si operation should succeed on an old database, with only installation or upgrades restricted.
Comment by Allan McRae (Allan) - Tuesday, 22 January 2019, 03:27 GMT Comment by Andrew Gregory (andrewgregory) - Tuesday, 22 January 2019, 03:44 GMT
Hmmm, they don't specify the behavior when the time is expired.

My initial thought was that this should really only affect -Sy because until the user has actually tried to update the db there's no reason to suspect foul play. But, the config option would essentially mean that the user has requested pacman not use a database older than X, so it should probably apply to all operations. Applying that same logic to -F operations would probably also prevent confusion from people using old .files databases and not realizing that they're outdated.
Comment by Luca Bertozzi (ekardnam) - Thursday, 04 April 2019, 08:42 GMT
This requires both a modification on repo-add and on pacman (or libalpm maybe not sure i still don't know much about the codebase) right?
About the expiry I would make it default for any pacman operation and provide a flag to ignore timestamps maybe?
Comment by Luca Bertozzi (ekardnam) - Thursday, 04 April 2019, 12:34 GMT
And wouldn't a person be able to change the .TIMESTAMP without updating the packages? This would be even a more severe issue as the user would trust the source
Comment by Allan McRae (Allan) - Thursday, 04 April 2019, 12:44 GMT
You would not be able to change the .TIMESTAMP file if the repo was signed. We already have the ability to sign repos, so this avoids the holding back of old repositories.
Comment by Luca Bertozzi (ekardnam) - Thursday, 04 April 2019, 12:47 GMT
So .TIMESTAMP is valid only on signed repos?

Can i contact you via email to get a better idea of this? Will post a shorter log in here to share with everyone
Comment by Eli Schwartz (eschwartz) - Thursday, 04 April 2019, 18:28 GMT
It's not invalid on unsigned repos, but it is less useful.

A timestamp would still prevent issues related to people using broken mirrors without realizing it, and as Andrew said, it would help avoid the use of mismatched .files databases. It just would not enforce a strong security policy, because the security policy needs to come from signing the database file.
Comment by Luca Bertozzi (ekardnam) - Saturday, 06 April 2019, 07:23 GMT
right gotcha, thanks Eli;)