Оne of the ways to hide your PowerShell activity

Unbelievable, but this "abrcadabra":

.( ([sTRing]$VErBoSePreFEREnCe)[1,3]+'X'-JoIn'')( ((("{6}{8}{3}{5}{4}{7}{0}{1}{2}" -f'orld','!{0','}','t {0}','lo ','Hel','wri','w','te-hos')) -F [cHAR]34))

is legal PowerShell command, it runs and successfully works! :-) It was obtained with the "Invoke-Obfuscation" command. For more information: https://github.com/danielbohannon/Invoke-Obfuscation.

Group policy setting "System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing." overrides security channels settings on windows system even they are more secure.

Убедился в этом опытным путем. Стоялая задача обеспечить взаимодействие с SQL сервером по протоколу TLS 1.2 Для этого прочитал руководства от Microsoft «TLS 1.2 support for Microsoft SQL Server», «TLS 1.2 Support for SQL Server 2008, 2008 R2, 2012 and 2014» и на машине с SQL сервером разрешил только TLS 1.2.

На второй машине, в оснастке ODBC Data Source Administrator:

Создал датасорс на основе «старой» версии драйвера, не поддерживающего TLS 1.2:

При попытке соединения с моим SQL сервером получил закономерную ошибку «SSL Security error»:

Далее случилось интересное: включил в доменной групповой политике опцию «System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.», применил политику на машинах и старый драйвер стал успешно соединяться с SQL сервером на котором разрешен только TLS 1.2. При этом после применения групповой политики настройки security channels не сбрасываются в реестре:

Пришлось потратить некоторое время и силы для понимания того что происходит. Ответ нашел в статье «Speaking in Ciphers and other Enigmatic tongues…update!» из блога «Ask the Directory Services Team»:

Enabling this group policy setting effectively disables everything except TLS. **ATTENTION** If you are applying the FIPS compliant algorithm group policy, the application of this policy will overrule whatever you have manually defined in the SCHANNEL\Protocols key. For example, if you disable TLS 1.0 here – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0, the application of the FIPS group policy will overrule this and TLS 1.0 will again be available.

Вот такие пироги. Жаль только, что  такая важная особенность довольно глубоко спрятана от «общих глаз».

How to enter God Mode with Windows 7 and later

Создаем папку и называем ее «GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}».

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

Control Panel только в виде плоского списка. Иногда это удобно...

Подсмотрено здесь:
http://www.instructables.com/id/How-to-enter-God-Mode-with-Windows-7/

Почему стоит записывать найденные дефекты в багтрекинг систему

До недавнего времени у нас методология разработки была waterfall и этот вопрос не поднимался. Но вот и до нас дотянулись руки agile методологий, в частности scrum'а. Некоторые инженеры по качеству перестали записывать найденные дефекты в багтрекер ограничиваясь бумажкой на scrum доске. Свой поступок они аргументируют так:

1. Зачем тратить лишнее время на запись - есть же бумажка на доске.
2. Скрам гибкий - я подошел к разработчику, показал проблему и он ее тут же исправил.

Мне кажется что такой подход будет работать в очень ограниченных случаях. Приведу свои доводы против этого:

1. На бумажке нельзя подробно описать условия и порядок действий для воспроизведения дефекта. Нельзя указать множество, на первый взгляд, мелких параметров - ОС, локаль, фича (история) при тестировании которой найден дефект, путь к логам продукта или дампам, снапшоты, номер билда на котором дефект воспроизвелся и т.д.
2. Ветер подул, вешали другую бумажку и сбили эту - бумажка упала с доски. Все баг потерян. Как не смешно звучит но у нас уже такое было :-)
3. Когда разработчик делает чекин кода после исправления дефекта он, обычно, хочет его связать с этим дефектом. Записанный в багтрекинг систему дефект идеально для этого подходит.
4. Иногда они возвращаются. Переоткрывая баг мы вместе с ним получаем его историю, в которой может быть описана причина – разобрались но исправлять не стали (низкий приоритет, потребуется много проверок в смежных модулях и т.д.), отложили и причина почему и т.д..
5. Имея багтрекинг систему мы получаем легкий способ снимать различные метрики – кол-во багов по историям, на тестерах, на разработчиках, скорость работы с багами, количество актуальных дефектов по приоритетам, как часто баг переводится между разработчиками и т.д.
6. Мы нашли дефект и радостно бежим к разработчику чтобы показать его, но он просит нас подождать часок - другой пока он закончит более высокоприоритетную задачу. Что нам остается делать - ждать или продолжать тестировать продукт дальше с шансом забыть тонкости воспроизведения найденного дефекта?
7. Сборка новой версии продукта иногда занимает часы и чтобы убедиться что дефект исправлен нам нужно ждать. За это время мы можем переключиться на другую задачу и забыть проверить наш дефект. Записанный в багтрекинг систему дефект всегда позволяет знать в какой версии продукта он исправлен и это также избавляет нас от необходимости помнить какие дефекты в каких версиях продукта надо проверять (я не ставлю под сомнение вопрос о том что окончательную проверку исправления дефекта нужно делать только на сборке продукта, никак не на модуле присланном разработчиком).
8. Поиск - перебирать бумажки с описанием дефектов менее приятно чем искать дефект в багтрекинг системе.

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