> По моему этот парольный менеджер не такая серьезная программа чтобы > потом плакать от каких-то проблем, > по любому нужно просмотреть нескольким людям и разносторонне оценить > возможные дыры, > в таком деле они могут быть только ламерскими либо если взломан алгоритм. > Про ламерские мне уже тут наподсказывали, спасибо.
Понимаешь, есть такой протокол - XMPP. Более известный по слову jabber. Тем, кто его придумывал, тоже кто-то когда-то (может, преподаватель в колледже, а может, коллега на работе) сказал, что TCP - протокол с надежной доставкой. Поэтому они не предусмотрели в протоколе квитирования получения сообщений. Кинули сообщение в сокет - и считают его доставленным. Эффект объяснять? Вокруг этого потом уже пытались прикрутить квитирование доставки, но поскольку в протоколе оно не обязательно, то с тех самых пор в этом протоколе навсегда (ну, по крайней мере до обратно-несовместимого изменения) осталась проблема ненадежной доставки. Ты никогда не можешь быть уверен, что твое сообщение доставят получателю. Еще там, Витус, помню, матерился, протоколы шифрования и подписи сообщений чата (не message, а именно chat) таковы, что если включить и то, и другое, то вместо тела сообщения приходит то ли подписанная информация о том, что сообщение зашифровано, то ли наоборот. А собственно информация не приходит. Зато не перехватишь, да. > А тему в рассылке я затеял чтобы узнать можно ли будет сократить путь > для включения проги в дистрибутив, > надеялся что кто-то ответит: "да собрать пакет это 5-10 минут, кидай > свою прогу, не забудь вложить лицензию GPL и запакетируем ее и положим в > experimental ветку", а то может я закончу чнение "Руководство > начинающего разработчика Debian" только через год. Ну а тебе ответили "ты сначала прогу-то покажи - разработчик Debian, однако, несет некую ответственность перед сообществом за то, что он пакетирует". Причем, обрати внимание, мейнтейнер пакета при этом, подразумевается, берет на себя взаимодействие с автором программы на тему всех проблем с нею. Или берет починку этих проблем на себя. И вот потенциальный мейнтейнер твоего пакета видит человека, который... ну, хочет, допустим, вменяемого, но может пока с трудом. Ему надо этого геморроя - то ли объяснять тебе, как правильно писать твою программу, то ли чинить ее за тебя, то ли считаться мейнтейнером потенциально глючного и дырявого пакета? И вообще, обычно в Debian пакетируют уже готовую программу, у которой уже есть разумное количество пользователей помимо автора. Начнем с этого. > Попробую еще раз объяснить что я хочу. И вправду я пока до конца не знаю > что делать. > Нужно сделать так чтобы при вводе мастер пароля показывались только > имена ключей из пары key=value > или только имя и значение указанного ключа, при условии что пароль > введен правильно, > чтобы доступ к value нельзя было получить одним только паролем и > допустить утечку сразу всех паролей. > > Тут приходит на ум использование второго пароля. И вместе с этой мыслью > вопрос: а нельзя ли избежать второго пароля? > Потому что второй пароль опять же откроет все значения ключей, если > только для шифрации ключей не используются разные пароли. Но > использовать разные пароли для ключей - тоже какой-то маразм - может > проще держать в уме сами пароли чем пароли к зашифрованным паролям :) . > > Вот я и ищу такой способ хранения при котором нельзя будет потерять > сразу все ключи и при этом не запоминать десяток паролей и ключей, но и > более сложный чем использование одного мастер-пароля. > > Если опять непонятно выразился, пишите. Теперь лучше. Теперь я тебе расскажу, что в компьютерной безопасности помимо угрозы первого рода (нелегитимный субъект получает доступ к информации) есть еще и угроза второго рода (легитимный субъект не получает доступа к информации). В принципе, ты уже сам интуитивно понимаешь, что каждый пароль на свое значение - это угроза второго рода, но хорошо бы было, чтобы ты взглянул на задачу чуть более системно. В безопасности всегда приходится балансировать между этими двумя угрозами. В твоем случае явно нужна возможность по вводу одного мастер-пароля получить все значения key, которые есть в базе, и при вводе пароля и key получить value. В принципе, ничто не мешает нарисовать такую систему на скриптах, не забывая только, что данные надо гонять через пайпы, а не через командную строку. Имея в качестве базы данных текстовый файл вида key=value по одной записи на строке, тупо зашифрованный openssl или gpg. Защититься от возможности прочитать все значения при компрометации одного мастер-пароля мы не сможем, а программа может быть просто достаточно умной, чтобы не показывать все значения сразу - много интеллекта на это не нужно. Типа если key не указан, то расшифрованный файл отдаем в пайп чему-то типа perl -pe 's/=.*//' вот тебе и список ключей, а если указан, то чему-то типа perl -e 'while (<STDIN>) {print if /^\s*\Q$ARGV[0]\E\s*=/}' "$1" Если слегка подумать головой, то вся программа умещается в один перловый файл, чуть ли не строчек на 20, не больше, не требующий вообще никаких перловых модулей, даже стандартных. Снаружи требует, в зависимости от выбранного варианта, openssl или gpg. К ней, правда, потом нужно написать man, обязательно по-английски, и русский тоже желателен. Для этого нужно научиться писать маны. Потом желательно показать себя отзывчивым автором, внятно реагирующим на сообщения от пользователей его программы (а значит, получить этих самых пользователей). И вот тогда уже, если к тому времени для тебя Debian developer manual (на английском, да) почему-то все еще будет проблемой, будет пора обращаться с просьбой о пакетировании. -- русская народная глупость Кнышев -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkgaiyli.wl%...@ran.pp.ru