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

Сообщение **sash-kan** » 11.11.2011 10:19

/dev/random
не-не-не, ты это в скрипт помести, как в примере!

p.s. в интерактивных bash-ах разных дистрибутивов вообще как-то странно ведут себя эти присвоения (особенно в вариации с/без добавки команды export)·

Сообщение **/dev/random** » 11.11.2011 10:28

sash-kan писал(а): ↑
11.11.2011 10:19
/dev/random
не-не-не, ты это в скрипт помести, как в примере!

p.s. в интерактивных bash-ах разных дистрибутивов вообще как-то странно ведут себя эти присвоения (особенно в вариации с/без добавки команды export)·

Код: Выделить всё

$ cat /tmp/test.lang; echo ---; bash /tmp/test.lang
#!/bin/bash
LANG=C
echo -n 'абв' | sed 's/./1/g' | wc -c
---
3

$ cat /tmp/test.lcall; echo ---; bash /tmp/test.lcall
#!/bin/bash
LC_ALL=C
echo -n 'абв' | sed 's/./1/g' | wc -c
---
6

Вообще, как я уже писал, по стандарту должно быть как у меня, и переопределение должно делаться через LC_ALL. Но если у тебя наоборот, то для надёжности впиши обе переменные.

Сообщение **sash-kan** » 11.11.2011 10:35

/dev/random
так·
а что по дефолту выдают у тебя:
$ locale
?
$ set | grep -E '^(LANG|LC_)'
?
$ env | grep -E '^(LANG|LC_)'
?

и какие версии bash и glibc?

Сообщение **sash-kan** » 11.11.2011 10:42

/dev/random писал(а): ↑
11.11.2011 10:28
Вообще, как я уже писал, по стандарту должно быть

согласно документации glibc: http://www.gnu.org/s/hello/manual/libc/Loc...cale-Categories
LC_ALL This is not an environment variable; it is only a macro that you can use with setlocale to set a single locale for all purposes. Setting this environment variable overwrites all selections by the other LC_* variables or LANG.
LANG If this environment variable is defined, its value specifies the locale to use for all purposes except as overridden by the variables above.

это с одной стороны·
а с другой:
LC_ALL This is not an environment variable; it is only a macro that you can use with setlocale to set a single locale for all purposes. Setting this environment variable overwrites all selections by the other LC_* variables or LANG.

где правда, брат? ©
видимо, правда в том, что та и другая взаимно переопределяют значения LC_*, и LC_CTYPE в частности (которая, по-моему, только одна и влияет на нужное мне поведение)·

Сообщение **sash-kan** » 11.11.2011 10:55

sash-kan писал(а): ↑
11.11.2011 10:42
видимо, правда в том, что та и другая взаимно переопределяют

правда, почему-то в твоей системе LANG работает явно не в соответствии с цитатой из документации·
разве что у тебя явно переопределены какие-то из LC_*·

Сообщение **/dev/random** » 11.11.2011 10:57

Стоп, до меня дошло. Я повторял команды по твоему образцу, не заметив, что в них нет export'а.

Установка (без ключевого слова export) экспортирует переменную в том и только в том случае, если она уже была экспортирована (возможно, с другим значением). Таким образом, и "LANG=...", и "LC_ALL=..." будут работать только в определённых, довольно специфичных обстоятельствах. Например, "LANG=..." - если экспортирован LANG, но не экспортирован ни один из LC_*

Попробуй _экспортировать_ LC_CTYPE и убедись, что после этого не будет работать ни один из тех двух способов.

Единственно правильный способ - это "export LC_ALL=...".

11.11.2011 11:54

sash-kan писал(а): ↑
10.11.2011 23:49
вижу нечто обратное:

А export LC_ALL Пушкин делать будет? :) LANG-то за тебя уже заэкспортили, поэтому работает, а вот LC_ALL — нет.

11.11.2011 12:00

sash-kan писал(а): ↑
11.11.2011 10:19
p.s. в интерактивных bash-ах разных дистрибутивов вообще как-то странно ведут себя эти присвоения (особенно в вариации с/без добавки команды export)·

Всё очень просто: экспортированные переменные shell передает в дочерние процессы, а не экспортированные — не передает. Если переменная экспортирована, то присвоение этой переменной не отменяет экспортированности.

sash-kan писал(а): ↑
11.11.2011 10:19
не-не-не, ты это в скрипт помести, как в примере!

Код: Выделить всё

#!/bin/sh

LC_ALL=C
export LC_ALL
locale

Shell

$ ./loc.sh
LANG=ru_RU.UTF-8
LANGUAGE=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
$ locale
LANG=ru_RU.UTF-8
LANGUAGE=
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME=en_US.UTF-8
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES=en_US.UTF-8
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

drBatty · Сообщение **drBatty** » 11.11.2011 13:35

sash-kan писал(а): ↑
11.11.2011 10:42
LC_CTYPE в частности (которая, по-моему, только одна и влияет на нужное мне поведение)·

да. Только она.

Сообщение **sash-kan** » 12.11.2011 22:51

написал даже пару скриптиков для теста: https://gist.github.com/1360811
и позапускал на разных машинах (результаты на той же странице)

смысл: проверить надёжность установки одной из локалей C, POSIX, en_US.utf8 с помощью одной из трёх переменных: LANG, LC_ALL, LC_CTYPE, с применением export или без него·

методика тестов:
в стартовом файле https://gist.github.com/1360811#file_alocaletest.bash для каждого отдельного теста сначала сбрасываются все locale-переменные, затем выполняется переданная параметром команда (варианты: "LANG=C", "export LANG=C" и т.д. — они в первом столбце перечислены)·
затем вызывается файл https://gist.github.com/1360811#file_atest.bash
в нём-то тест и происходит — выполняется переданная команда и вычисляется «длина» буквы "ф"·
если передана команда для установки utf, а «длина» получается равной двум, тест failed·
если передана команда для установки C/POSIX, а «длина» получается равной единице, тест failed·

сокращения в заголовках столбцов:
ALL=LC_ALL
CTYPE=LC_CTYPE
8=utf8
X=POSIX

Сообщение **sash-kan** » 12.11.2011 23:29

результаты всех выполненных тестов идентичны за одним исключением: https://gist.github.com/1360811#file_j
на этой машине переменные окружения, переданные скрипту, похоже, никакого влияния не оказывают·

что странно — установка LC_CTYPE не всегда помогает·

FlySnake · Сообщение **FlySnake** » 12.11.2011 23:55

[offtopic] Каким бы надёжным ни был пароль, терморектальный криптоанализ вскрывает его практически за постоянное время независимо от сложности [offtopic]

Сообщение **/dev/random** » 13.11.2011 01:52

sash-kan писал(а): ↑
12.11.2011 23:29
что странно — установка LC_CTYPE не всегда помогает·

Разумеется, не всегда. LC_ALL имеет самый высокий приоритет, и если она экспортирована, то остальные переменные, включая LC_CTYPE, игнорируются.

drBatty · Сообщение **drBatty** » 13.11.2011 05:23

FlySnake писал(а): ↑
12.11.2011 23:55
Каким бы надёжным ни был пароль, терморектальный криптоанализ вскрывает его практически за постоянное время независимо от сложности

GnuPG
Видите, под моей аватаркой GPG ID написан?
пишете

Код: Выделить всё

gpg --recv-key 4DFBD1D6

потом

Код: Выделить всё

gpg --encrypt --recipient drBatty

и шифруете так, что расшифровать вы не сможете. Даже с паяльником в заднице.

/dev/random писал(а): ↑
13.11.2011 01:52
Разумеется, не всегда. LC_ALL имеет самый высокий приоритет, и если она экспортирована, то остальные переменные, включая LC_CTYPE, игнорируются.

ИМХО в этом случае значение LC_CTYPE замещаются значением LC_ALL.

Сообщение **/dev/random** » 13.11.2011 07:14

drBatty писал(а): ↑
13.11.2011 05:23
и шифруете так, что расшифровать вы не сможете. Даже с паяльником в заднице.

Зато вы - сможете. Особенно с паяльником в заднице.

drBatty · Сообщение **drBatty** » 13.11.2011 07:44

/dev/random писал(а): ↑
13.11.2011 07:14
Зато вы - сможете. Особенно с паяльником в заднице.

это если меня найти, и если я не успел секретный ключ уничтожить.

Сообщение **sash-kan** » 13.11.2011 14:15

sash-kan писал(а): ↑
12.11.2011 23:29
результаты всех выполненных тестов идентичны за одним исключением: https://gist.github.com/1360811#file_j
на этой машине переменные окружения, переданные скрипту, похоже, никакого влияния не оказывают·

а этот момент знатоки никак прокомментировать не смогут?

p.s. drBatty
подписал ваш ключ своим (2B1F01C0) и отослал на keys.gnupg.net

drBatty · Сообщение **drBatty** » 13.11.2011 15:19

sash-kan писал(а): ↑
13.11.2011 14:15
подписал ваш ключ своим (2B1F01C0) и отослал на keys.gnupg.net

спасибо. А как ваш подписать? (не, я в курсе, но хотелось-бы сделать всё правильно, да и другим это будет полезно узнать ИМХО).

sash-kan писал(а): ↑
13.11.2011 14:15
а этот момент знатоки никак прокомментировать не смогут?

наверное это CentOS/RHEL - там что-то и у меня с этим глючило...

Nazyvaemykh · Сообщение **Nazyvaemykh** » 13.11.2011 15:29

FlySnake писал(а): ↑
12.11.2011 23:55
[offtopic] Каким бы надёжным ни был пароль, терморектальный криптоанализ вскрывает его практически за постоянное время независимо от сложности [offtopic]

Именно поэтому не стоит запоминать пароли. Записал на бумажку — а уничтожить клочок бумаги можно самыми подручными средствами.

13.11.2011 16:59

sash-kan писал(а): ↑
13.11.2011 14:15
а этот момент знатоки никак прокомментировать не смогут?

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

Shell

$ cat mylocaletest.sh
#!/bin/sh

locales="C POSIX en_US.UTF-8"
vars="LANG LC_CTYPE LC_ALL"

eval "$(env | sed -nr 's/^(LANG|LC_.*)=.*$/unset \1;/p')"

for v in $vars; do
  for l in $locales; do
    for e in "" export; do
      (
        eval "${e} ${v}=${l}"
        if ! sh "$(dirname "$0")/testscript.sh"; then
          echo "Failed with '${e} ${v}=${l}'"
        fi
      )
    done
  done
done
$ cat testscript.sh
#!/bin/sh

export LC_ALL=C
r=$(echo -n ф | sed 's/./1/g')
[ 11 = "$r" ]

УМВР

sash-kan писал(а): ↑
13.11.2011 14:15
p.s. drBatty
подписал ваш ключ своим (2B1F01C0) и отослал на keys.gnupg.net

Жуть. Не быть тебе в моей trust db.

drBatty писал(а): ↑
13.11.2011 15:19
А как ваш подписать?

Вам тоже.

Сообщение **sash-kan** » 13.11.2011 22:42

drBatty писал(а): ↑
13.11.2011 15:19
sash-kan писал(а): ↑
13.11.2011 14:15
а этот момент знатоки никак прокомментировать не смогут?

наверное это CentOS/RHEL - там что-то и у меня с этим глючило...

нет, это мандрива·

watashiwa_darede... писал(а): ↑
13.11.2011 16:59
Вот простой тест

это мы проходили…
в циклах у тебя просто накапливаются eval-ы·
мне же нужна была чистая картина·
«сложность» у меня, возможно, ещё ниже, если выкинуть код, рисующий табличку·

но вообще вопрос был к странному поведению одной из машин (файл j)·
у неё одной результаты отличаются·
вероятно, дело в слишком старых версиях bash/glibc·

Сообщение **sash-kan** » 13.11.2011 22:56

drBatty писал(а): ↑
13.11.2011 15:19
хотелось-бы сделать всё правильно

http://cryptnet.net/fdp/crypto/keysigning_....html#id2557964
есть и русский перевод·

p.s. я сначала прописываю степень trust-а ключу·
это делается с помощью "gpg --edit-key <keyid>", команда trust·
ну и там же, не отходя от кассы, подписываю (команда sign)·
потом команда save, и отправляю ключ: "gpg --send-key <keyid>"

watashiwa_darede... писал(а): ↑
13.11.2011 16:59
Не быть тебе в моей trust db.

поздняк метаться·
подписал и отослал ключ 4A643E4E

p.s. настали электронные времена, люди начинают доверять электронным адресам, а не только тёплым ламповым лицам…

13.11.2011 23:23

sash-kan писал(а): ↑
13.11.2011 22:42
в циклах у тебя просто накапливаются eval-ы·

Не накапливаются.

sash-kan писал(а): ↑
13.11.2011 22:42
вероятно, дело в слишком старых версиях bash/glibc·

Ты все-таки прогони мой тест. Если завершится без ошибок, то всё нормально.

sash-kan писал(а): ↑
13.11.2011 22:56
поздняк метаться·
подписал и отослал ключ 4A643E4E

Ну нет, не поздняк. В моей-то trust db вас с drBatty нет. И не будет именно по этой самой причине.

sash-kan писал(а): ↑
13.11.2011 22:56
p.s. настали электронные времена, люди начинают доверять электронным адресам, а не только тёплым ламповым лицам…

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

sash-kan писал(а): ↑
13.11.2011 22:56
это делается с помощью "gpg --edit-key <keyid>", команда trust·
ну и там же, не отходя от кассы, подписываю (команда sign)·

Для подписывания совершенно не обязательно делать trust. Более того, это совершенно, принципиально разные вещи. Т.е. если я с вами лично встречусь, то подписать ключ Сашкана я могу (но не drBatty), но trust он все равно у меня не будет.

drBatty · Сообщение **drBatty** » 14.11.2011 05:55

sash-kan
дык на команду sign мне пишет "подписать все?" а все подписывать я не хочу...

Сообщение **sash-kan** » 14.11.2011 05:55

watashiwa_darede... писал(а): ↑
13.11.2011 16:59
Вот простой тест, который тестирует ровно то, что тебе нужно

мой тест немного выходит за рамки «того, что мне нужно для ahappy»·
но твой вариант я тоже завтра (точнее, уже сегодня) прогоню на этом компьютере·
только как минимум ещё и с LC_ALL=en_US.utf8 во втором скрипте·
хотя там и с другими вариантами были отличия от остальных машин·
но это уже надо будет переиначивать твои скрипты·

watashiwa_darede... писал(а): ↑
13.11.2011 23:23
В моей-то trust db вас с drBatty нет. И не будет именно по этой самой причине.

вот я считаю, что получил подтверждение того, что ключ 4DFBD1D6 принадлежит некоему drBatty, по достаточно надёжному каналу·
а вот подтверждения того, что ключ 3B210778 принадлежит ему же, я не получал по столь же надёжному каналу·
также я считаю, что получил подтверждение того, что ключ 4A643E4E принадлежит некоему Watashiwa, по достаточно надёжному каналу·
а вот подтверждения того, что ключ 3C647875 принадлежит ему же, я не получал по столь же надёжному каналу (если память мне не изменяет)·
вот по этим причинам ключи 4DFBD1D6 и 4A643E4E мною подписаны (и для них даже выставлен уровень доверия marginally), а ключи 3B210778 и 3C647875 я подписывать не собираюсь — мало ли кто и зачем отправил их на кейсервер, где я их вижу·
и уровень доверия для них я выставил второй (i do NOT trust)·
и я совершенно не вижу причин, по которым ты не мог бы поступить аналогично (выставить первый или второй уровень доверия) со всеми ключами, в разумности суждений владельцев которых ты сомневаешься, ну и, естественно, не подписывать те ключи, подтверждение принадлежности которых поступило по недостатчно надёжному (с твоей точки зрения) каналу·

watashiwa_darede... писал(а): ↑
13.11.2011 23:23
Но даже если так, ты хоть одно подтверждение связи этого ключа с этим адресом получил?

ты имеешь в виду адрес электронной _почты_? который можно вписать любой и с ненулевой вероятностью такая подделка даже дойдёт до адресата?
нет, я получил (по достаточно надёжному с моей точки зрения каналу) подтверждение о том, что ключ 4A643E4E принадлежит некоему электронному персонажу, скрывающемуся на unixforum.org под ником watashiwa_daredeska·

watashiwa_darede... писал(а): ↑
13.11.2011 23:23
Для подписывания совершенно не обязательно делать trust.

вероятно, ты прав, просто мне лично так удобнее — чтоб «два раза не вставать»·

watashiwa_darede... писал(а): ↑
13.11.2011 23:23
но trust он все равно у меня не будет.

trust-ов много, зачем же зарекаться:
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately

Сообщение **sash-kan** » 14.11.2011 06:04

drBatty писал(а): ↑
14.11.2011 05:55
sash-kan
дык на команду sign мне пишет "подписать все?" а все подписывать я не хочу...

нужный uid можно выбрать командой "uid номер"·
возле выбранных появится звёздочка·
подписаны командой sign будут только выбранные·

drBatty · Сообщение **drBatty** » 14.11.2011 06:41

sash-kan
подписал и отправил 2B1F01C0 на pgp.mit.edu
ну и trust 3 поставил заодно.

sash-kan писал(а): ↑
14.11.2011 05:55
а вот подтверждения того, что ключ 3B210778 принадлежит ему же, я не получал по столь же надёжному каналу·

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

watashiwa_darede... писал(а): ↑
13.11.2011 23:23
Ну нет, не поздняк. В моей-то trust db вас с drBatty нет. И не будет именно по этой самой причине.

ну и зря. У меня trust db нужна для тех ID, которые я ручками проверил. У меня просто есть ещё несколько десятков ID, которые скачались автоматически, и им я естественно не могу никак доверять. В том числе и со степенью "доверия" 1.

watashiwa_darede... писал(а): ↑
13.11.2011 23:23
Доверять или не доверять можно чему-либо, обладающему свободой воли. Электронный адрес свободой воли не обладает — это все равно, что доверять квартире.

причём тут "адрес"? Сущность drBatty обладает свободой воли. Я гарантирую это!

Сообщение **sash-kan** » 14.11.2011 12:07

drBatty писал(а): ↑
14.11.2011 06:41
причём тут "адрес"? Сущность

это я неудачно выразился, чтоб слог выдержать·
да, вернее будет звучать так:
настали электронные времена, люди начинают доверять электронным персонажам, а не только тёплым ламповым лицам…

drBatty писал(а): ↑
14.11.2011 06:41
а этот ключ и не для людей

зачем же он опубликован?

Nazyvaemykh · Сообщение **Nazyvaemykh** » 14.11.2011 12:26

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

drBatty · Сообщение **drBatty** » 14.11.2011 12:46

sash-kan писал(а): ↑
14.11.2011 12:07
настали электронные времена, люди начинают доверять электронным персонажам, а не только тёплым ламповым лицам…

а что делать-то? Что мне теперь, к Патрегу лично ехать, что-бы Slackware получить?

sash-kan писал(а): ↑
14.11.2011 12:07
зачем же он опубликован?

ну например какому-либо скрипту приходит команда от меня. Как ему проверить, что команда действительно от меня? Он скачивает этот ключ, и проверяет.

unixforum.org

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

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль

Re: Надежный пароль