Nix: Strings can't contain null byte

Created on 6 Apr 2017  路  9Comments  路  Source: NixOS/nix

Inconvenient for representing random data (secrets).

bug

Most helpful comment

why has this been closed? this feature is essential, wtf? a "language" which is unable to handle binary data.
Just came across this nonsense, trying to readFile "some encrypted secrets" and NO, don't impose your opinion as to what a secret should constitute, what an arrogant response, just implement this shit once and for all.

All 9 comments

For now it might make sense to hex/base64-encode that data, if it must go through strings in the first place. Can you elaborate on a use case that leads to strings containing cryptononsense in the first place?

Sure, but we don't have Base64 -> String within Nix, making this usage a bit of pain.

The use case is for example NixOps keys management, where we could obviously add a way to use a path instead of a string for the secret source, but that's just a workaround.

I believe secrets should be small bits of text, otherwise it smells. Base64 in Nix wouldn't help, because you would get... same weird binary data. Instead, I think services should build their binary secrets, if any, at runtime.

I've seen a lot of types of secrets: SSL keys, passwords, configuration files, GPG keys (armored though). None was binary.

There is base64 in Nix, but as I said it wouldn't help :)

@ip1981, that's the moment when a tool starts to impose an opinion on a craftsman : -)

Sometimes we just don't have control over the choice/behavior of software we want to deploy with NixOps -- and so we beg for mercy : -)

why has this been closed? this feature is essential, wtf? a "language" which is unable to handle binary data.
Just came across this nonsense, trying to readFile "some encrypted secrets" and NO, don't impose your opinion as to what a secret should constitute, what an arrogant response, just implement this shit once and for all.

Nix is not a general purpose language and being able to handle binary data is not a use case for which it was designed.

@voobscout the issue is still open, no need for aggression.

@edolstra - there are users of this language, which are jumping through hoops just to have simple things done, I discovered many workarounds, done by different sufferers over the years. This is no longer your thesis research project, there are real users and usecases, why make us all suffer?

@domenkozar - no aggression, just frustrated dealing with nix "specialization" and seeing a basic BUG that's been opened for 3 years is just adding more fuel to it.

And ofcourse I totally realize, that Nix team will take a piss on me, since who am I to ask for stuff, which makes me maintain my own fork of Nix, only because I wanted a basic bug fixed.

Submitting a PR for this essential feature is futile, I appreciate the super-polite response of the creator, but in all honesty I would've taken a - "Go, write your own stuff" and that's basically it.

Submitting a PR for this essential feature is futile

@voobscout Seems way too early to jump to that conclusion. I'm sure a proof-of-concept implementation would go help with judging how feasible it is. (I believe many strings in nix use std::string, which should make it easier to do this in contrast to C-style null-terminated strings.)

who am I to ask for stuff

Well I don't know that, but nix has 1300 open issues, all of which are probably very important to at least one person. Complaining louder doesn't get more stuff done in the open-source world; coding does.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

edolstra picture edolstra  路  96Comments

copumpkin picture copumpkin  路  41Comments

Profpatsch picture Profpatsch  路  73Comments

domenkozar picture domenkozar  路  53Comments

lilyball picture lilyball  路  67Comments