Новый менеджер паролей

[Sergey Stremidlo]

Добрый день!

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

Рассмотрел такие:
cpm - Curses based password manager using PGP-encryption
fpm2 - password manager with GTK+ 2.x GUI
gringotts - secure password and data storage manager
password-gorilla - cross-platform password manager
revelation - GNOME2 Password manager
keepassx

из них только один работает в консоли - cpm, но как-то он страшен.


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4EB002DD...@gmail.com

[Павел Знаменский]

Что сказать-то хотели?

1 ноября 2011 г. 18:31 пользователь Sergey Stremidlo <sere...@gmail.com> написал:

[Andrey Rahmatullin]

On Tue, Nov 01, 2011 at 09:47:18PM +0600, Andrey Rahmatullin wrote:
> В squeeze ещё был pwsafe, но он уже закопан.
Впрочем, его снова пакетят (#630422)

--
WBR, wRAR

[Andrey Rahmatullin]

On Tue, Nov 01, 2011 at 06:31:57PM +0400, Sergey Stremidlo wrote:
> Добрый день!
>
> У меня есть вопросик или даже конкретное предложение,
> но я пока не освоил как правильно в таких случаях поступать.
> Я пишу утилитку - консольный менеджер паролей и хочу чтобы ее
> включили в дистрибутив.
> Пароли менеджеров конечно есть в дистре, но они какие-то громоздкие,
> я же пишу минималистичный с некоторыми вкусностями, которых не
> хватает другим.
>
> Рассмотрел такие:
> cpm - Curses based password manager using PGP-encryption
> fpm2 - password manager with GTK+ 2.x GUI
> gringotts - secure password and data storage manager
> password-gorilla - cross-platform password manager
> revelation - GNOME2 Password manager
> keepassx
>
> из них только один работает в консоли - cpm, но как-то он страшен.

В squeeze ещё был pwsafe, но он уже закопан.

Плюс есть vim и emacs.

--
WBR, wRAR

[Sergey Stremidlo]

01.11.2011 19:09, Павел Знаменский пишет:

Что сказать-то хотели?

1 ноября 2011 г. 18:31 пользователь Sergey Stremidlo <sere...@gmail.com> написал:

Добрый день!

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

... самое главное забыл :)
хочу предложить его в дистрибутив воткнуть.
Весь менеджер в одном файле, пока что в нем 300 строк (еще не доделан).
Собирается одной командой gcc
я так понимаю нужно будет сделать обвес чтобы пакетировался,
ну и полномочия чтобы залить в репозиторий.
Читаю доку как все это должно быть но объемная она http://l10n-russian.alioth.debian.org/maint-guide/index.ru.html
вот и подумал кому нибудь скинуть чтобы укатал мой файл в нужном формате.

[Sergey Stremidlo]

01.11.2011 19:47, Andrey Rahmatullin пишет:

Поглядел pwsafe - тож видимо тяжелый (ncurces,c++)
vim насколько момню шифрует xor - даже на калькуляторе разгадать можно
емакс не знаю как, но ведь не для этого он.
а вот мизерного диспетчера нету, чтобы хранил пароли в таком же виде как ssh хранит ключи,
чтобы очень просто и надежно, чтобы скинуть почтой на работу файл с паролями и прочитать из него в нужный момент пароль из консольки, а так же импортировать из него в ~/.passman недостающие пароли.
И проделывать тот же трюк в обратном порядке.
Что еще нужно для полного счастья?
только помнить мастер пароль и название ключа.
www_moisait_com=lalalamoiparol
шифроваться будет ключ и пароль, причем отдельно. чтобы не подглядеть от чего пароли.

Хочу сделать что-то чуть более сложное чем приведенные ниже скрипты.
Шифрование:

#! /bin/bash
if [ $# -ne 2 ]
then
        echo "Требуется указать 2 аргумента."
        echo "Первый - имя шифруемого файла (который после шифрации будет удален)."
        echo "Второй - имя выходного файла."
        exit 1
else
        openssl enc -e -aes-256-cbc -in "$1" -out "$2"
        rm -f "$1"
        exit 0
fi

Расшифровка:

#! /bin/bash
if [ $# -ne 1 ]
then
        echo "Требуется указать аргумент - имя расшифровываемого файла."
        exit 1
else
        openssl enc -d -aes-256-cbc -in "$1"
        exit 0
fi

[Alex Shulgin]

2011/11/1 Sergey Stremidlo <sere...@gmail.com>:

> Добрый день!
>
> У меня есть вопросик или даже конкретное предложение,
> но я пока не освоил как правильно в таких случаях поступать.
> Я пишу утилитку - консольный менеджер паролей и хочу чтобы ее включили в
> дистрибутив.
> Пароли менеджеров конечно есть в дистре, но они какие-то громоздкие,
> я же пишу минималистичный с некоторыми вкусностями, которых не хватает
> другим.

Что-то вроде этого: https://github.com/a1exsh/pwm/blob/master/pwm ?

Из вкусностей: генерация пароля, копирование в X-клипборд (т.е. можно
вообще ни разу в жизни не видеть конкретных паролей, и из-за плеча
подсмотреть не удастся) :)

Минусы: альфа-версия, но пользовать вполне можно. Сам использую около
месяца уже -- полет нормальный.

[yuri.n...@gmail.com]

On Tue, 1 Nov 2011, Alex Shulgin wrote:

>
> Что-то вроде этого: https://github.com/a1exsh/pwm/blob/master/pwm ?
>
> Из вкусностей: генерация пароля, копирование в X-клипборд (т.е. можно
> вообще ни разу в жизни не видеть конкретных паролей, и из-за плеча
> подсмотреть не удастся) :)
>
> Минусы: альфа-версия, но пользовать вполне можно. Сам использую около
> месяца уже -- полет нормальный.

Здорово. Кратко, понятно и под свои нужды подстраивается на раз.
Для такой программы альфа - только приемущество.

Ю.

p.s. Надо бы еще ехport старых паролей дописать.
Хотя можно и через edit_db() сделать.

[Andrey Rahmatullin]

On Tue, Nov 01, 2011 at 09:04:01PM +0400, Sergey Stremidlo wrote:
> Поглядел pwsafe - тож видимо тяжелый (ncurces,c++)

Ну если это для вас "тяжёлый"...

> vim насколько момню шифрует xor - даже на калькуляторе разгадать можно
> емакс не знаю как, но ведь не для этого он.

Речь не о встроенном шифровании, а о хуках для вызова gpg.

> openssl enc -e -aes-256-cbc -in "$1" -out "$2"

А зачем openssl enc, когда есть gpg?

--
WBR, wRAR

[Sergey Stremidlo]

02.11.2011 13:32, Andrey Rahmatullin пишет:

> On Tue, Nov 01, 2011 at 09:04:01PM +0400, Sergey Stremidlo wrote:
>> Поглядел pwsafe - тож видимо тяжелый (ncurces,c++)
> Ну если это для вас "тяжёлый"...

да, скачал deb пакет, поставил а он при старте выдал пару ошибок и не
подсказал как создать нужные ему файл базы данных.
Считаю что менеджер должен быть настолько легким чтобы его можно было
гуевым интерфейсом юзать (popen()),а файл паролей обрабатывать текстовым
редактором.

>> vim насколько момню шифрует xor - даже на калькуляторе разгадать можно
>> емакс не знаю как, но ведь не для этого он.
> Речь не о встроенном шифровании, а о хуках для вызова gpg.
>

чтобы хуки настроить надо еще vim изучить в такой степени чтобы знать
чего писать.

>> openssl enc -e -aes-256-cbc -in "$1" -out "$2"
> А зачем openssl enc, когда есть gpg?
>

pgp я еще не осилил :)

пожалуй ответ Юрия Нефёдова, наиболее близок к теме:

>Что-то вроде этого: https://github.com/a1exsh/pwm/blob/master/pwm ?
>
>Из вкусностей: генерация пароля, копирование в X-клипборд (т.е. можно
>вообще ни разу в жизни не видеть конкретных паролей, и из-за плеча
>подсмотреть не удастся) :)

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

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB123C5...@gmail.com

[Andrey Kiselev]

On Tue, Nov 01, 2011 at 09:04:01PM +0400, Sergey Stremidlo wrote:

> vim насколько момню шифрует xor - даже на калькуляторе разгадать можно

Vim так же умеет Blowfish.


--
Andrey V. Kiselev

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2011110211...@ak4719.spb.edu

[Andrey Rahmatullin]

On Wed, Nov 02, 2011 at 03:04:37PM +0400, Sergey Stremidlo wrote:
> >Речь не о встроенном шифровании, а о хуках для вызова gpg.
> чтобы хуки настроить надо еще vim изучить в такой степени чтобы
> знать чего писать.

$ vim-addons show gnupg
Addon: gnupg
Status: installed
Description: transparent editing of gpg encrypted files

> >> openssl enc -e -aes-256-cbc -in "$1" -out "$2"
> >А зачем openssl enc, когда есть gpg?
> pgp я еще не осилил :)

А туда же.
Это типично.

--
WBR, wRAR

[Sergey Stremidlo]

02.11.2011 16:42, Andrey Rahmatullin пишет:

> On Wed, Nov 02, 2011 at 03:04:37PM +0400, Sergey Stremidlo wrote:
>>> Речь не о встроенном шифровании, а о хуках для вызова gpg.
>> чтобы хуки настроить надо еще vim изучить в такой степени чтобы
>> знать чего писать.
> $ vim-addons show gnupg
> Addon: gnupg
> Status: installed
> Description: transparent editing of gpg encrypted files
>

$ sudo apt-get install vim-addon-manager
$ vim-addons show
Addon: editexisting
Status: installed
Description: edit the file with an existing Vim, if possible
Addon: justify
Status: installed
Description: left and right align text by filling in with extra spaces
Addon: matchit
Status: installed
Description: extended matching with '%' (e.g. if ... then ... else)
для gpg надо гдето качать?
опять же - все пароли в одном файле

