Виктор Сиротин

Репозиторий не хранит права доступа на файлы, как и другие атрибуты тоже. Коммит это не копирование файлов в новое место, а анализ и сохранение их исходного состояния в базу.
Единственный атрибут, который хранит гит — признак исполняемого файла.

core.fileMode
Tells Git if the executable bit of files in the working tree is to be honored.

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

https://en.wikipedia.org/wiki/Interval_tree

Важные данные обычно никогда не хранятся на клиенте, они передаются, используются и удаляются.

Есть ли какие-то ситуации, когда использование httpOnly сессионной куки нас защищает, а вот использование localStorage и sessionStorage уязвимо?

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

Теперь про токены. Токены в теории лучше всего держать не в localStorage, а в sessionStorage. Это хранилище переживает перезагрузки страниц и не расшарено между табами. Т.е. при открытии того же самого адреса в новом табе будет созданая новая сессия. Хранилище очищается при закрытии браузера и таба. Но это жутко неудобно, каждый раз логиниться. Поэтому здравая логика говорит об использовании localStorage, хотя если вы совсем отбитый, то можете хранить токен в сессионой куке.

Если вы прочли те статьи внимательно, то можно понять, что преимущества сессионных кук нивелируются неудобством их использования.
JWT Токены предназначены для микросервисной архитектуры. Т.е. у вас есть некоторый центр аутентификации, который выдает вам токен. Токен этот подписан относительно стойкой криптографией и постоянно ротируется.
Этот токен передается другим микросервисам, которые могут его верифицировать через публичные ключи (JWKS).
Т.е. если вы хотите, вы можете строить свои сервисы так, что они доверяют не только вашему центру аутентификации, но и гуглу с амазоном через OpenID. Есть ситуации, например когда вы хотите разрешить доступ к сервису сотрудникам другой компании. Например, когда такая компания огромна (десятки тысяч сотрудников). Они аутенфицируются у себя, а вы проверяете, что токен выпущен сервисом данной компании. Это не так сложно реализовать.
Реализация авторизации лежит на плечах каждого микросервиса и напрямую завязана на бизнес-логику. Как правило это некий внутренний микросервис, который интегрирован c middleware микросервиса.

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

на заре компов помнится читал описание игры в которой какие-то игровые функции формировались прямо во время работы игры.
сколь помню, был большой набор исполняемых кусков в файле, из которого копированием в память формировались цепочки исполнения, на начало которых CALL'ом передавалось управление, а в конце был обязательно RET.
периодически цепочки переформировывались.

и по идее, это одно из направлений анти реверсинга.

Направление "защиты от реверсинга" достаточно давно ушло в сторону виртуализации кода.
Такие инструменты как Themida, VMProtect, Enigma, etc при минимальных затратах времени и (самое главное) умении пользоваться этими инструментами - позволяют достаточно надежно защитить критические части приложения.
На данный момент лучшими инструментами (сугубо личное мнение, сформированные на основе опыта использования различных протекторов, а также на отзывах самих реверсеров) являются продукты Oreans Technologies (WinLicense, Themida, Code Virtualizer).
Сильные виртуальные машины (которых более десятка) + широкие возможности кастомизации позволяют доставить немало проблем реверсерам.

Сейчас с самомодифицирующимся [машинным] кодом стало заметно похуже. Точнее не сейчас, а примерно со времен protected mode в ключе x86 архитектур: сегмент кода как правило на аппаратном уровне становится защищенным для записи и чтобы все-таки в такие сегменты писать - надо несколько исхитриться, поборов противодействие во первых аппаратной защиты кода, во-вторых управление процессами ос.

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

в общем, решил вопрос:

name: Release

on:
  push:
    branches:
      - master

jobs:
  release:
    if: github.event_name == 'push' && github.ref == 'refs/heads/master'
    name: Release
    runs-on: ubuntu-latest
    steps:
      - name: Getting code
        uses: actions/checkout@master
      - name: Getting Python
        uses: actions/setup-python@master
      - name: Cache pip
        uses: actions/cache@v2
        with:
          path: ~/.cache/pip
          key: ${{ runner.os }}-pip-${{ hashFiles('poetry.lock') }}
          restore-keys: |
            ${{ runner.os }}-pip-
      - name: Getting Poetry
        uses: dschep/install-poetry-action@v1.3
      - name: Getting PostgreSQL
        uses: harmon758/postgresql-action@v1
        with:
          postgresql db: 'test_db'
          postgresql user: 'postgres'
          postgresql password: 'postgres'
      - name: Installing dependencies
        run: poetry install
      - name: Running tests
        run: make coverage_run
      - name: Running coverage check
        run: make coverage_cmd_report
      - name: Running codestyle checks
        run: make check_black
      - name: Running types checks
        run: make check_mypy

      - name: Generate coverage report
        run: make coverage_xml_report
      - name: Upload coverage to Codecov
        uses: codecov/codecov-action@v1
        with:
          token: ${{ secrets.CODECOV_TOKEN }}
          file: ./coverage.xml

      - name: Getting package version
        id: get_version
        run: echo "::set-output name=version::$(poetry version)"

      - name: Getting package clear version
        id: get_clear_version
        run: echo "::set-output name=clear_version::$(poetry version | cut -d ' ' -f 2)"

      - name: Make release and publish
        run: make release USERNAME=${{ secrets.PYPI_USERNAME }} TOKEN=${{ secrets.PYPI_TOKEN }}

      - name: Get asset name
        id: get_asset_name
        run: echo "::set-output name=assert_name::$(ls dist | grep gz)"

      - name: Create Release
        id: create_release
        uses: actions/create-release@latest
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ steps.get_clear_version.outputs.clear_version }}
          release_name: ${{ steps.get_version.outputs.version }}
          draft: false
          prerelease: false

      - name: Upload Release assets
        id: upload_gz
        uses: actions/upload-release-asset@latest
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: dist/${{ steps.get_asset_name.outputs.assert_name }}
          asset_name: ${{ steps.get_asset_name.outputs.assert_name }}
          asset_content_type: application/tar+gzip

В принципе все правильно. Берете и делаете. Серебрянной пули нет.

Особенно порадовало, что "все занимаются тестированием"- это правильно. Лишь бы это не было "все - значит никто". И следите за тем, чтобы тестирование давало результат - либо тикет в системе либо фикс. Если баги находят, но просто говорят о них на кухне - это не тестирование. Если баг фиксится сразу, это не значит что коммит-сообщение можно ляпнуть "fixed some strange bug" - он должен содержать описание сценария в котором он происходит и как он влияет на пользователя.

Улучшайте коммит-сообщения. Так чтобы из них можно было собрать патчноут и красиво показать пользователю. А не куча невнятного "внутряка". Формулируйте с позиции пользы, это заставит разработчиков немного больше гордиться проделанной работой, а следовательно добавит им мотивации. Для примера посмотрите как пишут патчноуты передовые представители игровой индустрии.

По автоматизации .. подводные камни такие:
- если автотестов много - их долго выполнять. Начните с небольшого количества 20-50. На них вы обкатаете внедрение и процесс. Не считайте никакие ROI - это бред. Чем считать ROI лучше написать еще один полезный тест.
- архитектуру тестов старайтесь организовать так, чтобы работу по их написанию можно было распараллелить. Например если у Вас Page Object - один может писать компоненты из которых другой может строить сценарии.
- ваш сервис сильно зависит от доступности источников данных - проверяйте доступность источников регулярно, особенно если эти данные вы получаете не по API, а выковыриваете парсером.
- сделать тестовую базу данных - правильно. Автоматизируйте ее свертывание-развертывание через контейнеры.
- по приоритетам автоматизации - точно так же - по "абстрактной" значимости. Хороший источник для идей - багтрекер. Кластеризуйте ошибки по типам и делайте выводы.
- не делайте автоматизацию ради автоматизации - в первую очередь чините продукт, потом тесты.
- не усложняйте тесты ради того чтобы они справлялись с более сложными условиями, упрощайте условия.
- автотесты будут сыпаться по непонятным причинам. Делайте как можно более полезное логгирование. Если тесты выполняются в произвольном порядке - это тоже может быть одной из причин. Любой рандом в тестировании - зло. Учитывайте это при наполнении тестовой базы данных. Желательно, чтобы тестовая база всегда содержала одинаковые данные. Смотря что у Вас за база. Если это только пользователи это одно, а если у вас там хранятся аггрегированные данные, то нужно время от времени пересобирать тестовую базу из свежих источников и проверять работу тестировочных скриптов с ней.
- автоматизацию тестирования можно применять не только для тестирования конечного продукта, можно тестировать миграции схемы базы данных, восстановление базы из бекапа и прочее.

Можете почитать мои ответы по этому хабу, может найдете там еще ответы на какие-то близкие Вам вопросы.
Вот некоторые из моих советов-ответов более-менее общей направленности:

Как добиться независимости в тестах (phpunit)?
Правильное тестирование Javascript?
Как систематически подойти к тестированию в малой компании разработчиков?
С чего начать изучение на должность QA автоматизатора?
Как создать отдел тестирования?
Какие шаги тестирования сайта?

Читайте:
"Lessons Learned in Software Testing" (Kaner, Bach, Pettichord)
"Experiences of Test Automation: Case Studies of Software Test Automation" (Graham, Fewster)
и вот эту вики: TestAutomationPatterns (Кстати, ее инициатор и редактор та же Dorothy Graham. Есть даже пару записей ее лекций на ютубе - советую глянуть)
В ней прям шаблоны. Проблема - решение. Бесценная вещь. Мне в свое время очень помогло, чтобы понять "что не так" и как это лечить.

Да, самый простой вариант, это:
Пользователь отправляет нам на сервер логин+пароль.
Сервер сверяет с данными в БД, если всё хорошо, то генерирует большую случайную строку(Токен), которую добавляет как запись в БД (UserID, Token), после этого отправляет клиенту токен, чтоб тот установил у себя его в куки (заголовок Set-Cookie).
Теперь браузер клиента на каждый запрос будет отсылать на сервер куку и мы можем, обращаясь к БД на поиск строки из куки, получать данные о пользователе.
Но так как хранение в БД не всегда эффективно, токены хранят иногда в быстрых БД, таких как Redis или MemCached.

По поводу сессии:
Иногда, чтоб не ходить в главную БД на каждый запрос, некоторые данные выносят из главной БД(В тот же Redis, MemCached или даже просто в файл на диске с именем токена). Просто теперь, хранится не только токен, но и по имени токена сразу же получают некоторые данные, например, что у пользователя ID=42 и что он администратор.

Через какое то время удалять?

День, неделя, несколько часов, зависит от задачи.
Например, некоторые сайты хранят сессию сутки, но если нажать галочку "Запомнить меня", то срок может увеличится до недели или месяца.
Сервисы оперирующие с деньгами или чем-то, что может представлять ценность, делают сессии от 10 минут.

WebSQL, увы, стал deprecated еще до того как вышел из черновика. Браузеры тут же кинулись встраивать SQLite, а Oracle испугался и через Mozilla продавил, что браузерное хранилище должно быть key-value. Кое-где (скажем откровенно, в Chromium-based браузерах) до сих пор работает, но когда отвалится -- неизвестно.
У IndexedDB есть одно ярковыраженное преимущество перед localStorage: по умолчанию доступное место заметно больше. Остальное по вкусу, тем более что есть фасадные надстройки над всеми тремя типа localForage.

Если необходимо хранить статичные данные для браузерного расширения

Если это пользовательские настройки, то альтернатив chrome.storage нету. Если это данные необходимые для работу самому расширению (скажем, карты уровней для игры), то проще и логичнее держать это в, например, JSON.

Наиболее стабильный и мощный инструмент, особенно под iOS - React Native. С помощью Expo проекты можно писать вообще без нативного кода, исключительно на js. Я уже год работаю на RN, писал как мелкие проекты, так и очень большие - меня все устраивает.