1.85K subscribers
3.26K photos
130 videos
15 files
3.54K links
Блог со звёздочкой.

Много репостов, немножко программирования.

Небольшое прикольное комьюнити: @decltype_chat_ptr_t
Автор: @insert_reference_here
Download Telegram
LinkedIn - это Tinder наоборот.

Девушки пишут задротам, а те им не отвечают

😂
😁35
Swolemates out of context
👍2
💯33😁11
Какая ещё, к чёрту, лента в приложении для заказа такси?
😁28🤯4💯2
#meme, который вам нравится?..
14😭10💔8😁5
#game #tips: негативные отзывы в Steam зачастую гораздо информативнее положительных
👍2💯2
#itsec #suckassstory

(кажется, первое обычно подразумевает второе)
Опубликован релиз утилиты для синхронизации файлов Rsync 3.4.0, в котором устранено шесть уязвимостей. Комбинация уязвимостей CVE-2024-12084 и CVE-2024-12085 позволяет клиенту добиться выполнения своего кода на сервере. Для совершения атаки достаточно анонимного подключения к серверу Rsync с доступом на чтение. Например, атака может быть совершена на зеркала различных дистрибутивов и проектов, предоставляющих возможность загрузки сборок через Rsync. Проблема также затрагивает различные приложения для синхронизации файлов и резервного копирования, использующие Rsync в качестве бэкенда, такие как BackupPC, DeltaCopy и ChronoSync.
. . .
Для упрощения проверки обновления серверов до новой версии Rsync номер протокола в выпуске Rsync 3.4.0 повышен до 32.
. . .
CVE-2024-12084 - запись за пределы выделенного буфера через передачу некорректной контрольной суммы, размер которой превышает 16 байт.
CVE-2024-12085 - утечка содержимого неинициализированных данных из стека (по одному байту за раз) при выполнении операций сравнения контрольных сумм некорректного размера.

В Rsync 3.4.0 устранены уязвимости, позволявшие выполнить код на сервере и клиенте
https://www.opennet.ru/opennews/art.shtml?num=62557

Rsync contains six vulnerabilities
https://kb.cert.org/vuls/id/952657

ЗЫ Ссылка на твит со скрина
https://x.com/KirillKorinsky/status/1879265433658020062
🥴11👍3🤯1
🤡14💯4
Forwarded from Хреногубка
Все так жалуются на «повесточку» в играх. Не нравятся им, видите ли, персонажи и сюжет 🥱

А вот раньше люди играли за фурри, у которого была гиперфиксация на яйцах. И ведь не жаловались!

Вот вам пруф.
🌚20💯11🤡5🤷1
#meme про трудовые будни
😁9💯9😭31🤨1
Технологический Болт Генона
Rust and Go are both awesome
🔫
Please open Telegram to view this post
VIEW IN TELEGRAM
😁11🤡5🍌1🤝1
#prog #rust хайлайты.

TL;DR: тык.

Среди многих хороших вещей, которые есть в Rust — указание версии, начиная с которой определение стабильно. Главным образом это относится к API в стандартной библиотеке, но эта информация также хранится и для фич компилятора — это позволяет компилятору указывать на то, что #![feature(...)] уже стабилизирована и потому не требует аннотаций в коде.

Долгое время эта версия указывалась вручную. Это обычно не так сложно — новое определение попадает в stable-версию, которая на три версии старше текущей. Однако PR в Rust имеют свойство затягиваться — особенно для больших и сложных фич типа non-lexical lifetimes — и потому эти атрибуты требовалось периодически обновлять. Так как это не очень интересная работа, а упустить эти атрибуты при работе очень легко, часто в master эти указания на стабильную версию попадали неверными, из-за чего их приходилось править задним числом после мерджа (например).

