[pacman-dev] [arch-general] Package signing

Denis A. Altoé Falqueto denisfalqueto at gmail.com
Fri May 7 20:17:31 CEST 2010

On Fri, May 7, 2010 at 11:00 AM, Florian Pritz
<bluewind at server-speed.net> wrote:
> On 06.05.2010 22:48, Denis A. Altoé Falqueto wrote:
>> But this doesn't solve the problem of a replay attack (as pointed by
>> Dan, some emails above), where an evil mirror admin puts an old
>> validly signed repo.db to force some user to download a validly signed
>> old package with an known vulnerability. This is tougher to solve. We
>> would need some guaranteed way to tell if the downloaded repo.db is
>> really the latest..... No ideas for now.
> Add the date when the database was signed (inside of the same signature
> of course) and when updating the database (not when installing a
> package) let pacman check if this date is at maximum 1 or 2 days old.
> This requires low mirror delays though.
> If there are no updates for 2 days some dev would have to resign the
> database, but that's quite unlikely and acceptable I think.
> Pacman should also check if the new date is more recent than the old one.

I was thinking about something like that, I would choose something
like 5 or 7 days. This would give a window of attack of at most 7 days
and would give enough time to the mirrors to sync. So, if some package
has a known vulnerability, it would be exploitable by replay attack
only for the last 7 days. After that, the repo.db would expire and the
user would have to download a new one (say, if the mirror is
compromised, it would be an indication of that). If the repository
activity is really low, it would require a new repo.db being resigned
each 5 or 7 days.

The only weak point is the source of time to the comparison. Should we
force an ntp query? Is it possible to use just a client library to do
that or would we need to require a local server? Should we be happy
enough with the time on the computer?

A: Because it obfuscates the reading.
Q: Why is top posting so bad?

Denis A. Altoe Falqueto

More information about the pacman-dev mailing list