Новая стабильная версия GnuPG 1.4.16.

Что нового What's New

 =========== *
Fixed the RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis attack as described by Genkin, Shamir, and Tromer. See . [CVE-2013-4576]

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

* Put only the major version number by default into armored output. 

(по умолчанию теперь в текстовом выхлопе пишется только "Version: GnuPG v1", раньше писалось полная версия, например "Version: GnuPG v1.4.14 (GNU/Linux)") 

* Do not create a trustdb file if --trust-model=always is used. 

(не создаётся файл с моделью доверий, если доверия используются всегда) 

* Print the keyid for key packets with --list-packets. 

(отладочная функция --list-packets теперь выводит id ключей. Примером может послужить например пакет из slackware: gpg --list-packets gnupg-1.4.16-i486-1.txz.asc. Фича полезная, т.к. я не в курсе был, как можно узнать, чем и для кого зашифрован файл) 

* Changed modular exponentiation algorithm to recover from a small performance loss due to a change in 1.4.14. 

 (изменился алгоритм возведения в степень для небольшого увеличения производительности) 


Источник: http://lists.gnupg.org/pipermail/gnupg-announce/2013q4/000337.html

bash скрипт для поиска самых больших установленных пакетов в Slackware

#/bin/bash

TMP=$(mktemp)

COUNT=0
for PKG in /var/log/packages/*; do
 SIZE_PKG=$(sed -rn 's/^UNCOMPRESSED PACKAGE SIZE:\s+(\S+)\s*$/\1/p' $PKG)
 M=1
 if [ "${SIZE_PKG%K}" != "$SIZE_PKG" ]; then
  SIZE_PKG="${SIZE_PKG%K}"
  M=1024
 elif [ "${SIZE_PKG%M}" != "$SIZE_PKG" ]; then
  SIZE_PKG="${SIZE_PKG%M}"
  M=1048576
 fi
 if [ "${SIZE_PKG%.*}" != "$SIZE_PKG" ]; then
  CA=0
  if [ "${SIZE_PKG%.[56789]*}" != "$SIZE_PKG" ]; then
   CA=1
  fi
  SIZE_PKG="${SIZE_PKG%.*}"
  (( SIZE_PKG += CA ))
 fi
 (( SIZE_PKG *= M ))
 DESCRIPTION=$(sed -rn '
  /^PACKAGE DESCRIPTION:$/{
   n
   p
  }' $PKG)

 echo -e "$SIZE_PKG\t${PKG##*/}\t$DESCRIPTION"
 echo -e "$SIZE_PKG\t${PKG##*/}\t$DESCRIPTION" >>$TMP
 (( COUNT++ ))
 if (( COUNT > 10 )); then
  #break;
  :
 fi
done

echo "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++"

sort -n $TMP


rm --force $TMP

Почему нельзя класть телефон на холодильник?

Действительно? Почему?

Вот что пишут на UFO:

1. Когда давно, были магнитные кассеты. От холодильника они реально могли размагнититься.
2. Существует ЭМИ, который может нарушить работу полупроводниковой техники. От холодильника ничего сравнимого по мощности/частоте нет, но есть люди с клинической перестраховкой.
3. Холодильник высокий, вероятность разбиться мобилке выше, чем падая со стола или тумбочки.

http://unixforum.org/index.php?showtopic=135736&view=findpost&p=1250001

Я сейчас проверил данный вопрос, ВНЕЗАПНО выяснился ещё один отрицательный момент: мой холодильник "новый", но на самом деле, ему уже скоро год. Там ТОЛСТЫЙ слой пыли!

Права доступа в Linux

прыг, ласточка прыг, прямо на двор...
Прыг, ласточка прыг, а в лапках - топор
С одной стороны свет,
А другой стороны нет,

Значит всё как всегда,

Ну цитаты невозбранно взяты у нашего Поэта, а именно у козлобородого гуру, Бориса Гребенщикова. Да, ещё до того времени 
ну слово "время" зачёркнуто, ибо именно о нём и пойдёт сейчас речь.

Итак, здравствуйте, мои дорогие дяди и тёти.

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

Если вы поставили Linux, то знайте, ВНЕЗАПНО: это всё полная хуета, ВАШ Linux НИЧЕМ не лучше маздайной хуйни. Смиритесь с этим, и сделайте вдоль, дабы очистить генофонд планеты от своих не нужных генов.

Я думаю, после ТАКОГО вступления уже никого не осталось, но окромя тех параноиков, которые ДЕЙСТВИТЕЛЬНО решили себя защитить. Продолжим...

Прав доступа в маздае попросту НЕТ. Есть имитация, но я сегодня не буду писать про имитацию, и если вы позволите, на этом я и закончу данный абзац. (PS: если не позволите, пишите в комментах)

Итак. Права доступа в Linux определяются некими битами, которые закреплены за файлами. Давайте определимся, что же есть "файл"? Файлом, я называю некое хранилище информации, в коем можно держать ЧТО-ТО.

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

1.  право доступа по чтению для хозяина
2.  право доступа для МОДИФИКАЦИИ для хозяина
3.  право ИСПОЛЬЗОВАНИЯ для хозяина
4.  право чтения для группы
5.  право модификации для группы
6.  право использования для группы
7.  право чтения для всех
8.  право модификации для всех
9.  право использования для всех

Если с чтением всё понятно, то с модификацией стоит пояснить: под модификацией подразумевается ИЗМЕНЕНИЕ файлов. Т.е. сам файл остаётся как был, но его СОДЕРЖИМОЕ изменяется. ВАЖНО понимать, что хозяин файла при этом НЕ меняется. Т.е., если Вы разрешили модификацию для всех, то не обижайтесь, что ВСЕ этот файл как-то изменяют. Зачем? Ведь если разрешить создание копии, то можно ведь и сделать измененную копию?

Отдельно надо сказать про право ИСПОЛЬЗОВАНИЕ -- это право даёт возможность именно использования as is. Только для текстовых файлов это чтение, для любых других файлов это именно ИСПОЛЬЗОВАНИЕ, например для бинарных файлов это исполнение, а для каталогов это вход в каталог (т.е. чтение/модификация/использование файлов внутри этого каталога).

xattr-message

простой скрипт для создания заметок к файлам для файлового менеджера.

Использует xattr

http://code.google.com/p/xattr-message/

Вступил в действие закон о запрете интернетов в сраной рашке

     Настоящий Федеральный  закон  вступает  в  силу  с  1  августа
2013 года.

Что ж,  господа, Здравствуй жопа новый год.

С сегодняшнего дня ЭТО уже наша новая реальность. ХYёвая, доложу я вам.

Вот полюбуйтесь на лурку.

Самое уродское заключается в том, что фильмы и музыку можно легко скачивать, и срали все пираты на этот ваш закон, закон касается исключительно ИНТЕРНЕТА, т.е. Сети с центральными узлами. Запретить так Kademlia невозможно, тупо потому, что у неё НЕТ никаких центральных узлов. В отличие скажем от этого(и ЛЮБОГО другого сайта). Не трудно догадаться, против кого направлен и будет действовать этот инструмент террора.


Остались мы без интернета,
Спасибо **** за это.

Настройка SSH

Мануал для настройки SSH.

http://emulek.ignorelist.com/forum/viewtopic.php?f=42&t=10734

в бложик такое плохо лезет.

Краткий учебник по sed

таки сделал.

Заходите, читайте.

http://emulek.tk/sed/

виртуальная клавиатура kvkbd и логин в linux

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

В силу того, что OS Slackware Linux, то я нагуглил слакобилд. Вот он:

#!/bin/sh
#-- kvkbd for Slackware --
# Build script by Phantom X 
# Suggested usage: $ kvkbd.SlackBuild 2>&1 | tee build.log
#--
# Copyright 2008, 2009, 2010, 2011 Phantom X, Goiania, Brazil.
# Copyright 2006 Martijn Dekker, Groningen, Netherlands.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR `AS IS'' AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

# http://www.kde-apps.org/content/show.php/Kvkbd?content=56019

PACKAGER_ID=${PACKAGER_ID:-$USER}
PACKAGER=${PACKAGER:-$USER@$HOSTNAME}

# Set YES for native build with gcc >= 4.2
SB_NATIVE=${SB_NATIVE:-NO}

# Set to YES to replicate slackbuild and patches
SB_REP=${SB_REP:-YES}

CWD=$(pwd)
TMP=${TMP:-/tmp}
if [ ! -d ${TMP} ]; then
  mkdir -p ${TMP}
fi

NAME=kvkbd
PKG=${PKG:-${TMP}/package-${NAME}}

VERSION=${VERSION:-0.6}
if [ "${SB_NATIVE}" = "YES" ] ;then
  ARCH=${ARCH:-$(uname -m)}
else
  ARCH=${ARCH:-x86_64}
fi
if [ "${ARCH}" = "x86_64" ] ;then
  SLKTARGET=${SLKTARGET:-x86_64}
else
  SLKTARGET=${SLKTARGET:-i486}
fi
SLKDTARGET=${SLKDTARGET:-slackware}
BUILD=${BUILD:-1}
NJOBS=${NJOBS:-$(( $(getconf _NPROCESSORS_ONLN) + 1 ))}
DOCDIR=${PKG}/usr/doc/${NAME}-${VERSION}
SBDIR=${PKG}/usr/src/slackbuilds/kde-apps/${NAME}
PKGDEST=${PKGDEST:-${CWD}}
PKGFORMAT=${PKGFORMAT:-tgz}
PKGNAME=${NAME}-$(echo ${VERSION} | tr - . )-${ARCH}-${BUILD}${PACKAGER_ID}

DATE=$(LC_ALL=C date +%d-%b-%Y)

SRCDIR=${NAME}-${VERSION}
SRCARCHIVE=94374-${SRCDIR}.tar.bz2

