new_year

До бесплатного семинара в Москве осталось

  • 2
  • 2
дня

До бесплатного семинара в Самаре осталось

  • 2
  • 0
дней

Форум

ГлавнаяГИС ЖКХ: Предложения по информационному обмену

ГИС ЖКХ: Предложения по информационному обмену

RSS
ГИС ЖКХ: Предложения по информационному обмену
 
Цитата
AlcorVol пишет:
Я - разработчик. Но разрабатывать "коммерческую ИС" не собираюсь. Буду дорабатывать софт для УК, ориентируясь на формирование и передачу файлов. Пока - в XLSX-формате.

Аналогично. Хотя бы с XLSX разобраться, для начала. Трата времени на интеграцию в эти дни разбитым корытом попахивает.
 
Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела. Десятка систем вполне хватило бы для конкуренции. Ну ок, пусть два десятка (в расчёте на то, что половина со временем сдохнет). А больше - зачем? Сейчас вместо десятка сильных команд разработчиков мы имеем множество слабых.
Извините, но эти вопросы решаются только рынком. А не Вашими личными соображениями на тему, что было бы полезно, а что вредно. И сколько команд разработчиков тут требуется.
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.

Цитата
AlcorVol пишет:
Я - разработчик. Но разрабатывать "коммерческую ИС" не собираюсь. Буду дорабатывать софт для УК, ориентируясь на формирование и передачу файлов. Пока - в XLSX-формате. УК/ТСЖ тоже не хотят становиться "ИС". Их вполне устроила бы загрузка файлов в ЛК.
Ну, может быть, разработчики и пойдут Вам навстречу и сделают загрузку данных через личный кабинет в удобном для генерации формате.

Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Хороший разработчик сделает в своём продукте интеграцию с ГИС ЖКХ.
Статус ИС почти никому на практике не нужен. Каждое ТСЖ - самостоятельная информационная система? Маразм!
Если ТСЖ разрабатывает свой софт, ведёт свои базы данных и т.п., то оно и есть информационная система. А если у нас ТСЖ на четыре квартиры, то ему и XLS хватит.

Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Я пока что не очень понимаю, чем Вам SOAP не угодил в качестве бесплатной альтернативы. Разработчики ГИС ЖКХ, помнится, на каком-то из вебинаров рассказывали про героя, который сумел подключиться к системе через SOAP за месяц.
Слава героям, смотрел этот вебинар. Но должны быть (о чём я подробнейшим образом писал ранее) и другие, более традиционные и простые решения. Практически полная безальтернативность - это очень нехорошо.
Ок, принято: на рынке много информационных систем, и поскольку их разработчики массово не умеют обмениваться данными в онлайне и учиться не хотят, нужно предоставить им что-то более традиционное, вроде XML через файлы. С учётом того, что внедрение отодвигается, почему бы и не сделать.
Но некоторые ведь и XML не умеют, и просят TXT (прямо в этой теме).

Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Например, необходимость испытаний на стенде - осталась бы: вы ведь не стали бы скармливать "боевому" личному кабинету сформированный вашим софтом XML, не убедившись как-то в его корректности, правда?
Нет, неправда. Если в документе есть ошибки, то ГИС должна возвратить файл с диагностиками. Что она сейчас, кстати, и делает для XLSX-файлов. Никакой трагедии.
Я так понимаю, что XLSX - решение для ТСЖ на четыре квартиры. Заполнили ручками, отправили, получили список ошибок, исправили (опять же ручками, за две минуты), отправили снова. А если у нас ошибочные данные генерирует софт, то так не получится: нужно звать программиста, и исправление откладывается минимум на день (а в худшем случае - на несколько месяцев). Если есть программист, то нужен и тестовый стенд.
 
Цитата
Sergey Cheban пишет:
Хороший разработчик сделает в своём продукте интеграцию с ГИС ЖКХ.
Да, кстати. Вы писали, что с ГИС ЖКХ не работали. Но поинтересоваться, что же там в интеграции разработчики предлагают, всё же и Вам стоило бы. Прилагаю архив с тремя документами общим объёмом в 1700+ страниц. Там не просто "загрузка/выгрузка файлов" реализована. Там десятки Web-сервисов с кучей разных удалённо вызываемых методов. Оцените "простоту" взаимодействия!
 
Цитата
Sergey Cheban пишет:
А если у нас ошибочные данные генерирует софт, то так не получится: нужно звать программиста, и исправление откладывается минимум на день (а в худшем случае - на несколько месяцев).
Умный софт должен сам анализировать ошибки. И если это ошибка оператора - подсказывать ему, что надо исправить. Моя программа обслуживает несколько УК и десятки ТСЖ. Ни к кому никогда не езжу. Только телефон, email и - иногда - Ammyy Admin.

Отправлено спустя 10 минуты 41 секунды:
Цитата
Sergey Cheban пишет:
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.
Это - искусственно созданное обстоятельство. Малый бизнес (основа среднего класса) и без того всюду выдавливается с рынка монополиями. Просто тут наблюдаем очередной удар ему по башке.
Цитата
Sergey Cheban пишет:
Ну, может быть, разработчики и пойдут Вам навстречу и сделают загрузку данных через личный кабинет в удобном для генерации формате.
Хотелось бы надеяться, что в итоге пойдут. Но только не мне лично, а многим тысячам мелких УК и ТСЖ и самозанятым программистам, их обслуживающим.
 
Цитата
Sergey Cheban пишет:
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.

А не похоже ли это на монополию, это требование?

Отправлено спустя 3 минуты 6 секунды:
Цитата
Sergey Cheban пишет:
Но некоторые ведь и XML не умеют, и просят TXT

Это почти про меня. XML я умею, но описание его содержимого оставляет желать лучшего.

Отправлено спустя 4 минуты 21 секунды:
Цитата
AlcorVol пишет:
Только телефон, email и - иногда - Ammyy Admin.
А у меня на первом месте YandexDisk, на втором - телефон.
 
Цитата
это нужно для жителей
Я уже тут писал, что на данный момент система авторизации на ГИС ЖКХ заслуживает самое мягкое определения "крайне непродуманная". В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры. А пенсионеров - треть населения страны. И они очень часто являются формальными владельцами. Итого, минимум треть квартир даже в принципе (не обращая внимание на то, что Росреестр привязывается как попало) не могут зайти и посмотреть, что же там УО внесли.
Цитата
SOAP в ЛК
Это конечно была шутка, забавное преувеличение. но! в каждой шутке как известно только доля шутки. ЭП на файлы передаваемые в ЛК не ставится, кто отправитель заранее известно, так что SOAP от XML практически не отличается в этом случае.
Цитата
Sergey Cheban пишет:
Протокол SOAP - открытый. И вот с этой точки - пожалуйста, сами, если можете. А если не можете, то и говорить не о чем. А DLL - это очень, очень плохая идея:Непонятная DLL, работающая с криптографией и имеющая доступ к приватным ключам - это не безопасно.DLL привязывает нас к платформе Windows.Интерфейс, предоставляемый DLL - это чистый C. Даже не C++. Работать с ним из современных языков программирования неудобно.DLL выполняется в адресном пространстве чужого процесса. Если в результате процесс падает, не всегда понятно, по чьей вине это произошло. Нет внятного разграничения зон ответственности.В DLL наверняка были бы ошибки. Распространение DLL с исправлениями этих ошибок - задача нетривиальная.
По пунктам:
1) Более половины реализации SOAP одинаково не только в рамках ГИС ЖКХ, но и вообще всех российских ФГИС (все что вне Body по большому счету описано SOAP, отличий не так уж много). То есть что разработчиков множество это плохо, а что государство не предложит единую реализацию SOAP, на которую могли бы ориентироваться те же разработчики будущих ФГИС, это нормально - как хотите так и плывите. Правильно Вас понимаю?
2) небезопасно, согласен. Но все криптопровайдеры тоже в своем составе имеют DLL, естественно подписанные и сертифицированные ФСБ. Им вы доверяете? И при этом лично звонили проверяли подлинность сертификата? Ну и прекрасно, используем их.
Собственно для данной DLL (обертки XML в SOAP, добавление подписи, отправки SOAP на сервер ГИС) нет необходимости работать с приватными ключами напрямую (даже скорее посторонняя функция, зачем изобретать велосипед и реализовывать криптографические примитивы) - можно вычислить необходимые значения либо через сертифицированный криптопровайдер (который, "зараза", формирует cades-bes в отсоединенной ЭП файла, но тем не менее сам не умеет формировать xades-bes внутри XML) либо через сертифицированную версию OpenSSL (как рекомендуется в статьях на хабре). Плюс цифровая подпись DLL, что ее никто не изменял и она сама ключи не ворует. Понятно, если бы библиотека была подписана подписью ГИС ЖКХ или КриптоПро к ней было бы больше доверия, чем к "левому" разработчику, потому и просим.
Естественно, будет ли пользователь использовать сертифицированный криптопровайдер, сертифицированные бинарные файлы OpenSSL (и платить денежку) или общедоступные несертифицированные или соберет свою сборку - остается на совести администратора информационной безопасности организации пользователя. Нет смысла "не выпускать джинна из бутылки" - кто захочет несертифицированный, сделает и по тем статьям на хабре.
3) На Linux есть аналог DLL - SO библиотеки. Если компилятор кроссплатформенный, то сделать библиотеку для Linux примерно так сложно как передать параметр TargetOs и ссылки на библиотеки взять в управляющие комментарии (в кроссплатформенных компиляторах как правило уже есть билды стандартных Unit с использованием библиотек поддерживаемых операционных систем, нужно только Unit собственного сочинения перестроить под них). Тем не менее, у меня, например, нет планов поддерживать библиотеку на *nix системах, так как у меня нет возможности составить корректные представления о криптопровайдерах на *nix и написать соответствующие Unit.
4) Здравствуйте, при всем уважении, а кроме семейства Си языки какие-то знаете? У меня например мои все DLL на Паскале. Главное, что бы формат параметров можно было описать на любом языке - неважен язык программирования разработчика DLL. Это дает огромное преимущество по сравнению с проектами которые все делают именно на C# или Java. Не считая отсутствия громоздкого dotNet. Это компенсирует некоторые неудобства. Написать объект на вашем языке программирования когда уже есть реализация кода объекта в виде отдельных функций DLL тоже простая задача - все основные функции операционной системы Windows как раз содержатся в DLL, тем не менее работаете с ними через объекты.
Если же Вы имеете ввиду ООП при работе самой библиотеки, то огромное количество COM объектов как раз используют фабрики экземпляров в виде DLL и OCX TLB (расширение не особо имеет значение - по сути это тоже внешний исполняемый код, подгружаемый программой). Но COM объекты как раз и привяжут нас к Windows. dotNet полагаю тоже?
5) Ошибки есть везде и зона ответственности не разграничена, согласен. Но посмотрим, в среднем процессе Windows 7 вовлечены более чем 100 библиотек - не потому что разработчик программы их все загрузил, а потому системные и околосистемные библиотеки тянут за собой огромное количество зависимостей. В этом смысле, если добавится еще одна библиотека, погоды это не сделает. Для этого есть современные средства отладки собирающие данные активности на момент сбоя во всех потоках процесса. Определить, что вылетело при выполнении такой-то функции - на раз.
Тут хочу высказаться о языке программирования, на котором сделана библиотека - компиляторы Паскаля как раз славятся тем, что при загрузке модуля (будь то программа или библиотека) сразу же запрашивается память у системы "про запас", не через getmem, а как еще один сегмент наряду с кодом и данными (в них сразу записаны значения) - сегмент "кучи" (значения не записаны, заполнен "мусором" из оперативной памяти). По умолчанию это 8 мегабайт, мало по нынешним меркам, но на хранение результатов криптооперации - с головой хватит. Заранее объявленные глобальные переменные сюда не входят - один раз была нужда и объявил глобальный многомерный массив, потянувший на гигабайт - и все это скомпилировалось в сегменте данных. Если памяти не хватит библиотека не загрузится вообще и будет ясно - вывалилось до загрузки библиотеки и обработать это корректно задача использующей программы. Если память есть, то все загрузится и пока запас не исчерпан, никакой дополнительной памяти у системы не запрашивается и всю обработку правильности использования памяти в сегментах ведет стандартный код, вставленный компилятором. То есть со внутренней "кучей" можно что угодно делать - это повлияет на корректность работы библиотеки, но на работоспособность программы, использующей библиотеку, и системы это не повлияет. Хотя конечно памяти потребляет больше, по сравнению с запросом и освобождением у системы памяти для каждого объекта, но так надежнее.
С использованием данных, переданных основной программой гораздо сложнее, но и тут можно подстелить соломку, проверяя все указатели системной функцией (IsBadReadPtr IsBadWritePtr кажется - для своих программ не делал, но если распространять библиотеку, то нужно делать), как это делает само ядро операционной системы, и возвращая код ошибки "неправильный указатель", если проверка не пройдена. Лезть в память программы, если библиотеку об этом не просили и не дали правильный указатель - заведомо ошибочное дело, нет разницы в одном мы адресном пространстве или в разных.
6) проблемы обновления DLL абсолютно такие же, как и у программы, а именно - что заменить файл модуля, который запущен в данный момент, мягко говоря, непросто. Плюс при этом нужно убедиться, что замена не испорчена, а то и подписана ЭП. Проще в том плане, что объем библиотеки мал. Апплеты панели управления с расширением CPL - все те же DLL, но написанные по определенным требованиям и выводящие пользователю диалоговые окна. В том числе среди них есть такие, что реализуют функцию обновления какой-либо программы. Есть и другие средства решения: например можно функцию обновления вызывать в самой DLL при инициализации. Либо экспортировать функцию обновления отдельно, а в комплекте распространять bat файл, запускающий rundll32 для загрузки библиотеки и выполнения функции.
Цитата
Sergey Cheban пишет:
3. В каком виде должна быть ЭЦП? Как она должна отделяться от данных?
Насчет этого - никаких проблем, просто ЭЦП должна быть отсоединенной, в виде отдельного файла с расширением sig. Заметьте, в ту же налоговую (и из нее тоже) передается отсоединенная ЭЦП. Еще краем уха слышал, сейчас можно подписать VBScript, тоже по сути текстовый файл, в подробности не вникал пока. С остальным соглашусь, формат должен быть описан точно.
Цитата
Sergey Cheban пишет:
Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела.
Это конечно так, однако вот так посмотришь что в одном регионе "горячее водоснабжение", в другом "подогрев воды" и так далее и тому подобное. Программа, учитывающая все нюансы будет огромной и соответственно пропорционально количеству кода возрастет количество ошибок. Собственно именно это и видим на примере ГИС. Хотя наверно тоже можно поделить на библиотеки :D
 
Цитата
two_oceans пишет:
В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры.
Мне очень понравилось заявление, что, мол, в ЕСИА зарегистрировано более 30 млн человек и все они могут легко "провалиться" в ЛК физ.лиц ГИС. А вот о том, какой процент из этих 30 млн являются собственниками, скромно промолчали. ;)
 
Готов частично профинансировать разработку веб сервиса для 1с, а также выступить разработчиком ТЗ.
 
Цитата
Basil пишет:
А вот о том, какой процент из этих 30 млн являются собственниками, скромно промолчали.
Думаю процентов 10-20 :) Молодежь, которая все умеет, но ничего пока не имеет :)
Цитата
МихаилИгоревич пишет:
Готов частично профинансировать разработку веб сервиса
Вот и наши люди начали с инакомыслящими разговаривать :)
 
Цитата
Rembo пишет:
Вот и наши люди начали в теме отмечаться
Вообще-то, тема - не о том. Лучше бы отдельную завести.
 
Цитата
AlcorVol пишет:
Вообще-то, тема - не о том.
Финансы - двигатель прогресса и ускоритель реакции.
 
Цитата
МихаилИгоревич пишет:
Готов частично профинансировать разработку веб сервиса для 1с, а также выступить разработчиком ТЗ.
1c это немного другое, там специфический Visual Basic с русским акцентом. Конечно это достойно отдельного обсуждения, работающих в 1с немало и есть платный модуль для гисгмп, так что есть с чего начать. Кстати, модуль для ГИС жкх вроде бы тоже есть, в соседнем разделе обсуждали как замечательно все синхронизируется с 1с, но кажется выгрузка-загрузка вручную. Вот тут начали что-то делать по автоматизации, но похоже пока не очень-то ладится и им посоветовали тоже сделать сервис на C#. Я за 1с не возьмусь - так как там специфическое обновление форм и как представлю что это все править после каждой смены версии форматов гис жкх, становится дурно.
Теоретически,если все же сделать DLL автоматической смены отчетов, можно подумать как прикрутить к 1с. Пока что проектирую DLL для обертки и отправки уже готовых данных, до подготовки самих отчетов еще не скоро дело дойдет.
 
Из 1С7.7 выгрузил через Excel 2003 (плюс конвертор) 80 квартир в шаблон МКД. ГИС принял, обработал.
Формат MXL да, очень хочется.
 
Прошу прощения за поздний ответ. Я сейчас в командировке, со временем напряг.
Цитата
AlcorVol пишет:
Умный софт должен сам анализировать ошибки. И если это ошибка оператора - подсказывать ему, что надо исправить.
Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить. Желательно, не на "боевых" данных, а на тестовых.
Собственно, ГИС ЖКХ сейчас кривая в том числе и потому, что отлаживать её было не на чем.
Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.
Это - искусственно созданное обстоятельство. Малый бизнес (основа среднего класса) и без того всюду выдавливается с рынка монополиями. Просто тут наблюдаем очередной удар ему по башке.
Обстоятельства вполне естественные: необходимость навести порядок в ЖКХ - объективна, а компьютеризация процессов способствует выявлению узких мест (что будет после выявления - вопрос отдельный). И ликвидация малого бизнеса в том виде, в котором он сейчас существует - тоже процесс естественный.

Отправлено спустя 6 минуты 29 секунды:
Цитата
Programmer пишет:
Цитата
Sergey Cheban пишет:
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.
А не похоже ли это на монополию, это требование?
Нет, не похоже. У нас не одна сильная команда программистов.

Цитата
Programmer пишет:
Это почти про меня. XML я умею, но описание его содержимого оставляет желать лучшего.
На это мне пока нечего ответить. Но это уже _другая_ проблема.
 
