worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced https://discourse.nixos.org/t/nixos-20-03-beta/5935 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
<infinisil> niksnut: Could the builtin:fetchurl builder be changed to allow unpacking arbitrary archives? Like how fetchTarball works
<infinisil> I'm kind of wondering why it only supports nar archives, I don't see any use of it anywhere in nix or nixpkgs
<gchristensen> if builtin:fetchurl supports NARs, I'd wager a bet it is an accident of implementation than intent
<infinisil> It sure looks like it was meant to be
<infinisil> Even has a (generic) `unpack ? false` argument
<infinisil> Eh whatever, it wouldn't work to fix https://github.com/NixOS/nix/issues/719, which I somehow thought it would originally
<{^_^}> 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
<gchristensen> I did but you didn't like it! :)
<infinisil> Oh??
<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
evils has joined #nixos-dev
lovesegfault has joined #nixos-dev
<infinisil> Well, too late for me, good night!
lovesegfault has quit [Quit: WeeChat 2.7.1]
orivej has joined #nixos-dev
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-dev
lovesegfault has joined #nixos-dev
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
__monty__ has joined #nixos-dev
<Mic92> worldofpeace: do you think another meeting is neccessary. Could you not just bring up your points in the RFC itself?
<infinisil> niksnut: Ah i see
tilpner has quit [Quit: tilpner]
<FRidh> Is there no issue with bootstrapping in case of custom store paths then?
<aanderse> niksnut: did you run into any problems with httpd at all?
teto has joined #nixos-dev
page_ is now known as page
clkamp_ has joined #nixos-dev
<clkamp_> Since today I'm not able to request reviews any more on my PRs. Was there a change in the rights?
tilpner has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
clkamp_ has quit [Ping timeout: 260 seconds]
madjar has joined #nixos-dev
Taneb is now known as nvd
<teto> clkamp https://www.githubstatus.com/ may be related, I can't merge prs right now
<gchristensen> wowowow github has been /sick/ lately.
vcunat has joined #nixos-dev
<gchristensen> I always get advanced notice of github outages from my own ofborgmonitoring paging me
__monty__ has quit [Quit: leaving]
cole-h has joined #nixos-dev
genesis has quit [Quit: Leaving]
genesis has joined #nixos-dev
teto has quit [Quit: WeeChat 2.7.1]
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
vcunat has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 272 seconds]
lovesegfault has quit [Client Quit]
lovesegfault has joined #nixos-dev
<samueldr> nixos:release-20.03-aarch64 hasn't evaluated for a while, and nixos:release-20.03 doesn't seem to have aarch64 in yet
<samueldr> how is this expected to be solved, aarch64 in the main eval or fixing that alternative jobset?
<gchristensen> first one, then maybe the other
<gchristensen> link to the aarc64 jobset?
<gchristensen> error: aggregate job 'tested' references non-existent job 'nixos.dummy.x86_64-linux'
<gchristensen> looks like the new tested jobset format has some kinks to work out.
<samueldr> currently looking at the firefox breakage on aarch64
<samueldr> then, just saw neovim apparently might be broken, too
<mjsir911> Hi all. I'm trying to move along #72296 and was wondering if there's anything I can do, or should I just wait? Thanks
<{^_^}> https://github.com/NixOS/nixpkgs/pull/72296 (by mjsir911, 17 weeks ago, open): softether: add vpnserver.settings option
ris has joined #nixos-dev
_ris has joined #nixos-dev
ris has quit [Ping timeout: 252 seconds]
<samueldr> [samueldr@aarch64:~/nixpkgs]$ nix log /nix/store/w31k3wzbj9p179y6cvsx8f11jgpqd2k6-firefox-unwrapped-73.0.1.drv
<samueldr> error: experimental Nix feature 'nix-command' is disabled
<samueldr> :|
<emily> huh, is that new...?
<niksnut> in 2.4, yes
<samueldr> how could we access (local build) logs before nix log?
<niksnut> nix-store -l
<samueldr> thanks
<worldofpeace> It seems people are suggesting backporting #80196 https://www.openssh.com/txt/release-8.2 to 20.03.
<{^_^}> https://github.com/NixOS/nixpkgs/pull/80196 (by prusnak, 1 week ago, merged): openssh: 8.1p1 -> 8.2p1
<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> for now
<qyliss> release notes: https://lwn.net/Articles/812537/
<emily> (just since I had it open)
<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> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 73
<samueldr> btw, if some of you were questioning themselves, https://lwn.net/Articles/812557/
<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
<qyliss> lib.fakeSha256
<gchristensen> > lib.fakeSha256
<{^_^}> "0000000000000000000000000000000000000000000000000000000000000000"
<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
drakonis_ has quit [Ping timeout: 255 seconds]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
ixxie has quit [Ping timeout: 272 seconds]
drakonis_ has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
lovesegfault has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-dev
drakonis1 has quit [Client Quit]
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev