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 <[email protected]>
>
> 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);
>>
>>
