Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-22 23:49, Jean-Philippe Ouellet wrote:
> On Sun, May 14, 2017 at 4:20 PM, Andrew David Wong  wrote:
>> On 2017-05-14 03:51, Holger Levsen wrote:
>>> On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote:
> you really dont protect your gpg key with a passphrase??
 See: https://www.qubes-os.org/doc/split-gpg/
>>>
>>> oh wow :(
>>>
 Why is that a problem? It's only visible in dom0. If an attacker is in
 dom0, it's already game over.
>>>
>>> no, the world is not black and white.
>>>
>>> If an attacker steals your computer while it's unlocked, all your gpg
>>> encrypted stuff is wide open.
>>>
>>> If an attacker steals my computer while it's unlocked, my gpg encrypted
>>> stuff is still locked. Surely the attacker can now install as many 
>>> backdoors as
>>> they want, but as long as I don't type my gpg passphrase into that computer
>>> anymore, it should be pretty safe.
>>>
>>
>> You're conflating two distinct problems:
>>
>> (1) Passphrases I've typed in dom0 are available in cleartext in
>> dom0.
>> (2) Data-at-rest is not encrypted while Qubes is booted and the screen
>> is unlocked.
>>
>> We could solve (1) without solving (2). If we did that, it would solve
>> the `ps` + qvm-backup problem (the first problem you mentioned), since
>> my backup would be encrypted, and the thief wouldn't have access to the
>> backup decryption passphrase.
>>
>> (2) is the second problem you mentioned. Solving (2) is distinct from
>> solving (1), but in order for the solution to (2) to be satisfactory, we
>> also have to solve (1) (or make sure no similar problem arises for
>> per-VM encryption), since otherwise my data-at-rest passphrase could be
>> obtained via (1).
>>
>> I think the right approach to (2) in Qubes is per-VM encryption [1]
>> (probably with LUKS instead of GPG, and certainly not relying on public
>> key crypto, though hopefully we're all already in agreement on the
>> latter point). If I'm in an untrusted physical environment, I should be
>> able to work with less sensitive VMs without decrypting sensitive VMs,
>> and if someone steals my unlocked laptop, they shouldn't be able to gain
>> access to the encrypted sensitive VMs. That's the goal, anyway.
>>
>>
>> [1] https://github.com/QubesOS/qubes-issues/issues/1293
> 
> Solving 1 is not a simple matter of patching some things to pass
> passwords on stdin instead of argv or env vars, it would still be a
> mostly trivial matter for an attacker to just make a core dump and run
> strings on it. Rather, I believe a proper solution to 1 would require
> that dom0 to some degree distrust whoever is physically at the
> keyboard. A "kiosking" of Qubes, if you will.
> 
> Also, I do not agree on your assessment about symmetric crypto being
> obviously the way to go. I think there is value in being able to
> initiate a backup from inside a hostile environment (think: someplace
> with cameras everywhere watching any passphrase you would enter),
> which would make sense to implement by encrypting to an asymmetric
> keypair for which the private half is only in a separate physical
> environment. (Sure, yes, use a symmetric algo for the bulk encryption
> and just encrypt that with the asymetric algo... not my point.) You
> would not be able to decrypt your own backups until you had regained
> access to the private half, but you would be able to start backups
> without needing to divulge your backup secret at the same time. In
> this scheme you would also have another keypair with the secret part
> on your laptop in order to sign the backup (authenticating it with an
> asymmetric signature without requiring a passphrase at backup-creation
> time). I've made this argument before, but perhaps never presented it
> well enough. Expect a PoC in the hopefully not-too-distant future.
> 

Encrypting a backup to a public key, where the private key is not and
never has been accessible to the machine creating the backup? You have
to admit that's a pretty remote edge case for Qubes, which is supposed
to be a trusted single-user system.

I'm not denying such edge cases exist, but it should be obvious that
statements like, "You should use symmetric crypto for your backups" are
not meant to apply in such remote edge cases. Rather, they're meant to
apply in the vast majority of cases in which they make sense. If we
tried to qualify every statement to make it perfectly accurate across
all domains of possibility, we'd never be able to say anything.

(By the way, just because a camera's watching everything you type
doesn't necessarily mean you have to use asymmetric crypto. You could
use, e.g., a preshared keyfile instead.)

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZI8aTAAoJENtN07w5UDAwwgoQALjoWMYgAMey/q1vrEwKnYse
xJ1hpSTiq1VpmQJ3AcPZTwUEXQ80JQs2jKn+8r/LyayxvyUoo5v83mJZ/3/R7UV3
jwC2fC4+ITdDUZUbDEIHHDTmi6/EClZ6XZ

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Jean-Philippe Ouellet]

On Sun, May 14, 2017 at 4:20 PM, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2017-05-14 03:51, Holger Levsen wrote:
>> On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote:
 you really dont protect your gpg key with a passphrase??
>>> See: https://www.qubes-os.org/doc/split-gpg/
>>
>> oh wow :(
>>
>>> Why is that a problem? It's only visible in dom0. If an attacker is in
>>> dom0, it's already game over.
>>
>> no, the world is not black and white.
>>
>> If an attacker steals your computer while it's unlocked, all your gpg
>> encrypted stuff is wide open.
>>
>> If an attacker steals my computer while it's unlocked, my gpg encrypted
>> stuff is still locked. Surely the attacker can now install as many backdoors 
>> as
>> they want, but as long as I don't type my gpg passphrase into that computer
>> anymore, it should be pretty safe.
>>
>
> You're conflating two distinct problems:
>
> (1) Passphrases I've typed in dom0 are available in cleartext in
> dom0.
> (2) Data-at-rest is not encrypted while Qubes is booted and the screen
> is unlocked.
>
> We could solve (1) without solving (2). If we did that, it would solve
> the `ps` + qvm-backup problem (the first problem you mentioned), since
> my backup would be encrypted, and the thief wouldn't have access to the
> backup decryption passphrase.
>
> (2) is the second problem you mentioned. Solving (2) is distinct from
> solving (1), but in order for the solution to (2) to be satisfactory, we
> also have to solve (1) (or make sure no similar problem arises for
> per-VM encryption), since otherwise my data-at-rest passphrase could be
> obtained via (1).
>
> I think the right approach to (2) in Qubes is per-VM encryption [1]
> (probably with LUKS instead of GPG, and certainly not relying on public
> key crypto, though hopefully we're all already in agreement on the
> latter point). If I'm in an untrusted physical environment, I should be
> able to work with less sensitive VMs without decrypting sensitive VMs,
> and if someone steals my unlocked laptop, they shouldn't be able to gain
> access to the encrypted sensitive VMs. That's the goal, anyway.
>
>
> [1] https://github.com/QubesOS/qubes-issues/issues/1293

Solving 1 is not a simple matter of patching some things to pass
passwords on stdin instead of argv or env vars, it would still be a
mostly trivial matter for an attacker to just make a core dump and run
strings on it. Rather, I believe a proper solution to 1 would require
that dom0 to some degree distrust whoever is physically at the
keyboard. A "kiosking" of Qubes, if you will.

Also, I do not agree on your assessment about symmetric crypto being
obviously the way to go. I think there is value in being able to
initiate a backup from inside a hostile environment (think: someplace
with cameras everywhere watching any passphrase you would enter),
which would make sense to implement by encrypting to an asymmetric
keypair for which the private half is only in a separate physical
environment. (Sure, yes, use a symmetric algo for the bulk encryption
and just encrypt that with the asymetric algo... not my point.) You
would not be able to decrypt your own backups until you had regained
access to the private half, but you would be able to start backups
without needing to divulge your backup secret at the same time. In
this scheme you would also have another keypair with the secret part
on your laptop in order to sign the backup (authenticating it with an
asymmetric signature without requiring a passphrase at backup-creation
time). I've made this argument before, but perhaps never presented it
well enough. Expect a PoC in the hopefully not-too-distant future.

Regards,
Jean-Philippe

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_CKyJYdocFbpz_O2YQhO%3DXbNweaDrm6oCsV_4tKvsyVag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Tuesday, May 16, 2017 at 11:33:41 PM UTC-4, cooloutac wrote:
> On Tuesday, May 16, 2017 at 9:31:50 PM UTC-4, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 2017-05-16 01:24, cooloutac wrote:
> > > On Sunday, May 14, 2017 at 11:09:25 PM UTC-4, Andrew David Wong
> > > wrote: On 2017-05-14 21:38, cooloutac wrote:
> >  On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David
> >  Wong wrote:
> > >>> 
> >  
> >  What do you mean? Are you suggesting that qvm-backup has
> >  "more attack vector" than an encrypted KeePassX (or whatever)
> >  database? Why? No, I think it's actually the opposite. An
> >  attacker could feed you a malformed database file, which you
> >  believe is your authentic database file. If it's not
> >  authenticated, you won't be able to tell. When you try to
> >  decrypt and open it with KeePassX, it could try to compromise
> >  KeePassX. qvm-backup is designed to protect against this
> >  class of attack. I'm not sure what you mean. If an attacker
> >  has a copy of your encrypted database and subsequently gets
> >  the key/passphrase to that database, she can then decrypt
> >  the database regardless of what you subsequently do.
> >  
> >  Are you saying that you would render the contents of the
> >  database worthless by changing every password stored in that
> >  database? How would you know to do this? Are you assuming
> >  that you'll somehow know the instant your database has been
> >  compromised? What if the attacker changes some or all of your
> >  passwords before you do? What if you have persistent
> >  passwords (e.g., not for online accounts) that can't be
> >  rendered useless in this way?
> >  
> >  
> >  Well if they can do that to one file,  couldn't they do that
> >  to alot more others if backing up the whole vm? I would think
> >  one file is alot easier to check. Since that whole vaultvm is
> >  only dedicated to that one file for me anyways, and I don't
> >  have custom configs or scripts in it.
> >  
> > > 
> > > No. With qvm-backup-restore, the entire backup blob is checked for 
> > > integrity and authenticity. That check will fail if any bit in the 
> > > blob has changed. Since the blob is encrypted, an attacker won't
> > > be able to tell what individual files are in it, unless you divulge
> > > that information in some other way.
> > > 
> >  One cool thing I saw about paranoid mode is it take into
> >  account things in user directories that are not even user
> >  data to begin with.  so ya I back up other vms that way
> >  especially templates, and especially vms with custom configs.
> >  or vms with just alot of data in alot of diff folders out of
> >  convenience.
> >  
> >  But for the vault I just do the single file.
> >  
> >  And so say if the database file is malware,  what do you mean
> >  by qvm-backup would prevent it?
> >  
> > > 
> > > Suppose you take your encrypted database file and store it
> > > somewhere (e.g., cloud storage, HDD in a safe deposit box). Suppose
> > > that an attacker secretly replaces that file with a malicious one
> > > without your knowledge. The next time you decrypt that database
> > > file, it silently compromises your client or VM and leaks your
> > > passphrases through side channels or does other nasty things.
> > > 
> > > If you had instead backed up the entire VM with qvm-backup, you
> > > would immediately know, upon trying to restore from the backup,
> > > that it was not the same trusted file that you had originally
> > > created, since Qubes would inform you that the integrity and
> > > authenticity check had failed when you entered your passphrase.
> > > 
> > > Now, if your password manager also uses authenticated encryption
> > > for its database files, then that's fine, but as far as I know,
> > > most don't.
> > > 
> >  And yes "rendering it useless by changing every password".
> >  We are talking of the times you suspect it, have a hunch, if
> >  you think you can never tell when you are compromised then
> >  what else is there to go on?
> > > 
> > > There's nothing wrong with acting on a hunch. In some cases, it may
> > > be obvious that a VM or whole system has been compromised, but
> > > there's no way to know for certain that a VM or whole system has
> > > *not* been compromised.
> > > 
> >  and what else can be done?
> >  
> > > 
> > > Use Qubes OS. Compartmentalize. Use Paranoid Mode. :)
> > > 
> > > 
> > > So you are saying qvm-backup will know if an attacker has switched
> > > up the backup file, which is well and good. But I'm assuming the vm
> > > or file is already compromised before backing it up in the first
> > > place.
> > > 
> > 
> > Oh, that's a quite a different scenario from what I had in mind, then.
> > 
> > > Also apparently qvm-backup ha

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Tuesday, May 16, 2017 at 9:31:50 PM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-05-16 01:24, cooloutac wrote:
> > On Sunday, May 14, 2017 at 11:09:25 PM UTC-4, Andrew David Wong
> > wrote: On 2017-05-14 21:38, cooloutac wrote:
>  On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David
>  Wong wrote:
> >>> 
>  
>  What do you mean? Are you suggesting that qvm-backup has
>  "more attack vector" than an encrypted KeePassX (or whatever)
>  database? Why? No, I think it's actually the opposite. An
>  attacker could feed you a malformed database file, which you
>  believe is your authentic database file. If it's not
>  authenticated, you won't be able to tell. When you try to
>  decrypt and open it with KeePassX, it could try to compromise
>  KeePassX. qvm-backup is designed to protect against this
>  class of attack. I'm not sure what you mean. If an attacker
>  has a copy of your encrypted database and subsequently gets
>  the key/passphrase to that database, she can then decrypt
>  the database regardless of what you subsequently do.
>  
>  Are you saying that you would render the contents of the
>  database worthless by changing every password stored in that
>  database? How would you know to do this? Are you assuming
>  that you'll somehow know the instant your database has been
>  compromised? What if the attacker changes some or all of your
>  passwords before you do? What if you have persistent
>  passwords (e.g., not for online accounts) that can't be
>  rendered useless in this way?
>  
>  
>  Well if they can do that to one file,  couldn't they do that
>  to alot more others if backing up the whole vm? I would think
>  one file is alot easier to check. Since that whole vaultvm is
>  only dedicated to that one file for me anyways, and I don't
>  have custom configs or scripts in it.
>  
> > 
> > No. With qvm-backup-restore, the entire backup blob is checked for 
> > integrity and authenticity. That check will fail if any bit in the 
> > blob has changed. Since the blob is encrypted, an attacker won't
> > be able to tell what individual files are in it, unless you divulge
> > that information in some other way.
> > 
>  One cool thing I saw about paranoid mode is it take into
>  account things in user directories that are not even user
>  data to begin with.  so ya I back up other vms that way
>  especially templates, and especially vms with custom configs.
>  or vms with just alot of data in alot of diff folders out of
>  convenience.
>  
>  But for the vault I just do the single file.
>  
>  And so say if the database file is malware,  what do you mean
>  by qvm-backup would prevent it?
>  
> > 
> > Suppose you take your encrypted database file and store it
> > somewhere (e.g., cloud storage, HDD in a safe deposit box). Suppose
> > that an attacker secretly replaces that file with a malicious one
> > without your knowledge. The next time you decrypt that database
> > file, it silently compromises your client or VM and leaks your
> > passphrases through side channels or does other nasty things.
> > 
> > If you had instead backed up the entire VM with qvm-backup, you
> > would immediately know, upon trying to restore from the backup,
> > that it was not the same trusted file that you had originally
> > created, since Qubes would inform you that the integrity and
> > authenticity check had failed when you entered your passphrase.
> > 
> > Now, if your password manager also uses authenticated encryption
> > for its database files, then that's fine, but as far as I know,
> > most don't.
> > 
>  And yes "rendering it useless by changing every password".
>  We are talking of the times you suspect it, have a hunch, if
>  you think you can never tell when you are compromised then
>  what else is there to go on?
> > 
> > There's nothing wrong with acting on a hunch. In some cases, it may
> > be obvious that a VM or whole system has been compromised, but
> > there's no way to know for certain that a VM or whole system has
> > *not* been compromised.
> > 
>  and what else can be done?
>  
> > 
> > Use Qubes OS. Compartmentalize. Use Paranoid Mode. :)
> > 
> > 
> > So you are saying qvm-backup will know if an attacker has switched
> > up the backup file, which is well and good. But I'm assuming the vm
> > or file is already compromised before backing it up in the first
> > place.
> > 
> 
> Oh, that's a quite a different scenario from what I had in mind, then.
> 
> > Also apparently qvm-backup has not taken every file into account or
> > there would be no need for paranoid mode.
> 
> I think you might be misunderstanding Paranoid Mode. VMs that you
> restore using Paranoid Mode may (still) be compromised.
> 
> > I still believe having to only verify the integ

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-16 01:24, cooloutac wrote:
> On Sunday, May 14, 2017 at 11:09:25 PM UTC-4, Andrew David Wong
> wrote: On 2017-05-14 21:38, cooloutac wrote:
 On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David
 Wong wrote:
