On Mon, 4 Jun 2018 15:34:48 -0400, Steve wrote in message <20180604153448.5a9ec...@mydesk.domain.cxm>:
> Hi all, > > Timing is everything. I was about to put my Stylz project on GitHub. > No more. > > GitLab's a maybe, but unexpected bad stuff happens in Open Source too: > systemd, Caldera going to the dark side, etc. > > My understanding, from reading man pages of a very few git commands, > is that git comes with a server to serve out read-only access to my > repository. And for those few with push/commit/branch rights, I can > give them ssh logins, key access only. > > 1) Can I put the preceding in a sandbox from which limited harm can be > done? > > 2) Can I enforce that those keys must have passwords? Passwords of a > certain length and quality? ..you _can_ chk for empty strings, e.g.: arnt@d44:~/skatten$ echo "" |md5sum 68b329da9893e34099c7d8ad5cb9c940 - arnt@d44:~/skatten$ echo |md5sum 68b329da9893e34099c7d8ad5cb9c940 - arnt@d44:~/skatten$ echo|md5sum 68b329da9893e34099c7d8ad5cb9c940 - ..maybe a 2 step login, first to "ssh-guest", then on to "git-guest"? (Never tried it myself) > 3) What security precautions must I take if this is on my daily driver > desktop? ..this is a no-brainer: Put it on its own disk in its own box. Even if you can afford losing your own daily driver desktop, you can _not_ afford to lose other peoples work. _That_ will piss them off, _hard_. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng