komuW

Take a look at FSRS.

The paper: https://dl.acm.org/doi/10.1145/3534678.3539081?cid=996605471...

Various implementations: https://github.com/open-spaced-repetition/awesome-fsrs

Some benchmarks of various srs algorithms: https://expertium.github.io/Benchmark.html

Have you looked at Tyk? https://github.com/TykTechnologies/tyk/

Location: Nairobi, Kenya

Remote: Yes

Willing to relocate: No

Technologies: Golang, Python, Django, SQL, PostgreSQL, AWS

Résumé/CV: https://www.komu.engineer/cv/komu-CV.pdf

Email: [email protected]

Blog: https://www.komu.engineer/blog

I'm a software engineer with ~8yrs experience. Here's somethings that I've done;

- Reduced cloud costs for a production kubernetes service by 20%. This was done by analysing pod utilisation on kubernetes and then right-sizing the pods to match the expected usage.

- Read the SMPP specification and implemented a client for it from scratch. Integrated the client into a production application and used it to send out SMS at averaget rates of 800/second.

- Created an open source ACME client based off the ACME specification.

Hi, could you guys please reply to job applications. I had applied in April and up to now I haven't received even a rejection email.

My solution[1] to this problem is to do what they did in the Apollo Guidance Computer; log to a ring buffer and only flush it (to disk or wherever) on certain conditions.

1. https://www.komu.engineer/blogs/09/log-without-losing-contex...

Nice article. If you ever wondered how the python equivalent(celery) works, I wrote a blogpost about that ~4years ago; https://www.komu.engineer/blogs/07/understand-how-celery-wor...

My favorite technique for reducing the cost of logging is the same technique that was employed in The Apollo Guidance Computer(though I'm not sure if they did it for cost purposes).

To quote from Annotations to Eldon Hall's Journey to the Moon[1]: "The Coroner recorded every instruction executed, with its inputs and results, writing over the oldest record when it filled up. When a program crashed, you could punch out a full record of what it was doing in most of its last second and analyze the problem at your ease. I have often wished that PCs offered such an advanced feature."

So essentially buffer all logs into an in-memory circular buffer of capacity N. If a log record is emitted that has a certain severity/level; flush all records from the buffer to disk/clickHouse/grafana/whatever.

The python MemoryHandler[2] almost implements the said technique, except that it also flushes when buffer is full; which is not particularly what I would want.

I also wrote a blogpost[3] about how to log without losing money or context, ~3yrs ago.

1. https://authors.library.caltech.edu/5456/1/hrst.mit.edu/hrs/...

2. https://github.com/python/cpython/blob/v3.11.1/Lib/logging/h...

3. https://www.komu.engineer/blogs/09/log-without-losing-contex...

Note that dumping the Vault's process memory is beyond hashicorp/Vault's threat model. See: https://github.com/hashicorp/vault/issues/1446#issuecomment-...

I'm bringing this up because the circleCI blogpost says that the attacker did memory-dump encryption keys from a running process. See https://circleci.com/blog/jan-4-2023-incident-report/

So even if they were using hashicorp/vault, the attacker could probably still have been able to mem-dump vault's process.

Note that dumping the Vault's process memory is beyond hashicorp/Vault's threat model. See: https://github.com/hashicorp/vault/issues/1446#issuecomment-...

yeah this just kicks the can down the road.

> That requires client-side SSL authentication,

I do not think it requires client side SSL. See: https://engineering.salesforce.com/tls-fingerprinting-with-j...

What is been fingerprinted is the TLS negotiation between client and server.

From the circleCI blogpost[1]: "Our investigation indicates that the malware was able to execute session cookie theft, enabling them to impersonate the targeted employee in a remote location"

I haven't seen much discussion on how this specific attacker entrypoint can be mitigated. So I'm going to make a naive attempt in this comment.

How about storing the client's IP address in the session cookie. Then whenever the server recieves the cookie, it compares the client's IP address against the one stored in the session cookie. The server denies the login if there's a mismatch. The cookie would of-course have to be signed(hmac etc) so that it is tamper proof.

One problem with this is that client IP addresses are easily spoofed[2].

So, instead of storing the client's IP address; how about we instead store the clients' SSL fingerprints[3][4]. I haven't looked much into the literature, but I think those fingerprints are hard to spoof.

1. https://circleci.com/blog/jan-4-2023-incident-report/

2. https://adam-p.ca/blog/2022/03/x-forwarded-for/

3. https://github.com/salesforce/hassh

4. https://github.com/salesforce/ja3

it's unrelated; https://news.ycombinator.com/item?id=33382369

Filippo Valsorda(FiloSottile), who is the maintainer of Go's cryptography libraries said on Go's slack channel that the patch is unrelated.

See screenshot of the slack conversation: https://paste.pics/f5622033ae711b36e0bbcda393a67866

Filippo Valsorda(FiloSottile), who is the maintainer of Go's cryptography libraries said on Go's slack channel that the patch is unrelated.

See screenshot of the slack conversation: https://paste.pics/f5622033ae711b36e0bbcda393a67866