[15:03:38] <chaomodus>	 o/
[15:42:03] <shdubsh>	   \o
[15:43:26] <cdanis>	 o/
[15:44:00] <herron>	 )o)
[15:47:21] <chaomodus>	 \o- -o- -o/
[18:05:05] <volans>	 at some point we should really find the time to work on secrets and go next pwstore... I want to add a file and my people chasing counter is already at 3...
[18:09:31] <chaomodus>	 what exacly is the issue?
[18:09:35] <herron>	 volans: including puppet secret() as well?
[18:09:54] <volans>	 herron: those are two different problems, but potentially yes
[18:10:07] <herron>	 are they?
[18:10:08] <volans>	 chaomodus: gpg expirations
[18:10:21] <chaomodus>	 ah surely we could .. alert on that?
[18:10:46] <volans>	 not really, the list of users that have access to it is not public
[18:10:54] <chaomodus>	 Mh
[18:10:56] <chaomodus>	 yah
[18:10:56] <volans>	 not to mention their GPGs
[18:10:58] <chaomodus>	 huh
[18:11:05] <volans>	 I mean, ofc they are public
[18:11:07] <volans>	 the keys
[18:11:19] <volans>	 but one could have multiple potentially
[18:11:51] <herron>	 could possibly walk .users and bark if one is expiring soon
[18:12:48] <volans>	 herron: I think they are related but have different angles, secret() is to deploy secrets to hosts, via our cfg mgmt software of choice, pwstore is for human secrets, they have slightly different requirements
[18:13:03] <volans>	 but I'm not excluding that one tool could fit both needs, if that's what you meant
[18:14:28] <herron>	 yeah that’s what I was thinking, of course a large effort, but managed secrets should be consumable by humans and programs
[18:14:46] <herron>	 IMO
[18:15:39] <volans>	 I've ideas for the requirements part, ETOOLONG/ETOOLATE to put them here now, but happy to chat about them next week if you remind me ;)
[18:16:27] <herron>	 nice, sounds good
[18:17:19] <chaomodus>	 cool