On Sat, Mar 26, 2011 at 1:21 AM, Dave Reisner <[email protected]> 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 <[email protected]> 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 PM_PGP_VERIFY_ALWAYS, PM_PGP_VERIFY_OPTIONAL or PM_PGP_VERIFY_NEVER. 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 -------------------------------------------
