[pacman-dev] pacman-key imports and key trust levels

Denis A. Altoé Falqueto denisfalqueto at gmail.com
Sat Mar 26 15:30:05 EDT 2011

On Sat, Mar 26, 2011 at 1:21 AM, Dave Reisner <d at falconindy.com> wrote:
> On Fri, Mar 25, 2011 at 11:52:28PM -0400, Ray Kohler wrote:
>> On Fri, Mar 25, 2011 at 11:40 PM, Ray Kohler <ataraxia937 at gmail.com> wrote:
>> > While I'm talking about signing stuff - I noticed an open question on
>> > what to do with the downloaded DB if sig verification fails. I suggest
>> > it be deleted, and the sig be deleted also. These are generally small
>> > files, and it feels really wrong to keep a file "live" on my disk
>> > which has been declared untrustworthy.
>> After a little more thought, probably it would be better to treat it
>> like a bad package download, and ask the user if it should be deleted
>> or not. The sig file is deleted before each download attempt anyway,
>> so it can probably just stay there.
> I've got some patchwork on my working branch that addresses this. The
> code in lib/sync.c that downloads the signature is moved to lib/dload.c
> and the same function downloads both the file follow by the associated sig.
> The current behavior is:
> * file download fails: delete the file
> * file download is aborted (SIGINT): keep the file
> * sig download is aborted: keep the file, delete the sig
> * sig download fails: delete the file _and_ the sig
> This is fairly paranoid behavior, but its in the best interest of the
> user. We need to make sure that the file and the sig both come from the
> same source. Of course, to that end, I'm not sure we can support
> resuming transfers at all. If a file download succeeds (or is aborted)
> and/or the sig is aborted, we can't guarantee that the next time that sync
> is requested, that we're pulling from the same mirror. Do we go
> extra-paranoid and not even give the user the option to save the
> untrusted (maybe partial) file?

Very cool!

I would suggest the use of db->pgp_verify option. It can be one of
So, if that option is always, a failure would mean that the user
doesn't accept failures. Optional would mean that a failure should
prompt the user to decide what to do. The option Never means that
pacman doesn't need to check anything related to signature.

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