Что значит закрытый код программы

В мире существует много программ. И классифицировать их можно по разным признакам. Один из них — открытость исходного кода.

Программы бывают с открытым и закрытым исходным кодом.

Открытый исходный код — это своего рода открытый «текст» программы. И этот «текст» каждый может изучить. Можно самому убедиться, что в исходном коде программы нет никаких вирусов или уязвимостей. Разработчик программы выкладывает этот код в свободный доступ.

Закрытый исходный код — это тот же «текст» программы, но хранящийся разработчиками втайне. Это их собственность, их изобретение, их технологии которые они не хотят никому показывать. И не имея этого кода, соответственно изучить его не представляется возможным. Насколько же можно доверять программам с открытым исходным кодом?

Довольно часто я слышу фразу — программы с открытым исходным кодом более безопасны, чем с закрытым. Такие люди часто ставят знак равенства между открытостью кода и безопасностью программы. Ниже я напишу аргументы сторонников открытого ПО и мои комментарии и пояснения.

Открытый и закрытый исходный код. Ошибки и ситуативные баги.

Программы с открытым кодом безопаснее. Ведь этот код я могу изучить и лично убедится в его безошибочности и надежности.

Тут обычно я задаю вопрос — а вы сами его изучали? Вот вы хвалите программу с открытым кодом, а код вы изучали? Ответ обычно нет. Но далее следует другой аргумент.

Так как код доступен всем, то этот код уже изучили тысячи человек.

То есть вы его не изучали. Но кто-то изучал? Возможно. Вы ему доверяете? А у этого неизвестного человека есть навыки или образование для качественной оценки кода?

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

• он общедоступен и открыт. Это значит, что злоумышленник может легко его изучить и найти в нем уязвимости. С закрытым кодом ему понадобится декомпилировать программу, решить проблему обфускации и провести дальнейший анализ проприетарного ПО.
• нет гарантий. Обычно все программы с открытым кодом бесплатны. И разработчик ни несет никакой ответственности ни за код, ни за программу.
• из этого кода каждый может «собрать» свою программу. И неопытный программист, который сделает программу с глюками и багами и хитрый хакер который внедрит туда вирус. Да, часто рабочая версия программы собранная из кода находится «рядом» с этим кодом. Но все же распространение самых разных версий открытого и бесплатного ПО с вирусами внутри имеет место быть.
• источник кода и программ часто — GitHub . И это нормально и так принято. Но неопытный разработчик может выложить нестабильный релиз или исходный код с серьезными ошибками. Да даже опытные разработчики иногда этим грешат.

Вывод — программам с открытым исходным кодом следует доверять также как к программам с закрытым исходным кодом. Открытый исходный код — это не преимущество программы, а её особенность.

Что такое открытый исходный код и как он работает?

Если вы всё таки поняли, о чем я писал в этой статье, то поставьте лайк. А можно ещё и подписаться на мой канал, ведь тут действительно много уникального контента. Ну и если вы являетесь сторонником open source, то напишите об этом в комментарии ниже. Возможно, я что то упустил и вы нам об этом расскажете.

Источник: dzen.ru

Что значит закрытый код программы

Нет аккаунта? Зарегистрироваться

Руслан Петрович Богатырёв

RB04. Открытый и закрытый код

• 2 июн, 2007 at 11:42 PM

Небольшие замечания относительно открытого и закрытого кода применительно к программным системам. Существует устойчивый ложный стереотип, что открытые системы, которые приравнивают к системам с открытым кодом (Open Source), — это гарантия полного контроля над системой.

Во-первых, точнее было бы говорить не “код” (code), а “исходный текст” (source). Я понимаю желание американцев всё упрощать до неузнаваемости. Но не надо за ними вторить глупости. Отсюда, кстати, и пошло пренебрежительное «кодер» (coder) по отношению к программистам (programmer). А также кодинг (coding) — процесс перевода решения на конкретный язык программирования, нередко без понимания того, как получено это решение, какова его специфика и т.п.

Во-вторых, исторически код — это объектный или машинный код (понимается исключительно программой/машиной). А исходный текст — он предназначен и для человека, и для машины (программы). В этом существенная терминологическая разница. Код или исходный текст могут быть открыты для анализа компьютером, но одновременно закрыты для анализа человеком. Причина: надо знать ту (формальную) модель, с которой происходит отображение на внешнее представление.

1. Стандарты (спецификации)
2. Исходные тексты (внешний вид на языке реализации)
3. Свобода использования

• Открытые системы (open systems) — соблюдение открытых (международных) стандартов и обеспечение переносимости на разные платформы .
• Закрытые системы (proprietary systems) — реализация систем по внутренним (часто неразглашаемым) спецификациям (ноу-хау, коммерческая тайна).

• Системы с открытыми исходными текстами (open-source systems).
• Системы с закрытыми исходными текстами (closed-source systems).

• детальная конфигурация оборудования, операционного окружения и самой системы;
• подробная спецификация и состав внешних данных (файлы, БД, источники ввода информации, включая интерактивный ввод и т.п.).

