Mkcert: Simple zero-config tool to make locally trusted development certificates
https://github.com/FiloSottile/mkcert
https://github.com/FiloSottile/mkcert
dotnet run app.cs
.NET 10 Preview 4 introduces file-based apps, allowing direct execution of C# files using dotnet run. This feature streamlines development, especially for beginners, and supports directives, NuGet packages, and cross-platform scripting.
Do It by Code
dotnet run app.cs .NET 10 Preview 4 introduces file-based apps, allowing direct execution of C# files using dotnet run. This feature streamlines development, especially for beginners, and supports directives, NuGet packages, and cross-platform scripting.
Referencing NuGet packages with #:package
#:package Humanizer@2.14.1
using Humanizer;
var dotNet9Released = DateTimeOffset.Parse("2024-12-03");
var since = DateTimeOffset.Now - dotNet9Released;
Console.WriteLine($"It has been {since.Humanize()} since .NET 9 was released.");
Forwarded from Gregory Klyushnikov
AI is a solution in a desperate search of a problem, just like blockchain. AI is very good at solving some very specific tasks, like data classification or generation of new data based on a prompt (image generation, speech synthesis, etc), but to use it for anything else is nothing but pure hype
👍1
CVE-2025-48827
- blog
- PoC (gist)
- PoC (by EgiX)
- kevintel
- CWE-424: Improper Protection of Alternate Path
- CWE-424 Example
#vulnerability #rce
Unauthenticated API Access in vBulletin:
vBulletin 5.0.0 through 5.7.5 and 6.0.0 through 6.0.3 allows unauthenticated users to invoke protected API controllers' methods when running on PHP 8.1 or later, as demonstrated by the /api.php?method=protectedMethod pattern, as exploited in the wild in May 2025.
- blog
- PoC (gist)
- PoC (by EgiX)
- kevintel
- CWE-424: Improper Protection of Alternate Path
- CWE-424 Example
#vulnerability #rce
Do It by Code
Avoid Updating your MinIO instance developers introduce trojan horse update stripping community edition of most features in the UI I noticed today that my MinIO docker image had been updated and the UI was stripped down to just an object browser. After some…
GitHub
GitHub - seaweedfs/seaweedfs: SeaweedFS is a distributed storage system for object storage (S3), file systems, and Iceberg tables…
SeaweedFS is a distributed storage system for object storage (S3), file systems, and Iceberg tables, designed to handle billions of files with O(1) disk access and effortless horizontal scaling. - ...
Recursive mutex misuse
What is a Recursive Mutex?
Potential Misuse Scenarios:
1. Incorrect Unlock Amount:
If a thread locks a recursive mutex multiple times but then unlocks it fewer times than it locked it, the mutex may become "permanently locked" in the sense that no other thread can acquire it.
2. Calling Unsafe Code:
If a thread accidentally calls unsafe code while holding a recursive mutex, and then attempts to lock it again, it could lead to unpredictable behavior.
3. Misunderstanding the Purpose:
Recursive mutexes are designed for situations where a thread needs to acquire the same mutex multiple times within the same execution context, such as when a function calls itself or when multiple parts of an object need to be protected by the same lock. Misusing them for situations where they're not necessary can lead to performance overhead and make the code harder to understand.
Recursive mutex misuse occurs when a thread incorrectly attempts to acquire a recursive mutex multiple times from the same thread without first unlocking it, leading to a deadlock or unexpected behavior.
What is a Recursive Mutex?
• A recursive mutex (also known as a reentrant mutex) allows a thread to acquire the same mutex multiple times from the same thread without causing a deadlock.
• Each time the mutex is locked, an internal counter is incremented. The mutex is only released when the counter reaches zero, which happens when the thread unlocks the mutex the same number of times it locked it.
Potential Misuse Scenarios:
1. Incorrect Unlock Amount:
If a thread locks a recursive mutex multiple times but then unlocks it fewer times than it locked it, the mutex may become "permanently locked" in the sense that no other thread can acquire it.
2. Calling Unsafe Code:
If a thread accidentally calls unsafe code while holding a recursive mutex, and then attempts to lock it again, it could lead to unpredictable behavior.
3. Misunderstanding the Purpose:
Recursive mutexes are designed for situations where a thread needs to acquire the same mutex multiple times within the same execution context, such as when a function calls itself or when multiple parts of an object need to be protected by the same lock. Misusing them for situations where they're not necessary can lead to performance overhead and make the code harder to understand.
Do It by Code
2. Calling Unsafe Code:
Unsafe Code: "Unsafe" code typically refers to:
1. Code that can bypass the language's safety guarantees
2. Code that might interact directly with hardware or memory
3. Code that could cause undefined behavior
The Problem Scenario:
1. Thread acquires a recursive mutex (locks it)
2. While holding this lock, it calls some "unsafe" code
3. This unsafe code tries to lock the same mutex again
4. Something goes wrong because the unsafe code doesn't follow proper rules
Example in C++:
The real danger is that unsafe code might:
- Not follow proper locking/unlocking patterns
- Manipulate the mutex's internal state directly
- Cause memory corruption that affects the mutex
- Create deadlocks or resource leaks
This is why languages with memory safety like Rust mark such operations as
1. Code that can bypass the language's safety guarantees
2. Code that might interact directly with hardware or memory
3. Code that could cause undefined behavior
The Problem Scenario:
1. Thread acquires a recursive mutex (locks it)
2. While holding this lock, it calls some "unsafe" code
3. This unsafe code tries to lock the same mutex again
4. Something goes wrong because the unsafe code doesn't follow proper rules
Example in C++:
#include <mutex>
#include <iostream>
std::recursive_mutex rmutex;
void unsafe_function() {
// This function doesn't properly handle the mutex
// Maybe it was written by another team or uses a C library
// It tries to lock the mutex but doesn't unlock it properly
rmutex.lock();
// Maybe it throws an exception or returns early
throw std::runtime_error("Something went wrong!");
// The unlock never happens!
rmutex.unlock();
}
void normal_function() {
// Lock the recursive mutex
rmutex.lock();
std::cout << "Doing some work with the lock held" << std::endl;
try {
// Call the unsafe function while holding the lock
unsafe_function();
} catch (const std::exception& e) {
std::cout << "Caught exception: " << e.what() << std::endl;
}
// We think we only need to unlock once, but the unsafe function
// has left the mutex in an inconsistent state
rmutex.unlock();
}
The real danger is that unsafe code might:
- Not follow proper locking/unlocking patterns
- Manipulate the mutex's internal state directly
- Cause memory corruption that affects the mutex
- Create deadlocks or resource leaks
This is why languages with memory safety like Rust mark such operations as
unsafe - they're telling you "be extremely careful here, the compiler can't protect you."
Do It by Code
Recursive mutex misuse Recursive mutex misuse occurs when a thread incorrectly attempts to acquire a recursive mutex multiple times from the same thread without first unlocking it, leading to a deadlock or unexpected behavior. What is a Recursive Mutex?…
before using a Mutex in a programming language, always make sure whether that specific mutex implementation is a recursive mutex (reentrant mutex) or a normal mutex.
Some languages such as C++ have different implementations with clear names:
- std::mutex
- std::recursive_mutex
- std::recursive_timed_mutex
etc...
but some languages such as GDScript's Mutex class only have a single
And some other languages such as Golang, do not recommend using a recursive mutex at all.
Some languages such as C++ have different implementations with clear names:
- std::mutex
- std::recursive_mutex
- std::recursive_timed_mutex
etc...
but some languages such as GDScript's Mutex class only have a single
Mutex class and it's a reentrant mutex.And some other languages such as Golang, do not recommend using a recursive mutex at all.
Do It by Code
And some other languages such as Golang, do not recommend using a recursive mutex at all.
One thing that people make mistake is: most of the times we assume only calling
You need to ensure you only call unlock after the mutex has been locked by the current thread, otherwise you may get deadlock, crashes or undefined behavior. (do you notice the "may"? because it entirely depends on the implementation of the mutex, or the platform)
For example, in C++:
- mutex.unlock
- timed_mutex.unlock
- recursive_mutex.unlock
- recursive_timed_mutex.unlock
- shared_mutex.unlock
- shared_timed_mutex.unlock
All of the articles above are saying the same thing:
"The mutex must be locked by the current thread of execution, otherwise, the behavior is undefined."
In other programming languages, such as Golang, you will panic (or exception).
.lock method on a mutex can cause a deadlock, however .unlock is also very important...You need to ensure you only call unlock after the mutex has been locked by the current thread, otherwise you may get deadlock, crashes or undefined behavior. (do you notice the "may"? because it entirely depends on the implementation of the mutex, or the platform)
For example, in C++:
- mutex.unlock
- timed_mutex.unlock
- recursive_mutex.unlock
- recursive_timed_mutex.unlock
- shared_mutex.unlock
- shared_timed_mutex.unlock
All of the articles above are saying the same thing:
"The mutex must be locked by the current thread of execution, otherwise, the behavior is undefined."
In other programming languages, such as Golang, you will panic (or exception).
Do It by Code
One thing that people make mistake is: most of the times we assume only calling .lock method on a mutex can cause a deadlock, however .unlock is also very important... You need to ensure you only call unlock after the mutex has been locked by the current…
In GDScript? you might get nothing.
no errors, no warnings, no logs, no nothing. since it's built on top of C++.
However, sometimes you might get deadlocks.
if the deadlock happens on your main thread, the whole code editor will freeze.
If you are running an exported game, the game will freeze, no logs.
If you look at event viewer, you will encounter this error:
not helpful at all. You will have to put breakpoints yourself and debug the code (painful).
Next thing is that, this might not be reproducible in 100% of cases. for example in my case, it was only happening on macos and windows, the linux version was working fine. Even more confusing and weird.
no errors, no warnings, no logs, no nothing. since it's built on top of C++.
However, sometimes you might get deadlocks.
if the deadlock happens on your main thread, the whole code editor will freeze.
If you are running an exported game, the game will freeze, no logs.
If you look at event viewer, you will encounter this error:
The program name.exe version 1.0.0.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.
not helpful at all. You will have to put breakpoints yourself and debug the code (painful).
Next thing is that, this might not be reproducible in 100% of cases. for example in my case, it was only happening on macos and windows, the linux version was working fine. Even more confusing and weird.
Do It by Code
In GDScript? you might get nothing. no errors, no warnings, no logs, no nothing. since it's built on top of C++. However, sometimes you might get deadlocks. if the deadlock happens on your main thread, the whole code editor will freeze. If you are running…
oh btw if this happens in a background thread...then may God help you 🙏
because as far as I know, Godot's debugger does not fully support debugging background threads yet (idk maybe this is implemented in recent versions of 4.*)
But yes, even if it supports, it will just make you more confused, because even if the editor does not freeze, but things just might not be working the way they are supposed to work...
welcome to concurrency hell (if you don't manage it correctly that is)
because as far as I know, Godot's debugger does not fully support debugging background threads yet (idk maybe this is implemented in recent versions of 4.*)
But yes, even if it supports, it will just make you more confused, because even if the editor does not freeze, but things just might not be working the way they are supposed to work...
welcome to concurrency hell (if you don't manage it correctly that is)