>>>> openssl enc -e -aes-256-cbc -in "$1" -out "$2"
>>> А зачем openssl enc, когда есть gpg?
>> pgp я еще не осилил :)
> А туда же.
> Это типично.
>

осилил:
gpg -c file
gpg file.gpg
но этого мало - суть та же

Кроме этого просмотрел pwm - упор на диалоговый режим, такое не надо.
Надо проще:
passman -a -p pass -k key -v "value1 and value2" - добавить
passman [-r] -p pass -k key - показать
passman -d -p pass -k key - удалить
passman -i from_file - импортировать из файла в ~/.passman
passman -f passfile - юзать указанный файл
passman -c [passfile] - создать указанный файл или дефолтный если не указано
если не задан -p то спросить отключив echo

в последствии можно использовать данную прогу как брелок с ключами

продолжаю делать свой passman, ищу как правильно применить финкции из
openssl/aes.h
как-то туго пока

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB24E2D...@gmail.com

[Andrey Rahmatullin]

On Thu, Nov 03, 2011 at 12:17:49PM +0400, Sergey Stremidlo wrote:
> $ sudo apt-get install vim-addon-manager
> $ vim-addons show
> Addon: editexisting
> Status: installed
> Description: edit the file with an existing Vim, if possible
> Addon: justify
> Status: installed
> Description: left and right align text by filling in with extra spaces
> Addon: matchit
> Status: installed
> Description: extended matching with '%' (e.g. if ... then ... else)
> для gpg надо гдето качать?

vim-scripts

> опять же - все пароли в одном файле

Сделайте в разных.

--
WBR, wRAR

[Sergey Stremidlo]

03.11.2011 12:27, Andrey Rahmatullin пишет:

> On Thu, Nov 03, 2011 at 12:17:49PM +0400, Sergey Stremidlo wrote:
>> $ sudo apt-get install vim-addon-manager
>> $ vim-addons show
>> Addon: editexisting
>> Status: installed
>> Description: edit the file with an existing Vim, if possible
>> Addon: justify
>> Status: installed
>> Description: left and right align text by filling in with extra spaces
>> Addon: matchit
>> Status: installed
>> Description: extended matching with '%' (e.g. if ... then ... else)
>> для gpg надо гдето качать?
> vim-scripts
>

спасибо за экспресс-курс, все получилось, буду пользоваться.

>> опять же - все пароли в одном файле
> Сделайте в разных.
>

и так в разных файлах. пароли от сайтов в файлах с названиями этих
сайтов - это пофиг конечно,
но вот пароли от мейлов в файлах с именами мейлов, это уже хуже...

добавлю опцию -l [filter] чтобы так же легко сделать обзор

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB25409...@gmail.com

[Alex Shulgin]

2011/11/3 Sergey Stremidlo <sere...@gmail.com>:

>
> Кроме этого просмотрел pwm - упор на диалоговый режим, такое не надо.
> Надо проще:
> passman -a -p pass -k key -v "value1 and value2" - добавить

Это есть в планах, как и gpg (по желанию, кому что ближе).

И вообще, после сборки -- обработать напильником. :)

[Иван Лох]

On Thu, Nov 03, 2011 at 12:17:49PM +0400, Sergey Stremidlo wrote:

> Кроме этого просмотрел pwm - упор на диалоговый режим, такое не надо.
> Надо проще:
> passman -a -p pass -k key -v "value1 and value2" - добавить
> passman [-r] -p pass -k key - показать

Так делать очень плохо. Например, потому, что этот пароль остается
в истории шелла, или потому, что он виден в многопользовательских системах
через ps.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20111103115...@nano.ioffe.rssi.ru

[Ivan Shmakov]

>>>>> Иван Лох <l...@1917.com> writes:
>>>>> On Thu, Nov 03, 2011 at 12:17:49PM +0400, Sergey Stremidlo wrote:

>> Кроме этого просмотрел pwm - упор на диалоговый режим, такое не
>> надо. Надо проще:

>> passman -a -p pass -k key -v "value1 and value2" - добавить

>> passman [-r] -p pass -k key - показать

> Так делать очень плохо. Например, потому, что этот пароль остается в
> истории шелла, или потому, что он виден в многопользовательских
> системах через ps.

… Попробовал представить себе su(1) или sudo(8) с передачей
пароля через командную строку…

--
FSF associate member #7257

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/86ty6l8...@gray.siamics.net

[Sergey Stremidlo]

03.11.2011 16:01, Ivan Shmakov пишет:

Иван Лох <l...@1917.com> writes:
On Thu, Nov 03, 2011 at 12:17:49PM +0400, Sergey Stremidlo wrote:

 >> Кроме этого просмотрел pwm - упор на диалоговый режим, такое не
 >> надо.  Надо проще:

 >> passman -a -p pass -k key -v "value1 and value2" - добавить

 >> passman [-r] -p pass -k key - показать

 > Так делать очень плохо.  Например, потому, что этот пароль остается в
 > истории шелла, или потому, что он виден в многопользовательских
 > системах через ps.

	… Попробовал представить себе su(1) или sudo(8) с передачей
	пароля через командную строку…

я это полностью понимаю, это для того чтобы потом гуй прикрутить или пользовать из других прог как пароледержатель, через канал (popen()) передавать пароль,
...хотя вот вдумался - ведь пароль можно пускануть следующей подачей через канал то...
подразобрался с использованием AES, вот так пойдет?
а то не вкурил до конца накой два ключа :), но мне кажется что потянет

// in   - входная строка
// out  - выходная
// len  - размер строки
// pass - фраза для генерации ключей
// mode = AES_ENCRYPT | AES_DECRYPT
int crypt (char *in, char *out, int len, char *pass, int mode)
{
/*      Для шифрования AES требуется 128,192,256-битный ключ
            для этого возьмем инвертированные байты пароля и повторим
                его если он меньше 16 символов и получим 128 бит
*/
        AES_KEY aeskey;
        char key[16];
        char  iv[16];
        int i,passlen,passi;

        passlen = strlen(pass);
        for (i=0; i<16; i++)
        {
                key[i] = ~pass[i % passlen];
                 iv[i] = -pass[i % passlen];
        }

        AES_set_encrypt_key(key, 128, &aeskey);
        AES_cbc_encrypt(in, out, len, &aeskey, iv, mode);
        return 0;
}

[Иван Лох]

On Tue, Nov 01, 2011 at 10:21:17PM +0200, Alex Shulgin wrote:
> 2011/11/1 Sergey Stremidlo <sere...@gmail.com>:
> > Добрый день!
> >
> > У меня есть вопросик или даже конкретное предложение,
> > но я пока не освоил как правильно в таких случаях поступать.
> > Я пишу утилитку - консольный менеджер паролей и хочу чтобы ее включили в
> > дистрибутив.
> > Пароли менеджеров конечно есть в дистре, но они какие-то громоздкие,
> > я же пишу минималистичный с некоторыми вкусностями, которых не хватает
> > другим.
>
> Что-то вроде этого: https://github.com/a1exsh/pwm/blob/master/pwm ?
>
> Из вкусностей: генерация пароля, копирование в X-клипборд (т.е. можно
> вообще ни разу в жизни не видеть конкретных паролей, и из-за плеча
> подсмотреть не удастся) :)

А разве у fd.o нет стандарта на передачу паролей через dbus? Никогда не поверю,
что нет CLI интерфейса к какому-нибудь gnome-keyring-daemon

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20111103121...@nano.ioffe.rssi.ru

[Andrey Rahmatullin]

On Thu, Nov 03, 2011 at 04:14:55PM +0400, Sergey Stremidlo wrote:
> а то не вкурил до конца накой два ключа :)

Какие два ключа?

--
WBR, wRAR

[Ivan Shmakov]

>>>>> Sergey Stremidlo <sere...@gmail.com> writes:

[…]

> /* Для шифрования AES требуется 128,192,256-битный ключ
> для этого возьмем инвертированные байты пароля и повторим
> его если он меньше 16 символов и получим 128 бит
> */

Во-первых, предполагая, что пароль состоит из кодов ASCII,
пространство ключей при таком подходе значительно ограничено (по
сравнению с предельными для алгоритмов AES 2¹²⁸ … 2²⁵⁶.)
Во-вторых, значимыми оказываются только первые 16 октетов
пароля.

Общепринятое решение — использовать в качестве ключа криптохэш
от пароля. E. g., SHA-256.

[…]

--
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/86pqh98...@gray.siamics.net

[Andrey Kiselev]

On Thu, Nov 03, 2011 at 04:11:09PM +0400, Иван Лох wrote:
> А разве у fd.o нет стандарта на передачу паролей через dbus? Никогда не
> поверю, что нет CLI интерфейса к какому-нибудь gnome-keyring-daemon

А вот и нету. Зато есть интерфейс к Python, с помощью которого можно всё
сделать в несколько строк.

--
Andrey V. Kiselev

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2011110312...@ak4719.spb.edu

[Artem Chuprina]

> > /* Для шифрования AES требуется 128,192,256-битный ключ
> > для этого возьмем инвертированные байты пароля и повторим
> > его если он меньше 16 символов и получим 128 бит
> > */
>
> Во-первых, предполагая, что пароль состоит из кодов ASCII,
> пространство ключей при таком подходе значительно ограничено (по
> сравнению с предельными для алгоритмов AES 2¹²⁸ … 2²⁵⁶.)
> Во-вторых, значимыми оказываются только первые 16 октетов
> пароля.
>
> Общепринятое решение — использовать в качестве ключа криптохэш
> от пароля. E. g., SHA-256.

Там, надо сказать, значимых битов будет не больше, потому что хэширование не
добавляет энтропии. Может быть, правда, перебор дороже, но учитывая, что
такие пароли и перебирают соответственно - а именно, составляя таблицы этих
хэшей заранее... А AES к степени, гм, взбитости энтропии в ключе должен
относиться иррелевантно. В смысле, ему должно быть пофиг, открытым текстом
там пароль или хэшированный. Хэшируют для того, чтобы всосать побольше бит из
длинной пассфразы. Более длинной, чем ключ AES. Вот тут простые средства
наложения, типа xor, могут ухудшить показатели (типа, в x xor x меньше
энтропии, чем просто в x), а хэш себя ведет хорошо, он для этого
разрабатывался.

