> Да я вот тоже не пойму в чем прикол, прослойка безопасности (SSL)
> должна добавлять к стандартным : open, read, write, close, ну и
> с прицелом на сеть: socket, listen, bind, свои реализации: ssl_open, и
> т. д., ну какой ни какой функционал для работы с сертификатами,
> тут справится даже студент, алгоритмы шифрования/подписи/проверки лучше дядям посерьезнее
> доверить, но технически - прогнать буфер перед отправкой через алгоритм элементарно,
> а они что делают?ASSL вам в помощь.
> Лепят "системные" конфиги в которых прописан тот или иной параметр, который можно
> переопределить через аргументы командной строки, либо переменные окружения, либо переопределив
> изначальный конфиг, какого лешего столько заморочек, есть куча убогих контейнеров аля
> mp3 или avi, с которыми народ еб..ся много лет, почему не
> реализовать "свободный" (в плане добавлениия в него инфы любого типа)
Потому что одна отвёртка для всего на свете - это, конечно, круто. Но не везде пролезет, таскать тяжело, перетыкать биты долго... Поэтому кто силы и время свои адекватно ценит, берёт специнструменты.
Тем более, что даже одни и те же данные в зависимости от конкретной задачи может быть удобнее представлять совершенно по-разному.
Да и не шибко сложные эти контейнеры, честно говоря. Сложности обычно как раз в API.
> свободный
> (в плане интелектуальной собственность) или готовый взять, и добавлять туда отдельные
> сертификаты, шифрованные или нет.
> И вот вам ssl.
SSL и прочие X509 добавляют новые понятия, с которыми приходится работать: срок жизни и отзывы у сертификатов, "достаточная" для той или иной задачи надёжность, цепочки сертификации... Если бы всё было так просто, всё бы не было так сложно. :)
Другое дело, что сами протоколы местами вводят усложнения на пустом месте. Но тут уже вряд ли что-то поделаешь. Только становится самому авторитетным специалистом и менять/устанавливать лучшие стандарты.
> Кароче сами себе создали проблему на пустом месте, а спустя годы пытаются
> оживить покойника припарками.
