<andi->
So, what is your 2nd factor backup strategy? Aka where do you safely store your GH recovery codes? Last time I checked GH didn't allow more then one token.
<gchristensen>
I have them printed in a safe
pie___ has quit [Ping timeout: 244 seconds]
__Sander__ has quit [Quit: Konversation terminated!]
pie___ has joined #nixos-security
pie___ has quit [Ping timeout: 240 seconds]
<andi->
Anyone doing offline (read: paper) backups of GPG keys or SSH keys? I have them printed but scanning/typing isn't really the best workflow
<gchristensen>
I also have a paper backup using printed QR codes
<gchristensen>
in the same safe :P
<gchristensen>
speaking of which, please don't find my safe
<andi->
hrhr
<andi->
I tried to make reasonable backups of things as QR codes.. It just doesn't really work for things like (root) CA certficiates (internal ones)
<andi->
You can chunk it in twenty QR codes
<andi->
but using a phone to scane the CA isn't really what I am after :D
<gchristensen>
lol
<andi->
I don't trust my phone... for that kind of stuff
<gchristensen>
right
<samueldr>
andi-: if you trust a scanner you can consume them without a phone :)
<samueldr>
(or a webcam)
<samueldr>
(I was thinking about how printers are hell, and now most scanners are part of a multi-function-center)
<gchristensen>
and careful with those printers that remember everything they've ever printed
<gchristensen>
or scanners that remember everything they've scanned
<samueldr>
part of "are hell" :(
<andi->
Never print unencrypted keys!!!111 ;-)
<andi->
and never print something with an intelligent printer tha tmgiht swap a few characters here and there..
<andi->
actually just don't print m(
<gchristensen>
I recommend just not having secrets
<gchristensen>
or computers
<andi->
yeah
<andi->
that sounds like a good idea
<andi->
Lets move to the woods...
* gchristensen
looks in his back yard
* gchristensen
looks at his front yard
<gchristensen>
:check:
<andi->
hrhr
<samueldr>
✔️
<andi->
are you self sustaining yet?
<gchristensen>
no way
<gchristensen>
extremely on the grid
<andi->
So the newest idea I am trying to explore (with the input from flokli) is that I am just using git notes or generic git objects for storage of CVE data to each commit. Generating different kind of views to the issue seems possible... Lets see how successful that is
<gchristensen>
git notes are terrible
<gchristensen>
avoid avoid avoid
<andi->
mhmm
<andi->
I just thought that since I am basically annotating each commit it wouldn't be that bad..
<gchristensen>
it is bad
<andi->
Will kittens die if I use it? :D
<flokli>
don't care about the kittens!
<gchristensen>
andi-: kittens? no
<gchristensen>
but do you ever want someone else to add notes?
<gchristensen>
and then be able to push and pull other people's notes?
<andi->
I would store them in a dedicated refs/vulns/fooo place
<andi->
and just use that internally..
<gchristensen>
git-notes?
<andi->
notes to an issue would live outside of that
<gchristensen>
I'm speakin specifically about notes, don't use notes
<flokli>
idea was to simply traverse each commit, find out vulns, then append a note to the cve
<gchristensen>
where notes is `git-notes`
<andi->
yes
<andi->
same
<gchristensen>
here is a fun exercise
<gchristensen>
one of you adds some notes
<gchristensen>
the other fetches adds some notes
<gchristensen>
the first adds notes in such a way that causes a merge conflict
<gchristensen>
now try and resolve that merge conflict
<gchristensen>
I used git-notes for NixOS security things in the past
<andi->
I'll have to die the one-object-per-commit (or per channel bump) death one way or another.. I still don't think that using a database blob for longterm storage is a good idea.. I might as well have a directory structure where you can lookup results per commit.. Just the reverse lookup (which commits are affected) sucks. It would also suck in the git notes case.
<gchristensen>
that seems good
<flokli>
we evaluated (ab)using a git repo to store versions plus names of applied patches for each package drv for each commit in nixpkgs in a directory-like structure, and then keep a directory of issues/cve's next to it. one could then simply create symlinks from inside each issue dir to affected pkgs… git might do a good job in deduplicting that, but I fear nobody will be able to check out a working
<flokli>
directory of that…
<flokli>
basically using git's view of a filesystem to mirror attrsets etc., plus have history
<flokli>
but well, a repo that nobody is able to checkout is probably not very useful, too…
<andi->
I'll attempt a very light approach to that.. I think being able to check the repo out is a must have feature ;-)
<ekleog>
<andi-> Anyone doing offline (read: paper) backups of GPG keys or SSH keys? I have them printed but scanning/typing isn't really the best workflow <-- There's http://www.jabberwocky.com/software/paperkey/ (not sure 'bout the URL but it was “paperkey”, so well…) that passed a few times on GnuPG MLs
<ekleog>
andi-: @ reverse-lookup: do you think the CVE repository would become big enough that grep -R isn't a solution?
<ekleog>
(I mean, I usually figure out where functions are defined in nixpkgs by `grep -R 'func ='`, and that's working pretty OK, so the repo would have to be larger than nixpkgs -- not even counting trying out ripgrep)