Для того, чтобы избежать подобных происшествий, в конце августа 2022 года est31 добавил поддержку заменителя версии. Именно, все новые стабильные фичи должны теперь вместо конкретной версии использовать строку "CURRENT_RUSTC_VERSION", и tidy (линтер компилятора) в CI проверяет, что это действительно так. Для того, чтобы менять версию на актуальную, этот же PR добавил для этого автоматический инструмент — replace-version-placeholder — который запускается каждый раз, когда отпочковывается новая бета-версия. Это очень тупой инструмент, который использует простую текстовую замену (буквально str::replace)

Однако определение этого шаблона нужно иметь и в сорцах компилятора — для того, чтобы корректно распознавать определения с указанием этой строки в качестве стабильной версии и давать связанные с версиями диагностики. По понятным причинам это определение используется в коде компилятора, ответственного за парсинг атрибутов. Чтобы избежать перезаписывания определения шаблона, в replace-version-placeholder был захардкожен путь до файла, отвечающего за эту часть компилятора. Однако структура компилятора не является отлитой в граните, и периодически файлы перемещают или переименовывают. Иногда меняется путь и до файла, содержащего определение шаблона, из-за чего инструмент для замены версий начинает заменять то, что не надо, и его надо править, чтобы поменять путь, который исключается из обработки.

Чтобы исключить подобную чехарду, Pietro Albini придумал гениальный ход с заменой определения шаблона в коде. Вот как определение VERSION_PLACEHOLDER выглядело до его PR:

pub const VERSION_PLACEHOLDER: &str = "CURRENT_RUSTC_VERSION";


А вот как оно же выглядит после:

pub const VERSION_PLACEHOLDER: &str = concat!("CURRENT_RUSTC_VERSIO", "N");


Несмотря на то, что определение де-факто осталось тем же, исходники теперь не содержат строку CURRENT_RUSTC_VERSION, а потому replace-version-placeholder файл не меняет. Это изменение позволило не только свободно перемещать исходники, но и убрать фильтрацию по имени файла из инструмента. Естественно, Pietro написал в комментариях, зачем это надо.

Но всё равно смешно.
😁20👍2😱1
Блог*
периодически файлы перемещают или переименовывают
Кто скажет, что это одно и то же — буду бить руководством по UX по голове
🌚4🤡2
#prog #amazingopensource

Josh — Just One Single History

README:

Combine the advantages of a monorepo with those of multirepo setups by leveraging a fast, incremental, and reversible implementation of git history filtering.

Из руководства пользователя:

The idea behind josh started with two questions:

1. What if history filtering could be so fast that it can be part of a normal, everyday workflow, running on every single push and fetch without the user even noticing?
2. What if history filtering was a non-destructive, reversible operation?


Что позволяет сделать этот инструмент? Например, склонировать отдельную директорию из репозитория, как отдельный репозиторий, который содержит только коммиты, связанные с этой директорией и её содержимым (первый пример в README). Причём директория может быть произвольной, а не из какого-то заданного заранее списка. josh даже позволяет сделать репозиторий из директории, которая в репозитории пока отсутствует!

Подобный склонированный под-репозиторий ведёт себя так же, как обычный git-репозиторий, и поддерживает тот же набор операций. В частности, новые коммиты будут видны в его истории, но при этом будут прозрачно интегрированы в историю исходного репозитория.

Josh также поддерживает более продвинутую функциональность для переобозначения директорий, когда, например, каждый подпроект содержится в отдельной директории, но при этом требует файлы из некой общей директории (второй пример в README).

Бонусом josh также даёт возможность делать запросы по содержимому репозитория через GraphQL API без необходимости клонирования репозитория целиком. Даже если вы не собираетесь использовать трюки с переписыванием истории, одно это уже может быть полезно.

Узнал про этот инструмент из этого PR в репу Rust, который преобразовал rustc-dev-guide из сабмодуля в директорию в составе основной репы с использованием josh.
🤯4👍3
Forwarded from Хреногубка
Практически в каждой мужской руке, которую ты жал, когда-то был член. Спустя время Хреногубка вернется к вам с новыми фактами.
🤝18👌3😁2👎1