<samueldr>
"Wind chill values will reach near minus 40 overnight tonight and early tomorrow morning in these regions" time to build Qt
<gchristensen>
nice
<gchristensen>
-21C on Monday
<samueldr>
-12C on monday, though it looks like there's going to snow during parts of the week-end, and most of the week :/
<simpson>
It's gonna be as low as 1C on Monday here, which means likely snow or freezing rain. :T
<gchristensen>
"Snow (20–33 in.) today through Thursday"
<gchristensen>
:D :D :D
<samueldr>
ouch, I was looking at the text for the weather report: "Frostbite in minutes" for tonight
<gchristensen>
yeah that sounds like -40...
<simpson>
Snow will be debilitating if there's more than an inch or so; I think there's maybe a dozen snow plows for all of this part of Oregon. Freezing rain is my real worry though. That stuff's dangerous for everybody.
<gchristensen>
oh wow
<gchristensen>
we can handle some freezing rain, but ice is bad news
<simpson>
I'm glad I bought strap-on cleats last year. Turns sneakers into iceboots.
<gchristensen>
a good bet for sure
<gchristensen>
I might try going snow shoeing this weekend if I can
sheth has quit [Ping timeout: 272 seconds]
<colemickens>
cachix down?
<colemickens>
nixos-rebuild sure leaves a lot to be desired in this case, --fallback is nearly useless
pie__ has quit [Read error: Connection reset by peer]
pie_ has joined #nixos-chat
sheth has joined #nixos-chat
pie__ has joined #nixos-chat
pie_ has quit [Ping timeout: 245 seconds]
ottidmes has quit [Ping timeout: 250 seconds]
endformationage has quit [Quit: WeeChat 2.3]
pie___ has joined #nixos-chat
pie__ has quit [Ping timeout: 246 seconds]
MichaelRaskin has joined #nixos-chat
<MichaelRaskin>
How do I stop feeling Schadenfreude from the fact that Debian systemd maintainer, one of the key people doing the hard work for systemd transition in Debian, refuses to talk to systemd upstream any more, and declared a break from maintainining systemd package in Debian?
<jasongrossman>
MichaelRaskin: Assuming their break doesn't last for ever, how can they not talk to upstream?
<MichaelRaskin>
Well, if there is a new maintainer, the old maintainer might help with the work but not with the talk
<jasongrossman>
MichaelRaskin: I see, yes.
<andi->
(Linux) distributions are kind of a religion.. One group of people has different views in how things should work and everyone refusing that is not worth of their time... I also find it kinda amusing while also realizing that since I am using Nix recommending it for "everything" is basically the same...
<MichaelRaskin>
systemd has the opinion on how things should work without
<MichaelRaskin>
having users to support
<MichaelRaskin>
(directly)
__monty__ has joined #nixos-chat
<MichaelRaskin>
«How many systemd package maintainers Debian can afford burning out per year»
<andi->
I tried back porting a lot of stables fixes of systemd to our NixOS fork.. I am also cured of attempting that again.. It breaks in so many ways..
<andi->
The option space to test is also enourmous
gwosix has joined #nixos-chat
<gwosix>
to chroot into a nix install how do you get the paths/shell profile?
<disasm>
anyone using bluetile with nixos?
ottidmes has joined #nixos-chat
gwosix has quit [Quit: WeeChat 2.3]
<mdash>
andi-: i spent two years convincing a debian user to stop making custom debs for all his stuff and package for nixos instead, now he's trying to convince other people ;)
endformationage has joined #nixos-chat
hedning has joined #nixos-chat
hedning has quit [Quit: hedning]
hedning has joined #nixos-chat
<ivan>
I am here yes
<gchristensen>
welcome =
<gchristensen>
)
<infinisil>
I think one of my disks is dying
<infinisil>
Been unpacking a nixpkgs tarball download for like 10 minutes now, hasn't finished yet..
<infinisil>
I have 2 HDD's in a mirror, so I think if either one of them has problems, the whole thing is slow
<gchristensen>
anything in smart?
<infinisil>
smartctl in smartmontools?
<gchristensen>
yea
<infinisil>
SMART overall-health self-assessment test result: PASSED
<infinisil>
For 2 of the three disks
<infinisil>
Namely one HDD and one SSD cache disk
<gchristensen>
sounds like you're right
<infinisil>
The other HDD gives /dev/sdc: Unknown USB bridge [0x059f:0x107c (0x001)]
<infinisil>
Which seems like it doesn't support that smart thing
<infinisil>
These disks are pretty old though, I'm not surprised if they had some problems
<gchristensen>
you have a mirror across an internal disk and a usb disk?
<gchristensen>
how about dmesg warnings, infinisil?
<infinisil>
I have a mirror accross one internal HDD and one USB HDD, and it has one internal SSD cache device
<infinisil>
I'll check later
<gchristensen>
interesting, ok. I don't think there is any specific problem with that config -- but I guess I'm surprised, I wouldn't expect the performance to be very good
<__monty__>
Reinitializing a new mirror disk is going to take ages.
<__monty__>
Though maybe USB3 is still bearable.
<infinisil>
gchristensen: it was pretty good (once the cache had the data..)
<MichaelRaskin>
I would also include «since shutdown became an idea»
iqubic has joined #nixos-chat
<__monty__>
gchristensen: I figured we'd need to lose 0.15% to make it only 2 nine's.
hedning has quit [Quit: hedning]
hedning has joined #nixos-chat
<elvishjerricco>
infinisil: How is that ssd cache setup?
<infinisil>
elvishjerricco: Just with zfs
<elvishjerricco>
infinisil: zfs can do both write and read caching right?
<infinisil>
Not sure, write caching seems problematic
<sphalerite>
how so?
<sphalerite>
I mean yes the ZIL isn't a true write cache, but…
<infinisil>
Well, write-through takes as long as the disks write speed, and write-back doesn't really work because then it would have to write the full cache to the HDD's when shutting down
<infinisil>
Ah yeah
<infinisil>
So write-through it probably is
<elvishjerricco>
Eli5 write back and write through?
<infinisil>
write-through writes to cache and disk together, waiting until both of them are done, so it updates everything immediately
<infinisil>
write-back writes only to the cache, the disk gets updated when that cache entry gets replaced
<elvishjerricco>
Doesn't ZIL just write to the cache and return, then start eagerly copying to the other disks in the background?
<elvishjerricco>
That doesn't sound like either of those
<infinisil>
Oh and I guess with write-through you have the benefit that you don't need to reread stuff from memory when you updated it, so consecutive reads will be fast, but the write itself won't
<infinisil>
elvishjerricco: I don't know :)
<infinisil>
I just know of these 2 caching write strategies
<iqubic>
Anyone know how to install a package from my own local fork of nixpkgs?
<infinisil>
sphalerite: Hmm, so do you know that it doesn't do writes to the cache?
<infinisil>
Or is this a bit speculative
<elvishjerricco>
Man another one of those Good Things in ZFS that’s just in perpetual review / development
<sphalerite>
infinisil: just assuming :p
<infinisil>
I see
<infinisil>
zpool iostat does have a write statistic for my cache device actually
<simpson>
iqubic: $ nix repl path/to/nixpkgs
<infinisil>
sphalerite: elvishjerricco: Am asking about l2arc in #zfsonlinux
<elvishjerricco>
Wtf. IRCCloud is banned from that channel
<elvishjerricco>
That’s annoying
<elvishjerricco>
Guess I can’t go there
<infinisil>
Huh
<elvishjerricco>
By that logic, the matrix irc integration ought to be banned too
<infinisil>
I can gist the logs after
<elvishjerricco>
Thanks :)
<__monty__>
It's all these spammers on IRCCloud. Looking at no one in particular <_<, elvishjerricco
<disasm>
I have page up and page down buttons again! Going to take a while to get used to that!
<infinisil>
elvishjerricco: The only thing I really got was "ZFS writes data to new sectors. so the old block pointer is effectively invalidated"
<infinisil>
So I assume there's a table in RAM from address to sector. So when something gets written, a new sector is created on the persistent disk, and the table is changed to point the data to that one
<samueldr>
the additional key right of left-shift is an *additional* key when compared to ANSI, what your picture looks like is they moved the key that's supposed to stay on the right, to the left... that's an horror
<samueldr>
(ANSI vs. ISO for me, I'm ambivalent, I'd prefer ISO layouts, but damn near impossible to get, so I settled on preferring ANSI since moving from one to the other is annoying)
<sphalerite>
samueldr: no, that's just an ISO keyboard with the UK layout
<samueldr>
right, then it's fine, though I didn't realise the UK layout had |\ on that additional key; on qwerty US it's the blue key to the right
<sphalerite>
it just so happens that the key next to left-shift on a UK keyboard has the same symbols as the one above enter on a US one
<sphalerite>
yeah
<samueldr>
because I HAVE SEEN keyboards where the *us qwerty* scancode for |\ is placed at that location, between shift and Z
<samueldr>
so if you would have set the keyboard as UK, you would have had ~# on that key
<sphalerite>
um. okay.
<samueldr>
(mainly on cheap "tablet" keyboards or on cheap laptops or smaller form factor PCs)
<sphalerite>
I must say, the short git hash for the vim-nix version in 18.09 is wonderful
<sphalerite>
ab3c4d5
<LnL>
heh
<infinisil>
Does it trim to a constant 7 chars?
<infinisil>
github urls with git hashes only work when they're unique afaik. So 7 char urls can occasionally fail
<infinisil>
Ohh
<infinisil>
Sorry I was confused there
hedning has quit [Quit: hedning]
<infinisil>
I thought it was vim-nix that had some new git hash trimming feature
<infinisil>
But it really was just the hash that has abcd and 345 in it :)
<sphalerit>
Yes
ixxie has joined #nixos-chat
<infinisil>
So yeah, this deriving of a password from domain and master password doesn't really work when you want to change the password
<MichaelRaskin>
Actually, there are sites that generate passwords for you (they generally generate good passwords) but don't give a clear way to set your own
<__monty__>
infinisil: Sure it works. If you want to change a single password just mangle the domain.
<MichaelRaskin>
(You can ask for a new random one, you can do a password recovery via linked contact data, but not enter a chosen password)
<infinisil>
__monty__: Mangle the domain?
<MichaelRaskin>
Then you need to keep track of what mangled version is used for which domain…
<infinisil>
Yeah
<LnL>
yeah, that idea breaks down pretty quickly
<infinisil>
At which point you might as well store the full password for each domain
<LnL>
you could also rotate the master password, but then you need to update
<LnL>
_everyting_
<MichaelRaskin>
Passwords are state. One way to see it is to ask if you ever wanted to roll back all your password changes from the last week.
<__monty__>
Well masterpassword does it with a simple counter, so if you forget you just increment it one by one. I think the programs also remember it for you as a convenience.
<MichaelRaskin>
You also need to keep track of the password rule versions
<__monty__>
It's the price you pay for stateless password management.
<__monty__>
Imo the price is laughably low compared to the convenience.
<infinisil>
Soo, the state is still there, it's the program that remembers that counter for you
<infinisil>
As much as I hate state, we can't deny it's there and sometimes necessary
<__monty__>
Yeah but it's unimportant state. Because you can easily find it out again.
<MichaelRaskin>
Do you have good enough backups of everything? (I do _not_ mean everything related to access tokens, I mean all the useful data)?
<MichaelRaskin>
Because there is enough state to keep track of that a few encrypted entries shouldn't really create a problem…
<__monty__>
The problem isn't just backups.
<__monty__>
It's having state available in random situations.
<infinisil>
MichaelRaskin: Okay that's actually a good argument, when you only store these incremental indices, there's no need to encrypt them, in comparison to password databases
<LnL>
what would be amazing is if there was some kind of standard to rotate service passwords, then password managers could use that to make doing that sane
<infinisil>
There was an attempt of this I think
<infinisil>
Or a proposal
<LnL>
I feel like a monkey when doing that
<infinisil>
Oh regarding the "no need to encrypt these indices", you can also just get that property by storing a random number and deriving the password from the rules, the random number and the master key
<infinisil>
So that would be pretty much the same as Lesspass, so you might as well use domains haha
jasongrossman has quit [Ping timeout: 244 seconds]
<__monty__>
infinisil: You *could* get rid of the counter state by relying on the brain's pattern recognition. Just have the program return the passwords for indices 1..5 or some reasonable number of "resets", then rely on you recognizing rather than remembering the right password.
<infinisil>
It does sound interesting, but the password rules seem problematic
<MichaelRaskin>
Also, the sites who really want to generate a password for you
<infinisil>
__monty__: Not sure what you mean
<__monty__>
The random number introduces hard to/non-reproducable state again though. Then you lose the most interesting property of the system.
<ixxie>
just gotta set seed
<ixxie>
and rerun everything xD
<ixxie>
but then the seed is the important secret
<__monty__>
infinisil: Instead of returning one password it'd return 5, incrementing the counter from 0 to 4 or whatever. Then you rely on recognizing the password, rather than remembering the counter.
<infinisil>
__monty__: You need to store the state anyways, and there's no real practical difference between an increasing sequence and a random number. But I guess an increasing sequence is guaranteed to never repeat, so that might be better yeah
<ixxie>
those of you who use pass, how do you use it across devices?
<MichaelRaskin>
Where exactly do you expect to have this tool installed but not gpg?
<__monty__>
infinisil: The good thing about the counter is you can figure it out when you lose the state.
<infinisil>
__monty__: Oh, you mean I can just try out the first, second, third and so fourth index and use what works?
<__monty__>
Yep.
<infinisil>
Oh, but what about systems that limit your retry number?
<__monty__>
And usually you'd have some recollection of whereabouts you need to start.
<__monty__>
With the counter you still have a chance, with non-reproducable state you don't.
<infinisil>
Yeah, okay so sequences make sense I agree
<infinisil>
But you still want to store them, you could store them unencrypted though and it wouldn't be a tragic loss if you destroyed it, just gotta hope you remember how many times you approximately changed them for each service
<__monty__>
You could also get in the habit of using abc suffixes or something. Maybe you find it easier to remember domain-once, domain-twice, etc.
<__monty__>
How often do you need to reset specific passwords though?
<__monty__>
You should still cycle everything periodically so the counters do get reset.
<infinisil>
How would they get reset?
<infinisil>
Wouldn't you need to change the master password to reset the counter?
<__monty__>
You pick a different master password to cycle everything.
<ixxie>
are you two talking hypothetical or is this how masterpassword actually works?
<__monty__>
ixxie: It's how it works.
<__monty__>
I missed the start of the conversation though. Or did everyone just implicitly know infinisil was talking about masterpassword?
<infinisil>
__monty__: I have about 200 passwords in my current database, I don't want to change all of them..
<infinisil>
I think it was lesspass originally
<ixxie>
__monty__: the conversation began in #nixos where I asked if anybody uses LessPass, which is another stateless password manager
<__monty__>
That's too many passwords. You're not allowed to have that many passwords.
<infinisil>
Lol
<ixxie>
not allowed by who?
<MichaelRaskin>
I think I have a few times more
<infinisil>
It's important to change passwords occasionally though, the password manager shouldn't try to discourage that
<infinisil>
People already don't change them as often as they should
<infinisil>
(me included)
<MichaelRaskin>
I think with randomly generated passwords it is unclear if changing them for services not worth targeted attack on you makes any sense…
<__monty__>
infinisil: Hmm, decide on frequency groups? Have either a password per group or a seed per group?
<infinisil>
MichaelRaskin: Good point
<MichaelRaskin>
(and with a targeted attack in most cases it won't help anyway)
<infinisil>
__monty__: That seems complicated and problematic (what about changing groups, where do i store these seeds, do i need to have a password manager for the password for the groups?)
<infinisil>
Oh also another problem with these "stateless" password managers: If I want to change the master password, I'd need to go to each one of the sites and change the password there too
<infinisil>
With my current setup (passwordstore.org) I can just reencrypt everything with a new gpg key
<joepie91>
to see the failure mode of stateless password managers, just look at brainwallets :)
<ixxie>
infinisil: you run that on a server you access remotely I presume?
<infinisil>
ixxie: I use git with my server as a remote
<ixxie>
so you clone the encrypted tree and decrypt it with pass locally?
<infinisil>
joepie91: What happened with brainwallets?
<ixxie>
infinisil: is there some mobile interface for this or just another terminal?
<joepie91>
infinisil: they get plundered routinely basically, because human brains and persisting entropy are not very compatible
<joepie91>
to the point that the advice is now basically "do not use a brainwallet"
<ixxie>
joepie91: plundered or lost? xD
<__monty__>
infinisil: Re the seeds, you might do something like important or just impreddit.com, impgithub.com, etc., spamfacebook.com, spam4chan, etc., just pick something you'll remember easily.
<joepie91>
ixxie: both, but mainly plundered
<infinisil>
ixxie: I'm using passforios, can very much recommend, it's open source and being maintained :) https://github.com/mssun/passforios
<ixxie>
joepie91: by coersion you mean?
<joepie91>
ixxie: no, by people literally guessing the seed string :)
<joepie91>
ixxie: they are stateless and deterministically derived from the seed string (your 'password'), therefore if you can guess the password you have access to all the $$$
<joepie91>
stateless password management has pretty much the same problem
<__monty__>
joepie91: Wouldn't it be more usefull with a hook rather than an eye?
<ixxie>
infinisil: what I meant was about syncing with the remote.... these clients do that for you?
<joepie91>
__monty__: these are designed to hang on existing hooks :)
<joepie91>
and in that scenario an eye reduces falling-off problems
<infinisil>
ixxie: passforios can do a git pull for you, I assume others can too
<ixxie>
cool
<infinisil>
browserpass just uses the locally installed pass, so the syncing is deferred to that
<ixxie>
yeah I figured
<ixxie>
its the mobile apps that I was wondering about mainly
hedning has joined #nixos-chat
<infinisil>
There seems to be an android app indeed
<__monty__>
joepie91: The idea with stateless password managers is that you're capable of remembering one or a few actually safe passwords. The manager then expands those into however many you need.
<joepie91>
__monty__: yes, the idea behind brainwallets is the same
<joepie91>
the problem is that people don't actually pick safe passwords
<__monty__>
What I'm most worried about with stateful password managers is companies taking people hostage (talking about less tech savvy people here), "Oh, you want to stop paying us? Well good luck resetting *all* your passwords."
<__monty__>
I use diceware passwords, afaik those are safe.
<joepie91>
'stateful password manager' doesn't equate 'entrusting storage to a company'
<joepie91>
those are different things
<infinisil>
Don't most password managers allow you to export them?
<joepie91>
equate to*
<joepie91>
I use KeepassXC; I'm not relying on any company to not remove access, yet it is absolutely stateful
<iqubic>
joepie91: Is that managed by the command line application kpcli?
<__monty__>
Like I said, talking about less tech savvy people here.
<__monty__>
Apple for example technically allows you to export your passwords, one by freaking one, with mouse clicks.
<__monty__>
Not sure if it's possible on a smartphone actually.
<ixxie>
less tech savvy people wouldn'y use diceware passwords
<ixxie>
those are the ones who don't grok entropy
<__monty__>
And who's to say the companies will keep offering exports?
<infinisil>
__monty__: Ohh, the password manager thing on macOS?
<joepie91>
iqubic: I have no idea what kpcli is
jasongrossman has joined #nixos-chat
<joepie91>
__monty__: less tech-savvy people can use KeepassXC fine?
<iqubic>
it's a command line tool to manage keepass databases.
<__monty__>
Except it doesn't look as snazzy as the ones hosted for you.
<joepie91>
ok....?
<__monty__>
ixxie: I think we can teach them to remember *one* secure password. Of course it doesn't work if they need to remember 20.
<ixxie>
yeah true
<__monty__>
joepie91: You can scoff at marketing but it works on most people.
<ixxie>
but the points about changing passwords stand
<ixxie>
so now when I am trying to decide what to use, I am leaning towards a stateful option like infinisil's approach
<__monty__>
They're not really points though. They're things stateless password managers state up front. "You can use us but keep in mind..."
<__monty__>
At least masterpassword tries to make it clear.
<ixxie>
yeah they do
<ixxie>
but its a problem for me
<joepie91>
__monty__: I'm sure it does, but that has zero relevance to the discussion of things being held hostage by a company
<ixxie>
I wanna be able to easily change passwords
<joepie91>
that just isn't something that's inherent to stateful password management
<joepie91>
so arguing for stateless password management on that basis makes no sense
<iqubic>
I use keepass and it's fine
<__monty__>
joepie91: "There's a *free* alternative where you can't be held hostage!" is what's irrelevant to the hostage scenario.
ar1a has joined #nixos-chat
<ar1a>
hey all
<__monty__>
ixxie: Yeah, then stateless is out.
<iqubic>
but then again... I have firefox store all of my passwords it its database, sooo....
<__monty__>
ixxie: Unless you accept the counter state as being acceptable and less of a drag than conventional password db.
<infinisil>
__monty__: Where does masterpassword explain the problems with that approach? I can't find it on the homepage
<ixxie>
__monty__: but changing the master password is still harder though...
<ixxie>
and that is the one you should change the most often, ideally
<iqubic>
I haven't changed my Master Password in a year.
<infinisil>
ixxie: It is? I'd think the master password is probably the most secure one, because it's entirely in your control and only in your mind (hopefully)
<__monty__>
Yeah, it's never transmitted over the wire so it shouldn't have to be changed often at all.
<infinisil>
Changing passwords on websites is mostly useful in case of a password leak (which are occasionally popping up)
<__monty__>
Having to change it is mostly because of user error, like sharing your master password with someone.
<iqubic>
my master password is over 10 characters long.
<iqubic>
Except I used the name of a character from an obscure video game as one of the words, and I inserted @ into the middle of one of the words.
<ixxie>
infinisil: I guess my logic is that I am worse at security than a team of engineers at some company, and the master password is a single point of failure for pwning my net identity
<__monty__>
infinisil: Hmm, the site's been changed. Used to have a lot more technical info about the algorithm. Only mention is in the "I share some of my accounts..." dropdown now.
<infinisil>
ixxie: Hmm yeah, you have a point
<__monty__>
Tbh, that's a terrible move on the part of the dev imo. I liked it because it was so up front about all the disadvantages that came with it.
<ixxie>
infinisil: this is why I have been hesitant to do pass and host it myself
<ixxie>
infinisil: however, it seems safer than doing what I do now
<infinisil>
ixxie: What do you do now?
<ixxie>
infinisil: you don't wanna know
<ixxie>
its not that bad
<ixxie>
but not optimal
<__monty__>
ixxie: Uhm, but stateful still relies on your one master password?
<__monty__>
Or do you think an attacker wouldn't be able to guess your username/email?
<ixxie>
__monty__: yeah but its easier to change the master password
<infinisil>
__monty__: Ah darn that's a shame then. Services that up-front tell me their disadvantages/what they can't solve gives me a lot of trust in them, more so than if they don't do it
<__monty__>
infinisil: The site used to basically be just an explanation of the algorithm and the implementation.
<__monty__>
I think masterpassword's the oldest stateless password manager btw.
<__monty__>
I guess lhunath wants to make some money off it, maybe he was afraid to have people lose interest because of the disadvantages?
<__monty__>
ixxie: Easier to change sure, but also more vulnerable to things like sniffing. The zero network traffic of stateless means it's a lot more secure.
<ixxie>
infinisil: because its run locally by relying on determinist algos
<__monty__>
infinisil: Why would there be network traffic? You don't need to fetch any state.
<ixxie>
__monty__: can people sniff my ssh?
<infinisil>
__monty__: Oh you mean how some stateful password managers use a web service to store them
<infinisil>
I think that's orthogonal to statefulness. There can be stateless web-based passwordmanagers and stateful local ones
<ixxie>
infinisil: or how some people use a git repo to centralize their statefull password mgmt xD
<ixxie>
infinisil: but the stateless ones make it a selling point, so I think they normally don't have a centralized deployment
<__monty__>
infinisil: Well, I assumed because ixxie said they'd rather pay for a team of engineers to worry about it.
<ixxie>
__monty__: that is not what I said
<__monty__>
You didn't?
<ixxie>
I meant that that it seemed to me that it is more important to rotate the master password than the service passwords because I am a single point of failure with no security training and the services have trained engineers
<ixxie>
that applies to stateful and stateless managers
<__monty__>
Not to stateless though, since they don't allow easy master password rotation, that's why I assumed you were talking about hosted stateful.
<__monty__>
ixxie: Why do you distrust yourself so though? Do you think you'd regularly share your master password on irc?
<__monty__>
Or do you fear you won't be able to come up with a good one.
<ixxie>
__monty__: that is the problem, you can't, which is why I am leaning to stateful.
<ixxie>
__monty__: I don't think I will do such stupid things; I think its more like, I might not update one of my devices, and then have some exploit listen in on my keystrokes and steal my master password
<ixxie>
__monty__: or any number of other things I can do wrong when maintaining my own systems
iqubic has quit [Ping timeout: 264 seconds]
<__monty__>
If they keylogged you you still have to change all the passwords in your vault. Not only were some of them probably logged as well but you have to assume they have a copy of everything in your vault.
iqubic has joined #nixos-chat
<infinisil>
ixxie: __monty__: I wonder if this "to change the master password you need to change all service passwords" problem can be solved by doing what LUKS does: Use the long private key for everything, and allow changing the password to that key without having to change the key itself
<infinisil>
(Currently trying to find out how they're doing it)
<ixxie>
or rather, the content doesn't get keylogged
<iqubic>
even if it does, will that give away the password?
<gchristensen>
if it has presence on your computer, then it can copy away the database and the key
<gchristensen>
if it has key-logging capabilities, it is pretty trivial to see "oh, ctrl-c ... *dump*"
<ixxie>
oh true
<ixxie>
I guess I just argued against self hosted password management in general then >.<
<__monty__>
ixxie: Any decent keylogger logs clipboard.
<gchristensen>
I don't love (at all) "stateless" password managers ... but that is me.
<infinisil>
I like the idea of only storing something non-secret per service (the counter + the password generation rules), but would like to not have the disadvantages we've discussed
<__monty__>
I'm only on the radical fanboy side of the fence because the discussion'd be pretty one-sided here otherwise it seems. I'm more of a balanced individual tbh. "If you don't mind the disadvantages I recommend stateless, otherwise stateful is still better than nothing."
<__monty__>
infinisil: I've thought about that as well.
<gchristensen>
I store other data with my passwords
<infinisil>
gchristensen: Oh yeah, I do too actually
<infinisil>
E.g. recovery keys
<__monty__>
Problem is threat model. How would someone find out your master password? Unless you go around telling people about it, probably some sort of keylogger? If they can attack you with a keylogger it's pretty trivial to get at your key probably...
<gchristensen>
yeah, I pretty much assume I don't have a keylogger
<ixxie>
and I guess a keylogger would pwn you no matter what you use
<ixxie>
LastPass or whatever included
<__monty__>
Yeah, masterpassword is/was gonna be (I think) hybrid. Use stateless as much as possible, password, security questions, etc. Use state for things you have to, work password you can't change for example.
<infinisil>
__monty__: It will always happen to some people, as much as it shouldn't. And if the password manager makes it incredibly hard to change it, people might even go "Oh well, it might be compromised, but it would be annoying to change it"
<infinisil>
If every service would implement a password change API endpoint, that would solve that problem
<__monty__>
infinisil: Yeah, I don't recommend stateless to non tech savvy people, (yet, hopefully : ).
<__monty__>
Yes please, and let's have this be the first thing everyone agrees to standardize from the get-go.
<ixxie>
or uuuh, we just make a universal authentication system?
<samueldr>
I do stateless passwords for sites I don't care about, makes it easier to get back in without my password store
<infinisil>
Yeah just wanted to say ixxie
<infinisil>
An universal authentication system is much more realistic
<ixxie>
OpenID is kinda close in some ways, but still problematic I guess
<samueldr>
one thing I liked with OpenID is how you could define your URL as delegating the auth to another service, and AFAIUI you could switch that service around and it'd still work fine
<samueldr>
so e.g. my.example.com would say "use ABC.auth.cool" and whenever auth.cool would fold, I only had to change my.example.com to point to XYZ.auth.cooler
<infinisil>
That leads me to the idea that everybody could get their own DNS namespace, essentially being their identity
<infinisil>
Which leads me to (dare I say it) blockchains! Namecoin could be used for that!
<infinisil>
That seems like a valid usecase for blockchains
<ixxie>
that would be a noble fight to fight
<ixxie>
I would make a startup for it if I wasn't already busy fighting another battle
<samueldr>
I would be less annoyed by services like github if I could say `git.samueldr.com is github.com/samueldr`
<samueldr>
which bitbucket for a while allowed
<samueldr>
that way, whenever I want to switch to another service, repos would continue working*
<infinisil>
Doesn't github pages allow that?
<samueldr>
* assuming mostly compatible points
<samueldr>
pages, but not the actual *service(
lopsided98 has quit [Ping timeout: 246 seconds]
<samueldr>
I want git clone ssh://git@git.samueldr.com/cool-stuff.git to work as expected, but using a third-party service
<samueldr>
so I am in control of the "domain" where my projects are, so I am not trapped in a url
lopsided98 has joined #nixos-chat
<samueldr>
just imagine a big project that moves to another service, how many things still point to the old service
<infinisil>
Ah yeah that would be neat
<infinisil>
samueldr: Does a DNS redirect work?
<ixxie>
samueldr: but of course that begs the question in a sense, because now DNS becauses a huge points of failure
<ixxie>
but I guess it always is
<samueldr>
infinisil: no such thing
<samueldr>
infinisil: if I CNAME/A to github's servers, it might just as well serve github.com, a blank page or worse, a rickroll
<jasongrossman>
samueldr: I don't understand what you mean by "it might just as well" here.
<samueldr>
after the domain name, the http server handles, it will receive "hi I want the page /cool-stuff for domain git.samueldr.com" and the http server will most probably error out saying "I don't know git.samueldr.com"
<infinisil>
Hmm, I see
<samueldr>
or it might serve from a default config, which the it would be like asking "example.com/cool-stuff"
<samueldr>
domain names and paths, while close in an URL, are totally at different levels
<samueldr>
and they don't work well together
<jasongrossman>
samueldr: Oh, I see, yes. Thanks.
<samueldr>
and here "might as well" is through configuration
<infinisil>
samueldr: What if you put a webserver on your end that redirects to github?
<samueldr>
infinisil: you wanna put your credentials in there?
<samueldr>
and it only handles the https part
<samueldr>
cloning through ssh won't really work :/
<samueldr>
though yeah, the ssh bit of git makes this an impossible problem to solve "right" since ssh has no concept of hostnames
<samueldr>
so it'd have to serve the whole lof ot the service on the domain, so git clone ssh://git@git.samueldr.com:NixOS/nixpkgs.git would clone nixpkgs
<samueldr>
not necessarily the worst, but an annoying thing to keep in mind
<ixxie>
thanks for the schooling folks, have a good evening
<__monty__>
ixxie: Thanks for the discussion and good night.
<infinisil>
Yeah thanks for the discussion
<jasongrossman>
samueldr: Yes, I know about this - just didn't understand that this was what you were referring to.
<samueldr>
I would like it if more things used SRV records :/
ixxie has quit [Quit: Lost terminal]
<jasongrossman>
samueldr: ("referring to" - pun not intended)
<jasongrossman>
Night ixxie
<samueldr>
like e.g. having _git._tcp.git.example.com SRV [some configuration git can use to figure out where to go] would be golden