>>> 
 
 What do you mean? Are you suggesting that qvm-backup has
 "more attack vector" than an encrypted KeePassX (or whatever)
 database? Why? No, I think it's actually the opposite. An
 attacker could feed you a malformed database file, which you
 believe is your authentic database file. If it's not
 authenticated, you won't be able to tell. When you try to
 decrypt and open it with KeePassX, it could try to compromise
 KeePassX. qvm-backup is designed to protect against this
 class of attack. I'm not sure what you mean. If an attacker
 has a copy of your encrypted database and subsequently gets
 the key/passphrase to that database, she can then decrypt
 the database regardless of what you subsequently do.
 
 Are you saying that you would render the contents of the
 database worthless by changing every password stored in that
 database? How would you know to do this? Are you assuming
 that you'll somehow know the instant your database has been
 compromised? What if the attacker changes some or all of your
 passwords before you do? What if you have persistent
 passwords (e.g., not for online accounts) that can't be
 rendered useless in this way?
 
 
 Well if they can do that to one file,  couldn't they do that
 to alot more others if backing up the whole vm? I would think
 one file is alot easier to check. Since that whole vaultvm is
 only dedicated to that one file for me anyways, and I don't
 have custom configs or scripts in it.
 
> 
> No. With qvm-backup-restore, the entire backup blob is checked for 
> integrity and authenticity. That check will fail if any bit in the 
> blob has changed. Since the blob is encrypted, an attacker won't
> be able to tell what individual files are in it, unless you divulge
> that information in some other way.
> 
 One cool thing I saw about paranoid mode is it take into
 account things in user directories that are not even user
 data to begin with.  so ya I back up other vms that way
 especially templates, and especially vms with custom configs.
 or vms with just alot of data in alot of diff folders out of
 convenience.
 
 But for the vault I just do the single file.
 
 And so say if the database file is malware,  what do you mean
 by qvm-backup would prevent it?
 
> 
> Suppose you take your encrypted database file and store it
> somewhere (e.g., cloud storage, HDD in a safe deposit box). Suppose
> that an attacker secretly replaces that file with a malicious one
> without your knowledge. The next time you decrypt that database
> file, it silently compromises your client or VM and leaks your
> passphrases through side channels or does other nasty things.
> 
> If you had instead backed up the entire VM with qvm-backup, you
> would immediately know, upon trying to restore from the backup,
> that it was not the same trusted file that you had originally
> created, since Qubes would inform you that the integrity and
> authenticity check had failed when you entered your passphrase.
> 
> Now, if your password manager also uses authenticated encryption
> for its database files, then that's fine, but as far as I know,
> most don't.
> 
 And yes "rendering it useless by changing every password".
 We are talking of the times you suspect it, have a hunch, if
 you think you can never tell when you are compromised then
 what else is there to go on?
> 
> There's nothing wrong with acting on a hunch. In some cases, it may
> be obvious that a VM or whole system has been compromised, but
> there's no way to know for certain that a VM or whole system has
> *not* been compromised.
> 
 and what else can be done?
 
> 
> Use Qubes OS. Compartmentalize. Use Paranoid Mode. :)
> 
> 
> So you are saying qvm-backup will know if an attacker has switched
> up the backup file, which is well and good. But I'm assuming the vm
> or file is already compromised before backing it up in the first
> place.
> 

Oh, that's a quite a different scenario from what I had in mind, then.

> Also apparently qvm-backup has not taken every file into account or
> there would be no need for paranoid mode.

I think you might be misunderstanding Paranoid Mode. VMs that you
restore using Paranoid Mode may (still) be compromised.

> I still believe having to only verify the integrity of a single
> file is better then  a whole vm.
> 

Well, the backup is itself a single file.

> Although this discussion makes me think maybe when loading the
> possibly compromised keepassx file I should load it in a disposable
> just to get the passwords, but not open it in the

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Sunday, May 14, 2017 at 11:09:25 PM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-05-14 21:38, cooloutac wrote:
> > On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David Wong
> > wrote:
>  
> > 
> > What do you mean? Are you suggesting that qvm-backup has "more
> > attack vector" than an encrypted KeePassX (or whatever) database?
> > Why? No, I think it's actually the opposite. An attacker could feed
> > you a malformed database file, which you believe is your authentic
> > database file. If it's not authenticated, you won't be able to
> > tell. When you try to decrypt and open it with KeePassX, it could
> > try to compromise KeePassX. qvm-backup is designed to protect
> > against this class of attack. I'm not sure what you mean. If an
> > attacker has a copy of your encrypted database and subsequently
> > gets the key/passphrase to that database, she can then decrypt the
> > database regardless of what you subsequently do.
> > 
> > Are you saying that you would render the contents of the database 
> > worthless by changing every password stored in that database? How 
> > would you know to do this? Are you assuming that you'll somehow
> > know the instant your database has been compromised? What if the
> > attacker changes some or all of your passwords before you do? What
> > if you have persistent passwords (e.g., not for online accounts)
> > that can't be rendered useless in this way?
> > 
> > 
> > Well if they can do that to one file,  couldn't they do that to
> > alot more others if backing up the whole vm? I would think one file
> > is alot easier to check. Since that whole vaultvm is only dedicated
> > to that one file for me anyways, and I don't have custom configs or
> > scripts in it.
> > 
> 
> No. With qvm-backup-restore, the entire backup blob is checked for
> integrity and authenticity. That check will fail if any bit in the
> blob has changed. Since the blob is encrypted, an attacker won't be
> able to tell what individual files are in it, unless you divulge that
> information in some other way.
> 
> > One cool thing I saw about paranoid mode is it take into account
> > things in user directories that are not even user data to begin
> > with.  so ya I back up other vms that way especially templates, and
> > especially vms with custom configs. or vms with just alot of data
> > in alot of diff folders out of convenience.
> > 
> > But for the vault I just do the single file.
> > 
> > And so say if the database file is malware,  what do you mean by
> > qvm-backup would prevent it?
> > 
> 
> Suppose you take your encrypted database file and store it somewhere
> (e.g., cloud storage, HDD in a safe deposit box). Suppose that an
> attacker secretly replaces that file with a malicious one without your
> knowledge. The next time you decrypt that database file, it silently
> compromises your client or VM and leaks your passphrases through side
> channels or does other nasty things.
> 
> If you had instead backed up the entire VM with qvm-backup, you would
> immediately know, upon trying to restore from the backup, that it was
> not the same trusted file that you had originally created, since Qubes
> would inform you that the integrity and authenticity check had failed
> when you entered your passphrase.
> 
> Now, if your password manager also uses authenticated encryption for
> its database files, then that's fine, but as far as I know, most don't.
> 
> > And yes "rendering it useless by changing every password".  We are
> > talking of the times you suspect it, have a hunch, if you think you
> > can never tell when you are compromised then what else is there to
> > go on?
> 
> There's nothing wrong with acting on a hunch. In some cases, it may be
> obvious that a VM or whole system has been compromised, but there's no
> way to know for certain that a VM or whole system has *not* been
> compromised.
> 
> > and what else can be done?
> > 
> 
> Use Qubes OS. Compartmentalize. Use Paranoid Mode. :)
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJZGRvVAAoJENtN07w5UDAwHAAQALd0vAijgbKELXG+Zc/lHT/Y
> 0MjYwfzxhjEzxD/nkqgVRjhX8Pjvwxq7LZGtSE0D6TlLl6VRM6OUwjsc2JCD7iSE
> /HIij8h/D89wgIuWLXBD394sBuGvLOjoHsaDbSU/GHfN16r88YKJ6L1YDe5XPiwL
> 0AuM8zvVVcPshNa7QH7fnnWo/VlA9wM2zr6NfKIclEyW1Ty555SXztlG03sQIrDD
> 1J4+7/NM9zHUvaWtgoy2PcFEPbEiXcL5IqoWUeWxDQhG5fWFuUcYDK5L3dheN43A
> B2YYwKK60DpH1/qIXjslpz6jYlV1KSAUaibI1GNQcXkj9HaQ6qHihUUCucYUbrIY
> pfMAmtPxOPpReA0HLRT0EurLsknVZ4dj/Va0oUbbL12ZbIsZM6qSoGHA2Uc/8I1+
> wQKWOaeSeiluARGwQMfHDOEoM9D6JzJ7LqRhCrV6jAuwMeWiFdeBd+6l/wtN8e9g
> UNqoKqK0JOJMJXiQct9zrZ0vyeqGloyW7X/BmytAM/MTznsa5fA+lzG5gx7/IWrZ
> BFarprX2R2rIrFkQoEn3LO0DkfjQs+7QKpKXLuvl3lk11Slib13Ah2qLfcV7dMg2
> 8PpHxVkmuLMfbHwCDFZZSs1K3jZ+c9J0wZZF46bqWqt5DeZi9F+JkBQ53/V2a3dW
> 52CXFlG7RHmJXxVujHjT
> =Z70t
> -END PGP SIGNATURE-

So you are saying qvm-backup will know

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-14 21:38, cooloutac wrote:
> On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David Wong
> wrote:
 
> 
> What do you mean? Are you suggesting that qvm-backup has "more
> attack vector" than an encrypted KeePassX (or whatever) database?
> Why? No, I think it's actually the opposite. An attacker could feed
> you a malformed database file, which you believe is your authentic
> database file. If it's not authenticated, you won't be able to
> tell. When you try to decrypt and open it with KeePassX, it could
> try to compromise KeePassX. qvm-backup is designed to protect
> against this class of attack. I'm not sure what you mean. If an
> attacker has a copy of your encrypted database and subsequently
> gets the key/passphrase to that database, she can then decrypt the
> database regardless of what you subsequently do.
> 
> Are you saying that you would render the contents of the database 
> worthless by changing every password stored in that database? How 
> would you know to do this? Are you assuming that you'll somehow
> know the instant your database has been compromised? What if the
> attacker changes some or all of your passwords before you do? What
> if you have persistent passwords (e.g., not for online accounts)
> that can't be rendered useless in this way?
> 
> 
> Well if they can do that to one file,  couldn't they do that to
> alot more others if backing up the whole vm? I would think one file
> is alot easier to check. Since that whole vaultvm is only dedicated
> to that one file for me anyways, and I don't have custom configs or
> scripts in it.
> 

No. With qvm-backup-restore, the entire backup blob is checked for
integrity and authenticity. That check will fail if any bit in the
blob has changed. Since the blob is encrypted, an attacker won't be
able to tell what individual files are in it, unless you divulge that
information in some other way.

> One cool thing I saw about paranoid mode is it take into account
> things in user directories that are not even user data to begin
> with.  so ya I back up other vms that way especially templates, and
> especially vms with custom configs. or vms with just alot of data
> in alot of diff folders out of convenience.
> 
> But for the vault I just do the single file.
> 
> And so say if the database file is malware,  what do you mean by
> qvm-backup would prevent it?
> 

Suppose you take your encrypted database file and store it somewhere
(e.g., cloud storage, HDD in a safe deposit box). Suppose that an
attacker secretly replaces that file with a malicious one without your
knowledge. The next time you decrypt that database file, it silently
compromises your client or VM and leaks your passphrases through side
channels or does other nasty things.

If you had instead backed up the entire VM with qvm-backup, you would
immediately know, upon trying to restore from the backup, that it was
not the same trusted file that you had originally created, since Qubes
would inform you that the integrity and authenticity check had failed
when you entered your passphrase.

Now, if your password manager also uses authenticated encryption for
its database files, then that's fine, but as far as I know, most don't.

> And yes "rendering it useless by changing every password".  We are
> talking of the times you suspect it, have a hunch, if you think you
> can never tell when you are compromised then what else is there to
> go on?

