[pacman-dev] [PATCH] Remove SyncFirst option

[Pierre Schmitz]

Am 14.02.2012 23:08, schrieb Dave Reisner:
> On Tue, Feb 14, 2012 at 02:30:06PM -0600, Dan McGee wrote:
>> This has outlived its usefulness and causes more problems than it
>> solves.
>>
>> Signed-off-by: Dan McGee <dan at archlinux.org>
>> ---
>>
>> This is an RFC first of all, so please feel free to comment.
>>
>> Pros:
>> 1. Removes complexity and a fair amount of code.
>> 2. Removes the hack necesary for download-only and print operations.
>> 3. Closes at least two bug reports.
>> 4. Pacman is now much more resiliant to updates to itself since vercmp is
>>    statically linked, etc. so updating it alone isn't always necessary.
>>
>> Cons:
>> 1. If a major underlying change occurs (such as a new compression format),
>>    users would need to update pacman explicitly first.
>> 2. ???
> 
> Just to be a jerk... Suppose the following:
> 
> - The fabled keyring package exists. Life is awesome.
> - I go insane and have to be forcefully removed from the dev team, and
>   my packaging key needs to be blacklisted. Alternatively, I'm off on
>   vacation and my desktop+gpg key is compromised. Same end effect.
> - It's assumed that a number of the packages that I maintain are now
>   highly suspect and should NOT be installed.
> 
> In this case, SyncFirst seems like the only way to make sure that people
> are safe from the rootkits that are infecting my packages.

SyncFirst wont help if I am able to sign malicious packages: I'll just
sign my own keyring package. I don't think there is any automatic method
to guarantee a secure update once a signing keys has been compromised.
(This is also why https and OCSP just cannot work; esp. when the
attacker owns the network)

Anyway: I think it'll be a good idea to remove the SyncFirst feature as
it indeed introduces some strange side effects. For some of them we
abused some versioned deps from the pacman package. But one result is
that your system might be in an inconsistent stage after the SyncFirst
run.

I don't think we need to be afraid about having the user to perform
some potential manual steps on major updates.

Greetings,

Pierre

-- 
Pierre Schmitz, http://pierre-schmitz.com