Критическая уязвимость в libgcrypt 1.9.0

И что сие означает?)

он тебе не про это сказал

Он про это. Про то, что инкапсуляция хуже.

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

Вовсе не сложнее. Этот код находится в классе и прятат нам нужно не столько этот код, сколько внутренние поля класса.

Расскажи, как проще и понятнее это делается в чистом C.

Этот код находится в классе и прятат нам нужно не столько этот код, сколько внутренние поля класса.

В ООП инкапсуляция - это не про «спрятать данные и код». Инкапсуляция в ООП - это про объединение/группировка данных и кода в один, так сказать, модуль. Скрытие данных - это «расширение» некоторых языков программирования и к ООП это не относится.

Скрытие данных и кода - это про модульное программирование.

Про то, что инкапсуляция хуже.

Ну, про что он там – давай у него спросим, а не будем гадать что нам там показалось

Вовсе не сложнее

дискуссионный вопрос

Этот код находится в классе и прятат нам нужно не столько этот код, сколько внутренние поля класса.

во-первых, ты немного подменил предмет разговора, ты говорил что код копирования буфера для этого hd можно было бы отдельно написать, я отметил, что ничего не мешает написать отдельно функцией, мол, можно и без классов

теперь ты говоришь про приватные поля – тоже мне проблема, например, статические переменные в отдельном файле

вообще, я не вижу особой проблемы организовать именно срогую защиту приватных полей, так, чтобы у программиста не было прям физической возможности доступа. Но программист – он же не ребенок малолетний, ты пиши как тебе кажется правильным – получится так, как тебе кажется правильным. Собственно, у меня ведь есть физическая возможность сейчас пойти на кухню и вонзить себе нож в глаз, я этого не делаю, потому что я разумный человек или потому что у меня нет физической возможности это сделать?

Скрытие данных и кода - это про модульное программирование.

два чая этому анонимусу. Нет никаких проблем так писать и на си. Фишка объектов – в наследовании. Ну… дело вкуса. Но как это приплести к сабжу – загадка

Фишка объектов – в наследовании.

Сомнительная фишка, которая портит современное ООП. Основная фишка объектов - это интерфейс. А наследование и полиморфизм на наследовании - это сомнительные фишки, вокруг которых до сих пор возникают священные войны.

вроде 4 звезды а не знаешь!?

сокращение «два чая этому господину», очевидно жЫ )))

PS: пардон, +1 каким-то волшебным глюком превратился в нечто непонятное мне самому 8-[ ]

как ооп поможет против дебила, который гадит в переменные? хеш 32 байта но напишу-ка я в длину 40 потому что «мы здесь власть».

Ржу в голос. :)))) В закладки. :)

В ООП инкапсуляция - это не про «спрятать данные и код». Инкапсуляция в ООП - это про объединение/группировка данных и кода в один, так сказать, модуль.

Ну да, внутренние данные и код доступа к ним находятся внутри класса.

Скрытие данных - это «расширение» некоторых языков программирования и к ООП это не относится.

В ООП объект характеризуется поведением и состоянием. Состояние - это внутренние данные, которые нужно менять только поведением, то есть никакого прямого доступа извне - скрытие данных.

Скрытие данных и кода - это про модульное программирование.

Модульное программирование - совсем необязательно про скрытие. В свою очередь инкапсуляция - не единственное свойство ООП и его можно рассматривать как нечто, реализующее модульность.

во-первых, ты немного подменил предмет разговора, ты говорил что код копирования буфера для этого hd можно было бы отдельно написать, я отметил, что ничего не мешает написать отдельно функцией, мол, можно и без классов

Я говорил про инкапсуляцию и ничего не подменял. И я не говорил, что: «код копирования буфера для этого hd можно было бы отдельно написать». Инкапсуляция подразумевает, что этот код находится внутри класса, вмести со скрытыми от прямого внешнего доступа данными.

вообще, я не вижу особой проблемы организовать именно срогую защиту приватных полей, так, чтобы у программиста не было прям физической возможности доступа. Но программист – он же не ребенок малолетний, ты пиши как тебе кажется правильным – получится так, как тебе кажется правильным. Собственно, у меня ведь есть физическая возможность сейчас пойти на кухню и вонзить себе нож в глаз, я этого не делаю, потому что я разумный человек или потому что у меня нет физической возможности это сделать?

Да, в Java можно обойти ограничения инкапсуляции при помощи рефлексии, но для этого придётся писать много дополнительного кода. Инкапсуляция - это не про физическую защиту, а про логическую.

Да, не все вообще понимают принципы ООП, отсюда и подобные заявления про «хеш 32 байта но напишу-ка я в длину 40». Нормальная инкапсуляция как раз и призвана не допускать этого.

Состояние - это внутренние данные

