<{^_^}>
nix#719 (by wizeman, 4 years ago, open): Nix garbage collects too much
<infinisil>
That issue is really annoying and I wish it was fixed..
<infinisil>
Well I guess flakes will resolve this actually
<infinisil>
Probably
<gchristensen>
oh?
<infinisil>
gchristensen: Because with flakes you won't be using IFD anymore, but rather specify all dependencies you need Nix code from as separate flakes
<infinisil>
Probably
<gchristensen>
oh I didn't notice the ifd
<infinisil>
Is it possible at all to pin nixpkgs with IFD but not rely on fetchTarball or so?
<gchristensen>
you specifically want to use IFD?
<infinisil>
gchristensen: Is there an alternative?
<gchristensen>
what about builtin?.fetchGit?
<infinisil>
Ah I'm counting this under the "or so". The thing that these builtins.* fetchers have in common is that they don't actually return a derivation, but only a source path in /nix/store, with it being cached in ~/.cache/nix
<gchristensen>
which is why it isn't IFD
<infinisil>
Hm yeah
<infinisil>
So yeah I specifically want to use IFD
<gchristensen>
for testing purposes, or for another purpose?
<infinisil>
Probably yeah, I'm kind of hoping I can gcroot them maybe or do other fancy things. I also think https://github.com/nmattia/niv/issues/198 has the same reasoning
<{^_^}>
nmattia/niv#198 (by nmattia, 2 weeks ago, open): Do not use builtin fetchers by default
<gchristensen>
ah
<infinisil>
Idea: Extract the stdenv and tar bootstrapping things from nixpkgs into a single file, expose that file at some url, then `builder = "builtins:fetchurl"` that and import it
<infinisil>
Um
<infinisil>
Then you can use a normal fixed-output derivation to fetch nixpkgs itself and untar that
<infinisil>
Or maybe use /bin/sh and an impure `tar`..
<infinisil>
builder = "/bin/sh"
drakonis has joined #nixos-dev
<infinisil>
Oh also: builtins:fetchurl *is* used often, but via <nix/fetchurl.nix>
<infinisil>
Just noticed that
<gchristensen>
<nix/fetchurl.nix> is the public API, builtins:fetchurl isn't afaik
<infinisil>
Hehe, how about writing a tool that inlines all `import`'s in nixpkgs, such that it's a single huge file
<infinisil>
Ohhh that thing for nixos configs, I remember now
<gchristensen>
:)
<gchristensen>
this is going strong btw, working great for me. I haven't had enough time to regret it yet.
<infinisil>
Nice
<gchristensen>
I've had to be careful to stay as data-only as possible. no kernelPackage setting.
<infinisil>
I was just wondering how hard it would be to serialize generic configuration.nix's
evils has quit [Ping timeout: 240 seconds]
<gchristensen>
probably pretty easy until you hit a { [..snip..] }:
<infinisil>
How about `builtins.serialize <arbitrary expression here>` returning a string of a pure Nix expression returning that
<infinisil>
I feel like that might even be possible
<infinisil>
Oh but use cases would be pretty amazing: In nix repl you could `:write some-varibale-you've-been-working-on-for-1-hour file.nix`
<infinisil>
It would allow `nix-env -E 'with import <nixpkgs> {}; hello.override { ... }` to store the actual expression, keeping the overrides for updates
<infinisil>
It would allow configuration.nix's to be serialized/minimized
colemickens_ has quit [Quit: Connection closed for inactivity]
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
lovesegfault has quit [Ping timeout: 272 seconds]
lovesegfault has joined #nixos-dev
ixxie has joined #nixos-dev
cole-h has quit [Ping timeout: 255 seconds]
lovesegfault has quit [Ping timeout: 255 seconds]
drakonis has quit [Quit: WeeChat 2.7.1]
Jackneill has joined #nixos-dev
ris has quit [Ping timeout: 258 seconds]
<niksnut>
infinisil: builtin:fetchurl supports unpacking NARs for the stdenv-linux bootstrap
<niksnut>
but we never got around to using it
<niksnut>
the idea is that you don't need to fetch busybox (or previously curl, tar, ...) first just to unpack bootstrapTools
<LnL>
oh really?
<clever>
2 nixcons ago, i was also talking to somebody about a bug in that area, where builtins.fetchurl was auto-unpacking a compressed file, which then broke things that tried to uncompress it again
<genesis>
fun it works on directory nix log /nix/store/05k1nvzffkdrb94lc586q0y8my8mbggl-cadence-0.9.1
<worldofpeace>
I don't maintain openssh, so I don't know to approve or reject this. Anyone have any opinions?
<emily>
worldofpeace: updating a minor release of security-relevant software seems like probably a good idea?
<emily>
or at least not likely to be a terrible idea
<emily>
(it also adds u2f support which a lot of people are likely to want to try out and would miss not having for the entire 20.03 release cycle, but that itself is probably not a good thing to take into account when backporting security-relevant software)
drakonis has joined #nixos-dev
<emily>
the rsa changes are probably good to have, albeit mostly in the form of disabling things
<gchristensen>
we cannot disable RSA at this point in the release processof 20.03
<emily>
you can readd it aiui
<emily>
actually it's kind of confusing
<gchristensen>
you can re-enable it for sure
<emily>
the release notes say they're disabling it in a future release, and then that they're disabling it this release
<qyliss>
they're disabling RSA for certs, IIRC
<qyliss>
in this release
<emily>
ah
<gchristensen>
if `ssh-keygen -t rsa`-generate SSH keys are broken -> no go. if they continue working -> okay
<emily>
SSH CA is a pretty rare feature to use anyway
<emily>
so I think that should be fine
<qyliss>
this release removes the "ssh-rsa"
<qyliss>
(RSA/SHA1) algorithm from those accepted for certificate signatures
<qyliss>
(i.e. the client and server CASignatureAlgorithms option)
<qyliss>
I do not expect this to affect very many people at all
<gchristensen>
+1 shipit :P
<samueldr>
I don't think it's a "minor" release
<emily>
gchristensen: it's only for CAs, ssh pubkeys will still work
<emily>
samueldr: I guess it's arguable with openssh's release cadence/versioning scheme
<emily>
I would say openssh releases tend to be pretty conservative in general though
<samueldr>
yeah, it's just "a" release, minor/major are not well defined terms, and they are generally noe applicable at large
<samueldr>
not applicable*
<worldofpeace>
At a glance, I just see it's wanted to be backported because features. We shouldn't usually do backports just because of that.
<samueldr>
it'd be interesting to classify updates with qualifiers that explain there are no breaking changes, no new behaviour, only bugfixes, etc, but the ship probably has sailed for that decades ago :/
<qyliss>
It's very difficult to do, in practice
<qyliss>
One person's bug fix is another's breaking change
<samueldr>
yep
<gchristensen>
«xkcd control key heater»
<qyliss>
semver tried and failed
<gchristensen>
"OpenSSH 8.2 was released on 2020-02-14." that is pretty, uh, fresh :P
<emily>
samueldr: any package that uses semver gets that "for free"
<emily>
insofar as semver can be trusted
<emily>
some ecosystems are stricter about it than others
<samueldr>
yeah
<emily>
realistically it's not something nixos could provide on top of other projects without taking a much more active role in maintenance than it does
<emily>
maybe debian investigates/mangles software updates enough to actually reliably write those
<gchristensen>
it is a lie anyway
<worldofpeace>
gchristensen: same evaluation on this side. It kinda sucks that a season of nice releases happens after at the same time we release
<gchristensen>
getting mired on old software is a trap. one of NixOS's greatest features is making the upgrades and changes understandable
<samueldr>
oh, I wasn't implying anything nixos in there, simply that it'd be nice to go back a couple decades back and better steer software in "marketing" changes right
<worldofpeace>
* after or at the same time
<gchristensen>
worldofpeace: on one hand, I feel really confident that problems in 8.2 will be quickly fixed by the project, and then we're in a good spot to release them to stable.
<gchristensen>
on the other, it is a big upgrade /right/ before release :P
<gchristensen>
so I'm +1 on not backporting, fwiw.
<gchristensen>
(but not -1 on backporting)
<qyliss>
How long will 8.1 get security updates?
<emily>
samueldr: in rust you can do git log --grep='[breaking-change]'
<emily>
and it's pretty reliable
<emily>
rust-lang/rust itself that is
* samueldr
withdraws from the versioning discussion
<emily>
sorry :p
<worldofpeace>
gchristensen: I feel similar
<gchristensen>
qyliss: a good question that I don't have an answer to. can you look?
<qyliss>
Can't find anything
<gchristensen>
maybe #openssh can answer
<qyliss>
so maybe there is not a clear answer
<gchristensen>
(and maybe they will make this decision very easy :))
lovesegfault has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-dev
<worldofpeace>
Thanks everyone, I think asking in #openssh about this would help to make the decision clearer.
<gchristensen>
I would love to check, but unfortunately gpg-agent has eaten my keys :|
<emily>
samueldr: nice, so some ssh-rsa keys are going to break and not others
<emily>
that is great and not at all confusing or terrible
<emily>
they should just deprecate RSA :P
<emily>
(disclaimer: this is all about a future release, not 8.2)
<samueldr>
while I'm getting knees deeper in the firefox build issue in aarch64, anyone has tips to help work with firefox issues?
<samueldr>
ooh, might have lucked out and found a related patch
<samueldr>
(upstream)
<samueldr>
now that hashes look like sha256-94jlP07t9kC5t9f4y0pWQt4V/fa0SkZfTsFQfXg5miw= in the default output, should we prefer that form in nixpkgs updates?
<samueldr>
I think the 52i0 tofu is weirdly appropriate: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
lovesegfault has quit [Quit: WeeChat 2.7.1]
* emily
really wished builders let you use tofu as a hash or something
<emily>
so I don't have to get the right amount of 0s all the time
<emily>
as in something that just unconditionally fails hash checks
<gchristensen>
oh
<gchristensen>
not a probably-wrong hash, but a guaranteed-wrong hash
<qyliss>
Is the distinction really important?
<gchristensen>
it depends if we ever find a build which actually hashes to 0
<qyliss>
(which we wont)
<emily>
qyliss: til, thanks. requires you to add lib to the package imports though
<emily>
which is why a string would be nicer
<qyliss>
emily: there's also stdenv.lib.fakeSha256
<emily>
"nicer"
<emily>
I mean, the whole tofu stuff is horrible, but UX-wise
<gchristensen>
(oh)
<emily>
qyliss: hm, right
<qyliss>
or rather, if we do find a build that hashes to all zeroes, we should stop using sha256 immediately
lovesegfault has joined #nixos-dev
<gchristensen>
but isn't an all-0 hash just as likely as any other hash?
<emily>
qyliss: that's not really accurate... there's no difference between all zeroes and any random 23 bytes you pull out of /dev/urandom
<qyliss>
gchristensen: correct
<emily>
it's more like it's so statistically improbable that we should start trying to figure out what the intended message from the god of our universe-simulation is
<gchristensen>
so then why would finding one mean we should ditch it?
<emily>
it doesn't imply any breakage of sha256 unless it was intentional
<emily>
(which admittedly is the far more likely reason for it to happen)
<emily>
32 bytes
<emily>
rather
<qyliss>
Because if you can find an input for any chosen output, the hash algorithm is broken
<gchristensen>
I'm not saying a chosen output
<qyliss>
All zeroes is a chosen output
<gchristensen>
uh
<gchristensen>
okay, my chosen output is 210b32af8372b8f68f261fdb7394075669222608d1e6a3bbf2031d59c826eb68. if you can find a file matching this chosen output, it is broken?
<qyliss>
Yes
<gchristensen>
okay
<qyliss>
(Assuming you didn't choose that by hashing something)
<gchristensen>
django-tagging 0.4.6's pypi release has broken sha256.
<qyliss>
that is extremely obviously not what i meant
<gchristensen>
I'm saying it is just as likely that some software tarball hashes to 210b32af8372b8f68f261fdb7394075669222608d1e6a3bbf2031d59c826eb68, and thusly it is perfectly possible that we'll see a software release which does hash to 0000000000000000000000000000000000000000000000000000000000000000 for a completely inoculous reason
<qyliss>
It's perfectly possible, but so improbable that we can assume it won't happen, and that if it does the cause is something else.
<gchristensen>
okay
<qyliss>
And if you had picked 210b32af8372b8f68f261fdb7394075669222608d1e6a3bbf2031d59c826eb68 before attempting to hash anything, it would be equally concerning if we then discovered something that hashed to it
<emily>
gchristensen: qyliss's point is that the probability of something hashing to 000... or 210b... is ~2^-256 (if sha256 is not broken)
<gchristensen>
sure
<emily>
so if you fix any particular hash prior to observing it as a hash result, it's more likely that your computer had a bunch of RAM bitflips and incorrectly reported that hash, than it is that the hash actually matches what you picked beforehand
<emily>
the key part being "if you fix ...", it's only unlikely to see 210b32... after you pick 210b32..., not if seeing it as a hash result is the first time you see it, so to speak
<gchristensen>
yeah I get it :P
<qyliss>
then why the pointless trolling?
<gchristensen>
well I didn't think I was trolling, but now I realize you thought I was trolling
lovesegfault has quit [Quit: WeeChat 2.7.1]
<gchristensen>
and I didn't mean that
<gchristensen>
and I'm sorry
<qyliss>
20:43 <gchristensen> django-tagging 0.4.6's pypi release has broken sha256.
<qyliss>
I'm not sure how that was anything but...
* emily
wasn't trolling either, just didn't understand your argument before ~20:41
<gchristensen>
it was an extreme example which seemed to disprove what you were saying. where I was coming from the scenario where an all-0 hash came up as naturally as the 210b3... hash.
<qyliss>
I see
<gchristensen>
does that make sense?
<qyliss>
Yeah, I think so
<gchristensen>
cool
<gchristensen>
I'm glad :)
<samueldr>
now that this is solved, any reason not to use `sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=` in nixpkgs?
<samueldr>
when was that form added to nix?
<gchristensen>
I think it is quite new still
<samueldr>
we'd want nix to still evaluate in like, two nixos releases prior, right?
<gchristensen>
yeah
<samueldr>
nixpkgs to evaluate*
lovesegfault has joined #nixos-dev
<samueldr>
C.2. Release 2.2 (2019-01-11)
<samueldr>
>> Nix now supports SRI hashes
<gchristensen>
hmm :)
<samueldr>
that's exactly two releases prior, right?
<samueldr>
though backporting to 20.03 is iffy
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-dev
lovesegfault has quit [Client Quit]
lovesegfault has joined #nixos-dev
lovesegfault has quit [Client Quit]
lovesegfault has joined #nixos-dev
drakonis_ has quit [Ping timeout: 272 seconds]
drakonis_ has joined #nixos-dev
<gchristensen>
I experimented with a little function today: src = exactSource ./. [ ./Cargo.toml ./Cargo.lock ./src/main.rs ... ]; producing a source directory of exactly those listed files in that same shaped tree