There's nothing wrong with acting on a hunch. In some cases, it may be
obvious that a VM or whole system has been compromised, but there's no
way to know for certain that a VM or whole system has *not* been
compromised.

> and what else can be done?
> 

Use Qubes OS. Compartmentalize. Use Paranoid Mode. :)

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZGRvVAAoJENtN07w5UDAwHAAQALd0vAijgbKELXG+Zc/lHT/Y
0MjYwfzxhjEzxD/nkqgVRjhX8Pjvwxq7LZGtSE0D6TlLl6VRM6OUwjsc2JCD7iSE
/HIij8h/D89wgIuWLXBD394sBuGvLOjoHsaDbSU/GHfN16r88YKJ6L1YDe5XPiwL
0AuM8zvVVcPshNa7QH7fnnWo/VlA9wM2zr6NfKIclEyW1Ty555SXztlG03sQIrDD
1J4+7/NM9zHUvaWtgoy2PcFEPbEiXcL5IqoWUeWxDQhG5fWFuUcYDK5L3dheN43A
B2YYwKK60DpH1/qIXjslpz6jYlV1KSAUaibI1GNQcXkj9HaQ6qHihUUCucYUbrIY
pfMAmtPxOPpReA0HLRT0EurLsknVZ4dj/Va0oUbbL12ZbIsZM6qSoGHA2Uc/8I1+
wQKWOaeSeiluARGwQMfHDOEoM9D6JzJ7LqRhCrV6jAuwMeWiFdeBd+6l/wtN8e9g
UNqoKqK0JOJMJXiQct9zrZ0vyeqGloyW7X/BmytAM/MTznsa5fA+lzG5gx7/IWrZ
BFarprX2R2rIrFkQoEn3LO0DkfjQs+7QKpKXLuvl3lk11Slib13Ah2qLfcV7dMg2
8PpHxVkmuLMfbHwCDFZZSs1K3jZ+c9J0wZZF46bqWqt5DeZi9F+JkBQ53/V2a3dW
52CXFlG7RHmJXxVujHjT
=Z70t
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Sunday, May 14, 2017 at 10:38:37 PM UTC-4, cooloutac wrote:
> On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > > 
> > 
> > What do you mean? Are you suggesting that qvm-backup has "more attack
> > vector" than an encrypted KeePassX (or whatever) database? Why?
> > No, I think it's actually the opposite. An attacker could feed you a
> > malformed database file, which you believe is your authentic database
> > file. If it's not authenticated, you won't be able to tell. When you
> > try to decrypt and open it with KeePassX, it could try to compromise
> > KeePassX. qvm-backup is designed to protect against this class of
> > attack.
> > I'm not sure what you mean. If an attacker has a copy of your
> > encrypted database and subsequently gets the key/passphrase to that
> > database, she can then decrypt the database regardless of what you
> > subsequently do.
> > 
> > Are you saying that you would render the contents of the database
> > worthless by changing every password stored in that database? How
> > would you know to do this? Are you assuming that you'll somehow know
> > the instant your database has been compromised? What if the attacker
> > changes some or all of your passwords before you do? What if you have
> > persistent passwords (e.g., not for online accounts) that can't be
> > rendered useless in this way?
> > 
> > - -- 
> > Andrew David Wong (Axon)
> > Community Manager, Qubes OS
> > https://www.qubes-os.org
> > -BEGIN PGP SIGNATURE-
> > 
> > iQIcBAEBCgAGBQJZGLRXAAoJENtN07w5UDAwmegP/imUHFRm0SadmiWdh6T71oWd
> > VaQt8TMrXoUeguysZEE3l0EwhWKbmET2KunXbkN5/RNfEz7wb9yIerNKnt5cTNMh
> > ko1ENAdNO9vWufJQyNSuZ+CScV/EL+tUG8626r28em1Rb2TknNk4COBb3pX0VRCC
> > RF3h7p+rSZufSy4xVuwVZRcllT94HhFTGpuvhzcB+f3FMmKjkTcYZLVL1gddiwcP
> > mEE1DAEGdsY5Y5eKl7xCAaiICvK2sSLWHTBGYZT3FZF6TSqLJ8iO92IoeMjPIbRS
> > +OShxw+ITr/g9oN+pSJ6con+mZk6xzrRC5ExZS9mRaYOLlXVx8LyC41cGVSxO0nb
> > KNoaMZqJ3nA8FtkfJ0Jo7786A2UBPYzSln4qzc8kqQ/23oa6Gevm9JckzixWLo3t
> > BnPN99fZ0zlspDcvkgPjoJhB3TPlUdvBbcHrWd5G93I/GIPCNp6yBvLAvoMyZcL5
> > RdZ4yH+CB7BK1aInrHaHtKN68Bjep5ZTBXCmWVwIuXN2g82kip7uQ9qPAUtFvSqx
> > B4a/N1MPkVB80DFLRFHDdDQM0ChiEj3ewA3NPp2mk6ECJbnq0lxUeWGMU93pufuN
> > Dqx5EpopP1bVX8amLr8eYn+2C+eTAxgZIj+lC+dUg/kmqn/kjq7mzS3sCyxc41ni
> > iZbzihGynHg5/sZ31Oft
> > =nZE4
> > -END PGP SIGNATURE-
> 
> Well if they can do that to one file,  couldn't they do that to alot more 
> others if backing up the whole vm? I would think one file is alot easier to 
> check. Since that whole vaultvm is only dedicated to that one file for me 
> anyways, and I don't have custom configs or scripts in it.
> 
>  One cool thing I saw about paranoid mode is it take into account things in 
> user directories that are not even user data to begin with.  so ya I back up 
> other vms that way especially templates, and especially vms with custom 
> configs. or vms with just alot of data in alot of diff folders out of 
> convenience. 
> 
> But for the vault I just do the single file.
> 
> And so say if the database file is malware,  what do you mean by qvm-backup 
> would prevent it?
> 
> And yes "rendering it useless by changing every password".  We are talking of 
> the times you suspect it, have a hunch, if you think you can never tell when 
> you are compromised then what else is there to go on?  and what else can be 
> done?

by a hunch I mean like noticing weird anomalies,  freezes, crashes, mouse 
issues, lag, or just anything really,  timing and sequence of events. after my 
account gets hacked do I still just say it could just be a random bug cause I 
have no proof?

if we really can't notice anything suspicious in even with live realtime 
network traffic, system logs,  or file integrity logs,  then what else are you 
supposed to do.  Just already assume its compromised.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/01ae4ab6-c8dd-4555-8c5c-73abc9cb6cee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> > 
> 
> What do you mean? Are you suggesting that qvm-backup has "more attack
> vector" than an encrypted KeePassX (or whatever) database? Why?
> No, I think it's actually the opposite. An attacker could feed you a
> malformed database file, which you believe is your authentic database
> file. If it's not authenticated, you won't be able to tell. When you
> try to decrypt and open it with KeePassX, it could try to compromise
> KeePassX. qvm-backup is designed to protect against this class of
> attack.
> I'm not sure what you mean. If an attacker has a copy of your
> encrypted database and subsequently gets the key/passphrase to that
> database, she can then decrypt the database regardless of what you
> subsequently do.
> 
> Are you saying that you would render the contents of the database
> worthless by changing every password stored in that database? How
> would you know to do this? Are you assuming that you'll somehow know
> the instant your database has been compromised? What if the attacker
> changes some or all of your passwords before you do? What if you have
> persistent passwords (e.g., not for online accounts) that can't be
> rendered useless in this way?
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJZGLRXAAoJENtN07w5UDAwmegP/imUHFRm0SadmiWdh6T71oWd
> VaQt8TMrXoUeguysZEE3l0EwhWKbmET2KunXbkN5/RNfEz7wb9yIerNKnt5cTNMh
> ko1ENAdNO9vWufJQyNSuZ+CScV/EL+tUG8626r28em1Rb2TknNk4COBb3pX0VRCC
> RF3h7p+rSZufSy4xVuwVZRcllT94HhFTGpuvhzcB+f3FMmKjkTcYZLVL1gddiwcP
> mEE1DAEGdsY5Y5eKl7xCAaiICvK2sSLWHTBGYZT3FZF6TSqLJ8iO92IoeMjPIbRS
> +OShxw+ITr/g9oN+pSJ6con+mZk6xzrRC5ExZS9mRaYOLlXVx8LyC41cGVSxO0nb
> KNoaMZqJ3nA8FtkfJ0Jo7786A2UBPYzSln4qzc8kqQ/23oa6Gevm9JckzixWLo3t
> BnPN99fZ0zlspDcvkgPjoJhB3TPlUdvBbcHrWd5G93I/GIPCNp6yBvLAvoMyZcL5
> RdZ4yH+CB7BK1aInrHaHtKN68Bjep5ZTBXCmWVwIuXN2g82kip7uQ9qPAUtFvSqx
> B4a/N1MPkVB80DFLRFHDdDQM0ChiEj3ewA3NPp2mk6ECJbnq0lxUeWGMU93pufuN
> Dqx5EpopP1bVX8amLr8eYn+2C+eTAxgZIj+lC+dUg/kmqn/kjq7mzS3sCyxc41ni
> iZbzihGynHg5/sZ31Oft
> =nZE4
> -END PGP SIGNATURE-

Well if they can do that to one file,  couldn't they do that to alot more 
others if backing up the whole vm? I would think one file is alot easier to 
check. Since that whole vaultvm is only dedicated to that one file for me 
anyways, and I don't have custom configs or scripts in it.

 One cool thing I saw about paranoid mode is it take into account things in 
user directories that are not even user data to begin with.  so ya I back up 
other vms that way especially templates, and especially vms with custom 
configs. or vms with just alot of data in alot of diff folders out of 
convenience. 

But for the vault I just do the single file.

And so say if the database file is malware,  what do you mean by qvm-backup 
would prevent it?

