arwt

You can. See: https://docs.astral.sh/uv/reference/cli/#uv-run--exclude-new...

How you use it depends on your workflow. An entry like this in your pyproject.toml could suffice:

  [tool.uv]
  exclude-newer = "5 days"

You can check the benchmarks here: https://github.com/tempestphp/100-million-row-challenge/blob...

A "good" run seems to be around 20-40s mark.

There are hundreds of shady crypto projects in the world right now, each one shadier than the last.

World order is out of the door, and has been for a while -- they are all probably fighting amongst themselves to get her onto their board ASAP.

Reminds me of the Tailwind situation.

I feel bad for Jeff and more importantly all of the staff members who are now out of a job. Laracasts was the first ever sort of online course I paid for, and I got immense value out of it at that time.

But times change. This is more true now than ever.

It is a brutal world. Good luck to them.

I implemented something similar a while back (exists just as a portfolio demo now: subpinger (dot) interrupt (dot) sh).

If you want go for that sort of "live" feeling, you should consider implementing websocket streaming instead of HTTP polling, it will feel a lot nicer for users.

Are you actually ingesting certificates or are you just showing a stream of entries from different logs? I figure the former as nothing seems to be searchable -- and ingesting this data can get very expensive very quickly.

Nevertheless, cool project! I am constantly thinking about ways to turn CT log data into meaningful, actionable streams for others. If you'd be up for working on something together, give me a shout!

Is there anything stopping you from transferring it to a different registrar before renewal, who might not charge you as much?

Or is the renewal price for "premium" domains controlled by the registry (e.g. Verisign)?

You raised some red flags with the information you provided. This doesn't happen to everyone. A support rep from Hetzner has spoke a bit more about this process on WebHostingTalk before[1], although they don't get into which specific heuristics may result in flagged accounts for obvious reasons. I'd imagine it's a combination of things like unpaid balances on previous accounts, IP address reputation, uncommon e-mail domains and so on.

[1] https://www.webhostingtalk.com/showthread.php?t=1810197&p=10...

Interesting idea! Looking forward to trying this once some VMs are available. :-)

Very interesting read. Thank you!

I'd love to see some insight as to how they were able to generate that domain name. Surely if they can do that (years ago, even), then a well-funded adversary would be able to generate the same now, given enough time.

Maybe it took x thousands of compute years to generate the secret key for `facebokcorewww` - and they didn't care about the last character. But still, let's say you're a government agency with endless resources - how hard would it be to recreate that private key? If a private corp can do it once with finite resources - why can't you?

Was it is just a stroke of luck for those working on it? What are the chances?

The risk has always been there with this kind of attack. The severity, as always, depends on the attackers' modus operandi. Nothing has changed. Only the tools which are dropped onto the machine have changed - which really isn't specifically relevant to this kind of attack. (Spy|Mal)ware adapts, as it always will. Harvesting saved browser passwords is nothing new. In this case, it's a marketing gimmick.

It's fun that it is customisable via a programming language. But really - this doesn't add anything new to the table at all. I bet you could do all of this with the previous generation of rubber duckies with a little bit of know-how. Drop a basic reverse shell (providing no firewall restrictions or whatever), and you can do what you want.

The same prevention guidelines apply as always. Don't plug random USB devices into your computer.