Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline auglov  
#1 Оставлено : 27 апреля 2017 г. 11:16:56(UTC)
auglov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 25.12.2014(UTC)
Сообщений: 76

Сказал(а) «Спасибо»: 3 раз
Здравствуйте.

При попытке подключить CAdES.jar в Scala-приложение и собрать его SBT получаю ошибку

package ru.CryptoPro.CAdES contains object and package with same name: b
one of them needs to be removed from classpath

Там, действительно, есть интерфейс b и пакет b.
Пробовал собрать с -Yresolve-term-conflict:object - получаю недоступность, например,

[warn] Class org.bouncycastle.asn1.cms.AttributeTable not found - continuing with a stub.
[error] Class ru.CryptoPro.AdES.external.interfaces.IAdESSignature not found - continuing with a stub.

Сейчас пробую -Yresolve-term-conflict:package - скорее всего, тоже ничего хорошего не будет.

Можете поменять сборку JCP таким образом, чтобы не было подобных конфликтов имен?
Offline basid  
#2 Оставлено : 27 апреля 2017 г. 12:21:00(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,042

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 141 раз в 127 постах
КриптоПро JCP не подключается к приложению.
КриптоПро JCP устанавливается в виде расширения в конкретных JRE/JDK. В вашем случае, JCP должно быть установлено в JRE/JDK, который использует SBT.
Offline auglov  
#3 Оставлено : 27 апреля 2017 г. 12:55:34(UTC)
auglov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 25.12.2014(UTC)
Сообщений: 76

Сказал(а) «Спасибо»: 3 раз
ОК. Установлен.
Дальше я хочу написать

Код:

import ru.CryptoPro.CAdES.CAdESSignature

object CryptoProUtils {
    def checkSign(data: Array[Byte], signature: String): Boolean = {
        val signBytes: Array[Byte] = new BASE64Decoder().decodeBuffer(signature)
        val s = new CAdESSignature(signBytes, data, null)
        s.verify(null, null)
    }
}


Собственно, чтобы случился import ru.CryptoPro.CAdES.CAdESSignature, мне нужно положить CAdES.jar туда, где его будет видеть SBT. Хотя бы, в lib рядом с исходниками. И даже если я его оставлю в JDK, сути это не поменяет - Scalac проверяет, что у него есть в области видимости, находит конфликт, и не знает, что с ним делать. Патч для Scalac решающий проблему с обфусцированными библиотеками уже пытались предложить https://issues.scala-lang.org/browse/SI-2089 но, к сожалению, он так и не был принят. Некоторые другие разработчики уже пошли навстречу и поменяли свои обфускаторы, в результате.

Отредактировано пользователем 27 апреля 2017 г. 13:01:52(UTC)  | Причина: Не указана

Offline auglov  
#4 Оставлено : 27 апреля 2017 г. 13:23:12(UTC)
auglov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 25.12.2014(UTC)
Сообщений: 76

Сказал(а) «Спасибо»: 3 раз
В общем, если не пытаться импортировать что-то из CAdES, то все классно работает.

Вот эта строчка все рушит:

val s = new ru.CryptoPro.CAdES.CAdESSignature(signBytes, response, null)

package CAdES contains object and package with same name: b
[error] one of them needs to be removed from classpath
[error] val s = new ru.CryptoPro.CAdES.CAdESSignature(signBytes, response, null)
[error] ^

Но, например

import ru.CryptoPro.JCP.ASN.CertificateExtensions.{GeneralName, GeneralNames}
import ru.CryptoPro.JCP.ASN.CryptographicMessageSyntax.{SignerInfo, DigestAlgorithmIdentifier, SignedData, ContentInfo}
import ru.CryptoPro.JCP.ASN.PKIX1Explicit88.{IssuerSerial, CertHash, SigningCertificateV2, ALL_PKIX1Explicit88Values}
import ru.CryptoPro.JCP.JCP
import ru.CryptoPro.JCP.params.OID

И все, что с этим связано, работает на ура, потому что в ru.CryptoPro.JCP нет никаких конфликтов имен. Повезло.
Offline basid  
#5 Оставлено : 28 апреля 2017 г. 4:52:59(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,042

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 141 раз в 127 постах
Автор: auglov Перейти к цитате
Собственно, чтобы случился import ru.CryptoPro.CAdES.CAdESSignature, мне нужно положить CAdES.jar туда, где его будет видеть SBT. Хотя бы, в lib рядом с исходниками.
Ещё раз.
Я не помню, как оно было в 1.0, где CADES появился "несколько отдельно", но в двойке, если не ошибаюсь, CADES уже идёт в комплекте.
Поэтому у вас может быть выбор "ставить или не ставить", но не может быть выбора "куда класть".
Механизм расширений для того и существовал, чтобы делать глобальные (для любых приложений) модификации JRE/JDK.

Offline auglov  
#6 Оставлено : 28 апреля 2017 г. 12:04:32(UTC)
auglov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 25.12.2014(UTC)
Сообщений: 76

Сказал(а) «Спасибо»: 3 раз
Еще раз. Проблема не в том, куда ставить или не ставить, а в том, как именно библиотека CAdES.jar воспринимается разными компиляторами.

Maven + Java8 (Javac чистый то есть) спокойно воспринимают наличие в jar-файле Пакета b и рядом лежащего интерфейса b. И все компилируется и запускается просто замечательно, никаких претензий.

Но как только мы берем SBT + Scalac (Scala 2.11) и пробуем скомпилировать тот же самый код, то получаем проблему.

Т.е. все дело именно в совместимости Scalac и такого способа именования сущностей в стороннем jar-файле, при попытке его использовать.

И это устойчиво воспроизводится при попытке использовать вообще любой jar с проблемными именами внутри. Не обязательно от КриптоПро.

Надежды на то, что Scalac будет исправлен нет, так что остается только надежда на КриптоПро, кто когда-нибудь они пойдут на встречу Scala-пользователям и поменяют правила обфускации имен пакетов в JCP.

Offline Евгений Афанасьев  
#7 Оставлено : 28 апреля 2017 г. 12:17:36(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,924
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 690 раз в 651 постах
Здравствуйте.
Проблема только в именах пакетов и/или классов/интерфейсов? Они должны быть уникальными для пакетов или для всех сущностей?
Offline auglov  
#8 Оставлено : 28 апреля 2017 г. 12:33:16(UTC)
auglov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 25.12.2014(UTC)
Сообщений: 76

Сказал(а) «Спасибо»: 3 раз
Здравствуйте, afev.

Как понимаю, проблема только для имен на одном уровне. То есть

ru.CryptoPro.CAdES.a - пакет
ru.CryptoPro.CAdES.a - класс

Это плохо. А вот

ru.CryptoPro.CAdES.p_a.a - допустим, тоже пакет, но уже внутри p_a
ru.CryptoPro.CAdES.a - класс

Уже будет хорошо. Для примера, JCP.jar работает без проблем - там нет похожих конфликтов на одном уровне.

В общем, кажется очевидным решение, если есть возможность, то для обфусцированных имен пакетов добавлять какой-нибудь префикс, например, "p_"

А. Да. И так для всех сущностей на одном уровне. Не важно, пакеты, интерфейсы или классы. Лишь бы полные имена для них различались.

Отредактировано пользователем 28 апреля 2017 г. 12:37:49(UTC)  | Причина: Не указана

Offline Евгений Афанасьев  
#9 Оставлено : 28 апреля 2017 г. 13:10:43(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,924
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 690 раз в 651 постах
Ясно, спасибо, попробуем поправить ситуацию.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.