<{^_^}>
#64888 (by yorickvP, 1 week ago, open): nixos/borgbackup: generate wrappers per job for easy borg access
<yorick>
these wrappers saved my ass last sunday :D
psyanticy has joined #nixos-dev
Guanin has joined #nixos-dev
orivej has joined #nixos-dev
phreedom_ has quit [Quit: No Ping reply in 180 seconds.]
phreedom has joined #nixos-dev
<gchristensen>
I wonder if packages like spotify (upgrades are regular and mandatory) should live in a different channel
<gchristensen>
since they barely depend upon nixpkgs
<samueldr>
aren't they prime flake candidates?
<gchristensen>
oh heck yes
<samueldr>
(I know, it's not ready for distribution now though)
<samueldr>
I guess the question is: what can we do right now with those third-party service-dependent software?
<gchristensen>
overall I think flakes probably don't belong in nixpkgs (dunno what niksnut thinks) but this would be a prime candidate
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 260 seconds]
<__monty__>
Hmm, I thought flakes would enable having nixpkgs carry packages that are maintained by upstream.
<__monty__>
Also flake splinter-cell when?
<gchristensen>
yeah, I'm not sure
<gchristensen>
we'll have to see
Jackneilll has joined #nixos-dev
Jackneill has quit [Ping timeout: 272 seconds]
<thoughtpolice>
__monty__: Flakes _will_ enable upstreams to maintain modules/packages on their own that you can add, sure. But I think that's a bit different than whether or not we want to make lots of things inside nixpkgs flakes. Some coarse grained categories like 'nix-warez' are good ideas, though IMO.
<__monty__>
thoughtpolice: Yeah, I thought the point was nixpkgs maintainers could stop worrying about some bits. Like, maybe mozilla would maintain a firefox/thunderbird flake. Good for users because they're still available in nixpkgs, good for maintainers because they don't have to worry about ff/tb anymore.
<qyliss^work>
bad for us when they decide to do something we don't approve of
<qyliss^work>
we're a distribution, and I think that's important.
<__monty__>
Yeah, but, realistically, *can* you control such things now really?
<__monty__>
There's so much stuff to keep an eye on. I'm sure tons of things slip through the cracks already.
<yorick>
packages being maintained by upstream is a bad idea
<gchristensen>
yes
<gchristensen>
we can :)
<samueldr>
yeah, I personally was thinking, in the particular case of the spotify-class of software, that it was a nixos-owned flake repo
<thoughtpolice>
There is, but you're not going to make it significantly better by just throwing it all to be done by upstream.
<thoughtpolice>
I mean, upstreams often actually make poor choices if they're not careful because it's difficult enough even on *non* NixOS systems.
<__monty__>
And then there's things nixpkgs might not care about but some users might. For example ranger can't be installed with python2 or pyp2 anymore because some random nixpkgs contributor decided py3k is the future.
<yorick>
we could never patch out the ZFS linux encryption thing if it were upstreamed. distros have a responsibility to gatekeep software to be good for users, not application makers
<gchristensen>
py3 is the future
<yorick>
(this is why all flatpak applications are terrible)
<qyliss^work>
__monty__: that's what overlays are for
<__monty__>
thoughtpolice: I think that problem could still be covered by flakes though. nixpkgs policy could be to pin flakes and only move the pins after review.
<thoughtpolice>
Plus even assuming every upstream is a perfect angel who is a genius and knows the perfect way to package, the "solution" quickly becomes worse than the disease if you take it too far, because then you're just playing games of whackamole tackling flake references.
<gchristensen>
and then what happens if the review is bad
<thoughtpolice>
It's not even really that you can't automate it. It's just that it's significantly worse than "Edit this one .nix file and fix it in 10 seconds". Like the whole workflow is just.... more annoying.
<gchristensen>
+1
<thoughtpolice>
It's like a git submodule. The first one is fine. Once you get to twenty of them you're going to hate it, a lot (I know this from experience)
<gchristensen>
cure vs. disease
<__monty__>
gchristensen: I know py3k is the future but nixos isn't ready to move to it yet and neither might some ranger users.
<gchristensen>
we're not ready?
<thoughtpolice>
Right. A good case I thought about is Eris, my HTTP binary cache server. It has a nixos module and a package. I'm actually not sure having a flake is very useful outside of the most extremely strange cases. It's not like I'd use it, I just hack it myself! And users would be better with an upstream module.
<yorick>
calibre is still python2
<gchristensen>
right, but we have cohabitating pythons
<__monty__>
gchristensen: Yes, but the current ranger expression doesn't allow you to use the other pythons because the argument was changed from pythonPackages to python3Packages.
<__monty__>
You could use any python you wanted before this.
<gchristensen>
I'm not understanding why this is a problem, though
<gchristensen>
what is the impact?
<__monty__>
I can't install a pypy run ranger using nix.
<gchristensen>
ah!
<__monty__>
And neither can our userbase.
<samueldr>
oh, so not about "the" python 2 interpreter, but "any other python interpreter"
<samueldr>
makes much more sense
<__monty__>
Just because someone change pythonPackages to python3Packages rather than pythonPackages ? python3Packages.
<__monty__>
At least I *think* the latter'd achieve having the default be cpython3 but allowing people to use pypy if they wanted to?
<samueldr>
I'm wondering if this shouldn't be part of the `callPackage` invocation, like `libsForQt5.callPackage` resolves to "any" qt5 and not even care about pythonVERSIONEDPackages in derivations
<Profpatsch>
samueldr: that it was a nixos-owned flake repo < what exactly do you gain by splitting nixpkgs in that way? Except maintenance overhead and atomicity issues?
<thoughtpolice>
To be fair, I think it would also be extremely reasonable in this *particular* case to simply argue that "changing it to python3Packages unilaterally is a regression" and just ask it to be undone, unless there's some dire need to do otherwise.
<__monty__>
I apologize for poluting #nixos-dev with this fairly minor problem I could just fix in a PR btw. It's just one of the reasons why I was looking forward to flakes. That we could take some control over what changes went into the nixpkgs ranger, rather than have nixpkgs maintainers (who probably don't care about ranger) review changes, without any notification to meta.maintainers.
<samueldr>
Profpatsch: it was re: <gchristensen> I wonder if packages like spotify (upgrades are regular and mandatory) should live in a different channel
ryantm has joined #nixos-dev
<thoughtpolice>
Like, it worked before. Python2 isn't gone, so it could just... be undone. :)
aszlig has joined #nixos-dev
<thoughtpolice>
But yes there are some issues like that which are otherwise tough and not always so clear cut.... (In this case it is just a flat-out regression though, IMO, clear as day)
<__monty__>
thoughtpolice: The problem is not that it happened. It's that it could happen and is likely to happen again.
<__monty__>
Would the default argument `pythonPackages ? python3Packages` work as I think it would? Otherwise I'll just PR that change.
<thoughtpolice>
That's something that's at some level always out of your control unless you tightly maintain it yourself, I'm afraid. After all, there's no guarantee someone who did author a ranger package in a flake would just benevolently keep it working on Python 2. They might make the exact same decision!
<Profpatsch>
__monty__: But that’s what maintainer notifications are for, right?
<__monty__>
thoughtpolice: But we, the ranger maintainers, would maintain that flake.
<Profpatsch>
Shoudn’t ofborg already cc you if you are in the maintainers field?
<gchristensen>
yeah
<samueldr>
Profpatsch: the implementation requires the user to be a member of the nixos orga though
<__monty__>
Profpatsch: It doesn't though. There's been half a dozen changes since I added myself to maintainers and I haven't gotten notified even once.
<thoughtpolice>
Oh! Well that's different (I didn't realize you maintained it.)
<Profpatsch>
That’s a tooling problem then, not a nixpkgs/flakes problem.
<thoughtpolice>
__monty__: FWIW codeowners is a better and more fool-proof way of doing it now, at least.
<samueldr>
gchristensen: I know you wanted to remove all commenting from ofborg, but maybe pinging maintainers needs to happen in comments still?
<Profpatsch>
If you split stuff into different repos, these problems will be magnified multitudes.
<thoughtpolice>
the whole "match GH name to commit author" has flaked on me sometimes too
<samueldr>
Profpatsch: I think issues might have been conflated here
<Profpatsch>
And it’s essentially the same (you still have to push the flake version), but it’s two steps now instead of one.
<gchristensen>
samueldr: unprivileged maintainer team is the answer
<__monty__>
gchristensen: Except not quite because of 2fa.
<samueldr>
the initial flake thing I was proposing was for the generally self-contained third-party service-dependent software like spotify and discord
<__monty__>
thoughtpolice: It's just that CODEOWNERS seemed like a far greater commitment to me. And I figured it was only for nixpkgs maintainers.
<thoughtpolice>
Mmmmm, true. I think it's "only" for Nixpkgs maintainers just because we haven't set up a team like gchristensen said, though tbh that does sound like a reasonable idea (there are a host of some other annoying GitHub behaviors like that I think)
<qyliss^work>
re: packages like Spotify, I think a seperate unfree repository would solve this problem and others
<qyliss^work>
you're not generally forced to upgrade free software
<qyliss^work>
And since not much in there would be built from source, channel updates would be fast.
<qyliss^work>
cc gchristensen samueldr Profpatsch
<gchristensen>
it wouldn't solve it for signal
<qyliss^work>
Signal is borderline unfree, for that reason
<qyliss^work>
You can't use modified versions with OWS's servers, and regular upgrades are forced on you.
<Profpatsch>
qyliss^work: It wouldn’t solve it for youtube-dl
<gchristensen>
that doesn't make it unfree, and is an acceptable clause to the GPL (was just chatting with armijn about this)
<qyliss^work>
not technically, but I think a distinction could be make there
<Profpatsch>
What is the reason for splitting them out in the first place?
<gchristensen>
fair. I think it would be wrong to put signal in an "unfree" bucket
<qyliss^work>
Does youtube-dl have to be upgraded that often? I don't upgrade that often, and have never had a problem with it.
<Profpatsch>
To introduce more broken UX?
<gchristensen>
Profpatsch: lol
<Profpatsch>
“Why is this package not there”
<__monty__>
We talked about this for Wire too recently. (Though they don't actually prevent using (slightly) out of date or altered versions.)
<simpson>
qyliss^work: FWIW I think that the source of unfreeness in these packages (hub, Spotify, youtube-dl, Signal) is that they interact with inherently-unfree SaaS products.
<qyliss^work>
Yeah...
<gchristensen>
Profpatsch: the idea I mentioned is is that if you don't upgrade spotify and signal (etc...) often enough, the packages stop working -- but it is a bit annoying to get them updated in nixpkgs and then backported, and then wait on the channel update.
<__monty__>
qyliss^work: Google regularly breaks it for me.
<simpson>
The SaaS gets updated, and suddenly the open packages break. Even ones with fully-open development processes, like youtube-dl. So I think that the problem's not necessarily self-inflicted, but corporation-inflicted.
<Profpatsch>
gchristensen: I was thinking on how to solve this for youtube-dl, yes
<qyliss^work>
FDroid has a NonFreeNetwork marker for this sort of thing
<samueldr>
already shouted in the void, that we may want a field to meta about those kind of misfeatures
<__monty__>
qyliss^work: Trust me, I'm too heavy to be reeled in ; )
<qyliss^work>
that's what they all say
<gchristensen>
__monty__: I leave resolving this situation in your capable hands :)
<__monty__>
Looking into it, I'm not sure this is a solvable problem tbh. 2FA over SMS isn't 2FA and my only other recourse is storing 2FA recovery keys on the computer, which isn't 2FA either : / I don't like security theater.
<qyliss^work>
How is TOTP on your computer security theatre?
<__monty__>
Because why wouldn't anyone be able to do that? If *I* can do it from any computer, anyone else can too.
<qyliss^work>
Right, but they don't know the secret.
<qyliss^work>
It's exactly the same as on a phone
<qyliss^work>
You don't register a phone, you store a secret on your phone, and use it to generate codes
<qyliss^work>
That's just how we implement "something you have"
<__monty__>
And how do I get secrets on all my devices?
<yorick>
__monty__: I have one of these yubikeys where I store the second factor
<yorick>
s/where I store/that is
<gchristensen>
__monty__: if you're not going to get a yubikey nor have a phone capable of the application, I leave the distribution problem in your capable hands
<qyliss^work>
__monty__: if you want to do that, you can put them in a password manager
<yorick>
__monty__: sms is an acceptable communication channel for second-factor tokens
<yorick>
it is not security theater at all and actually prevents a lot of 'hack's
<__monty__>
qyliss^work: You do see how a second password is hardly 2FA, no?
<qyliss^work>
It's not a second password though
<qyliss^work>
Because you never ever send it to anybody else
<qyliss^work>
Unlike your password, which you send all the time.
<__monty__>
The secret would be stored in a password manager behind a password, presumably the same password used to get at the github password.
<qyliss^work>
Right, but that would never be transmitted to anybody else
<qyliss^work>
And so would be much more difficult to intercept.
<yorick>
__monty__: yes, things leaking from your password manager directly is not the attack model this prevents against
<__monty__>
Ok, and SMS is supposedly fine because the codes aren't long-lived?
<gchristensen>
(although it would protect against a leaked password DB, if you had a yubikey or a phone)
<__monty__>
Presumably an attacker would only have to be close-enough to intercept an SMS though?
<yorick>
__monty__: yes, because it is unlikely that anyone having your password also has access to your SMS
<gchristensen>
the long and short of this discussion, though, is this: if you want to be part of that team, you'll need to solve the problem you've created for yourself
<__monty__>
yorick: Not really though, since SMS are so easily intercepted.
<yorick>
__monty__: if someone is physically nearby or a state actor, yes
<gchristensen>
you can talk all you want about how none of this is good enough, but at the end of the day it is better than a regular password
<qyliss^work>
I won't muddy the conversation any further by hating on SMS.
<__monty__>
gchristensen: I will. It's just really annoying that I have to complicate all my github logins just to get some mentions.
<yorick>
qyliss^work: yeah, if you are in russia and they want to steal your github, then they could with sms
<yorick>
__monty__: how many github logins do you even do
<gchristensen>
qyliss^work: I'd take SMS over none.
<__monty__>
yorick: Enough to make it annoying. I tend to log out of services unless I'm actively using them.
<qyliss^work>
Oh for sure I'd take it over none.
<qyliss^work>
But it's important not to use it as a fallback, because then you've weakened the whole thing.
<gchristensen>
sounds like a yubikey is a great choice for you, then! the U2F implementation is fabulous and makes a huge improvement to the UX of log-in, while also becoming much more difficult to phish
<__monty__>
gchristensen: I don't trust myself to not lose usb sticks. And I know I'm weird but I don't carry around a laptop so I somewhat regularly log in to github from other's devices so I'd have to carry a yubikey with me, hence the worry about losing it.
<gchristensen>
I believe in you
johanot has quit [Quit: WeeChat 2.4]
<yorick>
__monty__: if you regularly log in to github from other's devices then that's a huge risk of leaking your password
<Taneb>
__monty__: you can get ones that go on a keychain, and like I carry my keys around all the time and only rarely leave them on the outside of my door
<__monty__>
I don't really understand why 2FA's necessary just to get mentions btw. RFC39 Team membership doesn't extend any privileges outside of that, does it?
<yorick>
it's the only place we can enforce it technically
<qyliss^work>
GitHub doesn't let you do it per-team.
<qyliss^work>
I know a couple of people who keep their yubikeys around their necks!
<__monty__>
qyliss^work: Could ofBorg get the mentioning permissions from a different org maybe?
<qyliss^work>
Like people who have glasses with a chain so they can't fall off and get lost.
<yorick>
I would feel better if all the nixpkgs contributors who can push to master have 2fa, at least :P
<qyliss^work>
__monty__: not unless we move nixpkgs
<gchristensen>
no
<gchristensen>
yorick: all members of the org definitely have 2fa :)
<gchristensen>
and to be frank, maintainers of packages have more authority over their package, so we do indeed want maintainers to use 2fa
<__monty__>
yorick: I know it's a risk. I'm not worried about it so far though. Don't have important privileges anywhere and I value the recoverability more than the unnecessary security.
<gchristensen>
"this is a weird URL to fetch this package, are we sure its okay?" maintainer: yep! "okay!"
<gchristensen>
maintainership does bring privileges, as I'venoted
<qyliss^work>
__monty__: and yet you _are_ worried about your SMSes being intercepted?
<qyliss^work>
This threat model makes no sense.
<__monty__>
qyliss^work: No, I don't want the bother because it doesn't *add* much if any security.
<qyliss^work>
Requiring knowledge of a short-lived code sent to your phone doesn't add much security beyond typing your password into random computers?
<adisbladis>
SMS 2FA is _clearly_ better than no 2FA but of course you holding all your own keys is the best 2FA.
<qyliss^work>
And despite being willing to type your password into computers running who knows, you claim you can't be phished?
<__monty__>
But it's only better if we already accept the premise that the bother of 2FA is worth it/necessary. I'll reread RFC39 first though, I thought it didn't come with any privileges.
<qyliss^work>
It doesn't come with any priveleges in the technical sense.
<gchristensen>
the bother of 2fa is not only worth it, but required!
<qyliss^work>
In the social sense, it absolutely does.
<adisbladis>
gchristensen: <3
<__monty__>
qyliss^work: I didn't say that, I simply joked about my weight.
<qyliss^work>
my mistake, then
<__monty__>
gchristensen: Are you sure that's not a false sense of security. How well does the average (or below-average but still statistically significant) dev protect their 2FA?
<yorick>
" The research confirms that even comparatively weak 2FA through SMS messages to your phone are very effective, preventing 100% of automated attacks, 96% of bulk phishing attacks, and 76% of targeted attacks. "
<gchristensen>
I'm not going to debate the significance or value of 2fa, there is plenty of material on the internet. It is okay if you choose to not maintain packages due to the bother of 2fa
<qyliss^work>
76% of TARGETED attacks?? Wow
<__monty__>
I'm bothering, I'm just not gonna be silent on being bothered ; ) I'm willing to take my rants elsewhere though, as I said it's not my intention to pollute -dev.
<gchristensen>
okay, let's take it to #nixos-will-definitely-use-2fa
<qyliss^work>
__monty__: if you feel that strongly about it, the RFC process is ready and waiting for your proposal to change it.
<gchristensen>
qyliss^work: oh let's not give such false hopes :P
<adisbladis>
I thought that was pretty cool.
<gchristensen>
adisbladis: yeah! I've been reaching out to yubikey for similar, but they seem uninterested :(
<__monty__>
Yeah, not gonna fight a losing battle.
<adisbladis>
gchristensen: Really? I can try to reach out to their more techical peeps.
<gchristensen>
adisbladis: oh that would be awesome!
<simpson>
__monty__: Take cheer; if this were a typical employer, then you wouldn't have the option or the chance for discussion.
<adisbladis>
gchristensen: Who did you talk to?
<yorick>
simpson: if this were a typical employer it would provide a yubikey
<gchristensen>
adisbladis: their anonymous sales form
<adisbladis>
Ahh..
<adisbladis>
I'm actually going to Stockholm next weekend. I'll try to arrange something =)
<qyliss^work>
wish my employer provided yubikeys. that would be awesome.
<qyliss^work>
I just bring my own.
<simpson>
yorick: Or they tell one to use one's personal phone and offer zero recourse, forcing one to order a hardware token out of one's own paycheck. But yeah, you see my point.
<gchristensen>
adisbladis: <3 let me know if I can help
<yorick>
simpson: sounds unreasonable
<qyliss^work>
And I'll be self-employed in a few weeks so I can provide myself with whatever I want :)
<qyliss^work>
yorick: that's what mine does
<yorick>
I don't get any other hardware though :P
<simpson>
yorick: Yeah, USA employers are pretty cute in their inability to expense basic essentials for their employees.
<gchristensen>
qyliss^work: and then you'll be like the cobbler and their shoes :)
<qyliss^work>
gchristensen: not sure I know that idiom
<gchristensen>
the shoemaker has the worst shoes
<qyliss^work>
oh right
<qyliss^work>
otoh, it looks rather bad if I, developer of an independent security-focused operating system, get hacked
<qyliss^work>
so i may need some rather nice shoes
<gchristensen>
=)
<__monty__>
Oh, can hardware tokens be reused? I'm pretty sure I know of some dust-gathering ones.
<qyliss^work>
Depends. Yubikeys can.
<qyliss^work>
They can pair with arbitrarily many sites I think. Or some very high number anyway.
<yorick>
there is a limited number of TOTP slots (256 or so) but U2F is infinite
<FRidh>
/me would really like to move the makefile assumptions from stdenv.mkDerivation into hooks
Guanin has quit [Ping timeout: 252 seconds]
phreedom has joined #nixos-dev
phreedom_ has quit [Ping timeout: 260 seconds]
Drakonis has joined #nixos-dev
jtojnar has joined #nixos-dev
sorear has quit [Ping timeout: 252 seconds]
sorear has joined #nixos-dev
Drakonis has quit [Quit: WeeChat 2.4]
<jtojnar>
¡Hola!
<__monty__>
Hola, ¿como estas?
<jtojnar>
just fine, finally returned from vacation and ready for another round of NixOS hacking
__monty__ has quit [Ping timeout: 258 seconds]
__monty__ has joined #nixos-dev
orivej has joined #nixos-dev
Guanin has joined #nixos-dev
webster23_ has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
Drakonis has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
<gchristensen>
samueldr: thanks for writing my diff for me on obs :P
<samueldr>
well, I explained it wrong to you, better show the right way
jtojnar has quit [Ping timeout: 268 seconds]
jtojnar has joined #nixos-dev
Jackneilll has quit [Remote host closed the connection]
phreedom has quit [Ping timeout: 260 seconds]
NinjaTrappeur has quit [Quit: WeeChat 2.5]
Drakonis is now known as drakonis
drakonis is now known as Drakonis
Drakonis is now known as drakonis
NinjaTrappeur has joined #nixos-dev
phreedom has joined #nixos-dev
<worldofpeace>
jtojnar: 🎆 yay you're back
<gchristensen>
jtojnar: ♥‿♥
das_j has quit [Remote host closed the connection]
psyanticy has quit [Quit: Connection closed for inactivity]
<{^_^}>
nix#1205 (by copumpkin, 2 years ago, open): Inconsistent treatment of /usr/bin/env in build sandbox vs. NixOS
<aminechikhaoui>
is there any problem with having /usr/bin/env in the sandbox by default ?
Jackneill has joined #nixos-dev
orivej has joined #nixos-dev
Guanin has quit [Remote host closed the connection]
drakonis has quit [Quit: Leaving]
<yegortimoshenko>
aminechikhaoui: i can't come up with any purity concerns
<samueldr>
since the sandbox is handled by nix, I guess there is compatibility reasons
<samueldr>
things building on nixos systems configured with that addition to the sandbox, or through newer nix with that addition, wouldn't necessarily build on previous versions I think
<gchristensen>
yes, that can be pretty annoying
<clever>
i think the recent pty additions to nix broke the qemu stdio on vmWithBootloader
<infinisil>
aminechikhaoui: FWIW, NixOS has an unexposed option `environment.usrbinenv` with which you can turn off /usr/bin/env
<clever>
nice!
<gchristensen>
yikes :)
<gchristensen>
oh, wait, no that is a cool thing
<infinisil>
Yeah, this could prevent things like users forgetting to patch /usr/bin/env's (because they don't notice it since they have it in their path)
<das_j>
infinisil: Wtf? environment.usrbinenv??
<gchristensen>
matthewbauer: have you seen my issue around sandbox?
webster23_ has quit [Ping timeout: 264 seconds]
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
justanotheruser has quit [Ping timeout: 268 seconds]