And yes "rendering it useless by changing every password".  We are talking of 
the times you suspect it, have a hunch, if you think you can never tell when 
you are compromised then what else is there to go on?  and what else can be 
done?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b15a3edf-0d17-40a5-9a72-8f9761173f5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-14 03:51, Holger Levsen wrote:
> On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote:
>>> you really dont protect your gpg key with a passphrase??
>> See: https://www.qubes-os.org/doc/split-gpg/
> 
> oh wow :(
>  
>> Why is that a problem? It's only visible in dom0. If an attacker is in
>> dom0, it's already game over.
> 
> no, the world is not black and white.
> 
> If an attacker steals your computer while it's unlocked, all your gpg
> encrypted stuff is wide open.
> 
> If an attacker steals my computer while it's unlocked, my gpg encrypted
> stuff is still locked. Surely the attacker can now install as many backdoors 
> as
> they want, but as long as I don't type my gpg passphrase into that computer
> anymore, it should be pretty safe.
> 

You're conflating two distinct problems:

(1) Passphrases I've typed in dom0 are available in cleartext in
dom0.
(2) Data-at-rest is not encrypted while Qubes is booted and the screen
is unlocked.

We could solve (1) without solving (2). If we did that, it would solve
the `ps` + qvm-backup problem (the first problem you mentioned), since
my backup would be encrypted, and the thief wouldn't have access to the
backup decryption passphrase.

(2) is the second problem you mentioned. Solving (2) is distinct from
solving (1), but in order for the solution to (2) to be satisfactory, we
also have to solve (1) (or make sure no similar problem arises for
per-VM encryption), since otherwise my data-at-rest passphrase could be
obtained via (1).

I think the right approach to (2) in Qubes is per-VM encryption [1]
(probably with LUKS instead of GPG, and certainly not relying on public
key crypto, though hopefully we're all already in agreement on the
latter point). If I'm in an untrusted physical environment, I should be
able to work with less sensitive VMs without decrypting sensitive VMs,
and if someone steals my unlocked laptop, they shouldn't be able to gain
access to the encrypted sensitive VMs. That's the goal, anyway.


[1] https://github.com/QubesOS/qubes-issues/issues/1293

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZGLwgAAoJENtN07w5UDAwAbQP/juQIolMCIFVF8m+MP4pAOkK
2AssF3W2S9ta9HBj5zFQNxCPrkkg/cF0rK78iB5C4QevU/vXlGQSbtmudQL8vejV
S/tEXPQQZCpU9+9HOXkAAUSXGYxd8rr5j6xtUx5j+GwBV/1RFH1GEyzDAafU/bZR
7Sa8t0HPx6pjOPst85i0Fg++qmka/t0aBjTrjwk63LijqBZXz8FBpeQKdqAzv8Ip
he6/EpDSRP7H6VRuIm8iFeYs/6ohFOemesp8BMF7tcPYxOI68rQTtzdgpSYIf4ve
oALypvQ1oDJt8z/TKckbrGlIk5lYJfOuKq3/4MkyoZxM8V24yKPNaeeoyiEsLvOH
QrnBzyBSbxMIZnuHfNyTb5QGn+YM511hHaGQFSxqCPsSD4orVmuXpnJsm2YdEXeU
iChHyzdfsUrWOeh1TgqnfQ078AvK3JZKMwHwOYucYERgSMu5yUFjS57yv60FdmsH
yXl5S+I9CThKdr9y8mHq8GujEOlMjMG7eqlA8Q/Up48T7RQnHF8Ivrntkiwb4pBb
B2iciTO5KZ+JhcPqoNp/NPCvv3G4R2s0vtFF8QO3nMFjczVv9D3hrockRBEh7rkz
HMVaobICdqMKemHF4Dg30gqG5V9WDpiMwFybj2x339SoOLb6E3rMJ+YH3hM+vvVm
Bd5Hzi2hwvaAD/S31BZx
=6VoB
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/dfbbdb3b-7dab-f4ce-7c78-7991675f1b01%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-13 18:39, cooloutac wrote:
> On Saturday, May 13, 2017 at 3:50:36 PM UTC-4, Andrew David Wong 
> wrote: On 2017-05-09 14:54, cooloutac wrote:
 On Tuesday, May 9, 2017 at 1:40:03 AM UTC-4, Andrew David 
 Wong wrote: On 2017-05-08 23:47, cooloutac wrote:
>>> On Tuesday, May 9, 2017 at 12:47:11 AM UTC-4,
>>> cooloutac wrote:
 On Sunday, May 7, 2017 at 12:33:54 PM UTC-4, 
 nick...@kulinacs.com wrote:
> On May 7, 2017 10:39:22 AM CDT, Andrew David Wong 
>  wrote:
>>> On 2017-05-07 10:32, nickl...@kulinacs.com wrote:
 On May 7, 2017 10:23:54 AM CDT, Andrew David 
 Wong  wrote: On 2017-05-07 
 10:10, nickl...@kulinacs.com wrote:
>>> What benefit does this have over simply
>>> ysing qubes-split-gpg-client-wrapper,
>>> like done here: 
>>> https://github.com/kulinacs/pass-qubes 
>>> It seems like a lot of overhead for not
>>> a lot of gain.
>>> 
>>> On May 7, 2017 9:50:26 AM CDT, "Manuel 
>>> Amador (Rudd-O)"  
>>> wrote:
 Building on the excellent pass 
 (https://passwordstore.org), it
 gives me great pleasure to announce
 the initial release of qubes-pass —
 an inter-VM password manager and
 store for Qubes OS.
 
 Check it out here!
 
 https://github.com/Rudd-O/qubes-pass
 
 
 What are the advantages of either of these 
 over the traditional Qubes model of having a 
 normal password manager in a vault VM and 
 using the inter-VM clipboard to copy/paste 
 passwords out of it?
 
 
 I prefer Pass because it uses GPG for 
 encryption, meaning I can manage fewer 
 secrets over all (as it backends into my 
 normal GPG key) and then track my password 
 files in git. To do this with the
 traditional Keepass method, you either need
 to back up the password database somewhere
 secure or remember another password for it.
 
>>> 
>>> Why not just back up the entire vault with qvm-backup?
>>> 
> 
> Git has less storage overhead (as you're backing
> up a bunch of text files, not an entire VM),
> allows proper versioning, so it is trivial to see
> your passwords at a point in time, and can be used
> cross platform if you chose to keep your GPG key
> on another system.
 
 I just back up the database file. its encrypted.
>>> 
>>> I don't think backing up the whole vault is a good
>>> idea if you don't have to.
>>> 
 
 Why? No need to encrypt the database file if the whole VM is 
 encrypted. Also, if your database file doesn't use 
 authenticated encryption, that's another thing to worry 
 about. You may also worry about file-level metadata leakage.
 
 
 the database file is automatically encrypted.  I just feel 
 like vault more likely compromised then the file if
 something is.  but I could be wrong.  plus way less space.
 
> 
> I don't see any basis for that reasoning. The files in an AppVM are
> only as safe as the AppVM itself, unless the VM is used only for
> storage or something.
> 
> If the vault VM is compromised, then the encrypted database file in
> the vault is only safe as long as it remains encrypted. An attacker
> who can compromise your vault can set a trigger that waits for you
> to decrypt the database the next time you want to use it, then grab
> the passphrase, decryption key, or the whole decrypted database.
> 
 I think when we have paranoid mode it will be better.
 
> 
> 
> Because more attack vector. Seems like common sense for me.  The 
> whole point of paranoid mode isn't it?
> 

What do you mean? Are you suggesting that qvm-backup has "more attack
vector" than an encrypted KeePassX (or whatever) database? Why?

> As for attacker getting the key to the database file thats fine,
> in other words you also assume like I would that they are not
> turning it into malware itself.

No, I think it's actually the opposite. An attacker could feed you a
malformed database file, which you believe is your authentic database
file. If it's not authenticated, you won't be able to tell. When you
try to decrypt and open it with KeePassX, it could try to compromise
KeePassX. qvm-backup is designed to protect against this class of
attack.

> Even if they got the key thats fine if you are just using it to 
> change your passwords using a new database and new key.
> 

I'm not sure what you mean. If an attacker has a copy of your
encrypted datab

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Holger Levsen]

On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote:
> > you really dont protect your gpg key with a passphrase??
> See: https://www.qubes-os.org/doc/split-gpg/

oh wow :(
 
> Why is that a problem? It's only visible in dom0. If an attacker is in
> dom0, it's already game over.

no, the world is not black and white.

If an attacker steals your computer while it's unlocked, all your gpg
encrypted stuff is wide open.

If an attacker steals my computer while it's unlocked, my gpg encrypted
stuff is still locked. Surely the attacker can now install as many backdoors as
they want, but as long as I don't type my gpg passphrase into that computer
anymore, it should be pretty safe.


-- 
cheers,
Holger

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170514085123.GC13184%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Saturday, May 13, 2017 at 3:50:36 PM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-05-09 14:54, cooloutac wrote:
> > On Tuesday, May 9, 2017 at 1:40:03 AM UTC-4, Andrew David Wong 
> > wrote: On 2017-05-08 23:47, cooloutac wrote:
>  On Tuesday, May 9, 2017 at 12:47:11 AM UTC-4, cooloutac 
>  wrote:
> > On Sunday, May 7, 2017 at 12:33:54 PM UTC-4, 
> > nick...@kulinacs.com wrote:
> >> On May 7, 2017 10:39:22 AM CDT, Andrew David Wong 
> >>  wrote:
>  On 2017-05-07 10:32, nickl...@kulinacs.com wrote:
> > On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
> >  wrote: On 2017-05-07 10:10, 
> > nickl...@kulinacs.com wrote:
>  What benefit does this have over simply
>  ysing qubes-split-gpg-client-wrapper, like
>  done here:
>  https://github.com/kulinacs/pass-qubes It
>  seems like a lot of overhead for not a lot of
>  gain.
>  
>  On May 7, 2017 9:50:26 AM CDT, "Manuel Amador
>  (Rudd-O)"  wrote:
> > Building on the excellent pass 
> > (https://passwordstore.org), it gives me 
> > great pleasure to announce the initial 
> > release of qubes-pass — an inter-VM 
> > password manager and store for Qubes OS.
> > 
> > Check it out here!
> > 
> > https://github.com/Rudd-O/qubes-pass
> > 
> > 
> > What are the advantages of either of these over the
> > traditional Qubes model of having a normal password
> > manager in a vault VM and using the inter-VM
> > clipboard to copy/paste passwords out of it?
> > 
> > 
> > I prefer Pass because it uses GPG for encryption, 
> > meaning I can manage fewer secrets over all (as it 
> > backends into my normal GPG key) and then track my 
> > password files in git. To do this with the 
> > traditional Keepass method, you either need to
> > back up the password database somewhere secure or 
> > remember another password for it.
> > 
>  
>  Why not just back up the entire vault with qvm-backup?
>  
> >> 
> >> Git has less storage overhead (as you're backing up a 
> >> bunch of text files, not an entire VM), allows proper 
> >> versioning, so it is trivial to see your passwords at a 
> >> point in time, and can be used cross platform if you 
> >> chose to keep your GPG key on another system.
> > 
> > I just back up the database file. its encrypted.
>  
>  I don't think backing up the whole vault is a good idea if 
>  you don't have to.
>  
> > 
> > Why? No need to encrypt the database file if the whole VM is 
> > encrypted. Also, if your database file doesn't use authenticated 
> > encryption, that's another thing to worry about. You may also worry
> > about file-level metadata leakage.
> > 
> > 
> > the database file is automatically encrypted.  I just feel like 
> > vault more likely compromised then the file if something is.  but
> > I could be wrong.  plus way less space.
> > 
> 
> I don't see any basis for that reasoning. The files in an AppVM are
> only as safe as the AppVM itself, unless the VM is used only for
> storage or something.
> 
> If the vault VM is compromised, then the encrypted database file in
> the vault is only safe as long as it remains encrypted. An attacker
> who can compromise your vault can set a trigger that waits for you to
> decrypt the database the next time you want to use it, then grab the
> passphrase, decryption key, or the whole decrypted database.
> 
> > I think when we have paranoid mode it will be better.
> > 
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJZF2N9AAoJENtN07w5UDAw8goP/itJWd/QiGchOPYmavzXB+AS
> HKycQy2y4lvqHjl1cltPXP0unThvoK8BSgCWdm2wRbj7T/Lc5EG7mtCScXyZP6uc
> ouFTMPjyjYECmINWaU/rNEOJRy5XR6q3AcVeObBRZxdst59g9GNtCXAgu47U7WjJ
> 8u+9wqEO1PD7Oo+ZlFZ971JMsYluU7uxHwqDYqFabPc+FvkD5hEIBM3tfXvmbJuo
> qlhpQpVyudYcgCs8Xtt6e1P1GcSc0pXT03nd7mw8QeMsZq3Ua6x8tOEtAnl93pba
> LXWoHEmLGg5BbYbkbXMeZYYTyM+e5f4MN78DkolaqzwD73IVITg+8ctJD+rNSgIB
> dJhNeAVtsddyQ+7+3IHxsOSgVvnBANoC2e7iBLkVxd0zqKnT6hdbSNQPfrftIQzV
> uATOBVgCy16/xjgOeqPENAbT9ElZfgIyEhN3HPQsOPhM0ASSdSgx+fHNH9RY/dZ7
> aoWbILGJRL52J1R4koumXvbaWSHLo2HAIv1xljstedltDt4jyjDQtRfJ2Zbf7jK1
> hGXZcsUtyZHyZklHyYb8ZiQa6gbGj3KBHQaz91TznTdgIV/G42iL+GFb1jej8TIS
> 2mBALx5WL82jo5Nmb/4GJ/5nb3ShBAeOm9YkfctQX0fXd3lweZ7h9i79rAocIrZ9
> o87ju6uck1ri3q3q01Pt
> =oKxB
> -END PGP SIGNATURE-

Because more attack vector. Seems like common sense for me.  The whole point of 
paranoid mode isn't it?

As for attacker getting the key to the database file thats fine, in other words 
you also assume like I would that they 

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-11 20:53, Manuel Amador (Rudd-O) wrote:
> On 05/09/2017 07:54 PM, cooloutac wrote:
>> On Tuesday, May 9, 2017 at 1:40:03 AM UTC-4, Andrew David Wong 
>> wrote:
>> 
>> Why? No need to encrypt the database file if the whole VM is 
>> encrypted. Also, if your database file doesn't use authenticated
>>  encryption, that's another thing to worry about. You may also 
>> worry about file-level metadata leakage.
>> 
>>> the database file is automatically encrypted. I just feel like 
>>> vault
> more likely compromised then the file if something is. but I could 
> be wrong. plus way less space. > > I think when we have paranoid 
> mode it will be better. > Backing up using anything like
> qvm-backup is always going to be much slower — and require the VM
> to be off —than any file-level alternative. Plus, if you need to
> sync your keyring between different devices, that eliminates the
> possibility of using qvm-backup in any efficient way.
> 

I agree that qvm-backup is slower, bigger, and less efficient than
file-level backup/syncing methods, but the tradeoffs are pretty
reasonable for a lot of use cases. Since I can just start a script and
walk away, it doesn't really matter to me whether it takes a few extra
minutes while I'm not there.

Don't get me wrong, though. I'd love to see a more efficient solution
that combines some of the best effects of both (e.g., incremental
backup).

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZF2XJAAoJENtN07w5UDAwUL0P/i9TXn0XxN7U65Y8lmquVo2Y
29iUCeW6sfaXbBBsMmiO+Ptf400QAO4RQa0Yylrg9StROOScsXubbLo1ZBh9alsC
ohGxBIDaG0dUsaAqKnlHLBmyieYBZIbZ5qf93PwvldIJG1M8s8dfuvtKQFZa1zrF
E4ALvxs0qwkcO4zsXIrom2IwXLU5+DVov2N02qegxr3GBYTQEpq+k+meSNNEbpQi
N2CE+LU1oSSK7nI9zITVsICLJ3gROboh/h3EtgqS0BfmXLkHAgZ6EBMvw8KzkodM
HzJjRGfLKNo+kmJ/A+vdwfqO8FSKjBiC9cj2+vMrxmPbJYyc56pI7ircOVuTZETX
7COnAXveluyiej3qyXVUwgTaA6a1TAmaUJntEdtS1MWKlJ97nawPrPQFvGlh5IVg
yNZE3VphAbwJqyTFNI4ls5VrpVXgQ69lplcZFjWfe1OUqdWkiNwpBFi6yyWsRIq8
ZrBpVkNhlQe9Il2gX0iAsyKjjMgQxRPI50rNQ2EykLOeieRmJVv/cYkd7zOLU1t4
Lc760+odYqNW/ldXd1ndQIdhmlGbxOIc3ripLfklitlQtnYubAC28IYvp5jN30M/
4N7/N1HILAn8ssK4PTQycTPHNDLATG2wevvsM2K/ULjDHSrdjl2ir+Xn0VATjWXR
3fL65dRUR+U8aUYzCDp6
=3/mC
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/eae91840-9d76-4a38-f923-ff3c5b668e70%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-12 06:53, Holger Levsen wrote:
> On Sun, May 07, 2017 at 12:23:47PM -0500, Andrew David Wong wrote:
>> 1. LUKS passphrase 2. Backup passphrase 3. Screen locker
>> passphrase Managing these three allows me to have an arbitrary
>> number of additional secrets in VMs without having to remember
>> anything else.
> 
> you really dont protect your gpg key with a passphrase??
> 

See: https://www.qubes-os.org/doc/split-gpg/

> and I assume you dont change the backup passphrase, because it
> needs to be high entropy, despite being visible with "ps fax"…
> 

Why is that a problem? It's only visible in dom0. If an attacker is in
dom0, it's already game over.

Tracked here, BTW:
https://github.com/QubesOS/qubes-issues/issues/1582

> I'm really not convinced this is a good setup, though of cause
> everything depends on the thread model! :-)
> 

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZF2SYAAoJENtN07w5UDAwMf0P/1YRlQPo/C0/eUd1M/ZOjk+c
0niJvtOEQkJoo4QrOZqdJ/9CZa3KUYKlH6ktkzbg4TjrODgqRiffPhtTYmTmfxTL
8CMdD4HWSvXVLt4SEJYuX81NwS0BioHqk0lY5bA9dQCDFdb29O4cUvUX43h1+0Je
hQSK4Rcytp8vjelGSPTT9qDzMuVHu6tpUgYIYTwGPS67aeeVvnlT6VY6Q+QfUGr6
+GQWvGkspxTRg3ASml1UtMd4vglxkKvlwmVJTziY0IE/TN50xiTaXIVAvgyVQnf/
hn2gAyn2o5+ciP7Od18XhfXIlqcb8+R5Vn2nvyXtLAJP0zouNGtGDUiACAXXVFJ2
gwpP1yD/e0nmqsUMVYdG2GtuLKF1Y0fxtHswQpnHiPKP6N6hwcqmuRhgnN/GRlGS
jmcQWEETw3zEa/CwOiSyJhwVLxx8nHEjxTRnci2P7L9DHiXJTG+isZQ0innHSXV7
kHmv12Bf4pnpyxilpgDfJH7epZYuMWK1cUwDBDzEOvaH3ScHQyxU9rRd8sDYKlZO
28aK9NgT0xo6DTjgcLh+4z6ph5phrH2pRzrdniyCAyP79nDI4wBC3/bj/Q68aCij
q7jiQH5KxKxXNlr06DhNS4nGK0ugok0q1J5GFZtp4RIrktfopkEF8H4rrn2efoxa
vx2NzWi4br54hWbhS0RF
=Vyk2
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0db7489c-30ab-d905-92dd-e749c56bdc7a%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-09 14:54, cooloutac wrote:
> On Tuesday, May 9, 2017 at 1:40:03 AM UTC-4, Andrew David Wong 
> wrote: On 2017-05-08 23:47, cooloutac wrote:
 On Tuesday, May 9, 2017 at 12:47:11 AM UTC-4, cooloutac 
 wrote:
> On Sunday, May 7, 2017 at 12:33:54 PM UTC-4, 
> nick...@kulinacs.com wrote:
>> On May 7, 2017 10:39:22 AM CDT, Andrew David Wong 
>>  wrote:
 On 2017-05-07 10:32, nickl...@kulinacs.com wrote:
> On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
>  wrote: On 2017-05-07 10:10, 
> nickl...@kulinacs.com wrote:
 What benefit does this have over simply
 ysing qubes-split-gpg-client-wrapper, like
 done here:
 https://github.com/kulinacs/pass-qubes It
 seems like a lot of overhead for not a lot of
 gain.
 
 On May 7, 2017 9:50:26 AM CDT, "Manuel Amador
 (Rudd-O)"  wrote:
> Building on the excellent pass 
> (https://passwordstore.org), it gives me 
> great pleasure to announce the initial 
> release of qubes-pass — an inter-VM 
> password manager and store for Qubes OS.
> 
> Check it out here!
> 
> https://github.com/Rudd-O/qubes-pass
> 
> 
> What are the advantages of either of these over the
> traditional Qubes model of having a normal password
> manager in a vault VM and using the inter-VM
> clipboard to copy/paste passwords out of it?
> 
> 
> I prefer Pass because it uses GPG for encryption, 
> meaning I can manage fewer secrets over all (as it 
> backends into my normal GPG key) and then track my 
> password files in git. To do this with the 
> traditional Keepass method, you either need to
> back up the password database somewhere secure or 
> remember another password for it.
> 
 
 Why not just back up the entire vault with qvm-backup?
 
>> 
>> Git has less storage overhead (as you're backing up a 
>> bunch of text files, not an entire VM), allows proper 
>> versioning, so it is trivial to see your passwords at a 
>> point in time, and can be used cross platform if you 
>> chose to keep your GPG key on another system.
> 
> I just back up the database file. its encrypted.
 
 I don't think backing up the whole vault is a good idea if 
 you don't have to.
 
> 
> Why? No need to encrypt the database file if the whole VM is 
> encrypted. Also, if your database file doesn't use authenticated 
> encryption, that's another thing to worry about. You may also worry
> about file-level metadata leakage.
> 
> 
> the database file is automatically encrypted.  I just feel like 
> vault more likely compromised then the file if something is.  but
> I could be wrong.  plus way less space.
> 

I don't see any basis for that reasoning. The files in an AppVM are
only as safe as the AppVM itself, unless the VM is used only for
storage or something.

If the vault VM is compromised, then the encrypted database file in
the vault is only safe as long as it remains encrypted. An attacker
who can compromise your vault can set a trigger that waits for you to
decrypt the database the next time you want to use it, then grab the
passphrase, decryption key, or the whole decrypted database.

> I think when we have paranoid mode it will be better.
> 

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZF2N9AAoJENtN07w5UDAw8goP/itJWd/QiGchOPYmavzXB+AS
HKycQy2y4lvqHjl1cltPXP0unThvoK8BSgCWdm2wRbj7T/Lc5EG7mtCScXyZP6uc
ouFTMPjyjYECmINWaU/rNEOJRy5XR6q3AcVeObBRZxdst59g9GNtCXAgu47U7WjJ
8u+9wqEO1PD7Oo+ZlFZ971JMsYluU7uxHwqDYqFabPc+FvkD5hEIBM3tfXvmbJuo
qlhpQpVyudYcgCs8Xtt6e1P1GcSc0pXT03nd7mw8QeMsZq3Ua6x8tOEtAnl93pba
LXWoHEmLGg5BbYbkbXMeZYYTyM+e5f4MN78DkolaqzwD73IVITg+8ctJD+rNSgIB
dJhNeAVtsddyQ+7+3IHxsOSgVvnBANoC2e7iBLkVxd0zqKnT6hdbSNQPfrftIQzV
uATOBVgCy16/xjgOeqPENAbT9ElZfgIyEhN3HPQsOPhM0ASSdSgx+fHNH9RY/dZ7
aoWbILGJRL52J1R4koumXvbaWSHLo2HAIv1xljstedltDt4jyjDQtRfJ2Zbf7jK1
hGXZcsUtyZHyZklHyYb8ZiQa6gbGj3KBHQaz91TznTdgIV/G42iL+GFb1jej8TIS
2mBALx5WL82jo5Nmb/4GJ/5nb3ShBAeOm9YkfctQX0fXd3lweZ7h9i79rAocIrZ9
o87ju6uck1ri3q3q01Pt
=oKxB
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ef317c14-5796-bba4-19b1-a123abe9d2a1%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Manuel Amador (Rudd-O)]

On 05/12/2017 03:02 PM, Tom Hutchinson wrote:
> Thanks for the contribution Manuel. I'll check it out.

My pleasure :-)

Agreed about the passwords thing!

-- 
Rudd-O
http://rudd-o.com/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b2aed9aa-0147-d008-ce2a-64e0d087afe2%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Manuel Amador (Rudd-O)]

On 05/12/2017 11:53 AM, Holger Levsen wrote:
> On Sun, May 07, 2017 at 12:23:47PM -0500, Andrew David Wong wrote:
>> 1. LUKS passphrase
>> 2. Backup passphrase
>> 3. Screen locker passphrase
>> Managing these three allows me to have an arbitrary number of
>> additional secrets in VMs without having to remember anything else.
> you really dont protect your gpg key with a passphrase??

qubes-pass will prompt you for your GPG key passphrase using the GPG
agent, just as you'd expect it.

>
> and I assume you dont change the backup passphrase, because it needs to be 
> high
> entropy, despite being visible with "ps fax"…
>
> I'm really not convinced this is a good setup, though of cause everything
> depends on the thread model! :-)

