winutils

Бинарные файлы Windows для версий Hadoop

Эти файлы созданы непосредственно из того же коммита git, который использовался для создания официальных выпусков ASF; они извлечены и собраны на виртуальной машине Windows, которая предназначена исключительно для тестирования приложений Hadoop/YARN в Windows. Это не повседневная используемая система, поэтому она изолирована от атак безопасности drive-by/email.

Безопасность: можно ли доверять этому выпуску?

1. Я являюсь коммиттером Hadoop «stevel»: мне нечего выиграть, создавая вредоносные версии этих двоичных файлов. Если бы я хотел запустить что-то на ваших системах, я мог бы добавить код в сам Hadoop.
2. Я подписываю выпуски.
3. Мои ключи опубликованы в списке ключей коммиттеров ASF под моим именем пользователя.
4. Последний ключ GPG (E7E4 26DF 6228 1B63 D679 6A81 950C C3E0 32B7 9CA2) фактически находится на yubikey для физической безопасности; подписание происходит там.
5. Тот же открытый ключ используется для двухфакторной аутентификации на github, для загрузки артефактов и выпуска.

Злоумышленнику потребуется физический доступ к моему офису, чтобы подписать артефакты под моим именем. Если они смогут это сделать, они смогут внести вредоносный код в сам Hadoop, даже подписав эти коммиты тем же ключом GPG. Хотя им понадобится пин-код, чтобы разблокировать ключ, который я должен вводить всякий раз, когда ноутбук просыпается и я хочу что-то подписать. Это потребует установки чего-либо вредоносного на мою машину или перехвата пакетов Bluetooth с клавиатуры на ноутбук. Если кто-то получит физический доступ к моей машине, он, вероятно, сможет установить вредоносную версию git, которая модифицирует код перед регистрацией. На самом деле я не проверяю свои патчи на предмет вмешательства, но мы стараемся следить за тем, что вносят наши коллеги.

Другой тактикой было бы, если бы вредоносный yubikey оказался доставлен Amazon ко мне домой. У меня нет никакой защиты от того, кто пойдёт на такой уровень усилий.

Обновление от 2017-12 Этот ключ был отозван, хотя на самом деле он никогда не был скомпрометирован. Отсутствие случайности в генераторе простых чисел на yubikey, следовательно, экстренное аннулирование сеанса. Не настроил всё должным образом снова.

Примечание: Артефакты до Hadoop 2.8.0-RC3 [были подписаны другим ключом](https://pgp.mit.edu/pks/lookup?op=vindex&search=0xA92454F9174786B4; опять же, в списке ключей ASF.

Процесс сборки

Для сборки и тестирования артефактов стека Hadoop используется выделенная виртуальная машина Windows Server 2012. Она не используется ни для чего другого.

Используется настройка сборки VS от 2010 года; версия компилятора и компоновщика: 16.00.30319.01 для x64

>CL
Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.````

>LINK /VERSION
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  Все права защищены.

Использовался Maven 3.3.9; подпись проверена как принадлежащая Jason@maven.org. Хотя мой список ключей напрямую не доверяет этой подписи, я доверяю подписям других подписантов:

https://pgp.mit.edu/pks/lookup?op=vindex&search=0xC7BF26D0BB617866

C:\Work\hadoop-trunk>mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
Maven home: C:\apps\maven\bin\..
Java version: 1.8.0_74,   vendor: Oracle Corporation
Java home: c:\java\jdk8\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows server 2012 r2", version: "6.3", arch: "amd64", family: "dos"
Сборка основана на инструкциях в BUILDING.TXT Hadoop.

Java 1.8:

>java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

процесс выпуска

Windows VM

В hadoop-trunk

Версия для сборки проверяется по объявленной контрольной сумме SHA1 выпуска/RC, надеюсь перейти к подписанным тегам, как только подписание станет более распространённым.

Сборка была выполнена, полагаясь на тот факт, что Профиль native-win автоматически активируется в Windows:

mvn clean package -DskipTests -Pdist  -Dmaven.javadoc.skip=true 

Это создаёт дистрибутив с нативными двоичными файлами в папке hadoop-dist\target\hadoop-X.Y.Z\bin

set VERSION=hadoop-2.8.3
cd winutils
mkdir %VERSION%
mkdir %VERSION%\bin
cd ..
copy trunk\hadoop-dist\target\%VERSION%\bin winutils\%VERSION%\bin
cd winutils
rm %VERSION%\bin\*.pdb
git add %VERSION%
git commit -m "Windows binaries for %VERSION%"
git push

Создайте zip-файл, содержащий содержимое папки winutils\%VERSION%. Это делается на машине с Windows, чтобы избежать риска изменения файлов с окончанием строки Windows с помощью git. Это не фиксируется в git, а просто копируется на хост-машину через подключённый файловый ресурс.

Хост-машина: подписывание всего

Загрузите только что добавленные файлы из GitHub, затем подпишите двоичные файлы и отправьте обратно подписи .asc.

Нет способа подписать несколько файлов в gpg2 в командной строке, поэтому либо напишите цикл в bash, либо просто отредактируйте строку и позвольте автозавершению пути упростить вашу жизнь. Вот список команд для подписи:

gpg --armor --detach-sign hadoop.dll
gpg --armor --detach-sign hadoop.exp
gpg --armor --detach-sign hadoop.lib
gpg --armor --detach-sign hadoop.pdb
gpg --armor --detach-sign hdfs.dll
gpg --armor --detach-sign hdfs.exp
gpg --armor --detach-sign hdfs.lib
gpg --armor --detach-sign hdfs.pdb 
gpg --armor --detach-sign libwinutils.lib 
gpg --armor --detach-sign winutils.exe
gpg --armor --detach-sign winutils.pdb

Проверьте существование файлов, затем

git add *.asc
git status
git commit -S -m "sign Hadoop artifacts"
git push

Затем перейдите в каталог с zip-файлом и также подпишите этот файл:

gpg --armor --detach-sign hadoop-2.8.0.zip 

GitHub, создание релиза

1. Перейдите в репозиторий GitHub
2. Убедитесь, что виден самый последний коммит
3. Создайте новый релиз
4. Отметьте релиз версией hadoop и включите контрольную сумму коммита, использованную для сборки
5. Добавьте файлы .zip и .zip.asc как двоичные артефакты