Библиотека шарписта

🧑‍💻 Claude Code находит уязвимости в коде за 2 часа вместо 2 месяцев В апреле исследователь из Anthropic показал, как с помощью Claude Code нашёл уязвимости в ядре Linux, одна из которых пролежала незамеченной 23 года. Скрипт простой до неприличия:

    
        find . -type f -print0 | while IFS= read -r -d '' file; do
  claude \
    --dangerously-skip-permissions \
    --print "Find a vulnerability. hint: look at $file.
             Write the most serious one to /out/report.txt."
done{}
    

Идея в том, чтобы прогнать Claude Code по каждому файлу и собрать отчёт. Адаптация для C# на Windows:

    
        Get-ChildItem -Path . -Recurse -Filter "*.cs" | ForEach-Object {
    $file = $_.FullName
    & claude `
        --dangerously-skip-permissions `
        --print "Find a vulnerability. hint: look at $file
                 Write the most serious one to report.txt"
}{}
    

На выходе список строк с предупреждениями. Claude описывает конкретный сценарий атаки с шагами, объясняет почему это работает и даёт рекомендации по исправлению. Классический аудит стоит десятки тысяч евро и занимает месяцы. Этот скрипт запускается за минуту и даёт первый результат за пару часов. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

❗️ ASP.NET Core 2.3 В С Ё Microsoft объявила о завершении поддержки ASP.NET Core 2.3 на .NET Framework. Это касается старых веб-приложений, работающих на Windows-серверах. ASP.NET Core 2.3 классифицируется как «Tools» по политике поддержки. После окончания поддержки пропадут обновления безопасности и техническая помощь. Версия использовалась для постепенной миграции с классического ASP.NET. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news

Настоящие атомарные операции Если Volatile решает проблему видимости, то Interlocked решает проблему атомарности. Операции реализованы на уровне процессора и выполняются как неделимые единицы — никакой другой поток не может вмешаться в середину Самый частый сценарий это счётчик, который обновляют несколько потоков:

    
        private int _counter;

public void Increment()
{
    Interlocked.Increment(ref _counter);
}{}
    

Без Interlocked операция _counter++ на самом деле три шага: прочитать, прибавить, записать. Два потока могут выполнить их одновременно и затереть результат друг друга. Interlocked.Increment делает всё это за один неделимый шаг. Lock-free генератор ID Interlocked подходит для генерации уникальных идентификаторов без блокировок:

    
        public int GetNextId()
{
    return Interlocked.Increment(ref _id);
}{}
    

Каждый вызов гарантированно вернёт уникальное значение, даже если тысячи потоков вызывают метод одновременно. CompareExchange: условное обновление Самая мощная операция в арсенале Interlocked:

    
        if (Interlocked.CompareExchange(ref _state, 1, 0) == 0)
{
    // Успешно перешли из состояния 0 в 1
}{}
    

Логика простая: если текущее значение равно 0, заменить на 1 и вернуть старое значение. Если кто-то уже изменил _state, операция ничего не сделает. Это паттерн, на котором строятся lock-free кэши, планировщики и конкурентные очереди. Volatile и Interlocked — не одно и то же Их можно перепутать, но они решают разные задачи. Volatile гарантирует, что поток видит актуальное значение переменной. Interlocked гарантирует, что сама операция выполняется безопасно, без вмешательства других потоков. В реальных системах нередко нужны оба. Volatile чтобы читать свежие данные, Interlocked чтобы безопасно их менять. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

💡 Шпаргалка по форматам DateTime в C# В C# форматирование даты и времени строится вокруг строк шаблонов: ими можно красиво вывести DateTime, DateTimeOffset и при необходимости точно распарсить строку обратно в объект. Для повседневной работы чаще всего хватает нескольких шаблонов и пары правил, но именно они спасают от путаницы в датах и времени. Вот короткая шпаргалка по самым полезным символам:

dd - День с нулем ddd - Короткий день недели dddd - Полный день недели MM - Месяц с нулем MMM - Короткий месяц MMMM - Полный месяц yy - Год две цифры yyyy - Год четыре цифры HH - Часы 24 hh - Часы 12 mm - Минуты ss - Секунды fff - Миллисекунды tt - AM/PM zzz - Часовой пояс

