Форум

Я так и понимаю, что проблема обычно не в том месте на которое указывает отладка, ну или ошибки в том же месте достаточно тривиальны и находятся до компиляции. Не так давно - выдало ошибку в строке, где конец процедуры и одно только слово "end;".  Или когда вываливалось от неявного преобразования параметра - перед вызовом функции вывод на консоль есть, сразу после входа в функцию вывода нет. Точнее падает при попытке вывести параметры, без параметров иногда выводит. Отладчик там вообще выдал, что не узнает из какого исходника и какой строки данный код, вооружившись двумя дизассемблерами (использую старый W32Dasm c отладчиком и IDA Freeware, которая хорошо распознает фреймы стека и стандартные модули паскаля), по ассемблерному коду опознал, что это функция присвоения значения из shortstring в композитную строку. Дальше раскрутил - неявное преобразование.

Спасибо за наводку,  посмотрю исходники на предмет того, как проверить и отслеживать состояние встроенного менеджера памяти. У меня была неясная мысль, что есть зависимость сбоя от количества выделенной памяти (вроде не выделять ли самые большие куски из системы напрямую), спасибо что дали мысли определенную форму. Подозреваю, что если дело в менеджере - придется действительно выделять напрямую (через мини-менеджер).
За сегодня накидал мини-менеджер памяти для конкретного типа промежуточным слоем, но ясности это не принесло, кроме того, что теперь время от времени валится на нем, так как выделение/освобождение памяти теперь через него (но проходит через паскалевский менеджер). До сбойного места при склеивании строк пока дело не дошло.

[QUOTE]HouseManager пишет:
Сергей, прошу прощения, а Тотал командер это нужно доп. программу на комп установить? и где искать эту папку xl\worksheets\[/QUOTE]Если на компьютере стоит Windows 7/8/8.1/10, то обычный проводник раскрывает ZIP на ура. На 2000/XP нужна дополнительная программа, в 90% она уже есть - подойдет и Winzip, WinRar , 7zip, Far manager - по вкусу. Какой программой привыкли архивы открывать - той и пользуйтесь. Папка xl\worksheets\ внутри архива. Для просмотра Xml нужно извлечь, но обычно это делается автоматом во временную папку. Говорю ghj извлечение отдельно, потому что невозможно угадать какой лажью windows попытается открыть xml при автоматическом открытии. Вручную надежнее: извлечь, потом открыть с помощью и найти подходящую программу.

Однако, в противовес этому на "семерке и выше" сложнее изменить расширение файла XLSX на Zip. По  умолчанию, оно вообще не показывается. Это нужно лезть в "панель управления - параметры папок" и ставить галочку "Отображать/Показывать расширения для зарегистрированных типов". А потом еще и соглашаться когда выйдет предупреждение, что может стать недоступным.

В этом смысле Тотал Командер (или Far) для тех кто к нему привык удобнее на всех этапах - расширение можно тут же сменить, распаковать и просмотреть.

Подвижки за 2 недели:
Разобрался с классом fphttpclient (аналог дельфивского thttpclient как я понимаю), принимает на вход и выдает на выход TStream, Пришлось помучиться со стримами, так как перенос с дельфи оказался не 100% и документация по отличиям сводится к исходнику модуля sysutils, а в нем куча включаемых файликов (подогнаны под разные платформы). В итоге сделал переходник с моего композитного типа строки на ansistring и его передал при создании стрима. С получением результата дело наладилось когда поставил стрим в нулевую позицию перед чтением.
Для отладки всего это богатства написал страничку на php принимающую POST запрос и сохраняющую его в файл. Это тоже оказалось не очевидно: $HTTP_RAW_POST_DATA по умолчанию оказался отключен, если тип содержимого - стандартные данные формы, а по чтению из [URL=php://input]php://input[/URL] как оказалось нужно внимательней читать пример file_get_contents(). Подкорректировал скрипт на vbscript для отладки страницы (он как раз и выдает POST как стандартные данные формы). В итоге страничка приняла данные и от скрипта и от fphttpclient.
Далее научился программно искать на портале smev 2 информацию о сервисе (пока только федеральном) - для этого нужно отправить POST запрос с данными поиска в формате AJAX и получить ответ в формате AJAX с мнемоникой и версией сервиса, потом повторить (только уже GET) указав мненонику и версию - в итоге будет AJAX с паспортом сервиса, перечнем операций и их SoapAction-ами, списком узлов СМЭВ, на которых сервис зарегистрирован, включая адреса по которым сервис доступен. Остается только разобрать полученное и выбрать узел, соответствующий региону (или федеральный или 2 тестовых). С региональными сервисами процесс аналогичен, но в запрос чуть отличается.
Попробовал записать полученное в некий файл (кэш) и считывать чтобы не дергать портал при каждом запросе. Сначала попробовал в двоичный файл и ... чтение не вышло. Похоже композитный тип надо еще внимательно дорабатывать. Выяснился странный глюк - выделяю временную строку с 20Мб памяти, считываю из файла - все ОК. Пытаюсь изменить размер целевой строки: копирую указатель на старый буфер, обнуляю исходный указатель (без освобождения), выделяю память, копирую из старого буфера в новый (вот тут наверно ничего не делается так как в большинстве случаев целевая строка пуста) - ОК, освобождаю старый буфер - исключение Invalid pointer operation. Уже проверяю перед освобождением, что IsBadWritePtr возвратил 0/false (то есть права на запись есть) и все равно не-нет да проскочит ошибка освобождения буфера. Как будто его уже освободили или не выделили. А без освобождения - утечка памяти. Про освободили/не выделили сказать пока сложно - на взгляд вроде бы везде явное выделение памяти есть. Однако возможны неявные ситуации. Попробовал включить отображение адресов - так активно выделяются и освобождаются, глазами все не отследить, нужен менеджер памяти для этого.
По ходу отладки уже нашел баг - параметр функции был композитная строка с передачей по значению, по недосмотру туда передавалась строковая константа и компилятор об это даже не пикнул - попытался создать в стеке переменную композитной строки и туда затолкать константу в виде shortstring, типа присваивание же есть. Ага, а выделение памяти я должен в присваивании делать, непонятно как узнав, что память не выделена. Конечно, проверяю указатель на nil и (теперь) limit на ноль, но в стеке могут быть неочищенные значения с прошлого раза, так что гарантии это не дает и указатель может указывать на освобожденную память. Если это "куча", полученная менеджером памяти паскаля, то с точки зрения системы это все же допустимая память, а менеджер памяти определяет несоответствие. Так что выходит надо дорабатывать: или пилить еще один менеджер памяти для конкретного типа или общаться с паскалевским менеджером или запрашивать память напрямую у системы или передавать всегда параметры композитные строки по ссылке (тогда компилятор хотя бы ругнется "при передаче по ссылке тип должен совпадать").

Так что двоичный файл отложил, теперь пишу в xml (точнее подобный) формате. Проблема в принципе такая же, так что пока передаю неинициализированную строку на чтение, по ходу чтения выясняется нужный размер и под него выделяется память. Если нужно перечитать, перед чтением принудительно освобождаются строки.
Далее глюки продолжаются - последняя новость: в строке 152 символа (было несколько добавлений строк), память выделена под 400 Кб и при добавлении еще одной строки или при выводе на экран снова Access violation. Чуть раньше - все выводится без проблем. Вообще на ровном месте.
А на работе еще Семерка, сразу предлагает поискать решение.  :lol:  Поиск решений отключил, в список исключаемых из отчета программ добавил, но эта ерунда все равно выпадает (теперь в виде кнопки "закрыть программу") и, что самое неприятное, перехватывает исключение раньше чем выйдет информация о строках где сбой от отладочной версии программы. Кто-нибудь знает как вообще отключить такую "заботу" хотя бы для конкретной программы? Что они теперь предполагают, что все отлаживают внешним отладчиком?

[QUOTE]Крошка Элис пишет:
а мне постоянно выдает "Ошибка связанных записей"[/QUOTE]По связям это скорее всего лишние/недостающие пробелы. У очень многих людей при ручном вводе привычка ставить после слова пробел. Обычно это нормально, но если обрабатывать автоматически, все пробелы в конце ячейки вылезут в ошибки. У нас поначалу первые 10 запросов в некую ИС вернулись с ошибками из-за пробелов после фамилии или имени или отчества.[QUOTE]Сергей_ пишет:
А как вы увидели, что Эксел хранит число 1853.8600000000001? Я то тыкаю на ячейку, в верху в строке редактирования вроде два знака после запятой...[/QUOTE]Для представления дробного числа в памяти это распространенный подход - хранить больше знаков после запятой чем гарантируешь точностью, а показывать только гарантированные знаки (после округления). Причина том, что в двоичное представление чисел (ограниченной длины) не совпадает с десятичным на 100% и дает "мусор" в последних десятичных знаках дробных чисел. Это одна из причин почему целочисленные значения удобнее - для них двоичное представление однозначно соответствует десятичному и не дает "мусора" (хотя опять же в пределах ограниченной длины).
Если число знаков после запятой фиксировано, то есть другой подход - записывать целое число и указывать сколько знаков дробная часть. То есть вместо 1853,86 (в рублях) записать 185386 (в копейках, как если бы умножили на 100 и округлили до целого) и указать что 2 правых знака на самом деле дробные.[QUOTE]Basil пишет:
Например, сумма 1853.86 в файле хранится как 1853.8600000000001 и ГИС не может её прочитать (естественно, это косяк ГИС).[/QUOTE]Согласен. Можно предположить, что какой-то косяк с преобразованием Variant:Currency.
Хотя равным образом можно посчитать и косяком Excel. Понятно, когда такое хранится в памяти из-за двоичного представления числа - вопросов нет, но выводить так в xml, который псевдо-текстовый формат эти 0,000000000001 немного странно. Почему не записать целое число копеек?
Хотя это риторический вопрос - потому что Эксель позиционирует себя как расчетная программа и хочет хранить дробные части копеек "на всякий случай", а ГИС позиционирует файл Экселя только как носитель, который хранит некоторое значение и Эксель в качестве расчетной программы не воспринимает.[QUOTE]skad888 пишет:
решал данную проблему перезабивая цифры в ручную[/QUOTE]Выход наверно в том, чтобы выводить в Эксель уже округленные копейки - понятно, что вручную вбиваются только копейки, а вот автоматикой могут зацепится и их дробные части в силу того же двоичного представления. Можно попробовать округлить копейки вот так: =ЦЕЛОЕ(А1*100+0,5)/100.
С ГИС я не пробовал, но обычно для себя считаю финансы в Экселе с такой добавкой к формулам. При этом все равно бывают расхождения на 1-2 копейки при сравнении с квитанциями - оно и понятно: ЦЕЛОЕ ( +0,5) самое примитивное округление и наверно ошибается при отрицательных значениях, но разбираться со всеми функциями округления Экселя (их немало) - реально головная боль.

[QUOTE]Programmer пишет:
 В случае отсутствия оплаты, считаю, лучше получать пустой файл для контроля.[/QUOTE]Согласен, но тут важно, что: 1) отсутствие строчки в файле и отсутствие всего файла - вещи разные. Тот же EntryCard итоговую строчку выгружает в файл, даже если нет строк о платежах и общая сумма 0.00 и добавляет об этом еще одно предупреждение.2) получение совсем пустого файла не очень подходит для контроля, поскольку вызовет другие подозрения - не был ли файл испорчен при выгрузке/пересылке, изменен и т.д. Основная причина - при выгрузке, как правило, "пустой" файл (в смысле без строк, в случае dbf он может содержать заголовки) создается до доступа к информации о строчках и не все программы удаляют его при каком-либо сбое во время выгрузки. Потом такой недо-выгруженный файл теоретически может попасть в автоматическую пересылку. Если действительно нужен контроль, то мало "пустого"файла, все же желательно получить в файле строку итоговой суммы и/или контрольную сумму всего файла.

[QUOTE]BatalinVA пишет:
Наверняка в ней 0 и отсутствие не тождествены.[/QUOTE]Полагаю, очень вероятный вариант, уже следующего слоя обработки. Это если смотреть со стороны программиста и информационных моделей.
Однако, я бы заметил, что в некоторых бухгалтерских (в широком смысле) программах (например, сбербанковская EntryCard, которой у нас подготавливают зачисление на карточки) строки с 0,00 вообще не выгружаются (не имеет смысла делать платеж с суммой 0,00), то есть отсутствуют и об этом выдается соответствующее предупреждение. Раздражающе, но правильно с финансовой точки зрения.

Печально, что ГИС не следует примеру других программ и не отождествляет 0,00 с отсутствием. Если подумать, это наверно упирается в те самые "экономические стимулы", когда ГИС нужно отличать неразмещенный ПД по какой-либо услуге от нулевого ПД.

[QUOTE]skad888 пишет:
а программно при загрузке его нельзя просто игнорировать если оно заполнено?[/QUOTE]Можно, но тогда по идее нужно выдавать предупреждение/подсказку "поле игнорируется для данной услуги". Им всего лишь нужно сменить статус события с ошибки на предупреждение или на подсказку, тогда они с себя снимут ответственность (предупредили по-честному) и повесят на Вас (вроде "смотри чего грузишь").
Однако видимо где-то прописано что должна быть именно ошибка. Либо они хорошо понимают, что такие множественные подсказки все проигнорируют.

Полюбопытствовал на технологическом портале СМЭВ какие сервисы вводят и выводят, нашел интересное:
[quote:1042n91d]12 Июля 2017 17:05
Изменения по реестру федеральных тестовых сервисов
Зарегистрирован новый сервис SID0004783 в ТСМЭВ
Зарегистрирован новый тестовый сервис Министерства связи и массовых коммуникаций (Минкомсвязь) «Cведения о получателях платежей за ЖКХ».
Адрес сервиса: [URL=http://smev-mvf.test.gosuslugi.ru:7777/gateway/services/SID0004783]http://smev-mvf.test.gosuslugi.ru:7777/ ... SID0004783[/URL]
Адрес WSDL сервиса: [URL=http://smev-mvf.test.gosuslugi.ru:7777/gateway/services/SID0004783?wsdl]http://smev-mvf.test.gosuslugi.ru:7777/ ... 04783?wsdl[/URL][/quote:1042n91d]
[quote:1042n91d]22 Марта 2017 23:03
Изменения по реестру федеральных сервисов
Зарегистрирован новый сервис SID0004774 в ФСМЭВ
В ФСМЭВ зарегистрирован новый сервис Министерства связи и массовых коммуникаций (Минкомсвязь) «Cведения об информации, необходимой для внесения платы за ЖКУ через организации, осуществляющих деятельность на территории населенного пункта, на которой отсутствует доступ к сети "Интернет".».
Ознакомиться с подробной информацией о сервисе можно, пройдя по ссылке на карточку сервиса.[/quote:1042n91d]Минкомсвязь уже что-то пилит, судя по описанию это сведения из ГИС ЖКХ. То есть все-таки есть возможность запроса реквизитов без начислений?

Ок, как скажут старожилы. В свое оправдание скажу, что тема в "Прочие вопросы", то есть, как я понял, в ГИСовской флудилке. Может быть тогда стоит под ЛС выделить отдельный подфорум? А то темы про ЛС где только не открыты.
К слову, может быть я что-то не понимаю, по целых 2 подфорума про износы в одном [URL=http://forum.burmistr.ru/viewforum.php?f=136]2 темы[/URL], в другом [URL=http://forum.burmistr.ru/viewforum.php?f=134]5 тем[/URL] - так и надо?

Все, практичьте.  "Я все сказал"  :D

[QUOTE]Andrey_S пишет:
открывает лицевой счет на конкретного потребителя (по крайней мере должна так делать) - его и следует указать в сведениях об этом лицевом счете.[/QUOTE][QUOTE]Andrey_S пишет:
идентификатор ответственного плательщика - чтобы этот плательщик мог увидеть этот лицевой счет[/QUOTE]И нигде не сказано, что потребитель и плательщик совпадают.[QUOTE]Andrey_S пишет:
Нет, не перестраховываются.[/QUOTE]ОК, перестраховался Минэкономразвития. И в принципе не _любому_ поставщику, а только тем у кого договор с данным домом. Ведь теоретически возможно внести пункт о разрешении обработки данных сведений поставщику от потребителя, тогда такое ограничение Минэконом развития станет черезмерным.[QUOTE]Andrey_S пишет:
достаточно идентификатора лицевого счета (просто последовательность символов, сама по себе не содержащая никаких охраняемых законом сведений)[/QUOTE]Такими темпами не удивлюсь, что она под защиту попадет.[QUOTE]Andrey_S пишет:
Не вполне понял, как именно Вы предлагаете это сделать[/QUOTE]Аналогично переходу от простой учетной записи (без данных) на госуслугах к стандартной учетной записи. При этом вводится снилс и данные паспорта, которые проверяются по ПФР и ФМС. Технология уже есть, но, кажется, ограничена порталом госуслуг.[QUOTE]Andrey_S пишет:
Предложения следовало бы направлять разработчикам ГИС ЖКХ.[/QUOTE]Конечно так, но если в контракте техзадание пишет почта России, то что-то я не знаю - лучше писать Ланиту или Почте.

[QUOTE]Andrey_S пишет:
Что-то Вас кривая не туда вывела, никакие обязанности госорганов на УО в этом смысле не "переложены".[/QUOTE]Наверно я не очень понятно сформулировал, извините. В ГИС одни и те же категории данных на одни и те же помещения заполняют разные организации, но кто-то отсижывается и ждет пока их заполнят другие. Перекладка налицо. Так что кривая никуда не вывела, "госорганы" в том предложении не упоминались, скорее сама ГИС путем перекрестных запросов могла что-то выяснить, а не ждать пока в нее все-все внесут.
Ну и конечно, "обязанности" - не то же самое, что "функции" (которые у "госорганов"), так что аналогия была не вполне аналогией.[QUOTE]Andrey_S пишет:
Вот и здесь - нужно увязать, к чьим личным кабинетам должны подключиться размещенные УО лицевые счета и, соответственно, в чьих личных кабинетах должна оказаться доступна информация по отношениям поставщика и потребителя ЖКУ.[/QUOTE]И тут выходит, что данные собранные УО - наполовину абстракция. :? Собственник в ЕГРН - одно лицо, плательщик в УО другое, а фактически платит вообще третье лицо. Это - не считая опечаток. Не лучше тогда было определится сразу, прежде чем заполнять в первом приближении, кого указывать?

Или принимать деньги только по паспорту от указанного плательщика - реально раздражает, что "хоть кто" может платить, но не смотреть состояние ЛС. Впрочем, ясно, что никто на это не пойдет.[QUOTE]Andrey_S пишет:
Если лицевой счет открыт на физлицо - то увязка в ГИСе выполняется по СНИЛС или паспортным данным, если на юрлицо - по ОГРН (если на ИП - то по СНИЛС или паспортным данным или ОГРН). ЕГРЮЛ/ЕГРИП, как и кадастр недвижимости - общедоступные ресурсы, поэтому в ГИСе по этим реквизитам реализован подбор (выбирается ссылка из общедоступного списка). Сведения же о физлицах относятся к персональным данным, оператор ГИС не имеет права раскрывать их поставщикам ЖКУ, поэтому в ГИСе подбор из единого общего перечня физлиц не реализован. [/QUOTE]Очевидно, с этим вопросов нет, никто и не просит подбор из _общего_ перечня физлиц.

А вот выбор между ФИО собственников конкретной квартиры по данным ЕГРН - уже интереснее. Так как сам по себе только список ФИО (ФИО, не связанное с другими данными обеспечивающими 100% идентификацию, их долями и т.д.) не является персональными данными. Насколько помню, это четко указано в законе о персональных данных и это доступно из ЕГРН. Это оператор ГИС мог бы представить на выбор из списка. Вот только все перестраховываются и закрывают любое сочетание с ФИО, как включающее другие данные, так и не включающее.[QUOTE]Andrey_S пишет:
Остается только функционал ввода тех идентификационных данных, которые сам поставщик ЖКУ получает (должен получать) у потребителя, когда открывает на него лицевой счет, т.е. вступает с ним в договорные отношения. Он и реализован.[/QUOTE]В теории все замечательно, на практике - вмешивается человеческий фактор: перевод данных от ИС к ИС можно отладить до идеала, от человека к ИС - идеала никогда не будет, будет море опечаток.

И вот тут-то, перед сохранением в ГИС введенные УО данные и можно было бы проверить путем запросов из ГИС ЖКХ в другие ФГИС - при успехе проверки выдавать "подтверждено", при ошибке проверки выдавать "ошибка подтверждения, данные некорректны".

Верно. Точка входа. Первое приближение. Фактически, это обозначили, сделав ввод строгих идентификаторов при открытии ЛС в ГИС необязательным и переложив задачу на УО. Я скорее про то, что у государственных органов уже есть техническая основа для автоматической идентификации и проверки данных человека, надо только пнуть. Нет большого смысла перекладывать ввод идентификаторов на УО, у которых нет доступа к этой основе. Опять будут сканы паспортов хранящиеся неизвестно как, опечатки в номерах, сделанные при "набивании" в спешке, опечатки при вводе старых паспортов, в которых ФИО написано от руки и т.д. И раз на уровне УО нет доступного сервиса проверки введенных данных, было бы логично если б их проверил ГИС.
[quote:1wc227ek]ну вообще везде как первичный ключ для связей по гражданину используют снилс, ибо он неизменен(и уникален) и выдается с рождения.[/quote:1wc227ek]Именно. Но фото нет, увы. Насчет первичности везде, тоже не уверен, все же основным документом, удостоверяющим личность, по закону остается паспорт. Например, в том же регистре избирателей нет поля для снилс/инн, зато паспорт проверяется в разных ракурсах.

А так да, можно помечтать. Если когда-нибудь базу ПФР дополнят фотографией и свежее фото будет выдаваться по запросу СМЭВ, то все гораздо упростится. Можно будет просто вызубрить свой снилс и ходить по инстанциям без документов, как в американских фильмах.

[QUOTE]Sergey Cheban пишет:
[QUOTE]Andrey_S пишет:
Поэтому полагаю, что рано или поздно обязанность по размещению в ГИС ЖКХ строгих идентификационных данных плательщиков будет установлена и в нормативке (если, конечно, ГИС совсем не свернут). Так что сейчас если и не размещать их в ГИСе, то по крайней мере приводить в порядок свои собственные базы в этой части, выстраивать бизнес-процессы по сбору этих сведений поставщикам ЖКУ следовало бы.[/QUOTE]Я думаю, так:
1. У каждого жилого помещения, будь то комната или квартира, должна быть кадастровая стоимость, от которой считается налог на имущество. Значит, должен быть и кадастровый номер. У большинства помещений кадастровые номера есть уже сейчас, у остальных - появятся со временем, никуда не денутся.
2. По заявлению заинтересованных лиц Росреестр уже сейчас обязан приводить свои данные в порядок в трехдневный, кажется, срок.[/QUOTE]Я тоже полагаю, что идентификаторы должны поступать от госорганов. Другой вопрос, что на данный момент предусмотрено, что человек при получении госуслуг везде предъявляет паспорт, то есть возможно данные паспорта все-таки придется вносить. Однако нет необходимости их все хранить в ГИС - достаточно один раз (при внесении данных паспорта в ГИС) валидировать данные паспорта (как при регистрации на госуслугах) и по ним запросить ИНН и СНИЛС (внутренние запросы из ГИС ЖКХ по СМЭВ, см. ниже). Сохранения ФИО, СНИЛС и ИНН в ГИС ЖКХ (серия/номер паспорта может измениться, так что полагаться на них не очень хорошо) более чем достаточно для идентификации человека по любой другой ФГИС. Возможно сделать открытым для просмотра только ФИО, остальное при изменении вводить с чистого листа для защиты персональных данных.[QUOTE]Sergey Cheban пишет:
3. Данные по правам собственности на помещения есть в Росреестре уже сейчас, и в подавляющем большинстве случаев они достоверны. К сожалению, из персональных данных ЕГРН даёт в открытый доступ только ФИО.[/QUOTE]Согласен, но наверно нужно заметить, что доступ одной ГИС к другой и открытый доступ это "две большие разницы". Если в ЕГРН будут или данные паспорта, валидированные по ФМС или снилс/инн, и эти данные будут доступны для внутреннего запроса из ГИС ЖКХ, то не имеет значение, что в открытом доступе только ФИО.[QUOTE]Sergey Cheban пишет:
4. Системы, позволяющей по неполным данным (ФИО, дата-место рождения, номер удостоверения личности, СНИЛС, ИНН) установить конкретное лицо, в России пока нет, но работа по её созданию уже началась.[/QUOTE]На самом деле это не совсем так. Единой системы действительно нет, но запросить основные данные из разных систем, в том числе автоматически, возможно уже сейчас. Единая система будет нужна только для более специфической информации, вроде медицинской, налоговой или хранящейся в определенном органе. Фактически в единой системе даже наверно нет острой нужды - специфическую информацию и не нужно раскрывать всем, но конечно с единой системой будет удобнее.

Подробнее: по полным данным, указанным на скане разворота паспорта с фотографией, уже сейчас есть возможность запросить снилс и инн по каналам СМЭВ (причем достаточно ЭП-ОВ организации, без подписания ЭП-СП конкретного специалиста). То есть для любого госоргана, ОМСУ, МФЦ (для УЦ тоже, но они по своим регламентам требуют бумажки) это не должно составлять проблемы (к СМЭВ подключены не все, но это отдельный вопрос). Обратная операция - получение фио и даты рождения по указанным снилс или инн - тоже есть в СМЭВ, но требует дополнительно подписания запроса ЭП специалиста (ЭП-СП тоже есть не у всех).

На мой взгляд, этого более чем достаточно для установления конкретного лица - серия/номер паспорта, снилс или инн уникальны и выполнив несколько запросов можно установить их взаимное соответствие. Снилс даже не меняется при смене ФИО (на оба варианта возвращается тот же номер) и последние годы присваивается чуть ли не с рождения - для социальных выплат. Единственный недостаток снилс - отсутствие фотографии на карточке с ним, что требует предъявления паспорта и  опознания человеком по фото (компьютер пока плохо опознает: есть случаи когда не опознается тот же человек, есть случаи когда опознаются родственники, дочь и отец). Чтобы разрушить всю связку снилс-паспорт-инн нужно как минимум сменить гражданство, поменять ФИО, а потом вернуть гражданство. Чего еще то нужно от единой системы - чтобы на каждого наносили QR-код (как в антиутопиях) или идентификации по биометрическим данным вместо пары паспорт + снилс?

С другой стороны, пока нет возможности запросить данные разворота паспорта по серии/номеру, но есть сервис валидации введенных данных разворота по базе ФМС (это проверка при регистрации на госуслугах). По всей логике процесса предоставления госуслуг запроса о получении данных по номеру и не должно быть - по 210-ФЗ человек при получении услуги предъявляет паспорт, а остальные документы (и данные) госорганов запрашиваются по СМЭВ. Поэтому достаточно размещения информации на развороте паспорта в любой ФГИС, чтобы ФГИС по каналам СМЭВ смогла достаточно точно идентифицировать человека или выкинуть ошибку, если данные не верны (либо если у несовершеннолетнего нет снилс).

Вопрос только в реализации запросов и настройке доступа между ИС. Это реально. Ну и конечно в самом хранении персональных данных в ЕГРН или поступлении из ОМСУ. Вот тут может быть фантастика, но тоже выполнимо, если законодательство обяжет.[QUOTE]Sergey Cheban пишет:
вижу, что ни для одного из них лицевых счетов нет. Если б были, то, думаю, они тоже успешно привязались бы.[/QUOTE]Это же ГИС, которая пока активно дорабатывается и исправляется, поэтому я бы не был столь уверен в автоматической привязке. Хотя, скорее всего, счетов и правда нет.[QUOTE]Andrey_S пишет:
2) введению обязанности открывать лицевые счета только на собственников/нанимателей/арендаторов помещений (в зависимости от размещенных гос/мун-органами сведений), причем по количеству этих собственников/нанимателей/арендаторов (а как быть с несовершеннолетними/недееспособными? надстройку с законными представителями/опекунами городить?)[/QUOTE]Сложный вопрос. Наверное, правильнее всего, чтобы плательщика своей доли собственник определял сам и вносил его паспортные данные самостоятельно, а не через УО. Договорились в квартире - указали одного, не договорились - платите раздельно. Кнопку "назначить себя плательщиком" или выбор из списка собственников той же квартиры не так трудно сделать. А вот если собственник хочет указать кого-то другого, то пусть вводит все паспортные данные. С другой стороны, такой подход еще больше запутает УО.

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

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

Да, в какой-то из тем упоминали. Решилось как предлагают в сообщении - введением ЕЛС/ИЖКУ вместо ЛС для конкретного дома.

[QUOTE]Andrey_S пишет:
Заполнение платежки плательщиком как раз и основано на запросе начислений из ГИС ЖКХ. В интернет-банке у плательщика-физика это выглядит так. [/QUOTE]Нарисовать страничку и написать что найдено 0 счетов может каждый - вызывает сомнения, а запрашивается ли что-то вообще. :D Даже если работает, то бабулек заполняющих бумажные квитанции все равно больше чем плательщиков интернет-банка. Было бы интересно проверить весь цикл - внесли начисление, нашли в интернет-банке, оплатили, посмотрели что на выходе. Но даже если все успешно, повторять для каждого банка нервов не хватит.[QUOTE]Andrey_S пишет:
Во-первых, далеко не все поставщики ЖКУ ведут системную работу по взысканию задолженности (просто задумайтесь, можно ли вести такую работу, не поддерживая в актуальном состоянии идентификационные данные плательщиков по лицевым счетам) и в отношении не всех должников (лично видел примеры, когда поставщики ЖКУ "стесняются" сообщить о задолженности "уважаемым людям").[/QUOTE]Ну не знаю, у нас просто собирают комиссию с участковыми и местным телевидением и ходят стучат в двери, предупреждают об ответственности. При этом не так уж нужно знать ФИО. Кто открыл, расплачиваются за несколько дней - никому не хочется засветиться в кадре как должнику.
Про уважаемых людей конечно есть тема, я бы даже сказал задолженность часто пропорциональна месячному доходу человека. Самое смешное, что они и рассчитываются не моргнув глазом.[QUOTE]Andrey_S пишет:
Я имел ввиду то, что проблема неплатежей в ЖКХ отчасти перейдет на государственный уровень.[/QUOTE]Несколько сомневаюсь, что государству действительно есть до этого дело. Хотя например, ОМСУ было бы интересно. Не раз видел диалог - жители муниципального жилья приходят, просят что-то сделать и первый вопрос от ОМСУ "сколько по этому дому процент сбора?".
Но это не так что бы эффективно влияет на должников, максимум куда-то отселят должников, которые кроме того буянят и так далее. К "тихим" подобраться сложно. Вот какие эффективные меры можно предложить на государственном уровне, не нарушая прав человека (в том числе прав соседей)?[QUOTE]Andrey_S пишет:
[QUOTE]two_oceans пишет:

В случае ГИС ЖКХ наверно достаточно было бы указать правильный ЕЛС или реальный паспорт/СНИЛС.[/QUOTE]Паспорт/СНИЛС - не вариант. Во-первых, потому что оплату может делать третье лицо, а во-вторых это бесполезно до тех пор, пока сами поставщики ЖКУ не начнут связывать паспорта/СНИЛСы с размещенными в ГИС ЖКХ лицевыми счетами (см. выше).
ЕЛС - да, но реально это произойдет не скоро (см. выше).[/QUOTE]Это со стороны УК не вариант, а плательщику платеж в личном кабинете нарисуется. Назвать паспорт (допустим) родственника не так сложно.[QUOTE]Andrey_S пишет:
Теоретически было бы достаточно, если бы банки в информации о фактах оплаты в правильном поле проставляли используемый сейчас номер лицевого счета (присвоенный самим поставщиком ЖКУ). С учетом того, что сами поставщики ЖКУ в ГИС ЖКХ как получатели платежа идентифицированы это позволило бы идентифицировать и лицевые счета по фактам оплаты в ГИСе. Но по ЕЛС правильнее - единый ключ надежнее.[/QUOTE]Это да, несколько неудобно, что назначение платежа заполняется произвольно. Хорошо бы регламентировать и формулировки и количество знаков/пробелов. Но - что есть.[QUOTE]Andrey_S пишет:
Но это всё - сильно впереди. Сейчас ситуация такова, что ряд поставщиков ЖКУ (в наших краях - большинство, и в первую очередь - крупнейшие РСО) в ГИС ЖКХ тупо не размещают НИЧЕГО. Как будто закон на них не распространяется.[/QUOTE]Се ля ви. :? Это хорошо что только не размещают, судя по вопросам на которые дали ответы, где-то даже вбивают неправильные счета специально.

Подумал еще - 1) новый ГОСТ совершенно не снимает проблемы с параметрами хэша. Их все также не менее 3 наборов; 2) в методическим указаниях по ГИС пока вроде тишина про гост-2012, то есть пока что спешки нет. Без методических я не в курсе какие коды алгоритмов вписать в XML для нового ГОСТа. [URL=https://tools.ietf.org/html/draft-chudov-cryptopro-cpxmldsig-09]Вот тут[/URL] что-то нашлось, но будет ли это приниматься ГИС, не ясно.

По строкам - добавил запись в бинарные файлы. Спохватился, так как понял - если запишу структуру без обработки, то в файл запишется значение указателя на данные строки, а не сами данные. Ранее была поддержка текстовых файлов через совместимость с pchar. Точнее, совместимость не полная: нормально для обычных данных, но если "строка" содержит #0 в середине (например, не кодированные в base64 значения хэша/подписи), то запишется только часть до него.

По cryptoapi - обычно когда функция возвращает истину, не нужно смотреть GetLastError(), но в режиме отладки у меня вставлена функция которая принимает результат cryptoapi и название функции, вызывает GetLastError(), все выводит в консоль, а результат возвращает дальше (в условные операторы).

Выяснились 2 (пока) глюка: 1) после ошибки "не установлен криптопровайдер", даже если второй вызов (другого криптопровайдера) успешен, GetLastError возвращает тот же код, то есть код не обнуляется при успехе. Поэтому теперь делаю SetLastError(0) перед этим. Похоже, надо обнулять после каждой обработанной ошибки, иначе есть шанс получить код ошибки, которая была десяток операций назад; 2) если запросить контекст, ничего не сделать и закрыть его, то возвращается истина, но GetLastError показывает код ошибки "неожиданный конец данных ASN.1". Судя по поиску, у кого-то установка программ вываливается с эти кодом, весьма печально если причина - неочищенный GetLastError после открытия-закрытия контекста.

[QUOTE]Юлия Т. пишет:
[quote:3sejw7yv]Как я понимаю, задача квитирования - отследить то, что уходит "не туда" по поддельным квитанциям и принять меры чтобы предотвратить такие платежи.[/QUOTE]
А не проще ли было обязать операторов банков отслеживать реквизиты квитанций при приеме платежей? Либо вообще запретить операторам принимать платежи, все через терминалы, где левая квитанция точно не проскочит, так как не будут заведены реквизиты левой организации. С моей точки зрения, так проще, чем городить огород в ГИС ЖКХ.[/quote:3sejw7yv]Реквизиты будут подставлены автоматически, если запросить начисления из ГИС. Если не ошибаюсь, функционала запроса только реквизитов без начислений из ГИС не предусмотрено. Отслеживать вручную тоже не выход - у любого кассира в банке "глаз замылится" за рабочий день.Отслеживать автоматически - нужны электронные справочники реквизитов - приходим к ГИС.

К сожалению, терминалы не спасут. Потому что хотя реквизитов левой организации там не будет, но высока вероятность, что при смене реквизитов УК (в крупном городе) на каком-то терминале реквизиты не обновят. С другой стороны, мошенники уже это освоили и есть случаи, когда сами _терминалы_ были поддельными, все деньги оставались хозяину терминала.
[quote:3sejw7yv]Не все, некоторые банки уже реализовали функционал запросов начислений в ГИС ЖКХ по ЕЛС и идентификаторам платежных документов (видел такой функционал в Трасте).[/quote:3sejw7yv]К сожалению, что реализовали функционал - не значит, что они им пользуются. С одной стороны, банки тоже можно понять - ГИС сами видите как работает, а у банка есть нормы времени, за которое нужно обслужить клиента. Плюс там какие-то юридические заморочки, что если заполнена вручную платежка, то изменять (даже исправлять) ее оператору нельзя - надо отправить как заполнена. Однако оператор мог бы _уведомить_ клиента и _клиент_ мог бы _отозвать_ неправильно заполненную платежку и заполнить заново либо расписаться на автоматически сформированной платежке.[quote:3sejw7yv]А вообще - это следствие того, что в настоящее время нет реальной обязательности использования ЕЛС и, кроме того, большинство поставщиков ЖКУ (говорю по Владимирской области, в первую очередь крупные РСО) в настоящее время в ГИС ЖКХ и просто ничего не размещают (банкам просто нечего из ГИС ЖКХ взять даже если будет сделан запрос по известному ЕЛС).[/quote:3sejw7yv]Согласен, у нас в городе так до сих пор в квитанциях нет ЕЛС.[quote:3sejw7yv]Задача - возможность реального отслеживания платежной дисциплины и получение достоверных, полных и детальных сведений о её нарушении. При наличии этих сведений можно принимать адекватные меры по её повышению.[/quote:3sejw7yv]Это наверно слоган из выступления разработчиков ГИС? Или Минстроя?
Смотрите реально: сначала УК квитирует _вручную_ начисления (так как нет гарантии, что отправленные клиентом (и отраженные банком) деньги придут на счет УК) по реально полученным на счет, а потом сидит и отслеживает дисциплину по ГИС? С учетом, что практически у всех УК/РСО есть бухгалтерские/учетные программы по ЛС, а ТСЖ обычно поименно всех участников, не только должников знает, непонятно для кого такая "возможность реального отслеживания платежной дисциплины". Про "достоверные, полные и детальные" сведения вообще я бы не стал говорить.[quote:3sejw7yv]А вот с видимостью в ЛК потребителей фактов оплаты (сведений, размещенных банками) - беда.[/quote:3sejw7yv]Верно, хоть кашу платежей ГИС ЖКХ у меня нет возможности посмотреть, то же самое наблюдаю в ГИС ГМП. Точнее, реквизиты плательщиков ЮЛ прекрасно видны и даже назначения платежа почти вразумительные (где сокращено, где слова переставлены - человек разберет, но автоматом не сквитировать), а вот с ФЛ - беда. В большинстве "как бы указан" паспорт 1234 567890. Как я понимаю, серии 1234 пока не было, так что это 100% липовый паспорт. Назначение платежа вроде - "оплата штрафа", суммы "не бьют", попробуйте догадаться какого, если у человека их 10 штук висит. Или не указано ФИО в назначении и тот стоит тот липовый паспорт - от кого вообще пришло не понятно. Чуть легче, если фио нет, паспорт липовый, но есть реквизиты протокола "в свободной форме"- опять же вручную, автоматика не распознает. Понятно, что изначально проблема в отсутствии номера начисления в квитанции, банки при этом просто пишут 0.
Кстати, хочу поделиться прогрессом, раньше номер начисления был 20 знаков и включал русские/латинские буквы, так что было сложно различить русская или латинская буква. Банки этим оправдывали написание 0 вместо номера начисления. В новой версии форматов ГИС ГМП номер начисления 25 знаков и разрешены только цифры. Несмотря на это номера начислений в платежках банки все еще пишут нулевые.В случае ГИС ЖКХ наверно достаточно было бы указать правильный ЕЛС или реальный паспорт/СНИЛС.

[QUOTE]Юлия Т. пишет:
[QUOTE]two_oceans пишет:
Так что ждем-с, когда вообще отменят квитирование.[/QUOTE]
Думаете отменят? Если задача стоит отследить всю оплату в сфере ЖКХ, то вряд ли...[/QUOTE]Чуть выше:
[QUOTE]Sergey_P пишет:
Хотя слышал, что от квитирования скорее всего откажутся как обязаловки, будем ждать от Чибиса ослабительного приказа[/QUOTE]Если квитирование будет по желанию, то сомнительно, что кто-то в здравом уме пожелает квитировать вручную. Другой вопрос, что к этому могут вернуться чуть позже.
Как я понимаю, задача квитирования - отследить то, что уходит "не туда" по поддельным квитанциям и принять меры чтобы предотвратить такие платежи. Или почти собрались отключать должника, смотрите - а что-то от него должно прийти.. и отложили отключение на недельку, а вдруг плата реально придет.

А вот все финтифлюшки вроде отображения платежа в личном кабинете жителя - это больше попутные украшательства. Если платежа там не появится жители будут мозг банку выносить, а не УО. А видно там вообще статус квитирования?

Посмотрел.. оказывается в основной код openssl тоже добавили "Кузнечика" (Grasshopper) и хэш 34.11-2012 (смотрел в стабильных ветках, нашлось в 1.1.0g, в 1.0.2 еще вроде бы нет, точнее добавилось определение в crypto/objects/obj_dat.h) попробую ближайшие дни собрать 1.1.0g (или найти готовую сборку) и проверить есть ли в списке алгоритмов.

Вроде бы уже писал почему квитирование НЕ может быть автоматическим и все равно об автоматическом квитировании мечтают. Проблема в том, ГИС не биллинг, то есть банки вносят информацию в ГИС ЖКХ после того, как они приняли деньги, но до того, как деньги пришли на счет адресата. Если какой-то сбой в данных (например, поддельная квитанция - выглядит как Ваша, но с другими ИНН/КПП) платеж может вернутся с полдороги или вообще уйти непонятно кому и до Вашего счета не дойдет. Поэтому квитировать нужно только те платежи, которые реально пришли на счет и поэтому возникает проблема с двойной загрузкой - банк загружает платежи отправленные, УК загружает/квитирует платежи полученные (если кто загружает).
Так что ждем-с, когда вообще отменят квитирование.
[quote:2rp2sp32]посмотрите какую кашу банки вносят в ГИС.[/quote:2rp2sp32]Не в последнюю очередь каша из-за того, что банки не запрашивают данные из ГИС для формирования платежки, а вводят данные из произвольно заполненной платежки.
[quote:2rp2sp32]Вот и удивляюсь, почему так? Если мы в ГИС заносим наши лицевые счета, в банках и на Почте реестры начислений и оплаты идут с лицевыми счетами, почему не сопоставить по цепочке л/с учета в УК - л/с в реестре банка (Почты) - лицевой счет в ГИСе и убрать все лишнее в автоматическом режиме?[/quote:2rp2sp32]Про это тоже тут поясняли мне - иногда зачисляют все платежи единой суммой за весь день, а реестр никуда не уходит, передается сразу получателю, поэтому в середине цепочки сопоставить не с чем.

[QUOTE]Sergey Cheban пишет:
Я, честно говоря, предпочёл бы уйти от этой темы.[/QUOTE]OK.
[QUOTE]Sergey Cheban пишет:
Тем более с корневым ключом на три года (с учётом, что он окончательно сдохнет через полтора).[/QUOTE]1) Приобретение лицензий КриптоПро 4.0/добавление поддержки нового ГОСТ в Openssl займет некоторое время, а переделать каналы связи на туннели планирую до конца года (и неспешно осваивать новый стандарт в течение года).
2)Как я понимаю, запрет на гост-2001 касается схемы подписи и хэша, остальные алгоритмы благополучно переехали в новый ГОСТ, то есть, если 31 декабря 2018 года прекратить выпускать новые сертификаты (выпуск подразумевает их подпись), то выпущенными ранее можно будет работать (в плане шифрования соединения, не используя хеш 2001 года и не подписывая что-либо) еще до 15 месяцев (хотя это максимум срока клиентского сертификата в аккредитованных УЦ, во внутреннем УЦ можно и больше, но не буду зарываться). Срок сертификата УЦ должен перекрывать максимальный срок действия выпущенных им сертификатов чтобы цепочка доверия работала (в случае если не планируется его перевыпуск, на гост-2001 явно не планируется).
Теоретически возможно включить в новый сертификат УЦ сведения о ключе либо хэше старого сертификата, но полагаю это не сработает, если алгоритм хэша отличается. Во вложении пример 2 сертификатов одного УЦ, в сертификате 2014 года указан хэш оригинального сертификата 2012 года.
Общий срок действия сертификата УЦ при этих условиях составит (считая от сегодня до 1 января 2019 плюс 15 месяцев = 1 апреля 2020 года) 2 года 8 месяцев 10 дней, округленно 3 года. Так что через полтора года УЦ все еще будет действующим, но фактически не будет ничего выпускать/отзывать. Собственно, такая фаза (действующий, но не выпускающий новых сертификатов) предусматривается при любом выводе УЦ из использования. Конечно, все сертификаты, которыми нужно подписывать (не только шифровать) должны закончится раньше 1 января 2019 года и пройти замену на сертификаты с ГОСТ-2012.

Есть заминки - подписание списков отзыва (они должны быть подписаны тем же сертификатом УЦ, но если не отзывать, можно поставить срок действия "крайнего" списка отзыва с 31 декабря 2018 года до конца сертификата УЦ) и при авторизации по сертификату малый объем данных тоже подписывается (хотя никуда не сохраняется и дальше своего сервера уходить не будет, так что не такая уж проблема). Естественно, расчеты справедливы для OpenSSL туннелей и старых версий криптопровайдеров, в новый КриптоПро наверняка заложат запрет в том числе на авторизацию с 1 января 2019 года.[QUOTE]Sergey Cheban пишет:
Реализация гост для openssl есть в виде внешнего engine, подключаемого через конфиг: [URL=https://github.com/gost-engine/engine]https://github.com/gost-engine/engine[/URL]. Но - это и всё, кажется.[/QUOTE]Наверно этого и достаточно, его можно много куда прикрутить. Спасибо за ссылку, вижу, что ГОСТ-2012 там есть.[QUOTE]Sergey Cheban пишет:
В NSS (firefox, chrome, thunderbird etc) госта нет[/QUOTE]Могу ошибаться, но дело как правило в использовании старой версии OpenSSL (0.9.8, в которой ГОСТ не было - в каких-то программах как внешние библиотеки, в каких-то вкомпилированы в саму программу) и в системе управления сертификатами. КриптоПро, например, выпускает свой клон Firefox с поддержкой ГОСТ. Еще есть dll hell библиотек OpenSSL (они как правило лежат в папке программы, но недавно на ПК с XP обнаружил в windows/system32 обе библиотеки версии 0.9.8, попробовал заменить на 1.0.2 - защита системных файлов на них не сработала, не Майкрософтовские файлы, dll hell в полный рост) и отсутствие на среднем ПК под Windows файла конфигурации OpenSSL и переменной окружения на него указывающей. Есть подозрение, что если проблемы разрешить и настроить, добавить корневые сертификаты, то и в Firefox стандартном (хотя после таких модификаций сложно назвать стандартным) внезапно появится ГОСТ. Проблемы совместимости клиентских сертификатов с Firefox пропускаю.[QUOTE]Sergey Cheban пишет:
Российских корневых сертификатов нет по умолчанию в windows и браузерах, хотя процедура включения известна.[/QUOTE]Это логично: если Windows гостовские корневые примет в программу, даже если только сертификаты ГУЦ, то должна будет поддерживать алгоритм ГОСТ "из коробки". Однако, это будет означать, что, например, ФСБ получив в ГУЦ сертификат своего УЦ сможет получить некий доступ ко всем ПК с Windows. Американские спецслужбы просто не согласятся добавить ГУЦ, как и другие УЦ, которые не аккредитованы у них. Конечно, частично проблему бы решило включение ГУЦ и поддержки ГОСТ только в русские версии. С браузерами чуть попроще, но фундаментально проблема такая же - кроме включения корневого сертификата нужна еще поддержка алгоритма.

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

[QUOTE]Sergey Cheban пишет:
Как-то так (в очень упрощённом изложении и не затрагивая взаимодействие этого процесса с другими событиями).[/QUOTE]Ясно.. впрочем, разово не значит одновременно и все выключить. С учетом сказанного, а если так: переключить один жесткий диск на только чтение, скопировать, перевернуть данные на копии, подключить копию к новому хранилищу для чтения, протестить, при успехе перенести процессы связанные с данными на том диске на little endian компьютер (то есть создание процесса на LE, тест процесса, запрет процесса на BE), включить полный доступ на копии, исходный диск отключить (до конца переноса всех дисков), скопировать следующий диск и т.д. При ошибке - откат шага (запретить процесс на LE, отменить запрет на процесс BE, полный доступ на исходный диск), проанализировать что "не так" и повторить с учетом исправлений. Если процессы включают резервирование, то проблем с переключением одного диска на чтение вообще не должно быть, но будет проблема с дифференциальным копированием и его переворотом. Однако "разницу" обработать еще быстрее чем целый диск, так что это тоже решаемо.
В этом случае тоже потребуется некое ПО для копирования и правильного переворота, но его можно сделать сильно упрощенным по сравнению с бизнес-ПО для каждого endian, так как переворот можно заранее отладить по каждому типу файлов.[QUOTE]Sergey Cheban пишет:
Внутренний - беспроблемнее на RSA делать, imho. По крайней мере, там криптопровайдеры во всех ОС из коробки доступны и бесплатны. ... Но если хочется гост, то, конечно, "безумству храбрых поём мы песню".[/QUOTE]На американских алгоритмах уже есть внутренний УЦ (Майкрософтовский) в домене. При установке компонента УЦ можно было выбрать ГОСТ (КриптоПро 3.6 на сервере тоже есть), но вроде бы варианты взаимоисключающие. Там тоже свои заморочки - ставить IIS для веб-интерфейса я не хочу (много дыр), а из оснастки сертификаты можно только фиксированные типы сертификатов ("профили") запрашивать, несоответствующие профилю расширения можно заполнить, но их срезает при выпуске сертификата. Например, в сертификат для сервера терминалов я хотел включить и доменное имя и IP-адрес, но IP срезался. Теперь если зайти по IP, то предупреждает "сертификат не соответствует имени узла". Как добавлять профили - не разбирался. Мне наверно проще будет сделать подчиненный УЦ в OpenSSL, приладить к нему интерфейс HTA и издавать там, чем разбираться в надуманных ограничениях УЦ Майкрософта.

По ГОСТ: проблема даже не в том, что "хочется" ГОСТ - персональные данные передающиеся из одного подразделения в другое подразделение по общей сети провайдера должны быть защищены ГОСТ. Хотя сеть провайдера практически как локальная, но это не отменяет необходимость ГОСТ. Сейчас сетевая связность настроена, как обычная VPN (средствами Windows, а VPN нужна для обхода ограничений Windows по маске) и с этим 2 проблемы: 1) шифр не ГОСТ, ключ смешной длины. Для более надежного нужно серьезно разбираться с политиками VPN; 2) VPN соединение нужно устанавливать вручную. Конечно, можно настроить различные сценарии автозапуска, только со всеми одна проблема - допустим, соединение установили, потом я перезагрузил сервер, сервер считает соединения разорванными, но на клиенте соединение все еще считается подключенным! Чтобы работало его приходится вручную разъединить и подключить снова (ну или перезагрузиться).
Есть всем известное решение - Vipnet клиент, вот только там: 1) много лишнего, в данном случае нет необходимости шифровать ВСЕ соединения, фильтровать посторонние; постоянно запрашивает пароль на контейнер при входе, компьютер существенно тормозит; 2) клиент должен подключаться к координатору либо нужно по координатору в каждом подразделении + если сеть своя нужен комплекс администратора, в итоге выходит дорого; 3) конфликтует с КриптоПро - можно разрулить, но работать будет один криптопровайдер. Есть какое-то VPN решение от КриптоПро, подробности не узнавал, но тоже тянет на круглую сумму.

Для ГОСТ-2001 есть реализация stunnel (на основе исходников OpenSSL), то есть для внутреннего использования подойдет, дело только в сертификатах. Более того есть версия stunnel работающая с КриптоПро (так уж получается, что на большинстве ПК с персональными данными КриптоПро уже установлен), есть библиотека позволяющая из OpenSSL использовать сам КриптоПро (к слову, позволяет настроить веб-сервер с 2 сертификатами: один для ГОСТ с поддержкой TLS 1.0, другой обычный американского алгоритма с поддержкой TLS 1.2). Такая библиотека выручит, если вдруг кто скажет, что конкретная сборка OpenSSL не сертифицирована. Как я понимаю, туннель устанавливается для каждого входящего отдельно, то есть вручную переподключать тоже не надо. Для конкретной задачи - идеально.
Естественно для внутреннего использования сертификаты не стоят всех заморочек/денег получения в аккредитованном УЦ, да и российские УЦ все больше на ФЛ, ИП и ЮЛ ориентируются, внести дополнительное имя для сертификата узла или наименование ИС целая проблема. Поэтому все сводится к еще одному внутреннему УЦ с ГОСТ на OpenSSL, где я смогу рулить составом сертификата как пожелаю.

С ГОСТ-2012 будет проблема при отсутствии реализации в OpenSSL. Хотя и тут есть шанс попробовать библиотеку связывающую OpenSSL и КриптоПро, а вдруг она сумеет из КриптоПро 4.0 ГОСТ-2012 подключить (помечтать не вредно, но с учетом, что библиотека до сих пор TLS 1.2 не может обработать - маловероятно). Похоже все идет к тому, что придется сделать три версии внутреннего УЦ (с ГОСТ-2001 на 3 года, с RSA  и ГОСТ-2012 до 2040 года).

[SIZE=85px][COLOR=greenpt]Отправлено спустя 22 минуты 16 секунды:[/COLOR][/SIZE]
[QUOTE]Sergey Cheban пишет:
И второй позор - отсутствие бесплатной реализации и прочие vendor lock'и[/QUOTE]OpenSSL доберется и до него, вопрос времени.

[QUOTE]Sergey Cheban пишет:
int или строку.[/QUOTE]В этом смысле да, драйвер скорее может порядок посылки по времени в протоколе устройства поменять (что и делается в USB).[QUOTE]Sergey Cheban пишет:
внимательно расставить ntohl/htons по всему коду (при этом кода много, цена ошибки велика, да ещё и производительность может пострадать[/QUOTE]Как мне кажется, если уже есть перекомпилированный рабочий код на другую платформу, то весь вопрос в разовом перевороте данных на диске (с учетом длины переворачиваемых частей). То есть выяснить местоположение и размер каждой части и перевернуть. Усложнять весь код из-за необходимости разовой операции как-то черезмерно рискованно. А при разовой операции, какая бы она не была долгая, про урон производительность речи не идет.[QUOTE]Sergey Cheban пишет:
Криптопровайдер надо обновлять уже сейчас (я так понимаю, что нужен криптопро 4.0).[/QUOTE]Ну готовиться-то конечно можно, вот только новая версия криптопровайдера это еще и новые константы во всех функциях, морока еще та. Судя по прошлым версиям, КриптоПро никак не может протащить одно название и значение константы в следующую версию. Конечно за год ничего не улучшится, но уже будет некий гайд от тех кто наткнулся на подводные камни.

Меня вот озаботило другое - я думал делать внутренний УЦ на ГОСТ-2001 и корневой сертификат до 2040 года бахнуть (подчиненный УЦ лет на 5 и сертификаты на ПК (машинные) года на 3). Но если ГОСТ-2001 придется менять через полтора года, то наверно надо сразу ГОСТ-2012 закладывать. Вот печаль-то.[QUOTE]Sergey Cheban пишет:
Сейчас, по идее, старый гост пока должен работать (как на самом деле, не знаю). Я бы предположил, что ГИС требует хоть какой-нибудь ГОСТ, но именно ГОСТ, а не американские алгоритмы. По умолчанию ГОСТа нет ни в windows, ни в браузерах.[/QUOTE]Все так, проблема в том, что все сделано по инструкции: установлен КриптоПро 3.6, cades plugin и настроены доверенные узлы в IE - сайт налоговой говорит ГОСТ-2001 есть, тестирует и переключается на него в HTTPS, при этом ГИС ЖКХ говорит "ГОСТа нет" в том же браузере. И соединение с помощью OpenSSL на сайт ГИС ЖКХ с шифросьютом гост-2001 тоже не проходит, выбирается американский алгоритм. Потому у меня и возникли подозрения, те кто говорил, что сообщение не выдает присылали скриншоты с Windows 8.1 или 10, на которых нужна новая версия КриптоПро (которая попутно поддерживает новые шифры).

Ну как бы очевидно, биллинговая должна доработать ИС, если [U][B]хочет[/B][/U] распознавать ГУИД ФИАСА (именно он сейчас официальный справочник адресов, а дублирование другими справочниками тоже каким-то нпа запрещено) - есть выгрузки ФИАС по регионам (даже можно отфильтровать до города по ОКТМО) и если их загрузить в ИС биллинговой, тогда будет гуид распознаваться. Для временных адресов, которых нет в ФИАС - есть выгрузка из ГИС ЖКХ (аналогично фильтруется по регионам и октмо).

Еще вариант - есть веб-сервисы, которые уже загрузили и теперь переводят данные из гуид в адрес для других. Формат запроса/ответа ajax - гораздо проще чем SOAP. Другой вопрос, если дорабатывать не хотят, тогда может другой биллинг поискать (по крайней мере, можно вооружиться НПА, что "гуиды нужны вот так" и припугнуть что поищите, если не доработают).

[QUOTE]Sergey Cheban пишет:
У тех, кто думает о безопасности, свои профессиональные привычки. Они стараются не передавать ничего лишнего, потому что "всё, что вы скажете, может быть использовано против вас".[/QUOTE]Логично, доходит до того, что вводят специальную задержку, чтобы по времени обработки нельзя было определить на каком этапе ошибка по уменьшению длительности. Но это - внутри одной операции проверки, я не понимаю, как добавление второй целой операции (то есть тоже выровненной по длительности), срабатывающей при неправильном ответе, может создать дополни-тельную угрозу. И тем более как ее может создать изменение ответа на один из 2^256 вариантов хэша. В принципе, понятно, что безопасность и комфорт не очень совместимые понятие.[QUOTE]Sergey Cheban пишет:
Навскидку - посмотрите на byte order mark, позволяющий отличить little-endian utf-16 от big-endian utf-16.[/QUOTE]В скомпилированных программах конечно utf-16 широко используется, но в веб (и соответственно БД для веб) большая часть Юникода - utf-8. И в utf-8 byte order mark скорее сродни чуме чем спасению - большинство программ (включая браузеры) впадают в различные баги, встретив byte order mark в середине файла, а некоторые и в начале. Поэтому концепт создания страницы из кусочков приводит к тому что надо из всех кусочков byte order mark убрать, указав кодировку другими средствами.[QUOTE]Sergey Cheban пишет:
big-endian железо, которое пишет данные на диски в своём родном формате[/QUOTE]Мысль уловил, головняк изрядный, хотя пример про железо наверно не очень удачный, так как данные пишут диски, но и читают тоже они. Те же самые big-endian жесткие диски подключенные к одной платформе и к другой платформе прочитают то же самое, другой вопрос, что драйвер, работающий с ними должен будет данные перевернуть перед передачей прикладным программам. В зависимости от разных факторов, часть данных возможно не придется преобразовывать в программе после этого, но преобразование других данных может еще больше запутаться. Кстати, и под x86 некоторые устройства (вроде бы даже USB, внезапно) работают в big-endian, но мы этого не замечаем, потому что драйверы справляются. С оптическими дисками наверно хуже, не знаю есть ли там byte order mark.[QUOTE]Sergey Cheban пишет:
Я не в теме, но гугл подсказал, что не совсем так:[/QUOTE]Спасибо за ссылку, почитаю. На функции генерации как-то не обратил внимание, тем более что это не "майкрософтовская" функция, а именно "криптопрошная", которую "майкрософтовская" вызывает внутри после нескольких промежуточных шагов.[QUOTE]Sergey Cheban пишет:
Я опять же не в теме, но сдаётся мне, что правильно будет отказаться принимать такой сертификат от греха подальше: если мы будем принимать разные параметры криптоалгоритма, то злоумышленник сможет предложить нам наименее криптостойкие параметры.[/QUOTE]Логично, но как-то неправильно. Российские УЦ не сообщают клиентам практически никакую техническую информацию о будущем сертификате. Пару недель назад добивался от сотрудников регионального отдела продаж одного из крупнейших УЦ - добился только что в выбранный сертификат для ЭП-ОВ не будет включена персональная информация и что в других ИС кроме СМЭВ он вроде бы не должен работать (как мне и надо). Внятно объяснить какие именно расширения сертификата и значения расширенного использования будут в сертификате они не могут, максимум назвать тарифный план и спросить у кого-то будет ли работать на определенной ИС. Меня три раза переспросили действительно ли я хочу чтобы не работало. Про параметры хэша, полагаю, они даже не слышали.

Итого, покупая сертификат и платя денежки, клиенты УЦ покупают "кота в мешке". Шанс, что кто-то намеренно поменяет параметры хэша в сертификате хоть и не нулевой, но и для рядового клиента не велик. Зато велик шанс, что кто-то не зная ничего получит сертификат с нестандартными параметрами хэша и если мы его отклоним - попадет на деньги, так как придется заказывать сертификат в другом УЦ (в том же УЦ выдадут с теми же параметрами скорее всего). Нехорошо как-то. УЦ молодцы, в заявке на изготовления сертификата включен пункт, что клиент соглашается, что УЦ не несет ответственность за невозможность использования сертификата в определенной ИС.[QUOTE]Sergey Cheban пишет:
Я так понимаю, что "1.2.643.2.2.30.1" - это старый гост.[/QUOTE]Не вдавался настолько в тему про новый ГОСТ, с текущим бы разобраться, но попадалась на глаза [URL=https://www.osp.ru/lan/2016/06/13049759]статья[/URL] про будущий стандарт. Во-первых, разработчики стандартов всех уже запутали с 34.10 (вроде бы алгоритм шифрования?), 34.11 (алгоритм хэша) и 34.10/34.11 (алгоритм подписи, из которого умудряются тоже сократить до 34.10). Во-вторых, ГОСТ то может и новый, но в его рамках переопределены большинство алгоритмов из старого (названы "Магма", все те же с 1989 года) и добавлен новый "Кузнечик" (34.[B][U]12[/U][/B]-2015). Хэш тоже добавился новый "Стрибог" (34.11?-2012), с длиной 256 для "Магмы" и 512 для "Кузнечика". А еще режимы блочных шифров определили в 34.13-2015.
Путаница изрядная, ясно только, что с 2019  года нужно обновить криптопровайдер на поддерживающий новый хэш и видимо сгенерить новые ключи (с учетом что ключи как правило на год, ничего существенно нового - и там постоянно меняем). В итоге, надо будет сесть и хорошенько разобраться, что именно они понимают под схемой подписи 34.10-2001 (видимо ГОСТ Р 34.11-94/34.10-2001) и чем отличается от нового ГОСТ 2012 года. Судя по очередности принятия стандартов, исключительно хэшем. Пользователей OpenSSL полагаю тоже очень обрадует в 2019 году, если новый ГОСТ не будет там поддерживаться к тому времени (не изучал вопрос поддерживается ли сейчас). Кстати, не новый ли ГОСТ требует ГИС ЖКХ, когда ругается, что нет согласованного ФСБ алгоритма.

Про текущую поддержку новых ключей ничего утешительного сказать не могу - буквально вчера пытался установить сертификат с 2012 в алгоритме на компьютер, где криптопро 4.0 и континент-АП 3.7... вот я Вам скажу "засада" - открываю сертификат из оснастки сертификаты все нормально, открываю тот же сертификат с рабочего стола: "Произошла ошибка при  проверке отношений сертификатов", "Сертификат содержит неверную подпись". Как я понял, континент теперь тоже содержит свой криптопровайдер и криптопро (выставленный "по умолчанию") не может проверить сертификат, выпущенный континентом. А из хранилища сертификатов, где проставлена ссылка на контейнер, открывается криптопровайдер континента и все нормально. Причем в криптопро основной алгоритм 2001 года (логично, что 2012 не понимает. попробовал переключить на 2012, но отличий не заметил), а континентовский криптопровайдер не виден в списке (значит тип не такой, как у криптопро, но реализует те же алгоритмы).
Еще смешнее - похоже они поставлены в комплекте, так как для прошлого континента требовался криптопро, а компьютер сертифицированный и удалить криптопро нельзя. Конечно континент работает, проблема не критична, но конфликт - нехороший признак.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 7 минуты 3 секунды:[/COLOR][/SIZE]
[URL=http://intsysjournal.org/articles/is2001/04_kurganov.pdf]Еще статья[/URL]

[QUOTE]Sergey Cheban пишет:
Вот не надо так делать. Надо - понимать, кто в каком формате данные получает и предоставляет, и переворачивать правильным образом. [/QUOTE]Ну, потому и стоит смайлик, что "вредный совет". Про четко прописанные форматы и речи как бы нет, я не говорю, что после переворота и второй проверки подпись следует принять, но вывод ошибки "Похоже использован неверный endian, используйте big endian, определенный по стандарту" был бы более информативен для начинающих разбираться в теме (и копирующих примеры, не понимая их), чем просто "Плохая подпись".

Хотя, например, не понятно почему XMLDSIG, в котором почти все указывается параметрами (хотя для некоторых допустимое значение определено только одно! как для кодировки - Base64) не требует указывать big-endian явно в DigestValue и SignatureValue, а жестко определяет порядок байтов в базовом типе. Это бы тоже натолкнуло копирующих примеры (без чтения правильного, но мозгодробительного стандарта) на правильные мысли. Сетевой порядок байтов - это конечно хорошо, но фактически под win32 на intel x86-x64 программисты сталкиваются с ним главным образом при кодировании ip-адреса (и там он воспринимается скорее как "плагиат реализации IP протокола с линуха"). И наверно все, навскидку не припомню других широко распространенных применений.
А вот про "самописные" форматы, которыми славятся российские программы, вообще мрак.

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

Еще момент, который тоже хочется "перебрать" - возможность нахождения в контейнере 2 пар ключей: одна - типа AT_SIGNATURE, другая типа AT_KEYEXCHANGE. Формально первый тип предназначен для подписи, второй для согласования ключей. cryptoapi требует их указания и выдает ошибку, если такого типа в контейнере нет. КриптоПро их тоже различает и позволяет засунуть в один контейнер. Вот только: 1) могу ошибаться, но криптофункциям ГОСТ похоже все равно на тип ключа, подписывает ключом AT_KEYEXCHANGE без проблем; 2) пока не встречал контейнера КриптоПро c 2 ключами или контейнера с AT_SIGNATURE. Из объяснения (ссылка ниже) смутно понял, что AT_SIGNATURE имеет ряд ограничений использования в приложениях Майкрософт. С другой стороны, прописывать в программе AT_KEYEXCHANGE неправильно, вдруг встретится контейнер с AT_SIGNATURE. Пока указал AT_KEYEXCHANGE, но раздумываю может быть, помимо указания только одного типа, ввести ли для библиотеки значения вроде KEYEXCHANGE_FIRST и SIGNATURE_FIRST, позволяющие указывать предпочитаемый и при этом перебирать ключ второго типа, если предпочитаемый не нашелся. Коллеги, какие мысли на этот счет?
[quote:a7ukqisi]... US crypto exporting restrictions were only regarding strength of encryption keys but not signature keys. Microsoft was required to provide prove to the government that they never allow signature keys to be used for encryption purposes before they were allowed to ship Microsoft encryption modules with Windows. ... This all is explanation of why you get keyusage restrictions with Microsoft CSP, but not with thirdparty CSP.[URL=http://www.derkeiler.com/Newsgroups/microsoft.public.platformsdk.security/2005-06/0089.html]Ссылка[/URL][/quote:a7ukqisi]Похоже история тянется со времен, когда были ограничения экспортной криптографии в США и с российскими криптопровайдерами не связана.

Открываю сертификат через ASN.1 Editor, в нем есть ветка с ключом, для нее указан OID 1.2.643.2.2.19 (ГОСТ Р 34.10-2001, алгоритм подписи, открытый ключ), параметры: 1.2.643.2.2.36.0 (ГОСТ Р 34.10-2001, алгоритм подписи, параметры [B]обмена[/B] по умолчанию), 1.2.643.2.2.30.1 (ГОСТ Р 34.11-94, хэш функция, параметры по умолчанию). Алгоритм хэша ГОСТ Р 34.11-94 (OID 1.2.643.2.2.9), в сертификате не виден. В целом алгоритм хэша/подписи ГОСТ Р 34.11-94/34.10-2001 имеет OID 1.2.643.2.2.3, указан в самом начале сертификата.
Как я понимаю, 1.2.643.2.2.36.0 - это как раз парамсет (в данном случае exA) и по слову "обмена" похоже цифра 36 помимо прочего как раз указывает, что это ключ обмена, то есть AT_KEYEXCHANGE. В примере настроек OpenSSL парамсет указан как A, по аналогии - это AT_SIGNATURE. Выходит если в программе жестко прописать AT_KEYEXCHANGE, то будет беда с ключами сгенерированными в OpenSSL? Попробовать считывать из сертификата парамсет и по нему определяться какой ключ?

Не разобрался еще вот с чем - получаю hcryptprov с пустым ключом и флагом VERIFY_CONTEXT и создаю хэш, запрашиваю CryptGetHashParam с кодом HP_OID (0xA) и получаю "1.2.643.2.2.30.1" и по параметрам хэша КриптоПро контрольные значения совпадают. [URL=http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1323]Тут[/URL] и [URL=http://forum.foxclub.ru/read.php?29,562068,page=2]тут[/URL] утверждается, что если возвращает "1.2.643.2.2.30.1" то все вообще окей, а иначе надо устанавливать при проверке хэша/подписи то же значение параметров, что было при вычислении хэша/подписи. На форуме КриптоПро то же самое пишут.
Вопрос: а что указывать, если в сертификате окажется другое значение параметров хэша.. значение из сертификата только на проверку самого сертификата распространяется или на все операции с сертификатом? Ну в смысле вычисление хэша конечно идет без участия ключей и сертификата, но если хэш потом нужно подписать и приложить сертификат, то не будут ли параметры хэша для проверки считаны из сертификата? Значит их наверно нужно синхронизировать с сертификатом при вычислении подписи и проверке подписи. А что с другими хэшами в XMLDSIG - тоже согласовывать по сертификату? Итого: похоже все работают на параметрах по умолчанию и если их изменить вылезет масса недоработок в различном ПО, входящем в цепочку передачи данных.

За полмесяца у меня по теме прошел прогресс. Причина - наехали из структурного подразделения насчет подключения к ГИС ГМП. Служебная записка с объяснением что и как потянула на 5 страниц, скажу кратко: там тоже ЭЦП в SOAP. Причем не одна - запрос инкапсулируется в пакет СМЭВ, подписанный подписью ИС отправителя, при этом в запросе может быть до 100 начислений/платежей, каждый из которых подписывается тем, кто данные сформировал, не обязательно ИС отправителя - это могут быть структурные подразделения и подведомственные учреждения. При этом структурные подразделения не могут зарегистрировать ИС в СМЭВ, так что забота об ИС выпадает головной организации. Когда приходит к получателю на пакет еще наматываются ЭЦП всех узлов СМЭВ через которые пакет проходил.

В общем, с такой мотивацией я взялся за дело. На данный момент образовалось целых 3 слоя функций ниже объекта подписи: один хранит сертификаты независимо от криптопровайдера, второй определяет доступность и загружает определенный криптопровайдер (то есть независим от контейнера), третий выполняет собственно операции на определенном криптопровайдере (с указанным контейнером). По OpenSSL третьего слоя пока не доделал, зато вник в Майкрософтовский.

Весьма интересно спроектировано - hcryptprov как оказалось - не просто дескриптор криптопровайдера, а криптопровайдера с указанной ключевой "парой". Ключевая "пара" может быть пустой и запрос КриптоПро на выбор ключа не выводится, если указаны флаги NEW_KEYSET или VERIFY_CONTEXT, правда и подписать ими не получится. В первом случае ключевую пару нужно сгенерировать прежде чем подписывать, а второй используется для операций не связанных с закрытым ключом - вычисление хэша и проверка подписи. Для проверки подписи можно загрузить сертификат (например, считанный и перекодированный из проверяемой XMLDSIG) либо чисто данные ключа либо найти сертификат в хранилище (поиск пока не проверял) и получить дескриптор открытого ключа.

Насчет переворачивания байтов все подтвердилось: ms cryptoapi возвращает результат в little endian, а xmldsig-core стандарт предусматривает 2 типа ds:CryptoBinary и base64Binary. Оба определяются как big-endian bitstring, дополненная нулевыми битами слева до целого количества октетов (байтов). Обе кодируются в Base64. Отличие в том, что в ds:CryptoBinary байты слева, равные нулю, выкидываются перед кодированием, а в base64Binary остаются. Итого - в результате возвращенном ms cryptoapi нужно отзеркалить порядок байтов (не просто поменять endian по 2 или 4 байта как можно подумать, а самый первый из 32 байт с тридцать вторым, второй с тридцать первым и т.д.) перед кодированием в Base64, а при проверке отзеркаливать еще раз между декодированием Base64 и проверкой.

Еще интереснее выяснилось с .Net - там возвращается big-endian (лично не проверял), то есть для xmldsig переворот не нужен, просто кодирование/декодирование Base64. Однако, если пытаться проверить подпись .NET средствами ms cryptoapi (и наоборот) без переворота проверка провалится. То есть в подписи нет признака порядка байтов - если проверка выдала ошибку попробуйте перевернуть и проверить еще раз.  :lol:
Дальше - больше, в целях защиты от подбора закрытого ключа при подписании каждый раз генерируется случайное число, то есть подписав 2 раза подряд одни и те же байты данных получите 2 разных последовательности байтов подписи. Таким образом, проверить работу алгоритма подписи сравнением не выйдет. Это отражается и на наборе функций - есть функция CryptSignHash, подписывающая (то есть шифрующая) вычисленный хэш с использованием закрытого ключа текущей ключевой пары и есть CryptVerifySignature проверяющая подпись по уже вычисленному хэшу и открытому ключу. В смысле проверяющая математическую корректность подписи, проверка сертификата не включена. Комбайн CryptSignMessage все же предназначен для cades. Еще пришлось переписать определение функции CryptStringToBinary, которая, по идее, может использоваться для декодирования Base64. Как выяснилось, зря время тратил, практически она настолько навороченная, что использовать не получается, об этом ниже.

Впечатлившись всем этим, написал слой обработки для ms cryptoapi и решил протестировать (первый раз с февраля) что получилось. Программа конечно выпала (один раз по range checking, второй по access denied), причину на 100% не установил, зато нашелся баг в модуле длинных строк - при освобождении запись передавалась по значению, а не по ссылке. Обычно мне это не мешало, так как освобождаю в конце функции и переменную больше не использую. А тут ловил выпад и обнаружил, что после освобождения в переменной длина ненулевая и остался адрес на освобожденную память.

Передал по ссылке, падать перестало и я получил от cryptoapi ошибку 0x80090017 (не найдено криптопровайдера нужного типа). Установил КриптоПро, получил хэш примера (который тест для плагина на сайтк криптопро) и удивился - не совпадает. Ладно, нашел примеры на саму функцию хэширования - не совпадает. Приглядевшись к передаче данных выяснилось, что хотя обычно строку надо передавать включая в длину нулевой символ (иначе тот самый access denied выпадает, когда winapi нулевой символ ищет), то в функцию хэширования передается длина без нулевого символа! При этом примеры хэша стали совпадать, но хэш примера с сайта - нет. Значит... каноникализация все же нужна нужна. Попытки привести вручную не удались. Сегодня поищу еще примеры, может быть найдется уже каноничный текст. Конечно, если функция хэширования на примерах работает нормально, то можно и без тестов попробовать все собрать в каноничный xml (ну то есть каноничными должны быть только части попадающие под хэш и подпись) и отправить на СМЭВ, но вот при получении и проверке подписи номер не пройдет - не факт, что придет каноничный xml. Так что, собственно сейчас занят поиском годной каноникализации без .Net и Java. Уже есть 3 варианта модулей: из комплекта компилятора, uXMLHelper, TclCanonicalizer. Тест покажет, годные ли. Из последнего уже пришлось выкинуть несколько строк, а типы дописать.

Кстати, касательно СМЭВ, похоже будет логичнее помимо тега Signature добавлять той же функцией и обертку тегом Security при определенном значении параметра формата. Свойства сертификата ГИС ЖКХ и метка времени узлов СМЭВ тогда тоже будут дополнениями.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 42 минуты 4 секунды:[/COLOR][/SIZE]
Да, CryptStringToBinary оказалась суперкрутой функцией - в качестве параметра принимает тип кодирования строки, а на выходе должен быть массив байтов и действительный формат строки плюс количество символов не соответствовавших формату. Вот только проблема, что форматов функция "понимает" много и когда я передаю строку 44 байта в base64 ожидая получить 32 байта подписи... функция возвращает 62 ! байта, причем все они печатные символы - кажется, фактически вместо декодирования base64, функция кодирует их в base64 еще раз. Видимо не зря ее определение было косячным (и ссылка на импорт запорота): чтобы никто не использовал.

Ну ладно, в комплекте компилятора есть модуль кодирования, работающий с base64. Конечно прыгающая ansistring и короткая shortstring не лучший выбор, но на 32 байта казалось бы - вот оно! И снова нет, на этот раз декодирует прекрасно, но кодировать отказывается (причину пока не выяснял, возможно непечатные символы мешают). Ну тут выручает CryptBinaryToString, которая по-честному из массива байтов делает строку Base64. Вот так из 2 хромых модулей получилось нечто рабочее  :D

[QUOTE]skad888 пишет:
Вы на полном серьезе намерены работать в системе которая НЕ РАБОТАЕТ и НАФИГ НИКОМУ НЕ НУЖНА?[/QUOTE]Как бы то ни было, альтернативы нет - приходится работать. Хотя про серьезность не буду утверждать. :lol:
Вы не поверите - КОМУ-ТО НУЖНА! Специалистов ОМСУ сейчас вообще загрузили по модулю "Комфортная среда" ГИС ЖКХ, финансирование идет по материалам, размещенным там, так что приходится "по-серьезному" заполнять. Конечно, я в глубокой печали от того,  какие планы местности размещают наши отделы - без чертежного шрифта, рамки, указания масштаба, масштабной линейки, сторон света и т.д., но серьезность вопроса на лицо. Отдельная песня - прислали "макеты" для информирования жителей... в PDF! При том, что макет (веселенький кстати!) для какого-то дома в областном центре и его придется править.  rev
При этом по ОЖФ одноэтажных домов (которые не МКД) все еще многих нет, по субсидиям пока что-то тишина, раз не зовут - значит или все работает по плану или вообще накрылось.
[QUOTE]skad888 пишет:
а если одной суммой разместить ... можешь? дешевле будет?[/QUOTE]Что-то мне это напомнило разговор из басни: можно из этого меха 2 шапки сшить? конечно, можно, еще останется! Тогда, а 20 шапок можно? Можно! вышло 20 шапок , только размером каждая как на яблоко.

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

Ну так-то перемножить, это только начало. Если квартира площадью не в целое количество метров, то ГИС выдает 3-4 цифры после запятой, то есть дробные копейки, которые потом "выравнять" головная боль. Да и про долг ГИС ничего не знает. Тогда вообще загрузка шаблона получается "для галочки" - площадь и так должна быть в ГИС, с тарифы и реквизиты тоже.

[QUOTE]Programmer пишет:
А вот здесь в строке 13 графа T (входящий долг) стоит -500 рублей, и все проходит нормально. Значит, проблема в строке "Услуга предприятия".[/QUOTE]Спасибо за эксперименты. Похоже, что так. А если "услуга предприятия" все же в дополнительный ПД на листе ДПД заносить, пройдет? И до полного комплекта краш-тестов посмотреть, а с какой-то из "нормальных" услуг будет ли ошибка если к оплате выйдет отрицательное число? Если вдруг пройдет, то точно все мои первые догадки были мимо, но хотя бы со строкой угадал.[QUOTE]skad888 пишет:
заполняю всегда так:[/QUOTE]То есть расчет остается на ГИС?