--
There's no sense in being precise, when you don't even know what
you're talking about.
-- John von Neumann

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/877h3hjqh4.wl%r...@ran.pp.ru

[Ivan Shmakov]

>>>>> Artem Chuprina <r...@ran.pp.ru> writes:

>>> /* Для шифрования AES требуется 128,192,256-битный ключ для этого
>>> возьмем инвертированные байты пароля и повторим его если он меньше
>>> 16 символов и получим 128 бит */

>> Во-первых, предполагая, что пароль состоит из кодов ASCII,
>> пространство ключей при таком подходе значительно ограничено (по
>> сравнению с предельными для алгоритмов AES 2¹²⁸ … 2²⁵⁶.) Во-вторых,
>> значимыми оказываются только первые 16 октетов пароля.

>> Общепринятое решение — использовать в качестве ключа криптохэш от
>> пароля. E. g., SHA-256.

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

Действительно.

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

Разве в этом случае есть смысл в таблицах? Мне казалось, SHA —
сравнительно «дешевый» алгоритм.

[…]

--
FSF associate member #7257

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/86lirx8...@gray.siamics.net

[Ivan Shmakov]

>>>>> Иван Лох <l...@1917.com> writes:

[…]

> А разве у fd.o нет стандарта на передачу паролей через dbus?

BTW, каковы типовые задачи, решаемые D-Bus? У меня на
соответствующие демоны вечный Conflicts:; любопытно, не упускаю
ли я чего-либо полезного?

[…]

--
FSF associate member #7257

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/86hb2l8f...@gray.siamics.net

[Artem Chuprina]

> > Может быть, правда, перебор дороже, но учитывая, что такие пароли и
> > перебирают соответственно - а именно, составляя таблицы этих хэшей
> > заранее...
>
> Разве в этом случае есть смысл в таблицах? Мне казалось, SHA —
> сравнительно «дешевый» алгоритм.

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

Именно из этих соображений в /etc/shadow пароли соленые. "Соль" случайна, (в
норме берется как минимум из /dev/urandom, а если повезет, то из /dev/random),
и хотя ее показывают, хэш у того же пароля будет уже другой. А пространство
всех возможных комбинаций этих некоротеньких солей со всеми словарными
паролями существенно больше, чем просто пространство всех словарных паролей,
тут уже предвычесленных хэшей не напасешься.

--
Все учтено могучим ураганом...

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/874nyljnth.wl%r...@ran.pp.ru

[Sergey Stremidlo]

03.11.2011 17:16, Artem Chuprina пишет:

 > /*      Для шифрования AES требуется 128,192,256-битный ключ
 > для этого возьмем инвертированные байты пароля и повторим
 > его если он меньше 16 символов и получим 128 бит
 > */

	Во-первых, предполагая, что пароль состоит из кодов ASCII,
	пространство ключей при таком подходе значительно ограничено (по
	сравнению с предельными для алгоритмов AES 2¹²⁸ … 2²⁵⁶.)
	Во-вторых, значимыми оказываются только первые 16 октетов
	пароля.

	Общепринятое решение — использовать в качестве ключа криптохэш
	от пароля.  E. g., SHA-256.

Там, надо сказать, значимых битов будет не больше, потому что хэширование не
добавляет энтропии.  Может быть, правда, перебор дороже, но учитывая, что
такие пароли и перебирают соответственно - а именно, составляя таблицы этих
хэшей заранее...  А AES к степени, гм, взбитости энтропии в ключе должен
относиться иррелевантно.  В смысле, ему должно быть пофиг, открытым текстом
там пароль или хэшированный.  Хэшируют для того, чтобы всосать побольше бит из
длинной пассфразы.  Более длинной, чем ключ AES.  Вот тут простые средства
наложения, типа xor, могут ухудшить показатели (типа, в x xor x меньше
энтропии, чем просто в x), а хэш себя ведет хорошо, он для этого
разрабатывался.

учитывая все доводы решил сделать так:
1.считываем в password[16]
2.берем salt[16] из /dev/random
3.складываем с паролем побайтно, с переносом разряда
4.получаем md5-хеш из всей этой лабуды (и это будет ключ)
  итак AES_set_encrypt_key(key, 128, &aeskey); получит таки модный ключ,
5.сохраняем сальт в том же файле чтобы впоследствии с помощью пароля получить ключ для расшифровки.

а нафига iv нужен в AES_cbc_encrypt(in, out, len, &aeskey, iv, mode); ?
который я обозвал вторым ключом
можно предположить что это что-то типа сальта и его нужно сделать подобным способом как и ключ

[Andrey Rahmatullin]

On Thu, Nov 03, 2011 at 06:34:44PM +0400, Sergey Stremidlo wrote:
> а нафига iv нужен в *AES_cbc_encrypt(in, out, len, &aeskey, iv, mode);* ?

> который я обозвал вторым ключом

Рано вам криптософт в Debian проталкивать. Почитайте что-нибудь популярное
про режимы симметричного шифрования для начала.

--
WBR, wRAR

[yuri.n...@gmail.com]

On Thu, 3 Nov 2011, Иван Лох wrote:

> On Tue, Nov 01, 2011 at 10:21:17PM +0200, Alex Shulgin wrote:
>> 2011/11/1 Sergey Stremidlo <sere...@gmail.com>:

>> Что-то вроде этого: https://github.com/a1exsh/pwm/blob/master/pwm ?
>>
>> Из вкусностей: генерация пароля, копирование в X-клипборд (т.е. можно
>> вообще ни разу в жизни не видеть конкретных паролей, и из-за плеча
>> подсмотреть не удастся) :)
>
> А разве у fd.o нет стандарта на передачу паролей через dbus? Никогда не поверю,
> что нет CLI интерфейса к какому-нибудь gnome-keyring-daemon
>

Какой dbus, если я, скажем, на свою машину по сети приконектился?
А через X передавать хоть и не супер, но в разумных пределах
безопасно (imho).

Ю.

[Иван Лох]

On Thu, Nov 03, 2011 at 07:15:46PM +0400, yuri.n...@gmail.com wrote:
> >А разве у fd.o нет стандарта на передачу паролей через dbus? Никогда не поверю,
> >что нет CLI интерфейса к какому-нибудь gnome-keyring-daemon
> >
>
> Какой dbus, если я, скажем, на свою машину по сети приконектился?
> А через X передавать хоть и не супер, но в разумных пределах
> безопасно (imho).

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

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

Если ты не доверяешь локальной машине, то какой X клипборард

P.S. Я согласен, что нежелание принимать сетевые патчи к dbus
дебилизм.

P.S.S Третий dbus срач?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20111103152...@nano.ioffe.rssi.ru

[Иван Лох]

On Thu, Nov 03, 2011 at 09:13:09PM +0700, Ivan Shmakov wrote:
> >>>>> Иван Лох <l...@1917.com> writes:
>
> […]
>
> > А разве у fd.o нет стандарта на передачу паролей через dbus?
>
> BTW, каковы типовые задачи, решаемые D-Bus? У меня на
> соответствующие демоны вечный Conflicts:; любопытно, не упускаю
> ли я чего-либо полезного?

Topic, например. Приложение может запросить у хранилища ключей
пароль, а хранилище, может попросить себя открыть (или уже
быть открытым).

И, вообще, везде где нужна сигнальная шина. Приложение может сказать:
"Оп! Я развернулось на весь экран, блокировать скринсейверы и нотифайеры".

Или оповестить _все_ приложения о том, что батарея нетбука почти разряжена
и какие-то из них могут перейти в режим энергосбережения.

Или им же сказать, что поменялся активный пользователь у экрана компьютера, что,
обычно, ведет к изменению политик доступа. Например, IM пользователя ivanov
не должен пищать, если у монитора находится пользователь sidorov.
скрыт.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20111103152...@nano.ioffe.rssi.ru

[Ivan Shmakov]

>>>>> Иван Лох <l...@1917.com> writes:
>>>>> On Thu, Nov 03, 2011 at 09:13:09PM +0700, Ivan Shmakov wrote:
>>>>> Иван Лох <l...@1917.com> writes:

[…]

>>> А разве у fd.o нет стандарта на передачу паролей через dbus?

>> BTW, каковы типовые задачи, решаемые D-Bus? У меня на
>> соответствующие демоны вечный Conflicts:; любопытно, не упускаю ли я
>> чего-либо полезного?

> Topic, например. Приложение может запросить у хранилища ключей
> пароль, а хранилище, может попросить себя открыть (или уже быть
> открытым).

Это как раз ясно.

Я, к слову, не сторонник разведения паролей. Что-нибудь на
основе криптографии с открытым ключом (и, возможно, WoT) было
бы, на мой взгляд, куда удобнее.

К сожалению, X.509 во Всемирной паутине не прижились. OpenID —
едва ли удачное решение, но достаточно распространен, чтобы быть
полезным.

С другой стороны, надо полагать, что, e. g., emacsclient(1),
ssh-agent(1) и gpg-agent(1) также могли бы воспользоваться
D-Bus?

> И, вообще, везде где нужна сигнальная шина. Приложение может сказать:
> "Оп! Я развернулось на весь экран, блокировать скринсейверы и
> нотифайеры".

Может ли пользователь «отлучить» приложение от D-Bus?

[…]

> Или им же сказать, что поменялся активный пользователь у экрана
> компьютера, что, обычно, ведет к изменению политик доступа. Например,
> IM пользователя ivanov не должен пищать, если у монитора находится
> пользователь sidorov. скрыт.

Не понимаю. Завершился сеанс — завершились приложения. Зачем
D-Bus?

--
FSF associate member #7257

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/868vnx8...@gray.siamics.net

