<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 19, 2014 at 11:38 AM, Brian Shore <span dir="ltr"><<a href="mailto:brian@networkredux.com" target="_blank">brian@networkredux.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Wed, Mar 19, 2014 at 10:06 AM, Jan-Frode Myklebust<br>

<<a href="mailto:janfrode@tanso.net">janfrode@tanso.net</a>> wrote:<br>
> I agree it's a pain to distribute, and change keys, but am uncertain about if I'd want to blindly trust a keyring distributed together with the password store. Actually, even trusting the list of keyid's instead of a group name defined outside of the git repo is opening up an easy attack by changing the list of id's git-serverside to steal new passwords.<br>

><br>
> The .gpg_id (or keyring) should probably be signed by someone we trust outside of the password-store before use.<br>
<br>
</div>Why not sign the .gpg_id files after creation as part of the init<br>
process?  Does it need to be signed by someone who doesn't use the<br>
password store?</blockquote><div><br></div><div>I think issues of password store file integrity and authenticity will be handled by whatever decision comes out of this thread:  <a href="http://lists.zx2c4.com/pipermail/password-store/2014-March/000498.html">http://lists.zx2c4.com/pipermail/password-store/2014-March/000498.html</a></div>
<div><br></div><div>Right now we're leaning toward signed git commits.</div></div></div></div>