DL_PROG=${DL_PROG:-wget}
DL_TO=${DL_TO:-5}
DL_OPTS=${DL_OPTS:-"--timeout=${DL_TO}"}
DL_URL="http://www.kde-apps.org/CONTENT/content-files/${SRCARCHIVE}"

# if source is not present, download in source rootdir if possible
test -r ${CWD}/${SRCARCHIVE} || ${DL_PROG} ${DL_OPTS} ${DL_URL} || exit 1

if [ "${SB_NATIVE}" = "YES" ] ;then
  SLKCFLAGS="-O2 -march=native -mtune=native -pipe"
  [ "${SB_ECFLAGS}" ] && SLKCFLAGS="${SLKCFLAGS} ${SB_ECFLAGS}"
else
  case "${ARCH}" in
    i[3-6]86) SLKCFLAGS="-O2 -march=${ARCH} -mtune=i686"
                 ;;
    x86_64) SLKCFLAGS="-O2 -fPIC"
                 ;;
    s390|*) SLKCFLAGS="-O2"
                 ;;
  esac
fi
if [ "${ARCH}" = "x86_64" ] ;then
  LIBDIRSUFFIX="64"
  SLKCFLAGS="${SLKCFLAGS} -fPIC"
else
  LIBDIRSUFFIX=""
fi

# Set the config option variables if they are not already set:
[ -r ../KDE.options ] && source ../KDE.options
[ -r /etc/profile.d/kde4.sh ] && source /etc/profile.d/kde4.sh

_kde4_prefix=${_kde4_prefix:-/usr}
_kde4_sysconfdir=${_kde4_sysconfdir:-/etc/kde}
_kde4_libdir=${_kde4_libdir:-/usr/lib${LIBDIRSUFFIX}}
_kde4_libexecdir=${_kde4_libexecdir:-/usr/libexec/kde4}
_kde4_datadir=${_kde4_datadir:-/usr/share}
_kde4_sharedir=${_kde4_sharedir:-/usr/share}
_kde4_iconsdir=${_kde4_iconsdir:-${_kde4_sharedir}/icons}
_kde4_configdir=${_kde4_configdir:-${_kde4_sharedir}/config}
_kde4_appsdir=${_kde4_appsdir:-${_kde4_sharedir}/kde4/apps}
_kde4_docdir=${_kde4_docdir:-${_kde4_prefix}/doc}
_kde4_bindir=${_kde4_bindir=:-${_kde4_prefix}/bin}
_kde4_sbindir=${_kde4_sbindir:-${_kde4_prefix}/sbin}
_kde4_includedir=${_kde4_includedir:-${_kde4_prefix}/include/kde4}
_kde4_buildtype=${_kde4_buildtype:-release}
_kde4_macros_api=${_kde4_macros_api:-2}

if [ -d ${PKG} ]; then
  # Clean up a previous build
  rm -rf ${PKG}
fi
mkdir -p ${PKG}

unset QTDIR QTINC QTLIB
export QTDIR=$(qmake-qt4 -query QT_INSTALL_PREFIX)
PATH="$(qmake-qt4 -query QT_INSTALL_BINS):${PATH}" ; export PATH

cd ${TMP}
rm -rf ${SRCDIR}
tar -xvf ${CWD}/${SRCARCHIVE} || exit 1
cd ${SRCDIR} || exit 1

chmod -R u+w,go+r-w,a-s .

# zcat ${CWD}/${NAME}.patch.gz | patch -p0 -E --backup --verbose || exit 1

export CFLAGS="${SLKCFLAGS}"
export CXXFLAGS="${SLKCFLAGS}"
export FFLAGS="${SLKCFLAGS}"

mkdir -p build
( cd build || exit 1

  cmake .. \
    -DCMAKE_EXE_LINKER_FLAGS="$CFLAGS -lX11" \
    -DCMAKE_INSTALL_PREFIX:PATH=${_kde4_prefix} \
    -DSYSCONF_INSTALL_DIR:PATH=${_kde4_sysconfdir} \
    -DINCLUDE_INSTALL_DIR:PATH=${_kde4_includedir} \
    -DLIB_INSTALL_DIR:PATH=${_kde4_libdir} \
    -DLIB_SUFFIX=${LIBDIRSUFFIX} \
    -DLIBEXEC_INSTALL_DIR:PATH=${_kde4_libexecdir} \
    -DDATA_INSTALL_DIR:PATH=${_kde4_appsdir} \
    -DMAN_INSTALL_DIR:PATH=/usr/man \
    -DCMAKE_BUILD_TYPE=${_kde4_buildtype} \
    -DBUILD_SHARED_LIBS:BOOL=ON \
    -DCMAKE_SKIP_RPATH:BOOL=ON \
    -DCMAKE_VERBOSE_MAKEFILE=ON \
    || exit 1

  make -j${NJOBS} || make || exit 1
  make install/fast DESTDIR=${PKG} || exit 1

) || exit 1

find ${PKG} | xargs file | grep -e "executable" -e "shared object" | grep ELF \
  | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

# Add a documentation directory:
mkdir -p ${DOCDIR}
cp -a \
  AUTHORS COPYING ChangeLog README TODO ${CWD}/ChangeLog.SB \
  ${DOCDIR}/
find ${DOCDIR}/ -type d -print0 | xargs -0 chmod 0755
find ${DOCDIR}/ -type f -print0 | xargs -0 chmod 0644

# Compress and link manpages, if any:
if [ -d ${PKG}/usr/share/man ]; then
  mv ${PKG}/usr/share/man ${PKG}/usr/man
  rmdir ${PKG}/usr/share
fi
if [ -d ${PKG}/usr/man ]; then
  ( cd ${PKG}/usr/man
    for manpagedir in $(find . -type d -name "man*") ; do
      ( cd ${manpagedir}
        for eachpage in $( find . -type l -maxdepth 1) ; do
          ln -s $( readlink ${eachpage} ).gz ${eachpage}.gz
          rm -f ${eachpage}
        done
        gzip -9 *.?
        # Prevent errors
        rm -f *.gz.gz
      )
    done
  )
fi

mkdir -p ${PKG}/install
cat ${CWD}/slack-desc > ${PKG}/install/slack-desc
cat ${CWD}/slack-required > ${PKG}/install/slack-required

sed -i "s|_PACKAGER|${PACKAGER}|g; s|_BUILD_DATE|${DATE}|g" \
       ${PKG}/install/slack-desc

if [ "${SB_REP}" = "YES" ] ;then
  # Replicate slackbuild and patches
  mkdir -p ${SBDIR}
  install -m0644 ${CWD}/slack-desc ${CWD}/slack-required ${CWD}/ChangeLog.SB \
                 ${SBDIR}/
  install -m0755 ${CWD}/${NAME}.SlackBuild \
                 ${SBDIR}/${NAME}.SlackBuild
fi

# Build package:
set +o xtrace # no longer print commands upon execution

ROOTCOMMANDS="set -o errexit -o xtrace ; cd ${PKG} ;
  /bin/chown --recursive root:root . ;"

ROOTCOMMANDS="${ROOTCOMMANDS}
  /sbin/makepkg --linkadd y --chown n ${PKGDEST}/${PKGNAME}.${PKGFORMAT} "

if test ${UID} = 0; then
  eval ${ROOTCOMMANDS}
  set +o xtrace
elif test "$(type -t fakeroot)" = 'file'; then
  echo -e "\e[1mEntering fakeroot environment.\e[0m"
  echo ${ROOTCOMMANDS} | fakeroot
else
  echo -e "\e[1mPlease enter your root password.\e[0m (Consider installing fakeroot.)"
  /bin/su -c "${ROOTCOMMANDS}"
fi

# Clean up the extra stuff:
if [ "$1" = "--cleanup" ]; then
  echo "Cleaning..."
  if [ -d ${TMP}/${SRCDIR} ]; then
    rm -rf ${TMP}/${SRCDIR} && echo "${TMP}/${SRCDIR} cleanup completed"
  fi
  if [ -d ${PKG} ]; then
    rm -rf ${PKG} && echo "${PKG} cleanup completed"
  fi
  rmdir ${TMP} && echo "${TMP} cleanup completed"
fi
exit 0

скрипт несколько исправлен:

1. ставится kvkbd (слакобилд можно нагуглить, но он сейчас сломан. Что-бы его починить, надо в опции cmake добавить -DCMAKE_EXE_LINKER_FLAGS="$CFLAGS -lX11", тогда собирается и работает, исправленный скрипт выше)

2. в /etc/kde/kdm/kdmrc меняется

-UseTheme=true
+UseTheme=false

3. в /etc/kde/kdm/Xsetup +/usr/bin/kvkbd --loginhelper &
тогда при логине и при перелогине включается клава, и даже набирается. Но вот если усыпить девайс, то хрен там :-( Срабатывает блокировка. Хоть свою пиши на zenity :-( (но там нужно кучу костылей, что-бы её невозможно было-бы вырубить без пароля).
Пока пришлось сделать беспарольный вход, но это меня расстраивает.

Связанная тема на ЛОРе http://www.linux.org.ru/forum/desktop/9379797

HOWTO: использование ЭЦП и шифрования на практике

Часть первая

Часть вторая

Использование ключей для шифрования и для подписи.

Напомню краткое содержание первой части: там мы разобрали вопрос полезности ключей, а также их генерации. ИМХО полезно составить небольшую шпаргалку:

# создание нового ключа
gpg --gen-key 
# создаёт новые ключ. Ещё раз напомню, что СЕКРЕТНЫЙ КЛЮЧ ДОЛЖЕН БЫТЬ СВОЙ У КАЖДОЙ СИСТЕМЫ.

# список ключей
gpg --list-keys
gpg --list-keys KID
# список ключей и их субключей. 
# NOTE: можно добавить параметр KID -- уникальный кусок чего-то от какого-нить ключа.
# К примеру, если у меня только одни ключ содержит XYZ в имени или в описании или в почтовом адресе,
# я могу добавить только XYZ, и gpg выведет только этот ключ. Это верно и для многих других команд.
# также можно использовать ID ключа -- уникальное шестнадцатеричное восьмизначное число,
# которое выводится в списке ключей и в других случаях (это последние цифры отпечатка ключа, см. ниже)

# редактирование ключа
gpg --edit-key KID
# (см. выше NOTE, верно и для KID)
# подробности ниже

# экспорт ключа
gpg --export KID
gpg --armor --export KID
# выводит ключ на стандартный вывод
# --armor нужен для вывода в текстовом виде(такое можно смело вставлять в любой текст)

# импорт
gpg --import
# добавление ключа(ключей) из стандартного ввода в в ваше кольцо (keyring).

# шифрование
gpg --encrypt --recipient KID FILENAME
# данная команда шифрует файл FILENAME для KID.
# создаётся новый файл с именем FILENAME.gpg
# который может прочитать только KID
# можно задать несколько реципиентов, в т.ч. и себя, если это например бекап
# допустимо использовать ключ --armor, тогда имя файла будет FILENAME.asc
# и файл будет годен для вставки в любой текст

# дешифровка
gpg --decrypt FILENAME.{asc,gpg}
# расшифровывает файл и отправляет его в ст. вывод(допустимо и в файл с --output)
# для расшифровки нужен секретный ключ одного из реципиентов.

# проверка подписи
gpg --verify FILENAME.{asc,gpg,sig}
# проверяет ЭЦП FILENAME
# подпись может содержаться в самом FILENAME.gpg или лежать отдельно в файле FILENAME.sig или в FILENAME.asc

# подпись файла
gpg --sign FILENAME
gpg --sign --detach-sign FILENAME
# подписывает файл FILENAME
# если использовать --detach-sign, то подпись будет в виде отдельного файла FILENAME.sig
# вместе с --detach-sign можно использовать --armor
# для подписания требуется Ваш секретный ключ

# комбинация шифрования и подписи
gpg --sign --encrypt --recipient KID FILENAME
# шифрование и подпись можно и нужно комбинировать.
# тогда ваш реципиент будет уверен в том, что файл не подделка
# проблема в том, что публичный ключ реципиента известен всем
# в т.ч. и злоумышленнику
# а значит он может просто подменить наше сообщение

К примеру, Алиса желает отправить сообщение Бобу. У них имеется незащищённое хранилище insecure_storage, пусть это будет обычный каталог, к которому смонтированно облако яндекс-диска. Т.о. если Алиса просто отправит туда message, то злоумышленник может его не только прочитать, но и изменить. На компьютере Алисы

cp message insecure_storage/

На компьютере Боба

cp insecure_storage/message .

Тем временем на компьютере КровавойГБни

cp insecure_storage/message .
vim message
# Вау!
cp message insecure_storage/message

т.о. в иттоге Боб получит перлюстрированное и исправленное message. ИЧСХ, даже об этом не узнает, а будет уверен, что это личное дело между ним и Алисой.  

Как избежать такой атаки?

Шаг №1: Алиса и Боб создают свои ключи, и отправляют их в insecure_storage. Создание ключей уже обсуждалось. Экспорт осуществляется ключом ---export, например на компьютере Алисы

Сначала экспортируем свой ключ

gpg --export Alice >insecure_storage/alice.key

Теперь забираем ключ Боба

gpg --import insecure_storage/bob.key

(очевидно, Боб должен сделать тоже самое)

Шаг №2
В принципе, теперь Алиса может смело шифровать своё message

gpg --sign --encrypt --recipient Bob message
cp message.gpg insecure_storage/

Но не всё так просто...

Кровавая ГБня может с лёгкостью подменить insecure_storage/alice.key на свой. В дальнейшем она может непрерывно отслеживать insecure_storage, и постоянно подменять там message от Алисы на  свои, подписанные фейковым ключом. Боб этого не заметит. Также Кровавая ГБня может подменить insecure_storage/bob.key, и потому Алиса будет шифровать не для Боба, а для Кровавой ГБни. Ей(ГБне) останется только вовремя удалить insecure_storage/message от Алисы, прочитать фейковым ключом якобы Боба, а потом подписать фейковым ключём якобы Алисы и зашифровать настоящим ключом Боба. При этом Боб никак НЕ узнает, что message прочитано, и при необходимости изменено.

Данная ситуация НЕ решается в данных условиях. Имея только insecure_storage наладить связь невозможно. К счастью, не всё так трагично. В нашем сегодняшнем мире циркулируют тысячи гигабайт мусора во всех направлениях, и отследить их все в принципе невозможно.

Единственное, что нужно Алисе -- доказать Бобу, что она, это ОНА, а вовсе не Кровавая ГБня. В качестве доказательства можно использовать третью сторону, но это не слишком безопасно и надёжно (Кровавая ГБня может отслеживать третью сторону, и с помощью ректального криптоанализа _может_ заставить её делать то, что велит Политика Партии).

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

$ gpg --fingerprint amilo
pub   2048R/6D300475 2013-07-18
Отпечаток ключа = E3A9 7C06 C734 B779 92D3  69B5 3494 1316 6D30 0475
uid                  drBatty (amilo key) 
sub   2048R/FFE32EF7 2013-07-18

(Отпечаток выделен)
Этот отпечаток НЕ является секретным. Передать его можно вместе с _любым_ мусором, к пример прицепив его к любой фотке, что-бы его было не так заметно, его можно преобразовать, к примеру посчитать его md5. Тут даже не нужна возможность обращения Бобом этой md5, ведь получив alice.key Боб тоже узнает отпечаток, и может самостоятельно вычислить его md5. Алисе нужно лишь отправить по какому-то другому каналу Бобу этот отпечаток в любом виде. А вот задача Кровавой ГБни существенно осложняется: ей придётся закопаться во ВЕСЬ мусор, который _может_ генерировать Алиса. И в онлайне, и даже IRL(Алиса _может_ написать fingerprint на использованной прокладке, и её выкинуть на какой-то помойке. Расковыряв прокладку Боб узнает отпечаток. Т.о. Кровавой ГБне придётся даже все алисины прокладки распотрошить)

Зная отпечаток ключа, Боб может подписать alice.key своей ЭЦП, дабы в будущем не мучаться, сверяя этот отпечаток. Вот пример подписывания ключа моего нетбука. Сейчас я нахожусь дома, за десктопом ksu, GPG ID: 3B210778. При этом ключ нетбука amilo, GPG ID: 6D300475.

$ gpg --edit-key amilo
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  2048R/6D300475  создан: 2013-07-18  годен до: неогранич   применяемость: SC  
                     доверие: полное  достоверность: полное
sub  2048R/FFE32EF7  создан: 2013-07-18  годен до: неогранич   применяемость: E   
[ полное ] (1). drBatty (amilo key) 

gpg> sign

pub  2048R/6D300475  создан: 2013-07-18  годен до: неогранич   применяемость: SC  
                     доверие: полное  достоверность: полное
 Отпечаток главного ключа: E3A9 7C06 C734 B779 92D3  69B5 3494 1316 6D30 0475

     drBatty (amilo key) 

Вы уверены, что хотите подписать этот ключ
своим ключом: "drBatty (ksu) " (3B210778)

Действительно подписать? (y/N)y

Необходим пароль для доступа к секретному ключу пользователя: "drBatty (ksu) "
2048-бит RSA ключ, ID 3B210778, создан 2011-04-02
здесь был пароль к ключу ksu
                             
gpg> quit
Сохранить изменения? (y/N)y

(выделено то, что я вбивал)

Note: здесь используются два ключа: один подписывается, а ВТОРЫМ подписывают. Второй ключ получается автоматически, это первый ключ в кольце, который имеет секретную часть. Если вам нужен другой ключ, то перед командой --sign нужно указать --default-key KID, указывающий на нужный секретный ключ.

Вот теперь проверять Боб может не только просто так. Если подпись Алисы не подписана Бобом(в смысле, публичный ключ Алисы, который есть у Боба, не подписан ключом Боба), он увидит предупреждение:

gpg: ВНИМАНИЕ: Данный ключ не заверен доверенной подписью!
gpg:          Нет указаний на то, что подпись принадлежит владельцу.
 Отпечаток главного ключа: ...

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

 Даже если мы работаем с двумя компьютерами, всё равно в ключах просто запутаться. Нужно поставить степень доверия ключу командой trust (она вводится тоже после gpg --edit-key KID).

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


 1 = Не знаю или не буду отвечать
 2 = Не доверяю
 3 = Доверяю ограниченно
 4 = Полностью доверяю
 5 = Абсолютно доверяю
 m = вернуться в главное меню

 Я использую абсолютную(5) степень доверия для локальных ключей, полную(4) для своих, и ограниченную(3) для чужих ключей.

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


Редактирование и удаление ключей

У каждого ключа есть свой uid(User ID), он создаётся автоматически. Но этих uid'ов может быть и более одного. Именно на uid, а вовсе не на сам ключ, и устанавливается подпись. Можно добавлять/удалять uid командами adduid/deluid, что-бы удалить uid надо его для начала выбрать, просто набрав его номер. А затем можно удалять командой deluid.

gpg> list

pub  2048R/BEC9B8A8  создан: 2013-07-19  годен до: 2014-07-19  применяемость: SC  
                     доверие: полное  достоверность: полное
sub  2048R/EFF1C7DB  создан: 2013-07-19  годен до: 2014-07-19  применяемость: E   
[ полное ] (1). emulek2 (test) 
[ полное ] (2)  emulek (autosign) 

gpg> 1

pub  2048R/BEC9B8A8  создан: 2013-07-19  годен до: 2014-07-19  применяемость: SC  
                     доверие: полное  достоверность: полное
sub  2048R/EFF1C7DB  создан: 2013-07-19  годен до: 2014-07-19  применяемость: E   
[ полное ] (1)* emulek2 (test) 
[ полное ] (2)  emulek (autosign) 

gpg> deluid
Вы действительно хотите удалить данный User ID? (y/N)y

pub  2048R/BEC9B8A8  создан: 2013-07-19  годен до: 2014-07-19  применяемость: SC  
                     доверие: полное  достоверность: полное
sub  2048R/EFF1C7DB  создан: 2013-07-19  годен до: 2014-07-19  применяемость: E   
[ полное ] (1)  emulek (autosign) 

Как видите, выбранный uid выделяется звёздочкой (*). Именно таким образом и "редактируется" ключ, если в желаете например сменить своё имя, или почтовый адрес.

Точкой "." обозначается последний добавленный uid, используемый по умолчанию.

Установка Slackware на флешку в f2fs

Тут у нас появилась неплохая новая ФС, которая f2fs, эта фс разработана специально для флешек. Кроме того, я тут нашёл старый нетбук типа amilo mini ui 3520

В этом чуде китайской инженерной мысли установлен HDD формфактора  1.8, который по слухам стучит с момента покупки. Ну факт в том, что оно у меня отстучало. Вместе с тормозной вендой, что там была в комплекте.

Ну по такому поводу я и задумал туда поставить слаку на флешке, благо текущая версия слаки содержит ядро 3.9.9-smp, которое без бубнов умеет f2fs.

Я хотел конечно отформатировать флешку целиком, но к сожалению у меня это не получилось, потому пришлось сделать два раздела:

1. /dev/sda1 /boot/ 118M /ext2/
2. /dev/sda2 / (rootfs) 7.2GB

(флешка объёмом 8Гб).

Хоть ядро и поддерживает f2fs, но вот к сожалению отформатировать-то и нечем. Я взял авторскую f2fs-tools (это ссылка на git репозиторий). Кроме того, я нагуглил и слакобилд. Собрав mkfs.f2fs, я уже смог отформатировать флешку в этой новой ФС.

Однако, ставил я слаку на другую флешку, отформатированную в ext4. Смонтировать просто так не получается, необходимо обязательно указывать тип ФС

mount -t f2fs /dev/sdb2 /mnt/x

Вот примерно так.

initrd

Естественно, у меня ничего не взлетело(кто-бы сомневался!), опыта в этой области у мну явно недостаточно. Впрочем, я разобрался: для загрузки ОС нужно несколько модулей, которые можно в принципе вкомпиллить в ядро. Но это не наш путь. Куда как разумнее создать маленький ramdisk прямо в памяти, откуда их и подключить. Связано это даже не с кривой ФС, а с тем, что флешки это вообще говоря совсем не простой HDD/SSD, хотя с виду и не отличимы (глядя изнутри компа).

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

1. ehci_hcd, ehci_pci -- USB2.0
2. hid, hid_generic, hidusb -- поддержка клавиатуры USB. У меня ещё и родная клава сломалась. Впрочем, если есть ГАРАНТИЯ, что всё будет хорошо, то эти модули мне не нужны. Однако, если всё будет плохо, я могу исправить, пользуясь внешней клавой.
3. loop тащем-то не нужен, но полезен при аварии -- монтировать разные образы.
4. usb_storage, usb_realtek -- это как раз та самая прокладка, которое делает из USB некое подобие HDD(точнее скази).

Собственно говоря, initrd представляет собой вполне готовый и годный Linux, можно уже пользоваться. Вот только девайсы никакие не подключены, даже носители. Если что-то пойдёт не так(а у меня таки так и вышло), мы вывалимся в консоль busybox, которая представляет собой кастрированный bash.

Но для начала нужно собрать этот initrd. Собирается он специальным скриптом mkinitrd. В принципе, нам нужно только знать, где у нас будет корневая система, когда мы будем в initrd. Ну и модули конечно(см. выше). Собирается initrd в chroot'е, т.е. в такой встроенной виртуальной машине. Вот как-то так:

# сначала монтируем будущий корень
mount -t f2fs /dev/sda2 /mnt/floppy

# теперь монтируем туда спец. систему proc из хозяйской машины
mount -t proc /proc /mnt/floppy/proc

# теперь монтируем загрузочный каталог
mount /dev/sda1 /mnt/floppy/boot

# переходим в новый корень
chroot /mnt/floppy

# и отсюда идём в загрузочный каталог
cd /boot

# теперь можно создавать промежуточную корневую систему initrd
mkinitrd -c -k 3.9.9-smp -m ehci_pci:ums_realtek:hid_generic:usbhid:loop:f2fs -f f2fs -r /dev/sda2 -w 5

Описание ключей:

• -c очистка прежнего корневого  дерева /boot/initrd-tree/
• -k 3.9.9-smp Задаёт версию ядра. Нужен для поиска в /lib/modules, именно оттуда будут браться модули в initrd. У меня атом вместо процессора, но за то там HT. Потому я беру вариант smp (естественно ядро должно соответствовать)
• -m Список модулей через двоеточие (см. выше)
• -f f2fs Тип ФС
• -r /dev/sda2 расположение корневой системы
• -w 5 Задержка перед монтированием. Флешки определяются не мгновенно(задержка в секундах, и у меня слишком много. Можно уменьшить в моём случае)

После успешного завершения mkinitrd необходимо исправить загрузчик

lilo

Загрузчик состоит из двух частей, первая часть древняя, и занимает всего один сектор в 512 байт. Вторая часть это то, что не влезло в первую. Я использую самый простой загрузчик lilo. Он настолько прост, что не понимает ни одной ФС. Фактически, он просто загружает заданные сектора носителя, и передаёт им управление.

Для настройки загрузчика используется файл /etc/lilo.conf, вот он, с вырезанными коменнтами

boot = /dev/sdb
compact        # faster, but won't work on all systems.

  bitmap = /boot/slack.bmp
  bmp-colors = 255,0,255,0,255,0
  bmp-table = 60,6,1,16
  bmp-timer = 65,27,0,255

append=" vt.default_utf8=1"

prompt
timeout = 50

vga = normal

image = /boot/vmlinuz
  initrd = /boot/initrd.gz
  root = /dev/sda2
  label = Linux
  read-only  # Partitions should be mounted read-only for checking

Конфиг самый простой:

• boot = /dev/sdb -- Место, куда ставится загрузчик. В момент настройки, а не работы. В данном случае ставится в MBR.
• compact объединяет запросы к носителю вместе. ОЧЕНЬ сильно экономит время загрузки, и в особенности на флешках(очевидно потому, что на флешках страницы большие)
• image = /boot/vmlinuz имя симлинка, указывающего на образ ядра
• initrd = /boot/initrd.gz имя образа initrd
• label = Linux стандартное имя опции выбора в приглашении загрузчика
• read-only стандартная опция загрузки корневой системы

Остальные параметры обычные.

fstab

К сожалению, Kim Jaegeuk на сегодня ещё не доделал fsck, потому обходимся без проверки корневой системы. Как он доделает, будем проверять(а работы ведутся полным ходом прямо сейчас) Посему пока вот такой fstab

# монтируем корень без проверки
/dev/sda2        /                f2fs        defaults         1   0

# монтируем /boot/
/dev/sda1        /boot            ext2        defaults         1   2

#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro,comment=x-gvfs-show 0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0

devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0

# у меня всего 1015Мб памяти, потому для /tmp выделена половина(макс)
tmpfs            /tmp             tmpfs       nodev,nosuid,size=500M 0 0 

Необходимость выделить отдельный /boot/ тоже является временной. Проблема в том, что инсталлятор загрузчика /sbin/lilo на сегодня не понимает f2fs. Работы в этом направлении тоже ведутся, т.ч. в скором времени нам отдельный раздел /boot/ будет не нужен(на самом деле он и сейчас не нужен, если ручками сформировать карту. Но, т.к. я ленивый, то я просто использовал пока ext2. Это не на что не влияет, кроме разве что занятого места)

Удачи!

UPD: сижу вот тут с этим нетбуком. УМВР. Не тормозит как slax, это не live, нормальная годная система. Конечно пруфпик надо приложить:

вот, это я на лоре с гентушниками срусь. Ну гентушники они в своём репертуаре  -- вроде всё есть, да нихрена не работает :)

UPD2: немного запоздало ПОЗДРАВЛЯЮ ВСЕХ с двадцатилетним юбилеем Slackware Linux. Если-бы не она, так бы и компилял ядро всю жизнь. И не было-бы у меня ни детей, ни жены ;)

К счастью, есть OS которая ПРОСТО РАБОТАЕТ. Это главное.

HOWTO: использование ЭЦП и шифрования на практике

Ну такой небольшой HOWTO, по использованию электронной подписи и шифрования.

Часть первая.

Введение

Подпись применяется повсеместно, но её применение строгим образом лимитировано государством. Она называется в оффлайне "печатью", и ставится разными юр. лицами для того, что-бы было понятно, какое лицо создало данный документ. Для физ. лиц используется обычная подпись.

Для электронных документов не используется НИЧЕГО. Таким образом, получая документ, мы даже не знаем, кто его нам прислал. Для быдла это очевидно не нужно. Шибко грамотные используют обратный адрес(IP, доменное имя сайта) для установления отправителя, но никто не задумывается о том, что подделать его не просто, а очень просто. Часто используется SSL/TLS, хотя всем широко известно, что подделка этого протокола тоже возможна (ага, центр сертификации может быть скомпрометирован). Получается, что надеяться можно исключительно на себя.

Про шифрование вообще никому похоже в Этой Стране неизвестно. Его кагбэ и нет.  Ибо «честному человеку скрывать нечего». Это ложь.

Проблема в том, что честному человеку есть что скрывать, и эта информация постоянно собирается, продаётся и покупается. Личные данные нужны в основном для таргетинговой(целенаправленной) рекламы, рассылки спама, и прочей «полезной» деятельности. Естественно, иные криминальные и полукриминальные структуры также активно пользуются собранной информацией.

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

Принципы и проблемы

Достаточно просто зашифровать любой файл просто сложив его обратимым(это важно!) способом с любой известной случайной(т.е. непредсказуемой, и это тоже важно!) информацией. Доказано, что если дополнительная информация действительно непредсказуемая, то не зная её невозможно расшифровать файл. Эта дополнительная информация является ключом . Размер такого ключа должен быть равен размеру файла. Но к счастью, математики сумели придумать способ разворачивания небольшого пароля в ключ нужной длинны.

Ну следуя традиции, мы будем рассматривать передачу разведчицы Алисы резиденту Бобу. Перед передачей Алиса и Боб УЖЕ должны  знать пароль. Если его никто другой не знает, то никто не сможет прочитать переданный файл кроме Боба(Алиса тут тоже может, но это не обязательно, её же файл). Из-за того, что пароль короткий, злоумышленник может его подобрать с помощью грубой силы, используя тот факт, что о статистических данных сообщения можно заранее догадаться. Для предотвращения данной атаки, Алисе нужно рандомизировать своё сообщение так, что-бы оно было неотличимо от случайного мусора. К счастью, данная задача решена, с помощью известных всем программ сжатия -- они выкидывают лишнюю информации, оставляя только необходимую. При этом, каждый бит файла увеличивает свой "вес"(энтропию) до своего максимального значения равного ½ (как монетка, про которую мы ничего не знаем). Сообщение становится максимально непредсказуемым, что существенно затрудняет подбор.

Что-бы решить задачу аутентификации(что-бы Боб был уверен, что сообщение именно от Алисы), Алиса может отправить Бобу зашифрованную известную Бобу информацию. Этим она докажет то, что она это она.

Остаётся проблема передачи самого пароля. Данную задачу решает асимметричное шифрование. Имеются математические функции, которые можно легко(сравнительно) вычислить в прямом направлении, и намного сложнее в обратном. К примеру попробуйте разложить на простые множители 539369709830409850025883673. Мой компьютер с этим справился более чем в 400 раз дольше, чем перемножал. Числа нужно взять НАМНОГО больше, дабы разложение заняло-бы заведомо нереальное время. Такое произведение можно(и нужно) публично выкладывать где угодно, а вот сами множители нужно тщательно скрывать. Множители называются секретной частью, а произведение -- публичной(или секретным и открытым ключом соответственно).

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

Технически, асимметричное шифрование длинных файлов очень долгое, потому их шифруют неким одноразовым случайным паролем, а вот этот пароль шифруют асимметрично. Также и с подписью -- используется односторонняя функция от сообщения, называемая "хеш". Зная сообщения можно просто и быстро получить его хеш, но обратное преобразование невозможно. Также и коллизии(совпадения) хешей хоть и возможны теоретически, но вероятность их равна нулю (с практической т.з.) Алиса расшифровывает хеш своим секретным ключом, и то, что получилось, использует как ЭЦП. Любой может это число зашифровать публичным ключом Алисы, и получить хеш. Совпадение хешей гарантирует авторство Алисы. (подробнее, и не настолько упрощённо, см. в энциклопедии, здесь я попытался упростить до предела понимание, вплоть до того, что некоторые детали не совсем соответствуют действительности. Я думаю, они не слишком важны на практике)

Практика

Здесь и далее  я буду использовать стандартную программу gpg, у неё конечно есть GUI (и не один), а также она работает в любых системах. И тем не менее, я настоятельно рекомендую хотя-бы один раз сделать это в консоли. Начнём мы конечно с создания пары своих ключей:

$ gpg --gen-key 
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Выберите тип ключа:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (только для подписи)
   (4) RSA (только для подписи)
Ваш выбор (?-подробнее)? 
ключи RSA могут иметь длину от 1024 до 4096 бит.
Какой размер ключа Вам необходим? (2048) 
Запрашиваемый размер ключа 2048 бит
Выберите срок действия ключа.
         0 = без ограничения срока действительности
        = срок действительности n дней
      w = срок действительности n недель
      m = срок действительности n месяцев
      y = срок действительности n лет
Ключ действителен до? (0) 
Ключ не имеет ограничения срока действительности
Все верно? (y/N) y

Для идентификации Вашего ключа необходим User ID
Программа создаст его из Вашего имени, комментария и адреса e-mail в виде:
    "Baba Yaga (pensioner) "

Ваше настоящее имя: emulek-test
Email-адрес: emulek.bx@gmail.com
Комментарий: тест
Используется таблица символов: `utf-8'.
Вы выбрали следующий User ID:
    "emulek-test (тест) "

Сменить (N)Имя, (C)Комментарий, (E)email-адрес или (O)Принять/(Q)Выход? O
Для защиты секретного ключа необходим пароль.

Вам не нужен пароль? Это ОЧЕНЬ ПЛОХАЯ идея!
Работа будет продолжена. Вы сможете сменить пароль в любое время,
запустив данную программу с ключом "--edit-key".

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

Недостаточно случайных чисел.  Выполняйте какие-либо действия для того,
чтобы ОС могла получить больше случайных данных! (Необходимо ещё 284 байт)
.+++++
.+++++
Необходимо сгенерировать много случайных чисел. Желательно, что бы Вы
выполняли некоторые другие действия (печать на клавиатуре, движения мыши,
обращения к дискам) в процессе генерации; это даст генератору
случайных чисел возможность получить лучшую энтропию.

Недостаточно случайных чисел.  Выполняйте какие-либо действия для того,
чтобы ОС могла получить больше случайных данных! (Необходимо ещё 23 байт)
.........+++++

Недостаточно случайных чисел.  Выполняйте какие-либо действия для того,
чтобы ОС могла получить больше случайных данных! (Необходимо ещё 53 байт)
.....+++++
gpg: ключ E79DF0AF помечен как абсолютно доверяемый.
открытый и закрытый ключи созданы и подписаны.

gpg: проверка таблицы доверий
gpg: 3 ограниченных необходимо, 1 выполненных необходимо, PGP модель доверия
gpg: глубина: 0  корректных:   3  подписанных:   1  доверия: 0-, 0q, 0n, 0m, 0f, 3u
gpg: глубина: 1  корректных:   1  подписанных:   0  доверия: 0-, 0q, 0n, 0m, 1f, 0u
pub   2048R/E79DF0AF 2013-07-09
Отпечаток ключа = 15A7 34D1 5C8A 0589 A8A0  F2DB 8BB8 B503 E79D F0AF
uid                  emulek-test (тест) 
sub   2048R/B60B9CA7 2013-07-09

Принцип защиты информации базируется на том, что злоумышленник никогда не узнает секретную часть ключа, потому важно, что-бы она НЕ покидала компьютер (бекапить её можно например зашифровав весь каталог ~/.gnupg, причём это можно сделать всего один раз. Этот ключ не поменяется, если вы его конечно сами не отзовёте), ну и кроме того, даже локально секретный ключ тоже шифруется паролем. Каждый раз при расшифровке и при подписывание НЕОБХОДИМО ручками этот пароль набирать. Если на другом компьютере вам понадобится ключ -- просто сделайте ещё один. Это ведь не сложно.

Следует помнить, что ВСЯ зашифрованная информация при потере секретного ключа превратится в груду бесполезного мусора.

Публичная часть ключа

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

Только-что сделанный ключ можно преобразовать в файл такой командой:

gpg --armor --export E79DF0AF

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

gpg --list-key
pub   2048R/E79DF0AF 2013-07-09
uid                  emulek-test (тест) 
sub   2048R/B60B9CA7 2013-07-09

(список секретных ключей можно смотреть с опцией --list-secret-keys). Также ключ можно и отправить на публичный сервер ключей командой

$ gpg --send-keys E79DF0AF
gpg: отправляю ключ E79DF0AF на hkp сервер pgp.mit.edu

Сервер ключей задан в ~/.gnupg/gpg.conf (можно задать и в команде ключом --keyserver. Принимать ключ с сервера нужно так же, но с опцией --recv-keys. За раз можно принять несколько ключей)

Ну а уж про использование ключей я расскажу в следующей части…

Часть вторая

Торренты запрещают. Что теперь делать?! Уходим в андеграунд, или Kademlia жива!

Давеча в начале месяца власти решили таки запретить нам скачивание наших любимых фильмов, дабы мы их таки не скачали. Это не может не "радовать". Так что-же нам делать?

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

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

1. Время. Один из компьютеров должен быть включён в Сеть 24/7/365.
2. Адрес. Неплохо-бы знать, откуда нам собственно нужно качать наш любимый контент. Понятное дело, что никакие узлы не горят желанием публично выкладывать свои адреса, дабы избежать сложностей.
3. Далеко не все клиенты имеют сегодня полноценный доступ в Сеть. Многие "сидят за NAT'ом", т.е. имеют возможность работать лишь как клиенты (если вы "сидите за NAT'ом", то вы можете лишь скачивать откуда-то что-то по вашему запросу, или заливать что-то кудато по своей инициативе). "NAT" в кавычках потому, что "за ним", на самом деле находятся все пользователи Интернета(и не за одним NAT'ом), но не все NAT'ы одинаково полезны. У каждого клиента имеется свой IP адрес, этих адресов немного, и они стоят денег. А посему, многие провайдеры выдают один IP адрес на множество клиентов. Очевидно, запрос К такому клиенту не дойдёт, потому-что шлюз провайдера не знает, к кому он именно, среди Over9000 таких же. Если вы "за NAT'ом", то вы не сможете меняться файлами с такими-же бедолагами как вы (исключения есть, но они сложно реализуемы на сегодня). К счастью, примерно половина пользователей интернета имеет на сегодня полноценное подключение, а следовательно, вы теряете не так много(а именно около половины источников)

Все эти проблемы можно решить привлечением третей стороны.

Исторически первыми, среди массового файлообмена, были FTP серверы. Такой сервер представляет собой обычный компьютер, который работает не совсем в обычном режиме. Во первых он работает 24/7/365. Во вторых, он имеет полноценный широкополосный интернет, причём на отдачу (часто многие провайдеры умалчивают о том, сколько вы можете отдать, по той причине, что большинство клиентов только забирает). FTP серверы публиковали свои координаты на разных форумах, и народ оттуда спокойно качал файло. Это было очень давно, задолго до наших лет(в прошлом веке). Сейчас все такие сервисы давно закрыты, ибо никто в здравом уме не желает сидеть в тюрьме непонятно за что(один человек просто физически не сможет проверить законность контента, что ему присылают, а ответственность за CP появилась задолго до интернетов).

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

К счастью, к тому времени появилось достаточно много узлов, которые обладали анлимом, и могли без проблем меняться файлами друг с другом непосредственно. Но проблема №2(см. выше, невозможность узнать адрес источника) осталась. Эта проблема была решена с привлечением третей стороны, а именно треккера.

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

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

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

В ближайшее время тоталитаризм грядёт и в Россию, и нам срочно надо думать, что-же делать?

Ну для начала подумаем, как именно будет происходить борьба: лентару говорит, что всё будет просто: предупреждение, потом, если не осознал, штраф 5 тыщ. Не сложно догадаться, что все осознают, и просто снимут с раздачи то, что они там закачали. А если кто не снимет, то штраф 5000руб никак не окупит оперативно-следственную работу по выявлению "пирата". Лога провайдера для этого точно недостаточно, ибо на треккерах полно легального контента. Пруф. Это ведь надо будет конкретную слежку/прослушку ставить. Конечно это оправдано для поимки убийцы/педофила, но для поимки пирата это слишком.

Какаим-же образом будет выполняться постановление Правительство СР? Очевидно лишь одним: придётся заблокировать треккеры, если не все, то хотя-бы самые крупные (этого более чем достаточно, ибо 3.5 юзерам остальных будет просто неоткуда качать. А если их треккер станет популярным, то и его быстро залочат).

Технически это реализовать очень просто, просто запретить соединения от клиентов к IP треккера. ВСЁ.

И что-же делать?

Да очень просто, если нельзя сделать один большой треккер, давайте его порежем на 100500 маленьких, и будем поддерживать каждый кусочек самостоятельно!

Именно в этом и заключается идея Kademlia.

Реализация Kademlia

Всё довольно просто: каждому файлу, как и на треккере, присвоен md4 хэш. Но хеш присвоен не только файлам, но и самим клиентам(случайным образом). Основная идея Kademlia(как и любой DHT) заключается в том, что-бы считать каждого клиента узлом некого гиперкуба. В Kademlia гиперкуб 128и мерный, а следовательно имеет 2^128=340282366920938463463374607431768211456 вершин. Очевидно, что практически все из них пустые. Также очевидно и то, что двигаясь только по рёбрам гиперкуба, мы можем пройти от любой вершине к любой другой не более, чем за 32 прыжка. Но самое главное, что мы всегда можем найти кратчайший путь(расстояние между узлами очень легко посчитать: оно равно числу разных бит в хешах, если их записать в двоичной СС). Конечно всё это верно, если наши узлы расположены равномерно. Но это так и есть.

Подключение к Сети

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

Поиск хеша

Поиск осуществляется с помощью UDP запроса, который отправляется в адрес того соседа(из 1000), хеш которого ближайший к искомому. Сосед поступает также. В итоге, уже через ~10…15 прыжков ответ достигает узлов, хеш которых ближе всех к искомому. Именно там и встречаются запросы  всех клиентов, которые что-то ищут. И там же хранятся адреса ищущих. Они-то и отправляются тому, кто это искал. Ну а далее ищущий обращается к тем, у кого что-то есть, уже напрямую(в случае, если источник "за NAT'ом", то он сам обращается к ищущему).

Хеш можно вычислить от чего угодно, а вовсе не только от файла целиком. Сам файл делится на блоки (по 10Мб), каждый из которых имеет свой хеш. Эти блоки тоже можно искать. Кроме того, каждое имя файла дробится на слова, и хеши слов тоже публикуются, а потому, в Kademlia можно искать и по имени файла, а не только имея ссылку. Потому Kademlia НЕ нуждается в сайтах для поиска, которые тоже можно забанить. Кроме имени, размера, и хеша файла, в Kademlia предусмотренна и иная информация о файле(рейтинг, комментарий, параметры мультимедиа, если ОС смогла их распознать, например разрешение экрана, и т.д.). Искать по ней нельзя, но можно фильтровать.

Число источников

Ещё не начав качать файл, мы уже знаем, сколько человек его раздаёт (примерно конечно). Это очень важно, ибо плохие файлы никто не станет хранить, а следовательно и раздавать. Потому, если источников мало, то файл очевидно почти никому не нужен. Он либо редкий, либо поддельный.

Вуалирование

Вуалирование == шифрование. Однако не обычное, а специальное, в  котором ключ лежит рядом с данными. Смысл его вовсе не в  защите информации от чтения врагами, а в том, что-бы не допустить провайдеру блокировать трафик. Пакеты в Kademlia имеют известную и документированную структуру, а следовательно их очень просто заблокировать. Если-же они зашифрованы, то для поиска необходимо расшифровать ВСЕ пакеты ВСЕХ клиентов. Это возможно лишь теоретически, но никак не на практике. На практике, пакеты Kademlia имеют содержимое неотличимое от случайного мусора, и случайный размер.

Заключение

В заключение я лишь могу дать ссылки на оффсайт emule, там же вы найдёте необходимую документацию и т.п.

Имеется также кросплатформенный клиент aMule, имеющийся в репозиториях всех популярных Linux'ов(также есть версия его же для apple). Естественно, amule работает не только GUI клиентом, но и демоном (в составе есть удалённые морды, GUI, CLI, и web). Ссылку намерено не даю, ибо программы необходимо ставить из репозитория, а не "бесплатно и без СМС". В силу почти полного совпадения кодовой базы, документация по eMule подходит и для aMule (за небольшими исключениями, которые не играют роли).

За сим -- желаю удачи.

Свирепой шестерёнкой в механизме государства
Армейской мясорубке не давай себя сжевать.
Назло!!!!!!!!!
поперёк!!!!!!!!!
Назло!!!!!!!!!
поперёк!!!!!!!!!

Сторонникам порядка навреди как можно больше
В проигранной  войне сопротивляйся до конца.
Назло!!!!!!!!!
поперёк!!!!!!!!!
Назло!!!!!!!!!
поперёк!!!!!!!!!

Шагай на красный цвет и нарушай правопорядок
Законам и запретам поступай наперекор.
 Назло!!!!!!!!!
 поперёк!!!!!!!!!
Назло!!!!!!!!!
поперёк!!!!!!!!!

На всякое насилье отвечай сопротивленьем
В безликом окруженьи будь всегда самим собой.
Назло!!!!!!!!!
поперёк!!!!!!!!!
Назло!!!!!!!!!
поперёк!!!!!!!!!

(Гражданская Оборона)

подключение яндекс-диска в Linux.

что-то слишком уж много стало мануалов, и ни одного нормального. Вот напишу шпаргалку на будущее.

step by step

1. понадобятся права root'а. Во первых для установки davfs2.

2. для Slackware Linux нужно предварительно создать пользователя и группу.

# groupadd -g 230 davfs2
# useradd -u 230 -d /var/cache/davfs2 -g davfs2 -s /bin/false davfs2

(для остальных дистрибутивов этот пользователь сам создаётся, хотя это нужно проверить).

Теперь можно ставить davfs2 (slackbuilds.org)

3. основной юзер(у меня drb) должен входит в группу davfs2. (добавить можно командой usermod, или просто подправив /etc/group)

4. для монтирования нужно добавить запись в /etc/fstab

https://webdav.yandex.ru   /home/drb/yandex  davfs   noauto,user           0   0

вам нужно будет поменять имя каталога на нужное. Именно туда и смонтируется yandex.disk. У меня это /home/drb/yandex

5. теперь права рута нам не нужны 

6. Создаём точку монтирования  /home/drb/yandex (простой каталог, создаём НЕ от рута, а от себя).

7. создаём каталог ~/.davfs2 (права 0755, как обычно)

8. копируем туда /usr/share/davfs2/secrets и /usr/share/davfs2/davfs2.conf

9. назначаем права

chmod -v 0600 ~/.davfs2/secrets

10. забиваем в этот файл своё имя и свой пароль к учётке яндекса. Например у меня почта на яндексе: emulek@yandex.ru, потому я добавил такую запись:

/home/drb/yandex             emulek       мой_пароль

11. теперь можно монтировать обычной командой

mount ~/yandex

которую можно внести в автозагрузку например.

12. в конфиге есть параметр  debug most, который позволяет посмотреть, по каким причинам каталог не смонтировался. Пароль вводить ессно не нужно.

UDP: Зачем?
Да, действительно, доступ к я-диску можно получить иначе. Однако, _любой_ иной способ, кроме монтирования, имеет существенный недостаток: невозможно работать с диском иначе, как этим способом.

Монтирование делает из диска обычный локальный каталог, с которым может работать _любая_ программа, в т.ч. dolphin/rsync.

У меня проблема с бекапами, которые мне необходимо делать автоматически, иначе я про них забываю. Т.о. запускать для них дельфин для меня неприемлемо(и уж паче того wine).

Кроме того, локальные бекапы можно хранить в открытом виде, но чужим облакам я не верю. Яндекс убрал пункт, запрещающий шифрованные файлы. Потому ничего не мешает хранить файлы в шифрованном виде. Однако, программы вроде GnuPG про яндекс-диск не в курсе, за то отлично работают с обычными каталогами, в частности и из скриптов. Используя асимметричное шифрование, можно легко добиться автоматической работы (ибо зашифровать файл может кто угодно, а именно это и нужно).

В ядре Linux обнаружена локальная root-уязвимость

http://www.linux.org.ru/forum/security/9160925

http://www.opennet.ru/opennews/art.shtml?num=36933

В ядре Linux обнаружена уязвимость, позволяющая получить root-доступ произвольному пользователю. Проблему усложняет то, что ошибка существовала на протяжении последних 2-3 лет и существует во всех ядрах начиная с 2.6.37 и включая 3.8.10.
Проблема присутствует в коде PERF_EVENTS, которая должна быть активирована для успешной эксплуатации уязвимости. Пользователи RHEL 6 и CentOS, несмотря на использование ядра 2.6.32, не застрахованы от данной ошибки - проблемный код был успешно бэкпортирван Red Hat в пакет с ядром, поставляемом в RHEL.
Эксплоит уже доступен публично

ссылка на сам эксплоит http://packetstormsecurity.com/files/121616/semtex.c

PoC:

   bash-4.1# gcc -O2 exploit.c
   bash-4.1# chmod 777 a.out
   bash-4.1# su nobody -s /bin/bash
   bash-4.1$ id
   uid=99(nobody) gid=99(nobody) groups=99(nobody)

   bash-4.1$ cd /
   bash-4.1$ ls
   a.out  bin  boot  dev  etc  exploit.c  home  lib  lib64  media....
  
   bash-4.1$ ./a.out
   2.6.37-3.x x86_64

   sh-4.1# id 

   uid=0(root) gid=0(root) groups=0(root),99(nobody)

только что-то в Slackware Linux проблемы начались  уже с su nobody вполне предсказуемо. А с какого перепугу у nobody есть шел?

Очевидно, что на эту команду su просит пароль, которого не существует.

Fail

Впрочем, получив права рута, я таки смог насильно зайти как nobody с оболочкой bash, как мне тут рекомендуют (само по себе бред). Очевидно, в каталог пользователя, компилявшего эксплоит меня не пустили

Fail

Ладно, вернув права рута, переместил эксплоит в /tmp, и потом опять вошёл как nobody (руту можно всё). Наконец-то можно запускать!

Fail

Данный былокод просто завис.

Итог: в слаке это трижды НЕ работает. 

ЗЫЖ и да, ядро обновлять мне лениво.

Linux ksu 3.8.4 #2 SMP Tue Mar 26 23:52:24 CDT 2013 x86_64 Intel(R) Pentium(R) CPU G2020 @ 2.90GHz GenuineIntel GNU/Linux

cat это кошка (пруфлинк). правда некоторые говорят, что cat это сокращение от concatenate, но они врут. На самом деле, за всё существование cat она соединила ровно столько-же файлов, сколько съела мышек моя кошка. А именно - ни одной. cat умеет делать ровно столько-же, что и обычная кошка - кушать и какать. Кушает она с рук, с клавиатуры, а какает там-же где и живёт - в терминале. Если вы мне не верите, напишите:

Консоль

cat

кормить её нужно там-же, и какать она будет в том-же терминале, где её завести/запустить. Когда надоест, нажмите CTRL+D, что значит "всё, пожрали!".
Можно заставить cat жрать файлы, воспользовавшись перенаправленнием, например:

Консоль

cat <кошачий_корм

Если у вас конечно есть файл кошачий_корм.
Можно заставить её какать в туалет:

Консоль

cat >кошачий_туалет

А можно и то и другое одновременно:

Консоль

cat <кошачий_корм >кошачий_туалет

Если туалета нет, то он создастся.
Больше всего кошка любит жрать. Причём она умеет находить жратву самостоятельно. Ей не обязательно насильно пихать жратву в рот, можно просто её пнуть^W оставить наедине с кормом:

Консоль

cat кошачий_корм

…

паранойя

вот приходит всякая шняга… Им-то какое дело, как меня завут?

поменял на "Дмитрий Иванов", может отвяжутся.

Здравствуйте!
Похоже, что имя drBatty emulek, которое Вы указали в профиле Google+, не является именем.
Возможно, это название Вашей компании, либо наша система ошиблась.
Мы можем предложить Вам указанные ниже варианты решения проблемы.

• Если это название компании или бренда, укажите вместо него имя представителя организации в своем аккаунте. Позже Вы сможете создатьстраницу Google+ с помощью этого профиля. Напоминаем: +страницы предназначены для организаций, а профили – для индивидуальных пользователей.

• Если это все-таки Ваше имя, войдите в аккаунт и, следуя инструкциям, добавьте сведения о себе, чтобы мы могли устранить ошибку.

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

• Если ни один из этих вариантов Вам не подходит, поскольку Вы используете указанное в Google+ имя для входа в YouTube, отключите свой канал от профиля Google+. В этом случае у Вас останется доступ к YouTube, но профиль Google+ будет заблокирован до тех пор, пока Вы не выполните одно из указанных выше действий. Если Вы управляете каналом бренда, вскоре у Вас появится возможность использовать свои данные для доступа ко всем сервисам Google

SSD

Всё что вы таки хотели знать, и побоялись спросить.

История

На самом деле, твёрдотельные накопители известны с древнейших времён. Ещё в ZX Spectrum использовались "флешки", а точнее EEPROM. Данная память являлась энергонезависимой, т.е. при отключении питания информация в ней сохранялась. Удалить её не было никакой возможности в штатном режиме.

Конструкция

Сама по себе EEPROM являлась матрицей из самых обычных МОП транзисторов. За одним интересным исключением: данный транзистор имел карман над затвором, т.е. некоторую изолированную область. Если она была пуста (т.е. как соседние слои кремния), то никакого эффекта от неё не было. Транзистор проводил ток,  что трактовалось как 1. Но если-бы в кармане присутствовали заряды, он-бы тогда работал как затвор,  и его заряд отклонял-бы поток носителей (электронов/дырок) в канале МОП транзистора. Такое состояние условно обозначается как 0.

Запись

Для записи в ячейку используется туннельный эффект, который можно представить как обратимый пробой изоляции кармана. Для этого на карман подают высокое напряжение (+12V например, как в упомянутом ZX), за счёт чего электроны и попадают в т.ч. и в этот карман.

Записывать можно исключительно нулевые биты, ибо нет никакого способа сделать из 0 →   1. В начальном состоянии все биты имеют значение 1, и при записи, некоторые из них переходят в 0. Очевидно, что если EEPROM может записывать только нули, то в начальном состоянии все байты содержат 0xFF, и перевести их можно в конечном итоге не далее, чем в 0x00. Именно по этой причине, в системе команд тех CPU код 0x00 означал NOP (нет операции).

Умножитель

Использовать два источника питания (+5В и +12В) было естественно неудобно. Потому к концу 80х годов прошлого века, изобрели второй раз умножитель напряжения. Этот девайс работает по совсем простому принципу: заряжает несколько конденсаторов параллельно, а затем разряжает последовательно, получая высоковольтный импульс напряжением, которое пропорционально числу конденсаторов. Таким образом и получался высоковольтный импульс годный для записи.

Стирание

Первые чипы EEPROM не имели стирания вовсе. Однако, почти сразу было замечено, что облучение УФ светом выбивает электроны из карманов, приводя EEPROM в исходное состояние. Потому чипы стали делать с окошечком, через которое они собственно и стирались. Ресурс был не очень большой, ибо выходом из строя чипа считался выход любого его эл-та. А даже в первых вариантах эл-тов было порядка 128К. Таким образом ресурс составлял всего около сотни циклов записи (с учётом того, что после каждой записи нужно стирание).

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

NOR

Такие чипы NOR устанавливали во все компьютеры, начиная с первых IBM-PC. NORами они назывались по очень простой причине - все эл-ты были соединены параллельно, а стало быть выполняли функцию ИЛИ, однако, и-за того, что сам по себе транзистор выполняет функцию NOT (если есть напряжение на затворе, или в кармане, транзистор заперт, и ток через него НЕ течёт), то получившийся элемент выполнял функцию NOT-OR. Эти чипы практически были вечными, ибо читались всего один раз, во время загрузки. Затем ROM отключалась, и на работу компьютера не влияла. Однако, можно было стереть, и перезаписать прошивку, чем и пользовался вирус CIH. Для лечения требовалось вынуть флешку из здоровой мамки(такой же), вставить в больную, загрузится, по горячему поменять, и прошить больную флешку. Иногда такая беда возникала без всяких вирусов, сама по себе, и лечилась так же. Судя по этому опыту, можно сказать, что информация во флеш чипах может хранится как минимум десятилетиями, и вероятность потери ничтожно мала (и даже если мы потеряем какой-то бит, мы потеряем именно один бит, который можем и восстановить, и переписать).

NAND

NOR это конечно хорошо, но мало. Чтобы было больше, транзисторы можно построить столбиком, и соединить последовательно. Ток через такой столбик пойдёт в том, и только в том случае, если все транзисторы открыты, как затворами, так и карманами. Т.о. они выполняют логическую функцию NOT-AND. Побочный эффект очевиден - хотя в одном столбике и можно записать несколько бит, но вот прочитать за один раз можно только один. Впрочем, это не важно, т.к. всего у нас 100500 эл-тов, и прочитать их все сразу нет никакой возможности.

MLC

Ещё один путь повышения ёмкости (кроме NAND столбиков) - хранение в карманах не просто какого-то заряда, а несколько разных значений этого заряда. Такой метод называется MLC. Обычно в кармане хранят не два (0,1), а четыре уровня (00,01,10 и 11), что позволяет добиться хранения двух битов на одном транзисторе. Также можно хранить и 8 уровней(TLC), однако профит этого не настолько большой, и потому проще делать четырёхуровневые MLC(их больше влезает).

Болезни by design

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

• одной из основных проблем флешек является низкое число циклов записи/стирания. Конечно это далеко не 100 циклов, но и 10000..100000 тоже немного для использования флешек вместо типичного ЗУ. Проблема кроется в том, что туннельный эффект, это тоже в некотором смысле пробой, и постоянная инжекция электронов в карманы ведёт к деградации их изоляции. Т.к. за каждой записью нужно стирание, то это также приводит к старению эл-тов. Мало того - стирать можно только целиком весь носитель, потому, даже если мы записали немного, то для повторной записи придётся стереть всё. Для устранения этой проблемы пришлось ввести контроллер, который выбирает для записи всякий раз новые страницы, дабы запись не осуществлялась в одно и то же место. Кроме того, современные флешки уже не стираются полностью, а могут стираться отдельными островами. Сегодняшние SSD могут теперь похвастаться огромным ресурсом, и это уже НЕ является особой проблемой. Однако важно всё же помнить о том, что для нормальной работы SSD необходимо свободное пространство, ибо если его не будет, контроллер будет просто вынужден использовать только очень небольшой объём, который и будет планомерно задрачивать(и который быстро выйдет из строя). Конечно, во внешних ЗУ 1 мегабайт равен 1 000 000 байт, хотя на самом деле 1048576 байт. Потому небольшой резерв есть всегда. Но, ИМХО, для надёжной работы администратор просто обязан обеспечить некоторое свободное место. Если у вас Windows™, вы можете просто разметить SSD так, что-бы была какая-то неразмеченная область (чем больше, тем лучше для ресурса). Для Linux с этим вопросом проще, если вы используете ручное разделение на разделы (всё равно требуется выделять с запасом).
• Вторая важная проблема: низкая скорость записи и стирания. Скорость записи в настоящее время весьма велика, и составляет примерно 40..20% от скорости чтения. Это обеспечивается исключительно тем, что запись происходит одновременно в несколько островов. Ещё один повод выделить достаточно свободного места, ибо очевидно, что если остров всего один, ни о какой параллельной записи не может идти речи. Низкая скорость стирания связана с работой умножителя, который требует длительной зарядки ёмкостей. (см. выше). Практически неустранима на сегодняшний день, однако, её можно делать в фоне(см. далее).
• "Усиление записи". Выше я уже писал о том, что страницы на SSD организованы в острова, которые можно стирать только полностью, всем островом. Это приводит к тому, что каждая страница может находится в трёх состояниях: Во первых страница может быть чистой, и готовой к записи. Во вторых страница может содержать нужные данные, и в третьих страница может содержать уже ненужные данные. Возможна ситуация, когда на острове все страницы находятся в состояниях 2 или 3. И несмотря на то, что страницы в состоянии 3 уже не нужны, остров невозможно очистить из-за страниц в состоянии 2. Потому возможна ситуация, когда свободное место есть, но писать данные некуда.

TRIM

Для решения всех этих трёх проблем, первоочередное место занимает число свободных островов. Если у вас  их много, то никаких проблем нет. Однако, современные ФС не стирают информацию при её удалении, для HDD/FDD это просто не нужно. Посему, большинство страниц рано или поздно зависает в состоянии 3, и требует очистки. При этом, страницы в состоянии 2 требуют перемещения на свободные острова. Это можно всё выполнить в фоне, если использовать новую ATA команду TRIM.

Следует помнить, что команда TRIM сама по себе ничего не стирает. Она лишь уведомляет носитель о том, что страница перешла из состояния 2(с данными) в состояние 3(грязная). Само по себе стирание осуществляется лишь сборщиком мусора(GC), который переносит нужные страницы на свободные острова, а потом стирает те острова, где грязных страниц больше всего. Это может занять длительное время, которое тем не менее никак не сказывается на скорости работы (если достаточно чистых страниц).

Страницы также могут быть опознаны носителем в состоянии 3, в том случае, если мы осуществляем повторную запись в страницу, которая находится в состоянии 2. Запись при этом осуществляется в какую-то другую страницу (чистую), а эта помечается как ненужная. В таком режиме чистые страницы очень быстро закончатся, и скорость записи катастрофически упадёт (что мы и видим на фешках). Тоже самое будет и с SSD, если не включить команду TRIM. Проблема ещё и в том, что у сборщика мусора в данной ситуации нет ни времени, ни места, и потому его эффектность близка к нулю - он слишком много пишет и стирает. Это сильно уменьшает ресурс носителя.

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

Рекомендации и мифы

Основная рекомендация: свободное место. Его должно быть МНОГО. В идеале 40%, хотя можно и поменьше, но не менее 25% носителя. Следует помнить о том, что фундаментальные истины не стареют: ещё Кнут доказал, что ЛЮБОЕ ЗУ начинает тупить, если сильно заполнено (более 90%). Потому не нужно думать, что вы выбрасываете мегабайты на ветер. НЕ ЖАДНИЧАЙТЕ. В конце концов, сейчас мегабайт стоит копейки, даже если это RAM, а тем более SSD.

Вторая рекомендация: TRIM. Все современные ФС это умеют (man mount на предмет discard для ext4), и этим НАДО пользоваться. Без TRIM вы мучаете свой SSD, не нужно этого.

Как не странно, что касается записи, то это всего лишь третья рекомендация. Да, лишних записей не нужно. Но и фанатизма тоже не надо. Скажите спасибо ненастраиваемой Windows™, благодаря которой, SSD сейчас допускают бешеное количество циклов записи.

Однако, есть смысл таки прикупить памяти, и смонтировать туда /tmp/. Этот каталог не нужен при перезагрузке, да и его можно использовать для компиляции, распаковки (напосмотреть), и прочих временных нужд. Даже с SSD память всё равно в разы быстрее. Ну и зачем мучить SSD, если без этого можно обойтись? С т.з. безопасности /tmp тоже желательно выкинуть в память, ибо удаление в SSD никем и никогда не гарантировалось, потому враги могут в принципе отыскать ваши пароли/ключи в грязных блоках.

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

Мало того, если вы вынесете всякие кеши и т.д. в память, это может привести лишь к тормозам, и сильному износу SSD. Почему? А потому, что SSD отлично работает на чтение, и если ваш браузер что-то там закешировал, есть смысл это прочитать с кеша, чем грузить вторично из интернета.

Тоже самое касается noatime, которая тоже не нужна. Почему? А потому, что именно по времени доступа ваш браузер и другие программы судят о нужности или не нужности закешированного файла. Если atime маленькая, значит файл не нужен (мы его давно не использовали), и его можно удалить, а освободившееся место использовать для нужного. Если вы поставите noatime, вы всё поломаете, и программы будут удалять нужные файлы, которые они постоянно используют. А сразу вслед за этим скачивать их повторно из интернета, и губить этим ваш SSD (ну и тормозить для комплекта).

SWAP

Своп не нужен, но должен быть. Странно, да? Ничего странного: в нормальном режиме своп не нужен, если он у вас используется: goto за новой памятью. Или мучайтесь с тормозами. А зачем своп? А нужен своп за тем, дабы у системы было немного времени на раздумья, кого надо убивать за перерасход памяти. Такое бывает. Такое бывает даже с хорошими программами в странных условиях. И если свопа нет, то для системы это равносильно как для вас топором по голове. Если своп есть - OOM Killer успеет выяснить виновника, и убить его. На сервере это критически важно. На десктопе - это просто неудобно, когда ВНЕЗАПНО иксы падают, и у вас чёрный экран. Да, ничего не сохранилось конечно. Вам это надо?

Размер свопа не нужно делать большим. В принципе достаточно 512Мб(для десктопа), но из-за наличия свободного места для SSD, его можно сделать и побольше. Вплоть до полного объёма памяти, дабы обеспечить засыпание.

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

Нужен-ли commit=xx? Не нужен. С ним вы потеряете свою работу за последние xx секунд, без него ваш носитель будет работать не 6472 дня, а 6451 день. Выбирайте сами, что вам дороже.

Нужно-ли сувать в память кеш пакетного менеджера? В принципе нужно, если вам нравится сидеть и смотреть, как оно это всё выкачивает по 10 раз.

Нужно-ли отключать журналирование? Нужно, если вы хотите ЗАГУБИТЬ СВОИ ДАННЫЕ И СИСТЕМУ. Для SSD это тем более важно, ибо данные на SSD носителе, хоть и раз в 10 лет, но таки иногда портятся. Без журнала это похоронит нах всю файловую систему.

Ну и наконец: "почему у меня не работает TRIM?" Ответ: см. hdparm -I /dev/sdX. Если там пишет - "работает", значит работает. Ну и конечно discard для ext4 включите (в других ФС я не знаю как). Если у вас всё в 0xFF не вставляется - это не повод для беспокойства, оно не сразу. Народ говорит, что в некоторых SSD вставляет в 0x00, это не страшно, 0 и 1 это условности. Главное - вставляет.

Здравствуйте, дорогие дяди и тёти.

Это я, drBatty, он же emulek.

Решил вот я бложик завести, ибо модно, стильно и молодёжно. Да и домен я давеча прое^Wутерял. Да и йух то с ним.

Посему вот здесь, пока мну ещё и в гугле не забанили.

Пишите, Ваше мнение очень важно для нас.