sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.03 released! https://discourse.nixos.org/t/nixos-19-03-release/2652 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-dev
Drakonis has quit [Ping timeout: 276 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-dev
phreedom_ has quit [Quit: No Ping reply in 180 seconds.]
phreedom has joined #nixos-dev
Drakonis has joined #nixos-dev
Drakonis has quit [Ping timeout: 250 seconds]
Drakonis has joined #nixos-dev
octe has quit [Ping timeout: 252 seconds]
FRidh has quit [Ping timeout: 244 seconds]
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
FRidh has joined #nixos-dev
Jackneill has joined #nixos-dev
<edef> i'm not really sure how to move forward with https://github.com/NixOS/nixpkgs/pull/63585
<{^_^}> #63585 (by edef1c, 4 weeks ago, open): openssh: use SUID ssh-keysign path
<edef> it's been a month, nobody has levelled additional criticism at it, am i clear to merge this?
<edef> the button looms bright and green and very pushable, but i'm honestly unsure when several people jumped on as reviewers and haven't responded to re-requested reviews
<gchristensen> hmm that doesn't actually make it setuid though
johanot has joined #nixos-dev
<gchristensen> seems fine, though? (as an aside, the argument about removing other ones before deciding against enabling this one is not a very honest argument)
<gchristensen> although, this impurity will break ssh on non-nixos hosts when using SSH with ssh-keysign as root
<edef> this is true
<edef> but it is an impurity that was previously ignored
<gchristensen> it was?
<edef> i don't think anyone was paying attention to it
<gchristensen> there is an impurity right now
<gchristensen> ?
<edef> or, hm, no, it would use the one in the store, you're right
<edef> i think that is a fairly niche case
<gchristensen> yeah, it might be
<gchristensen> however I know in the past changes which made ssh progressively more nixos-specific hurt users off nixos
<gchristensen> which is a pretty hard place to find ourselves
<edef> so like, you're using nixpkgs OpenSSH, as root, but aren't interested in having host-based authentication work with regular users
<edef> that's a fairly specific user, and i posit that there are zero of them
<gchristensen> yeah, it would be nice to be able to query users easily and get some feedback on that
<edef> what could be interesting is making it use FHS ssh-keysign if available, and i would be happy to write a patch for that
<gchristensen> anyway
<edef> because then you could use host-based auth configured by your system administrator while also using nixpkgs OpenSSH
<edef> note that host-based auth requires explicit cooperation from the operators of *both* systems
<gchristensen> the only case I could easily imagine is nix-daemon's ssh implementation for SSHing to remote builders, but that uses libssh2
<edef> i'd like to make HBA very easy to use on NixOS, i've got a small fleet of machines set up with it right now and users are enjoying it
<gchristensen> it is probably fine to merge it
<gchristensen> overall though I much regret the use of /run/wrappers and the impure GL bits creeping in to otherwise pure packages, as it threatens (and indeed breaks) core goals of Nix
<edef> yeah, i understand that
<edef> but HBA is inherently ambient authority
<gchristensen> yeah but authority is not the problem
<gchristensen> there is probably a protocol ssh-keysign uses to communicate, which means that any users must have compatible callers
<edef> sure
<edef> you can make that argument all the way up to the kernel
<gchristensen> well yes and that is why I use nix
<gchristensen> I could, and do, make that argument
<edef> like, i'm not saying this from a position of disagreement
<gchristensen> I know :)
<edef> i've pondered writing stuff to mask uname and limit syscalls to a known set
<gchristensen> the glibc locale archive stuff is really really awful
<edef> yeah, and there's the /bin/sh bit
<gchristensen> heh
<edef> i started writing some stuff to close that ages ago, ran into musl support being fairly meh
<edef> overall having libc and sh in different derivations all the way is kind of awkward, they inherently have circular dependencies
<gchristensen> hmm I wonder if I practically depend on /bin/sh anywhere
<johanot> gchristensen: I see that adamt mentioned me here earlier. I also see that lejonet responded to your comments on the ceph PR. If you need me for anything reagarding that, I'm awake now :)
rsa has quit [Ping timeout: 258 seconds]
<gchristensen> I am desperately late for bed, so I really should be going :x
<gchristensen> but I am presently grepping my hard drive for '^#!/bin/sh' ...
<johanot> damn time zones :p
<gchristensen> what TZ are you in?
<johanot> UTC+2 .. CEST
<johanot> Copenhagen, more specifically
<gchristensen> oh no worries, I'll be in America/New_York next week. I'm in America/Los_Angeles this week teaching a training.
<johanot> hehe. East coast is much more tolerable :)
<gchristensen> _much_. good night :)
<johanot> gn :)
orivej has quit [Ping timeout: 268 seconds]
octe has joined #nixos-dev
orivej has joined #nixos-dev
__Sander__ has joined #nixos-dev
adamt has joined #nixos-dev
adamt has quit [Changing host]
adamt has joined #nixos-dev
Drakonis has quit [Quit: WeeChat 2.4]
adamt has quit [Quit: WeeChat 2.4]
adamt has joined #nixos-dev
psyanticy has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
johanot has quit [Ping timeout: 245 seconds]
psyanticy has quit [Quit: Connection closed for inactivity]
FRidh has quit [Ping timeout: 258 seconds]
<pie_> how would you guys attach GDB to something started in an activation script?
<pie_> i.e. in a situation where I know _what_ gets started, but its something really hard to attach a debugger to
<pie_> I think windows has something where you can set in the registry that an executable should have a debugger attached on launch
<pie_> ...well I suppose a wrapper could be used in that case. hm.
johanot has joined #nixos-dev
<matthewbauer> worldofpeace: yeah looks good to me!
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 248 seconds]
FRidh has joined #nixos-dev
cransom has joined #nixos-dev
adamt has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
johanot has quit [Quit: WeeChat 2.4]
__Sander__ has quit [Quit: Konversation terminated!]
<gchristensen> we need to decide in principle if we want to do https://github.com/NixOS/nixpkgs/pull/63585. the code is good, the reason it hasn't merged is the principle of it.
<{^_^}> #63585 (by edef1c, 4 weeks ago, open): openssh: use SUID ssh-keysign path
<gchristensen> I am inclined to merge it: it improves SSH support on NixOS, especially for large enterprises and edef
<gchristensen> the problems come from non-nixos users using this specific feature set as root. I agree with edef that we probably don't have users like this.
<samueldr> does it break an existing use case?
<gchristensen> the existing code _could_ work a Nix user off NixOS uses a Nixpkgs-built SSH as root.
<samueldr> without SSH_KEYSIGN set at build time, does openssh use a global default path or the store specific path?
<samueldr> /run/wrappers is likely something that can be factored out for other platforms too, while the store specific path will never work with SUID
<adisbladis> samueldr: It's relative
<gchristensen> I think it presently uses the libexec
<samueldr> so AFAIUI it shouldn't break existing workflows? unless it also kinda works when not SUID?
<gchristensen> it could work for a Nix user off NixOS uses a Nixpkgs-built SSH as root
<adisbladis> I think the patch is pretty reasonable as-is.. But, maybe sshKeysignPath should be passed by the NixOS module?
<gchristensen> adisbladis: oh! could it be?
<gchristensen> this sounds Way nicer
<adisbladis> I'll make a comment on the PR
<samueldr> wouldn't that make all nixos users build a "custom" sshd?
<gchristensen> if we have to patch ssh and upstream it, this feels like a win.
<samueldr> the sshd in the cache would be with the default sshKeysignPath, which I presume would be null, right?
<adisbladis> samueldr: We would be building both
<gchristensen> oh wait a sec
<gchristensen> I thought we were talking about a config option
<gchristensen> can we make this a config option?
<samueldr> if it's a nixos config option, that's given to the opensshd package, the opensshd package from e.g. nix-build or nix-shell would be different than from the sshd service, no?
<adisbladis> samueldr: Yes it would
<samueldr> and while hydra machines would end up building it, maybe I'm missing something, but would it only be copied to the cache if it's specifically made to copy it?
<gchristensen> this isn't workable I think, because _every_ ssh needs it set correctly, causing mass rebuilds for everybody
<samueldr> unless there's two openssh in pkgs, pkgs.openssh, pkgs.openssh-but-with-suid-path-configured-for-nixos
<adisbladis> gchristensen: Damn :/
<adisbladis> Ugh..
<samueldr> is that it?
<gchristensen> no
<gchristensen> because thousands of things depend upon ssh
<gchristensen> and thos ethings need a correct ssh too
<samueldr> isn't that for the linstening sshd?
<gchristensen> no, it is executed by the user
<gchristensen> that is why it need to be setuid
<adisbladis> gchristensen: Ah, that's what you mean by making it a config option! We would patch openssh to make it configurable.
<gchristensen> exactly
<samueldr> ah, I see, both sides are using it
<adisbladis> Right. That sounds like the best option so far.
<samueldr> (just opened the manpages)
webster23 has joined #nixos-dev
rsa has joined #nixos-dev
<yorick> gchristensen: hmm, can you make it read ssh-keysign from PATH?
<samueldr> I wouldn't think it's a good idea if it's a security thing
<nbp> https://home.cern/news/news/computing/migrating-open-source-technologies (CERN) “evaluations of alternative solutions for various software packages used for IT core services”
morgib has joined #nixos-dev
<gchristensen> oh great nbp!
__monty__ has joined #nixos-dev
adamt has joined #nixos-dev
adamt has quit [Changing host]
adamt has joined #nixos-dev
<edef> 18:44:14 < samueldr> wouldn't that make all nixos users build a "custom" sshd?
<edef> samueldr: sshd doesn't use ssh-keysign
<edef> samueldr: the *client* needs to authenticate using the host key
<edef> oh, that was mentioned above
<gchristensen> ;)
<adisbladis> We have breakage in unzip https://github.com/NixOS/nixpkgs/pull/64909 https://github.com/NixOS/nixpkgs/pull/64910 and I'm considering what to do about it. Reverting the patch seems wrong.
<{^_^}> #64909 (by mmahut, 1 week ago, merged): unzip: CVE-2019-13232
<{^_^}> #64910 (by mmahut, 1 week ago, closed): [WIP] unzip: CVE-2019-13232 (release-19.03)
<adisbladis> Debian has applied the patches too and are running into similar issues within the gradle ecosystem https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931895 but no conclusion yet.
<gchristensen> ouch
<gchristensen> if it were me, I'd wait for debian and follow their lead
adamt has quit [Quit: WeeChat 2.4]
Drakonis has joined #nixos-dev
<adisbladis> gchristensen: It's likely too slow.
<gchristensen> they have users in prod having problems, or their problem are in testing or something?
<adisbladis> gchristensen: Their patched unzip is only in unstable/testing
<gchristensen> ahhh let's revert
<adisbladis> I was leaning towards that too. Even though I feel dirty doing it :/
<gchristensen> eh
<gchristensen> debian hasn't even made it to stable yet, so there you go :P
<adisbladis> Anyway, thanks for being a good rubber duckie :)
<gchristensen> :D
<yorick> https://discourse.nixos.org/t/nixfmt-beta-release/3545 please check it out, don't forget to like and subscribe :P
<Drakonis> dont you mean comment, like and subscribe?
<marek> gchristensen, adisbladis if I understand debian is not looking to fix/revert the patch (it is valid), just working to fix the regressions as we were?
<gchristensen> oh interesting
<marek> the patch is doing what it is supposed to, it just shows now the buggy/broken zip files from upstream, this is the analysis about these jar from maven https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931895#73
<ajs124> The bootstrap*zip in hydra (for the frontend) is also affected by this
<marek> so far, we have seen two - broken docbook upstream tarball, fixed by upgrading to the latest version by vcunat and zip-archive haskell package which shipped a broken zip archive in a test
<marek> I kind of feel we will have to address this in the future anyway, maybe we should revert this in master and work on fixing the regressions we have collected so far?
<marek> I sadly do not know a good way to find these regressions, it comes from user reports so far
<samueldr> has hydra eval'd with the fix? pick the new failures from that eval
<samueldr> it'll not be exhaustive, but a good chunk
<samueldr> (things already failing, that would then fail due to the fix wouldn't be listed in newly failing jobs)
__monty__ has quit [Quit: leaving]
webster23 has quit [Ping timeout: 250 seconds]