[Dmitry Nezhevenko]

On Thu, Nov 03, 2011 at 11:56:53PM +0700, Ivan Shmakov wrote:
> > Или им же сказать, что поменялся активный пользователь у экрана
> > компьютера, что, обычно, ведет к изменению политик доступа. Например,
> > IM пользователя ivanov не должен пищать, если у монитора находится
> > пользователь sidorov. скрыт.
>
> Не понимаю. Завершился сеанс — завершились приложения. Зачем
> D-Bus?

Смена активного пользователя != завершился сеанс.

--
WBR, Dmitry

[Иван Лох]

On Thu, Nov 03, 2011 at 11:56:53PM +0700, Ivan Shmakov wrote:
>

> > И, вообще, везде где нужна сигнальная шина. Приложение может сказать:
> > "Оп! Я развернулось на весь экран, блокировать скринсейверы и
> > нотифайеры".
>
> Может ли пользователь «отлучить» приложение от D-Bus?

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

> > Или им же сказать, что поменялся активный пользователь у экрана
> > компьютера, что, обычно, ведет к изменению политик доступа. Например,
> > IM пользователя ivanov не должен пищать, если у монитора находится
> > пользователь sidorov. скрыт.
>
> Не понимаю. Завершился сеанс — завершились приложения. Зачем
> D-Bus?

Он не завершился. Просто активен X-сервер другого пользователя. Многие
сеансы не закрывают месяцами. Несколько X серверов просто запущено.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20111103170...@nano.ioffe.rssi.ru

[Andrey Kiselev]

On Thu, Nov 03, 2011 at 11:56:53PM +0700, Ivan Shmakov wrote:

> С другой стороны, надо полагать, что, e. g., emacsclient(1),
> ssh-agent(1) и gpg-agent(1) также могли бы воспользоваться
> D-Bus?

gnome-keyring-daemon выполняет функции ssh- и gpg-agent и использует DBus.

--
Andrey V. Kiselev

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20111103181...@ak4719.spb.edu

[Sergey Stremidlo]

03.11.2011 18:40, Andrey Rahmatullin пишет:

> On Thu, Nov 03, 2011 at 06:34:44PM +0400, Sergey Stremidlo wrote:

>> а нафига iv нужен в *AES_cbc_encrypt(in, out, len,&aeskey, iv, mode);* ?

>> который я обозвал вторым ключом
> Рано вам криптософт в Debian проталкивать. Почитайте что-нибудь популярное
> про режимы симметричного шифрования для начала.
>

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

может какие есть готовые алгоритмы для такого дела?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB2E9D9...@gmail.com

[Ivan Shmakov]

>>>>> Иван Лох <l...@1917.com> writes:
>>>>> On Thu, Nov 03, 2011 at 11:56:53PM +0700, Ivan Shmakov wrote:

>>> И, вообще, везде где нужна сигнальная шина. Приложение может
>>> сказать: "Оп! Я развернулось на весь экран, блокировать
>>> скринсейверы и нотифайеры".

>> Может ли пользователь «отлучить» приложение от D-Bus?

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

Я так понимаю, что снятие (unset) соответствующих переменных
окружения приведет к тому, что вновь запускаемое приложение не
сможет подключиться к D-Bus?

>>> Или им же сказать, что поменялся активный пользователь у экрана
>>> компьютера, что, обычно, ведет к изменению политик
>>> доступа. Например, IM пользователя ivanov не должен пищать, если у
>>> монитора находится пользователь sidorov. скрыт.

>> Не понимаю. Завершился сеанс — завершились приложения. Зачем
>> D-Bus?

> Он не завершился. Просто активен X-сервер другого пользователя.
> Многие сеансы не закрывают месяцами. Несколько X серверов просто
> запущено.

Действительно.

$ ps x -o etime,cmd | grep -F -- emacs
413-22:43:44 emacs

--
FSF associate member #7257

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/86ty6k7...@gray.siamics.net

[Artem Chuprina]

> >> а нафига iv нужен в *AES_cbc_encrypt(in, out, len,&aeskey, iv, mode);* ?
> >> который я обозвал вторым ключом
> > Рано вам криптософт в Debian проталкивать. Почитайте что-нибудь популярное
> > про режимы симметричного шифрования для начала.
> >
> с тонкостями по ходу дела разберусь, тут еще обвес вокруг этого
> шифрования нужно сделать.

Криптография - это такая штука, где по ходу дела с тонкостями разбираться
нельзя. Будет ОЧЕНЬ больно, причем в самый неподходящий момент.

Конкретно про этот алгоритм я могу рассказать, что такое iv и зачем оно нужно,
но вообще совет почитать букварь на эту тему (Шнайер, "Прикладная
криптография", хотя бы первые главы) здрав.

> на данный момент шифруется ключ и его значение одним паролем, но это уже
> лучше чем vim+gpg.
> т.е. в один момент будет засвечиваться только одна пара ключ=значение,
> т.е. компрометация мастер пароля не приведет к раскрытию остальных, но
> придется помнить имена ключей.
> Хотя сильно облегчит дальнейший подбор - придется подбирать только ключи.
> Вот хочу еще что-нибудь придумать чтобы предотвратить это, да и
> запоминать ключи тоже как-то...
>
> может какие есть готовые алгоритмы для такого дела?

Может, и есть. Если бы ты смог объяснить, чего хочешь, так, чтобы понял не
только ты (а заодно и ты сам поймешь), может, ты даже получил бы внятный
ответ.

--
Творить - не делать! (c)Элхэ Ниеннах

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/8739e4jea6.wl%r...@ran.pp.ru

[Иван Лох]

On Fri, Nov 04, 2011 at 12:40:53PM +0700, Ivan Shmakov wrote:
>
> Я так понимаю, что снятие (unset) соответствующих переменных
> окружения приведет к тому, что вновь запускаемое приложение не
> сможет подключиться к D-Bus?

If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use D-Bus, by default the process will attempt to
invoke dbus-launch with the --autolaunch option to start up a new session bus or find the existing bus address on the X
display or in a file in ~/.dbus/session-bus/

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20111104125...@nano.ioffe.rssi.ru

[Ivan Shmakov]

>>>>> Иван Лох <l...@1917.com> writes:
>>>>> On Fri, Nov 04, 2011 at 12:40:53PM +0700, Ivan Shmakov wrote:

>> Я так понимаю, что снятие (unset) соответствующих переменных
>> окружения приведет к тому, что вновь запускаемое приложение не
>> сможет подключиться к D-Bus?

> If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to
> use D-Bus, by default the process will attempt to invoke dbus-launch
> with the --autolaunch option to start up a new session bus or find
> the existing bus address on the X display or in a file in
> ~/.dbus/session-bus/

Ясно, благодарю.

Решение (помимо, e. g., $ HOME=$(mktemp -dt) myapp &)?

--
FSF associate member #7257

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/867h3g6...@gray.siamics.net

[Иван Лох]

On Fri, Nov 04, 2011 at 08:12:44PM +0700, Ivan Shmakov wrote:
> >>>>> Иван Лох <l...@1917.com> writes:
> >>>>> On Fri, Nov 04, 2011 at 12:40:53PM +0700, Ivan Shmakov wrote:
>
> > with the --autolaunch option to start up a new session bus or find
> > the existing bus address on the X display or in a file in
> > ~/.dbus/session-bus/
>
> Ясно, благодарю.
>
> Решение (помимо, e. g., $ HOME=$(mktemp -dt) myapp &)?

Написать в эту переменную нечто, кроме autolaunch

P.S. О cli для gnome-keyring
gkeyring (питон), gnome-keyring-query (C и даже короче)

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20111104134...@nano.ioffe.rssi.ru

[Sergey Stremidlo]

04.11.2011 15:52, Artem Chuprina пишет:

>>>> а нафига iv нужен в *AES_cbc_encrypt(in, out, len,&aeskey, iv, mode);* ?
>>>> который я обозвал вторым ключом
>>> Рано вам криптософт в Debian проталкивать. Почитайте что-нибудь популярное
>>> про режимы симметричного шифрования для начала.
>>>
>> с тонкостями по ходу дела разберусь, тут еще обвес вокруг этого
>> шифрования нужно сделать.
> Криптография - это такая штука, где по ходу дела с тонкостями разбираться
> нельзя. Будет ОЧЕНЬ больно, причем в самый неподходящий момент.
>
> Конкретно про этот алгоритм я могу рассказать, что такое iv и зачем оно нужно,
> но вообще совет почитать букварь на эту тему (Шнайер, "Прикладная
> криптография", хотя бы первые главы) здрав.
>

Значит, буду читать книгу, спасибо за совет. Книга эта есть в эл.виде,
проглядел оглавление, но не увидел явного AES или rajiendael или как там
его поэтому полез в тырнет.

По моему этот парольный менеджер не такая серьезная программа чтобы
потом плакать от каких-то проблем,
по любому нужно просмотреть нескольким людям и разносторонне оценить
возможные дыры,
в таком деле они могут быть только ламерскими либо если взломан алгоритм.
Про ламерские мне уже тут наподсказывали, спасибо.
А тему в рассылке я затеял чтобы узнать можно ли будет сократить путь
для включения проги в дистрибутив,
надеялся что кто-то ответит: "да собрать пакет это 5-10 минут, кидай
свою прогу, не забудь вложить лицензию GPL и запакетируем ее и положим в
experimental ветку", а то может я закончу чнение "Руководство
начинающего разработчика Debian" только через год.

>> на данный момент шифруется ключ и его значение одним паролем, но это уже
>> лучше чем vim+gpg.
>> т.е. в один момент будет засвечиваться только одна пара ключ=значение,
>> т.е. компрометация мастер пароля не приведет к раскрытию остальных, но
>> придется помнить имена ключей.
>> Хотя сильно облегчит дальнейший подбор - придется подбирать только ключи.
>> Вот хочу еще что-нибудь придумать чтобы предотвратить это, да и
>> запоминать ключи тоже как-то...
>>
>> может какие есть готовые алгоритмы для такого дела?
> Может, и есть. Если бы ты смог объяснить, чего хочешь, так, чтобы понял не
> только ты (а заодно и ты сам поймешь), может, ты даже получил бы внятный
> ответ.
>

Попробую еще раз объяснить что я хочу. И вправду я пока до конца не знаю
что делать.
Нужно сделать так чтобы при вводе мастер пароля показывались только
имена ключей из пары key=value
или только имя и значение указанного ключа, при условии что пароль
введен правильно,
чтобы доступ к value нельзя было получить одним только паролем и
допустить утечку сразу всех паролей.

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

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

Если опять непонятно выразился, пишите.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB4F68A...@gmail.com

[Alex Shulgin]

2011/11/5 Sergey Stremidlo <sere...@gmail.com>:

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

Цель здравая, хотя что не понятно что будуте делать, если начисто
забыли нужный ключ. Раззве что перебирать похожие варианты, пока не
вспомните.

Простейший вариант -- хранить каждый пароль в отдельном файле. Для
открытия одного пароля вводим мастер-пароль и ключ, по ним строим ключ
для расшифрования и перебираем все файлы, пока не подойдет ключ.
Естественно, нужен такой алгоритм, который четко сможет определить,
что ключ не подходит и не выплюнет вместо расшифрованных данных вам
какой-нибудь мусор. AES-256, насколько я помню, таким свойством _не_
обладает.

Мысль вдогонку: если у вас угнали мастер-пароль и вашу базу, то многие
пароли все равно будут раскрыты, т.к. в качестве ключей наверняка
будут использоваться очевидные значения: например, адрес сайта. Чтобы
этого избежать придется использовать неочевидные, трудно подбираемые
ключи, а их легче забыть. И не проще ли тогда сами ключи использовать
в качестве паролей?

--
Alex

[Artem Chuprina]

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

Понимаешь, есть такой протокол - 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-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87zkgaiyli.wl%r...@ran.pp.ru

[Andrey Kiselev]

On Fri, Nov 04, 2011 at 05:44:40PM +0400, О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ wrote:
> P.S. О©╫ cli О©╫О©╫О©╫ gnome-keyring
> gkeyring (О©╫О©╫О©╫О©╫О©╫), gnome-keyring-query (C О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫)

О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ Debian?

--
Andrey V. Kiselev

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2011110511...@ak4719.spb.edu

[Sergey Stremidlo]

> Ну а тебе ответили "ты сначала прогу-то покажи - разработчик Debian, однако,
> несет некую ответственность перед сообществом за то, что он пакетирует".
>

прога вот http://paste.debian.net/hidden/117ce902/
по моим прикидкам готова на треть
работаю над функцией добавление нового пароля
./passman -a -p pass -k key1 -v val1

> И вообще, обычно в Debian пакетируют уже готовую программу, у которой уже есть
> разумное количество пользователей помимо автора. Начнем с этого.
>

видимо стоит завести страничку на sourceforge сначала, пожалуй так и сделаю

>
> Если слегка подумать головой, то вся программа умещается в один перловый файл,
> чуть ли не строчек на 20, не больше, не требующий вообще никаких перловых
> модулей, даже стандартных. Снаружи требует, в зависимости от выбранного
> варианта, openssl или gpg.
>
>

меня удивляет почему еще никто не написал эти 20 строк,
чтобы закрыть дырку между диалоговыми менеджерами паролей и gpg.
Уверен что многие были бы рады такой утилитке.
Я не знаю перла поэтому взялся за си, но поскольку у си примитивная
библиотека работы со строками
приходится делать большой обвес вокруг шифрующих/дешифрующих функций.

У меня всего несколько требований к менеджеру паролей, но им не
соответствует ни один мне знакомый менеджер.
А именно:
- текстовый файл в ascii (чтобы почтой переслать себе на работу нужные
пароли, вручную почистить его)
- запрос пароля из командной строки (когда не запущены Х)
- отсутствие диалогового режима (например чтобы читать пароли из
скриптов на php)

PS: шифрованый ключ и значение отделяются пробелом типа того:
siq5lQf3sc6hmI0eJp1MYg1lupY
AAAAB3NzaC1yc2EAAAABIwAAAQEAnYNEwvrv6CSFM8kMGjuZBM
чтобы можно было в ключе и его значении использовать произвольные символы,
ибо менеджер паролей это основное назначение, в колонке "пароли" я
собираюсь держать строки типа
email=my...@mail.ru login=mylogin pass=mypass
т.е. не просто пароль а секретные данные.

Думаю что нужно как-то решить проблему второго рода (легитимный субъект
не получает доступа)
и пойти по пути второго пароля, но например чтобы облегчить запоминание
требовать е-майл.
Т.е. е-майл + пароль высветит только половину зашифрованных данных если
используются рабочий и домашний
адреса. С одним мастер паролем вполне хватит и gpg, я борюсь как раз с
одновременой потерей всех паролей.
Может быть использовать мак-адрес для шифрования, а впоследствии режим
восстановления и указывать мак-адрес так
же в командной строке, зато если потерял файл то злоумышленнику нужен
еще и мак-адрес.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB539C4...@gmail.com

[Sergey Stremidlo]

>> меня удивляет почему еще никто не написал эти 20 строк,
>> чтобы закрыть дырку между диалоговыми менеджерами паролей и gpg.
>> Уверен что многие были бы рады такой утилитке.

> Да таких утилит -- мильён, ихмо. А я свой вариант писал не от того,
> что думал, что нет такой программы, а потому что интересно, да и лучше
> разбираться в вопросе буду (надеюсь ;)
>
Я увидел только pwm и то он не удовлетворяет пока моим критериям

>> Я не знаю перла поэтому взялся за си, но поскольку у си примитивная
>> библиотека работы со строками
>> приходится делать большой обвес вокруг шифрующих/дешифрующих функций.

> Ну, на перле свет клином не сошелся. Любой скриптовый язык подошел бы
> лучше, чем C.
>
php мне не нравится, до питона тоже не добрался

>> У меня всего несколько требований к менеджеру паролей, но им не
>> соответствует ни один мне знакомый менеджер.
>> А именно:
>> - текстовый файл в ascii (чтобы почтой переслать себе на работу нужные
>> пароли, вручную почистить его)

> А на флешке с собой носить не судьба?
>
я забываю флешку часто :) проще на телефоне, но нету удобных прог, да и
жалко пароли с телефоном терять

>> - отсутствие диалогового режима (например чтобы читать пароли из скриптов на
>> php)

> ой, а это-то зачем?
>
например чтобы при разработке веб-приложений не писать код для работы с
юзверями.
подключился к серверу и из командной строки добавил нужного.
да и мало ли зачем, это просто пример. Вся сила юникс в возможности
комбинации программ,
а диалоговый режим разрушает эту силу, поэтому все что не может работать
через командную
строку или stdin не круто.

>> PS: шифрованый ключ и значение отделяются пробелом типа того:
>> siq5lQf3sc6hmI0eJp1MYg1lupY
>> AAAAB3NzaC1yc2EAAAABIwAAAQEAnYNEwvrv6CSFM8kMGjuZBM
>> чтобы можно было в ключе и его значении использовать произвольные символы,

> Кроме пробела, да?
>
пробел тоже можно, он будет вшифрован в абрукадабру которая не имеет
пробела ибо представляет собой base64 или аналогичный код (я взял тупо
тетрады, т.е. двоичное 255 будет представлено в моем случае ff, потому
что очень просто реализуется).

>
>
>> Думаю что нужно как-то решить проблему второго рода (легитимный субъект не
>> получает доступа)
>> и пойти по пути второго пароля, но например чтобы облегчить запоминание
>> требовать е-майл.
>> Т.е. е-майл + пароль высветит только половину зашифрованных данных если
>> используются рабочий и домашний
>> адреса.

> Как-то слишком запутанно и сложно для понимания. Это скорее снизит
> надежность, чем ее увеличит.
>
я размышляю в рассылку потому что жду что может кто предложит разумный
вариант,
а не раскритикует сырые мысли.

>
>> Может быть использовать мак-адрес для шифрования, а впоследствии режим
>> восстановления и указывать мак-адрес так
>> же в командной строке, зато если потерял файл то злоумышленнику нужен еще и
>> мак-адрес.

> Ну это вообще, по-моему ни в какие ворота. Ну принесли вы базу на
> работу. Какой мак адрес вводить? Проще тогда на бумажке все пароли
> записать.
чтобы обеспечить работоспособность паролей на другой машине в этом
случае придется и мак адрес приложить при пересылке, а затем произвести
перепривязку пароля путем указания специальной опции аварийного
восстановления :)
... мда, надо чтото более простое, некоторые могут не знать что такое
мак-адрес.

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

Вот такая еще идея посетила:
вводим ./passman -l -p password
т.е. командой -l получаем список ключей и подглядев нужный нам делаем
очередной запрос:
./passman -k key -p password
прога расшифровывает контрольный вопрос и задает его:
Моё любимое блюдо:
и уже после ввода отображает содержимое ключа.
или так: ./passman -k key -p password -w answer
Т.е. желающие пользоваться будут вынуждены приучиться создавать
нормальные контрольные вопросы и к более долгому добыванию своего пароля.
Кому лень - юзают gpg.
Мне нравится эта идея :) пока

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB54D12...@gmail.com

[Alex Shulgin]

2011/11/5 Sergey Stremidlo <sere...@gmail.com>:

>
>> Ну, на перле свет клином не сошелся.  Любой скриптовый язык подошел бы
>> лучше, чем C.
>>
> php мне не нравится, до питона тоже не добрался

Менеджер паролей на php это было бы сильно... ажно дух захватывает :)
Подсказка: на php и питоне свет также клином не сошелся, хотя выбор
резко сужается.

> проще на телефоне, но нету удобных прог, да и
> жалко пароли с телефоном терять

Ой, а про бекапы вы слышали?

>>> - отсутствие диалогового режима (например чтобы читать пароли из скриптов
>>> на
>>> php)
>>
>> ой, а это-то зачем?
>>
> например чтобы при разработке веб-приложений не писать код для работы с
> юзверями.
> подключился к серверу и из командной строки добавил нужного.

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

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

а, ну да, ну да. а это письмо, отправленное с @gmail.com вы тоже с
командной строки послали? нет, а почему? это ж не круто.

>>> PS: шифрованый ключ и значение отделяются пробелом типа того:
>>> siq5lQf3sc6hmI0eJp1MYg1lupY
>>> AAAAB3NzaC1yc2EAAAABIwAAAQEAnYNEwvrv6CSFM8kMGjuZBM
>>> чтобы можно было в ключе и его значении использовать произвольные
>>> символы,
>>
>> Кроме пробела, да?
>>
> пробел тоже можно, он будет вшифрован в абрукадабру которая не имеет пробела
> ибо представляет собой base64 или аналогичный код (я взял тупо тетрады, т.е.
> двоичное 255 будет представлено в моем случае ff, потому что очень просто
> реализуется).

каюсь, погорячился :)

> я размышляю в рассылку потому что жду что может кто предложит разумный
> вариант,
> а не раскритикует сырые мысли.

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

> Т.е. желающие пользоваться будут вынуждены приучиться создавать нормальные
> контрольные вопросы и к более долгому добыванию своего пароля.
> Кому лень - юзают gpg.

что-то я не вижу каким боком здесь зависимость от того чем идет
шифрование -- gpg, openssl или что-то другое. совершенно не связанные
друг с другом вещи

Все, мне надоело. :-p

[Artem Chuprina]

> > Ну а тебе ответили "ты сначала прогу-то покажи - разработчик Debian, однако,
> > несет некую ответственность перед сообществом за то, что он пакетирует".
> >
> прога вот http://paste.debian.net/hidden/117ce902/
> по моим прикидкам готова на треть
> работаю над функцией добавление нового пароля
> ./passman -a -p pass -k key1 -v val1

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

> > И вообще, обычно в Debian пакетируют уже готовую программу, у которой уже
> > есть разумное количество пользователей помимо автора. Начнем с этого.
> >
> видимо стоит завести страничку на sourceforge сначала, пожалуй так и сделаю
> >
> > Если слегка подумать головой, то вся программа умещается в один перловый
> > файл, чуть ли не строчек на 20, не больше, не требующий вообще никаких
> > перловых модулей, даже стандартных. Снаружи требует, в зависимости от
> > выбранного варианта, openssl или gpg.
> >
> меня удивляет почему еще никто не написал эти 20 строк,
> чтобы закрыть дырку между диалоговыми менеджерами паролей и gpg.

Как обычно, "кто может, тому не надо". Собственно, мне программа с таким
функционалом просто не нужна, поэтому я ее и пишу.

С другой стороны, когда мне нужна программа на 20 строк, я ее пишу, но не
публикую.

