I’m not an Arch user, but the Arch Wiki has become the best place to figure out how to do some random thing in Linux. Nice work Arch people — thank you.
I'm not holding my breath for it to change much, but wish the best of luck to progressive groups in the country nonetheless – Goddess knows the people of Iran deserve a fucking break.
I'm genuinely curious.. when I make #FOSS applications I always make it work according to my needs instead of thinking about making it usable for everyone else. Is this normal? Am I the only one who does this? #oss
@ro I try making my stuff portable but often streamline for my own use-case with the plumbing in place to streamline for others if the need actually arises.
My previous web framework for example had a mechanism to generate configs for easier deployments, but I only implemented it for nginx+uwsgi because that's what I was using.
@ro Eh, if it's geared towards your personal use-case anyways, I'd say just don't package and release it as a… crate I think is the term in rust?
If you wanna be super clear about this, you can just add a README with a note about what use case it actually works in or it not being for public consumption or whatever.
That way people can find it and use your code to possibly find a solution to their specific problems but it's clear that it's not a supported package.
Okay, after doing a couple hours of research I'll still want to use uwsgi to deploy the new site, even tho the project marked itself as "in maintenance mode".
Reason being that I need to pass info about client-cert auth to the web application but I don't want to pass it in via header because it's security-critical.
Doing it with headers would of course work, but then commenting out a line of the nginx config would lead to a silent-ish failure where clients can sidestep the entire cert auth by just sending the right headers and that seems like a bad idea – so I want to keep that info out-of-band.
That's what you can do with uwsgi_param – or fcgi_param and scgi_param for that matter.
There is support for (ha)proxy protocol in both nginx and Gunicorn to pass out-of-band information, but it has a pre-defined list of fields and while those seem to include whether the client cert auth passed, there's no field for the cert or its fingerprint, which I need to check which user the the cert is assigned to.
So, wrapping WSGI in FCGI or SCGI would feasibly be an option but the most popular project there – flup – is so old that even it's "new" python 3 port (flup6) is already so old that the repo isn't reachable and the last update was in 2015.
Apart from that, there only seem to be wrapper projects with like 5½ commits and a bus factor of "author might have already been swallowed by the earth". :thaenkin:
fuck #telegram why people think is secure? beats me, but here watch minute 7:16 https://vid.puffyan.us/watch?v=pjseaH7eX44 and STOP using telegram and whatsup!! :D use matrix or at least signal if your friends need something easy to use but matrix is the way.
Currently porting the TLS clientcert stuff from my old framework to my new site. Together with the (now proven to be time-stable) SHA3 password storage this marks the first time I'm building multi-factor authentication.
And all without annoying one time login tokens coming in through SMS or E-Mail.
Even better, with TLS client certs, authentication is done for every request (and upstream by nginx, so I can't even fuck up the security with a faulty implementation).
So even if an attacker manages to break flasks client-side cryptographically signed and verified cookie sessions, that still won't be enough to get in. :)
@jens I might be off here, after all it's been over a decade since I read the spec, but IIRC the cert is sent with every request and authenticated for every request.
Correct me if I'm wrong, but sessions aren't really a thing for HTTP itself as it's stateless and every request goes over a new connection, so grouping those into a "session" is a whole other can of worms and I'm pretty sure that's why pretty much every framework has its own mechanism to implement sessions.
@Exagone313
Ah yes, that sounds sensible. I probably just conflated TLS connections with HTTP requests in my brain over the years, because those more or less map 1:1 to each other (at least in a simplified abstraction).
Indeed, the devil is in the details – but for me the critical part is that for every request that arrives at my application, I can be sure that the associated connection went through the authentication.
All I have to do is check the env vars passed in by nginx (specifically, $ssl_client_verify and $ssl_client_raw_cert).
Tons of work (SVG 2, fill & stroke, and more) has sat unimplemented for years. At this point, in standards circles, we know not to touch SVG with a barge pole.
@leaverou I'm somebody who puts a focus on JS-less web development and I not only create SVG assets with Inkscape but also write SVG myself, both static and templated and I think it's the same reason why HTML didn't see any big developments in over 2 decades…
Google has a controlling interest on the web and Google wants everything to depend on JS because that's what their data collection (i.e. profits) are based on.
Computer is computering to determine if the timings on my SHA3-512 auth are leaky… and it's taking a loooong time to get the dataset to a statistically robust size. :F
here's the spiel i always give people about bojack horseman
it starts off as your typical adult animated comedy, something akin to family guy-lite but with a focus on lampooning hollywood
but midway through the first season, it slowly begins morphing into a far darker deconstruction of those same tropes
like it essentially asks the question: "what if someone tried living real life like it was a sitcom?" with all the consequences and drama that would entail
because bojack's whole thing is, he was a famous sitcom actor back in the 90's, and sees life like a series of tropes. but it DOESN'T work that way
the tone shift was so prominent that it permanently changed the way indiewire reviews seasons. now they review entire seasons at once instead of just the first half
@wilbr Mhh, not sure if that's a combination that jives well with me… maybe I'll check it out, but I still have one or two other weird shows to get through.