Опубликовано: 10.12.2021
Просмотры: 57

Слово «протокол», очень распространено в современной криптологии. Протоколы – составная часть теории связи. Они такая же неотъемлемая часть учебников и практических руководств, как формулы, чертежи и диаграммы. Грубо говоря, Интернет – это не программы и не компьютеры, а набор протоколов, обеспечивающих всемирную меж-компьютерную связь. В криптологии протоколы тоже широко используются для описания процессов распространения шифрованной информации.
Протоколы похожи на театральные пьесы или на киносценарии.  Они предписывают порядок действий, которые следует предпринять участникам сеанса передачи информации, чтобы этот сеанс завершился успешно.
В любой пьесе есть актеры. Криптографические протоколы «разыгрывают» агенты, которые могут быть людьми, а могут быть и компьютерами, и компьютерными программами или даже менее «умными» приборами, скажем, турникетами или считывателями штрих-кодов. Но человеку свойственно одушевлять и олицетворять все, что его окружает: и природные силы, и рабочие инструменты, и участников криптографических протоколов тоже.

При описании криптографических протоколов принято называть действующих агентов человеческими именами, за каждым из которых закреплена определенная роль. Как в итальянской комедии дель арте роль персонажа определяется его именем. Панталоне – значит, венецианский купец, а потому богач, но одновременно старик, а потому глуповатый скупердяй. Арлекин – значит, слуга, сообразительный и проворный. Коломбина – значит, служанка, девушка простая, но честная, не унывающая и сообразительная. Подобная же прямая зависимость роли персонажа от его фамилии наблюдается и в классицистических пьесах 18-го века. Достаточно вспомнить комедию Д. И. Фонвизина «Недоросль»: Скотинин, Простаковы, Стародум, Правдин, Милон... Действия этих персонажей предписаны их фамилиями.
Впервые достаточно длинный список «персонажей», действующих при описании криптографических протоколов, появился в 1994 году в книге замечательного американского криптографа и популяризатора науки Брюса Шнайера (Bruce Schneier; род. 15 января 1963) «Прикладная криптография».
В первую очередь, в этом списке следует выделить Алису и Боба (Alice and Bob). Эти персонажи — обычные пользователи, обменивающиеся сообщениями по линии связи. Так сказать, «А и Б сидели на трубе». Алиса и Боб гораздо старше прочих персонажей в списке Брюса Шнайера и придуманы они не им. Впервые двух участников процесса обмена информацией по каналу связи назвал Алисой и Бобом Рон  Ривест  (Ronald Linn Rivest; род. 1947) в своей научной статье, опубликованной в 1978 году.
Рон Ривест – известный криптограф, один из изобретателей криптографического алгоритма RSA с помощью которого появилась возможность обмениваться секретной информацией по открытым каналам связи. Первая буква в названии алгоритма RSA «принадлежит» Ривесту. Две другие буквы – первые буквы в фамилиях его коллег и соавторов, S – Ади Шамира (Adi Shamir), а A – Леонарда Адлемана (Leonard Adleman).

Иногда бывает так, что криптографический протокол описывает связь не между двумя, а между тремя, четырьмя и более участниками сеанса связи. Таких участников называют Чарли (Charlie), Дэйв (Dave). И так далее, по алфавиту.
Впрочем, буква E зарезервирована для имени Ева (Eve). Это созвучно английскому слову evil. Поэтому Ева— злоумышленник. Она злодей пассивный. Перехватывает сообщения, которыми обмениваются Алиса  и Боб, но изменить эти сообщения не может.
А вот Мэллори (Mallory, чье имя созвучно слову malicious, злонамеренность) или Труди (Trudy, созвучная слову  intruder, нарушитель) — злоумышленники активные. В отличие от затаившейся и все регистрирующей Евы, эти девушки могут изменять сообщения, от Алисы к Бобу и от Боба к Алисе, а значит, влиять на их взаимоотношения. Помните, с чего началась «Сказка о царе Салтане»?

А ткачиха с поварихой,
С сватьей бабой Бабарихой,
Извести ее хотят,
Перенять гонца велят;
Сами шлют гонца другого
Вот с чем от слова до слова:
«Родила царица в ночь
Не то сына, не то дочь;
Не мышонка, не лягушку,
А неведому зверюшку».
То-то же!

Среди «бойцов невидимого фронта» есть также взломщик паролей по имени Крейг (Craig). Этот Крейг — почти что Crack, взлом. Болтается также и какой-то посторонний Чак (Chuck). По старой шпионской привычке, чужой – это враг. Поэтому добра от Чака ждать не стоит.
Но и добрых людей, стоящих на страже справедливости, среди действующих лиц криптографических протоколов достаточно.  Это Пегги (Peggy), чье имя сближается со словом prover, проверяющий, а также контролер Виктор (Victor), чье имя производится от verify, подтверждать. Проверяющие и контролеры передают абсолютно правдивые сообщения о транзакциях (то есть, о переводах денег) в сети. Есть также и доверенный арбитр Трент (Trent), сообщениям которого следует абсолютно доверять. Ведь его имя произведено от слова true, правда. Надзиратель Уолтер (Walter)  неустанно следит за Алисой или Бобом. Не всегда Уолтер –  полисмен или сотрудник тюрьмы. Иногда он может охранять и защищать простых пользователей, Алису и Боба.
Идея называть действующих лиц криптографических протоколов по именам, которые характеризуют их функциии, большинству криптографов понравилась. Конечно, список этот не является каноническим. Кого-то в него добавляют, кого-то убирают. Но теперь даже в серьезных научных трудах можно встретить Алису, Боба и Еву и прочих перечисленных персонажей.

Читать далее

Опубликовано: 09.12.2021
Просмотры: 59

Кратко

Учитывая номер версии МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ, следует увеличивать:
  1. МАЖОРНУЮ версию, когда сделаны обратно несовместимые изменения API.
  2. МИНОРНУЮ версию, когда вы добавляете новую функциональность, не нарушая обратной совместимости.
  3. ПАТЧ-версию, когда вы делаете обратно совместимые исправления.
Дополнительные обозначения для предрелизных и билд-метаданных возможны как дополнения к МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ формату.

Вступление

В мире управления процессом разработки есть понятие «ад зависимостей» (dependency hell). Чем больше растёт ваша система и чем больше библиотек вы интегрируете в ваш проект, тем больше вероятность оказаться в этой ситуации.
В системе с множественными зависимостями выпуск новой версии может быстро превратиться в кошмар. Если спецификации зависимости слишком жесткие, вы находитесь в опасности блокирования выпуска новой версии (невозможность обновить пакет без необходимости выпуска новой версии каждой зависимой библиотеки). Если спецификация зависимостей слишком свободна, вас неизбежно настигнет версионное несоответствие (необоснованное предположение совместимости с будущими версиями).
В качестве решения данной проблемы я предлагаю простой набор правил и требований, которые определяют, как назначаются и увеличиваются номера версий. Для того чтобы эта система работала, вам необходимо определить публичный API. Он может быть описан в документации или определяться самим кодом. Главное, чтобы этот API был ясным и точным. Однажды определив публичный API, вы сообщаете об изменениях в нём особым увеличением номера версий. Рассмотрим формат версий X.Y.Z (мажорная, минорная, патч). Баг-фиксы, не влияющие на API, увеличивают патч-версию, обратно совместимые добавления/изменения API увеличивают минорную версию и обратно несовместимые изменения API увеличивают мажорную версию.
Я называю эту систему «Семантическое Версионирование» (Semantic Versioning). По этой схеме номера версий и то, как они изменяются, передают смысл содержания исходного кода и что было модифицировано от одной версии к другой.

Спецификация Семантического Версионирования (SemVer)

Слова «ДОЛЖЕН» (MUST), «НЕ ДОЛЖЕН» (MUST NOT), «ОБЯЗАТЕЛЬНО» (REQUIRED), «СЛЕДУЕТ» (SHOULD), «НЕ СЛЕДУЕТ» (SHOULD NOT), «РЕКОМЕНДОВАННЫЙ» (RECOMMENDED), «МОЖЕТ» (MAY) и «НЕОБЯЗАТЕЛЬНЫЙ» (OPTIONAL) в этом документе должны быть интерпретированы в соответствии с RFC 2119.
  1. ПО, использующее Семантическое Версионирование, должно объявить публичный API. Этот API может быть объявлен самим кодом или существовать строго в документации.  Как бы ни было это сделано, он должен быть точным и исчерпывающим.
  2. Обычный номер версии ДОЛЖЕН иметь формат X.Y.Z, где X, Y и Z — неотрицательные целые числа и НЕ ДОЛЖНЫ начинаться с нуля. X — мажорная версия, Y — минорная версия и Z — патч-версия. Каждый элемент ДОЛЖЕН увеличиваться численно. Например: 1.9.0 ->1.10.0 -> 1.11.0.
  3. После релиза новой версии пакета содержание этой версии НЕ ДОЛЖНО быть модифицировано. Любые изменения ДОЛЖНЫ быть выпущены как новая версия.
  4. Мажорная версия ноль (0.y.z) предназначена для начальной разработки. Всё может измениться в любой момент. Публичный API не должен рассматриваться как стабильный.
  5. Версия 1.0.0 определяет публичный API. После этого релиза номера версий увеличиваются в зависимости от того, как изменяется публичный API.
  6. Патч-версия  Z (x.y.Z | x > 0) ДОЛЖНА быть увеличена только если содержит обратно совместимые баг-фиксы. Определение баг-фикс означает внутренние изменения, которые исправляют некорректное поведение.
  7. Минорная версия (x.Y.z | x > 0) ДОЛЖНА быть увеличена, если в публичном API представлена новая обратно совместимая функциональность. Версия ДОЛЖНА быть увеличена, если какая-либо функциональность публичного API помечена как устаревшая (deprecated). Версия МОЖЕТ быть увеличена в случае реализации новой функциональности или существенного усовершенствования в приватном коде. Версия МОЖЕТ включать в себя изменения, характерные для патчей. Патч-версия ДОЛЖНА быть обнулена, когда увеличивается минорная версия.
  8. Мажорная версия X (X.y.z | X > 0) ДОЛЖНА быть увеличена, если в публичном API представлены какие-либо обратно несовместимые изменения. Она МОЖЕТ включать в себя изменения, характерные для уровня минорных версий и патчей. Когда увеличивается мажорная версия, минорная и патч-версия ДОЛЖНЫ быть обнулены.
  9. Предрелизная версия МОЖЕТ быть обозначена добавлением дефиса и серией разделённых точкой идентификаторов, следующих сразу за патч-версией. Идентификаторы ДОЛЖНЫ содержать только ASCII буквенно-цифровые символы и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Числовые идентификаторы НЕ ДОЛЖНЫ начинаться с нуля. Предрелизные версии имеют более низкий приоритет, чем соответствующая релизная версия. Предрелизная версия указывает на то, что эта версия не стабильна и может не удовлетворять требованиям совместимости, обозначенными соответствующей нормальной версией. Примеры: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
  10. Сборочные метаданные МОГУТ быть обозначены добавлением знака плюс и ряда разделённых точкой идентификаторов, следующих сразу за патчем или предрелизной версией. Идентификаторы ДОЛЖНЫ содержать только ASCII буквенно-цифровые символы и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Сборочные метаданные СЛЕДУЕТ игнорировать, когда определяется старшинство версий. Поэтому два пакета с одинаковой версией, но разными сборочными метаданными, рассматриваются как одна и та же версия. Примеры: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
  11. Приоритет определяет, как версии соотносятся друг с другом, когда упорядочиваются. Приоритет версий ДОЛЖЕН рассчитываться путём разделения номеров версий на мажорную, минорную, патч и предрелизные идентификаторы. Именно в такой последовательности (сборочные метаданные не фигурируют в расчёте). Приоритет определяется по первому отличию при сравнении каждого из этих идентификаторов слева направо: Мажорная, минорная и патч-версия всегда сравниваются численно. Пример: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. Когда мажорная, минорная и патч-версия равны, предрелизная версия имеет более низкий приоритет, чем нормальная версия. Пример: 1.0.0-alpha < 1.0.0. Приоритет двух предрелизных версий с одинаковыми мажорной, минорной и патч-версией ДОЛЖНЫ быть определены сравнением каждого разделённого точкой идентификатора слева направо до тех пор, пока различие не будет найдено следующим образом: идентификаторы, состоящие только из цифр, сравниваются численно; буквенные идентификаторы или дефисы сравниваются лексически в ASCII-порядке. Численные идентификаторы всегда имеют низший приоритет, чем символьные. Больший набор предрелизных символов имеет больший приоритет, чем меньший набор, если сравниваемые идентификаторы равны. Пример: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

Зачем использовать семантическое версионирование?

Это не новая или революционная идея. Вероятно, вы уже используете что-то подобное. Проблема в том, что «подобное» — не достаточно хорошо. Без соответствия формальной спецификации, номера версий практически бесполезны для управления зависимостями. Ясно определив и сформулировав идею версионирования, становится легче сообщать о намерениях пользователям вашего ПО. Когда эти намерения ясны, гибки (но не слишком), спецификации зависимостей наконец могут быть созданы.
Простой пример демонстрирует, как Семантическое Версионирование может сделать «ад зависимостей» вещью из прошлого. Представим библиотеку, названную «Firetruck». Она требует Семантически Версионированный пакет под названием «Ladder». Когда Firetruck был создан, Ladder был 3.1.0 версии. Так как Firetruck использует функциональность версии 3.1.0,  вы спокойно можете объявить зависимость от Ladder версии 3.1.0, но менее чем 4.0.0. Теперь, когда доступен Ladder 3.1.1 и 3.2.0 версии, вы можете интегрировать его в вашу систему и знать, что он будет совместим с текущей функциональностью.
Как ответственный разработчик, вы, конечно, хотите быть уверены, что все обновления функционируют как заявлено. В реальном мире полный бардак и ничего нельзя с этим поделать. Что вы можете сделать — это дать Семантическому Версионированию предоставить способ выпуска релизов без выпуска новых версий зависимых пакетов и сохранить вам время и нервы.
Если это звучит соблазнительно, всё что вам нужно — это начать использовать Семантическое Версионирование, объявить, что вы его используете, и следовать правилам. Добавьте ссылку на этот сайт в вашем README, тогда пользователи будут знать правила и извлекать из этого пользу.

FAQ

Что я должен делать с ревизиями в 0.y.z на начальной стадии разработки?

Самое простое — начать разработку с 0.1.0 и затем увеличивать минорную версию для каждого последующего релиза.

Как я узнаю, когда пора делать релиз 1.0.0?

Если ваше ПО используется на продакшене, оно, вероятно, уже должно быть версии 1.0.0. Если у вас стабильный API, от которого зависят пользователи, версия должна быть 1.0.0. Если вы беспокоитесь за обратную совместимость, вероятно, версия вашего ПО уже 1.0.0.

Не препятствует ли это быстрой разработке и коротким итерациям?

Мажорная версия 0 как раз и означает быструю разработку. Если вы изменяете API каждый день, вы должны быть на версии 0.y.z или на отдельной ветке разработки работать над следующей главной версией.

Даже если малейшие обратно несовместимые изменения в публичном API требуют выпуска новой главной версии, не закончится ли это тем, что очень скоро версия станет 42.0.0?

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

Документирование всего API — слишком много работы!

Это ваша ответственность, как профессионального разработчика, правильно документировать ПО, предназначенное для широкого использования. Управление сложностью ПО очень важная часть поддержки высокой эффективности проекта. Это тяжело сделать, если никто не знает, как использовать ваше ПО или какой метод можно вызывать безопасно. В долгосрочной перспективе Семантическое Версионирование и настойчивость в качественном документировании публичного API поможет всем и всему работать слаженно.

Что мне делать, если я случайно зарелизил обратно несовместимые изменения как минорную версию?

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

Что я должен делать, если я обновляю свои собственные зависимости без изменения публичного API?

Это можно рассматривать как совместимые изменения, так как они не влияют на публичный API. ПО, которое явно зависит от тех же зависимостей что и ваш пакет, должно иметь собственные спецификации зависимостей и автор будет уведомлен о возможных конфликтах. Являются ли данные изменения уровня патча или минорного уровня, зависит от того, обновили ли вы свои зависимости чтобы исправить баг или реализовать новую функциональность. В последнем случае, как правило, добавляется некоторое количество дополнительного кода и как следствие, увеличивается минорная версия.

Что если я нечаянно изменил публичный API в несоответствии с изменением номера версии (т.е. код содержит обратно несовместимые изменения в патч-релизе)?

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

Что делать с устаревшей функциональностью?

Объявление функциональности устаревшей — это обычное дело в ходе разработки и часто необходимо для продвижения вперёд. Когда вы объявляете устаревшим часть публичного API, вы должны сделать две вещи: (1) обновить вашу документацию, чтобы дать пользователям узнать об этом изменении; (2) выпустить новый релиз с увеличением минорной версии. Прежде чем вы полностью удалите устаревшую функциональность в релизе с увеличением главной версии, должен быть как минимум один минорный релиз, содержащий объявление функциональности устаревшей, чтобы пользователи могли плавно перейти на новый API.

Есть ли в SemVer лимиты на длину строки версии?

Нет, но руководствуйтесь здравым смыслом. 255 символов в строке версии, пожалуй, перебор. Кроме того, определенные системы могут предъявлять свои собственные ограничения на размер строки.

Об авторе

Авторство спецификаций Семантического Версионирования принадлежит Тому Престон-Вернеру, основателю Gravatars и соучредителю GitHub.
Читать далее

Опубликовано: 09.11.2021
Просмотры: 86

Чтобы поменять на репозиторий Яндекса перейдите /etc/apt/sources.list или /etc/apt/sources.list.d/sources.list и измените на

# buster
 
deb http://security.debian.org/ buster/updates main
# Line commented out by installer because it failed to verify:
deb-src http://security.debian.org/ buster/updates main
 
deb http://mirror.yandex.ru/debian buster main
deb-src http://mirror.yandex.ru/debian buster main
 
deb http://mirror.yandex.ru/debian buster-updates main
deb-src http://mirror.yandex.ru/debian buster-updates main
 
deb http://mirror.yandex.ru/debian/ buster-proposed-updates main non-free contrib
deb-src http://mirror.yandex.ru/debian/ buster-proposed-updates main non-free contrib
 
# Backports
#deb http://mirror.yandex.ru/debian buster-backports main contrib non-free
#deb-src http://mirror.yandex.ru/debian buster-backports main contrib non-free


Знак # чтобы закомментировать строчку и для удобства есть команды nano или mcedit

Для обновления используйте эту команду

apt-get update -y  && apt-get dist-upgrade -y && apt-get autoremove -y && apt-get autoclean -y

Читать далее

Опубликовано: 04.11.2021
Просмотры: 78

Для установки Ethereum в операционной системе Debian 10 или 11 потребуется добавить официальный репозиторий эфира, для этого создадим файл с помощью команды.
nano /etc/apt/sources.list.d/ethereum.list

Добавим в его содержимое - ссылки на репозитории Ethereum.
deb http://ppa.launchpad.net/ethereum/ethereum/ubuntu bionic main 
deb-src http://ppa.launchpad.net/ethereum/ethereum/ubuntu bionic main

Сохраните и выйдите. Затем вам нужно будет импортировать ключ GPG для PPA.
apt-key adv --keyserver keyserver.ubuntu.com  --recv-keys 2A518C819BE37D2C2031944D1C52189C923F6CA9

После того, как Apt завершит импорт ключа, обновите свою операционную систему и установите пакет Ethereum.
apt-get update
apt-get install ethereum

После завершения установки можно проверить версию клиента сети ethereum.
geth version

Читать далее

Опубликовано: 09.06.2021
Просмотры: 270

1 января 2019 года вступил в силу новый налоговый режим. Это новая возможность для ведения бизнеса физическими лицами — стать самозанятым.

Кто такие самозанятые и как работает новый налог НПД

Чтобы вести предпринимательскую деятельность в Российской Федерации, нужно иметь определённый правовой статус. До недавнего времени для небольших компаний были доступны два варианта: ИП (индивидуальный предприниматель) и ООО (общество с ограниченной ответственностью). Теперь появился ещё один правовой статус — самозанятый.

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

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

Чем может заниматься самозанятый:
  • реализовывать продукцию (собственного производства в том числе и продукты в области IT).
  •  монетизировать свои навыки и оказывать услуги.
  •  одновременно работать и по найму, и на себя.

Деятельност Самозанятых граждан опирается на Федеральный закон от 27.11.2018 N 422-ФЗ «О проведении эксперимента по установлению специального налогового режима „Налог на профессиональный доход” в городе федерального значения Москве, в Московской и Калужской областях, а также в Республике Татарстан (Татарстан)», сокращенно НПД, который вступил в силу 1 января 2019 года.

С 1 января 2020 года проект распространяется ещё на 19 регионов: Санкт-Петербург, Воронежская, Волгоградская, Ленинградская, Нижегородская, Новосибирская, Омская, Ростовская, Самарская, Сахалинская, Свердловская, Тюменская, Челябинская области, Красноярский и Пермский край, Ненецкий автономный округ, Ханты-Мансийский автономный округ — Югра, Ямало-Ненецкий автономный округ и республику Башкортостан.

С 1 июля 2020 года Государственная Дума разрешила всем регионам вводить НПД на своей территории. Власти регинов самостоятельно принимают решение об участии в эксперименте и могут нормативно-правовым актом ввести на своей территории данный налоговый режим.

А с 9 июня 2021 года я стал счасливым обладателем этого почетного статуса, статуса Самозанятого гражданина!

Какие плюсы получаю я?
  • НПД позволяет получать прибыль и не бояться, что налоговая привлечет к ответственности за незаконную предпринимательскую деятельность, заставит платить налог на доходы (НДФЛ) в размере 13%, НДС по ставке 20% и штраф.
  • Простота регистрации ─ не ппришлось никуда ходить, всё происходит онлайн. Подробно о регистрации я расскажу в статье «Как стать самозанятым».
  •  Не надо самим рассчитывать сумму налога, это делает налоговая.
  •  Отсутствие отчетности.
  •  Нет обязательной уплаты страховых взносов.
  •  Не нужно открывать расчетный счет, так как принимать оплату можно любыми способами, включая перевод на вашу личную банковскую карту и электронные кошельки.
  •  Не требуется онлайн-касса.
  •  Я могу официально подтвердить свои доходы, например, для получения кредита ─ соответствующая справка формируется в приложении «Мой налог».
  •  Самозанятую деятельность легко совмещать с наемной работой.

Какие плюсы получают мои клиенты и партнеры?
  • Легальность и прозрачность всех сделок.
  • Работать с самозанятыми выгодно: не надо платить за них НДФЛ 13%, страховые взносы и сдавать отчётность, а оплату их работ и услуг можно относить к расходам — и уменьшать налоги к уплате.
  • Проверка по ИНН на сайте налоговой - https://npd.nalog.ru/check-status/.
  • Отношения с самозанятым регулирует гражданско-правовой договор, а не трудовой.
  • После того, как самозанятый выполнил работы или услуги, он должен прислать чек из приложения «Мой налог».
  • Чек обязателен, акт выполненых работ — на ваше усмотрение. (Закон разрешает работать с самозанятым без актов выполненных работ. Акты можно собирать для подстраховки)

Читать далее

Опубликовано: 31.05.2021
Просмотры: 205

Добро пожаловать!
Читать далее