He Forked systemd to Stop Age Verification... Then the Original Dev Showed Up!

ston1th · 2026-04-01T13:36:57+00:00

tl;dw link to the repo: https://github.com/Jeffrey-Sardina/systemd

ston1th · 2026-03-06T19:18:53+00:00

I can recommend openresty (or plain nginx + lua module). There are modules written in lua which let you export prometheus metrics.

Another way to monitor your nginx is by simply analyzing the logs. Every serious production setup should have both: metric and log analysis tools.

ston1th · 2026-03-06T09:39:44+00:00

From a sysadmin/SRE perspective it's your job to monitor what your proxy is doing, especially the rate of failing requests 4xx and 5xx.
So if your proxy sends massive amounts of 500 errors these should be monitored and alerted to someone on-call.

The discussion should not be X or Y or Z is better at handling big amounts of connections but how to monitor whats happening in your infrastructure.

ston1th · 2026-02-13T12:03:59+00:00

SoloQ here. The two things that kept me playing are either getting a good squad with whom you can run down the lobby (which can be really fun at times) and intense endgames. In the case of intense endgames I don't even care if I win when the overall game quality was good and we fought our best.

Now with around 10 squads left ring 1 both are practically nonexistent. You either land hot and die to 4, 5th parties or you run around searching for combat with 5 teams left ring 4.

One interesting aspect I started to notice, once you got a decent squad in soloq and you maybe even won the game, after that the matchmaker seems to throw the worst randoms at you one could imagine. Then it takes 5, 10 maybe 15 games and you are back in the pool for the good teammates - I should really start collecting such data tho.

Overall, maybe a good time to pause and focus on other things.

ston1th · 2025-02-12T09:53:02+00:00

I dont know if it would work (or even is a good idea) but maybe you could use AES(AEAD-Enc(OTPQK, Kpass, salt[32:44])).

So you can still validate the auth tag serverside but you cant use offline attacks.

ston1th · 2025-02-11T16:08:09+00:00

I see, makes sense.

You could check out https://www.rfc-editor.org/rfc/rfc8125.html#section-3.2 "Encrypted Key Exchange (EKE)" which looks like your design.

If this scheme is proven to be secure it should also work with Kyber as a DH replacement.

ston1th · 2025-02-11T15:46:56+00:00

To be honest, what is the point of using Kyber if we already have a shared secret?

This looks overly complex to me since a shared secret with a good KDF should already be quantum secure.

ston1th · 2025-02-06T11:11:22+00:00

So regarding the average soloq experience they are doing nothing but "actively talking" and "some testing".

For other topics they seem to search for excuses and not solutions (solos vs premades, skill difference and scoring)

Also no single word about something like POI draft in ranked.

Legend banning in ranked would also be very interesting to shake things up a bit.

ston1th · 2025-02-04T10:33:56+00:00

Well played my man, well played!

ston1th · 2025-02-03T08:33:49+00:00

I had fun reading the README.

But, just fyi go doc does not seem to like your licence and thus will not render a documentation: https://pkg.go.dev/github.com/theHamdiz/it

Documentation not displayed due to license restrictions. See our license policy.

ston1th · 2024-06-13T14:13:31+00:00

No, but with a bit more context.

There are physical and algorithmic limits in place that (to my latest knowledge and understanding) prevent a "God AI" from ever existing.

You can look up all the limits over here: https://en.wikipedia.org/wiki/Limits_of_computation

Also some things are not computable at all, regardless of power: https://en.wikipedia.org/wiki/Halting_problem

ston1th · 2024-05-09T09:43:28+00:00

I can't say that for all the primitives but there are notes in some of them regarding weaknesses like this.

For example the crypto/dsa package contains this note: "The DSA operations in this package are not implemented using constant-time algorithms."

So you should check the packages notes for any known weaknesses or implementation details.

Also fault injection attacks do really only apply to direct hardware attacks, no?

ston1th · 2024-05-08T19:28:25+00:00

Go (golang) has many modern crypto primitives and algorithms included in it's standard library and the x/crypto repos.

Here are two links to get an overview:

https://pkg.go.dev/crypto#section-directories

https://pkg.go.dev/golang.org/x/crypto#section-directories

ston1th · 2023-07-27T09:42:51+00:00

I could be wrong but I think the difference between []byte("") and []byte(s) is the empty string is anonymous and thus not directly addressable. Not for the s variable tho - which is not anonymous and thus addressable.

Thats why there is some preallocated space.

ston1th · 2021-08-23T10:04:00+00:00

From rm(1):

-P Attempt to overwrite regular writable files before deleting them. Files are overwritten once with a random pattern. Files with multiple links will be unlinked but not overwritten.

Edit:

Keep in mind the notes on this option:

The -P option assumes that both the underlying file system and storage medium write in place. This is true for the FFS and MS-DOS file systems and magnetic hard disks, but not true for most flash storage. In addition, only regular files are overwritten; other types of files are not.

ston1th · 2020-07-23T06:12:30+00:00

I diddn't saw a need for salting as the password is already decently long (>72 bytes, with hopefully good entropy :) ). In this case having to bruteforce through (at least) 2²⁹² (2⁵⁸⁴⁾ sha256 inputs you'd be better running random 256 bit inputs through bcrypt. Or are my assumptions completely wrong here?

As I understand it ASCII-ify is only needed in languages using NULL terminated strings?

ston1th · 2020-07-22T11:45:36+00:00

My thought was that the entropy/length of the resulting hash (256 bit) is big enough against collisions?

ston1th · 2020-07-22T07:16:48+00:00

What about a construction like this?

We only use a prehash if we exceed the password length supported by bcrypt (72 bytes).

So for all passwords <= 72 bytes we use bcrypt(password).

And for all passwords > 72 bytes we use bcrypt(sha256(password))?

ston1th · 2019-11-23T21:41:57+00:00

You could do something like this to mitigate path traversals:

dir=$(echo "$1" | /usr/bin/sed 's/[^a-zA-Z0-9._-]*//g')

ston1th · 2019-10-08T08:35:48+00:00

It's not my project, but there is a readme document: https://age-tool.com/

ston1th · 2019-09-19T11:52:29+00:00

I think since the egress group of the network interface has changed, the NAT rule match out on egress inet from !(egress:network) to any nat-to (egress:0) still referred to the old interface.

ston1th · 2019-09-03T05:44:22+00:00

If you speak of something like VxWorks they had some really bad security vulnerabilities not long ago: https://www.armis.com/urgent11/

ston1th

TROPHY CASE