<andi->
why impurities? Just have them as inputs on the flake interface?
<samueldr>
it was a "cute way" to say that
<samueldr>
they are required "impurities", though not environmental ones, but like, something that is needed for some evals
<andi->
we would probably want to specify not just the `system` but also the triplet of target-, host-, (forgot)-system
<andi->
I am thinking that you might want multiple system closures, cd images, … as output of one flake
<samueldr>
I think that's exactly why it's not thought of yet... those sound good
<andi->
Someone will probably come up with an idea... will sleep on it now :-)
johnny125 has quit [Ping timeout: 245 seconds]
johnny101m has joined #nixos-dev
<gchristensen>
a surprising number of things depend on ppp :(
<gchristensen>
oh dear webkitgtk depends upon it
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.4]
johnny101 has quit [Remote host closed the connection]
johnny101 has joined #nixos-dev
LnL has quit [Ping timeout: 246 seconds]
drakonis_ has joined #nixos-dev
Drakonis has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-dev
alp has joined #nixos-dev
FRidh has joined #nixos-dev
LnL has joined #nixos-dev
LnL is now known as Guest35612
orivej has quit [Ping timeout: 246 seconds]
Guest35612 has quit [Ping timeout: 245 seconds]
chaker has joined #nixos-dev
johanot has joined #nixos-dev
<chaker>
Hey, In Hydra, if you have a failed build and restart it, its log will be overwritten with the new one. From first loook to the repo, there's no way to change this behavoir currently. Should I open an issue in nixos/Hydra for this?
<niksnut>
chaker: sure, though it probably won't be very easy to fix
<niksnut>
logs are drv-addressed so there can be only one log per drv
LnL has joined #nixos-dev
LnL is now known as Guest33436
<chaker>
So we would have to change the way we address the stored logs. To be able to store multiple ones
<chaker>
The need for this is infrequent, but when we face an impure build ( one that fails with different error almost every time restarted) it's needed to fix it.
<chaker>
For now I can live with downloading the log of each run to my laptop.
<chaker>
Though, I guess if you can compile nix and provide it as a lambda function, it should work in principle.
<chaker>
That's said, lambda doesn't offer a C++ runtime
<chaker>
Also the execution time is limited to 15 minutes and most of the builds that I work with are higher than that :D
<chaker>
I stand to be corrected, C++ is indeed supported in Lambda.
<yorick>
chaker: the point is to do one gcc invocation per lambda and parallelize it to 2000 cores
alp has quit [Ping timeout: 264 seconds]
<chaker>
yorick: Yep, I got it, I saw the paper yesterday trending in HN. I was talking about building using Nix & Lambda. As the most granular entity in Nix is a build, we can't split it more to gcc invocation.
Drakonis has joined #nixos-dev
pie_ has quit [Ping timeout: 250 seconds]
drakonis_ has quit [Ping timeout: 264 seconds]
drakonis_ has joined #nixos-dev
Drakonis has quit [Ping timeout: 252 seconds]
Drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
<arianvp>
do we sign the ISOs at all?
<arianvp>
I can only find verification instructions for the nix installer. but not for nixos
<arianvp>
:/
orivej has quit [Ping timeout: 272 seconds]
__monty__ has quit [Ping timeout: 245 seconds]
<adisbladis>
chaker: It's pretty trivial to build most things to run in lambda
__monty__ has joined #nixos-dev
<samueldr>
anyone knows about a good software that uses map tiles, preferrably OSM, where I can at least drop pins wherever I want, and hopefully annotate however I want?
<samueldr>
not for publishing, for local consumption mainly
<samueldr>
oops, I was off by one channel
<samueldr>
arianvp: wouldn't that make sense only for manually vetted isos? our iso is piped from hydra to the server, so signing it (I think) has less value
<chaker>
arianvp: I don't think we do ( I wasn't able to found anything about that in the org repos ).
<chaker>
samueldr: Not sure, even if the ISOs are generated in Hydra,we should provide a way to verify that it was really generated there.
<samueldr>
which in the Details column has hashes to validate it's the same thing as built by hydra
<samueldr>
this (I think) fits the "verify it was really generated there" story
<samueldr>
and tangentially, you get the full path to realise it through nix
drakonis_ has joined #nixos-dev
Drakonis has quit [Read error: Connection reset by peer]
Drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
<chaker>
Yep, but if someone got access to the backend server of NixOS foundation he can change all of that. The goal from signing the ISO is that you can verify the identity of the owner using a 3rd party ( e.g. the key server ).
<gchristensen>
the reason we don't do that is the ISOs update automatically when the channel advances
<gchristensen>
and the Nix installer only updates at release time
<samueldr>
thanks gchristensen, you probably have a better handle on how to answer this :)
<gchristensen>
:)
<gchristensen>
one thing we could do is have the initial release signed, but it would be come extremely stale
<chaker>
gchristensen: Yeah, that explains it. But can't we automate the signin process?
<gchristensen>
no
<gchristensen>
because then, as you say, if someone got access to the backend server of NixOS foundation he can change all of that.
<gchristensen>
the Nix cache is all signed of course, automatically, with the Nix signing key -- but not using GPG
<samueldr>
gchristensen: the iso itself would become stale, but is it that big of an issue? I imagine an "evergreen installer" iso could fetch the channel to the last revision before installing, rather than relying on whatever channel the iso was released at?
<chaker>
(I'm in no way an expert in security, in the contrary :D, I just want to follow the discusion that arianvp started )
<gchristensen>
right
<samueldr>
sounds like a good alternative for a hand picked signed iso, also good to publish for those asking for torrents?
<arianvp>
but we dont sign files individually.. we sign the NARs
<gchristensen>
important to consider this, and how to fix this: what does verifying the ed25519 signature do for you? it ensures the key listed on the website matches the key used to sign the artifact. how do you get the artifact? from the website. how do you get the key? from the website.
<arianvp>
true
<arianvp>
TOFU
<gchristensen>
a lot of signing's value came from the fact that you fetched the artifact from mirrors
<gchristensen>
so you'd get the key from www.debian.org and then could fetch it from gregs-homepage.com and verify it matched
<gchristensen>
the rest of signing's value comes from WoT
<gchristensen>
presumably you could check a bunch of people's homepages and find their keys and then see that their key was used to sign the debian signing key, and then have a fairly reasonable way of deciding it was trustworthy
<gchristensen>
(unless you had the holy grail of attending or a friend who attended a key signing party)
<arianvp>
signing still has use without WoT
<gchristensen>
no doubt!
<gchristensen>
but out of the box, signing leaves bootstrapping trust as an exercise to the reader
<gchristensen>
we definitely do not want to go back to a world without signing
<arianvp>
and since we're doing very similar signing process for the cache as openbsd is doing, perhaps we can steal some of their ideas regarding trust?
<gchristensen>
so the question to answer is how does openbsd bootstrap a user's trust in this ed25519 key
<arianvp>
> Note that the signify package on other operating systems may not include the required public key, or it may be installed in another location.
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):255:97
<gchristensen>
their answer is to put it everywhere
<gchristensen>
"There are no key servers for signify. No web of trust. Just keys. The good news is the keys are pretty small. As demonstrated. We can stick them just about everywhere, and we do. They're on the web site, they're on twitter, they're on the top side of CD. 56 base64 characters. You can read it out loud over the phone in under a minute."
<gchristensen>
so, we could do that, yeah
<arianvp>
put them on swag we hand out during nixcon :P
<gchristensen>
sure :)
<arianvp>
so yes. using your distribution's nix package I assume is a sane way to bootstrap this
<arianvp>
but we should perhaps document that
<gchristensen>
right
<gchristensen>
(or, use the installer on the website)
<arianvp>
(i'm also not happy with the installer; i don't trust it)
<arianvp>
first thing it does is curl another URL and execute it last time I checked
<arianvp>
(which in theory is fine; but it hinders auditability
<gchristensen>
you don't have to trust it
<gchristensen>
fetch the GPG-signed artifact
<gchristensen>
though it does, indeed, still re-fetch another artifact right after execution
<adisbladis>
Hmm.. Wouldn't it be better for the installer to contain the nix GPG key rather than sha256 for each platform?
<adisbladis>
Or maybe both
<gchristensen>
no
<gchristensen>
because then the user has to have a functional GPG
<arianvp>
so for trust it doesn't matter. as the urls are sha256'd
<gchristensen>
for no win
<arianvp>
but "do I trust the source" is not the same as "did I trust the download"
<arianvp>
those are two separate steps.
<gchristensen>
hm?
<arianvp>
I first download and verify with the key. I then want to inspect what the installation script actually does
<gchristensen>
aye
<gchristensen>
yeah, that is a good point
<adisbladis>
Exactly
<adisbladis>
What I meant
<arianvp>
now if I download it, I'm prompted with " curl | sh"
<arianvp>
so I need to manually construct that url, download it too, _then_ also _manually_ do the sha256sum check and then read that source
<gchristensen>
right
<arianvp>
before I can call the toplevel script
<gchristensen>
that is annoying
<gchristensen>
not good
<arianvp>
I think we should just add 5 URLs to the homepage. one for each platform
<gchristensen>
that is a good idea
<gchristensen>
would not be tough, since that is autogenerated anyway
<arianvp>
and have each of them signed
<gchristensen>
less interested
<gchristensen>
signing the one file gets you free signatures for the rest
<yorick>
I'm getting systemd-timesyncd failures when doing nixos-rebuild switch from a 19.03 system with no state
<arianvp>
oh well. in that case we can sign a set of SHA256SUMS
<arianvp>
ahh so we already have all the parts we just need to change the instructions?
<gchristensen>
I'm not sure what you want to do or why, yet. the only thing that is clearly an improvement to me is the replacing the constructed URL with a hardcoded URL
<gchristensen>
can you restate what you want to do and why for me? (sorry if I'm being dense)
<arianvp>
no problem
<arianvp>
I'll gurken it. one min
<arianvp>
=)
<arianvp>
1. I want to verify that the artifact that I download to be from Eelco
<arianvp>
2. I want to audit that Eelco is not rm -rf /'ing my computer
<arianvp>
Once I have established both. I will run the installer
<arianvp>
step 1 I can do (if I follow the instructions on the website)
<arianvp>
then step 2 is hard. as we have a ./install script that downloads the correct nix tarball (with another install script inside) based on your detected arch
<arianvp>
so there isn't much that convinces me that the install script isn't malicious
<arianvp>
So i'd prefer to get rid of the auto-detect wrapper install script, download the correct tarball myself, call gpg on that
<arianvp>
unpack it and look at its install script directly
<arianvp>
But there is no direct link to this tarball on the website. it instead links to this script that indirectly downloads it
<gchristensen>
perhaps two todos: (1) change the switch to use absolute URLs, no interpolation (2) a note on the website, near the gpg instructions, about how the install script is a dispatcher, and fetches tarballs which are in that directory and individually signed
<{^_^}>
#64931 (by toonn, 18 minutes ago, open): wire-desktop: refactor to add Darwin support
<__monty__>
My current thinking is these terms are just ass-covering legalese since the GPL doesn't grant you the right to connect to their servers anyway? But I'm far from a lawyer so figured I'd ask.
<gchristensen>
I think we should mark it unfree
<gchristensen>
I'm asking an outside dev who is pretty familiar with licenses
drakonis_ has joined #nixos-dev
<gchristensen>
ok that dev has pinged some lawyers to give their feedback
<arianvp>
I guess I can give an answer about this one given I work at Wire
<gchristensen>
yeah that'll be good
<gchristensen>
also the SFLC has been contacted to see what they think about it
<arianvp>
I can forward this to the correct person
<arianvp>
I'll send him a link to the PR
<gchristensen>
cool
<arianvp>
Ok i've forwarded it
* __monty__
's sitting here feeling like he pressed the MAD button o.O
<arianvp>
:D
<gchristensen>
licenses are complicated
<gchristensen>
hehe
<gchristensen>
and people care a lot about getting them right :P
<__monty__>
I just hope Wire won't throw up their hands and go "Aaaargh, floss is too complicated, this is proprietary software now."
<gchristensen>
unlikely
<arianvp>
__monty__: don't worry about that
<__monty__>
Should I maybe already mention that I do have vague intents to dig deeper and actually fetch the built html/css/js and electronifiy it as per clever? Maybe I'd need to go so far as to also nixify the yarn build to get the html/css/js? Since samueldr said licensing might be different for the source and the build product.
<arianvp>
__monty__: it will be quite a big yarn.lock file though and we won't be able to add those packages to nodePackages I think
<gchristensen>
FRidh2: joy.
<arianvp>
I tried packaging a yarn project before (The UI for Vault, Consul and Nomad) and we decided not to merge because it would bloat nixpkgs too much
<__monty__>
arianvp: Yeah, clever already hinted at the infeasibility of this.
<__monty__>
If there's no other options though...
<arianvp>
perhaps a separate nix overlay outside of nixpkgs? :P
<arianvp>
idk
<__monty__>
Clearly we need flakes.
<arianvp>
Okay my collegue responded by the response isn't very helpful so I asked for a bit of clarification :P
<arianvp>
> Hey Arian, all our client code is published under GPLv3, no additional terms apply
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):255:10
<__monty__>
Disclaimer: I don't actually know whether flakes would help or hinder.
<arianvp>
but I guess the question is whether those extra terms are "further restrictions" or not?
<arianvp>
sorry {^_^} :D
<worldofpeace>
cool that you work at Wire arianvp ✨
<gchristensen>
^
<arianvp>
Started last month
psyanticy has quit [Quit: Connection closed for inactivity]
<arianvp>
I've already infected one collegue with NixOS today
<arianvp>
see how far I get :P
<gchristensen>
yay!
<arianvp>
We're currently at the NixOS meetup at C-base and just installed his system
<andi->
arianvp: I do not see `nix` in the wire readme
<arianvp>
It should be soon. I have a local PR for that :P
<andi->
very good.
<arianvp>
(a least for the backend)
<gchristensen>
very cool :D
<arianvp>
it only sets up the build env for stack though. haven't cabal2nix'd it yet that is a lot more work
<arianvp>
but did package our crytpo libraries already. maybe I should upstream those to nixpkgs
FRidh2 has quit [Quit: Konversation terminated!]
Jackneill has joined #nixos-dev
<gchristensen>
anyone have a handy way to test patches to nix, where the changes are in the nix daemon, on nixos?
<andi->
I just do nix.package = pkgs.nixUnstable.overrideAttrs … and add patches
<andi->
or change src
<gchristensen>
aye
<gchristensen>
it'd be nice to be able to use the resul0t from `make`
<andi->
can't you just `nix.package = /home/grahamc/fooo/nix/inst` ?
<andi->
or is something depending on some attribute of the nix package?
<gchristensen>
hmm that might could work..!
justanotheruser has quit [Ping timeout: 272 seconds]
<gchristensen>
oh man I seriously broke my nix :P
<andi->
I was "hoping" for that :D
<andi->
because of your patch or because of the hack above?
<gchristensen>
my patch
<gchristensen>
/run/current-system/sw/bin/nixos-rebuild: line 225: exec: Signing: not found
<andi->
/run/booted-system to the rescue? ;-)
<chaker>
So, you can't rollback!!
<gchristensen>
nah I could roll back
<gchristensen>
Nix is only messed up when I run it as root :)
pie_ has quit [Ping timeout: 268 seconds]
<worldofpeace>
So I'm pretty sure plasma5 was broken on master by the QtWrappers and #64720 would fix it. Would it be appropriate to merge that to master if I could verify that?
<infinisil>
worldofpeace: Sounds good to me if that really fixes it
<samueldr>
worldofpeace: is there a way to test the issue with the plasma5 test?
<samueldr>
if so, and if it fails on master, works on your fix, that would be like 100% approve and merge
<worldofpeace>
Well currently the plasma5 test on my system for master does nothing because the dbus services won't start because their executables aren't wrapped
<samueldr>
I wonder if there are other locations where binaries (or .so?) could be found that needs similar fixes, but won't have it with wrappers
<worldofpeace>
I could just build the plasma5 test with that commit but I'm guessing it would take a rather long time
<gchristensen>
ok this time I really did break nix
<worldofpeace>
samueldr: other place I mentioned was an issue with sbin
<samueldr>
hmm, on my workstation changing Qt and building the test IIRC took ~1-2 hours, wasn't _too_ bad
<worldofpeace>
Guess I'll do that, wish me luck
<samueldr>
I'll do it too
<worldofpeace>
Lol someone just commented that they did that
<samueldr>
I assume this is about where the issue is happening
<worldofpeace>
Yep, I'm gussing maybe something still isn't wrapped or wrapped correctly
<samueldr>
I'll be blunt, but the plasma5 test wasn't ran on the PR with the scripts? I'm not permitting myself to pass judgement since I didn't look at it, it kinda rubbed me the wrong way :/
<samueldr>
the PR with the wrappers*
<samueldr>
(and blunt toward no one in particular, to be fair)
<worldofpeace>
I'm thinking the same thing
<worldofpeace>
I would have never merged the PR before doing that if I was reviewing
<worldofpeace>
But yeah, pointing fingers isn't helpful. Swooping in for a save can be though 😃
justanotheruser has joined #nixos-dev
drakonis_ has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
Drakonis has joined #nixos-dev
_e has quit [Quit: WeeChat 2.4]
_e has joined #nixos-dev
pie_ has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
johnny101m2 has joined #nixos-dev
johnny101m has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<samueldr>
worldofpeace: does running dolphin from the gui transitively "pollutes" its env?
<samueldr>
meanwhile, the test uses `su` and DISPLAY=:0 to start it from outside
<worldofpeace>
samueldr: Yes exactly
<worldofpeace>
samueldr: that's why manually it was working
lassulus has quit [Ping timeout: 248 seconds]
<samueldr>
yeah, I guess that's one way that wrappers are hard :/
<samueldr>
environment propagation makes all things tricky
<samueldr>
ideally, the wrapper-added environment shouldn't propagate to child to ensure issues aren't masked
lassulus has joined #nixos-dev
Guanin has joined #nixos-dev
<samueldr>
(though AFAIK it's not possible to an environment not to propagate without having the process handle it)