On Sat, Mar 26, 2011 at 1:21 AM, Dave Reisner <d@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@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 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 -------------------------------------------