zsh% ls ~/etc/bin|wc -l
52
zsh% cat ~/etc/bin/*|wc -l
944

В смысле, у меня в ~/etc/bin, включенном в PATH, 52 программы. Суммарная их
длина - 944 строки. То есть, натурально, в среднем чуть меньше 20 строк на
программу. В норме это либо sh (иногда zsh-специфичные вещи встречаются - это
мой любимый шелл, в нем есть много вкусного по сравнению с sh, и я об этом
знаю), либо perl.

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

> Уверен что многие были бы рады такой утилитке.
> Я не знаю перла поэтому взялся за си, но поскольку у си примитивная
> библиотека работы со строками
> приходится делать большой обвес вокруг шифрующих/дешифрующих функций.

Лучше бы перл выучил, право слово. Ну или не знаю, python, tcl...

> У меня всего несколько требований к менеджеру паролей, но им не
> соответствует ни один мне знакомый менеджер.
> А именно:
> - текстовый файл в ascii (чтобы почтой переслать себе на работу нужные
> пароли, вручную почистить его)
> - запрос пароля из командной строки (когда не запущены Х)
> - отсутствие диалогового режима (например чтобы читать пароли из
> скриптов на php)
>

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

> Думаю что нужно как-то решить проблему второго рода (легитимный субъект
> не получает доступа)
> и пойти по пути второго пароля, но например чтобы облегчить запоминание
> требовать е-майл.
> Т.е. е-майл + пароль высветит только половину зашифрованных данных если
> используются рабочий и домашний
> адреса. С одним мастер паролем вполне хватит и gpg, я борюсь как раз с
> одновременой потерей всех паролей.
> Может быть использовать мак-адрес для шифрования, а впоследствии режим
> восстановления и указывать мак-адрес так
> же в командной строке, зато если потерял файл то злоумышленнику нужен
> еще и мак-адрес.

Когда я учился в школе, у нас был такой анекдот.

Чукча приезжает в Москву, садится в автобус и покупает два билета.
- Чукча, зачем тебе второй билет?
- Однако, если первый потеряю, второй есть!
- А если оба потеряешь?
- Однако, у чукчи проездной есть!

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

А проблемы с доступом к паролям скриптов на PHP решаются иначе. А именно:

0) этим скриптам не показывают никаких паролей, кроме тех, что нужны им для
работы;
1) эти пароли хранят открытым текстом, но с правом чтения только для того
пользователя, от которого работают эти скрипты (и который сами эти скрипты,
разумеется, тоже может прочесть);
2) понимают, какова степень защищенности этих паролей, и каковы у этого
следствия.

Все ухищрения с шифрованием паролей для полного автопилота почти бессмысленны,
ибо что может сделать один автопилот, то может сделать и другой. ("Почти"
относится к ситуации, когда у тебя не скрипт на PHP, а что-то компилируемое,
unreadable для того пользователя, из-под которого работает, немалого размера,
и желательно написанное не на C, чтобы дебаггер не помогал. Тогда добыть из
такого файла пароль для расшифрования можно, но дорого, дешевле сломать
соседний сайт, он на PHP.)

--
Ну какая работа со строками может быть в языке, название которого является
не строкой, а символом?
Sergue E. Leontiev в <csc2ot$hra$1...@ddt.demos.su>

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87y5vuijy5.wl%r...@ran.pp.ru

[Sergey Stremidlo]

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

и я ответил что осознаю это, что это для упрощения взаимодействия с
другими программами.
в скайпе например есть опция --pipelogin
$ skype -h | grep pipe
--pipelogin Command line login. "echo username password |
skype --pipelogin"

>
> Как обычно, "кто может, тому не надо". Собственно, мне программа с таким
> функционалом просто не нужна, поэтому я ее и пишу.
>
> С другой стороны, когда мне нужна программа на 20 строк, я ее пишу, но не
> публикую.
>
> zsh% ls ~/etc/bin|wc -l
> 52
> zsh% cat ~/etc/bin/*|wc -l
> 944
>
> В смысле, у меня в ~/etc/bin, включенном в PATH, 52 программы. Суммарная их
> длина - 944 строки. То есть, натурально, в среднем чуть меньше 20 строк на
> программу. В норме это либо sh (иногда zsh-специфичные вещи встречаются - это
> мой любимый шелл, в нем есть много вкусного по сравнению с sh, и я об этом
> знаю), либо perl.
>
> Если я начну их публиковать, поддерживать или упаси бог, писать к ним маны,
> меня сообщество не поймет.
>

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

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB5932B...@gmail.com

[Artem Chuprina]

> Как обычно, "кто может, тому не надо". Собственно, мне программа с таким
> функционалом просто не нужна, поэтому я ее и пишу.

читать "и не пишу".

--
русская народная глупость
Кнышев

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87vcqyicfa.wl%r...@ran.pp.ru

[Artem Chuprina]

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

Судя по эффекту, ты не осознаешь, что это делает твою программу существенно
менее осмысленной. Поскольку она вроде как для безопасности, а безопасность
от этого сильно снижается. Чего б тогда прямо скриптам на php в командной
строке пароль не отдавать? :-)

> в скайпе например есть опция --pipelogin
> $ skype -h | grep pipe
> --pipelogin Command line login. "echo username password |
> skype --pipelogin"

Разницу между stdin и командной строкой понимаешь? У скайпа, обрати внимание,
не параметры командной строки, а пайп. Нет, конечно, в мире много людей,
которые поймут написанное буквально, и будут передавать ему username и
password в пайп через команду echo, чтобы засветить их если не в командной
строке скайпа, то хотя бы в командной строке echo.

> > Как обычно, "кто может, тому не надо". Собственно, мне программа с таким
> > функционалом просто не нужна, поэтому я ее и пишу.
> >
> > С другой стороны, когда мне нужна программа на 20 строк, я ее пишу, но не
> > публикую.
> >
> > zsh% ls ~/etc/bin|wc -l
> > 52
> > zsh% cat ~/etc/bin/*|wc -l
> > 944
> >
> > В смысле, у меня в ~/etc/bin, включенном в PATH, 52 программы. Суммарная их
> > длина - 944 строки. То есть, натурально, в среднем чуть меньше 20 строк на
> > программу. В норме это либо sh (иногда zsh-специфичные вещи встречаются - это
> > мой любимый шелл, в нем есть много вкусного по сравнению с sh, и я об этом
> > знаю), либо perl.
> >
> > Если я начну их публиковать, поддерживать или упаси бог, писать к ним маны,
> > меня сообщество не поймет.
> >
> А мне кажется что в репозитории дебиана существует много программ,
> которые поддерживают и пишут к ним маны,
> про которые можно сказать что они не нужные и что ту же работу можно
> сделать одной строкой перла или вообще поиграться опциями другой
> продвинутой проги.
> Но тем не менее их не исключают из репозитория, значит сообщество
> нейтрально реагирует на них.

Давайте добавим к ним еще одну плохую программу? У нас маловат размер
репозитория?

--
HTTP тоже не каждый дятел может сделать. Только дятлы об этом обычно не знают.
Victor Wagner в <b9td98$d8k$3...@wagner.wagner.home>

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87ty6iibm7.wl%r...@ran.pp.ru

[Sergey Stremidlo]

>>> Вообще-то тебе уже говорили, что так делать (в смысле, показывать пароль в
>>> командной строке), мягко говоря, несекьюрно.
>>>
>> и я ответил что осознаю это, что это для упрощения взаимодействия с
>> другими программами.
> Судя по эффекту, ты не осознаешь, что это делает твою программу существенно
> менее осмысленной. Поскольку она вроде как для безопасности, а безопасность
> от этого сильно снижается. Чего б тогда прямо скриптам на php в командной
> строке пароль не отдавать? :-)
>

пока я отлаживаю программу то лениво вручную забивать пароль каждый раз.
для отладки пользую CodeLite и в параметры проекта прописал опции
командной строки.
при выпуске программы в массовое пользование можно отключить опцию -p
ибо если запускать ./passman из командной строки то она потребует пароль
у пользователя,
а если запускать drugaya_proga | passman то запрос пароля уже будет из
перенаправленого stdin
и drugaya_proga выплюнув пароль в свой stdout попадет прямо в stdin
парольного менеджера.
Я понял опасность попадания пароля в хистори и засвета его в списке
процессов,
опцию -p сохраняю для наглядности и понимания откуда что идет.

>
>>> Как обычно, "кто может, тому не надо". Собственно, мне программа с таким
>>> функционалом просто не нужна, поэтому я ее и пишу.
>>>
>>> С другой стороны, когда мне нужна программа на 20 строк, я ее пишу, но не
>>> публикую.
>>>
>>> zsh% ls ~/etc/bin|wc -l
>>> 52
>>> zsh% cat ~/etc/bin/*|wc -l
>>> 944
>>>
>>> В смысле, у меня в ~/etc/bin, включенном в PATH, 52 программы. Суммарная их
>>> длина - 944 строки. То есть, натурально, в среднем чуть меньше 20 строк на
>>> программу. В норме это либо sh (иногда zsh-специфичные вещи встречаются - это
>>> мой любимый шелл, в нем есть много вкусного по сравнению с sh, и я об этом
>>> знаю), либо perl.
>>>
>>> Если я начну их публиковать, поддерживать или упаси бог, писать к ним маны,
>>> меня сообщество не поймет.
>>>
>> А мне кажется что в репозитории дебиана существует много программ,
>> которые поддерживают и пишут к ним маны,
>> про которые можно сказать что они не нужные и что ту же работу можно
>> сделать одной строкой перла или вообще поиграться опциями другой
>> продвинутой проги.
>> Но тем не менее их не исключают из репозитория, значит сообщество
>> нейтрально реагирует на них.
> Давайте добавим к ним еще одну плохую программу? У нас маловат размер
> репозитория?
>

а кто сказал что моя прога плохая? я ее еще не доделал чтобы можно было
судить.
а когда я выучу перл то тоже буду писать 10-строчные проги и от имени
сообщества авторитетно заявлять:
"что вы все время велосипеды изобретаете? неужели так трудно выучить
перл, ведь он может все!?
а не хотите учить перл и баш, то юзайте виндовс и не парьте нам мозг!"

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB5A0D6...@gmail.com

[Sergey Stremidlo]

>> да и мало ли зачем, это просто пример. Вся сила юникс в возможности
>> комбинации программ,
>> а диалоговый режим разрушает эту силу, поэтому все что не может работать
>> через командную
>> строку или stdin не круто.
> а, ну да, ну да. а это письмо, отправленное с @gmail.com вы тоже с
> командной строки послали? нет, а почему? это ж не круто.
>

не круто не то что я послал письмо не из командной строки,
а то что icedove из которого я послал письмо уже ни с чем не с интегрируешь,
я его даже свернутым запустить не могу, как-то его перекореживает опция
-turbo.
какой-то минимум опций у него есть, но со временем хочется чего-то более
мощного.
пробую переехать на claws-mail.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB5AA14...@gmail.com

[Artem Chuprina]

> >> да и мало ли зачем, это просто пример. Вся сила юникс в возможности
> >> комбинации программ,
> >> а диалоговый режим разрушает эту силу, поэтому все что не может работать
> >> через командную
> >> строку или stdin не круто.
> > а, ну да, ну да. а это письмо, отправленное с @gmail.com вы тоже с
> > командной строки послали? нет, а почему? это ж не круто.
> >
> не круто не то что я послал письмо не из командной строки,
> а то что icedove из которого я послал письмо уже ни с чем не с интегрируешь,
> я его даже свернутым запустить не могу, как-то его перекореживает опция
> -turbo.
> какой-то минимум опций у него есть, но со временем хочется чего-то более
> мощного.
> пробую переехать на claws-mail.

Вот если бы ты не пробовал, а решительно переезжал, и главное, не на
claws-mail, а на gnus, или еще круче mutt, в твои заявки про разрушающий всю
силу диалоговый режим еще как-то можно было поверить.

Нет, возможность работать без лишних вопросов к юзеру - великая сила. Но
ключевое слово здесь - не "вопросов", а "лишних". Ты бы сперва постоял на
плечах гигантов, в смысле, поучился бы тому, как это делают те, кто это делает
давно и успешно. Тот же ssh поизучай как следует. Не с точки зрения кодера,
а с точки зрения юзера. Вот уж кто действительно умеет работать без лишних
вопросов, причем как раз с обеспечением безопасности.

--
Пифагоровы штаны Лобачевскому смешны
-- <lj user=osd>

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87sjm2i6ws.wl%r...@ran.pp.ru

[Ivan Shmakov]

>>>>> Artem Chuprina <r...@ran.pp.ru> writes:

[…]

>> в скайпе например есть опция --pipelogin

>> $ skype -h | grep pipe
>> --pipelogin Command line login. "echo username password |
>> skype --pipelogin"

> Разницу между stdin и командной строкой понимаешь? У скайпа, обрати
> внимание, не параметры командной строки, а пайп. Нет, конечно, в
> мире много людей, которые поймут написанное буквально, и будут
> передавать ему username и password в пайп через команду echo, чтобы
> засветить их если не в командной строке скайпа, то хотя бы в
> командной строке echo.

Нет никакой командной строки echo [*]. Поскольку:

$ type echo
echo is a shell builtin
$

[…]

[*] При использовании GNU bash 4.1 из Debian 6.0, в настройках
по-умолчанию.

[Artem Chuprina]

> > Давайте добавим к ним еще одну плохую программу? У нас маловат размер
> > репозитория?
> >
> а кто сказал что моя прога плохая? я ее еще не доделал чтобы можно было
> судить.

Я сказал. Ты уже сказал достаточно, чтобы я мог судить.

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

Может быть, ты когда-нибудь тоже это узнаешь. И даже напишешь такой
менеджер. Но с тем, о чем ты говоришь сейчас, он не будет иметь ничего
общего.

--
Дело говоришь!
Теперь делай его.
Кнышев.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87r51mi6jp.wl%r...@ran.pp.ru

[Sergey Stremidlo]

06.11.2011 01:41, Artem Chuprina пишет:

> Вот если бы ты не пробовал, а решительно переезжал, и главное, не на
> claws-mail, а на gnus, или еще круче mutt, в твои заявки про разрушающий всю
> силу диалоговый режим еще как-то можно было поверить.
>

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

> Нет, возможность работать без лишних вопросов к юзеру - великая сила. Но
> ключевое слово здесь - не "вопросов", а "лишних". Ты бы сперва постоял на
> плечах гигантов, в смысле, поучился бы тому, как это делают те, кто это делает
> давно и успешно. Тот же ssh поизучай как следует. Не с точки зрения кодера,
> а с точки зрения юзера. Вот уж кто действительно умеет работать без лишних
> вопросов, причем как раз с обеспечением безопасности.
>

я и учусь когда сюда пишу, только почемуто все более язвительные ответы
получаю.
идея текстового хранения как раз от ssh и идет. (как легко удалить
строку с ключем который сменился)
помню раньше было видно ip-адреса в строчках, а сейчас нет - не палятся
управляемые сервера.
только я не пойму что я должен изучить еще с точки зрения юзера?

вот не знаю можно ли с одного компа на другой копировать строчки из
known_hosts,
хотя смысла в этом не вижу

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

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB5C919...@gmail.com

[Artem Chuprina]

> > Нет, возможность работать без лишних вопросов к юзеру - великая сила. Но
> > ключевое слово здесь - не "вопросов", а "лишних". Ты бы сперва постоял на
> > плечах гигантов, в смысле, поучился бы тому, как это делают те, кто это
> > делает давно и успешно. Тот же ssh поизучай как следует. Не с точки
> > зрения кодера, а с точки зрения юзера. Вот уж кто действительно умеет
> > работать без лишних вопросов, причем как раз с обеспечением безопасности.
> >
> я и учусь когда сюда пишу, только почемуто все более язвительные ответы
> получаю.
> идея текстового хранения как раз от ssh и идет. (как легко удалить
> строку с ключем который сменился)
> помню раньше было видно ip-адреса в строчках, а сейчас нет - не палятся
> управляемые сервера.

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

То есть тут, особенно во втором случае, мы видим довольно типичный для
применений криптографии случай, когда мера, с виду повышающая безопасность,
будучи применена не по делу, может ее, напротив, снизить. Это к вопросу о
твоей идее о втором пароле.

(Лирическое отступление: в безопасности хорошая двухкомпонентая авторизация -
там, где она действительно нужна - состоит из двух компонент разной природы:
то, что ты знаешь (пароль) и то, что ты имеешь (материальный предмет -
e-token, мобильный телефон, на который придет SMS). Наиболее яркий пример
такого рода - это банковские карты в сочетании со съемом денег из банкомата.
Необходимо предъявить саму карту и пин-код. Да, даже такая схема здесь
выполнена не вполне удачно и обходится - существуют устройства, которые
позволяют считать информацию с карты и снять пин-код с клавиатуры банкомата,
но они хотя бы есть, в отличие от взгляда через плечо, не у каждого второго, и
вообще сам факт их наличия или попытки приобрести - уже повод для подключения
полиции.)

> только я не пойму что я должен изучить еще с точки зрения юзера?

Но я больше хотел обратить твое внимание на богатство возможностей ssh по
авторизации без лишних (но строго лишних) вопросов - авторизация по ключу и
ssh-agent в различных сочетаниях. Причем именно на богатство вариантов -
когда можно подобрать сочетание ровно под свою комбинацию
безопасности-работоспособности. Где-то это будет незапароленный ключ, но
право выполнить ровно одну конкретную команду, где-то запароленный, ssh-agent
при логине, и право выполнить любую команду, а где-то - отдельный ключ,
загружаемый в агент (тоже в норме отдельный) ровно на сеанс бэкапа _и_ право
выполнить ровно одну команду по этому ключу.

> вот не знаю можно ли с одного компа на другой копировать строчки из
> known_hosts,
> хотя смысла в этом не вижу

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

> убунта видимо сильно спасает дебиан со своими ppa, а то бы невидать ему
> такой популярности

А по-моему, наоборот. Это убунта катается на дебиане - когда тебе чего-то не
хватает в убунте, ты ставишь это себе из дебиана.

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

Этот порог вхождения обеспечивает некоторое качество результата. Тот факт,
что дебианом можно пользоваться без особого страха, что половиной программ
пользоваться вообще нельзя, причем которой - заранее непонятно.

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

--
User Guide:
Тыц "ПЫЩЬ" button!

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87pqh5iwb5.wl%r...@ran.pp.ru

[Artem Chuprina]

> >> в скайпе например есть опция --pipelogin
>
> >> $ skype -h | grep pipe
> >> --pipelogin Command line login. "echo username password |
> >> skype --pipelogin"
>
> > Разницу между stdin и командной строкой понимаешь? У скайпа, обрати
> > внимание, не параметры командной строки, а пайп. Нет, конечно, в
> > мире много людей, которые поймут написанное буквально, и будут
> > передавать ему username и password в пайп через команду echo, чтобы
> > засветить их если не в командной строке скайпа, то хотя бы в
> > командной строке echo.
>
> Нет никакой командной строки echo [*]. Поскольку:
>
> $ type echo
> echo is a shell builtin
> $
>
> […]
>
> [*] При использовании GNU bash 4.1 из Debian 6.0, в настройках
> по-умолчанию.

Обращу внимание, что /bin/sh в Debian 6.0, если что, по умолчанию dash. Там,
правда, echo тоже builtin, но это отнюдь не значит, что любое употребление
echo будет употребля builtin.

Но.

zsh% bash
ran@wizzle:~/.keepass$ echo abrakadabra
abrakadabra
ran@wizzle:~/.keepass$ exit
zsh% grep abrakadabra ~/.bash_history
echo abrakadabra

Так что насчет "никакой командной строки" сэр малость погорячился. Может
быть, оно не засветится в выводе ps, но на диске оно, как видим, прикопалось
просто на ура. И главное, надолго (с учетом бэкапа так очень надолго), что
справедливо считается более серьезной угрозой.

--
Кто первый встал, того и грабли
Д. Белявский

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87obwpivwo.wl%r...@ran.pp.ru

[Ivan Shmakov]

>>>>> Artem Chuprina <r...@ran.pp.ru> writes:

[…]

>> Нет никакой командной строки echo [*]. Поскольку:

>> $ type echo
>> echo is a shell builtin
>> $

>> [*] При использовании GNU bash 4.1 из Debian 6.0, в настройках
>> по-умолчанию.

> Обращу внимание, что /bin/sh в Debian 6.0, если что, по умолчанию
> dash.

Речь, помниться, была об интерактивном использовании? Так Shell
по-умолчанию для passwd(5) все одно /bin/bash:

--cut: adduser_3.113_all/usr/share/man/man5/adduser.conf.5.gz --
DSHELL
The login shell to be used for all new users. Defaults
to /bin/bash.
--cut: adduser_3.113_all/usr/share/man/man5/adduser.conf.5.gz --

[…]

> zsh% grep abrakadabra ~/.bash_history
> echo abrakadabra

> Так что насчет "никакой командной строки" сэр малость погорячился.
> Может быть, оно не засветится в выводе ps, но на диске оно, как
> видим, прикопалось просто на ура. И главное, надолго (с учетом
> бэкапа так очень надолго), что справедливо считается более серьезной
> угрозой.

Не спорю.

[Sergey Stremidlo]

06.11.2011 10:45, Artem Chuprina пишет:

> А ты обратил внимание, что это отключаемо? Потому что так да, безопаснее, но
> менее удобно.

да, гибкость это тоже одна из великих штук которые обычно вкладываются в
*nix программы.
я пока делаю в начале каждой строки "1" чтобы потом дальше развивать
алгоритм
и ставить "2" - мол другой способ используется тут.

> В результате мне нужно только
> один раз позвонить голосом хозяину хоста и сравнить увиденный fingerprint с
> тем, что на самом деле.

теперь буду знать где оно пригодится

> А по-моему, наоборот. Это убунта катается на дебиане - когда тебе чего-то не
> хватает в убунте, ты ставишь это себе из дебиана.

я на убунте год наверно просидел или полтора, начало доставать каждые
полгода решать проблемы,
только последнюю рану зализал и тут на - новый дистрибутив и снова куча
проблем после обновления.
поэтому выбрал выбрал дебиан, причем aptosid :)

> Этот порог вхождения обеспечивает некоторое качество результата. Тот факт,
> что дебианом можно пользоваться без особого страха, что половиной программ
> пользоваться вообще нельзя, причем которой - заранее непонятно.

не понял второе предложение.
и кстати про качество, почемуто такое ощущение что sid менее расшатан
чем testing

> Ибо "помочь" - это сделать не то, что кажется помощью тому, кто помогает, а
> то, что считает помощью тот, кому помогают.

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

поэтому не буду писать сюда и беспокоить народ пока не доделаю прогу до
конца, а там будет видно, нужна она или нет.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4EB6620...@gmail.com

[Artem Chuprina]

> >> Нет никакой командной строки echo [*]. Поскольку:
>
> >> $ type echo
> >> echo is a shell builtin
> >> $
>
> >> [*] При использовании GNU bash 4.1 из Debian 6.0, в настройках
> >> по-умолчанию.
>
> > Обращу внимание, что /bin/sh в Debian 6.0, если что, по умолчанию
> > dash.
>
> Речь, помниться, была об интерактивном использовании?

Одна из целей оригинального автора - иметь возможность молчать отдать пароль
из скрипта. И обсуждается как раз эта ветка функциональности. Так что о
неинтерактивном в этом месте тоже не следует забывать.

--
Think of C++ as an object-oriented assembly language.
-- Bruce Hoult (br...@hoult.actrix.gen.nz)

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87ipmxicst.wl%r...@ran.pp.ru

[Artem Chuprina]

> > Этот порог вхождения обеспечивает некоторое качество результата. Тот факт,
> > что дебианом можно пользоваться без особого страха, что половиной программ
> > пользоваться вообще нельзя, причем которой - заранее непонятно.
> не понял второе предложение.

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

> и кстати про качество, почемуто такое ощущение что sid менее расшатан
> чем testing

Ну, не знаю, мой опыт ближе к обратному. Вообще, если я правильно понимаю
техническую политику и если она не менялась в последние несколько лет, то
testing до момента freeze - это по определению внутренне непротиворечивая
версия sid с небольшим отставанием по времени. Типа пакет попадает в testing
автоматически, если он пролежал в sid неделю и не ломает зависимостей внутри
testing. Но иногда бывает, что из-за второго условия в testing на некоторое
время застревает пакет неудачной версии или сборки.

--
Реляционная база данных - это не единственный способ сделать дурацкий поиск.
Victor Wagner

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87k47dicwp.wl%r...@ran.pp.ru

[Andrey Rahmatullin]

On Sat, Nov 05, 2011 at 06:49:54PM +0400, Sergey Stremidlo wrote:
> Мне понравилось недавнее нововведение у гугла - двухэтапное
> подтверждение, но не то что высылается смс на телефон, а то что
> приложения для доступа получают вместо паролей какието хеши, которые
> могут быть анулированы.

Какие ж это "хеши, которые могут быть анулированы", обычные генереные
пароли из 16 alphanumeric символов. Думаю, они тупо хранятся в аккаунте
одним списком, из которого их можно удалять по одному.

--
WBR, wRAR

[Andrey Rahmatullin]

On Sun, Nov 06, 2011 at 05:44:06PM +0400, Artem Chuprina wrote:
> > и кстати про качество, почемуто такое ощущение что sid менее расшатан
> > чем testing
> Ну, не знаю, мой опыт ближе к обратному. Вообще, если я правильно понимаю
> техническую политику и если она не менялась в последние несколько лет, то
> testing до момента freeze - это по определению внутренне непротиворечивая
> версия sid с небольшим отставанием по времени. Типа пакет попадает в testing
> автоматически, если он пролежал в sid неделю и не ломает зависимостей внутри
> testing. Но иногда бывает, что из-за второго условия в testing на некоторое
> время застревает пакет неудачной версии или сборки.

Из последних итераций обсуждения CUT/rolling я понял, что Основная
Проблема Тестинга по мнению пользователей - "оттуда пакеты пропадают".
Поскольку тестинг - это будущий стейбл, а не то, что можно использовать
постоянно, для починки его общего состояния допустимо ломать вплоть до
удаления отдельно взятые пакеты.

--
WBR, wRAR

[Alex Shulgin]

2011/11/6 Sergey Stremidlo <sere...@gmail.com>:

>
> поэтому не буду писать сюда и беспокоить народ пока не доделаю прогу до
> конца, а там будет видно, нужна она или нет.

По-моему, это первое разумное предложение с Вашей стороны.

Удачи, увидимся когда прога будет готова :)