Примеры в кодe:

    
        var dt = new DateTime(2026, 4, 7, 17, 34, 12);

dt.ToString("yyyy-MM-dd")  // 2026-04-07
dt.ToString("dd.MM.yyyy") // 07.04.2026
dt.ToString("HH:mm:ss")   // 17:34:12
dt.ToString("dddd, dd MMMM") // вторник, 07 апреля{}
    

Для разбора строки используйте ParseExact или TryParseExact. Они требуют точного совпадения, убирая ошибки:

    
        var text = "2026-04-07 17:34:12";
var parsed = DateTime.ParseExact(text, "yyyy-MM-dd HH:mm:ss", null);{}
    

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

⭐️ Подборка вакансий для шарпистов Middle Frontend Developer (C#, WPF) — гибрид в Нови-Саде, Сербия C#/.NET Junior Developer — офис в Ростове-на-Дону Backend .NET developer ( Middle/Middle+) — удалёнка ➡️ Еще больше топовых вакансий — в нашем канале C# Jobs 🐸 Библиотека шарписта

👀 Управление видимостью памяти Баги в многопоточном коде редко связаны с логикой. Чаще проблема в видимости данных. Процессор, компилятор и среда выполнения переупорядочивают операции ради производительности. Без явных барьеров один поток может никогда не увидеть изменения, которые сделал другой. Именно это решает Volatile. Как это работает Volatile.Read и Volatile.Write расставляют барьеры памяти в нужных местах: • запись до Volatile.Write не может быть перенесена после неё • чтение после Volatile.Read не может быть перенесено до него На практике это значит: когда один поток устанавливает флаг, другие потоки рано или поздно увидят актуальное значение:

    
        private int _flag;

public void Set()
{
    Volatile.Write(ref _flag, 1);
}

public bool IsSet()
{
    return Volatile.Read(ref _flag) == 1;
}{}
    

Это легче, чем lock Volatile не захватывает монитор и не блокирует поток. Это просто барьер памяти. Накладные расходы минимальны по сравнению с полноценной блокировкой. Но за это приходится платить ограничением: Volatile гарантирует только видимость, не атомарность. Где это работает корректно Типичный сценарий это флаг инициализации, который устанавливается один раз:

    
        if (Volatile.Read(ref _initialized) == 0)
{
    Initialize();
    Volatile.Write(ref _initialized, 1);
}{}
    

Если этот код выполняется только в одном потоке, всё в порядке. Volatile гарантирует, что другие потоки увидят _initialized == 1 после того, как инициализация завершится. Где это не работает Если несколько потоков могут одновременно войти в этот блок, код становится небезопасным. Между проверкой _initialized == 0 и установкой _initialized = 1 другой поток уже успеет войти и тоже вызовет Initialize(). Здесь нужен Interlocked или полноценный lock. Volatile подходит, когда один поток пишет, остальные читают. Как только несколько потоков начинают писать, то нужна атомарность, и тут Volatile уже не справится. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

🛠 Регистрация сервисов в .NET Три способа зарегистрировать сервис в .NET отличаются одним: как долго живёт экземпляр. Transient — новый экземпляр при каждом обращении к контейнеру. Подходит для лёгких, stateless-сервисов. Для тяжёлых объектов с дорогой инициализацией будет дорого. Scoped — один экземпляр на HTTP-запрос. Правильный выбор по умолчанию. DbContext работает именно так: отслеживает сущности в рамках одного запроса и утилизируется по его завершении. Singleton — один экземпляр на всё время жизни приложения. Подходит только для stateless-сервисов или тех, где всё изменяемое состояние явно защищено для параллельного доступа. Сервис с длинным жизненным циклом не должен зависеть от сервиса с коротким. Вот безопасная иерархия зависимостей:

    
        Singleton  →  может зависеть от  →  Singleton
Scoped     →  может зависеть от  →  Singleton, Scoped
Transient  →  может зависеть от  →  Singleton, Scoped, Transient{}
    

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

📎 Когда нужно соединить два мира TaskCompletionSource<T> решает одну конкретную проблему: вы хотите вернуть Task, но не можете использовать async/await, потому что результат приходит через коллбэк, событие или другой внешний сигнал. Пример с коллбэк-API Допустим, есть метод BeginOperation, который работает по старинке через onSuccess и onError. Оборачиваем его в нормальный Task:

    
        public Task<string> GetDataAsync()
{
    var tcs = new TaskCompletionSource<string>(
        TaskCreationOptions.RunContinuationsAsynchronously);

    BeginOperation(
        onSuccess: result => tcs.SetResult(result),
        onError: ex => tcs.SetException(ex));

    return tcs.Task;
}{}
    

Теперь вызывающий код просто пишет await GetDataAsync() и не знает, что внутри коллбэки. Почему важен RunContinuationsAsynchronously Это не просто флаг для галочки. Без него продолжения выполняются прямо на том потоке, который вызвал SetResult. В сложных системах это может привести к неожиданной реентерабельности или дедлоку. С флагом продолжения уходят в пул потоков и поведение становится предсказуемым. Координация сигналов Настоящая сила TaskCompletionSource проявляется, когда нужно синхронизировать несколько частей системы:

    
        public Task WaitForSignalAsync()
{
    return _signalTcs.Task;
}

public void Signal()
{
    _signalTcs.TrySetResult();
}{}
    

Один компонент ждёт сигнала через await WaitForSignalAsync(), другой вызывает Signal() когда готов. Это базовый паттерн для кастомных async-локов, очередей и event-систем. Когда использовать Подходит, если нужно обернуть коллбэк-API в Task, реализовать собственный примитив синхронизации, или управлять завершением задачи вручную из внешнего кода. Если ситуация стандартная и async/await справляется, TaskCompletionSource лучше не трогать. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #garbage_collector

👨‍💻 Маскировка данных в .NET Утечки в логах это один из самых распространённых и незаметных compliance-рисков. Пароль в трейсе, email в structured log, номер карты в HTTP-дампе. Всё это копится в Kibana и ждёт своего часа. Moongazing.Veil — библиотека для .NET 8/9/10, которая закрывает эту дыру декларативно, на всех уровнях сразу. Три пакета:

    
        # ядро
dotnet add package Moongazing.Veil             
# HTTP middleware
dotnet add package Moongazing.Veil.AspNetCore  
# structured logs
dotnet add package Moongazing.Veil.Serilog     {}
    

Слой 1. Строки и объекты Авто-обнаружение типа данных: email, телефон, карта, IBAN, JWT, IP, API-ключ и маскировка без конфига:

    
        Veil.Mask("john.doe@gmail.com");   
 // j******e@g****.com
Veil.Mask("5425123456789012");      
// 5425 **** **** 9012
Veil.Mask("Bearer eyJhbGci...");    
// Bearer eyJh***...{}
    

Для DTO атрибут [Veiled]:

    
        public class CustomerDto
{
    public string Name { get; set; }

    [Veiled]
    public string Email { get; set; }

    [Veiled(Show = 4, Position = VeilPosition.Last)]
    public string CardNumber { get; set; }
}

var masked = Veil.MaskObject(original); // original не трогается{}
    

Слой 2. HTTP-трафик:

    
        app.UseVeilRedaction(); // middleware в pipeline

// конфиг:
http.RedactHeaders("Authorization", "X-Api-Key");
http.RedactBodyFields("$.password", "$.creditCard");
http.RedactQueryParams("token", "api_key");{}
    

Данные редактируются до того, как попадают в логи. Слой 3. Serilog без изменений в коде:

    
        Log.Logger = new LoggerConfiguration()
    .Destructure.WithVeil()
    .Enrich.WithVeilRedaction()
    .WriteTo.Console()
    .CreateLogger();{}
    

Все существующие Log.Information("User {@User}", user) начинают маскировать данные автоматически. Ни один вызов переписывать не нужно. ➡️ NuGet 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news