Comments 14
Ну и в чем правильность? Не понимаю что такое «аудит ключа», и почему пользователям приходится делать кучу ненужных действий. Ну была у них дыра, пофиксили же? Больше же никто не может добавить в чужой аккаунт свои ключи, к чему этот дополнительный геморрой?
К тому, что кто-то мог добавить до того, как дыру пофиксили.
Ну вот выключили бы текущие ключи, кому надо — включит. А они ввели какую-то сложную схему с аудитом и подтверждением по email.
Они так и сделали. Нет никакого «подтверждения по email».
Какой емейл? Вы о чём? В веб-интерфейсе просто «reject или approve».
— We are forcing an audit of all existing SSH keys
— Adding a new SSH key will now prompt for your password
— We will now email you any time a new SSH key is added to your account
— You now have access to a log of account changes in your Account Settings page
Ок, не подтверждение. Но остальные меры шизофренические. Имхо, как раз восхищаться нечем.
— Adding a new SSH key will now prompt for your password
— We will now email you any time a new SSH key is added to your account
— You now have access to a log of account changes in your Account Settings page
Ок, не подтверждение. Но остальные меры шизофренические. Имхо, как раз восхищаться нечем.
По списку:
* аудит обсудили.
* запрос пароля при добавлении ключа — разумная мера. Забытый компьютер, украденная кука и т.д. — и возможность «твори что хочешь». (Разумность сравнима с запросом старого пароля при установке нового).
* Отправка по почте уведомления о добавлении нового ключа. Что плохого?
* Журнал операций с ключами. Снова, что плохого?
* аудит обсудили.
* запрос пароля при добавлении ключа — разумная мера. Забытый компьютер, украденная кука и т.д. — и возможность «твори что хочешь». (Разумность сравнима с запросом старого пароля при установке нового).
* Отправка по почте уведомления о добавлении нового ключа. Что плохого?
* Журнал операций с ключами. Снова, что плохого?
Была дыра, когда злоумышленник мог добавить ключи. Дыру закрыли, а вот добавленные ключи могли остаться. И они требуют у всех пользователей проверить «свои» ключи. И не просто письмом «надо проверить», а явно запрещают пользоваться ключами до их подтверждения (по каждому ключу раздельно). Потому что у меня на гитхабе, например, всего 4 ключа. А могло бы быть и больше (по числу рабочих станций, за которыми я бываю). И среди этого множества может быть один, затесавшийся посторонний.
Ок, я не пишу ничего массивного и активно использующегося. А есть те, кто пишут. А если коммит будет «не от того»?
Ок, я не пишу ничего массивного и активно использующегося. А есть те, кто пишут. А если коммит будет «не от того»?
Гхм. Ну ведь в том же письме так и было написано: «Until you have approved your SSH keys, you will be unable to clone/pull/push your repositories over SSH»
Ну, вот и случай хороший пришёл старые ключики выкинуть оттуда, и интерфейс удобный для этого появился.
Правильно оно то правильно — только это правильно пока тебя лично не коснется, так сказать «общечеловеческое» правильно, по аналогии с «общечеловеческими ценностями.
А так ночной билд не собрался, в тестирование не ушел, в продакшен не вылился… со всеми вытекающими.
Так, что кое-кто бы предпочел чтобы письмо имело характер — через 6/12/24 часа ключи будут отключены, если хотите сейчас проверте и сделайте reject на ненужные и поставте галочку что не нужно отключат нужные.
А так ночной билд не собрался, в тестирование не ушел, в продакшен не вылился… со всеми вытекающими.
Так, что кое-кто бы предпочел чтобы письмо имело характер — через 6/12/24 часа ключи будут отключены, если хотите сейчас проверте и сделайте reject на ненужные и поставте галочку что не нужно отключат нужные.
Sign up to leave a comment.
Правильный подход к проблемам безопасности на github