[pacman-dev] pacman signing security vulnerabilities

Denis A. Altoé Falqueto denisfalqueto at gmail.com
Tue Feb 8 19:42:47 EST 2011


On Tue, Feb 8, 2011 at 10:02 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Tue, Feb 8, 2011 at 5:43 PM, Denis A. Altoé Falqueto
> <denisfalqueto at gmail.com> wrote:
>> On Tue, Feb 8, 2011 at 8:02 PM, Dan McGee <dpmcgee at gmail.com> wrote:
>>> On Tue, Feb 8, 2011 at 2:47 PM, Michael Seiwald <michael at mseiwald.at> wrote:
>>>> (3) Repository Freeze Attacks
>>>> An attacker is able to prevent clients from updating by replaying an old
>>>> sync db file with a valid signature. This could be used to keep clients
>>>> from updating software with known vulnerabilities.
>>>> Solution: gpg-signatures already contain a timestamp. Before each
>>>> update, pacman could check if the timestamp is not older than a
>>>> specified period (e.g. a week).
>>>
>>> Yes, very well known, and the site I tell all people to have a read
>>> before hacking on this stuff:
>>> http://www.cs.arizona.edu/stork/packagemanagersecurity/
>>>
>>> We will find a way to address this before we consider package signing complete.
>>
>> I remember some talking about that in the mailing list. It was
>> suggested to have a time limit for the validity of the database
>> signature, so the developers would have to generate a new signature at
>> least every n days, if the database didn't change. That would be a
>> worst case scenario, because the rolling release nature of Arch
>> generates lots of database updates and they would be signed very
>> often.
>
> Allan and I are going to repeat this until our heads explode, but
> pacman != Arch Linux.
>
> What was that?
>
> pacman != Arch Linux.

Yes, of course, my fault :) I always forget about it. Probably you'll
have to remember me some more times :)

> This needs to somehow be feasible for *everyone*, or at least not get
> in their way. I've had (although it has gone stagnant) my one-package
> eee kernel repo; I shouldn't have to sign that every 10 days if
> nothing changes, nor should some in-office repo providing a custom 10
> packages or so, esp. if said database can be fetched from a reliable
> (HTTPS with valid cert, say) source.

Maybe each database could have a property specifying the length of
validity? It could be in days and 0 could be always valid.

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

-------------------------------------------
Denis A. Altoe Falqueto
Linux user #524555
-------------------------------------------


More information about the pacman-dev mailing list