Состояние - это состояние, это не скрытые внутренние данные.

И начал плавать с одного берега на другой - с одного представления ООП [инкапсуляция, наследование, полиморфизм] к другому [объекты и поведение]. Это - разные представления о разном (как бы) ООП. Они не взиамозаменяемые и не надо термины одного применять в отношении другого.

никому не удастся использовать в виду случайного характера нарушений.

Кому надо - уже поиспользовали и потом скинули в паблик… какие все наивные….

Инкапсуляция не есть плохо, но инкапсуляция никак не помешает тебе ошибиться с размером буфера, что в сишной функции, что в

своей собственной реализацией копирования буфера и соответствующими проверками выхода за его границы

Как же не помешает? Если у меня внутри класса поле расчитано на 32 байта и в сетере я проверяю, что извне меня просят скопировать именно 32 байта, то вероятность ошибки конечно есть, он она стремится к нулю.

Состояние - это состояние, это не скрытые внутренние данные.

Состояние - это именно данные (поля класса) и по-хорошему они должны быть скрыты, то есть инкапсулированы.

И начал плавать с одного берега на другой - с одного представления ООП [инкапсуляция, наследование, полиморфизм] к другому [объекты и поведение]. Это - разные представления о разном (как бы) ООП. Они не взиамозаменяемые и не надо термины одного применять в отношении другого.

Я и не говорил, что поведение и состояние взаимозаменяемы инкапсуляции, наследованию и полиморфизму. Поведение и состояние - это всего лишь то, что характеризует любой объект в ООП. А инкапсуляция, наследование, полиморфизм - это список методологий ООП.

А если ты ошибёшься и будешь проверять 40? А если у тебя 100500 видов разных хэш-функций, и у каждой свой размер? Будешь на каждую наследовать класс и пилить уникальные геттеры-сеттеры? Вместо одного параметра в функции копирования? А потом цепепе программы раздуваются и компилируются по 100 часов, и никто в них ковыряться не хочет

А если ты ошибёшься и будешь проверять 40?

Маловероятно. Гораздо вероятнее, что ты в своём чистом C коде ошибёшься.

А если у тебя 100500 видов разных хэш-функций, и у каждой свой размер? Будешь на каждую наследовать класс и пилить уникальные геттеры-сеттеры?

Хеш алгоритмов не так уж много, чтобы про них 100500 говорить и да, по-хорошему, для каждого такого хеша должен быть отдельный объект и, кстати, совсем необязательно новый класс. Можешь использовать ровно один универсальный класс хешей и завести фактори метод, который получает параметром тип хеша и возвращает соответствующий экземпляр того единственного класса с уже инициализированным размером и всем остальным.

Вместо одного параметра в функции копирования?

И потом ты этот параметр должен будешь передавать из 100500 мест, что с достаточно большой долей вероятности приведёт к ошибке. Я уже не говорю о такой нехорошей вещи как magic number.

А потом цепепе программы раздуваются и компилируются по 100 часов, и никто в них ковыряться не хочет

Оно совсем по другим причинам так долго компилируется. Простое наследование этому совсем не причина. Вон в Java этой проблемы нет.

Сомнительная фишка

И я о том же

Основная фишка объектов - это интерфейс

А чем интерфейс объекта (плюсового) отличается от классического хидера с объявленными переменными и прототипами функций, для работы с данным «объектом»? Переопределением операторов?

вроде 4 звезды а не знаешь!?

Когда у меня не было звезд, я на ЛОРе встретил непонятную мне аббревиатуру «ЛГБТ», спросил что это, мне ответили, теперь я знаю. ЛОР образовательный :)

очевидно жЫ

да, вроде, из контекста понятно, но я решил спросить на всякий

пардон

пфф, фил, так сказать, фри!

И я не говорил, что: «код копирования буфера для этого hd можно было бы отдельно написать»

«Почему этот hd не является объектом со своей собственной реализацией копирования буфера и соответствующими проверками выхода за его границы?»

а, по-моему, говорил

Инкапсуляция подразумевает, что этот код находится внутри класса, вмести со скрытыми от прямого внешнего доступа данными.

Да че ты заладил? Ты реально думаешь что здесь кто-то не знает что такое инкапсуляция? Тебе про другое толдычат, а именно: что твоя хваленая инкапсуляция – суть подход к программированию, а не особенность ООП вообще и плюсов в частности. Соответственно, твои слезы по поводу того почему это не переписали на плюсах и нормально не заинкапсулировали в класс, как тебе кажется (или мне кажется, что тебе кажется?) единственно-верным, проливаешь ты зря. Во-первых, написание этого на плюсах не гарантирует ничего, во-вторых, ничего, так же, не мешает написать это так и на си. Теперь понял?

Инкапсуляция - это не про физическую защиту, а про логическую.

Тогда хоть заинкапсулируйся на любом языке безо всякого ООП.

WindowsXP ★★

Кажись, икспуха вчера с одной звездой была!!! :)

Если у меня внутри класса поле расчитано на 32 байта и в сетере я проверяю, что извне меня просят скопировать именно 32 байта, то вероятность ошибки конечно есть, он она стремится к нулю.

божечки, а если у меня в структуре поле на 32 и я в сеттере проверю? Разница-то в чем? Может в твоем объекте проверки автоматом? Нет. А если руками писать надо, и там и там, то может дело в том написана проверка или нет, а не в том – объект это или нет?

И я не говорил, что: «код копирования буфера для этого hd можно было бы отдельно написать»

«Почему этот hd не является объектом со своей собственной реализацией копирования буфера и соответствующими проверками выхода за его границы?»

а, по-моему, говорил

Ну так в ООП это совсем не отдельно, а как раз внутри класса.

Да че ты заладил? Ты реально думаешь что здесь кто-то не знает что такое инкапсуляция? Тебе про другое толдычат, а именно: что твоя хваленая инкапсуляция – суть подход к программированию, а не особенность ООП вообще и плюсов в частности. Соответственно, твои слезы по поводу того почему это не переписали на плюсах и нормально не заинкапсулировали в класс, как тебе кажется (или мне кажется, что тебе кажется?) единственно-верным, проливаешь ты зря. Во-первых, написание этого на плюсах не гарантирует ничего, во-вторых, ничего, так же, не мешает написать это так и на си. Теперь понял?

Как ты в чистом C запретишь прямой доступ к полю в структуре? Какая же это инкапсуляция? Это не более чем самодисциплина, которая, как мы видим на примерах подобных уязвимостей, которых много, вовсе не спасает.

Тогда хоть заинкапсулируйся на любом языке безо всякого ООП.

Без модификаторов доступа такая инкапсуляция невозможна. Я могу согласиться с тем, что в каких-то языках программирования (Rust?) модификаторы доступа могут существовать и без ООП, но в чистом C этих модификаторов просто нет.

и никто в них ковыряться не хочет

… по полу валяется – никто его не ест! )

божечки, а если у меня в структуре поле на 32 и я в сеттере проверю? Разница-то в чем?

В отсутствии разграничения доступа. К твоему полю в структуре могут продолжать обращаться напрямую, минуя сетер.

А если ты ошибёшься и будешь проверять 40?

Маловероятно. Гораздо вероятнее, что ты в своём чистом C коде ошибёшься.

Атас.

Ты и там и там пишешь руками, почему вероятность ошибки разная? Святой дух Страуструпа тебя бережет?

«Когда у тебя в руках молоток – любая проблема кажется гвоздем» – это про горячих ньюфагов плюсов. Ты пойми нас правильно, все были молодыми и горячими сторонниками чего-нибудь-там. И с пеной у рта доказывали окружающим силу вновь обретенного знания. Но будь мудр: не пытайся объяснить нам принципы ООП, лучше воспользуйся опытом и знаниями сообщества, это единственное что есть ценного на ЛОРе, возможность спросить совета и расширить тем самым свой кругозор или избежать граблей, на которые кто-то уже наступал.

Согласись, неразумно с твоей стороны пытаться обучить людей старше и опытнее тебя, рассказав им про инкапсуляцию, про которую они без тебя, сто пудов, не слышали.

Мы тебя как раз и пытаемся уберечь от граблей по которым уже многие ходили, а именно «ООП головного мозга», никто не спорит ООП и/или плюсы, штука клевая, но не ответ на вопрос о смысле жизни вселенной и всего такого.

Ты и там и там пишешь руками, почему вероятность ошибки разная? Святой дух Страуструпа тебя бережет?

Потому что реализация этой проверки находится в одном месте (классе) с буфером, а максимальный размер буфера будет задаваться во время создания или инициализации объекта.

Мы тебя как раз и пытаемся уберечь от граблей по которым уже многие ходили, а именно «ООП головного мозга», никто не спорит ООП и/или плюсы, штука клевая, но не ответ на вопрос о смысле жизни вселенной и всего такого.

«ООП головного мозга» - это когда он используется бездумно.

Ну так в ООП это совсем не отдельно, а как раз внутри класса.

Я не про то отдельно. Ты или реально не понимаешь, или троллишь умело, издеваясь над уставшим человеком )

Как ты в чистом C запретишь прямой доступ к полю в структуре?

структуру – в отдельный файл, объявляешь статиком. Пишешь функцию гет_поле_структуры и сет_поле_структуры. Тадам: готово. Из основной программы функции сеттеры и геттеры доступны, а сама структура, включая все поля – нет

Какая же это инкапсуляция?

да такая же как и в плюсах, только писанины меньше (гугли анекдот про льва, зайца и писанины добавилось)

