Re: [gentoo-user] What do you think about pam-gnupg?
On 3/2/23 9:53 PM, efeizbudak wrote: Doesn't this sort of defeat the purpose of using pass? I mean if it's always decryptable then is it really useful to have it encrypted in the first place (assuming you have full disk encryption set up)? I may be missing something crucial here so please let me know. There is value in not having a password in clear text on a file system. It really depends on what your trying to protect from / against. Grant: This seems like the lesser of all evils to me. As I understand, you're suggesting that I lend the email password to the daemon at start and only have that password stored in memory instead of my actual gpg password, is that correct? I think we're talking about the same thing. Again, I may be missing something here, but does having your GPG credentials unprotected offer any real protection? See my response to your comment / question to Matt. I guess this is where I'll eventually be heading towards. I'm personally looking forward to being able to use TPMv2 to protect keys for services running on the system. It requires said services to support the TPM. By the way, thanks to both of you for your thoughts! :-) -- Grant. . . . unix || die
Re: [gentoo-user] What do you think about pam-gnupg?
Matt: > I don't have any thoughts on the pam module, but I make use of some > scripts that rely on pass as well. For my use case I just raised the > TTL setting of gpg-agent to match an eight hour work day or eight hour > evening period and ran with it. Feels fairly natural to "log in" to > the agent once a day at the first use. Doesn't this sort of defeat the purpose of using pass? I mean if it's always decryptable then is it really useful to have it encrypted in the first place (assuming you have full disk encryption set up)? I may be missing something crucial here so please let me know. Grant: > Can you re-architect this as a (pseudo) daemon so that you unlock it > once (or at least a LOT less often) and it stores the necessary > information in memory for subsequent re-use? This seems like the lesser of all evils to me. As I understand, you're suggesting that I lend the email password to the daemon at start and only have that password stored in memory instead of my actual gpg password, is that correct? > Could you re-configure things so that (a copy of) the requisite password > is accessible via a different set of GPG credentials specific to the > process that you're running? Then you could probably have just that set > of GPG credentials unprotected so that the script could use them as it > is today. Again, I may be missing something here, but does having your GPG credentials unprotected offer any real protection? > If neither of these options were possible I'd look into something like a > TPM and / or Yubikey wherein I could offload some of the GPG to it so > that the decryption key is physically tied to the source computer /and/ > *where* *it* *can't* *be* *copied*. I guess this is where I'll eventually be heading towards. By the way, thanks to both of you for your thoughts! -- All the best, Efe The funny quote of this email is trivial and left as an exercise. signature.asc Description: PGP signature
Re: [gentoo-user] Is it OK to get rid of app-alternatives/* ?
Thanks Dave On Sun, Feb 19, 2023, 05:31 Neil Bothwick wrote: > On Wed, 15 Feb 2023 23:09:54 -0500, Walter Dnes wrote: > > > > It's bad enough depclean deleting the active kernel if you don't > > > watch out, without something deciding to install a non-existent > > > kernel and deleting the live one :-) > > > > I have my own hand-coded script that runs "emerge --pretend > > --depclean" and tweaks/filters the output into another script called > > "cleanscript". I've set it to filter out "gentoo-sources". I then > > inspect "cleanscript" before running it. And, oh yeah, depclean wants > > to remove nano. I had to "emerge -n nano" to protect it. > > You can add kernel sources to a set so they are never depcleaned > > % cat sets.conf > [kernels] > class = portage.sets.dbapi.OwnerSet > world-candidate = False > files = /usr/src > > Then emerge -n @kernels > > I do the same with gcc so I can keep the previous version > > [gcc] > class = portage.sets.dbapi.OwnerSet > world-candidate = False > files = /usr/x86_64-pc-linux-gnu/gcc-bin > > > -- > Neil Bothwick > > For security reasons, all text in this mail > is double-rot13 encrypted. >
Re: [gentoo-user] What do you think about pam-gnupg?
On 3/2/23 6:48 AM, Matt Connell wrote: You just described gpg-agent, the core of what Efe (OP) is meddling with :) No, I didn't. I was referring to having the OP's utility read the password and interact with GPG /once/ at startup and then the utility run for a much longer time retaining the decrypted password in it's memory. The difference may seem subtle, but it is very important to understand. -- Grant. . . . unix || die
Re: [gentoo-user] What do you think about pam-gnupg?
On Wed, 2023-03-01 at 15:38 -0700, Grant Taylor wrote: > Can you re-architect this as a (pseudo) daemon so that you unlock it > once (or at least a LOT less often) and it stores the necessary > information in memory for subsequent re-use? You just described gpg-agent, the core of what Efe (OP) is meddling with :) > Could you re-configure things so that (a copy of) the requisite password > is accessible via a different set of GPG credentials specific to the > process that you're running? Then you could probably have just that set > of GPG credentials unprotected so that the script could use them as it > is today. > > If neither of these options were possible I'd look into something like a > TPM and / or Yubikey wherein I could offload some of the GPG to it so > that the decryption key is physically tied to the source computer /and/ > *where* *it* *can't* *be* *copied*. Since pass, the utility that OP is using in their script, is built around GPG, of course there have been some spinoffs, using other encryption methods. Personally setting the gpg-agent timeout higher and having good physical security works for my use case, but everyone has a different situation. If I worked in an office still, I think I would have a physical GPG-based key solution, though I will admit I'm not read up on which ones are the tops right now. Efe, it may be useful to review the pass mailing list archives[1] for some other ideas. I don't think you're trying to solve a snowflake problem here, but pam tie-ins doesn't feel quite right for a solution either. 1: https://lists.zx2c4.com/pipermail/password-store/