Do please present an attack model and I can then reason with you whether
it is covered by the setup or not.

Note that the qubes-pass setup is *exactly the same* as the Qubes GPG
model, and intended to protect against the same attacks.

-- 
Rudd-O
http://rudd-o.com/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e2b2bc61-1ffc-9945-5f62-c8f49f49889b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Friday, May 12, 2017 at 11:03:01 AM UTC-4, Tom Hutchinson wrote:
> Thanks for the contribution Manuel. I'll check it out.
> 
> I can't wait for us all to get rid of passwords. They are garbage
> technology and garbage security. I don't know - maybe that's just me.
> 
> Cheers,
> 
> Tom
> 
> On Fri, May 12, 2017 at 7:53 AM, Holger Levsen  wrote:
> > On Sun, May 07, 2017 at 12:23:47PM -0500, Andrew David Wong wrote:
> >> 1. LUKS passphrase
> >> 2. Backup passphrase
> >> 3. Screen locker passphrase
> >> Managing these three allows me to have an arbitrary number of
> >> additional secrets in VMs without having to remember anything else.
> >
> > you really dont protect your gpg key with a passphrase??
> >
> > and I assume you dont change the backup passphrase, because it needs to be 
> > high
> > entropy, despite being visible with "ps fax"…
> >
> > I'm really not convinced this is a good setup, though of cause everything
> > depends on the thread model! :-)
> >
> >
> > --
> > cheers,
> > Holger
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "qubes-users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to qubes-users+unsubscr...@googlegroups.com.
> > To post to this group, send email to qubes-users@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/qubes-users/20170512115330.GC27029%40layer-acht.org.
> > For more options, visit https://groups.google.com/d/optout.

Yes I agree.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/63019060-3662-4eb4-8341-ba37c75211d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Friday, May 12, 2017 at 7:53:40 AM UTC-4, Holger Levsen wrote:
> On Sun, May 07, 2017 at 12:23:47PM -0500, Andrew David Wong wrote:
> > 1. LUKS passphrase
> > 2. Backup passphrase
> > 3. Screen locker passphrase
> > Managing these three allows me to have an arbitrary number of
> > additional secrets in VMs without having to remember anything else.
> 
> you really dont protect your gpg key with a passphrase??
> 
> and I assume you dont change the backup passphrase, because it needs to be 
> high
> entropy, despite being visible with "ps fax"…
> 
> I'm really not convinced this is a good setup, though of cause everything
> depends on the thread model! :-)
> 
> 
> -- 
> cheers,
>   Holger

I assume his Gpg key would be in one of those 3. Its all we got We basically 
have no choice.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/40e3c9de-88f2-40f1-a909-ab63cd60997f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Tom Hutchinson]

Thanks for the contribution Manuel. I'll check it out.

I can't wait for us all to get rid of passwords. They are garbage
technology and garbage security. I don't know - maybe that's just me.

Cheers,

Tom

On Fri, May 12, 2017 at 7:53 AM, Holger Levsen  wrote:
> On Sun, May 07, 2017 at 12:23:47PM -0500, Andrew David Wong wrote:
>> 1. LUKS passphrase
>> 2. Backup passphrase
>> 3. Screen locker passphrase
>> Managing these three allows me to have an arbitrary number of
>> additional secrets in VMs without having to remember anything else.
>
> you really dont protect your gpg key with a passphrase??
>
> and I assume you dont change the backup passphrase, because it needs to be 
> high
> entropy, despite being visible with "ps fax"…
>
> I'm really not convinced this is a good setup, though of cause everything
> depends on the thread model! :-)
>
>
> --
> cheers,
> Holger
>
> --
> You received this message because you are subscribed to the Google Groups 
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/20170512115330.GC27029%40layer-acht.org.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CALvEeygEmK%2BbooEqJh%2BwRzKZJ2z1xmguywCUe%2BDbwEQhJQ_voA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Holger Levsen]

On Sun, May 07, 2017 at 12:23:47PM -0500, Andrew David Wong wrote:
> 1. LUKS passphrase
> 2. Backup passphrase
> 3. Screen locker passphrase
> Managing these three allows me to have an arbitrary number of
> additional secrets in VMs without having to remember anything else.

you really dont protect your gpg key with a passphrase??

and I assume you dont change the backup passphrase, because it needs to be high
entropy, despite being visible with "ps fax"…

I'm really not convinced this is a good setup, though of cause everything
depends on the thread model! :-)


-- 
cheers,
Holger

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170512115330.GC27029%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Manuel Amador (Rudd-O)]

On 05/09/2017 07:54 PM, cooloutac wrote:
> On Tuesday, May 9, 2017 at 1:40:03 AM UTC-4, Andrew David Wong wrote:
>
> Why? No need to encrypt the database file if the whole VM is
> encrypted. Also, if your database file doesn't use authenticated
> encryption, that's another thing to worry about. You may also worry
> about file-level metadata leakage.
>
> > the database file is automatically encrypted. I just feel like vault
more likely compromised then the file if something is. but I could be
wrong. plus way less space. > > I think when we have paranoid mode it
will be better. >
Backing up using anything like qvm-backup is always going to be much
slower — and require the VM to be off —than any file-level alternative. 
Plus, if you need to sync your keyring between different devices, that
eliminates the possibility of using qvm-backup in any efficient way.

