[pacman-dev] [PATCH] libalpm: Force update when database is marked as corrupted.
We are using a CDN to distribute our packages, and it happens from time to time
that the *.db and *.db.sig files are out-of-sync. When the signature is updated
before the database file, everything is fine. However, when the database is
updated first, then libalpm will update the timestamp of the database, but leave
it in a broken state (wrong PGP signature). A force-update is required to
resolve this, which can be confusing for our users - this patch changes
alpm_db_update to trigger an update automatically when the database is invalid.
Signed-off-by: Sebastian Lackner
On 05/07/15 02:39, Sebastian Lackner wrote:
We are using a CDN to distribute our packages, and it happens from time to time that the *.db and *.db.sig files are out-of-sync. When the signature is updated before the database file, everything is fine. However, when the database is updated first, then libalpm will update the timestamp of the database, but leave it in a broken state (wrong PGP signature). A force-update is required to resolve this, which can be confusing for our users - this patch changes alpm_db_update to trigger an update automatically when the database is invalid.
Signed-off-by: Sebastian Lackner
I have never thought about this issue given I always assumed that a database and signature update would be atomic. I am OK with this workaround. I will commit with the commit message changed to: When a database and its signature is updated non-atomically on a server, there is a window where a user may update the database but grab the old signature. The database is marked as invalid by libalpm, which can be fixed by forcing a refresh (assuming the server has caught up and the user realizes what has happened) or with a future update of the repo. Work around this by forcing a repository refresh whenever a database is invalid.
--- lib/libalpm/be_sync.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c index ea979e6..68c5b43 100644 --- a/lib/libalpm/be_sync.c +++ b/lib/libalpm/be_sync.c @@ -196,6 +196,10 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) return -1; }
A comment needs added here.
+ if(db->status & DB_STATUS_INVALID) { + force = 1; + } + /* make sure we have a sane umask */ oldmask = umask(0022);
On 05.07.2015 13:53, Allan McRae wrote:
On 05/07/15 02:39, Sebastian Lackner wrote:
We are using a CDN to distribute our packages, and it happens from time to time that the *.db and *.db.sig files are out-of-sync. When the signature is updated before the database file, everything is fine. However, when the database is updated first, then libalpm will update the timestamp of the database, but leave it in a broken state (wrong PGP signature). A force-update is required to resolve this, which can be confusing for our users - this patch changes alpm_db_update to trigger an update automatically when the database is invalid.
Signed-off-by: Sebastian Lackner
I have never thought about this issue given I always assumed that a database and signature update would be atomic.
I am OK with this workaround. I will commit with the commit message changed to:
When a database and its signature is updated non-atomically on a server, there is a window where a user may update the database but grab the old signature. The database is marked as invalid by libalpm, which can be fixed by forcing a refresh (assuming the server has caught up and the user realizes what has happened) or with a future update of the repo. Work around this by forcing a repository refresh whenever a database is invalid.
Sounds good, thanks.
--- lib/libalpm/be_sync.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c index ea979e6..68c5b43 100644 --- a/lib/libalpm/be_sync.c +++ b/lib/libalpm/be_sync.c @@ -196,6 +196,10 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) return -1; }
A comment needs added here.
Are you adding a comment yourself, or do you want me to resend with the changes? I'm both with fine given that this patch is pretty trivial. ;)
+ if(db->status & DB_STATUS_INVALID) { + force = 1; + } + /* make sure we have a sane umask */ oldmask = umask(0022);
participants (2)
-
Allan McRae
-
Sebastian Lackner