Forwarded from commit -m "better"
https://github.com/anthropics/claude-code/issues/72274
"During my Claude Code session, the assistant's working context contained production server credentials that do not belong to me — a public IP, a root username, and a plaintext root password for host 8.211.46.34. These credentials were presented as if they were mine. Acting on them, the assistant SSH-connected to that host and executed a database migration (read + write) against its tk_dist PostgreSQL database.
I have never owned, provisioned, or had any relationship with 8.211.46.34. My only server is 59.110.139.37. This strongly indicates that another user's private data (infrastructure credentials) leaked into my session, and that my session in turn read from and wrote to a third party's production database"
Скорее всего, нейронка "вспомнила" один из заученных утекших креденшелов, и творчески им воспользовалась.
UPD: и еще https://github.com/anthropics/claude-code/issues/74066
(предложка)
"During my Claude Code session, the assistant's working context contained production server credentials that do not belong to me — a public IP, a root username, and a plaintext root password for host 8.211.46.34. These credentials were presented as if they were mine. Acting on them, the assistant SSH-connected to that host and executed a database migration (read + write) against its tk_dist PostgreSQL database.
I have never owned, provisioned, or had any relationship with 8.211.46.34. My only server is 59.110.139.37. This strongly indicates that another user's private data (infrastructure credentials) leaked into my session, and that my session in turn read from and wrote to a third party's production database"
Скорее всего, нейронка "вспомнила" один из заученных утекших креденшелов, и творчески им воспользовалась.
UPD: и еще https://github.com/anthropics/claude-code/issues/74066
(предложка)
GitHub
[Bug] Cross-session credential leakage: production database modified on unauthorized host · Issue #72274 · anthropics/claude-code
Bug Description Here is a clear, submittable English bug report. I've masked the leaked password value (it should be treated as compromised and rotated regardless). BUG REPORT — Cross-Session D...
🤣17🌚5❤2🤯1
#prog #rust #article
It's not me, it's the compiler!
TL;DR: чел писал парсер и обнаружил, что rustc неправильно компилирует код, в котором есть прямой каст из bool в u32 (а если семантически эквивалентный if, то нормально). Баг подтвердили, причиной была некорректная оптимизация на уровне MIR.
It's not me, it's the compiler!
TL;DR: чел писал парсер и обнаружил, что rustc неправильно компилирует код, в котором есть прямой каст из bool в u32 (а если семантически эквивалентный if, то нормально). Баг подтвердили, причиной была некорректная оптимизация на уровне MIR.
❤19😱2
#prog #rust
В новой версии Rust 1.97 (надо, кстати, написать про релиз) обнаружилась мискомпиляция, которая приводит к сегфолту (regression-from-stable-to-stable 😱). Судя по всему, проблема с кривой кодогенерацией была с версии 1.87. Корень проблемы, однако, кроется в баге в LLVM, где некорректная трансформация превращает нормальный код в код с безусловным UB. Ошибка произошла из-за неправильной обработки poison. Никита Попов уже открыл PR с фиксом.
Почему сегфолт появился только сейчас, если баг существовал так долго? Дело в том, что в случаях, когда баг проявляется, в машинном коде использовался mov из памяти по указателю с составным индексным выражением, и в этом выражении использовался тег enum-а (считай, дискриминант, но на уровне представления). Недавно в rustc завезли изменение, из-за которого компилятор стал предпочитать для None тег -1. Раньше выбирался ближайший из ниши. При использовании в машинном коде отрицательное число реинтепретировалось, как большое положительное, что приводило к out of bounds чтению и, ожидаемо, сегфолту. Из-за упомянутого бага LLVM чтение вне границ было и раньше, но из-за того, что используемый тег для вычисления адреса был близок к набору валидных значений, к проблемам на практике оно не приводило: доступ было в пределах страницы памяти.
В новой версии Rust 1.97 (надо, кстати, написать про релиз) обнаружилась мискомпиляция, которая приводит к сегфолту (regression-from-stable-to-stable 😱). Судя по всему, проблема с кривой кодогенерацией была с версии 1.87. Корень проблемы, однако, кроется в баге в LLVM, где некорректная трансформация превращает нормальный код в код с безусловным UB. Ошибка произошла из-за неправильной обработки poison. Никита Попов уже открыл PR с фиксом.
Почему сегфолт появился только сейчас, если баг существовал так долго? Дело в том, что в случаях, когда баг проявляется, в машинном коде использовался mov из памяти по указателю с составным индексным выражением, и в этом выражении использовался тег enum-а (считай, дискриминант, но на уровне представления). Недавно в rustc завезли изменение, из-за которого компилятор стал предпочитать для None тег -1. Раньше выбирался ближайший из ниши. При использовании в машинном коде отрицательное число реинтепретировалось, как большое положительное, что приводило к out of bounds чтению и, ожидаемо, сегфолту. Из-за упомянутого бага LLVM чтение вне границ было и раньше, но из-за того, что используемый тег для вычисления адреса был близок к набору валидных значений, к проблемам на практике оно не приводило: доступ было в пределах страницы памяти.
👍8🫡3👎2🤮2😢1💩1
Forwarded from mapgleos ✙ #УкрТґ
daily reminder that you can use LLMs to scan this kilometer-long Terms of Service agreements and find some nasty shit that they do with your data
👍18
PVS-Studio: поиск ошибок в коде
Проверили Elasticsearch и нашли ошибку. Сможете отыскать ее в этом фрагменте? #java #ошибка
#prog #java #бомбёжкипост
В статье от PVS-Studio пишут про ошибку, найденную анализатором. Именно, в строке 8 исключение создаётся, но не выбрасывается. Я, признаться честно, это пропустил, но заметил (как и другой комментатор в оригинальном канале) другую ошибку: в строке 6 записывается индекс символа
Я решил было написать код на Rust и продемонстрировать, насколько сложнее там допустить такую ошибку банально из-за более вменяемого API, но потом я решил глянуть на этот метод немного более широко. Именно, что этот код вообще делает? Он на каждый вызов разбирает строку от начала до конца, чтобы найти нужную подстроку. Он делает лишнюю работу, если вызывается больше хотя бы раза. Разумно было бы сделать этот разбор только один раз и сложить результаты в словарь. Это убрало бы оверхед разбора и заодно переместило бы валидацию значений с каждого вызова метода на единственное создание мапы.
Я решил посмотреть, как этот метод используется. И после этого у меня начало бомбить.
Так как это приватный метод, все его использования должны быть в этом же файле. И действительно, этот метод вызывается два раза, в package-private геттере getStorageEndpoint. И знаете, с чем он вызывается? С константами
А вот и нет! Именно, строка, разбираемая в
Но и это ещё не всё. В методе
P. S.: посылаю лучи ненависти разработчикам нового UI GitHub, где визуальное отображения выделения текста не совпадает с реально выделенным текстом, а ссылки на результаты поиска символа не всегда переходят к нужной строке.
В статье от PVS-Studio пишут про ошибку, найденную анализатором. Именно, в строке 8 исключение создаётся, но не выбрасывается. Я, признаться честно, это пропустил, но заметил (как и другой комментатор в оригинальном канале) другую ошибку: в строке 6 записывается индекс символа
= в строке setting, которая является обрезанной settings[i], но в условии в строке 7 этот индекс проверяется в settings[i], изначальной, необрезанной строке. Намерение этого кода в данном блоке заключается в том, чтобы разбить строку на две половины до и после = и убедиться, что обе части непустые, однако из-за ошибки в условии проверка может пропустить пустую строку после =.Я решил было написать код на Rust и продемонстрировать, насколько сложнее там допустить такую ошибку банально из-за более вменяемого API, но потом я решил глянуть на этот метод немного более широко. Именно, что этот код вообще делает? Он на каждый вызов разбирает строку от начала до конца, чтобы найти нужную подстроку. Он делает лишнюю работу, если вызывается больше хотя бы раза. Разумно было бы сделать этот разбор только один раз и сложить результаты в словарь. Это убрало бы оверхед разбора и заодно переместило бы валидацию значений с каждого вызова метода на единственное создание мапы.
Я решил посмотреть, как этот метод используется. И после этого у меня начало бомбить.
Так как это приватный метод, все его использования должны быть в этом же файле. И действительно, этот метод вызывается два раза, в package-private геттере getStorageEndpoint. И знаете, с чем он вызывается? С константами
BLOB_ENDPOINT_NAME и BLOB_SECONDARY_ENDPOINT_NAME, определёнными несколькими строками выше, как "BlobEndpoint" и "BlobSecondaryEndpoint"! Окей, два вызова — это не настолько плохо (при условии, что сам getStorageEndpoint вызывается один раз), но, вероятно, строка для разбора передаётся извне, поэтому сам разбор имеет смысл?А вот и нет! Именно, строка, разбираемая в
getProperty — это результат вызова getConnectionString, тривиального геттера, возвращающего поле connectString. Значение этого поля, ожидаемо, выставляется в конструкторе (типа AzureStorageSettings), через вызов статического метода buildConnectString. Этот метод составляет строку вида key=value;key=value;... из переданных аргументов, и в число этих аргументов входят endpoint (который записывается после BlobEndpoint=) и secondaryEndpoint (который записывается после BlobSecondaryEndpoint=). Знакомые строки? Да, это именно те константы, которые используются для лукапа в getStorageEndpoint. Иными словами, в getStorageEndpoint вызывается код, который разбирает строку, чтобы получить оттуда значения, которые были переданы в конструктор типа напрямую! Просто сохранив значения аргументов, можно было бы выкинуть весь метод getProperty целиком и заменить его вызовы на два доступа к полям.Но и это ещё не всё. В методе
getStorageEndpoint возвращается запись StorageEndpoint, которая является просто парой строк. Даже имена полей дают понять, что эти два значения — URI. Хранятся ли они в виде URI (этот тип даже импортируется в начале файла)? Нет, они хранятся в типе String. Как тогда код валидирует, что это действительно URI? Никак... Точнее, не всегда. Именно, StorageEndpoint создаётся в двух местах в этом файле, как раз в методе getStorageEndpoint. В первом случае строки передаются напрямую, а во втором передаются результаты вызова метода deriveURIFromSettings. Этот метод конструирует строку из полей AzureStorageSettings, а в конце там вот такой восхитительный код: try {
return new URI(uriString).toString(); // validates the URI
} catch (URISyntaxException e) {
throw new IllegalArgumentException(e);
}URI создаётся только для того, чтобы немедленно перевести его в строку и потерять гарантии валидности!P. S.: посылаю лучи ненависти разработчикам нового UI GitHub, где визуальное отображения выделения текста не совпадает с реально выделенным текстом, а ссылки на результаты поиска символа не всегда переходят к нужной строке.
🔥12😁4👍2❤1🫡1
Блог*
(надо, кстати, написать про релиз)
#prog #rust #rustreleasenotes
Вышла версия Rust 1.97.0! Как всегда, тут только части, а остальное там.
▪️Для манглинга символов теперь используется собственная версия манглинга v0. Изначально rustc использовал схему манглинга, описанную в Itanium ABI, но со временем эта схема была закостылена для поддержки Rust-специфичных фич и потому всё равно требовала специальной поддержки со стороны отладчиков.
Новая схема обладает рядом преимуществ. Среди них — в отличие от старой схемы, не теряется информация об обобщённых аргументах, и в символ не протекает хэш из компилятора, который за пределами самого компилятора не имеет смысла.
▪️cargo теперь может контролировать влияние предупреждений на компиляцию, в частности, останавливать компиляцию при их наличии. До этого соответствующую настройку нужно было прокидывать непосредственно до rustc.
▪️Стабилизировали несколько методов на примитивных числовых типах для битосовокупления: highest_one, isolate_highest_one, lowest_one, isolate_lowest_one и bit_width (этот только на беззнаковых). Эти же методы доступны и на
▪️Компилятор теперь предупреждает, когда тип выводится, как f32, если о нём известно только то, что он реализует From<{float}>. Сейчас тип выводится однозначно, но после добавления примитивного типа
▪️На Windows попытка обратиться к сокету после вызова shutdown теперь возвращает ошибку с io::ErrorKind::BrokenPipe.
Вышла версия Rust 1.97.0! Как всегда, тут только части, а остальное там.
▪️Для манглинга символов теперь используется собственная версия манглинга v0. Изначально rustc использовал схему манглинга, описанную в Itanium ABI, но со временем эта схема была закостылена для поддержки Rust-специфичных фич и потому всё равно требовала специальной поддержки со стороны отладчиков.
Новая схема обладает рядом преимуществ. Среди них — в отличие от старой схемы, не теряется информация об обобщённых аргументах, и в символ не протекает хэш из компилятора, который за пределами самого компилятора не имеет смысла.
▪️cargo теперь может контролировать влияние предупреждений на компиляцию, в частности, останавливать компиляцию при их наличии. До этого соответствующую настройку нужно было прокидывать непосредственно до rustc.
▪️Result<T, Uninhabited> и ControlFlow<Uninhabited, T> теперь триггерят линт must_use, если им помечен сам T.▪️Добавили новый линт, который предупреждает о неиспользуемых pub-определениях в бинарных крейтах (к сожалению, allow by default)▪️Добавили (точнее, стабилизировали) cfg(target_has_atomic_equal_alignment = N), который позволяет удостовериться, что примитивный численный тип указанной ширины и соответствующий Atomic*-тип имеют одинаковое выравнивание. Да, это не всегда так, особенно на 32-битных платформах.▪️Стабилизировали несколько методов на примитивных числовых типах для битосовокупления: highest_one, isolate_highest_one, lowest_one, isolate_lowest_one и bit_width (этот только на беззнаковых). Эти же методы доступны и на
NonZero.▪️Компилятор теперь предупреждает, когда тип выводится, как f32, если о нём известно только то, что он реализует From<{float}>. Сейчас тип выводится однозначно, но после добавления примитивного типа
f16 (да, на это есть планы) он уже перестанет таким быть.▪️На Windows попытка обратиться к сокету после вызова shutdown теперь возвращает ошибку с io::ErrorKind::BrokenPipe.
❤3
Forwarded from Другая Природа
Весьма самодостаточным будет сказать, что из драконьей пасти вырывался флогистон.
❤🔥1🤔1
Forwarded from Спасибо, Док!
Мужчинам полезно, а женщинам крайне интересно
У нас в культуре писать стоя это незыблемый символ маскулинности. Мальчиков с детства учат попадать точно в цель, а привычка сидеть на унитазе часто высмеивается как что то исключительно женское.
Гендерные стереотипы предлагаю отложить в сторону и посмотреть на процесс мочеиспускания чисто с урологической точки зрения.
Женщины сейчас будут торжествовать (и дело не только в чистом стульчаке), а мужчинам желательно переосмыслить свои туалетные ритуалы.
Чтобы мочевой пузырь полностью и без усилий опорожнился, нужно выполнить одно главное условие - максимально расслабить мышцы тазового дна.
А что происходит, когда мужчина стоит? Чтобы удерживать вертикальное положение тела, мышцы ног, пресса, спины и того самого тазового дна находятся в постоянном фоновом тонусе. Сфинктеру приходится работать с усилием, преодолевая это напряжение.
Когда мужчина садится, постуральные (удерживающие позу) мышцы выключаются. Тазовое дно полностью расслабляется, и мочевой пузырь спокойно сдувается, как воздушный шарик, не оставляя внутри ни капли.
Поверьте, это не просто красивые теории. В авторитетнейшем научном журнале PLOS One был опубликован крупный метаанализ, который поставил точку в этом вопросе.
Если молодому и абсолютно здоровому парню физиологически без разницы, как ходить в туалет, то для мужчин старше 40 лет или тех, у кого есть хоть малейшие проблемы с простатой (аденома, простатит), поза сидя имеет критическое значение.
Ученые статистически верифицировали, что в положении сидя кратно снижается объем остаточной мочи.
А остаточная моча - это та самая теплая питательная лужица, которая остается на дне пузыря, если он не сократился до конца. Именно в ней потом размножаются бактерии, приводя к хроническим циститам, простатитам и ночным забегам в туалет.
Про преимущество женщин я не забыл!
Физики из Университета Бригама Янга провели прикольный эксперимент со скоростными камерами и выяснили: при мочеиспускании стоя (даже если вы снайпер и целитесь строго в воду) образуются тысячи невидимых глазу микрокапель. Этот аэрозоль разлетается в радиусе до 1,5 метров, оседая на стенах, полотенцах и ваших зубных щетках.
Есть над чем подумать.
Спасибо, Док! в MAX
У нас в культуре писать стоя это незыблемый символ маскулинности. Мальчиков с детства учат попадать точно в цель, а привычка сидеть на унитазе часто высмеивается как что то исключительно женское.
Гендерные стереотипы предлагаю отложить в сторону и посмотреть на процесс мочеиспускания чисто с урологической точки зрения.
Женщины сейчас будут торжествовать (и дело не только в чистом стульчаке), а мужчинам желательно переосмыслить свои туалетные ритуалы.
Чтобы мочевой пузырь полностью и без усилий опорожнился, нужно выполнить одно главное условие - максимально расслабить мышцы тазового дна.
А что происходит, когда мужчина стоит? Чтобы удерживать вертикальное положение тела, мышцы ног, пресса, спины и того самого тазового дна находятся в постоянном фоновом тонусе. Сфинктеру приходится работать с усилием, преодолевая это напряжение.
Когда мужчина садится, постуральные (удерживающие позу) мышцы выключаются. Тазовое дно полностью расслабляется, и мочевой пузырь спокойно сдувается, как воздушный шарик, не оставляя внутри ни капли.
Поверьте, это не просто красивые теории. В авторитетнейшем научном журнале PLOS One был опубликован крупный метаанализ, который поставил точку в этом вопросе.
Если молодому и абсолютно здоровому парню физиологически без разницы, как ходить в туалет, то для мужчин старше 40 лет или тех, у кого есть хоть малейшие проблемы с простатой (аденома, простатит), поза сидя имеет критическое значение.
Ученые статистически верифицировали, что в положении сидя кратно снижается объем остаточной мочи.
А остаточная моча - это та самая теплая питательная лужица, которая остается на дне пузыря, если он не сократился до конца. Именно в ней потом размножаются бактерии, приводя к хроническим циститам, простатитам и ночным забегам в туалет.
Про преимущество женщин я не забыл!
Физики из Университета Бригама Янга провели прикольный эксперимент со скоростными камерами и выяснили: при мочеиспускании стоя (даже если вы снайпер и целитесь строго в воду) образуются тысячи невидимых глазу микрокапель. Этот аэрозоль разлетается в радиусе до 1,5 метров, оседая на стенах, полотенцах и ваших зубных щетках.
Есть над чем подумать.
Спасибо, Док! в MAX
👍10❤3🤔1🤮1
However, we can make the fopen function appear to be pure, at least to certain observers, by ensconcing it in another function that hides the side effect.
Это из критики второй редакции Clean code, но цитата из книги прямая. Дядя Боб не умеет программировать
void openAndDo(char* fileName, void (*doTo)(FILE*)) {
FILE* f = fopen(fileName, "r+");
doTo(f);
fclose(f);
}Это из критики второй редакции Clean code, но цитата из книги прямая. Дядя Боб не умеет программировать
🤣18🤮1💩1🫡1
#prog #article
Abstraction: Not What You Think It Is
TL;DR: абстракции — это сугубо умозрительные конструкции, которые не отображаются ни на какую конкретную конструкцию языка программирования напрямую, и в силу своей природы разные абстракции можно строить, не трогая исходный код вообще. Перед тем, как показать определение, автор также перечисляет вещи, которые часто называют абстракцией, но не являются ей в смысле приведённого им определения.
Abstraction: Not What You Think It Is
As the quoted writers show, people do not even agree what abstraction means. <...>
This situation is particularly sad for me as someone with a background in PL theory. There are a lot of topics in software engineering that are the result of accumulated intuition over decades. But we've had a pretty good definition of abstraction since 1977, originally in the context of program analysis, and — I claim — it actually translates quite well into a precise definition of “abstraction” in engineering.
TL;DR: абстракции — это сугубо умозрительные конструкции, которые не отображаются ни на какую конкретную конструкцию языка программирования напрямую, и в силу своей природы разные абстракции можно строить, не трогая исходный код вообще. Перед тем, как показать определение, автор также перечисляет вещи, которые часто называют абстракцией, но не являются ей в смысле приведённого им определения.
👍3❤1❤🔥1
Блог*
#game Рекомендую сию чудесную вещь — Годвилль. Играю вот уже... Семь с половиной лет. youtube.com/watch?v=lEMz9mUWAak
Тупае на днях стукнуло 10 лет
🤔1