On Thu, Sep 29, 2011 at 6:39 PM, Dan McGee <[email protected]> wrote: > On Thu, Sep 29, 2011 at 1:37 PM, Denis A. Altoé Falqueto > <[email protected]> wrote: >> On Thu, Sep 22, 2011 at 2:27 PM, Dan McGee <[email protected]> wrote: >>> Please report any issues you may find with this package, as it is >>> getting very close to being an actual releasable version. These are >>> debug builds with symbols, so getting stack traces and helpful logging >>> should be relatively straight forward if necessary. >> >> I'm using it in a daily basis and it is very good! I just have one >> issue with pacman-key. >> >> I'm using --lsign-key to sign keys locally, so gpg trusts them for >> validating signatures. But pacman-key is confirming the process >> without asking me. It just feeds 'y's to gpg, so it signs the keys >> without I having the chance of doing manual validation of >> fingerprints. I think pacman-key should just let gpg handle the >> process, showing information about the key and asking if I agree with >> that. For example, if one uses --edit-key to sign keys, a manual >> confirmation is needed to get a key signed. >> >> Do you agree? I can send a patch, if that's the case. > If you want this level of control, why wouldn't you just use > `pacman-key --edit-key`?
Indeed, I could. And i was, until I saw the option to sign directly. But I think it is important for the user to have an opportunity to validate the key that will be signed. It is an important operation and shouldn't be made in a hurry. That's why gpg itself requires the user to confirm before signing. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
