On Thu, Aug 20, 2015 at 03:24:02PM -0700, Bryce Harrington wrote: > On Thu, Aug 20, 2015 at 03:04:32PM -0400, Martin Owens wrote: > > On Thu, 2015-08-20 at 12:01 -0700, Josh Andler wrote: > > > I think a simple system like that could be beneficial. Given the info > > > about it and my lack of knowledge of OSUOSL's systems, is our web > > > hosting on an encrypted filesystem? > > > > Not as far as I know. But an encrpyted sqlite3 db should be possible > > with an fs mount If I remember how ubuntu used to do home directory > > encryption. > > I'll point out we already have a gpg/git-based password management > system. I'll be happy to add anyone to it that needs access, and while > I know gpg can be kind of technically complicated, I did attempt to > document it well enough that most steps should be pretty > paint-by-numbers. > > Given that, I'd only want to consider switching the system if the new > one is a) properly open source, b) at least as secure as our current > system, and c) *technically* better in some way (apart from usability). > Bonus points for being user friendly.
I would add d) "is more or equally simple in implementation". > With that said, and not having actually played with Rattic, (a) seems to > be covered since it's GPL licensed. (b) it is essentially sidestepping > by leaving it to the webserver and filesystem to handle (which actually > is probably a smart approach); however it feels like I'm comparing > apples to oranges so I'd want to hear the evaluation of an actual > security expert (e.g. Kees Cook) before deciding this one. As to (c), > it looks like it'll handle everything our current approach does, and > adds Auditing which our current system does *not* do, and which I do > think would be useful. Unfortunately they don't post screenshots of the > app itself, but presumably nearly anything would be more user friendly > than command line gpg so I'll concede that point. > > Given A and C, I see no reason not to go ahead and set up something we > can try out. I'd want B settled before we migrate to it though. > > In terms of priority, since we do have a system for handling passwords > right now, I don't see this as urgent, myself, but if Martin is gung ho > to experiment with it, I don't see a reason not to. > > I *would* like to see a listing of what passwords we'd put in it, and > who should have access.* > > Bryce > > * - Mostly because if there's anything our current system is missing, > then I should make a priority to fix that ASAP. If this is for shared password management, I would actually argue for eliminating the need for shared passwords entirely. How does revocation currently work? Right now, I imagine you're sharing credentials instead of having a credential for each person, which then has authorizations tied to that credential. For example, give each admin an account (separate credentials), and access to a sudo group (authorization tied to their credential). I suspect my lack of context here means something about your requirements make this suggestion unworkable, though. :) -Kees -- Kees Cook @outflux.net ------------------------------------------------------------------------------ _______________________________________________ Inkscape-board mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/inkscape-board