Обычно во главу угла здесь ставят бесплатность использования. Но за всё, как известно, надо платить. В свободном программном обеспечении (free software) свобода условна, она ограничивается: сферой (режимом) применения, возможностью дальнейшего развития, сохранением прав за правообладателями, невозможностью извлечения прибыли и т.п. Обычно единственная гарантируемая свобода — бесплатность использования. История возникновения бесплатного ПО подробно изложена в моей статье «Тайна «Золотых ворот» (Мир ПК, #03/2005).

Система может быть бесплатной, закрытой (не соблюдающей открытые стандарты), но с открытыми исходными текстами!

Наличие всех исходных текстов не даёт гарантии контроля, поскольку текст может быть получен и как отображение с более высокоуровневых моделей, которые не известны тому, кто анализирует. В частности, в ряде задач я применял для этой цели такой формальный математический аппарат, как сети Петри (как вариант — конечные автоматы). Заказчику передавались все исходники (на нужном ему языке программирования), но он не мог полностью контролировать то, что там происходит (и даже не мог внести существенные изменения в логику). Данные, выносимые за рамки языка, становились командами. Топология связей диктовалась данными, которые могли меняться динамически.

При рассуждениях относительно открытости по исходным текстам стоит иметь в виду следующие моменты:

1. Даже если конкретная ОС в конкретной конфигурации сертифицирована и переданы все её исходные тексты, ЛЮБОЕ обновление по сути нарушает гарантии сертификата. См. «AIX: формула безопасности» (Открытые системы, #04/2001).

2. Достоверные (trusted) и защищённые (secure) операционные системы должны строиться таковыми с самого начала (!), на этапе проектирования ядра, а не путём последующих примочек и насадок. См. «Защищённые операционные системы» (Открытые системы, #04/2001).

3. Нельзя в полной мере доверять исходному тексту, который разрабатывал кто-то посторонний. Это наглядно продемонстрировал и автор UNIX, Кен Томпсон. См. «Dan O’Dowd Reminds World of UNIX Creator Ken Thompson’s Security Stunt»

4. Наличие внутри ОС чужеродных систем антивирусной защиты (развиваемых структурами, сторонними по отношению к создателям/владельцам ОС) сводит безопасность к нулю. К сожалению, многие так и не осознали всю глубину подобной проблемы. Недавний случай с Symantec (май 2007 г.) — это цветочки: «Symantec парализовал миллионы ПК» (CNews, 25.05.2007)

6. Потакание пиратскому режиму распространения программного обеспечения позволяет вбрасывать специальные модификации коммерческих систем (особенно ОС), которые находятся вне контроля (включая спецслужбы) и за которые не несёт ответственности компания-разработчик. Хотя, строго говоря, она вообще практически ни за что ответственности де-юре и де-факто не несёт.

7. Наличие всех исходных текстов существенно облегчает процесс поиска уязвимостей, взлома и создания вредоносных программ. Это обратная сторона медали открытости исходных текстов.

Вывод: качественные программные системы с претензией на высокий уровень информационной безопасности должны подразумевать как наличие открытых исходных текстов, так и части, закрытые от посторонних глаз. И дело здесь не в ноу-хау. При отсутствии реальной возможности всё перепроверить остаётся только доверие, а оно обеспечивается доверием к производителю, который несёт ответственность. Коммерческие структуры заинтересованы в извлечении прибыли, контроле над рынком и не несут (никакой) ответственности. Именно поэтому конечный контроль со стороны государства в отношении системообразующего ПО (операционные системы) очень важен.

Источник: rbogatyrev.livejournal.com

Открытый исходный код — благо или троянский конь?

Сразу хочется сузить рамки — разговор идет о продаже программного продукта (php+MySQL).
Вопрос — (про)давать ли исходный код?

Аргументы в пользу закрытого кода.
— Подавляющему большинству клиентов нужно чтобы продукт работал и исходный код не нужен.
— При закрытом коде проще осуществлять тех. поддержку — клиент своими руками не залезет куда не надо и не породит новых уникальных ошибок, в которых хрен разберешься.
— Сложнее стырить исходный код. А точнее его можно получить, но вот что-то серьезное переделать в этом «исходнике» сложно — максимум сломать защиту, внести незначительные правки.
— Есть некоторая надежда разработчика, что закрытый код спасет от перепродажи его продукта лихими людьми.
— Есть легкая надежда, что купят продукт, потому как «сломать» не смогут, либо «ломанный» побоятся использовать.
— Народ (наш народ 🙂 ) привык что если код открыт, значит бесплатно!

Аргументы в пользу открытого кода.
— Иногда клиенту просто хочется иметь возможность взглянуть на код. То есть не обязательно даже его иметь, но чтобы возможность такая была. Это могут быть параноики безопасности в хорошем смысле или просто борцы за какие-то права.
— Клиент имеет возможность внести правки, причем весьма серьезные. Вплоть до потери совместимости с последующими версиями продукта (хотя вот это возможно уже в минус).
— Нет проблем с дешифратором закрытого кода. Не секрет, что такие проблемы встречаются (отсутствие Зенда и иже с ним, какие-то локальные глюки т.д.).
— Есть возможность построить сообщество разработчиков купивших скажем девелоперскую лицензию с доступом к открытому коду.

Добавлю немного конкретики.
Вопрос «открытого кода» интересует в связи с «внутрифирменной» дискуссией по поводу развития одного из наших продуктов (CNCat). Мы проходили разные стадии (открытый код, Зенд) и сейчас осуществляем обфрускейтивание (замену названий переменных на бессмысленные) и легкую шифрацию. Когда мы давали продукт в открытом коде и давали его бесплатно — много кто тырил код и на его основе делали свои продукты без всяких ссылок на нас. Что было немного обидно и сейчас не хочется на этом обжечься опять.
Однако правильное позиционирование открытого кода (АПИ, поддержка, контроль и т.д.) может дать нам приток сторонних разработчиков новых фич, мощную обратную связь, отладку — в общем новый импульс.

Дык хочется получить какие-то дополнительные аргументы или мысли по данному вопросу. Как бы Вы повели себя как клиент, как разработчик (конечно желательно чтобы Вы им являлись, чтоб не голословно)? Может есть какие в мире устоявшиеся теории и доказанные практикой подходы (типа фри версия закрыта, купленная открыта)?

Источник: habr.com