<samueldr>
I guess that means you could use a mail client by replying from the other account to mails received through that interface
<samueldr>
considering mailman's gzip is basically a `cat` of all plaintext messages... I guess it should be possible to "rehydrate" them into an NNTP interface
<samueldr>
mailman supports *forwarding* to NNTP built-in, but AFAICT nothing from just using an instance's data
<samueldr>
the good thing, too, is you know the archives in the past won't change
lunc has quit [Ping timeout: 246 seconds]
<samueldr>
oh right, gmane... that was a thing that's not a thing anymore, wasn't it?
<samueldr>
(not exactly, there is apparently gmane.io which is an NNTP interface to lists)
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-chat
<gchristensen>
can jq parse a string as json within an expression? hmm
<gchristensen>
yes, fromjson, neat
<gchristensen>
tailscale is nice ...
cole-h has joined #nixos-chat
rajivr has joined #nixos-chat
<aleph->
Yep
<elvishjerricco>
Is tailscale just "WireGuard, but we did all the annoying stuff for you"?
<gchristensen>
yeah
<gchristensen>
so ... I guess I use that now instead
<elvishjerricco>
From their FAQ: "Tailscale might bounce your encrypted packets through one of our relay servers scattered around the Internet."
<elvishjerricco>
That's a bit annoying
<elvishjerricco>
Not an issue since it's encrypted
<elvishjerricco>
Wish they would have explained when that happens though
<elvishjerricco>
I'm currently using tinc because it's decentralized, totally self hosted, it's a mesh network, and it has NAT traversal
<elvishjerricco>
Do WireGuard/tailscale do all that?
<aleph->
Not mesh yet.
<aleph->
Otherwise yes
<elvishjerricco>
aleph-: So everyone has to know everyone else's public IP?
<aleph->
For plain wg? Trying to remember...
<aleph->
I usually do it site to site.
<aleph->
So a node on my core router at home so all my clients can access the network when remote.
<aleph->
I believe they need to yes.
LnL has quit [Ping timeout: 264 seconds]
LnL has joined #nixos-chat
<Ashy>
not every node, just one public IP with forwarding enabled is enough
<Ashy>
so long as at least that is available they'll all be able to find each other
<Ashy>
even as the dynamic IPs change
<Ashy>
oh I'm talking about wireguard, tailscale probably makes that even easier
<danderson>
elvishjerricco: tailscale is a mesh of wireguard tunnels, with keys tied to SSO and NAT traversal.
<danderson>
relay servers: they get used when NAT traversal fails (we have a whole blog post on how nat traversal works and when that might happen), and to exchange some metadata to help NAT traversal (basically "hey start probing me now, here's my ip:ports")
<danderson>
tailscale isn't decentralized. There is a central coordination server that handles propagating network information between nodes. Tailscale the company runs that, though enterprises can pay us for an on-premises deployment.
<danderson>
so, if self-hosting is a big deal to you, tinc is probably a better fit.
<danderson>
aside from that, yeah, tailscale is in the same vein as tinc, zerotier, and a few others: a full mesh of tunnels between your machines, with some niceties built on top (automagic DNS names, strong identity for connections in the mesh, device sharing between users, central ACL configs...)
<elvishjerricco>
So WireGuard itself doesn't do mesh or NAT traversal, but tailscale implements those things on top of WireGuard. Cool
<danderson>
yup, that's right
<danderson>
oh, and SSO. WireGuard works similar to basic SSH: you generate keypairs, statically configure each end.
<danderson>
tailscale makes you log in with some SSO provider (e.g. gmail, okta, office365...), and ties that identity to the keypairs used for communication
<danderson>
The appeal for that is mostly companies, because it means their VPN automatically ties into their existing central auth system
<danderson>
But under the hood, all we're doing is: the client sends a pubkey to the coordination server, coordination server says "do an OAuth dance to tell me which human you are"
<danderson>
and once you've done the dance, coordination server goes "ok, so this pubkey belongs to danderson@tailscale.com, I'll tell all the other members of the tailscale.com network how to connect to it"
<danderson>
and a few other things happen, like ACLs might get recompiled and pushed to everyone (for example, if you have a global ACL defined as "danderson@tailscale.com -> tag:server:*", when you auth a new machine, all machines tagged with "server" receive a new firewall ruleset that allows the new peer to connect)
<danderson>
all stuff you can do by yourself, using wireguard and a bunch of effort. We've just done it so you don't have to ;)
Dotz0cat_ has joined #nixos-chat
slack1256 has quit [Remote host closed the connection]
Dotz0cat has quit [Ping timeout: 272 seconds]
<aleph->
danderson: Heh didn't I help take down one of the tun servers with a routing loop?
<aleph->
Or did I just help make that error knowm
<aleph->
known...*
<danderson>
heh, yeah, one of the DERP servers went nuts when you did that thing
<danderson>
it does have rate-limiters to protect it and between users, so only you suffered from it
<danderson>
but it was a pretty hilarious cliff in the traffic graphs
<danderson>
1 ping -> 10MB/sec lol
<aleph->
Yeahhhh haha
<aleph->
danderson: Btw for next week, replied to your email for work stuff. Was laid up most the week as I mentioned haha.
<lovesegfault>
gchristensen: I found a better way to control backlight. Add `ddcci-driver` to extraModulePackages and load `ddcci-backlight` on boot. It just exposes them in `/sys/class/backlight` and you can control things with `echo` and no extra tools
<lovesegfault>
also easier to use b/c you can just write to all `/sys/class/backlight/ddcci*` devices and synchronize all your monitors with one command
<elvishjerricco>
lovesegfault: I use that on my desktop and it's very nice. It doesn't always work for me though, and there were some quirks with nvidia drivers that affected when I had to load the module (had to do it in the display manager setup commands, after writing some config thing for the nvidia card)
<lovesegfault>
Yeah, nvidia is a wildcard as always
<elvishjerricco>
Now I can just use the brightness keys on my keyboard, which is just so... so nice
<lovesegfault>
I use `brillo -e -S`
<elvishjerricco>
Never heard of brillo
<lovesegfault>
simple cli tool
<elvishjerricco>
Ah. Keyboard key is quicker :P
LnL- has joined #nixos-chat
LnL has quit [Ping timeout: 260 seconds]
<danderson>
aleph-: oh, right. I'm out for the start of the week
<aleph->
Heh, enjoy!
srhb has quit [Read error: Connection reset by peer]
jackdk has quit [Read error: Connection reset by peer]
jackdk has joined #nixos-chat
srhb has joined #nixos-chat
waleee-cl has quit [Quit: Connection closed for inactivity]
slack1256 has joined #nixos-chat
supersandro2000 has quit [Quit: Ping timeout (120 seconds)]
supersandro2000 has joined #nixos-chat
slack1256 has quit [Remote host closed the connection]
<eyJhb>
It is always a little fun updating once own NixOS router, while you are having a lecture! :D And then you just hope it works, else do a rollback :P
<aleph->
Eyeppp.
<aleph->
Speaking of I do kinda wish nixops had infinisil's rollback feature if unable to connect to a network on the host.
<aleph->
Or if it does advertised it better
<srk>
how do you handle network topology data and dns for your deployments?
<eyJhb>
aleph-: It is a really nice feature, the only thing I miss/annoys me is, that it will reboop my system if I cancel a deploy
ky0ko has quit [Read error: Connection reset by peer]
Gaelan has quit [Read error: Connection reset by peer]
ky0ko has joined #nixos-chat
__monty__ has joined #nixos-chat
FRidh has quit [Ping timeout: 272 seconds]
FRidh has joined #nixos-chat
supersandro2000 has joined #nixos-chat
supersandro2000 has quit [Changing host]
Dotz0cat_ has quit [Ping timeout: 240 seconds]
tilpner has joined #nixos-chat
Dotz0cat has joined #nixos-chat
cole-h has quit [Ping timeout: 272 seconds]
<infinisil>
eyJhb: i should really fix that already...
<infinisil>
Shouldn't be too hard
Dotz0cat has quit [Ping timeout: 264 seconds]
<sphalerite>
joepie91: a colleague is currently considering using JWT for authentication to avoid keeping state on the server side, that was one of your pet peeves, right? Do you have an article or such that explains why?
<joepie91>
even in the odd case that you really do need stateless tokens, it's a badly-designed standard resulting in security-critical implementation errors constantly
<joepie91>
in which case you want something like PASETO instead
BaughnLogBot has quit [Quit: ZNC 1.6.2+deb1 - http://znc.in]
<adisbladis>
[unpopular opinion]: Most problems people have with JWT comes from the fact that they know nothing about secure designs
<joepie91>
without even discussing whether that is true, that is frankly another reason why people should generally not be using it :)
<joepie91>
insufficiently misuse-resistant
<adisbladis>
That said, PASETO is pretty much how I've always used JWT anyway
<adisbladis>
But I think ppl bashing on JWT is a bunch of FUD
<adisbladis>
I even think PASETO did some major mistakes
<adisbladis>
Like standardising on ed25519
<adisbladis>
Which has very little support in hardware tokens
<adisbladis>
So it's not useful for many applications
<adisbladis>
In many ways I'd be happier with nistp256 (secp256r1)
<joepie91>
have you filed a bug? :P
<adisbladis>
Nah, I'd rather just stick to jwt where this "just works"
<adisbladis>
There are good reasons for JWT to have a flexible alg field
<gchristensen>
lovesegfault: oh that is great!
BaughnLogBot has joined #nixos-chat
<__monty__>
joepie91: Hmm, what did you do differently to have the second url encode the twiddle but not the first?
<__monty__>
adisbladis: There's a lot of pressure from the cryptography community not to include the NIST curves in anything though?
<adisbladis>
__monty__: Sure, but that's not practical.
<adisbladis>
Right now everyone is walking around with crypto hardware in their pockets that only supports those curves
<gchristensen>
really?
<adisbladis>
gchristensen: All android phones for one
<__monty__>
Otoh being under the impression you're doing something securely when it's not is maybe worse than not being able to do it "securely" at all.
<gchristensen>
they don't support any non-nist curves? that is a shame
<adisbladis>
gchristensen: Yep.. :/
<adisbladis>
And it's actually worse than it sounds
<__monty__>
Though maybe I'm too biased about the NIST curves. I don't believe any weaknesses are known publicly. They're just too suspect for me to have any confidence in them.
<gchristensen>
it is a bigger shame that math doesn't advance at the same speed of law
<adisbladis>
Because a lot of applications are using secp256k1 but phones only support secp256r1
<adisbladis>
This was a major hassle at my old job
<adisbladis>
Apple is actually really good here
<adisbladis>
Their enclaves support ed25519
<adisbladis>
But their nist curves are only r1
<gchristensen>
yay apple
<adisbladis>
But really, that r1/k1 split is annoying as hell
<adisbladis>
tl;dr; We had to do ECC in ethereum smart contracts
<adisbladis>
Because of the incompatible curves
<adisbladis>
Even though they are pretty much identical...
<joepie91>
__monty__: dunno, Firefox being weird I guess
<joepie91>
maybe I got one from the URL bar and another from Copy Link?
<siraben>
adisbladis: hehe, ethereum!
<joepie91>
adisbladis: also, to be clear, complaints about JWT certainly are not "FUD"
<joepie91>
it is a misdesigned standard where implementations do constantly fail in the same dumb (and dangerous ways) and which on top of that is constantly recommended for usecases that should not use stateless tokens
<joepie91>
all of this is trivially verifiable
<joepie91>
and "PASETO chose an algo that doesn't have hardware support" is, to put it mildly, not really a problem of the same magnitude as "lol you can completely bypass signature verification"
<gchristensen>
it reminds me of SAML's very common failure points
<V>
gchristensen: lol
<V>
I read your message before I saw the URL, and cannot unsee
<joepie91>
and whether one would personally choose JWT or not depending on circumstances does not really change that these are real problems with real impact
<adisbladis>
Sure, these are problems
<adisbladis>
But I'm not sure if they are problems with jwt as such
<adisbladis>
And I think making an inflexible standard to replace it isn't a solution
<joepie91>
sorry, but this is the exact same reasoning as "no, the problem isn't with C, but with people writing memory-unsafe code"
<joepie91>
dangerous tools are bad, end of
<joepie91>
unnecessarily dangerous tools*
<adisbladis>
I'm arguing that paseto is also bad :P
<adisbladis>
And not a good replacement
<joepie91>
I have seen no plausible arguments to support that
<joepie91>
"it does not use a hardware-supported algo" is not a safety issue, for example
<adisbladis>
It is
<joepie91>
how is it?
<adisbladis>
Having accessible key material is a huge liability
<adisbladis>
And with the standard as written it's not possible to work around it given real world hardware constraints
<adisbladis>
With JWT this is entirely trivial
<joepie91>
yeah, okay, sorry, but I'm not going down that particular rabbit hole. the reasoning always assumes that a perfectly secure enclave both exists and is used, neither of which are true
<adisbladis>
I'm not saying this hardware is perfect
<joepie91>
you may not be saying it, but I have very little faith that the rationale will hold up without that assumption, because that's basically always how it plays out when I try to have this discussion with people, and honestly it's become an exercise in time-wasting that I don't particularly wish to repeat
<adisbladis>
Same but in reverse
<joepie91>
if you feel that the algorithm selection in paseto is a poor choice, then the correct venue for reporting that and having an in-depth discussion on tradeoffs is the issue tracker
<adisbladis>
I'm sick and tired of people pushing ed25519 without consideration for the implications re key mgmt
<adisbladis>
joepie91: Or I keep using jwt which doesn't have this drawback?
<joepie91>
and if it actually works out being a better idea to choose a different algorithm, then I'm sure it will get changed accordingly
<joepie91>
adisbladis: which doesn't have this largely-theoretical drawback and instead signs you up for a perpetually-broken ecosystem of implementations :.
<joepie91>
:/ *
<joepie91>
there may well be specific circumstances where this tradeoff actually makes sense
<joepie91>
but it is not representative of how people actually use stateless tokens
<joepie91>
on average
<joepie91>
and in the way that people actually generally use them, the issue you're seeing with PASETO is basically irrelevant whereas people constantly get bitten by the JWT implementation issues
<joepie91>
please don't confuse those two cases
<joepie91>
very few developers even know about the existence of hardware enclaves, on the whole
<joepie91>
and so I can understand *you personally* making another choice, but I don't appreciate you dismissing these very real concerns as "FUD"
<joepie91>
it's already difficult enough to convey the problem to developers who don't understand the implementation internals or spec safety issues, please don't make that job harder by making such broad claims
<__monty__>
I wonder whether people believe enclaves solve the inherent privilege to grant equal access that comes with having access to key material?
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-chat
Dotz0cat has joined #nixos-chat
lunc has joined #nixos-chat
Dotz0cat has quit [Ping timeout: 256 seconds]
<andi->
I never got why we are still passing tokens around as matter of authorization. I would actually wish fro everyone that is using JWT to use JWS at the same time. JWT tokens (signed by the issuer that signifies the requesters key as trusted) will be passed on as auth token and the actuall message signed via JWS. The handling server can then (almost stateless?) confirm that a) the message is
<andi->
authenticated & b) the token hasn't been intercepted anywhere and the message is valid
<andi->
many JWTs should be short lived anyway and rolling a key for that period of time might not be a problem at all..
ky0ko has quit [Ping timeout: 246 seconds]
<__monty__>
:reload
<__monty__>
Apologies.
<infinisil>
> timeTo mars
<{^_^}>
"3 days, 1 hour, 39 minutes, 8 seconds"
<__monty__>
Ugh, it's been 3 days for days!
<gchristensen>
such is life when you're traveling at the speed of light
slack1256 has joined #nixos-chat
waleee-cl has joined #nixos-chat
<ldlework>
There was a young lady named Bright
<ldlework>
Whose speed was far faster than light;
<ldlework>
She set out one day
<ldlework>
In a relative way
<ldlework>
And returned on the previous night.
slack1256 has quit [Ping timeout: 265 seconds]
srhb has quit [Ping timeout: 264 seconds]
ghuntley has quit [Ping timeout: 268 seconds]
srhb has joined #nixos-chat
<__monty__>
When the running shoes you chose are great in every way but the fit :"(
ghuntley has joined #nixos-chat
rajivr has quit [Quit: Connection closed for inactivity]
<infinisil>
But all the definitions are only accessible by :v in the bot itself
<infinisil>
E.g.
<infinisil>
> :v mars
<{^_^}>
mars = date.parseDateTime "2021-02-18 19:15:00"
<infinisil>
(or I could manually publish the json of all definitions if wanted)
<infinisil>
Oh also, the date library used here is stored in a file on the nixbot host, soo that also can't be viewed without me manually publishing it atm 😅
<{^_^}>
{ day = <CODE>; hour = <CODE>; minute = <CODE>; month = <CODE>; second = <CODE>; year = <CODE>; }
<infinisil>
That's the NixOS 20.09 release date
<infinisil>
57th of September!
<aleph->
~Do you remember~
<aleph->
~The 57th of Septemberrrr~
<infinisil>
Ah yes
<das_j>
~Love was changing the mind of pretenders~
<samueldr>
well, it's not a *date*, but it's some kind of relative moment, and not having to deal with overflowing values in the right container at the right moment is a net bonus
<infinisil>
Oh wait, let's see if it can normalize it by converting to unix epoch and back
<aanderse>
i think i've only ever had ramen that wasn't spicy maybe twice in my life :D
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):475:11
<infinisil>
I'm kind of partial about spicy ramen
<aanderse>
pork+kimchi+miso ramen <3
<infinisil>
Because from the ramen I've tasted, the spicier ones seemed to have less flavor (or at least it was less noticeable due to the spice)
<infinisil>
I do like both spice and flavor though
<infinisil>
I'm currently making notes for which ramen has how much spice and how much flavor :)
<infinisil>
So far, spice seems to be inversely proportional to flavor
<aanderse>
taking notes on ramen sounds like a good idea ha ha ha
<infinisil>
(out of 4 products)
<joepie91>
this feels like a twitter account in the making
<joepie91>
@RamenRates or something
<infinisil>
Hehe
<infinisil>
Traveling the world, tasting ramen in all sorts of places
<aanderse>
i feel like this tv show must already exist
tilpner_ has joined #nixos-chat
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
<aleph->
It does I'm fairly certain
<cole-h>
Anybody else's "news feed" on GitHub get removed as well? (Visible on `https://github.com` when logged in)
<cole-h>
I relied on that to see what cool things the people I'm following were doing :(
<jtojnar>
refined-github?
<cole-h>
I have it disabled at the moment
<rmcgibbo[m]>
Does anyone know of a tutorial on how to use github actions to create a nix channel backed by a binary cache? e.g. having GH actions build on every commit but then only update the channel if the build succeeds and was pushed to cachix, so that installing from the channel will always trigger a fetch of the most recent successful build.
<rmcgibbo[m]>
Maybe some trick with having the CI run `git push --force` to a second branch after a successful build and then https://github.com/<owner>/<repo>/archive/<branch>.tar.gz as the channel...