Это не более чем самодисциплина

ошибаешься, гугли статики в си

но в чистом C этих модификаторов просто нет

а если найду? )

В отсутствии разграничения доступа. К твоему полю в структуре могут продолжать обращаться напрямую, минуя сетер.

Можно разграничить. Сколько раз мне еще сказать?

Потому что реализация этой проверки находится в одном месте (классе) с буфером, а максимальный размер буфера будет задаваться во время создания или инициализации объекта.

А кто тебе не дает на си в одном месте писать? )

Короче, чую, бесполезно

«ООП головного мозга» - это когда он используется бездумно.

ООП головного мозга, это когда «ООП круче, потому что ООП!» и хоть кол на голове теши, все равно ООП круче потому что инкапсуляция

структуру – в отдельный файл, объявляешь статиком. Пишешь функцию гет_поле_структуры и сет_поле_структуры. Тадам: готово. Из основной программы функции сеттеры и геттеры доступны, а сама структура, включая все поля – нет

И зачем мне нужна такая статическая структура, которая целиком недоступна? Как мне сделать несколько экземпляров этой структуры? На каждый экземпляр заводить отдельный compilation unit? Как мне сделать эти экземпляры динамически создаваемыми?

Ты бы не пыхтел, а лучше привёл бы пример кода на C с разграничением доступа к полям структуры. Для простоты пусть это будет структура user с полем char name[10]. Таких юзеров у меня 100500 штук и одного из них зовут Constantine. На Константине должна сработать защита от выхода за пределы массива.

Mон шер ами, чтобы решить проблемы плюсанутых погромистов придумали жабу.

Да, не все вообще понимают принципы ООП

Согласен. Ты, например, не понимаешь. :)

«хеш 32 байта но напишу-ка я в длину 40». Нормальная инкапсуляция как раз и призвана не допускать этого.

Бред собачий. Инкапсуляция тут поможет разве что упрощением тестирования и отладки этого бага. При условии, что его вообще увидели.

Бред собачий.

Не знал о твоей родословной.

Инкапсуляция тут поможет разве что упрощением тестирования и отладки этого бага. При условии, что его вообще увидели.

Инкапсуляция - это методология, позволяющая писать более безопасный код. Если ты бездумно нагенерировал сетеров, без какой-то логики или смысла, это вовсе не значит, что ты используешь инкапсуляцию. В таком случае ты просто генерируешь год, как обезьяна. Не задумываясь о том, что ты делаешь.

И зачем мне нужна такая статическая структура, которая целиком недоступна?

Ты две страницы надрываешься об контроле доступа. Теперь мне тебе объяснять зачем это надо? Целиком недоступна, а через функции установки-чтения доступна.

Как мне сделать несколько экземпляров этой структуры?

Так же как и несколько экземпляров любой другой структуры или объекта.

На каждый экземпляр заводить отдельный compilation unit?

нет

Как мне сделать эти экземпляры динамически создаваемыми?

так же, как и любую другую переменную

Серьезно, ты либо тупой, либо совсем в жир скатился. В обоих случаях никто с тобой общаться не захочет.

Ты бы не пыхтел, а лучше привёл бы пример кода на C

Я бы привел, без проблем, но уже думаю что в толк не пойдет. Я такой постараюсь, напишу, а ты мне объяснишь на этом примере что я – дурак, коза моя – дура и муж мой дурак, хоть и помер. Это вместо того чтоб попытаться выслушать и разобраться.

Хочешь общаться и опыта и знаний сообщества набираться – велкам. а вот это вот «Ты бы не пыхтел» оставь своим ровесникам, которые продолжают с тобой общаться не смотря на хамскую риторику.

Без модификаторов доступа такая инкапсуляция невозможна. Я могу согласиться с тем, что в каких-то языках программирования (Rust?) модификаторы доступа могут существовать и без ООП

В любом языке с полноценными замыканиями это возможно и без всякого ООП. Rust и современный C++ такими языками являются.

это был SP2 ))

Я так и думал, что ты сольёшь. Простой пример кода был бы куда полезнее всего того бесполезного, что ты написал.

я на ЛОРе встретил непонятную мне аббревиатуру «ЛГБТ»

Геологи нашли мальчика, воспитанного дятлами (с).

когда кажется - надо перекреститься

А если ты ошибёшься и будешь проверять 40? А если у тебя 100500 видов разных хэш-функций, и у каждой свой размер? Будешь на каждую наследовать класс и пилить уникальные геттеры-сеттеры?

В современном С++ (и rust с D тоже) будет одна шаблонная функция или структура (не класс, логически тут ООП не нужно просто) и все размеры будут контролироваться в compile time. И это на самом деле в отличии от ООП подхода повысит надежность, а часто и быстродействие кода.