drakonis has quit [Remote host closed the connection]
Lisanna has quit [Remote host closed the connection]
ma27 has joined #nixos-chat
ma27 has quit [Ping timeout: 256 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
ma27 has joined #nixos-chat
ma27 has quit [Client Quit]
ma27 has joined #nixos-chat
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-chat
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-chat
jtojnar has quit [Quit: jtojnar]
ma27 has quit [Ping timeout: 265 seconds]
ma27 has joined #nixos-chat
Lisanna has joined #nixos-chat
ma27 has quit [Ping timeout: 265 seconds]
MichaelRaskin has joined #nixos-chat
nh has joined #nixos-chat
<MichaelRaskin>
In the unlikely case anyone cares: argh, Nix libstore force-chmods the store basically whenever it feels like that.
<LnL>
yeah, I know
<sphalerite>
haha
<LnL>
you also thinking about the separate store for secrets idea?
<MichaelRaskin>
Pity you didn't happen to be here yesterday.
<MichaelRaskin>
Nope.
<MichaelRaskin>
I just don't want to have readdir in /nix/store take forever when I didn't even want it
<MichaelRaskin>
Maybe the enforced permissions should be _way_ weaker. Something like «at least rwx--x--xt» (I know --x--xt doesn't make sense, but sticky bit is needed in some rare setups so better to include it in the guaranteed mask)
taktoa has quit [Remote host closed the connection]
<zybell_>
--x--t does make sense:you must know the name exactly(hash is passwd)!
<MichaelRaskin>
zybell_: and what does sticky bit do in this case?
<MichaelRaskin>
Yeah, with ACL it could be even useful, Iknow
Sonarpulse has joined #nixos-chat
<zybell_>
it does what it ever does:it protects one user from the other. No user can delete what another *owns*(there is nothing about 'can read')
<sphalerite>
zybell_: this doesn't apply for the nix store though, only root can write to it.
<MichaelRaskin>
Well, it could be group-writeable, but not with --x--t
<MichaelRaskin>
But theoretically one could use ACLs… not sure _why_
<zybell_>
I think the buildusers can too. And *they* may need it.
<MichaelRaskin>
Well, you could do that, please don't
<MichaelRaskin>
I mean, if the store is root-owned, normally the daemon creates a sandbox, and moves the path on its own after the build
<MichaelRaskin>
And if builders write directly, the store is usually just group-writeable
<zybell_>
and t
<zybell_>
It may make sense to make the 'group writeable' the opposite of 'start daemon'
<zybell_>
what djb s service does with x-bit on some files
<ekleog>
MichaelRaskin: btw, that's a bit painful, like when you cp a large file during a build you'd like to just ln it, but no, have to cp, wait a while and then when the nix-daemon notices it can optimize the two in .links it re-rm's it and ln's it
<MichaelRaskin>
No, daemon-or-no-daemon has little to do with group writeable
<ekleog>
(because $out and $in aren't on the same fs)
<MichaelRaskin>
There is still no option to have $out backed by a special .in-progress directory in store?
<MichaelRaskin>
Pity
<ekleog>
none that I know of
<MichaelRaskin>
I naively hoped it would be the default by now…
<ekleog>
anyway, would a ln work across a mount --bind?
<ekleog>
nope
<ekleog>
just tested and “ln: failed to create hard link 'b/bar.nix' => 'foo.nix': Invalid cross-device link”
<MichaelRaskin>
Argh
<ekleog>
so it's not even nix's fault here, just the sandboxing's one
<ekleog>
would have to write a custome fuse sandboxfs, I guess
<MichaelRaskin>
Am I allowed to start collapsing in pain already?
<ekleog>
(that said I already thought it might be nice for eg. containers and the like, having a sandboxfs that does like a mount --bind but with a whitelist of paths to allow)
<ekleog>
no you aren't :p
<MichaelRaskin>
Then I will have to do it without permission
<MichaelRaskin>
There just are a few packages where the build consists mostly of unpacking a gigabyte of data into $out
<ekleog>
yeah, hit exactly the same issue when building VMs in-store, it was so slow it became un-manageable, so I switched to generating the VM's store in /var on VM startup
<ekleog>
I wonder if disabling sandboxing would allow for `ln`, but anyway the packages are supposed to build both sandbox and unsandboxed, so…
<ekleog>
guess the only option'd be sandboxing with a sandboxfs :(
<zybell_>
you only need a RPC in daemon:link this.
<ekleog>
that'd be a pain to both write and maintain, and would likely be a source of security issues, so…
<zybell_>
the daemon checks the parms ofc,why else woud you need a daemon;-)
<ekleog>
I mean, even if there was a RPC for this, then we'd have to override ln, but then some programs would just call the link syscall by themselves and we'd need to ptrace them, and then it's bloated (granted, could work with just overriding `ln`, but then at least there'd be a need to support a few flags and it starts being painful)
<sphalerite>
it "starts" being painful? :p
<ekleog>
well, privileged daemons have a strong tendency to not properly check the parameters, so I personally only trust %wheel with access to the nix rpc, but I guess not everyone is doing the same, so…
<ekleog>
sphalerite: yeah, adding a RPC and wrapping `ln` are alright :D
<ekleog>
♪♫♪ lalala ♪♫♪
<zybell_>
norm ln is blocked by crossdev, only special $(LN) is allowed (which the makefile uses already)
<zybell_>
It is astounding how much is already standard
<ekleog>
feel like pushing for a PR to nix handling that? :D
<ekleog>
unrelated: lol the matterbridge module
<ekleog>
“#WARNING: as this file contains credentials, be sure to set correct file permissions” in example value of services.matterbridge.configFile
<ekleog>
(btw, please go +1 the last comment on https://github.com/NixOS/rfcs/pull/5#issuecomment-383613752 ; if there's enough +1 and noone re-triggers a lengthy discussion, maybe it can be merged and edolstra can land the commit that's waiting for it)
<MichaelRaskin>
I am afraid that's not how it works…
<ekleog>
MichaelRaskin: not sure, with unenumeratable I do systemctl cat matterbridge.service and boom I've got the hash of the config file
<ekleog>
s/with unenumeratable/even & store/
<ekleog>
nixos is leaking hashes everywhere
<MichaelRaskin>
Yeah, that's true.
<sphalerite>
yeah and nix-store --gc --print-{dead,live}
<MichaelRaskin>
But if you have unenumeratable store, you can encrypt normally
<MichaelRaskin>
Maybe printing will have to be restricted in the bright future
<ekleog>
hmm? but then you have to decrypt at some point?
* ekleog
can't see the link between (un)enumeratable store and encryption, for me the two are orthogonal
<MichaelRaskin>
Well, decryption key lives in a root-only non-store file
<ekleog>
also, /run/current-system/init can likely allow to trace the path up to the config files
<MichaelRaskin>
Store enumeration is what kills most of the implementations of encryption without explicit Nix support
<ekleog>
decryption key in a root-only non-store file… that's basically RFC5?
<ekleog>
(also, what makes me hopeful is that it's edolstra who actually wrote the commit for encryption, so if the RFC lands I'm pretty confident he'd agree to merge his own commit)
<MichaelRaskin>
But with trivial changes to Nix, without hardcoding encryption function choice into Nix…
* ekleog
can't really see how the store being non-enumeratable would change things here
<zybell_>
ekleog:dont see how the *example* attr is used?
<MichaelRaskin>
Well, with store enumeration you cannot have a derivation that encrypts in the build time, as the derivation file might be visible in the store
<ekleog>
oh, got it
<MichaelRaskin>
Well, you can but it is pointless
<ekleog>
so you have to ban nix-store -q --deriver too
<ekleog>
zybell_: ?
<MichaelRaskin>
ekleog: not really
<MichaelRaskin>
Hm
<MichaelRaskin>
Hm
<MichaelRaskin>
It's a good question where to make the cut…
<MichaelRaskin>
Maybe you are right, this is the cheaper place
<ekleog>
well, actually the RPC equivalent of nix-store -q --deriver, so as to avoid being able to just by-pass the removal of the option by using /nix/var/nix/daemon-socket/socket
<MichaelRaskin>
Of course.
<ekleog>
but even then, I'd feel better with actual nix-level encryption than with unenumeratable store with no way to access the deriver, if only because that'd allow me to not encrypt /nix/store and not feel in danger
<simpson>
It's cooler to slowly inch more towards a capability store.
<ekleog>
(and also because I think it's easier to secure a feature than an absence of flaw)
<MichaelRaskin>
Well, maybe both things are good
<ekleog>
(then, ideally there'd be both being un-enumeratable store *and* nix-level encryption, but that's for my sweet dreams :))
MichaelRaskin has quit [Ping timeout: 248 seconds]
* zybell_
has read RFC5
<zybell_>
ekleog:comment to RFC5 there should be a system'nonce' a value that is generated at system install in a manner to be reasonably sure that it is unique. because a nonce doesnt have to be confidential, it is system wide available, but not easily obtainable to make copying between systems a nonissue.
<zybell_>
the real nonces are generated by a decrypt daemon from user nonce and system nonce.
<ekleog>
zybell_: there is no need for a system-wide nonce
<zybell_>
with NixOps it is.
<ekleog>
only need a per-encrypted-string nonce that is stored alongside it, as per the RFC
<zybell_>
Because keys can repeat.
<ekleog>
keys « can » repeat is not the good term, keys do repeat (and actually with the RFC there is a single key, <nixos-store-key>, used for all encryption and decryption)
<ekleog>
but so long as the nonce doesn't repeat it's alright
<ekleog>
but the thing is, the nonce must be unique *per encrypted string*, not per nixos system
<ekleog>
I haven't looked at how nixops does thing, but from what I've heard of friends struggling with it before eventually switching to custom-made scripts built on top of nixos-rebuild, it's not necessarily a good example ;)
<ekleog>
s/thing/&s/
<zybell_>
and that is the goal of the sstem nonce:make sure that nonces never repeat.
<ekleog>
there are two ways of making sure a nonce never repeats, one is randomly picking it, and the other is making it move forward
<ekleog>
for nixos, I very very very much prefer randomly picking it
<zybell_>
sstem=system
<ekleog>
because I don't think the daemon can consistently ensure a monotonically increasing nonce value
<ekleog>
and it's much easier to just pick a random value
<ekleog>
(and colliding on nonces 2^128 long is not really an issue, so long as you don't encrypt terabyte-long files)
<zybell_>
how hard it is to pick a random value debian has demonstrated in singularly sectacular fashion.
<ekleog>
(and even with terabyte-long files it just means we'd have to think more about how to do it)
<ekleog>
if you don't have random values your crypto is dead anyway
<ekleog>
I mean, the *key* is randomly generated, so if your CSPRNG is actually not CS you're dead
<ekleog>
also, even if it were to be implemented with a system-wide nonce, I don't want it to ever appear in the user-facing process (which is what this RFC is about), because otherwise that'd mean I could just send a forged nonce for nix-daemon to use to encrypt and start having fun with collisions
<ekleog>
(which would completely break the crypto)
<zybell_>
it wasnt not CS it wasnt even really random
<ekleog>
is was stupidly broken, yeah
<ekleog>
because some debian dev thought it was a good idea to patch openssl to remove a warning from gcc
<zybell_>
I know
<ekleog>
but this led to *keys* that were not strong, the nonces weren't even an issue
<ekleog>
(btw, the real debacle was with RSA keys, which are notoriously vulnerable to not-actually-really-random RNGs)
<ekleog>
anyway, the nonce issue is an implementation detail that should be discussed at implementation time, I don't think it's good to delay even more this RFC, that has already been waiting for like a year, for implementation questions, as the point of the RFC is « is this interface OK or not? » (for technical RFCs)
<zybell_>
yeah but with an analog of debians fail the nonces of only 130 machines would collide with >50% on first use.
<ekleog>
hopefully your 130 machines don't have the same key
<ekleog>
otherwise you're completely done for already
<ekleog>
(also, the debian debacle has been *the* debacle in the last 20-or-so years, everyone has been speaking about since 2008, and it has lasted 2 years, so it's not really that frequent, and hopefully not all maintainers patch stuff based on complaints from valgrind)
<zybell_>
And that is where NixOps can fail for a short period after deployment.
<zybell_>
(the same key issue)
<ekleog>
… seriously, nixops is *that* broken?
<zybell_>
Its simply a matter of timing
<ekleog>
not only of timing, the same key should never be broadcast to all the machines
<ekleog>
anyway, back to the actual question of the RFC : the question is basically “is the interface made of `builtins.encryptString [key] [string]` and `nix decrypt [key] [file]` good?” and to this question the nonce issue is not relevant, because you'd never want the nonce to appear in the parameters to these functions (as it could be used for various cryptographic attacks otherwise)
<zybell_>
The image *will* be broadcast.If there are encrypted files in, you would need either the same key on all machines until the file can be reencrypted with an individual key or you want to make the file decryptable with multiple keys,a use case *your encryptString doesnt* provide for.
<zybell_>
You could use a keyList.
<ekleog>
wait, so you're deploying 130 bitwise-identical machines? if so then indeed there's no issue with pushing the same key on all machines (as they're all supposed to have access to the same information), but then using random nonces is actually a hard requirement, as you'd *never* manage to synchronize the nonces among the machines
<ekleog>
and using a key list for encryptString is indeed a possibility, but honestly I can't see any use case for it, just as using public-key cryptography as per the unresolved questions
<zybell_>
what I was trying to explain
<ekleog>
(actually, using a key list is not incompatible with the current interface design, you'd just have to set the encryption key to be a key list and the decryption key to be a single key in the key list)
<zybell_>
Only has to be documented.
<ekleog>
yup, and I'd love to first have encryption possible, before even thinking about key lists ;)
<ekleog>
(also because I still don't see the point of encrypting with multiple keys, when it's just as easy to duplicate the file to be encrypted with multiple keys, as encrypted portions should be in config files, so relatively small)
<zybell_>
But thats it exactly. Unless you cover *all* bases, you wont make progress in crypto, because in crypto its especially hard to change a design. for an example you can look at the TLS standardization.
<ekleog>
the thing is, you don't have to cover *all* bases, you can just add a builtins.encryptStringNew and deprecate builtins.encryptString if need be
<ekleog>
TLS has a much harder issue, that is the one of having to stay compatible with virtually every browser (among other softwae) that ever existed, and that leads to issues, just like JS, that's nothing crypto-specific
<zybell_>
That was tried with export ciphers in SSL, the success was mixed in the best case. And that wasnt about compat, because the stronger ciphers were available from the start.
<ekleog>
what. there's *no link at all* with export ciphers
<zybell_>
Not your use case,standrdization in general.
<zybell_>
Example
<ekleog>
anyway, I'll tell it one last time and then go try doing something more productive than xkcd386, the current RFC is enough to cover 90% of the use cases, and that's waaaay enough for me to not even want to consider the remaining 10% (even though I think it's actually covered too), as that'd slow things down so much that we'll still be at 0% ten years from now if we try to