-- 
Rudd-O
http://rudd-o.com/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1baae202-000c-1ae1-9b09-c2e272ed4b85%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Tuesday, May 9, 2017 at 1:40:03 AM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-05-08 23:47, cooloutac wrote:
> > On Tuesday, May 9, 2017 at 12:47:11 AM UTC-4, cooloutac wrote:
> >> On Sunday, May 7, 2017 at 12:33:54 PM UTC-4, nick...@kulinacs.com
> >> wrote:
> >>> On May 7, 2017 10:39:22 AM CDT, Andrew David Wong
> >>>  wrote:
> > On 2017-05-07 10:32, nickl...@kulinacs.com wrote:
> >> On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
> >>  wrote: On 2017-05-07 10:10, 
> >> nickl...@kulinacs.com wrote:
> > What benefit does this have over simply ysing 
> > qubes-split-gpg-client-wrapper, like done here: 
> > https://github.com/kulinacs/pass-qubes It seems
> > like a lot of overhead for not a lot of gain.
> > 
> > On May 7, 2017 9:50:26 AM CDT, "Manuel Amador
> > (Rudd-O)"  wrote:
> >> Building on the excellent pass
> >> (https://passwordstore.org), it gives me great
> >> pleasure to announce the initial release of
> >> qubes-pass — an inter-VM password manager and
> >> store for Qubes OS.
> >> 
> >> Check it out here!
> >> 
> >> https://github.com/Rudd-O/qubes-pass
> >> 
> >> 
> >> What are the advantages of either of these over the
> >> traditional Qubes model of having a normal password
> >> manager in a vault VM and using the inter-VM clipboard to
> >> copy/paste passwords out of it?
> >> 
> >> 
> >> I prefer Pass because it uses GPG for encryption, meaning
> >> I can manage fewer secrets over all (as it backends into
> >> my normal GPG key) and then track my password files in
> >> git. To do this with the traditional Keepass method, you
> >> either need to back up the password database somewhere
> >> secure or remember another password for it.
> >> 
> > 
> > Why not just back up the entire vault with qvm-backup?
> > 
> >>> 
> >>> Git has less storage overhead (as you're backing up a bunch of
> >>> text files, not an entire VM), allows proper versioning, so it
> >>> is trivial to see your passwords at a point in time, and can be
> >>> used cross platform if you chose to keep your GPG key on
> >>> another system.
> >> 
> >> I just back up the database file. its encrypted.
> > 
> > I don't think backing up the whole vault is a good idea if you
> > don't have to.
> > 
> 
> Why? No need to encrypt the database file if the whole VM is
> encrypted. Also, if your database file doesn't use authenticated
> encryption, that's another thing to worry about. You may also worry
> about file-level metadata leakage.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJZEVYkAAoJENtN07w5UDAwuAUQAMxJvs6Z5SK+2jJ7AaKPUnSQ
> 9sj2z7S4XzteTNRmV6e3c8MIiMuVUuO491B9/1p+s3ndsIZjQV2bK8gKwhsEvcJQ
> /jGoRpq+cTsYN7PCup17oP+hXqZMO6w23ehgJa5KTDnHl8DzQWoaG3QqCmkFSPL3
> W2QdJ2wYgH14xlIwwqsDdsawZsjHs18OLO8u5tsaUqYZZDkhKN9SIABXjCfm+4bN
> za2xxcQlXX0HLEtGqHSRlBt36AKM0IYjQDh8ArM109E58uf+QWI/rXYe0U1bIRxR
> 7VyDSnNIH9qJ5GP25ZnTUu0czPTA3sh6Dr0y2gLfbvoEUmZfNRDX7IrSyVsG7q6P
> +GKrr10Cawym8tLr/v3pSZ2DLRG+3Am/zsEOyGUY3Cg5xUG0lSyVJp8WIb2xGtND
> o9mkaMaFV+iFFIxPzld5Wc9nwy7h+d3eF0b/fX32PsI+CpIVudOOpwibtPh1pte6
> VMgclD00eQnabTjT3Egw6+8EvBsvDJc4smCJ/blWWRWgirRgdPwATlJ7CwxEICtW
> 8bwJTMXQsIeHqduEcBZO1qnI+sqaUF86KME2p6leD51qb+BUC/463l5En8terTe+
> auIKVGdzcF5QRXihEMdJSDGrUgTsSUxoAdLFDEZGLWa1po62++3C0225DVvgOpp+
> 03AmrJMi0eyaJ0ndGJG+
> =soty
> -END PGP SIGNATURE-

the database file is automatically encrypted.  I just feel like vault more 
likely compromised then the file if something is.  but I could be wrong.  plus 
way less space.

I think when we have paranoid mode it will be better.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/72935423-38cb-485f-92cc-9fe2dfd79bef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-08 23:47, cooloutac wrote:
> On Tuesday, May 9, 2017 at 12:47:11 AM UTC-4, cooloutac wrote:
>> On Sunday, May 7, 2017 at 12:33:54 PM UTC-4, nick...@kulinacs.com
>> wrote:
>>> On May 7, 2017 10:39:22 AM CDT, Andrew David Wong
>>>  wrote:
> On 2017-05-07 10:32, nickl...@kulinacs.com wrote:
>> On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
>>  wrote: On 2017-05-07 10:10, 
>> nickl...@kulinacs.com wrote:
> What benefit does this have over simply ysing 
> qubes-split-gpg-client-wrapper, like done here: 
> https://github.com/kulinacs/pass-qubes It seems
> like a lot of overhead for not a lot of gain.
> 
> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador
> (Rudd-O)"  wrote:
>> Building on the excellent pass
>> (https://passwordstore.org), it gives me great
>> pleasure to announce the initial release of
>> qubes-pass — an inter-VM password manager and
>> store for Qubes OS.
>> 
>> Check it out here!
>> 
>> https://github.com/Rudd-O/qubes-pass
>> 
>> 
>> What are the advantages of either of these over the
>> traditional Qubes model of having a normal password
>> manager in a vault VM and using the inter-VM clipboard to
>> copy/paste passwords out of it?
>> 
>> 
>> I prefer Pass because it uses GPG for encryption, meaning
>> I can manage fewer secrets over all (as it backends into
>> my normal GPG key) and then track my password files in
>> git. To do this with the traditional Keepass method, you
>> either need to back up the password database somewhere
>> secure or remember another password for it.
>> 
> 
> Why not just back up the entire vault with qvm-backup?
> 
>>> 
>>> Git has less storage overhead (as you're backing up a bunch of
>>> text files, not an entire VM), allows proper versioning, so it
>>> is trivial to see your passwords at a point in time, and can be
>>> used cross platform if you chose to keep your GPG key on
>>> another system.
>> 
>> I just back up the database file. its encrypted.
> 
> I don't think backing up the whole vault is a good idea if you
> don't have to.
> 

Why? No need to encrypt the database file if the whole VM is
encrypted. Also, if your database file doesn't use authenticated
encryption, that's another thing to worry about. You may also worry
about file-level metadata leakage.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZEVYkAAoJENtN07w5UDAwuAUQAMxJvs6Z5SK+2jJ7AaKPUnSQ
9sj2z7S4XzteTNRmV6e3c8MIiMuVUuO491B9/1p+s3ndsIZjQV2bK8gKwhsEvcJQ
/jGoRpq+cTsYN7PCup17oP+hXqZMO6w23ehgJa5KTDnHl8DzQWoaG3QqCmkFSPL3
W2QdJ2wYgH14xlIwwqsDdsawZsjHs18OLO8u5tsaUqYZZDkhKN9SIABXjCfm+4bN
za2xxcQlXX0HLEtGqHSRlBt36AKM0IYjQDh8ArM109E58uf+QWI/rXYe0U1bIRxR
7VyDSnNIH9qJ5GP25ZnTUu0czPTA3sh6Dr0y2gLfbvoEUmZfNRDX7IrSyVsG7q6P
+GKrr10Cawym8tLr/v3pSZ2DLRG+3Am/zsEOyGUY3Cg5xUG0lSyVJp8WIb2xGtND
o9mkaMaFV+iFFIxPzld5Wc9nwy7h+d3eF0b/fX32PsI+CpIVudOOpwibtPh1pte6
VMgclD00eQnabTjT3Egw6+8EvBsvDJc4smCJ/blWWRWgirRgdPwATlJ7CwxEICtW
8bwJTMXQsIeHqduEcBZO1qnI+sqaUF86KME2p6leD51qb+BUC/463l5En8terTe+
auIKVGdzcF5QRXihEMdJSDGrUgTsSUxoAdLFDEZGLWa1po62++3C0225DVvgOpp+
03AmrJMi0eyaJ0ndGJG+
=soty
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/17b4002e-ec43-1acd-ad8e-9b26af3e2a81%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Tuesday, May 9, 2017 at 12:47:11 AM UTC-4, cooloutac wrote:
> On Sunday, May 7, 2017 at 12:33:54 PM UTC-4, nick...@kulinacs.com wrote:
> > On May 7, 2017 10:39:22 AM CDT, Andrew David Wong  wrote:
> > >-BEGIN PGP SIGNED MESSAGE-
> > >Hash: SHA512
> > >
> > >On 2017-05-07 10:32, nickl...@kulinacs.com wrote:
> > >> On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
> > >>  wrote: On 2017-05-07 10:10, 
> > >> nickl...@kulinacs.com wrote:
> > > What benefit does this have over simply ysing 
> > > qubes-split-gpg-client-wrapper, like done here: 
> > > https://github.com/kulinacs/pass-qubes It seems like a lot
> > > of overhead for not a lot of gain.
> > > 
> > > On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)" 
> > >  wrote:
> > >> Building on the excellent pass (https://passwordstore.org),
> > >> it gives me great pleasure to announce the initial release
> > >> of qubes-pass — an inter-VM password manager and store for
> > >> Qubes OS.
> > >> 
> > >> Check it out here!
> > >> 
> > >> https://github.com/Rudd-O/qubes-pass
> > >> 
> > >> 
> > >> What are the advantages of either of these over the traditional 
> > >> Qubes model of having a normal password manager in a vault VM and 
> > >> using the inter-VM clipboard to copy/paste passwords out of it?
> > >> 
> > >> 
> > >> I prefer Pass because it uses GPG for encryption, meaning I can 
> > >> manage fewer secrets over all (as it backends into my normal GPG 
> > >> key) and then track my password files in git. To do this with the 
> > >> traditional Keepass method, you either need to back up the password
> > >> database somewhere secure or remember another password for it.
> > >> 
> > >
> > >Why not just back up the entire vault with qvm-backup?
> > >
> > >- -- 
> > >Andrew David Wong (Axon)
> > >Community Manager, Qubes OS
> > >https://www.qubes-os.org
> > >-BEGIN PGP SIGNATURE-
> > >
> > >iQIcBAEBCgAGBQJZDz+kAAoJENtN07w5UDAwVdEQAKyEUNffYrCLsTK8TyRvWnyi
> > >3dz15oDFHAL/PXkUHptcn4NJfU3BrmPBcf8DaBM2ROlXVJQayYZq9QwE1wlftxjr
> > >+ZblvNOuYbc/+FGxGNpqimc7jSC5TSaaduMW47THp66xemYH55pVChD2WT3X/dk4
> > >gn51SLYKE7tixnsOaqNEQSawpwbDsVaL4hLDgV4NLDKeZTbhLLxLbFlvikoMsUxY
> > >BXj19mfje2oJrDAXEDUtDK9qq8tOjttK4EomVG0HQVinyhpKiLn/Nil91xQnKvES
> > >H8QG9sEUUEGs0/GsYsXIkb3VJqRdkns5A1Cp5FR3/WTiIxBARfewXY3klQKO0UFj
> > >zTovVZ3OgjuqmqDlkLLGRI5bn1NHZ2k9IFly4+8VUYXPOVBNdkKmIpqS3x0EPhuO
> > >rFZmg/1OYHeT3FLt6WwDJilNGzN2I/FByx7AbwiEHGgspQYVviDRha2n6eCDGh0R
> > >uIZ3/8iYj+QA+glXZFGj5ghIKjBiA6rcn7vTh7/r+9rGaOCCDCGY6L4ZrgL8Ao76
> > >VOw1MnnzVHIOGjGQ0RacDN9qZ8D/YTy2BqZVUdF1RXoBb77LQgAfVfVAeIjzuWg7
> > >KIlXI9ScIFqEbbcxC7w4SC1LHbEcET81q5B0tNzJUJ+QL0/CZQ9avrPHBOq9kVRs
> > >NK8zRvknFnPargpog2UK
> > >=vzjL
> > >-END PGP SIGNATURE-
> > 
> > Git has less storage overhead (as you're backing up a bunch of text files, 
> > not an entire VM), allows proper versioning, so it is trivial to see your 
> > passwords at a point in time, and can be used cross platform if you chose 
> > to keep your GPG key on another system.
> 
> I just back up the database file. its encrypted.

I don't think backing up the whole vault is a good idea if you don't have to.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/dc2b9af1-1599-48ca-91e5-969627f9ca15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[cooloutac]

On Sunday, May 7, 2017 at 12:33:54 PM UTC-4, nick...@kulinacs.com wrote:
> On May 7, 2017 10:39:22 AM CDT, Andrew David Wong  wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA512
> >
> >On 2017-05-07 10:32, nickl...@kulinacs.com wrote:
> >> On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
> >>  wrote: On 2017-05-07 10:10, 
> >> nickl...@kulinacs.com wrote:
> > What benefit does this have over simply ysing 
> > qubes-split-gpg-client-wrapper, like done here: 
> > https://github.com/kulinacs/pass-qubes It seems like a lot
> > of overhead for not a lot of gain.
> > 
> > On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)" 
> >  wrote:
> >> Building on the excellent pass (https://passwordstore.org),
> >> it gives me great pleasure to announce the initial release
> >> of qubes-pass — an inter-VM password manager and store for
> >> Qubes OS.
> >> 
> >> Check it out here!
> >> 
> >> https://github.com/Rudd-O/qubes-pass
> >> 
> >> 
> >> What are the advantages of either of these over the traditional 
> >> Qubes model of having a normal password manager in a vault VM and 
> >> using the inter-VM clipboard to copy/paste passwords out of it?
> >> 
> >> 
> >> I prefer Pass because it uses GPG for encryption, meaning I can 
> >> manage fewer secrets over all (as it backends into my normal GPG 
> >> key) and then track my password files in git. To do this with the 
> >> traditional Keepass method, you either need to back up the password
> >> database somewhere secure or remember another password for it.
> >> 
> >
> >Why not just back up the entire vault with qvm-backup?
> >
> >- -- 
> >Andrew David Wong (Axon)
> >Community Manager, Qubes OS
> >https://www.qubes-os.org
> >-BEGIN PGP SIGNATURE-
> >
> >iQIcBAEBCgAGBQJZDz+kAAoJENtN07w5UDAwVdEQAKyEUNffYrCLsTK8TyRvWnyi
> >3dz15oDFHAL/PXkUHptcn4NJfU3BrmPBcf8DaBM2ROlXVJQayYZq9QwE1wlftxjr
> >+ZblvNOuYbc/+FGxGNpqimc7jSC5TSaaduMW47THp66xemYH55pVChD2WT3X/dk4
> >gn51SLYKE7tixnsOaqNEQSawpwbDsVaL4hLDgV4NLDKeZTbhLLxLbFlvikoMsUxY
> >BXj19mfje2oJrDAXEDUtDK9qq8tOjttK4EomVG0HQVinyhpKiLn/Nil91xQnKvES
> >H8QG9sEUUEGs0/GsYsXIkb3VJqRdkns5A1Cp5FR3/WTiIxBARfewXY3klQKO0UFj
> >zTovVZ3OgjuqmqDlkLLGRI5bn1NHZ2k9IFly4+8VUYXPOVBNdkKmIpqS3x0EPhuO
> >rFZmg/1OYHeT3FLt6WwDJilNGzN2I/FByx7AbwiEHGgspQYVviDRha2n6eCDGh0R
> >uIZ3/8iYj+QA+glXZFGj5ghIKjBiA6rcn7vTh7/r+9rGaOCCDCGY6L4ZrgL8Ao76
> >VOw1MnnzVHIOGjGQ0RacDN9qZ8D/YTy2BqZVUdF1RXoBb77LQgAfVfVAeIjzuWg7
> >KIlXI9ScIFqEbbcxC7w4SC1LHbEcET81q5B0tNzJUJ+QL0/CZQ9avrPHBOq9kVRs
> >NK8zRvknFnPargpog2UK
> >=vzjL
> >-END PGP SIGNATURE-
> 
> Git has less storage overhead (as you're backing up a bunch of text files, 
> not an entire VM), allows proper versioning, so it is trivial to see your 
> passwords at a point in time, and can be used cross platform if you chose to 
> keep your GPG key on another system.

I just back up the database file. its encrypted.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/40489a94-f31d-40be-b221-e9cd0e38748b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Manuel Amador (Rudd-O)]

On 05/07/2017 05:23 PM, Andrew David Wong wrote:
>
> I prefer the security of qvm-backup[-restore], since it allows me to
> keep the vault and its contents permanently offline. The entire VM is
> BZIP compressed, AES-256 encrypted, and HMAC-SHA512 authenticated. The
> integrity verification, authentication, and decryption all happen at
> the dom0 level. The backup is tiny, so the storage overhead is
> inconsequential, and there's no need to worry about file-level
> metadata leakage or the backup file itself being used as an attack
> vector. KeePassX has sufficient built-in versioning for me, and it's
> easy enough to sync Qubes backups across machines with simple scripts.

Git push takes 5 seconds.

qvm-backup requires anywhere between minutes and many hours. 
Additionally, it requires the target VM be off.

Weekly backups are served okay by qvm-backup (I say "okay" because I
have a borg backup setup on my Qubes OS system, and it's far more usable
and performant than qvm-backup).  Git push is much better suited to,
say, syncing your keyring to other systems.

-- 
Rudd-O
http://rudd-o.com/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6da3112a-4873-bc02-4cac-34bf329c4a63%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Manuel Amador (Rudd-O)]

On 05/07/2017 03:23 PM, Andrew David Wong wrote:
> On 2017-05-07 10:10, nickl...@kulinacs.com wrote:
> > What benefit does this have over simply ysing
> > qubes-split-gpg-client-wrapper, like done here:
> > https://github.com/kulinacs/pass-qubes It seems like a lot of
> > overhead for not a lot of gain.
>
> > On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
> >  wrote:
> >> Building on the excellent pass (https://passwordstore.org), it
> >> gives me great pleasure to announce the initial release of
> >> qubes-pass — an inter-VM password manager and store for Qubes
> >> OS.
> >>
> >> Check it out here!
> >>
> >> https://github.com/Rudd-O/qubes-pass
> >>
>
> What are the advantages of either of these over the traditional Qubes
> model of having a normal password manager in a vault VM and using the
> inter-VM clipboard to copy/paste passwords out of it?
>

These programs do not require user interaction as long as the policies
are properly configured.  Thus, they are extremely useful for batch
processes or system orchestration purposes.

-- 
Rudd-O
http://rudd-o.com/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e8f22638-8944-b0c4-57f6-e962350fdb8b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Manuel Amador (Rudd-O)]

On 05/07/2017 03:10 PM, nickl...@kulinacs.com wrote:
> What benefit does this have over simply ysing
> qubes-split-gpg-client-wrapper, like done here:
> https://github.com/kulinacs/pass-qubes
> It seems like a lot of overhead for not a lot of gain.

 1. The actual store is stored in a separate VM.  It is never decrypted
in the VM you manage the passwords from.
 2. You do not need to set up your own GPG key, as `qvm-pass init` does
it for you.
 3. There are two different services — one for read-only access and one
for read-write.
 4. There is a get-or-generate feature which is useful for stuff like
https://github.com/Rudd-O/ansible-qubes/tree/master/lookup_plugins


>
> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
>  wrote:
>
> Building on the excellent pass (https://passwordstore.org), it gives me
> great pleasure to announce the initial release of qubes-pass — an
> inter-VM password manager and store for Qubes OS.
>
> Check it out here!
>
> https://github.com/Rudd-O/qubes-pass
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity. --
> You received this message because you are subscribed to the Google
> Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to qubes-users+unsubscr...@googlegroups.com
> .
> To post to this group, send email to qubes-users@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/0A765A21-F411-4015-B9C2-790508B1A0C1%40kulinacs.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
Rudd-O
http://rudd-o.com/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c8fc3adc-5fce-46de-05e5-d0aa2946ed6b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-07 12:23, Andrew David Wong wrote:
> On 2017-05-07 11:33, nickl...@kulinacs.com wrote:
>> On May 7, 2017 10:39:22 AM CDT, Andrew David Wong
>>  wrote: On 2017-05-07 10:32,
>> nickl...@kulinacs.com wrote:
> On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
>  wrote: On 2017-05-07 10:10, 
> nickl...@kulinacs.com wrote:
 What benefit does this have over simply ysing 
 qubes-split-gpg-client-wrapper, like done here: 
 https://github.com/kulinacs/pass-qubes It seems like a
 lot of overhead for not a lot of gain.

 On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
   wrote:
> Building on the excellent pass
> (https://passwordstore.org), it gives me great
> pleasure to announce the initial release of
> qubes-pass — an inter-VM password manager and store
> for Qubes OS.
>
> Check it out here!
>
> https://github.com/Rudd-O/qubes-pass
>
>
> What are the advantages of either of these over the
> traditional Qubes model of having a normal password manager
> in a vault VM and using the inter-VM clipboard to copy/paste
> passwords out of it?
>
>
> I prefer Pass because it uses GPG for encryption, meaning I
> can manage fewer secrets over all (as it backends into my
> normal GPG key) and then track my password files in git. To
> do this with the traditional Keepass method, you either need
> to back up the password database somewhere secure or remember
> another password for it.
>
> 
>> Why not just back up the entire vault with qvm-backup?
> 
> 
>> Git has less storage overhead (as you're backing up a bunch of text
>> files, not an entire VM), allows proper versioning, so it is
>> trivial to see your passwords at a point in time, and can be used
>> cross platform if you chose to keep your GPG key on another
>> system.
> 
> 
> I prefer the security of qvm-backup[-restore], since it allows me to
> keep the vault and its contents permanently offline. The entire VM is
> BZIP compressed, AES-256 encrypted, and HMAC-SHA512 authenticated. The
> integrity verification, authentication, and decryption all happen at
> the dom0 level. The backup is tiny, so the storage overhead is
> inconsequential, and there's no need to worry about file-level
> metadata leakage or the backup file itself being used as an attack
> vector. KeePassX has sufficient built-in versioning for me, and it's
> easy enough to sync Qubes backups across machines with simple scripts.
> 
> With this setup, considerations like "managing fewer secrets" seem out
> of place. I only have to manage three secrets:
> 
> 1. LUKS passphrase
> 2. Backup passphrase
> 3. Screen locker passphrase
> 

I should add that using the same passphrase for (some subset of) 1, 2,
and 3 would arguably be a very reasonable trade-off between security and
convenience for most users (i.e., a likely negligible drop in security
for a significant gain in the form of having to remember fewer things).

> Managing these three allows me to have an arbitrary number of
> additional secrets in VMs without having to remember anything else. I
> can't replace 1, 2, or 3 with my PGP key(s), because my PGP key(s) are
> inside my PGP VM, which I can't access except via 1, 2, or 3. But
> that's by design. I wouldn't want to make that replacement even if I
> could, since I wouldn't want an attacker who gains access to my (one
> of my) PGP (sub)key(s) to have access equivalent to 1, 2, or 3. I also
> wouldn't want to use my (import) PGP keys on any non-Qubes systems,
> since that would likely defeat the purpose of protecting them via
> Split GPG.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZD1vAAAoJENtN07w5UDAw0PgP/jZwC1XYgGbXn6Oja5IkDKuF
09sfEZVlWsfUgWB+rT6X6sOX2cpUrxKSL/7e2Zb/YuebCDawwSycZxi1XVsOGP2y
sTxD8fi3k/t86i1LvgVFi7TbwKBjqwzvbP1en575iMrbTa8ye48Vg1tpaLmnt82/
GrDneJNgnQDw79bbjK0GO4Ak/Y3kAhZm9QRvaHNM4rKrdyI0fobDq18TXmaAIKi+
pIJ+fsO+CAemS2pfKuKjaCgzc3dEprzWqOpQgbcOq96dQZ/8t1QPoQqJirpBJ7Tn
Nj06YELPm+IgzPF+9KYRW/EiFJYF2gNBFpA4SNoj4R0fs2nuK2hRb4QCvsiIXGoR
8Bn7Ri5ns4B3Ky8prUWvvnOyXb83XxBe3nZ6q1SaKn4iKKoOYOYEn4KSzDOfH8hL
8edVCWuHNagJS3xXt3j7+xMNBFsYmdYFyuqpiJqq/cgqmiWJnmOp7h4M6y2CZ/9m
CPut/OUw4CFe8zHg7dUDA8Ihc5YGB2Ssegk0hGA3NhpamM3sOsTJ+hDPI/Uq7o1l
8LI4nRhpwC1gLXWKw++X0oPp2wZIYHY/ufB6cgqVnFlZjRhr3FHSpXom8yUOYWGk
dMvWUZM0oJ/Smq6aP4JobX0wBsC5lMhmCVxOf9jQCKh3aoA43Sapm46ekdDDItoP
kszj1eCEzqCrKNMRKki4
=J4QR
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
h

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-07 11:33, nickl...@kulinacs.com wrote:
> On May 7, 2017 10:39:22 AM CDT, Andrew David Wong
>  wrote: On 2017-05-07 10:32,
> nickl...@kulinacs.com wrote:
 On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
  wrote: On 2017-05-07 10:10, 
 nickl...@kulinacs.com wrote:
>>> What benefit does this have over simply ysing 
>>> qubes-split-gpg-client-wrapper, like done here: 
>>> https://github.com/kulinacs/pass-qubes It seems like a
>>> lot of overhead for not a lot of gain.
>>> 
>>> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
>>>   wrote:
 Building on the excellent pass
 (https://passwordstore.org), it gives me great
 pleasure to announce the initial release of
 qubes-pass — an inter-VM password manager and store
 for Qubes OS.
 
 Check it out here!
 
 https://github.com/Rudd-O/qubes-pass
 
 
 What are the advantages of either of these over the
 traditional Qubes model of having a normal password manager
 in a vault VM and using the inter-VM clipboard to copy/paste
 passwords out of it?
 
 
 I prefer Pass because it uses GPG for encryption, meaning I
 can manage fewer secrets over all (as it backends into my
 normal GPG key) and then track my password files in git. To
 do this with the traditional Keepass method, you either need
 to back up the password database somewhere secure or remember
 another password for it.
 
> 
> Why not just back up the entire vault with qvm-backup?
> 
> 
> Git has less storage overhead (as you're backing up a bunch of text
> files, not an entire VM), allows proper versioning, so it is
> trivial to see your passwords at a point in time, and can be used
> cross platform if you chose to keep your GPG key on another
> system.
> 

I prefer the security of qvm-backup[-restore], since it allows me to
keep the vault and its contents permanently offline. The entire VM is
BZIP compressed, AES-256 encrypted, and HMAC-SHA512 authenticated. The
integrity verification, authentication, and decryption all happen at
the dom0 level. The backup is tiny, so the storage overhead is
inconsequential, and there's no need to worry about file-level
metadata leakage or the backup file itself being used as an attack
vector. KeePassX has sufficient built-in versioning for me, and it's
easy enough to sync Qubes backups across machines with simple scripts.

With this setup, considerations like "managing fewer secrets" seem out
of place. I only have to manage three secrets:

1. LUKS passphrase
2. Backup passphrase
3. Screen locker passphrase

Managing these three allows me to have an arbitrary number of
additional secrets in VMs without having to remember anything else. I
can't replace 1, 2, or 3 with my PGP key(s), because my PGP key(s) are
inside my PGP VM, which I can't access except via 1, 2, or 3. But
that's by design. I wouldn't want to make that replacement even if I
could, since I wouldn't want an attacker who gains access to my (one
of my) PGP (sub)key(s) to have access equivalent to 1, 2, or 3. I also
wouldn't want to use my (import) PGP keys on any non-Qubes systems,
since that would likely defeat the purpose of protecting them via
Split GPG.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZD1gbAAoJENtN07w5UDAwu14P/2ZzxA5RM4QS/F+GhyafenJM
rQmgmxpZbDIENeiwCrxQGkPxO5vZjGXcIKsACekLlTVeWwNvmRtfOnQa5vvhBDyS
1WGoHYOnuODM7EVe2GZhA4gngRWiJ+iLFvvtRcApG6hMA7BwGqxsLUhl1XbQL3XA
EVYEIfkLZ8CffIe2QuXAwFMMc6uBYMHunTSeZPZHuy7DmGLEHacHuuJvUadxzHqF
r3zncyZeCwrFwUrJFgDE8UTXcrv5azuih4Pr1GN1G3HgsvpjfMTtyYZlfYJX1agQ
JonOQ//N6Fv8B2Fn5tFEGCHJN9hddfc1YW0xMvgHc8AbiBEGN4aUzb+pd+EprL8j
7uEsFnYy/zBs/TXMaQaAecQYIGOln76IDtUMNQhTmBTHdltJoe3yE0RdCP3T2zJj
d5dtP09imbNx2GFoac/6gA3HnmP/4rPeK6qnad7i0y1OyuMl4zTrU2AdqwcG4+S8
N0XGywpBlr+bDUCEuxtGO13pDPomgQXuPoOgZPmJORF/4T/KxEBMKEBEPVs1K81E
nblCCG6n80STe48a4Vk0Gv4IFw9Or/kFYR5M4B4UvnmJCoMaWj1a92VBC/8z8KCG
ck0MkR2y6KbA1wI3CUAF8GkjlIfEE2ewaU8BQcEQqKplL7gNV4NqfRbpMuvLe1LW
TK/sqfLYBdq0r/UsYQ+p
=dZn6
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/76e540df-ef80-cbaa-9ab7-f0aaf8684523%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[nicklaus]

On May 7, 2017 10:39:22 AM CDT, Andrew David Wong  wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>On 2017-05-07 10:32, nickl...@kulinacs.com wrote:
>> On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
>>  wrote: On 2017-05-07 10:10, 
>> nickl...@kulinacs.com wrote:
> What benefit does this have over simply ysing 
> qubes-split-gpg-client-wrapper, like done here: 
> https://github.com/kulinacs/pass-qubes It seems like a lot
> of overhead for not a lot of gain.
> 
> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)" 
>  wrote:
>> Building on the excellent pass (https://passwordstore.org),
>> it gives me great pleasure to announce the initial release
>> of qubes-pass — an inter-VM password manager and store for
>> Qubes OS.
>> 
>> Check it out here!
>> 
>> https://github.com/Rudd-O/qubes-pass
>> 
>> 
>> What are the advantages of either of these over the traditional 
>> Qubes model of having a normal password manager in a vault VM and 
>> using the inter-VM clipboard to copy/paste passwords out of it?
>> 
>> 
>> I prefer Pass because it uses GPG for encryption, meaning I can 
>> manage fewer secrets over all (as it backends into my normal GPG 
>> key) and then track my password files in git. To do this with the 
>> traditional Keepass method, you either need to back up the password
>> database somewhere secure or remember another password for it.
>> 
>
>Why not just back up the entire vault with qvm-backup?
>
>- -- 
>Andrew David Wong (Axon)
>Community Manager, Qubes OS
>https://www.qubes-os.org
>-BEGIN PGP SIGNATURE-
>
>iQIcBAEBCgAGBQJZDz+kAAoJENtN07w5UDAwVdEQAKyEUNffYrCLsTK8TyRvWnyi
>3dz15oDFHAL/PXkUHptcn4NJfU3BrmPBcf8DaBM2ROlXVJQayYZq9QwE1wlftxjr
>+ZblvNOuYbc/+FGxGNpqimc7jSC5TSaaduMW47THp66xemYH55pVChD2WT3X/dk4
>gn51SLYKE7tixnsOaqNEQSawpwbDsVaL4hLDgV4NLDKeZTbhLLxLbFlvikoMsUxY
>BXj19mfje2oJrDAXEDUtDK9qq8tOjttK4EomVG0HQVinyhpKiLn/Nil91xQnKvES
>H8QG9sEUUEGs0/GsYsXIkb3VJqRdkns5A1Cp5FR3/WTiIxBARfewXY3klQKO0UFj
>zTovVZ3OgjuqmqDlkLLGRI5bn1NHZ2k9IFly4+8VUYXPOVBNdkKmIpqS3x0EPhuO
>rFZmg/1OYHeT3FLt6WwDJilNGzN2I/FByx7AbwiEHGgspQYVviDRha2n6eCDGh0R
>uIZ3/8iYj+QA+glXZFGj5ghIKjBiA6rcn7vTh7/r+9rGaOCCDCGY6L4ZrgL8Ao76
>VOw1MnnzVHIOGjGQ0RacDN9qZ8D/YTy2BqZVUdF1RXoBb77LQgAfVfVAeIjzuWg7
>KIlXI9ScIFqEbbcxC7w4SC1LHbEcET81q5B0tNzJUJ+QL0/CZQ9avrPHBOq9kVRs
>NK8zRvknFnPargpog2UK
>=vzjL
>-END PGP SIGNATURE-

Git has less storage overhead (as you're backing up a bunch of text files, not 
an entire VM), allows proper versioning, so it is trivial to see your passwords 
at a point in time, and can be used cross platform if you chose to keep your 
GPG key on another system.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/B06DAF03-3208-4AB4-A0CF-96274F6A4804%40kulinacs.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-07 10:32, nickl...@kulinacs.com wrote:
> On May 7, 2017 10:23:54 AM CDT, Andrew David Wong 
>  wrote: On 2017-05-07 10:10, 
> nickl...@kulinacs.com wrote:
 What benefit does this have over simply ysing 
 qubes-split-gpg-client-wrapper, like done here: 
 https://github.com/kulinacs/pass-qubes It seems like a lot
 of overhead for not a lot of gain.
 
 On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)" 
  wrote:
> Building on the excellent pass (https://passwordstore.org),
> it gives me great pleasure to announce the initial release
> of qubes-pass — an inter-VM password manager and store for
> Qubes OS.
> 
> Check it out here!
> 
> https://github.com/Rudd-O/qubes-pass
> 
> 
> What are the advantages of either of these over the traditional 
> Qubes model of having a normal password manager in a vault VM and 
> using the inter-VM clipboard to copy/paste passwords out of it?
> 
> 
> I prefer Pass because it uses GPG for encryption, meaning I can 
> manage fewer secrets over all (as it backends into my normal GPG 
> key) and then track my password files in git. To do this with the 
> traditional Keepass method, you either need to back up the password
> database somewhere secure or remember another password for it.
> 

Why not just back up the entire vault with qvm-backup?

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZDz+kAAoJENtN07w5UDAwVdEQAKyEUNffYrCLsTK8TyRvWnyi
3dz15oDFHAL/PXkUHptcn4NJfU3BrmPBcf8DaBM2ROlXVJQayYZq9QwE1wlftxjr
+ZblvNOuYbc/+FGxGNpqimc7jSC5TSaaduMW47THp66xemYH55pVChD2WT3X/dk4
gn51SLYKE7tixnsOaqNEQSawpwbDsVaL4hLDgV4NLDKeZTbhLLxLbFlvikoMsUxY
BXj19mfje2oJrDAXEDUtDK9qq8tOjttK4EomVG0HQVinyhpKiLn/Nil91xQnKvES
H8QG9sEUUEGs0/GsYsXIkb3VJqRdkns5A1Cp5FR3/WTiIxBARfewXY3klQKO0UFj
zTovVZ3OgjuqmqDlkLLGRI5bn1NHZ2k9IFly4+8VUYXPOVBNdkKmIpqS3x0EPhuO
rFZmg/1OYHeT3FLt6WwDJilNGzN2I/FByx7AbwiEHGgspQYVviDRha2n6eCDGh0R
uIZ3/8iYj+QA+glXZFGj5ghIKjBiA6rcn7vTh7/r+9rGaOCCDCGY6L4ZrgL8Ao76
VOw1MnnzVHIOGjGQ0RacDN9qZ8D/YTy2BqZVUdF1RXoBb77LQgAfVfVAeIjzuWg7
KIlXI9ScIFqEbbcxC7w4SC1LHbEcET81q5B0tNzJUJ+QL0/CZQ9avrPHBOq9kVRs
NK8zRvknFnPargpog2UK
=vzjL
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1a23c189-47e1-d88d-ff1b-e077b6d920db%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[nicklaus]

On May 7, 2017 10:23:54 AM CDT, Andrew David Wong  wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>On 2017-05-07 10:10, nickl...@kulinacs.com wrote:
>> What benefit does this have over simply ysing
>> qubes-split-gpg-client-wrapper, like done here: 
>> https://github.com/kulinacs/pass-qubes It seems like a lot of
>> overhead for not a lot of gain.
>> 
>> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
>>  wrote:
>>> Building on the excellent pass (https://passwordstore.org), it
>>> gives me great pleasure to announce the initial release of
>>> qubes-pass — an inter-VM password manager and store for Qubes
>>> OS.
>>> 
>>> Check it out here!
>>> 
>>> https://github.com/Rudd-O/qubes-pass
>>> 
>
>What are the advantages of either of these over the traditional Qubes
>model of having a normal password manager in a vault VM and using the
>inter-VM clipboard to copy/paste passwords out of it?
>
>- -- 
>Andrew David Wong (Axon)
>Community Manager, Qubes OS
>https://www.qubes-os.org
>-BEGIN PGP SIGNATURE-
>
>iQIcBAEBCgAGBQJZDzwAAAoJENtN07w5UDAwPwYP/A1L6MTJWkSTAkopSLUFQnbg
>bL0/6/YxjMNG7YBRSDhB0k5hAD70WOnHt/W2AyEkr6ihhVDkflmeAkBuc7tZgZNa
>Us/9q3X3bgN/loQ/nCgAlVN+E5EqdzJyo1y94fSF9hrKKXCKPF1/nK+GxweGJl+N
>PLd+oq1XjhQ8YVSI1z2yZhfO0ro5j85YhE3F/btLbNpyjVEu41JVtgdamYmHrz2O
>C72llnuLedHoYJ7uTtw1inurkenndnHnGrRw8QdJFy9l8Lq8o30dOTS2/zqZriig
>NF+LVlwDzJ5kostP1Rx8f/80RGhjqtqsalT+WGbgcSC/mOBzoPxKMi48tiD5BGxx
>wb6hezl0fcl/JKep7DfwZm+LGmEXO/S1KLEyGhACSkiIGmEaKDnzPq3q/nq8DKRj
>7ZDUjp2+chXdK0OxgGuc6/NpQkSrT0fqe3wawH/JZmg8rYi49mMxWMVNfc3Rvfvl
>3d093U+2voFmlr3uyO/3q9TeMV/fRJY9ft+ygXwrMie9zCBLHfKS5bACldzCeaW5
>JXqbkNuSmw48+f/QmS0EeRCPDCtv6cXB2vTN4rzxgKee7ww4p5JV6mqQi7RLA00Y
>bJ7xP9BZb8R8eSXtLbsCmGpkSXMnyPl5NGgrkrFaktz4pYpH7+HGYXVOfvHxJkLG
>I0EO4GdyH2SaXrj9OXke
>=FKB/
>-END PGP SIGNATURE-

I prefer Pass because it uses GPG for encryption, meaning I can manage fewer 
secrets over all (as it backends into my normal GPG key) and then track my 
password files in git. To do this with the traditional Keepass method, you 
either need to back up the password database somewhere secure or remember 
another password for it.

---
kulinacs

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1BBC6F4A-1054-4AB7-87EA-1E1236DB56DB%40kulinacs.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-07 10:10, nickl...@kulinacs.com wrote:
> What benefit does this have over simply ysing
> qubes-split-gpg-client-wrapper, like done here: 
> https://github.com/kulinacs/pass-qubes It seems like a lot of
> overhead for not a lot of gain.
> 
> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
>  wrote:
>> Building on the excellent pass (https://passwordstore.org), it
>> gives me great pleasure to announce the initial release of
>> qubes-pass — an inter-VM password manager and store for Qubes
>> OS.
>> 
>> Check it out here!
>> 
>> https://github.com/Rudd-O/qubes-pass
>> 

What are the advantages of either of these over the traditional Qubes
model of having a normal password manager in a vault VM and using the
inter-VM clipboard to copy/paste passwords out of it?

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZDzwAAAoJENtN07w5UDAwPwYP/A1L6MTJWkSTAkopSLUFQnbg
bL0/6/YxjMNG7YBRSDhB0k5hAD70WOnHt/W2AyEkr6ihhVDkflmeAkBuc7tZgZNa
Us/9q3X3bgN/loQ/nCgAlVN+E5EqdzJyo1y94fSF9hrKKXCKPF1/nK+GxweGJl+N
PLd+oq1XjhQ8YVSI1z2yZhfO0ro5j85YhE3F/btLbNpyjVEu41JVtgdamYmHrz2O
C72llnuLedHoYJ7uTtw1inurkenndnHnGrRw8QdJFy9l8Lq8o30dOTS2/zqZriig
NF+LVlwDzJ5kostP1Rx8f/80RGhjqtqsalT+WGbgcSC/mOBzoPxKMi48tiD5BGxx
wb6hezl0fcl/JKep7DfwZm+LGmEXO/S1KLEyGhACSkiIGmEaKDnzPq3q/nq8DKRj
7ZDUjp2+chXdK0OxgGuc6/NpQkSrT0fqe3wawH/JZmg8rYi49mMxWMVNfc3Rvfvl
3d093U+2voFmlr3uyO/3q9TeMV/fRJY9ft+ygXwrMie9zCBLHfKS5bACldzCeaW5
JXqbkNuSmw48+f/QmS0EeRCPDCtv6cXB2vTN4rzxgKee7ww4p5JV6mqQi7RLA00Y
bJ7xP9BZb8R8eSXtLbsCmGpkSXMnyPl5NGgrkrFaktz4pYpH7+HGYXVOfvHxJkLG
I0EO4GdyH2SaXrj9OXke
=FKB/
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/db34d43c-a1a1-1019-1e8a-b6f4303ad025%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[nicklaus]

What benefit does this have over simply ysing qubes-split-gpg-client-wrapper, 
like done here:
https://github.com/kulinacs/pass-qubes
It seems like a lot of overhead for not a lot of gain.

On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"  
wrote:
>Building on the excellent pass (https://passwordstore.org), it gives me
>great pleasure to announce the initial release of qubes-pass — an
>inter-VM password manager and store for Qubes OS.
>
>Check it out here!
>
>https://github.com/Rudd-O/qubes-pass
>
>-- 
>Rudd-O
>http://rudd-o.com/
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "qubes-users" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to qubes-users+unsubscr...@googlegroups.com.
>To post to this group, send email to qubes-users@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/24c27d7a-e72e-14fc-e388-2f5718d95660%40rudd-o.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0A765A21-F411-4015-B9C2-790508B1A0C1%40kulinacs.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Manuel Amador (Rudd-O)]

Building on the excellent pass (https://passwordstore.org), it gives me
great pleasure to announce the initial release of qubes-pass — an
inter-VM password manager and store for Qubes OS.

Check it out here!

https://github.com/Rudd-O/qubes-pass

-- 
Rudd-O
http://rudd-o.com/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/24c27d7a-e72e-14fc-e388-2f5718d95660%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.