Цитата
Sergey Cheban пишет:
Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить.
Согласен. И где же специальные "средства отладки" при загрузке информации через XLSX? Их просто нет. Только ответные диагностики. Вот, их-то и надо показывать оператору. Другого выхода нет. И если диагностики связаны с программными ошибками, то потребуется, конечно, доработка программы. В иных случаях реагировать придётся оператору.
Цитата
Sergey Cheban пишет:
И ликвидация малого бизнеса в том виде, в котором он сейчас существует - тоже процесс естественный.
Здесь - категорически не соглашусь. Но это - тема не для нашего форума.
 
Цитата
two_oceans пишет:
Я уже тут писал, что на данный момент система авторизации на ГИС ЖКХ заслуживает самое мягкое определения "крайне непродуманная". В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры. А пенсионеров - треть населения страны. И они очень часто являются формальными владельцами. Итого, минимум треть квартир даже в принципе (не обращая внимание на то, что Росреестр привязывается как попало) не могут зайти и посмотреть, что же там УО внесли.
Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).

Цитата
two_oceans пишет:
Цитата
SOAP в ЛК
Это конечно была шутка, забавное преувеличение. но! в каждой шутке как известно только доля шутки. ЭП на файлы передаваемые в ЛК не ставится, кто отправитель заранее известно, так что SOAP от XML практически не отличается в этом случае.
Вообще-то если по уму, то следовало бы требовать подпись и от файлов, передаваемых через ЛК.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Протокол SOAP - открытый. И вот с этой точки - пожалуйста, сами, если можете. А если не можете, то и говорить не о чем. А DLL - это очень, очень плохая идея:Непонятная DLL, работающая с криптографией и имеющая доступ к приватным ключам - это не безопасно.DLL привязывает нас к платформе Windows.Интерфейс, предоставляемый DLL - это чистый C. Даже не C++. Работать с ним из современных языков программирования неудобно.DLL выполняется в адресном пространстве чужого процесса. Если в результате процесс падает, не всегда понятно, по чьей вине это произошло. Нет внятного разграничения зон ответственности.В DLL наверняка были бы ошибки. Распространение DLL с исправлениями этих ошибок - задача нетривиальная.
По пунктам:
1) Более половины реализации SOAP одинаково не только в рамках ГИС ЖКХ, но и вообще всех российских ФГИС (все что вне Body по большому счету описано SOAP, отличий не так уж много). То есть что разработчиков множество это плохо, а что государство не предложит единую реализацию SOAP, на которую могли бы ориентироваться те же разработчики будущих ФГИС, это нормально - как хотите так и плывите. Правильно Вас понимаю?
Реализации SOAP предлагает не государство, а разработчики языков программирования и библиотек.

Цитата
two_oceans пишет:
2) небезопасно, согласен. Но все криптопровайдеры тоже в своем составе имеют DLL, естественно подписанные и сертифицированные ФСБ. Им вы доверяете? И при этом лично звонили проверяли подлинность сертификата? Ну и прекрасно, используем их.
Плевать на сертификат ФСБ. Главное, чтобы софт, установленный на той машине, с которой есть доступ к приватному ключу, не умел втихаря генерировать подпись для текста "Продаю всё своё имущество имяреку за 1 (один) рубль".

Цитата
two_oceans пишет:
Понятно, если бы библиотека была подписана подписью ГИС ЖКХ или КриптоПро к ней было бы больше доверия, чем к "левому" разработчику, потому и просим.
Деньги давать не пробовали? А то вот у меня к еде из магазина больше доверия, чем к еде с помойки, но это же не причина, чтобы попрошайничать.

Цитата
two_oceans пишет:
3) На Linux есть аналог DLL - SO библиотеки.
С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.

Цитата
two_oceans пишет:
4) Здравствуйте, при всем уважении, а кроме семейства Си языки какие-то знаете? У меня например мои все DLL на Паскале. Главное, что бы формат параметров можно было описать на любом языке - неважен язык программирования разработчика DLL.
Ага, сейчас.
- Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.
- Предположим, у нас есть простенькая функция:
__declspec(dllexport) std::string foo(const std::string &d) {return d;} Сможете Вы вызвать её из Паскаля? Вряд ли. Я именно об этом. А сишный интерфейс (const char *) - устарел и неудобен.

Цитата
two_oceans пишет:
Если же Вы имеете ввиду ООП при работе самой библиотеки, то огромное количество COM объектов как раз используют фабрики экземпляров в виде DLL и OCX TLB (расширение не особо имеет значение - по сути это тоже внешний исполняемый код, подгружаемый программой). Но COM объекты как раз и привяжут нас к Windows. dotNet полагаю тоже?
SOAP нас к винде не привязывает. А com-объекты - да, привязали бы не хуже dll.

Цитата
two_oceans пишет:
5) Ошибки есть везде и зона ответственности не разграничена, согласен. Но посмотрим, в среднем процессе Windows 7 вовлечены более чем 100 библиотек - не потому что разработчик программы их все загрузил, а потому системные и околосистемные библиотеки тянут за собой огромное количество зависимостей. В этом смысле, если добавится еще одна библиотека, погоды это не сделает.
Те DLL, которые грузятся при старте обычной программы, в основном созданы MS - компанией с очень серьёзным подходом к качеству ПО. В России аналогов нет. Да и у MS регулярно находят проблемы.

Цитата
two_oceans пишет:
Для этого есть современные средства отладки собирающие данные активности на момент сбоя во всех потоках процесса. Определить, что вылетело при выполнении такой-то функции - на раз.
Это если оно вылетело. А если memory corruption? Такое тоже ищется, но ох не сразу.


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

Цитата
two_oceans пишет:

6) проблемы обновления DLL абсолютно такие же, как и у программы, а именно - что заменить файл модуля, который запущен в данный момент, мягко говоря, непросто.
Технически - такие же. Юридически - нет: если нет DLL, то техподдержка ГИС ЖКХ избавляется от разговоров про эту DLL.
 
Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить.
Согласен. И где же специальные "средства отладки" при загрузке информации через XLSX? Их просто нет. Только ответные диагностики. Вот, их-то и надо показывать оператору. Другого выхода нет. И если диагностики связаны с программными ошибками, то потребуется, конечно, доработка программы. В иных случаях реагировать придётся оператору.
Что-то я потерял нить разговора. Помнится, начинали мы с того, что злые разработчики ГИС ЖКХ заставляют бедных разработчиков подключаться к своим тестовым стендам. Я говорил, что без тестового стенда невозможно выловить ошибки софта, работающего с ГИС ЖКХ, и этот стенд - не зло, а полезная штука.

Если Вам диагностики не хватает - ну ок, это может быть проблемой. Хотя тут тоже аккуратно надо, чтобы не дойти до диагностики вида "Ошибка в 13 бите пароля".
 
Цитата
Sergey Cheban пишет:
Что-то я потерял нить разговора. Помнится, начинали мы с того, что злые разработчики ГИС ЖКХ заставляют бедных разработчиков подключаться к своим тестовым стендам.
Ну, не надо утрировать. :) Перечитайте всё, написанное выше. Особое внимание обратите на объём документации по взаимодействию ИС с ГИС через Web-сервисы. Сам подход никак не предполагает, что каждое ТСЖ будет регистрироваться как "собственная ИС" (в понимании разработчиков ГИС), проходить испытания на стенде и выходить на промышленную эксплуатацию. А не хотите так - долбите ручками в Экселе. Такая вот "альтернатива". Они никак не предполагали, что куча народу будет искать средства автоматического формирования XLSX-файлов...

Впрочем, я уже повторяюсь. И предлагаю не толочь воду в ступе. Ваша позиция мне понятна. Надеюсь, что моя Вам - тоже.
 
Цитата
Sergey Cheban пишет:
Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).
Что-то я такой опции не увидел. И никаких "наводок" на это тоже. Поищу еще, если получится - премного благодарен.
Цитата
Sergey Cheban пишет:
Вообще-то если по уму, то следовало бы требовать подпись и от файлов, передаваемых через ЛК.
Это да. но раз полагаются на ПЭП Госуслуг, нам проще.
Цитата
Sergey Cheban пишет:
Реализации SOAP предлагает не государство, а разработчики
Согласен, но государство покупает реализации SOAP для центральных узлов СМЭВ - ничего не мешает включить в ТЗ пункт про библиотеку для свободного распространения. Бог с реализацией, но на данный момент каждая ГИС дополняет формат SOAP как в голову придет разработчикам ГИС. Минкомсвязь могло бы утвердить правила, уточняющие как именно дополнять стандарт - в какое место файла располагать ЭП, как стандартно указывать отправителя/получателя и тд. В конце концов, Little Endian или Big Endian использовать в кодировке ЭП. Это явно задача государства, а не разработчиков, которые реализуют только один вариант, но при этом никто не может внятно объяснить, почему нельзя по другому- в ГОСТ это не указано. Тем не менее, другой вариант возвращается с ошибкой - "Неверная ЭП".
Цитата
Sergey Cheban пишет:
С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.
Конечно, но это другая платформа, то есть привязка к Windows - мнимая. Тот же код программы, который напишете на Си будет скомпилирован и упакован в разный формат исполняемых файлов для разных операционных систем.
Цитата
Sergey Cheban пишет:
Деньги давать не пробовали?
Что это изменит? Качество вряд ли будет выше пропорционально сумме. Другой вопрос - кому? Реализация SOAP в ГИС довольно неполная и кривоватая, нет никакой гарантии, что другая неполная же реализация других разработчиков совпадет "по кривизне" и будет работать. В магазине Вам тоже могут предложить Столичный хлеб, когда вы пришли за Бородинским. Даже если с одной ГИС будет, хотелось бы универсальную библиотеку для всех федеральных ГИС. А если тем же, кто разрабатывал ГИС, то их компании и так уже заплатило государство (а государство это взяло из налогов и штрафов, то есть с нас с Вами в том числе) и совершенно немалые суммы. Честно, меня просто жаба задавит добавлять к тем суммам.
Цитата
Sergey Cheban пишет:
Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.
Знаю. Я в это когда-то вникал и смогу вызвать функцию, хотя возможно это займет время, чтобы разобрать код на Си и подобрать аналогичное описание объекта на Паскале. Либо подключить другую библиотеку того же языка, реализующую этот объект - если не вникать как объект устроен, а просто скормить, что передали и получить, что нужно либо наоборот. Как правило ключевые слова меняют порядок аргументов, так что для функции с одним аргументом мало что изменится, пример неудачен.
(я таки на Си не пишу, но немного разбираю, char * - указатель на буфер сразу, std::string &d вроде бы указатель на объект из которого еще надо получить указатель на буфер через c_str и длину через length/size, в этом смысле достаточно каким-то образом реализовать или подключить c_str и size. Скорее даже не так - объекты обычно хранят указатели на реализованные методы объекта, то есть достаточно найти в объекте нужный указатель на уже реализованную функцию c_str и узнать как ей передать объект). В общем, я не так хорошо знаю Си, а Вы похоже вообще не знаете Паскаль, примеры тут бессмысленно обсуждать.
Для информации - в Паскале таких ключевых слов тоже с десяток, включая вышеназванные - это раз. Если ни одно не подойдет, то никто не отменял возможность сделать "оберточную функцию" и вставить в код на Паскале операторную скобку asm .. end и написать внутри код ассемблера для передачи параметров и вызова импортируемой функции - это два. Конечно, при этом вся типизация коту под хвост и возможны ошибки. Но, надеюсь Вы не считаете, что разные языки для передачи параметров компилируют какой-то иной машинный код, несовместимый с ассемблером под ту же архитектуру процессора? Можно еще проще, просто используем stdcall - большинство языков умеет работать с системными библиотеками. Итого: остается просто описать заголовки (ну или оберточные функции) на нужном языке, а проблема не стоит выеденного яйца - решаем один раз, потом миллионы раз вызываем функцию.
Цитата
Sergey Cheban пишет:
Да и у MS регулярно находят проблемы.
Да и большая часть из них именно переполнение буфера, то есть по сути именно memory corruption. Это именно болезнь языка Си и прямого использования char * - даже хотя есть вариант функций с указанием размера, многие даже в Майкрософт на это плюют и используют функции без ограничения размера либо неправильно вычисляют ограничение. В Паскале все жестче - например, обычный string (shortstring в моей IDE) ограничен 255 байтами и (используя стандартные функции, без обращения к символам по номеру и махинаций с указателями) 256-ой записать невозможно в принципе - при любой записи берется минимум из ограничения и ожидаемого размера данных. Конечно, 255 байт откровенно сказать мало, но тут ничего не мешает найти исходник встроенного типа по образцу сделать собственный тип скажем на 10 мегабайт и тоже жестко вшить в него ограничение.
Цитата
Sergey Cheban пишет:
Пока не решены проблемы с интерфейсами, не вижу смысла это обсуждать.
Учитывая, выше про stdcall, не вижу проблем. Интерфейс всегда можно доработать, если Вам удобнее получать строчку в std::string чем в голом char * то это предмет переговоров о включении дополнительной "оберточной" функции. Либо мне тоже std::string понравится и я портирую объект на Паскаль. Но тут как раз может вылезти что объект не такой уж и std (стандартный), а отличается в разных Си.
Цитата
Sergey Cheban пишет:
Технически - такие же. Юридически - нет: если нет DLL, то техподдержка ГИС ЖКХ избавляется от разговоров про эту DLL.
я и не говорил, что это именно техподдержка ГИС ЖКХ будет по DLL по SOAP работу вести, так как федеральных ГИС много, и желательно общую библиотеку. Есть ситуационный центр электронного правительства. Как вариант, сама компания-разработчик библиотеки. А вот конкретно по библиотеке отчетов для ГИС ЖКХ, там конечно техподдержка этой ГИС и тут все понятно (в смысле наоборот непонятно, с чего начинать).
 
Для разработчиков на Паскале (Delphi) напомню, что строковые переменные и в DLL и в программе должны иметь тип shortstring. Все другие строковые типы, указатели на них, а так же примочки в виде делфийских DLL не работают или работают некорректно!
 
Цитата
two_oceans пишет:
непонятно, с чего начинать

Из-за этого очень сильные тормоза!
 
Цитата
Programmer пишет:
shortstring
Конечно они должны иметь одинаковый тип, точнее одинаково описанный. Хм, никогда не было проблем с этим. Ни со своими DLL, ни с системными. Сейчас перепроверю какой тип использовался, насколько помню pchar и все дела. Точнее, совместимый с ним собственный тип pathstr=array[1..260] of char и запись #0 в конце, от которого брался указатель. Что со мной не так? :D Замечу, что это не был объект и соответственно методы работы с ним реализовались независимо на каждой стороне, операторы не переопределялись. Конечно, так работать неудобно.
Другой вопрос, что типы-объекты нужно правильно (ре)конструировать и правильно передавать - просто положиться на среду программирования не всегда получится. Паскаль обычно использует как ссылку на себя внутри объекта (и она передается в метод в регистре процессора, а не через стек) ссылку на данные объекта (а не на начало памяти объекта ) - с одной стороны от нее (адрес в большую сторону, насколько помню) данные объекта, с другой стороны (в меньшую сторону соответственно) - адреса функций и процедур (методы) объекта. Если описание объекта не совпадает (методы и данные не совпадут после передачи) либо если передать ссылку на данные вместо объекта целиком и наоборот (так при передаче адресов методов может не оказаться в объекте на стороне-получателе), то ничего работать не будет.
Поэтому (если не заморачиваться) обычно и нужно избегать передавать объекты. Но, если я реконструирую объект после получения (исправлю адреса методов и поставлю указатель на нужное место), то проблем быть не должно. В этом смысле общее адресное пространство между программой и библиотекой скорее плюс, ссылки на методы должны быть все еще действительными после передачи. Однако, тут важно помнить, что адрес самой DLL может измениться при загрузке библиотеки, и если реализация объекта находится в DLL, то изменится и адрес реализации метода. Поэтому адрес метода нужно не прописывать конкретной цифрой, а импортировать либо находить системной функцией (GetProcAddress) после загрузки библиотеки.
Цитата
Programmer пишет:
Цитата
two_oceans пишет:
[99427]непонятно, с чего начинать
Из-за этого очень сильные тормоза!
Ну, в смысле, понятно, что можно получить описания схем и их проанализировать на предмет новых полей, изменений формата, удалений полей. Но далее нужно как-то связать с получаемыми из базы данных УО/ТСЖ данными. Пока придумался такой вариант - после обновления документация анализируется и структура тегов вроде
Цитата
... <soapenv:Body>
<pay:importNotificationsOfOrderExecutionRequest base:version="10.0.1.1">
<pay:NotificationOfOrderExecutionType>

<pay1:RecipientInfo>
<org:INN>3436018361</org:INN>...
преобразуется в имя переменной: в начале и конце строки ставится $, имена тегов (можно без пространств имен, но тогда еще отдельно нужно имена пространств передавать и сопоставлять плюс проверять ссылки на них) соединяются точками согласно иерархии, получится строка вроде$soapenv:Body.pay:importNotificationsOfOrderExecutionRequest.pay:NotificationOfOrderExecutionType.pay1:RecipientInfo.org:INN$ (с пространствами) либо $Body.importNotificationsOfOrderExecutionRequest.NotificationOfOrderExecutionType.RecipientInfo.INN$ (без пространств), формируется и где-то сохраняется шаблон в котором вместо значения подставлена такая строка (и так по всем значениям). Можно конечно как-то сокращать имена до $RecipientInfo.INN$ например, а то в shortstring не впишемся, но тогда нужно сопоставлять сокращенные и краткие имена. Зато попутно можно сопоставлять новое положение переменной в иерархии старому краткому имени и это может делать "опытный пользователь", не обязательно программист.
По запросу от библиотеки программа может получить список массив имен нужных переменных (без $), массив их обязательности и версию для конкретного шаблона SOAP запроса.
При формировании из программы передаются два массива строк для формирования отчета - один с именами переменных (без $), другой со соответствующими значениями переменных (значения уже заранее переведены в строку). Функция проверяет, что все переменные заполнены либо остались незаполнены необязательные (если не хватает выдает ошибку и, допустим, массив нехватающих переменных и их обязательность), убирает пустые необязательные и формирует готовый для отправки SOAP запрос, соответствующий новому шаблону.
Результат программа проверяет, что там нет "Продаю имущество имярек за 1 рубль". Можно, например, выводить пользователю для визуальной оценки (если XML плохо смотреть, то можно в библиотеку еще формирование версии для печати заложить на основе переданного XML и данных о стилях полученных из описания новой версии запроса. Чтобы не привязываться к платформе можно записывать html для печати во временную папку и открывать ассоциированным браузером. Либо выводить в самой программе псевдографикой моноширинным шрифтом как у AlcorVol) и ждать нажатия кнопки "Подписать и отправить".
После этого программа передает запрос в другую библиотеку для подписания/отправки вместе с адресом, портом, сертификатом. Как-то так, но это совсем "просто" получается.

Отправлено спустя 49 минуты 52 секунды:
Еще подумалось, что можно в библиотеке подписания просто запретить слова из юридических формул вроде "Продаю" "Дарю" "Завещаю" и возвращать ошибку, если текст их содержит.
 
Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).
Что-то я такой опции не увидел. И никаких "наводок" на это тоже. Поищу еще, если получится - премного благодарен.
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Реализации SOAP предлагает не государство, а разработчики
Согласен, но государство покупает реализации SOAP для центральных узлов СМЭВ - ничего не мешает включить в ТЗ пункт про библиотеку для свободного распространения. Бог с реализацией, но на данный момент каждая ГИС дополняет формат SOAP как в голову придет разработчикам ГИС. Минкомсвязь могло бы утвердить правила, уточняющие как именно дополнять стандарт - в какое место файла располагать ЭП, как стандартно указывать отправителя/получателя и тд. В конце концов, Little Endian или Big Endian использовать в кодировке ЭП. Это явно задача государства, а не разработчиков, которые реализуют только один вариант, но при этом никто не может внятно объяснить, почему нельзя по другому- в ГОСТ это не указано. Тем не менее, другой вариант возвращается с ошибкой - "Неверная ЭП".
Вот отклонение от отраслевых стандартов (я имею в виду не только ГОСТ, но и RFC и пр.) - это серьёзная проблема, и здесь я однозначно на стороне тех, кто хочет, чтобы стандарты соблюдались.
Установление новых стандартов и повышение единообразия - тоже дело хорошее, но проблема в том, что всё это требует времени, а внедрять надо уже сейчас. Так что увы, строгий порядок нас ждёт только на кладбище (квартал такой-то, ряд такой-то, могила такая-то), а пока мы живём, нам придётся бороться с беспорядком. Так этот мир устроен.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.
Конечно, но это другая платформа, то есть привязка к Windows - мнимая. Тот же код программы, который напишете на Си будет скомпилирован и упакован в разный формат исполняемых файлов для разных операционных систем.
Если Вы считаете, что эта штука действительно нужная, то попробуйте сами её сделать, а потом продать. Ну или хотя бы прикиньте, сколько времени и людей потребуется на разработку, и сколько экземпляров по какой цене можно продать. Если получается не выгодно, то и государству не стоит этим заниматься.

А написание портабельного кода - дело хоть и не невозможное, но всё же не тривиальное, и граблей на этом пути разложено значительно больше, чем хотелось бы. Тот же __stdcall - не стандарт, а расширение языка, gcc его не поймёт.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Деньги давать не пробовали?
Что это изменит? Качество вряд ли будет выше пропорционально сумме. Другой вопрос - кому? Реализация SOAP в ГИС довольно неполная и кривоватая, нет никакой гарантии, что другая неполная же реализация других разработчиков совпадет "по кривизне" и будет работать.
Вот про кривизну - это уже более конструктивный разговор.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.
Знаю. Я в это когда-то вникал и смогу вызвать функцию, хотя возможно это займет время, чтобы разобрать код на Си и подобрать аналогичное описание объекта на Паскале. Либо подключить другую библиотеку того же языка, реализующую этот объект - если не вникать как объект устроен, а просто скормить, что передали и получить, что нужно либо наоборот. Как правило ключевые слова меняют порядок аргументов, так что для функции с одним аргументом мало что изменится, пример неудачен.
Порядок аргументов, ответственность за очистку стека, передача части аргументов через регистры.

Цитата
two_oceans пишет:
(я таки на Си не пишу, но немного разбираю, char * - указатель на буфер сразу, std::string &d вроде бы указатель на объект из которого еще надо получить указатель на буфер через c_str и длину через length/size, в этом смысле достаточно каким-то образом реализовать или подключить c_str и size. Скорее даже не так - объекты обычно хранят указатели на реализованные методы объекта, то есть достаточно найти в объекте нужный указатель на уже реализованную функцию c_str и узнать как ей передать объект). В общем, я не так хорошо знаю Си, а Вы похоже вообще не знаете Паскаль, примеры тут бессмысленно обсуждать.
Я скромно замечу, что программированием занимаюсь как хобби с конца восьмидесятых, а профессионально с середины девяностых, и паскаля не миновал.
Проблемы с std::string и прочими не-сишными типами в том, что двоичная совместимость гарантируется только тогда, когда всё собрано одним и тем же компилятором с одними и теми же настройками. Обычно двоичную совместимость стараются сохранять в пределах мажорной версии компилятора, хотя даже из этого правила бывают исключения. И нет, конкретно в случае std::string у Вас не будет указателя на таблицу виртуальных методов, потому что эти методы не виртуальные.

Цитата
two_oceans пишет:
Для информации - в Паскале таких ключевых слов тоже с десяток, включая вышеназванные - это раз. Если ни одно не подойдет, то никто не отменял возможность сделать "оберточную функцию" и вставить в код на Паскале операторную скобку asm .. end и написать внутри код ассемблера для передачи параметров и вызова импортируемой функции - это два. Конечно, при этом вся типизация коту под хвост и возможны ошибки. Но, надеюсь Вы не считаете, что разные языки для передачи параметров компилируют какой-то иной машинный код, несовместимый с ассемблером под ту же архитектуру процессора? Можно еще проще, просто используем stdcall - большинство языков умеет работать с системными библиотеками. Итого: остается просто описать заголовки (ну или оберточные функции) на нужном языке, а проблема не стоит выеденного яйца - решаем один раз, потом миллионы раз вызываем функцию.
__stdcall как раз и оставит нам интерфейс на голом Си. С небезопасными строками, без поддержки исключений (exceptions), с проблемами освобождения переданной памяти, с проблемами использования из языков, отличных от си-подобных.
Паскаль, насколько я понимаю, застрял в девяностых, и поэтому у него с SOAP проблемы. Но в более современных языках всё уже есть. Либо в виде внешних библиотек, либо прямо в составе языка.

Цитата
two_oceans пишет:
Но тут как раз может вылезти что объект не такой уж и std (стандартный), а отличается в разных Си.
Двоичное представление - отличается.
 
Цитата
Sergey Cheban пишет:
Так что увы, строгий порядок нас ждёт только на кладбище (квартал такой-то, ряд такой-то, могила такая-то), а пока мы живём, нам придётся бороться с беспорядком. Так этот мир устроен.
Увы, в реальности и кладбища далеко не везде упорядочены рядами и кварталами.
Цитата
Sergey Cheban пишет:
Если Вы считаете, что эта штука действительно нужная, то попробуйте сами её сделать, а потом продать. Ну или хотя бы прикиньте, сколько времени и людей потребуется на разработку, и сколько экземпляров по какой цене можно продать. Если получается не выгодно, то и государству не стоит этим заниматься.
Да, считаю что нужна. Федеральных ГИС все больше. В принципе, меня одного хватит, только в одиночку это может затянуться надолго. А вот продавать - смысла не вижу, так как это потянет ответственность за дальнейшую поддержку. Максимум - добровольные пожертвования.
Цитата
Sergey Cheban пишет:
А написание портабельного кода - дело хоть и не невозможное, но всё же не тривиальное, и граблей на этом пути разложено значительно больше, чем хотелось бы. Тот же __stdcall - не стандарт, а расширение языка, gcc его не поймёт.
Согласен. Однако, наверняка можно использовать средства, которые понимают.
Цитата
Sergey Cheban пишет:
паскаля не миновал
Прошу простить в таком случае.
Цитата
Sergey Cheban пишет:
Проблемы с std::string и прочими не-сишными типами в том, что двоичная совместимость гарантируется только тогда, когда всё собрано одним и тем же компилятором с одними и теми же настройками. Обычно двоичную совместимость стараются сохранять в пределах мажорной версии компилятора, хотя даже из этого правила бывают исключения. И нет, конкретно в случае std::string у Вас не будет указателя на таблицу виртуальных методов, потому что эти методы не виртуальные.
Какой ужас, тогда мне вообще не ясно почему Си++ и более поздние версии так популярны. В любом случае, передавать методы как бы не обязательно, важны данные, в том же дельфи есть тип, в котором в начале длина строки (вариации тоже разные, до 8 байт на длину), потом само значение, для гарантии еще #0 в конце. Все это (и функции работы с ним) можно описать в Unit на Паскале или соответственно в заголовочном файле Си.
Цитата
Sergey Cheban пишет:
__stdcall как раз и оставит нам интерфейс на голом Си. С небезопасными строками, без поддержки исключений (exceptions), с проблемами освобождения переданной памяти, с проблемами использования из языков, отличных от си-подобных.
Что ж поделать, если с безопасными такая неприятность из-за двоичной несовместимости.
Цитата
Sergey Cheban пишет:
Паскаль, насколько я понимаю, застрял в девяностых, и поэтому у него с SOAP проблемы. Но в более современных языках всё уже есть. Либо в виде внешних библиотек, либо прямо в составе языка.
Что застрял, не отрицаю. Однако с SOAP в целом никаких проблем нет, есть стандартные Unit ("диалекты" Паскаля можно адаптировать, так что насобирать их не проблема). Проблемы начинаются, когда SOAP нужно подписать ЭП вообще (из-за не очень верной каконикализации в стандартных Unit (и даже в старых системных com-объектах), не совпадающей с новейшими каноникализаторами С#, использованными в ГИС), и невнятно определенной стандартом ГОСТ ЭП в частности. С отправкой на веб-сервис тоже не все гладко - модули есть, но в них нужно добавить "вкус шифрования ГОСТ". Итого - Unit, добавляющий к SOAP "вкус ГОСТ", как раз бы пригодился. Реализации этого естественно уже есть на Паскале, но, к сожалению, готового решения не нашел, ни бесплатно ни за деньги. На форумах активно обсуждались проблемы написания, но потом авторы написали и замолчали, на попытки связаться не отвечают. Естественно, можно попробовать перенести с других языков - но для этого нужно знать язык источника и тогда собственно проще писать именно на нем. А библиотека - способ не переписывать весь код с другого языка, а только интерфейсы - это проще.
С другой стороны, смены версий форматов запросов SOAP тоже сильно действуют на нервы и вынести функционал SOAP вне "основного кода" своей ИС в "модуль генерации SOAP" было бы логично. Начать с присвоения хранимым в своей ИС данным неких однозначных имен. Дальнейшие шаги по сопоставлению этих имен с тегами в запросах SOAP не потребуют изменения ИС, а простой смены настроек "модуля генерации SOAP". А вот если понадобятся передавать данные, которых нет в ИС - собственную ИС все равно придется дорабатывать: добавлять таблицы/поля для хранения данных, формы ввода и определять новые имена, но это не так сложно, по сравнению с чтением огромной, меняющейся и частично неверной документации к запросам. И снова в этом случае код "модуля генерации SOAP" менять не придется, а только его настройки. Если посмотреть шире, то "модуль генерации SOAP" будет в общих чертах одинаков практически у всех. Какой смысл тратить человеко-часы на написание его снова и снова разными разработчиками. С моей точки зрения, библиотека DLL как раз такой способ вынести общий, редко обновляемый функционал вне "основного кода" ИС.
Кроме того, если не ограничиваться ГИС ЖКХ, то, например, СМЭВ требует сохранять все запросы и ответы в базе данных (так порой сделаешь неправильный запрос, обнаружишь тестом, что в нем ошибка еще до отправки, а нет - удалять нельзя даже неотправленный запрос, так и висит как памятник глупости), а это в свою очередь пересекается с импортозамещением баз данных. То есть, по-хорошему, нужна вообще платформа включающая формирование SOAP из XML, подписание, отправку и отечественную базу данных (ясно что это уже не бесплатно, но хотелось бы за приемлемые деньги).

Отправлено спустя 26 минуты 50 секунды:
Цитата
Sergey Cheban пишет:
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.
Спасибо, попробую. Логично, я эту функцию и использовал, но после выбора адреса - выдало, что у меня нет прав. Правда, номер лицевого я не указывал (и мне интересно как я должен был об этом догадаться). С этим тоже проблема - например, у нас счета одной РСО выглядят вроде "01-1089" (особенность местного разработчика ПО, "01-" это номер УО/РСО), но в квитанции банк пишет просто 1089 и реквизиты компании. У другой РСО счет вида "ЧРТ010111111", в квитанции также, но на их сайте, например, нужно вводить без букв, только цифры. Поэтому я и не стал вводить лицевой счет без дополнительной "наводки" - нужно еще догадаться/подобрать, что РСО указало в этом поле.
 
Цитата
two_oceans пишет:
Еще подумалось, что можно в библиотеке подписания просто запретить слова из юридических формул вроде "Продаю" "Дарю" "Завещаю" и возвращать ошибку, если текст их содержит.
Я бы предложил более традиционный подход: использовать для подписания документов ноутбук, изолированный от сети и хранящийся в сейфе. Документы для подписания приносить на флешке и перед подписанием просматривать глазами ответственного человека. И ОС, и криптографический софт на ноутбук установить из доверенных источников (как минимум, не из помойки, как максимум - с сертификатом от ФСБ, и ноутбук тоже сертифицированный). Другой софт, включая антивирусы, - не устанавливать вообще.
Второй вариант - использовать для работы с ГИС ЖКХ такой сертификат электронной подписи, который позволит работать с ГИС ЖКХ, но при этом не позволит ничего продать, подарить или завещать в силу "ограничений, содержащихся в квалифицированном сертификате". Подробнее, увы, не знаю.
 
Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Проблемы с std::string и прочими не-сишными типами в том, что двоичная совместимость гарантируется только тогда, когда всё собрано одним и тем же компилятором с одними и теми же настройками. Обычно двоичную совместимость стараются сохранять в пределах мажорной версии компилятора, хотя даже из этого правила бывают исключения. И нет, конкретно в случае std::string у Вас не будет указателя на таблицу виртуальных методов, потому что эти методы не виртуальные.
Какой ужас, тогда мне вообще не ясно почему Си++ и более поздние версии так популярны.
На самом деле эта неприятная особенность существенно снижает популярность C++, а в попытках обойти её выросли такие технологии как COM, CORBA, Google Protobuf и XML. Но если у нас для всего есть исходники (что в мире C/C++ типично), то жить можно. Зато мы выигрываем в скорости на самом разнообразном железе.

Цитата
two_oceans пишет:
Итого - Unit, добавляющий к SOAP "вкус ГОСТ", как раз бы пригодился. Реализации этого естественно уже есть на Паскале, но, к сожалению, готового решения не нашел, ни бесплатно ни за деньги. На форумах активно обсуждались проблемы написания, но потом авторы написали и замолчали, на попытки связаться не отвечают. Естественно, можно попробовать перенести с других языков - но для этого нужно знать язык источника и тогда собственно проще писать именно на нем. А библиотека - способ не переписывать весь код с другого языка, а только интерфейсы - это проще.
Насколько я понимаю, разработчики ГИС ЖКХ пишут на C# и совместимы в первую очередь именно с ним, а с другими средствами разработки - как повезёт. Выбор C#, может быть, и не самый идеологически верный, если смотреть с точки зрения идеологов свободного ПО, но это не самый плохой вариант. С "идеологически верными" решениями, уверяю, на практике хлопот было бы не меньше. И я думаю, что лучше для взаимодействия с ГИС ЖКХ использовать C#, чем пытаться заставить работать то же самое на паскале. А паскаль с C# можно дружить уже на локальном компе.

Цитата
two_oceans пишет:
С другой стороны, смены версий форматов запросов SOAP тоже сильно действуют на нервы и вынести функционал SOAP вне "основного кода" своей ИС в "модуль генерации SOAP" было бы логично. Начать с присвоения хранимым в своей ИС данным неких однозначных имен. Дальнейшие шаги по сопоставлению этих имен с тегами в запросах SOAP не потребуют изменения ИС, а простой смены настроек "модуля генерации SOAP".
Это, увы, следствие agile-подхода в разработке ГИС ЖКХ. Не очень удобно, зато сравнительно быстро и сравнительно дёшево. Альтернатива этому подходу - всякие ФГУП, которые пытаются действовать "правильно", но при этом хронически не укладываются в требования, бюджет и сроки. Ну и ещё бывают life-critical systems (авиация, атом и пр), там порядка несколько больше, но зато и цена такая, что ой.

Цитата
two_oceans пишет:
С моей точки зрения, библиотека DLL как раз такой способ вынести общий, редко обновляемый функционал вне "основного кода" ИС.
Увы, нет. У разработчиков ГИС ЖКХ нет "редко обновляемого функционала". Они пытаются строить систему на ходу и не знают, что будет завтра. Параллельно меняется и законодательство, и требования, и всякие внешние обстоятельства, и внутренние баги, и пр. И смежники наверняка свои сюрпризы подкидывают, начиная с ошибочных данных в Росреестре. Со временем, конечно, всё это утрясётся, но пока - так.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.
Спасибо, попробую. Логично, я эту функцию и использовал, но после выбора адреса - выдало, что у меня нет прав. Правда, номер лицевого я не указывал (и мне интересно как я должен был об этом догадаться). С этим тоже проблема - например, у нас счета одной РСО выглядят вроде "01-1089" (особенность местного разработчика ПО, "01-" это номер УО/РСО), но в квитанции банк пишет просто 1089 и реквизиты компании. У другой РСО счет вида "ЧРТ010111111", в квитанции также, но на их сайте, например, нужно вводить без букв, только цифры. Поэтому я и не стал вводить лицевой счет без дополнительной "наводки" - нужно еще догадаться/подобрать, что РСО указало в этом поле.
Там нужен номер лицевого счёта от ГИС ЖКХ, а не от РСО. Поскольку на внедрение ГИС ЖКХ все дружно забили, этих счетов почти ни у кого нет, и подключать нечего. Мне повезло: у моего отца несколько дней был лицевой счёт, пока его не удалили, и я успел заметить и попробовать подключиться.
 
Цитата
Sergey Cheban пишет:
Я бы предложил более традиционный подход: использовать для подписания документов ноутбук, изолированный от сети и хранящийся в сейфе.
Согласен с этим вариантом, если бы это было в идеальном мире, где некая госструктура написала все библиотеки и сертифицировала. С другой стороны, со стороны государства все больше контроля и нет гарантий, что и в сертифицированных программах нет "закладок". Начать можно с того, что, насколько я знаю, до сих пор не опубликован алгоритм, отличающий "слабые" ключи ГОСТ от "сильных". При этом примеры "слабых" ключей есть (как минимум тривиальный - когда зашифрованный текст равен исходному). Конечно, хорошо, что не опубликован, но хотелось бы убедится, что ключи у нас не "слабые".
А Вы упорно упоминаете "про помойку". За "платформу" в целом можно заплатить, но в разумных пределах, скажем до 20-30 тысяч за все (то есть за каждую "перепроданную" доработанную копию). За одну-две сертифицированных библиотеки для написания своей программы, которую я не собираюсь продавать - ну долларов пять максимум.

Собственно, я никого не убеждаю в использовании библиотек неизвестного происхождения, у всех своя голова на плечах и свои представления кому и чему они доверяют. Я ведь тоже не беру чужую библиотеку, а пишу свою. Если кто-то захочет ее использовать - пожалуйста, мне не жалко (еще даже не написал, а уже столько шума), если кто-то побоится - их личное дело. Даже без генерации подписи на "Продам" в интернете полно вирусов на сайтах, где можно "найти" какую-то библиотеку и вполне очевидно, что осторожность с чужим кодом (а лучше паранойя) не помешает. Так что, может быть, хватит уже напоминать "про помойку" почти в каждом сообщении - режет глаз.

Ближе к теме. При всех плюсах подхода "ноутбук в сейфе плюс ответственный человек" есть и минусы: 1) для подписания в интеграции это (перенос туда-сюда на флешке, просмотр каждого XML) не подойдет, особенно если документов много и для XML нет вида для печати - глаз человека "замылится". От "Продам" и "Дарю" это, может быть, и защитит, но от прочих ошибок - нет. А если человек сидит и просматривает, хотелось бы чтобы это несло и другую полезную нагрузку. С другой стороны, если есть вид для печати, то опять же нужна гарантия, что на экране то содержание, которое подписываешь; 2) тривиально, но не у всех размер сейфа позволит положить туда производительный ноутбук; 3) ФСБ и др. особенно не рекомендуют использовать ноутбуки - украсть ноутбук гораздо проще и там практически всегда есть функция беспроводной сети, кстати, в сертифицированных ноутбуках антенну физически отрезают (у нас один есть в "секретном" отделе - стоимость железа, программ, вместе с сертификацией где-то 120 тысяч, сертификацию периодически нужно продлять, так что для многих при упоминании стоимости вопрос сразу закрывается); 4) для организации это значит минус один сотрудник, занимающийся только подписям; 5) флешки и без антивируса - это точно идеальный мир, а не тот в котором мы живем. В сертифицированных "секретных" ноутбуках вообще запрет подключать флешки - весь обмен документами исключительно на оптических дисках, а антивирус установлен, DrWeb.
Цитата
Sergey Cheban пишет:
Второй вариант - использовать для работы с ГИС ЖКХ такой сертификат электронной подписи, который позволит работать с ГИС ЖКХ, но при этом не позволит ничего продать, подарить или завещать в силу "ограничений, содержащихся в квалифицированном сертификате". Подробнее, увы, не знаю.
С этим я еще более согласен, я бы вообще все сертификаты сотрудников ограничивал к черту. Но с этим все гораздо хуже. Несмотря на упоминание в законе "ограничений, содержащихся в квалифицированном сертификате", фактически я еще не видел ни одного такого сертификата (имею ввиду российского, в зарубежных бывает "Заявление поставщика" - не знаю, может быть это оно и есть). Более того, работники местного отделения Федерального Казначейства, оформляющие заявки в удостоверяющий центр мне официально заявили, что нет возможности исключить использование определенного квалифицированного сертификата за пределами определенной ИС. При этом в форме заявки можно указать те самые ограничения. То есть, хотя ограничения как бы есть, нет механизма, который бы исключал их нарушение. В законе об электронной подписи тоже сказано всего лишь, что владелец должен использовать сертификат, соблюдая установленные в нем ограничения. Лично я не уверен, что этого будет достаточно для признания предложения "Продам..." юридически недействительным. Зато буквально на днях смотрел, что в новой редакции, вступившей в 2016 году, добавили, что любая государственная ИС не может предъявлять к сертификату требования, исключающие возможность использования этого сертификата в других ИС.
 
Цитата
Sergey Cheban пишет:
На самом деле эта неприятная особенность существенно снижает популярность C++, а в попытках обойти её выросли такие технологии как COM, CORBA, Google Protobuf и XML. Но если у нас для всего есть исходники (что в мире C/C++ типично), то жить можно. Зато мы выигрываем в скорости на самом разнообразном железе.
Не буду спорить о разнообразии железа и выигрыше у других языков высокого уровня, но вот насчет выигрыша Си, скажем у ассемблера есть сомнения. Даже на x86 у разных процессоров есть различия в скорости выполнения тех же инструкций и многое зависит от того как компилятор переведет язык высокого уровня в машинный код. Вроде как общепринято, что из-за этого ассемблер дает до 40% прироста скорости?
Пожалуйста, поясните, как тут мысль перекинулась на XML? Имеются ввиду манифесты?
Цитата
Sergey Cheban пишет:
Насколько я понимаю, разработчики ГИС ЖКХ пишут на C# и совместимы в первую очередь именно с ним, а с другими средствами разработки - как повезёт. Выбор C#, может быть, и не самый идеологически верный, если смотреть с точки зрения идеологов свободного ПО, но это не самый плохой вариант. С "идеологически верными" решениями, уверяю, на практике хлопот было бы не меньше. И я думаю, что лучше для взаимодействия с ГИС ЖКХ использовать C#, чем пытаться заставить работать то же самое на паскале. А паскаль с C# можно дружить уже на локальном компе.
Лично я даже и не рассматривал с точки зрения свободного ПО, но соглашусь. Для меня проблема не в идеологической верности, а в том что для меня C# это синоним dotNet Framework. Поправьте меня как более сведущий в мире языков Си, если я не прав. Я категорически против таких огромных фреймворков и именно поэтому лет надцать не стал переходить на C#, хотя выглядело чертовски заманчиво. С библиотекой Visual Basic в те времена можно было смириться - она практически везде ставилась с Windows. Но dotNet меня не устраивает - 1) огромный, даже хотя он у меня уже стоит и обновляется, когда вижу в системных требованиях, стараюсь выбрать альтернативное программное решение; 2) постоянно находят ошибки, что можно выполнить произвольную программу с админскими правами; 3) не менее постоянно обновляется, чтобы их закрыть - и после этого не знаешь, а запустится программа или нет; 4) программы требующие его, нужно обязательно устанавливать штатным установщиком, просто распаковать EXE c библиотеками и запустить не получается - выдает кучу ругани на зависимости компонентов, даже если dotNet стоит; 5) серьезно, сообщения об ошибках выглядят как невразумительная ругань, при том не связанная с самой ошибкой. Было большим открытием когда "матерился" на тип integer в веб-клиенте Росстата и исправилось установкой обновления; 6) и вот только после этого идет, что идеологически неверен. В итоге, дружить свое решение с C# смысла не вижу, так как это не уберет зависимости комплекса от dotNet. Поэтому уж лучше "изобрету велосипед", но без dotNet-зависимости. Уверен очень многие разработчики, не использующие C#, будут солидарны со мной.
Цитата
Sergey Cheban пишет:
Это, увы, следствие agile-подхода в разработке ГИС ЖКХ. Не очень удобно, зато сравнительно быстро и сравнительно дёшево. Альтернатива этому подходу - всякие ФГУП, которые пытаются действовать "правильно", но при этом хронически не укладываются в требования, бюджет и сроки. Ну и ещё бывают life-critical systems (авиация, атом и пр), там порядка несколько больше, но зато и цена такая, что ой.
Они (Разработчики ГИС ЖКХ) пытаются строить систему на ходу и не знают, что будет завтра. Параллельно меняется и законодательство, и требования, и всякие внешние обстоятельства, и внутренние баги, и пр. И смежники наверняка свои сюрпризы подкидывают, начиная с ошибочных данных в Росреестре. Со временем, конечно, всё это утрясётся, но пока - так.
С этим соглашусь в целом.
Цитата
Sergey Cheban пишет:
Цитата
two_oceans пишет:
С моей точки зрения, библиотека DLL как раз такой способ вынести общий, редко обновляемый функционал вне "основного кода" ИС.
Увы, нет. У разработчиков ГИС ЖКХ нет "редко обновляемого функционала".
Это не полностью верно, мы же не они. У них нет, а у нас может быть. Просто нужно, чтобы все изменения можно было "решить" не изменяя исполняемого кода. Скажем, обменяться настройками. Тут все зависит от того, как выстроить абстракцию.
Простой пример, понятный каждому программисту: если меняются требования к Вашей программе, Вы корректируете исходники, а не обновляете транслятор/компилятор! В этом случае, можно считать правила формирования машинного кода под конкретную архитектуру - стандартом, компилятор - редко обновляемым функционалом, а исходники Вашей программы и передаваемые опции - своего рода "настройками" для него. То есть берете "настройки" (исходник), отдаете "редко обновляемому функционалу" (компилятору), получаете "продукт" (исполняемый файл) соответствующий "стандарту" (правилам формирования машинного кода). Важно взять за "стандарт" что-то такое, чего разработчики не собираются менять. Ну вот вообще не собираются.
Применительно к интеграции с ГИС ЖКХ логично взять за "стандарт" описание протокола SOAP, за рамки которого разработчики не собираются слишком сильно выходить. Если 1) сделать полную реализацию всех его возможных деталей в "модуле генерации SOAP" ; 2) в "настройках" по факту указать какие именно детали реализации и как использовать плюс какой шаблон использовать, тогда "настройки" (плюс данные) можно воспринимать как своего рода исходник, а "модуль генерации SOAP" как своего рода транслятор, а готовый запрос SOAP как продукт трансляции. Все счастливы, а модуль генерации можно не обновлять. Конечно, как все "универсальное" (реализующее все возможные детали и анализирующее "настройки" при выполнении) это будет работать гораздо медленее, чем "специализированное" под конкретные детали, используемые конкретной ГИС на текущий момент. Другой вопрос, если разработчики вдруг захотят добавить нечто не предусмотренное протоколом. Или расширят стандарт так, как мы не предусмотрели. Тогда да, придется модуль изменять. Поэтому важно заранее хорошо придумать как такие расширения отразить в настройках, когда они внезапно появятся.
Цитата
Sergey Cheban пишет:
Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.
Спасибо, попробую. Логично, я эту функцию и использовал, но после выбора адреса - выдало, что у меня нет прав. Правда, номер лицевого я не указывал (и мне интересно как я должен был об этом догадаться). С этим тоже проблема - например, у нас счета одной РСО выглядят вроде "01-1089" (особенность местного разработчика ПО, "01-" это номер УО/РСО), но в квитанции банк пишет просто 1089 и реквизиты компании. У другой РСО счет вида "ЧРТ010111111", в квитанции также, но на их сайте, например, нужно вводить без букв, только цифры. Поэтому я и не стал вводить лицевой счет без дополнительной "наводки" - нужно еще догадаться/подобрать, что РСО указало в этом поле.
Там нужен номер лицевого счёта от ГИС ЖКХ, а не от РСО. Поскольку на внедрение ГИС ЖКХ все дружно забили, этих счетов почти ни у кого нет, и подключать нечего. Мне повезло: у моего отца несколько дней был лицевой счёт, пока его не удалили, и я успел заметить и попробовать подключиться.
Шутите? Повезло? Если так, то о каком добавлении своих/чужих счетов можно говорить. Подбирать ЕЛС никто не будет и в квитанции ЕЛС пока не фигурирует. Еще вариант прийти в УК/РСО лично и между сверкой платежей выспросить/подсмотреть. А значит на этом можно пока поставить точку - без знания ЕЛС сможет подключить только "собственник". А значит внесенные сведения практически никто не увидит. А значит "большинству населения" толку ноль от ГИС - вроде все полезно, а доступа нет.
 
Цитата
two_oceans пишет:
А Вы упорно упоминаете "про помойку". ... Так что, может быть, хватит уже напоминать "про помойку" почти в каждом сообщении - режет глаз.
Да господь с Вами. В первый раз упомянул.

Цитата
two_oceans пишет:
За "платформу" в целом можно заплатить, но в разумных пределах, скажем до 20-30 тысяч за все (то есть за каждую "перепроданную" доработанную копию). За одну-две сертифицированных библиотеки для написания своей программы, которую я не собираюсь продавать - ну долларов пять максимум.
В принципе можно и бесплатный openssl взять: хоть к нему и есть вопросы, я совсем не уверен, что решения с сертификатом от ФСБ будут лучше.

Я в основном о том, чтобы не использовать ЭЦП на том же компе, на котором внук ген. директора по ночам режется в пиратские игры. Всё, что сверх этого (сертификаты ФСБ, отрезание антенн и пр.) - уместно лишь тогда, когда есть что защищать. Если у нас ТСЖ на десять квартир, то нет смысла тратить сотни тысяч на безопасность: ущерб от взлома будет меньше.

Цитата
two_oceans пишет:
Лично я не уверен, что этого будет достаточно для признания предложения "Продам..." юридически недействительным. Зато буквально на днях смотрел, что в новой редакции, вступившей в 2016 году, добавили, что любая государственная ИС не может предъявлять к сертификату требования, исключающие возможность использования этого сертификата в других ИС.
Увы, увы. Насколько я понимаю, нынешняя политика ведомств в области ЭЦП сводится к выжиманию денег за сертификаты "для работы с площадкой Росраспилрегулирование", а о том, чтобы получить денег за что-то полезное, они даже не думают.
 
Так, да что такое, в третий раз браузер завис при написании ответа. Отправлю пустое сообщение с цитатами, потом добью текст по частям.
Цитата
Sergey Cheban пишет:
Цитата
two_oceans пишет:
За "платформу" в целом можно заплатить, но в разумных пределах, скажем до 20-30 тысяч за все (то есть за каждую "перепроданную" доработанную копию). За одну-две сертифицированных библиотеки для написания своей программы, которую я не собираюсь продавать - ну долларов пять максимум.
В принципе можно и бесплатный openssl взять: хоть к нему и есть вопросы, я совсем не уверен, что решения с сертификатом от ФСБ будут лучше.
Согласен. Уже есть сертифицированные решения, основанные на ветке OpenSSL (МагПро крипто пакет, кажется). То есть сертификация вряд ли означает отсутствие всех уязвимостей, скорее проверялся алгоритм формирования ключа ГОСТ и что с ключом не производится "левых" операций. При этом такая сертифицированная версия OpenSSL уже не бесплатна. Это что касается криптографических операций и подписи cades.
Тут наверно нужно еще сказать, что вызов самого исполняемого файла OpenSSL из программы выглядит как минимум не эстетично, то есть более интересно использовать ssleay32.dll и libeay32.dll. Другой довод в эту пользу - антивирусы крайне отрицательно относятся к программам, которые одновременно обращаются к интернету и запускают некий исполняемый файл - это классифицируется как неопознанный троян. У меня был такой прецедент (вызывал winrar.exe для подсчета CRC32, потом отправлял другому экземпляру программы и DrWeb определил программу как троян. Пришлось переписать на использование zlib.dll), и мне больше не хочется объяснять кому-то, что моя программа на самом деле не вирус. (Самое смешное, что программа администрирования, которая на самом деле аналогична трояну - выполняет произвольную команду полученную по локальной сети - антивирусами не блокировалась.)
У нас же задача немного сложнее - подписать XML другим определенным форматом xades-bes и включить подпись в файл. Как я понимаю, OpenSSL "из коробки" этого не умеет - иначе бы зачем изобретали велосипед в тех проектах на хабре. Так что в этом отношении все равно придется реализовать каноникализацию и допиливать формирование ЭП.
Далее, шифрование канала - тут огромное количество средств, начиная от Stunnel на основе OpenSSL (у криптопро своя версия одноименной программы, основана ли на OpenSSL до конца не ясно) до Континент-АП и Vipnet. В общем случае, почти никак не затрагивает нашу программу - меняется только адрес/порт назначения.
А вот с реализацией протокола TLS совсем плохо, несмотря на все уязвимости, OpenSSL тут мало что можно противопоставить. Конечно, есть Континент TLS клиент и Jinn-клиент (рекомендованные для ГИИС "Электронный бюджет"), но можно сказать, что они очень большая редкость. Есть компонент TLS в КриптоПро, но мне пока не очень понятно как его использовать и не понадобится ли отдельная лицензия.
Итого, если не обращать внимание на уязвимости, OpenSSL действительно практически идеальный выбор - допилить xades-bes и вперед.
Цитата
Sergey Cheban пишет:
Я в основном о том, чтобы не использовать ЭЦП на том же компе, на котором внук ген. директора по ночам режется в пиратские игры. Всё, что сверх этого (сертификаты ФСБ, отрезание антенн и пр.) - уместно лишь тогда, когда есть что защищать. Если у нас ТСЖ на десять квартир, то нет смысла тратить сотни тысяч на безопасность: ущерб от взлома будет меньше.
Согласен. И не только внук. Порой с виду приличные сотрудники такое устанавливают на своих рабочих местах, что пиратские игры отдыхают. Как минимум будет полезно ограничить права пользователя на таком компьютере.
#61
0 0
Цитата
AlcorVol пишет:
Я - разработчик. Но разрабатывать "коммерческую ИС" не собираюсь. Буду дорабатывать софт для УК, ориентируясь на формирование и передачу файлов. Пока - в XLSX-формате.

Аналогично. Хотя бы с XLSX разобраться, для начала. Трата времени на интеграцию в эти дни разбитым корытом попахивает.
#62
0 0
Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела. Десятка систем вполне хватило бы для конкуренции. Ну ок, пусть два десятка (в расчёте на то, что половина со временем сдохнет). А больше - зачем? Сейчас вместо десятка сильных команд разработчиков мы имеем множество слабых.
Извините, но эти вопросы решаются только рынком. А не Вашими личными соображениями на тему, что было бы полезно, а что вредно. И сколько команд разработчиков тут требуется.
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.

Цитата
AlcorVol пишет:
Я - разработчик. Но разрабатывать "коммерческую ИС" не собираюсь. Буду дорабатывать софт для УК, ориентируясь на формирование и передачу файлов. Пока - в XLSX-формате. УК/ТСЖ тоже не хотят становиться "ИС". Их вполне устроила бы загрузка файлов в ЛК.
Ну, может быть, разработчики и пойдут Вам навстречу и сделают загрузку данных через личный кабинет в удобном для генерации формате.

Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Хороший разработчик сделает в своём продукте интеграцию с ГИС ЖКХ.
Статус ИС почти никому на практике не нужен. Каждое ТСЖ - самостоятельная информационная система? Маразм!
Если ТСЖ разрабатывает свой софт, ведёт свои базы данных и т.п., то оно и есть информационная система. А если у нас ТСЖ на четыре квартиры, то ему и XLS хватит.

Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Я пока что не очень понимаю, чем Вам SOAP не угодил в качестве бесплатной альтернативы. Разработчики ГИС ЖКХ, помнится, на каком-то из вебинаров рассказывали про героя, который сумел подключиться к системе через SOAP за месяц.
Слава героям, смотрел этот вебинар. Но должны быть (о чём я подробнейшим образом писал ранее) и другие, более традиционные и простые решения. Практически полная безальтернативность - это очень нехорошо.
Ок, принято: на рынке много информационных систем, и поскольку их разработчики массово не умеют обмениваться данными в онлайне и учиться не хотят, нужно предоставить им что-то более традиционное, вроде XML через файлы. С учётом того, что внедрение отодвигается, почему бы и не сделать.
Но некоторые ведь и XML не умеют, и просят TXT (прямо в этой теме).

Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Например, необходимость испытаний на стенде - осталась бы: вы ведь не стали бы скармливать "боевому" личному кабинету сформированный вашим софтом XML, не убедившись как-то в его корректности, правда?
Нет, неправда. Если в документе есть ошибки, то ГИС должна возвратить файл с диагностиками. Что она сейчас, кстати, и делает для XLSX-файлов. Никакой трагедии.
Я так понимаю, что XLSX - решение для ТСЖ на четыре квартиры. Заполнили ручками, отправили, получили список ошибок, исправили (опять же ручками, за две минуты), отправили снова. А если у нас ошибочные данные генерирует софт, то так не получится: нужно звать программиста, и исправление откладывается минимум на день (а в худшем случае - на несколько месяцев). Если есть программист, то нужен и тестовый стенд.
#63
0 0
Цитата
Sergey Cheban пишет:
Хороший разработчик сделает в своём продукте интеграцию с ГИС ЖКХ.
Да, кстати. Вы писали, что с ГИС ЖКХ не работали. Но поинтересоваться, что же там в интеграции разработчики предлагают, всё же и Вам стоило бы. Прилагаю архив с тремя документами общим объёмом в 1700+ страниц. Там не просто "загрузка/выгрузка файлов" реализована. Там десятки Web-сервисов с кучей разных удалённо вызываемых методов. Оцените "простоту" взаимодействия!
#64
0 0
Цитата
Sergey Cheban пишет:
А если у нас ошибочные данные генерирует софт, то так не получится: нужно звать программиста, и исправление откладывается минимум на день (а в худшем случае - на несколько месяцев).
Умный софт должен сам анализировать ошибки. И если это ошибка оператора - подсказывать ему, что надо исправить. Моя программа обслуживает несколько УК и десятки ТСЖ. Ни к кому никогда не езжу. Только телефон, email и - иногда - Ammyy Admin.

Отправлено спустя 10 минуты 41 секунды:
Цитата
Sergey Cheban пишет:
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.
Это - искусственно созданное обстоятельство. Малый бизнес (основа среднего класса) и без того всюду выдавливается с рынка монополиями. Просто тут наблюдаем очередной удар ему по башке.
Цитата
Sergey Cheban пишет:
Ну, может быть, разработчики и пойдут Вам навстречу и сделают загрузку данных через личный кабинет в удобном для генерации формате.
Хотелось бы надеяться, что в итоге пойдут. Но только не мне лично, а многим тысячам мелких УК и ТСЖ и самозанятым программистам, их обслуживающим.
#65
0 0
Цитата
Sergey Cheban пишет:
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.

А не похоже ли это на монополию, это требование?

Отправлено спустя 3 минуты 6 секунды:
Цитата
Sergey Cheban пишет:
Но некоторые ведь и XML не умеют, и просят TXT

Это почти про меня. XML я умею, но описание его содержимого оставляет желать лучшего.

Отправлено спустя 4 минуты 21 секунды:
Цитата
AlcorVol пишет:
Только телефон, email и - иногда - Ammyy Admin.
А у меня на первом месте YandexDisk, на втором - телефон.
#66
0 0
Цитата
это нужно для жителей
Я уже тут писал, что на данный момент система авторизации на ГИС ЖКХ заслуживает самое мягкое определения "крайне непродуманная". В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры. А пенсионеров - треть населения страны. И они очень часто являются формальными владельцами. Итого, минимум треть квартир даже в принципе (не обращая внимание на то, что Росреестр привязывается как попало) не могут зайти и посмотреть, что же там УО внесли.
Цитата
SOAP в ЛК
Это конечно была шутка, забавное преувеличение. но! в каждой шутке как известно только доля шутки. ЭП на файлы передаваемые в ЛК не ставится, кто отправитель заранее известно, так что SOAP от XML практически не отличается в этом случае.
Цитата
Sergey Cheban пишет:
Протокол SOAP - открытый. И вот с этой точки - пожалуйста, сами, если можете. А если не можете, то и говорить не о чем. А DLL - это очень, очень плохая идея:Непонятная DLL, работающая с криптографией и имеющая доступ к приватным ключам - это не безопасно.DLL привязывает нас к платформе Windows.Интерфейс, предоставляемый DLL - это чистый C. Даже не C++. Работать с ним из современных языков программирования неудобно.DLL выполняется в адресном пространстве чужого процесса. Если в результате процесс падает, не всегда понятно, по чьей вине это произошло. Нет внятного разграничения зон ответственности.В DLL наверняка были бы ошибки. Распространение DLL с исправлениями этих ошибок - задача нетривиальная.
По пунктам:
1) Более половины реализации SOAP одинаково не только в рамках ГИС ЖКХ, но и вообще всех российских ФГИС (все что вне Body по большому счету описано SOAP, отличий не так уж много). То есть что разработчиков множество это плохо, а что государство не предложит единую реализацию SOAP, на которую могли бы ориентироваться те же разработчики будущих ФГИС, это нормально - как хотите так и плывите. Правильно Вас понимаю?
2) небезопасно, согласен. Но все криптопровайдеры тоже в своем составе имеют DLL, естественно подписанные и сертифицированные ФСБ. Им вы доверяете? И при этом лично звонили проверяли подлинность сертификата? Ну и прекрасно, используем их.
Собственно для данной DLL (обертки XML в SOAP, добавление подписи, отправки SOAP на сервер ГИС) нет необходимости работать с приватными ключами напрямую (даже скорее посторонняя функция, зачем изобретать велосипед и реализовывать криптографические примитивы) - можно вычислить необходимые значения либо через сертифицированный криптопровайдер (который, "зараза", формирует cades-bes в отсоединенной ЭП файла, но тем не менее сам не умеет формировать xades-bes внутри XML) либо через сертифицированную версию OpenSSL (как рекомендуется в статьях на хабре). Плюс цифровая подпись DLL, что ее никто не изменял и она сама ключи не ворует. Понятно, если бы библиотека была подписана подписью ГИС ЖКХ или КриптоПро к ней было бы больше доверия, чем к "левому" разработчику, потому и просим.
Естественно, будет ли пользователь использовать сертифицированный криптопровайдер, сертифицированные бинарные файлы OpenSSL (и платить денежку) или общедоступные несертифицированные или соберет свою сборку - остается на совести администратора информационной безопасности организации пользователя. Нет смысла "не выпускать джинна из бутылки" - кто захочет несертифицированный, сделает и по тем статьям на хабре.
3) На Linux есть аналог DLL - SO библиотеки. Если компилятор кроссплатформенный, то сделать библиотеку для Linux примерно так сложно как передать параметр TargetOs и ссылки на библиотеки взять в управляющие комментарии (в кроссплатформенных компиляторах как правило уже есть билды стандартных Unit с использованием библиотек поддерживаемых операционных систем, нужно только Unit собственного сочинения перестроить под них). Тем не менее, у меня, например, нет планов поддерживать библиотеку на *nix системах, так как у меня нет возможности составить корректные представления о криптопровайдерах на *nix и написать соответствующие Unit.
4) Здравствуйте, при всем уважении, а кроме семейства Си языки какие-то знаете? У меня например мои все DLL на Паскале. Главное, что бы формат параметров можно было описать на любом языке - неважен язык программирования разработчика DLL. Это дает огромное преимущество по сравнению с проектами которые все делают именно на C# или Java. Не считая отсутствия громоздкого dotNet. Это компенсирует некоторые неудобства. Написать объект на вашем языке программирования когда уже есть реализация кода объекта в виде отдельных функций DLL тоже простая задача - все основные функции операционной системы Windows как раз содержатся в DLL, тем не менее работаете с ними через объекты.
Если же Вы имеете ввиду ООП при работе самой библиотеки, то огромное количество COM объектов как раз используют фабрики экземпляров в виде DLL и OCX TLB (расширение не особо имеет значение - по сути это тоже внешний исполняемый код, подгружаемый программой). Но COM объекты как раз и привяжут нас к Windows. dotNet полагаю тоже?
5) Ошибки есть везде и зона ответственности не разграничена, согласен. Но посмотрим, в среднем процессе Windows 7 вовлечены более чем 100 библиотек - не потому что разработчик программы их все загрузил, а потому системные и околосистемные библиотеки тянут за собой огромное количество зависимостей. В этом смысле, если добавится еще одна библиотека, погоды это не сделает. Для этого есть современные средства отладки собирающие данные активности на момент сбоя во всех потоках процесса. Определить, что вылетело при выполнении такой-то функции - на раз.
Тут хочу высказаться о языке программирования, на котором сделана библиотека - компиляторы Паскаля как раз славятся тем, что при загрузке модуля (будь то программа или библиотека) сразу же запрашивается память у системы "про запас", не через getmem, а как еще один сегмент наряду с кодом и данными (в них сразу записаны значения) - сегмент "кучи" (значения не записаны, заполнен "мусором" из оперативной памяти). По умолчанию это 8 мегабайт, мало по нынешним меркам, но на хранение результатов криптооперации - с головой хватит. Заранее объявленные глобальные переменные сюда не входят - один раз была нужда и объявил глобальный многомерный массив, потянувший на гигабайт - и все это скомпилировалось в сегменте данных. Если памяти не хватит библиотека не загрузится вообще и будет ясно - вывалилось до загрузки библиотеки и обработать это корректно задача использующей программы. Если память есть, то все загрузится и пока запас не исчерпан, никакой дополнительной памяти у системы не запрашивается и всю обработку правильности использования памяти в сегментах ведет стандартный код, вставленный компилятором. То есть со внутренней "кучей" можно что угодно делать - это повлияет на корректность работы библиотеки, но на работоспособность программы, использующей библиотеку, и системы это не повлияет. Хотя конечно памяти потребляет больше, по сравнению с запросом и освобождением у системы памяти для каждого объекта, но так надежнее.
С использованием данных, переданных основной программой гораздо сложнее, но и тут можно подстелить соломку, проверяя все указатели системной функцией (IsBadReadPtr IsBadWritePtr кажется - для своих программ не делал, но если распространять библиотеку, то нужно делать), как это делает само ядро операционной системы, и возвращая код ошибки "неправильный указатель", если проверка не пройдена. Лезть в память программы, если библиотеку об этом не просили и не дали правильный указатель - заведомо ошибочное дело, нет разницы в одном мы адресном пространстве или в разных.
6) проблемы обновления DLL абсолютно такие же, как и у программы, а именно - что заменить файл модуля, который запущен в данный момент, мягко говоря, непросто. Плюс при этом нужно убедиться, что замена не испорчена, а то и подписана ЭП. Проще в том плане, что объем библиотеки мал. Апплеты панели управления с расширением CPL - все те же DLL, но написанные по определенным требованиям и выводящие пользователю диалоговые окна. В том числе среди них есть такие, что реализуют функцию обновления какой-либо программы. Есть и другие средства решения: например можно функцию обновления вызывать в самой DLL при инициализации. Либо экспортировать функцию обновления отдельно, а в комплекте распространять bat файл, запускающий rundll32 для загрузки библиотеки и выполнения функции.
Цитата
Sergey Cheban пишет:
3. В каком виде должна быть ЭЦП? Как она должна отделяться от данных?
Насчет этого - никаких проблем, просто ЭЦП должна быть отсоединенной, в виде отдельного файла с расширением sig. Заметьте, в ту же налоговую (и из нее тоже) передается отсоединенная ЭЦП. Еще краем уха слышал, сейчас можно подписать VBScript, тоже по сути текстовый файл, в подробности не вникал пока. С остальным соглашусь, формат должен быть описан точно.
Цитата
Sergey Cheban пишет:
Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела.
Это конечно так, однако вот так посмотришь что в одном регионе "горячее водоснабжение", в другом "подогрев воды" и так далее и тому подобное. Программа, учитывающая все нюансы будет огромной и соответственно пропорционально количеству кода возрастет количество ошибок. Собственно именно это и видим на примере ГИС. Хотя наверно тоже можно поделить на библиотеки :D
#67
0 0
Цитата
two_oceans пишет:
В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры.
Мне очень понравилось заявление, что, мол, в ЕСИА зарегистрировано более 30 млн человек и все они могут легко "провалиться" в ЛК физ.лиц ГИС. А вот о том, какой процент из этих 30 млн являются собственниками, скромно промолчали. ;)
#68
0 0
Готов частично профинансировать разработку веб сервиса для 1с, а также выступить разработчиком ТЗ.
#69
0 0
Цитата
Basil пишет:
А вот о том, какой процент из этих 30 млн являются собственниками, скромно промолчали.
Думаю процентов 10-20 :) Молодежь, которая все умеет, но ничего пока не имеет :)
Цитата
МихаилИгоревич пишет:
Готов частично профинансировать разработку веб сервиса
Вот и наши люди начали с инакомыслящими разговаривать :)
#70
0 0
Цитата
Rembo пишет:
Вот и наши люди начали в теме отмечаться
Вообще-то, тема - не о том. Лучше бы отдельную завести.
#71
0 0
Цитата
AlcorVol пишет:
Вообще-то, тема - не о том.
Финансы - двигатель прогресса и ускоритель реакции.
#72
0 0
Цитата
МихаилИгоревич пишет:
Готов частично профинансировать разработку веб сервиса для 1с, а также выступить разработчиком ТЗ.
1c это немного другое, там специфический Visual Basic с русским акцентом. Конечно это достойно отдельного обсуждения, работающих в 1с немало и есть платный модуль для гисгмп, так что есть с чего начать. Кстати, модуль для ГИС жкх вроде бы тоже есть, в соседнем разделе обсуждали как замечательно все синхронизируется с 1с, но кажется выгрузка-загрузка вручную. Вот тут начали что-то делать по автоматизации, но похоже пока не очень-то ладится и им посоветовали тоже сделать сервис на C#. Я за 1с не возьмусь - так как там специфическое обновление форм и как представлю что это все править после каждой смены версии форматов гис жкх, становится дурно.
Теоретически,если все же сделать DLL автоматической смены отчетов, можно подумать как прикрутить к 1с. Пока что проектирую DLL для обертки и отправки уже готовых данных, до подготовки самих отчетов еще не скоро дело дойдет.
#73
0 0
Из 1С7.7 выгрузил через Excel 2003 (плюс конвертор) 80 квартир в шаблон МКД. ГИС принял, обработал.
Формат MXL да, очень хочется.
#74
0 0
Прошу прощения за поздний ответ. Я сейчас в командировке, со временем напряг.
Цитата
AlcorVol пишет:
Умный софт должен сам анализировать ошибки. И если это ошибка оператора - подсказывать ему, что надо исправить.
Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить. Желательно, не на "боевых" данных, а на тестовых.
Собственно, ГИС ЖКХ сейчас кривая в том числе и потому, что отлаживать её было не на чем.
Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.
Это - искусственно созданное обстоятельство. Малый бизнес (основа среднего класса) и без того всюду выдавливается с рынка монополиями. Просто тут наблюдаем очередной удар ему по башке.
Обстоятельства вполне естественные: необходимость навести порядок в ЖКХ - объективна, а компьютеризация процессов способствует выявлению узких мест (что будет после выявления - вопрос отдельный). И ликвидация малого бизнеса в том виде, в котором он сейчас существует - тоже процесс естественный.

Отправлено спустя 6 минуты 29 секунды:
Цитата
Programmer пишет:
Цитата
Sergey Cheban пишет:
Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.
А не похоже ли это на монополию, это требование?
Нет, не похоже. У нас не одна сильная команда программистов.

Цитата
Programmer пишет:
Это почти про меня. XML я умею, но описание его содержимого оставляет желать лучшего.
На это мне пока нечего ответить. Но это уже _другая_ проблема.
#75
0 0
Цитата
Sergey Cheban пишет:
Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить.
Согласен. И где же специальные "средства отладки" при загрузке информации через XLSX? Их просто нет. Только ответные диагностики. Вот, их-то и надо показывать оператору. Другого выхода нет. И если диагностики связаны с программными ошибками, то потребуется, конечно, доработка программы. В иных случаях реагировать придётся оператору.
Цитата
Sergey Cheban пишет:
И ликвидация малого бизнеса в том виде, в котором он сейчас существует - тоже процесс естественный.
Здесь - категорически не соглашусь. Но это - тема не для нашего форума.
#76
0 0
Цитата
two_oceans пишет:
Я уже тут писал, что на данный момент система авторизации на ГИС ЖКХ заслуживает самое мягкое определения "крайне непродуманная". В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры. А пенсионеров - треть населения страны. И они очень часто являются формальными владельцами. Итого, минимум треть квартир даже в принципе (не обращая внимание на то, что Росреестр привязывается как попало) не могут зайти и посмотреть, что же там УО внесли.
Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).

Цитата
two_oceans пишет:
Цитата
SOAP в ЛК
Это конечно была шутка, забавное преувеличение. но! в каждой шутке как известно только доля шутки. ЭП на файлы передаваемые в ЛК не ставится, кто отправитель заранее известно, так что SOAP от XML практически не отличается в этом случае.
Вообще-то если по уму, то следовало бы требовать подпись и от файлов, передаваемых через ЛК.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Протокол SOAP - открытый. И вот с этой точки - пожалуйста, сами, если можете. А если не можете, то и говорить не о чем. А DLL - это очень, очень плохая идея:Непонятная DLL, работающая с криптографией и имеющая доступ к приватным ключам - это не безопасно.DLL привязывает нас к платформе Windows.Интерфейс, предоставляемый DLL - это чистый C. Даже не C++. Работать с ним из современных языков программирования неудобно.DLL выполняется в адресном пространстве чужого процесса. Если в результате процесс падает, не всегда понятно, по чьей вине это произошло. Нет внятного разграничения зон ответственности.В DLL наверняка были бы ошибки. Распространение DLL с исправлениями этих ошибок - задача нетривиальная.
По пунктам:
1) Более половины реализации SOAP одинаково не только в рамках ГИС ЖКХ, но и вообще всех российских ФГИС (все что вне Body по большому счету описано SOAP, отличий не так уж много). То есть что разработчиков множество это плохо, а что государство не предложит единую реализацию SOAP, на которую могли бы ориентироваться те же разработчики будущих ФГИС, это нормально - как хотите так и плывите. Правильно Вас понимаю?
Реализации SOAP предлагает не государство, а разработчики языков программирования и библиотек.

Цитата
two_oceans пишет:
2) небезопасно, согласен. Но все криптопровайдеры тоже в своем составе имеют DLL, естественно подписанные и сертифицированные ФСБ. Им вы доверяете? И при этом лично звонили проверяли подлинность сертификата? Ну и прекрасно, используем их.
Плевать на сертификат ФСБ. Главное, чтобы софт, установленный на той машине, с которой есть доступ к приватному ключу, не умел втихаря генерировать подпись для текста "Продаю всё своё имущество имяреку за 1 (один) рубль".

Цитата
two_oceans пишет:
Понятно, если бы библиотека была подписана подписью ГИС ЖКХ или КриптоПро к ней было бы больше доверия, чем к "левому" разработчику, потому и просим.
Деньги давать не пробовали? А то вот у меня к еде из магазина больше доверия, чем к еде с помойки, но это же не причина, чтобы попрошайничать.

Цитата
two_oceans пишет:
3) На Linux есть аналог DLL - SO библиотеки.
С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.

Цитата
two_oceans пишет:
4) Здравствуйте, при всем уважении, а кроме семейства Си языки какие-то знаете? У меня например мои все DLL на Паскале. Главное, что бы формат параметров можно было описать на любом языке - неважен язык программирования разработчика DLL.
Ага, сейчас.
- Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.
- Предположим, у нас есть простенькая функция:
__declspec(dllexport) std::string foo(const std::string &d) {return d;} Сможете Вы вызвать её из Паскаля? Вряд ли. Я именно об этом. А сишный интерфейс (const char *) - устарел и неудобен.

Цитата
two_oceans пишет:
Если же Вы имеете ввиду ООП при работе самой библиотеки, то огромное количество COM объектов как раз используют фабрики экземпляров в виде DLL и OCX TLB (расширение не особо имеет значение - по сути это тоже внешний исполняемый код, подгружаемый программой). Но COM объекты как раз и привяжут нас к Windows. dotNet полагаю тоже?
SOAP нас к винде не привязывает. А com-объекты - да, привязали бы не хуже dll.

Цитата
two_oceans пишет:
5) Ошибки есть везде и зона ответственности не разграничена, согласен. Но посмотрим, в среднем процессе Windows 7 вовлечены более чем 100 библиотек - не потому что разработчик программы их все загрузил, а потому системные и околосистемные библиотеки тянут за собой огромное количество зависимостей. В этом смысле, если добавится еще одна библиотека, погоды это не сделает.
Те DLL, которые грузятся при старте обычной программы, в основном созданы MS - компанией с очень серьёзным подходом к качеству ПО. В России аналогов нет. Да и у MS регулярно находят проблемы.

Цитата
two_oceans пишет:
Для этого есть современные средства отладки собирающие данные активности на момент сбоя во всех потоках процесса. Определить, что вылетело при выполнении такой-то функции - на раз.
Это если оно вылетело. А если memory corruption? Такое тоже ищется, но ох не сразу.


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

Цитата
two_oceans пишет:

6) проблемы обновления DLL абсолютно такие же, как и у программы, а именно - что заменить файл модуля, который запущен в данный момент, мягко говоря, непросто.
Технически - такие же. Юридически - нет: если нет DLL, то техподдержка ГИС ЖКХ избавляется от разговоров про эту DLL.
#77
0 0
Цитата
AlcorVol пишет:
Цитата
Sergey Cheban пишет:
Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить.
Согласен. И где же специальные "средства отладки" при загрузке информации через XLSX? Их просто нет. Только ответные диагностики. Вот, их-то и надо показывать оператору. Другого выхода нет. И если диагностики связаны с программными ошибками, то потребуется, конечно, доработка программы. В иных случаях реагировать придётся оператору.
Что-то я потерял нить разговора. Помнится, начинали мы с того, что злые разработчики ГИС ЖКХ заставляют бедных разработчиков подключаться к своим тестовым стендам. Я говорил, что без тестового стенда невозможно выловить ошибки софта, работающего с ГИС ЖКХ, и этот стенд - не зло, а полезная штука.

Если Вам диагностики не хватает - ну ок, это может быть проблемой. Хотя тут тоже аккуратно надо, чтобы не дойти до диагностики вида "Ошибка в 13 бите пароля".
#78
0 0
Цитата
Sergey Cheban пишет:
Что-то я потерял нить разговора. Помнится, начинали мы с того, что злые разработчики ГИС ЖКХ заставляют бедных разработчиков подключаться к своим тестовым стендам.
Ну, не надо утрировать. :) Перечитайте всё, написанное выше. Особое внимание обратите на объём документации по взаимодействию ИС с ГИС через Web-сервисы. Сам подход никак не предполагает, что каждое ТСЖ будет регистрироваться как "собственная ИС" (в понимании разработчиков ГИС), проходить испытания на стенде и выходить на промышленную эксплуатацию. А не хотите так - долбите ручками в Экселе. Такая вот "альтернатива". Они никак не предполагали, что куча народу будет искать средства автоматического формирования XLSX-файлов...

Впрочем, я уже повторяюсь. И предлагаю не толочь воду в ступе. Ваша позиция мне понятна. Надеюсь, что моя Вам - тоже.
#79
0 0
Цитата
Sergey Cheban пишет:
Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).
Что-то я такой опции не увидел. И никаких "наводок" на это тоже. Поищу еще, если получится - премного благодарен.
Цитата
Sergey Cheban пишет:
Вообще-то если по уму, то следовало бы требовать подпись и от файлов, передаваемых через ЛК.
Это да. но раз полагаются на ПЭП Госуслуг, нам проще.
Цитата
Sergey Cheban пишет:
Реализации SOAP предлагает не государство, а разработчики
Согласен, но государство покупает реализации SOAP для центральных узлов СМЭВ - ничего не мешает включить в ТЗ пункт про библиотеку для свободного распространения. Бог с реализацией, но на данный момент каждая ГИС дополняет формат SOAP как в голову придет разработчикам ГИС. Минкомсвязь могло бы утвердить правила, уточняющие как именно дополнять стандарт - в какое место файла располагать ЭП, как стандартно указывать отправителя/получателя и тд. В конце концов, Little Endian или Big Endian использовать в кодировке ЭП. Это явно задача государства, а не разработчиков, которые реализуют только один вариант, но при этом никто не может внятно объяснить, почему нельзя по другому- в ГОСТ это не указано. Тем не менее, другой вариант возвращается с ошибкой - "Неверная ЭП".
Цитата
Sergey Cheban пишет:
С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.
Конечно, но это другая платформа, то есть привязка к Windows - мнимая. Тот же код программы, который напишете на Си будет скомпилирован и упакован в разный формат исполняемых файлов для разных операционных систем.
Цитата
Sergey Cheban пишет:
Деньги давать не пробовали?
Что это изменит? Качество вряд ли будет выше пропорционально сумме. Другой вопрос - кому? Реализация SOAP в ГИС довольно неполная и кривоватая, нет никакой гарантии, что другая неполная же реализация других разработчиков совпадет "по кривизне" и будет работать. В магазине Вам тоже могут предложить Столичный хлеб, когда вы пришли за Бородинским. Даже если с одной ГИС будет, хотелось бы универсальную библиотеку для всех федеральных ГИС. А если тем же, кто разрабатывал ГИС, то их компании и так уже заплатило государство (а государство это взяло из налогов и штрафов, то есть с нас с Вами в том числе) и совершенно немалые суммы. Честно, меня просто жаба задавит добавлять к тем суммам.
Цитата
Sergey Cheban пишет:
Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.
Знаю. Я в это когда-то вникал и смогу вызвать функцию, хотя возможно это займет время, чтобы разобрать код на Си и подобрать аналогичное описание объекта на Паскале. Либо подключить другую библиотеку того же языка, реализующую этот объект - если не вникать как объект устроен, а просто скормить, что передали и получить, что нужно либо наоборот. Как правило ключевые слова меняют порядок аргументов, так что для функции с одним аргументом мало что изменится, пример неудачен.
(я таки на Си не пишу, но немного разбираю, char * - указатель на буфер сразу, std::string &d вроде бы указатель на объект из которого еще надо получить указатель на буфер через c_str и длину через length/size, в этом смысле достаточно каким-то образом реализовать или подключить c_str и size. Скорее даже не так - объекты обычно хранят указатели на реализованные методы объекта, то есть достаточно найти в объекте нужный указатель на уже реализованную функцию c_str и узнать как ей передать объект). В общем, я не так хорошо знаю Си, а Вы похоже вообще не знаете Паскаль, примеры тут бессмысленно обсуждать.
Для информации - в Паскале таких ключевых слов тоже с десяток, включая вышеназванные - это раз. Если ни одно не подойдет, то никто не отменял возможность сделать "оберточную функцию" и вставить в код на Паскале операторную скобку asm .. end и написать внутри код ассемблера для передачи параметров и вызова импортируемой функции - это два. Конечно, при этом вся типизация коту под хвост и возможны ошибки. Но, надеюсь Вы не считаете, что разные языки для передачи параметров компилируют какой-то иной машинный код, несовместимый с ассемблером под ту же архитектуру процессора? Можно еще проще, просто используем stdcall - большинство языков умеет работать с системными библиотеками. Итого: остается просто описать заголовки (ну или оберточные функции) на нужном языке, а проблема не стоит выеденного яйца - решаем один раз, потом миллионы раз вызываем функцию.
Цитата
Sergey Cheban пишет:
Да и у MS регулярно находят проблемы.
Да и большая часть из них именно переполнение буфера, то есть по сути именно memory corruption. Это именно болезнь языка Си и прямого использования char * - даже хотя есть вариант функций с указанием размера, многие даже в Майкрософт на это плюют и используют функции без ограничения размера либо неправильно вычисляют ограничение. В Паскале все жестче - например, обычный string (shortstring в моей IDE) ограничен 255 байтами и (используя стандартные функции, без обращения к символам по номеру и махинаций с указателями) 256-ой записать невозможно в принципе - при любой записи берется минимум из ограничения и ожидаемого размера данных. Конечно, 255 байт откровенно сказать мало, но тут ничего не мешает найти исходник встроенного типа по образцу сделать собственный тип скажем на 10 мегабайт и тоже жестко вшить в него ограничение.
Цитата
Sergey Cheban пишет:
Пока не решены проблемы с интерфейсами, не вижу смысла это обсуждать.
Учитывая, выше про stdcall, не вижу проблем. Интерфейс всегда можно доработать, если Вам удобнее получать строчку в std::string чем в голом char * то это предмет переговоров о включении дополнительной "оберточной" функции. Либо мне тоже std::string понравится и я портирую объект на Паскаль. Но тут как раз может вылезти что объект не такой уж и std (стандартный), а отличается в разных Си.
Цитата
Sergey Cheban пишет:
Технически - такие же. Юридически - нет: если нет DLL, то техподдержка ГИС ЖКХ избавляется от разговоров про эту DLL.
я и не говорил, что это именно техподдержка ГИС ЖКХ будет по DLL по SOAP работу вести, так как федеральных ГИС много, и желательно общую библиотеку. Есть ситуационный центр электронного правительства. Как вариант, сама компания-разработчик библиотеки. А вот конкретно по библиотеке отчетов для ГИС ЖКХ, там конечно техподдержка этой ГИС и тут все понятно (в смысле наоборот непонятно, с чего начинать).
#80
0 0
Для разработчиков на Паскале (Delphi) напомню, что строковые переменные и в DLL и в программе должны иметь тип shortstring. Все другие строковые типы, указатели на них, а так же примочки в виде делфийских DLL не работают или работают некорректно!
#81
0 0
Цитата
two_oceans пишет:
непонятно, с чего начинать

Из-за этого очень сильные тормоза!
#82
0 0
Цитата
Programmer пишет:
shortstring
Конечно они должны иметь одинаковый тип, точнее одинаково описанный. Хм, никогда не было проблем с этим. Ни со своими DLL, ни с системными. Сейчас перепроверю какой тип использовался, насколько помню pchar и все дела. Точнее, совместимый с ним собственный тип pathstr=array[1..260] of char и запись #0 в конце, от которого брался указатель. Что со мной не так? :D Замечу, что это не был объект и соответственно методы работы с ним реализовались независимо на каждой стороне, операторы не переопределялись. Конечно, так работать неудобно.
Другой вопрос, что типы-объекты нужно правильно (ре)конструировать и правильно передавать - просто положиться на среду программирования не всегда получится. Паскаль обычно использует как ссылку на себя внутри объекта (и она передается в метод в регистре процессора, а не через стек) ссылку на данные объекта (а не на начало памяти объекта ) - с одной стороны от нее (адрес в большую сторону, насколько помню) данные объекта, с другой стороны (в меньшую сторону соответственно) - адреса функций и процедур (методы) объекта. Если описание объекта не совпадает (методы и данные не совпадут после передачи) либо если передать ссылку на данные вместо объекта целиком и наоборот (так при передаче адресов методов может не оказаться в объекте на стороне-получателе), то ничего работать не будет.
Поэтому (если не заморачиваться) обычно и нужно избегать передавать объекты. Но, если я реконструирую объект после получения (исправлю адреса методов и поставлю указатель на нужное место), то проблем быть не должно. В этом смысле общее адресное пространство между программой и библиотекой скорее плюс, ссылки на методы должны быть все еще действительными после передачи. Однако, тут важно помнить, что адрес самой DLL может измениться при загрузке библиотеки, и если реализация объекта находится в DLL, то изменится и адрес реализации метода. Поэтому адрес метода нужно не прописывать конкретной цифрой, а импортировать либо находить системной функцией (GetProcAddress) после загрузки библиотеки.
Цитата
Programmer пишет:
Цитата
two_oceans пишет:
[99427]непонятно, с чего начинать
Из-за этого очень сильные тормоза!
Ну, в смысле, понятно, что можно получить описания схем и их проанализировать на предмет новых полей, изменений формата, удалений полей. Но далее нужно как-то связать с получаемыми из базы данных УО/ТСЖ данными. Пока придумался такой вариант - после обновления документация анализируется и структура тегов вроде
Цитата
... <soapenv:Body>
<pay:importNotificationsOfOrderExecutionRequest base:version="10.0.1.1">
<pay:NotificationOfOrderExecutionType>

<pay1:RecipientInfo>
<org:INN>3436018361</org:INN>...
преобразуется в имя переменной: в начале и конце строки ставится $, имена тегов (можно без пространств имен, но тогда еще отдельно нужно имена пространств передавать и сопоставлять плюс проверять ссылки на них) соединяются точками согласно иерархии, получится строка вроде$soapenv:Body.pay:importNotificationsOfOrderExecutionRequest.pay:NotificationOfOrderExecutionType.pay1:RecipientInfo.org:INN$ (с пространствами) либо $Body.importNotificationsOfOrderExecutionRequest.NotificationOfOrderExecutionType.RecipientInfo.INN$ (без пространств), формируется и где-то сохраняется шаблон в котором вместо значения подставлена такая строка (и так по всем значениям). Можно конечно как-то сокращать имена до $RecipientInfo.INN$ например, а то в shortstring не впишемся, но тогда нужно сопоставлять сокращенные и краткие имена. Зато попутно можно сопоставлять новое положение переменной в иерархии старому краткому имени и это может делать "опытный пользователь", не обязательно программист.
По запросу от библиотеки программа может получить список массив имен нужных переменных (без $), массив их обязательности и версию для конкретного шаблона SOAP запроса.
При формировании из программы передаются два массива строк для формирования отчета - один с именами переменных (без $), другой со соответствующими значениями переменных (значения уже заранее переведены в строку). Функция проверяет, что все переменные заполнены либо остались незаполнены необязательные (если не хватает выдает ошибку и, допустим, массив нехватающих переменных и их обязательность), убирает пустые необязательные и формирует готовый для отправки SOAP запрос, соответствующий новому шаблону.
Результат программа проверяет, что там нет "Продаю имущество имярек за 1 рубль". Можно, например, выводить пользователю для визуальной оценки (если XML плохо смотреть, то можно в библиотеку еще формирование версии для печати заложить на основе переданного XML и данных о стилях полученных из описания новой версии запроса. Чтобы не привязываться к платформе можно записывать html для печати во временную папку и открывать ассоциированным браузером. Либо выводить в самой программе псевдографикой моноширинным шрифтом как у AlcorVol) и ждать нажатия кнопки "Подписать и отправить".
После этого программа передает запрос в другую библиотеку для подписания/отправки вместе с адресом, портом, сертификатом. Как-то так, но это совсем "просто" получается.

Отправлено спустя 49 минуты 52 секунды:
Еще подумалось, что можно в библиотеке подписания просто запретить слова из юридических формул вроде "Продаю" "Дарю" "Завещаю" и возвращать ошибку, если текст их содержит.
#83
0 0
Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).
Что-то я такой опции не увидел. И никаких "наводок" на это тоже. Поищу еще, если получится - премного благодарен.
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Реализации SOAP предлагает не государство, а разработчики
Согласен, но государство покупает реализации SOAP для центральных узлов СМЭВ - ничего не мешает включить в ТЗ пункт про библиотеку для свободного распространения. Бог с реализацией, но на данный момент каждая ГИС дополняет формат SOAP как в голову придет разработчикам ГИС. Минкомсвязь могло бы утвердить правила, уточняющие как именно дополнять стандарт - в какое место файла располагать ЭП, как стандартно указывать отправителя/получателя и тд. В конце концов, Little Endian или Big Endian использовать в кодировке ЭП. Это явно задача государства, а не разработчиков, которые реализуют только один вариант, но при этом никто не может внятно объяснить, почему нельзя по другому- в ГОСТ это не указано. Тем не менее, другой вариант возвращается с ошибкой - "Неверная ЭП".
Вот отклонение от отраслевых стандартов (я имею в виду не только ГОСТ, но и RFC и пр.) - это серьёзная проблема, и здесь я однозначно на стороне тех, кто хочет, чтобы стандарты соблюдались.
Установление новых стандартов и повышение единообразия - тоже дело хорошее, но проблема в том, что всё это требует времени, а внедрять надо уже сейчас. Так что увы, строгий порядок нас ждёт только на кладбище (квартал такой-то, ряд такой-то, могила такая-то), а пока мы живём, нам придётся бороться с беспорядком. Так этот мир устроен.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.
Конечно, но это другая платформа, то есть привязка к Windows - мнимая. Тот же код программы, который напишете на Си будет скомпилирован и упакован в разный формат исполняемых файлов для разных операционных систем.
Если Вы считаете, что эта штука действительно нужная, то попробуйте сами её сделать, а потом продать. Ну или хотя бы прикиньте, сколько времени и людей потребуется на разработку, и сколько экземпляров по какой цене можно продать. Если получается не выгодно, то и государству не стоит этим заниматься.

А написание портабельного кода - дело хоть и не невозможное, но всё же не тривиальное, и граблей на этом пути разложено значительно больше, чем хотелось бы. Тот же __stdcall - не стандарт, а расширение языка, gcc его не поймёт.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Деньги давать не пробовали?
Что это изменит? Качество вряд ли будет выше пропорционально сумме. Другой вопрос - кому? Реализация SOAP в ГИС довольно неполная и кривоватая, нет никакой гарантии, что другая неполная же реализация других разработчиков совпадет "по кривизне" и будет работать.
Вот про кривизну - это уже более конструктивный разговор.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.
Знаю. Я в это когда-то вникал и смогу вызвать функцию, хотя возможно это займет время, чтобы разобрать код на Си и подобрать аналогичное описание объекта на Паскале. Либо подключить другую библиотеку того же языка, реализующую этот объект - если не вникать как объект устроен, а просто скормить, что передали и получить, что нужно либо наоборот. Как правило ключевые слова меняют порядок аргументов, так что для функции с одним аргументом мало что изменится, пример неудачен.
Порядок аргументов, ответственность за очистку стека, передача части аргументов через регистры.

Цитата
two_oceans пишет:
(я таки на Си не пишу, но немного разбираю, char * - указатель на буфер сразу, std::string &d вроде бы указатель на объект из которого еще надо получить указатель на буфер через c_str и длину через length/size, в этом смысле достаточно каким-то образом реализовать или подключить c_str и size. Скорее даже не так - объекты обычно хранят указатели на реализованные методы объекта, то есть достаточно найти в объекте нужный указатель на уже реализованную функцию c_str и узнать как ей передать объект). В общем, я не так хорошо знаю Си, а Вы похоже вообще не знаете Паскаль, примеры тут бессмысленно обсуждать.
Я скромно замечу, что программированием занимаюсь как хобби с конца восьмидесятых, а профессионально с середины девяностых, и паскаля не миновал.
Проблемы с std::string и прочими не-сишными типами в том, что двоичная совместимость гарантируется только тогда, когда всё собрано одним и тем же компилятором с одними и теми же настройками. Обычно двоичную совместимость стараются сохранять в пределах мажорной версии компилятора, хотя даже из этого правила бывают исключения. И нет, конкретно в случае std::string у Вас не будет указателя на таблицу виртуальных методов, потому что эти методы не виртуальные.

Цитата
two_oceans пишет:
Для информации - в Паскале таких ключевых слов тоже с десяток, включая вышеназванные - это раз. Если ни одно не подойдет, то никто не отменял возможность сделать "оберточную функцию" и вставить в код на Паскале операторную скобку asm .. end и написать внутри код ассемблера для передачи параметров и вызова импортируемой функции - это два. Конечно, при этом вся типизация коту под хвост и возможны ошибки. Но, надеюсь Вы не считаете, что разные языки для передачи параметров компилируют какой-то иной машинный код, несовместимый с ассемблером под ту же архитектуру процессора? Можно еще проще, просто используем stdcall - большинство языков умеет работать с системными библиотеками. Итого: остается просто описать заголовки (ну или оберточные функции) на нужном языке, а проблема не стоит выеденного яйца - решаем один раз, потом миллионы раз вызываем функцию.
__stdcall как раз и оставит нам интерфейс на голом Си. С небезопасными строками, без поддержки исключений (exceptions), с проблемами освобождения переданной памяти, с проблемами использования из языков, отличных от си-подобных.
Паскаль, насколько я понимаю, застрял в девяностых, и поэтому у него с SOAP проблемы. Но в более современных языках всё уже есть. Либо в виде внешних библиотек, либо прямо в составе языка.

Цитата
two_oceans пишет:
Но тут как раз может вылезти что объект не такой уж и std (стандартный), а отличается в разных Си.
Двоичное представление - отличается.
#84
0 0
Цитата
Sergey Cheban пишет:
Так что увы, строгий порядок нас ждёт только на кладбище (квартал такой-то, ряд такой-то, могила такая-то), а пока мы живём, нам придётся бороться с беспорядком. Так этот мир устроен.
Увы, в реальности и кладбища далеко не везде упорядочены рядами и кварталами.
Цитата
Sergey Cheban пишет:
Если Вы считаете, что эта штука действительно нужная, то попробуйте сами её сделать, а потом продать. Ну или хотя бы прикиньте, сколько времени и людей потребуется на разработку, и сколько экземпляров по какой цене можно продать. Если получается не выгодно, то и государству не стоит этим заниматься.
Да, считаю что нужна. Федеральных ГИС все больше. В принципе, меня одного хватит, только в одиночку это может затянуться надолго. А вот продавать - смысла не вижу, так как это потянет ответственность за дальнейшую поддержку. Максимум - добровольные пожертвования.
Цитата
Sergey Cheban пишет:
А написание портабельного кода - дело хоть и не невозможное, но всё же не тривиальное, и граблей на этом пути разложено значительно больше, чем хотелось бы. Тот же __stdcall - не стандарт, а расширение языка, gcc его не поймёт.
Согласен. Однако, наверняка можно использовать средства, которые понимают.
Цитата
Sergey Cheban пишет:
паскаля не миновал
Прошу простить в таком случае.
Цитата
Sergey Cheban пишет:
Проблемы с std::string и прочими не-сишными типами в том, что двоичная совместимость гарантируется только тогда, когда всё собрано одним и тем же компилятором с одними и теми же настройками. Обычно двоичную совместимость стараются сохранять в пределах мажорной версии компилятора, хотя даже из этого правила бывают исключения. И нет, конкретно в случае std::string у Вас не будет указателя на таблицу виртуальных методов, потому что эти методы не виртуальные.
Какой ужас, тогда мне вообще не ясно почему Си++ и более поздние версии так популярны. В любом случае, передавать методы как бы не обязательно, важны данные, в том же дельфи есть тип, в котором в начале длина строки (вариации тоже разные, до 8 байт на длину), потом само значение, для гарантии еще #0 в конце. Все это (и функции работы с ним) можно описать в Unit на Паскале или соответственно в заголовочном файле Си.
Цитата
Sergey Cheban пишет:
__stdcall как раз и оставит нам интерфейс на голом Си. С небезопасными строками, без поддержки исключений (exceptions), с проблемами освобождения переданной памяти, с проблемами использования из языков, отличных от си-подобных.
Что ж поделать, если с безопасными такая неприятность из-за двоичной несовместимости.
Цитата
Sergey Cheban пишет:
Паскаль, насколько я понимаю, застрял в девяностых, и поэтому у него с SOAP проблемы. Но в более современных языках всё уже есть. Либо в виде внешних библиотек, либо прямо в составе языка.
Что застрял, не отрицаю. Однако с SOAP в целом никаких проблем нет, есть стандартные Unit ("диалекты" Паскаля можно адаптировать, так что насобирать их не проблема). Проблемы начинаются, когда SOAP нужно подписать ЭП вообще (из-за не очень верной каконикализации в стандартных Unit (и даже в старых системных com-объектах), не совпадающей с новейшими каноникализаторами С#, использованными в ГИС), и невнятно определенной стандартом ГОСТ ЭП в частности. С отправкой на веб-сервис тоже не все гладко - модули есть, но в них нужно добавить "вкус шифрования ГОСТ". Итого - Unit, добавляющий к SOAP "вкус ГОСТ", как раз бы пригодился. Реализации этого естественно уже есть на Паскале, но, к сожалению, готового решения не нашел, ни бесплатно ни за деньги. На форумах активно обсуждались проблемы написания, но потом авторы написали и замолчали, на попытки связаться не отвечают. Естественно, можно попробовать перенести с других языков - но для этого нужно знать язык источника и тогда собственно проще писать именно на нем. А библиотека - способ не переписывать весь код с другого языка, а только интерфейсы - это проще.
С другой стороны, смены версий форматов запросов SOAP тоже сильно действуют на нервы и вынести функционал SOAP вне "основного кода" своей ИС в "модуль генерации SOAP" было бы логично. Начать с присвоения хранимым в своей ИС данным неких однозначных имен. Дальнейшие шаги по сопоставлению этих имен с тегами в запросах SOAP не потребуют изменения ИС, а простой смены настроек "модуля генерации SOAP". А вот если понадобятся передавать данные, которых нет в ИС - собственную ИС все равно придется дорабатывать: добавлять таблицы/поля для хранения данных, формы ввода и определять новые имена, но это не так сложно, по сравнению с чтением огромной, меняющейся и частично неверной документации к запросам. И снова в этом случае код "модуля генерации SOAP" менять не придется, а только его настройки. Если посмотреть шире, то "модуль генерации SOAP" будет в общих чертах одинаков практически у всех. Какой смысл тратить человеко-часы на написание его снова и снова разными разработчиками. С моей точки зрения, библиотека DLL как раз такой способ вынести общий, редко обновляемый функционал вне "основного кода" ИС.
Кроме того, если не ограничиваться ГИС ЖКХ, то, например, СМЭВ требует сохранять все запросы и ответы в базе данных (так порой сделаешь неправильный запрос, обнаружишь тестом, что в нем ошибка еще до отправки, а нет - удалять нельзя даже неотправленный запрос, так и висит как памятник глупости), а это в свою очередь пересекается с импортозамещением баз данных. То есть, по-хорошему, нужна вообще платформа включающая формирование SOAP из XML, подписание, отправку и отечественную базу данных (ясно что это уже не бесплатно, но хотелось бы за приемлемые деньги).

Отправлено спустя 26 минуты 50 секунды:
Цитата
Sergey Cheban пишет:
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.
Спасибо, попробую. Логично, я эту функцию и использовал, но после выбора адреса - выдало, что у меня нет прав. Правда, номер лицевого я не указывал (и мне интересно как я должен был об этом догадаться). С этим тоже проблема - например, у нас счета одной РСО выглядят вроде "01-1089" (особенность местного разработчика ПО, "01-" это номер УО/РСО), но в квитанции банк пишет просто 1089 и реквизиты компании. У другой РСО счет вида "ЧРТ010111111", в квитанции также, но на их сайте, например, нужно вводить без букв, только цифры. Поэтому я и не стал вводить лицевой счет без дополнительной "наводки" - нужно еще догадаться/подобрать, что РСО указало в этом поле.
#85
0 0
Цитата
two_oceans пишет:
Еще подумалось, что можно в библиотеке подписания просто запретить слова из юридических формул вроде "Продаю" "Дарю" "Завещаю" и возвращать ошибку, если текст их содержит.
Я бы предложил более традиционный подход: использовать для подписания документов ноутбук, изолированный от сети и хранящийся в сейфе. Документы для подписания приносить на флешке и перед подписанием просматривать глазами ответственного человека. И ОС, и криптографический софт на ноутбук установить из доверенных источников (как минимум, не из помойки, как максимум - с сертификатом от ФСБ, и ноутбук тоже сертифицированный). Другой софт, включая антивирусы, - не устанавливать вообще.
Второй вариант - использовать для работы с ГИС ЖКХ такой сертификат электронной подписи, который позволит работать с ГИС ЖКХ, но при этом не позволит ничего продать, подарить или завещать в силу "ограничений, содержащихся в квалифицированном сертификате". Подробнее, увы, не знаю.
#86
0 0
Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
Проблемы с std::string и прочими не-сишными типами в том, что двоичная совместимость гарантируется только тогда, когда всё собрано одним и тем же компилятором с одними и теми же настройками. Обычно двоичную совместимость стараются сохранять в пределах мажорной версии компилятора, хотя даже из этого правила бывают исключения. И нет, конкретно в случае std::string у Вас не будет указателя на таблицу виртуальных методов, потому что эти методы не виртуальные.
Какой ужас, тогда мне вообще не ясно почему Си++ и более поздние версии так популярны.
На самом деле эта неприятная особенность существенно снижает популярность C++, а в попытках обойти её выросли такие технологии как COM, CORBA, Google Protobuf и XML. Но если у нас для всего есть исходники (что в мире C/C++ типично), то жить можно. Зато мы выигрываем в скорости на самом разнообразном железе.

Цитата
two_oceans пишет:
Итого - Unit, добавляющий к SOAP "вкус ГОСТ", как раз бы пригодился. Реализации этого естественно уже есть на Паскале, но, к сожалению, готового решения не нашел, ни бесплатно ни за деньги. На форумах активно обсуждались проблемы написания, но потом авторы написали и замолчали, на попытки связаться не отвечают. Естественно, можно попробовать перенести с других языков - но для этого нужно знать язык источника и тогда собственно проще писать именно на нем. А библиотека - способ не переписывать весь код с другого языка, а только интерфейсы - это проще.
Насколько я понимаю, разработчики ГИС ЖКХ пишут на C# и совместимы в первую очередь именно с ним, а с другими средствами разработки - как повезёт. Выбор C#, может быть, и не самый идеологически верный, если смотреть с точки зрения идеологов свободного ПО, но это не самый плохой вариант. С "идеологически верными" решениями, уверяю, на практике хлопот было бы не меньше. И я думаю, что лучше для взаимодействия с ГИС ЖКХ использовать C#, чем пытаться заставить работать то же самое на паскале. А паскаль с C# можно дружить уже на локальном компе.

Цитата
two_oceans пишет:
С другой стороны, смены версий форматов запросов SOAP тоже сильно действуют на нервы и вынести функционал SOAP вне "основного кода" своей ИС в "модуль генерации SOAP" было бы логично. Начать с присвоения хранимым в своей ИС данным неких однозначных имен. Дальнейшие шаги по сопоставлению этих имен с тегами в запросах SOAP не потребуют изменения ИС, а простой смены настроек "модуля генерации SOAP".
Это, увы, следствие agile-подхода в разработке ГИС ЖКХ. Не очень удобно, зато сравнительно быстро и сравнительно дёшево. Альтернатива этому подходу - всякие ФГУП, которые пытаются действовать "правильно", но при этом хронически не укладываются в требования, бюджет и сроки. Ну и ещё бывают life-critical systems (авиация, атом и пр), там порядка несколько больше, но зато и цена такая, что ой.

Цитата
two_oceans пишет:
С моей точки зрения, библиотека DLL как раз такой способ вынести общий, редко обновляемый функционал вне "основного кода" ИС.
Увы, нет. У разработчиков ГИС ЖКХ нет "редко обновляемого функционала". Они пытаются строить систему на ходу и не знают, что будет завтра. Параллельно меняется и законодательство, и требования, и всякие внешние обстоятельства, и внутренние баги, и пр. И смежники наверняка свои сюрпризы подкидывают, начиная с ошибочных данных в Росреестре. Со временем, конечно, всё это утрясётся, но пока - так.

Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.
Спасибо, попробую. Логично, я эту функцию и использовал, но после выбора адреса - выдало, что у меня нет прав. Правда, номер лицевого я не указывал (и мне интересно как я должен был об этом догадаться). С этим тоже проблема - например, у нас счета одной РСО выглядят вроде "01-1089" (особенность местного разработчика ПО, "01-" это номер УО/РСО), но в квитанции банк пишет просто 1089 и реквизиты компании. У другой РСО счет вида "ЧРТ010111111", в квитанции также, но на их сайте, например, нужно вводить без букв, только цифры. Поэтому я и не стал вводить лицевой счет без дополнительной "наводки" - нужно еще догадаться/подобрать, что РСО указало в этом поле.
Там нужен номер лицевого счёта от ГИС ЖКХ, а не от РСО. Поскольку на внедрение ГИС ЖКХ все дружно забили, этих счетов почти ни у кого нет, и подключать нечего. Мне повезло: у моего отца несколько дней был лицевой счёт, пока его не удалили, и я успел заметить и попробовать подключиться.
#87
0 0
Цитата
Sergey Cheban пишет:
Я бы предложил более традиционный подход: использовать для подписания документов ноутбук, изолированный от сети и хранящийся в сейфе.
Согласен с этим вариантом, если бы это было в идеальном мире, где некая госструктура написала все библиотеки и сертифицировала. С другой стороны, со стороны государства все больше контроля и нет гарантий, что и в сертифицированных программах нет "закладок". Начать можно с того, что, насколько я знаю, до сих пор не опубликован алгоритм, отличающий "слабые" ключи ГОСТ от "сильных". При этом примеры "слабых" ключей есть (как минимум тривиальный - когда зашифрованный текст равен исходному). Конечно, хорошо, что не опубликован, но хотелось бы убедится, что ключи у нас не "слабые".
А Вы упорно упоминаете "про помойку". За "платформу" в целом можно заплатить, но в разумных пределах, скажем до 20-30 тысяч за все (то есть за каждую "перепроданную" доработанную копию). За одну-две сертифицированных библиотеки для написания своей программы, которую я не собираюсь продавать - ну долларов пять максимум.

Собственно, я никого не убеждаю в использовании библиотек неизвестного происхождения, у всех своя голова на плечах и свои представления кому и чему они доверяют. Я ведь тоже не беру чужую библиотеку, а пишу свою. Если кто-то захочет ее использовать - пожалуйста, мне не жалко (еще даже не написал, а уже столько шума), если кто-то побоится - их личное дело. Даже без генерации подписи на "Продам" в интернете полно вирусов на сайтах, где можно "найти" какую-то библиотеку и вполне очевидно, что осторожность с чужим кодом (а лучше паранойя) не помешает. Так что, может быть, хватит уже напоминать "про помойку" почти в каждом сообщении - режет глаз.

Ближе к теме. При всех плюсах подхода "ноутбук в сейфе плюс ответственный человек" есть и минусы: 1) для подписания в интеграции это (перенос туда-сюда на флешке, просмотр каждого XML) не подойдет, особенно если документов много и для XML нет вида для печати - глаз человека "замылится". От "Продам" и "Дарю" это, может быть, и защитит, но от прочих ошибок - нет. А если человек сидит и просматривает, хотелось бы чтобы это несло и другую полезную нагрузку. С другой стороны, если есть вид для печати, то опять же нужна гарантия, что на экране то содержание, которое подписываешь; 2) тривиально, но не у всех размер сейфа позволит положить туда производительный ноутбук; 3) ФСБ и др. особенно не рекомендуют использовать ноутбуки - украсть ноутбук гораздо проще и там практически всегда есть функция беспроводной сети, кстати, в сертифицированных ноутбуках антенну физически отрезают (у нас один есть в "секретном" отделе - стоимость железа, программ, вместе с сертификацией где-то 120 тысяч, сертификацию периодически нужно продлять, так что для многих при упоминании стоимости вопрос сразу закрывается); 4) для организации это значит минус один сотрудник, занимающийся только подписям; 5) флешки и без антивируса - это точно идеальный мир, а не тот в котором мы живем. В сертифицированных "секретных" ноутбуках вообще запрет подключать флешки - весь обмен документами исключительно на оптических дисках, а антивирус установлен, DrWeb.
Цитата
Sergey Cheban пишет:
Второй вариант - использовать для работы с ГИС ЖКХ такой сертификат электронной подписи, который позволит работать с ГИС ЖКХ, но при этом не позволит ничего продать, подарить или завещать в силу "ограничений, содержащихся в квалифицированном сертификате". Подробнее, увы, не знаю.
С этим я еще более согласен, я бы вообще все сертификаты сотрудников ограничивал к черту. Но с этим все гораздо хуже. Несмотря на упоминание в законе "ограничений, содержащихся в квалифицированном сертификате", фактически я еще не видел ни одного такого сертификата (имею ввиду российского, в зарубежных бывает "Заявление поставщика" - не знаю, может быть это оно и есть). Более того, работники местного отделения Федерального Казначейства, оформляющие заявки в удостоверяющий центр мне официально заявили, что нет возможности исключить использование определенного квалифицированного сертификата за пределами определенной ИС. При этом в форме заявки можно указать те самые ограничения. То есть, хотя ограничения как бы есть, нет механизма, который бы исключал их нарушение. В законе об электронной подписи тоже сказано всего лишь, что владелец должен использовать сертификат, соблюдая установленные в нем ограничения. Лично я не уверен, что этого будет достаточно для признания предложения "Продам..." юридически недействительным. Зато буквально на днях смотрел, что в новой редакции, вступившей в 2016 году, добавили, что любая государственная ИС не может предъявлять к сертификату требования, исключающие возможность использования этого сертификата в других ИС.
#88
0 0
Цитата
Sergey Cheban пишет:
На самом деле эта неприятная особенность существенно снижает популярность C++, а в попытках обойти её выросли такие технологии как COM, CORBA, Google Protobuf и XML. Но если у нас для всего есть исходники (что в мире C/C++ типично), то жить можно. Зато мы выигрываем в скорости на самом разнообразном железе.
Не буду спорить о разнообразии железа и выигрыше у других языков высокого уровня, но вот насчет выигрыша Си, скажем у ассемблера есть сомнения. Даже на x86 у разных процессоров есть различия в скорости выполнения тех же инструкций и многое зависит от того как компилятор переведет язык высокого уровня в машинный код. Вроде как общепринято, что из-за этого ассемблер дает до 40% прироста скорости?
Пожалуйста, поясните, как тут мысль перекинулась на XML? Имеются ввиду манифесты?
Цитата
Sergey Cheban пишет:
Насколько я понимаю, разработчики ГИС ЖКХ пишут на C# и совместимы в первую очередь именно с ним, а с другими средствами разработки - как повезёт. Выбор C#, может быть, и не самый идеологически верный, если смотреть с точки зрения идеологов свободного ПО, но это не самый плохой вариант. С "идеологически верными" решениями, уверяю, на практике хлопот было бы не меньше. И я думаю, что лучше для взаимодействия с ГИС ЖКХ использовать C#, чем пытаться заставить работать то же самое на паскале. А паскаль с C# можно дружить уже на локальном компе.
Лично я даже и не рассматривал с точки зрения свободного ПО, но соглашусь. Для меня проблема не в идеологической верности, а в том что для меня C# это синоним dotNet Framework. Поправьте меня как более сведущий в мире языков Си, если я не прав. Я категорически против таких огромных фреймворков и именно поэтому лет надцать не стал переходить на C#, хотя выглядело чертовски заманчиво. С библиотекой Visual Basic в те времена можно было смириться - она практически везде ставилась с Windows. Но dotNet меня не устраивает - 1) огромный, даже хотя он у меня уже стоит и обновляется, когда вижу в системных требованиях, стараюсь выбрать альтернативное программное решение; 2) постоянно находят ошибки, что можно выполнить произвольную программу с админскими правами; 3) не менее постоянно обновляется, чтобы их закрыть - и после этого не знаешь, а запустится программа или нет; 4) программы требующие его, нужно обязательно устанавливать штатным установщиком, просто распаковать EXE c библиотеками и запустить не получается - выдает кучу ругани на зависимости компонентов, даже если dotNet стоит; 5) серьезно, сообщения об ошибках выглядят как невразумительная ругань, при том не связанная с самой ошибкой. Было большим открытием когда "матерился" на тип integer в веб-клиенте Росстата и исправилось установкой обновления; 6) и вот только после этого идет, что идеологически неверен. В итоге, дружить свое решение с C# смысла не вижу, так как это не уберет зависимости комплекса от dotNet. Поэтому уж лучше "изобрету велосипед", но без dotNet-зависимости. Уверен очень многие разработчики, не использующие C#, будут солидарны со мной.
Цитата
Sergey Cheban пишет:
Это, увы, следствие agile-подхода в разработке ГИС ЖКХ. Не очень удобно, зато сравнительно быстро и сравнительно дёшево. Альтернатива этому подходу - всякие ФГУП, которые пытаются действовать "правильно", но при этом хронически не укладываются в требования, бюджет и сроки. Ну и ещё бывают life-critical systems (авиация, атом и пр), там порядка несколько больше, но зато и цена такая, что ой.
Они (Разработчики ГИС ЖКХ) пытаются строить систему на ходу и не знают, что будет завтра. Параллельно меняется и законодательство, и требования, и всякие внешние обстоятельства, и внутренние баги, и пр. И смежники наверняка свои сюрпризы подкидывают, начиная с ошибочных данных в Росреестре. Со временем, конечно, всё это утрясётся, но пока - так.
С этим соглашусь в целом.
Цитата
Sergey Cheban пишет:
Цитата
two_oceans пишет:
С моей точки зрения, библиотека DLL как раз такой способ вынести общий, редко обновляемый функционал вне "основного кода" ИС.
Увы, нет. У разработчиков ГИС ЖКХ нет "редко обновляемого функционала".
Это не полностью верно, мы же не они. У них нет, а у нас может быть. Просто нужно, чтобы все изменения можно было "решить" не изменяя исполняемого кода. Скажем, обменяться настройками. Тут все зависит от того, как выстроить абстракцию.
Простой пример, понятный каждому программисту: если меняются требования к Вашей программе, Вы корректируете исходники, а не обновляете транслятор/компилятор! В этом случае, можно считать правила формирования машинного кода под конкретную архитектуру - стандартом, компилятор - редко обновляемым функционалом, а исходники Вашей программы и передаваемые опции - своего рода "настройками" для него. То есть берете "настройки" (исходник), отдаете "редко обновляемому функционалу" (компилятору), получаете "продукт" (исполняемый файл) соответствующий "стандарту" (правилам формирования машинного кода). Важно взять за "стандарт" что-то такое, чего разработчики не собираются менять. Ну вот вообще не собираются.
Применительно к интеграции с ГИС ЖКХ логично взять за "стандарт" описание протокола SOAP, за рамки которого разработчики не собираются слишком сильно выходить. Если 1) сделать полную реализацию всех его возможных деталей в "модуле генерации SOAP" ; 2) в "настройках" по факту указать какие именно детали реализации и как использовать плюс какой шаблон использовать, тогда "настройки" (плюс данные) можно воспринимать как своего рода исходник, а "модуль генерации SOAP" как своего рода транслятор, а готовый запрос SOAP как продукт трансляции. Все счастливы, а модуль генерации можно не обновлять. Конечно, как все "универсальное" (реализующее все возможные детали и анализирующее "настройки" при выполнении) это будет работать гораздо медленее, чем "специализированное" под конкретные детали, используемые конкретной ГИС на текущий момент. Другой вопрос, если разработчики вдруг захотят добавить нечто не предусмотренное протоколом. Или расширят стандарт так, как мы не предусмотрели. Тогда да, придется модуль изменять. Поэтому важно заранее хорошо придумать как такие расширения отразить в настройках, когда они внезапно появятся.
Цитата
Sergey Cheban пишет:
Цитата
two_oceans пишет:
Цитата
Sergey Cheban пишет:
По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.
Спасибо, попробую. Логично, я эту функцию и использовал, но после выбора адреса - выдало, что у меня нет прав. Правда, номер лицевого я не указывал (и мне интересно как я должен был об этом догадаться). С этим тоже проблема - например, у нас счета одной РСО выглядят вроде "01-1089" (особенность местного разработчика ПО, "01-" это номер УО/РСО), но в квитанции банк пишет просто 1089 и реквизиты компании. У другой РСО счет вида "ЧРТ010111111", в квитанции также, но на их сайте, например, нужно вводить без букв, только цифры. Поэтому я и не стал вводить лицевой счет без дополнительной "наводки" - нужно еще догадаться/подобрать, что РСО указало в этом поле.
Там нужен номер лицевого счёта от ГИС ЖКХ, а не от РСО. Поскольку на внедрение ГИС ЖКХ все дружно забили, этих счетов почти ни у кого нет, и подключать нечего. Мне повезло: у моего отца несколько дней был лицевой счёт, пока его не удалили, и я успел заметить и попробовать подключиться.
Шутите? Повезло? Если так, то о каком добавлении своих/чужих счетов можно говорить. Подбирать ЕЛС никто не будет и в квитанции ЕЛС пока не фигурирует. Еще вариант прийти в УК/РСО лично и между сверкой платежей выспросить/подсмотреть. А значит на этом можно пока поставить точку - без знания ЕЛС сможет подключить только "собственник". А значит внесенные сведения практически никто не увидит. А значит "большинству населения" толку ноль от ГИС - вроде все полезно, а доступа нет.
#89
0 0
Цитата
two_oceans пишет:
А Вы упорно упоминаете "про помойку". ... Так что, может быть, хватит уже напоминать "про помойку" почти в каждом сообщении - режет глаз.
Да господь с Вами. В первый раз упомянул.

Цитата
two_oceans пишет:
За "платформу" в целом можно заплатить, но в разумных пределах, скажем до 20-30 тысяч за все (то есть за каждую "перепроданную" доработанную копию). За одну-две сертифицированных библиотеки для написания своей программы, которую я не собираюсь продавать - ну долларов пять максимум.
В принципе можно и бесплатный openssl взять: хоть к нему и есть вопросы, я совсем не уверен, что решения с сертификатом от ФСБ будут лучше.

Я в основном о том, чтобы не использовать ЭЦП на том же компе, на котором внук ген. директора по ночам режется в пиратские игры. Всё, что сверх этого (сертификаты ФСБ, отрезание антенн и пр.) - уместно лишь тогда, когда есть что защищать. Если у нас ТСЖ на десять квартир, то нет смысла тратить сотни тысяч на безопасность: ущерб от взлома будет меньше.

Цитата
two_oceans пишет:
Лично я не уверен, что этого будет достаточно для признания предложения "Продам..." юридически недействительным. Зато буквально на днях смотрел, что в новой редакции, вступившей в 2016 году, добавили, что любая государственная ИС не может предъявлять к сертификату требования, исключающие возможность использования этого сертификата в других ИС.
Увы, увы. Насколько я понимаю, нынешняя политика ведомств в области ЭЦП сводится к выжиманию денег за сертификаты "для работы с площадкой Росраспилрегулирование", а о том, чтобы получить денег за что-то полезное, они даже не думают.
#90
0 0
Так, да что такое, в третий раз браузер завис при написании ответа. Отправлю пустое сообщение с цитатами, потом добью текст по частям.
Цитата
Sergey Cheban пишет:
Цитата
two_oceans пишет:
За "платформу" в целом можно заплатить, но в разумных пределах, скажем до 20-30 тысяч за все (то есть за каждую "перепроданную" доработанную копию). За одну-две сертифицированных библиотеки для написания своей программы, которую я не собираюсь продавать - ну долларов пять максимум.
В принципе можно и бесплатный openssl взять: хоть к нему и есть вопросы, я совсем не уверен, что решения с сертификатом от ФСБ будут лучше.
Согласен. Уже есть сертифицированные решения, основанные на ветке OpenSSL (МагПро крипто пакет, кажется). То есть сертификация вряд ли означает отсутствие всех уязвимостей, скорее проверялся алгоритм формирования ключа ГОСТ и что с ключом не производится "левых" операций. При этом такая сертифицированная версия OpenSSL уже не бесплатна. Это что касается криптографических операций и подписи cades.
Тут наверно нужно еще сказать, что вызов самого исполняемого файла OpenSSL из программы выглядит как минимум не эстетично, то есть более интересно использовать ssleay32.dll и libeay32.dll. Другой довод в эту пользу - антивирусы крайне отрицательно относятся к программам, которые одновременно обращаются к интернету и запускают некий исполняемый файл - это классифицируется как неопознанный троян. У меня был такой прецедент (вызывал winrar.exe для подсчета CRC32, потом отправлял другому экземпляру программы и DrWeb определил программу как троян. Пришлось переписать на использование zlib.dll), и мне больше не хочется объяснять кому-то, что моя программа на самом деле не вирус. (Самое смешное, что программа администрирования, которая на самом деле аналогична трояну - выполняет произвольную команду полученную по локальной сети - антивирусами не блокировалась.)
У нас же задача немного сложнее - подписать XML другим определенным форматом xades-bes и включить подпись в файл. Как я понимаю, OpenSSL "из коробки" этого не умеет - иначе бы зачем изобретали велосипед в тех проектах на хабре. Так что в этом отношении все равно придется реализовать каноникализацию и допиливать формирование ЭП.
Далее, шифрование канала - тут огромное количество средств, начиная от Stunnel на основе OpenSSL (у криптопро своя версия одноименной программы, основана ли на OpenSSL до конца не ясно) до Континент-АП и Vipnet. В общем случае, почти никак не затрагивает нашу программу - меняется только адрес/порт назначения.
А вот с реализацией протокола TLS совсем плохо, несмотря на все уязвимости, OpenSSL тут мало что можно противопоставить. Конечно, есть Континент TLS клиент и Jinn-клиент (рекомендованные для ГИИС "Электронный бюджет"), но можно сказать, что они очень большая редкость. Есть компонент TLS в КриптоПро, но мне пока не очень понятно как его использовать и не понадобится ли отдельная лицензия.
Итого, если не обращать внимание на уязвимости, OpenSSL действительно практически идеальный выбор - допилить xades-bes и вперед.
Цитата
Sergey Cheban пишет:
Я в основном о том, чтобы не использовать ЭЦП на том же компе, на котором внук ген. директора по ночам режется в пиратские игры. Всё, что сверх этого (сертификаты ФСБ, отрезание антенн и пр.) - уместно лишь тогда, когда есть что защищать. Если у нас ТСЖ на десять квартир, то нет смысла тратить сотни тысяч на безопасность: ущерб от взлома будет меньше.
Согласен. И не только внук. Порой с виду приличные сотрудники такое устанавливают на своих рабочих местах, что пиратские игры отдыхают. Как минимум будет полезно ограничить права пользователя на таком компьютере.
Сейчас на форуме: 3 пользователя
3 пользователя сейчас на форуме

Подпишись на рассылку новостей ЖКХ, а также наших статей!

Спасибо, вы успешно подписались на рассылку!