Re: BC jdk15on 1.62 incompatible with JDK 8

The issue is not a fail of Java or BC, but the additional stuff not 
correctly using it. The ProGuard issue is caused by ProGuard try to 
obfuscate a class wich is beyond the set level - so fault of ProGuard to 
not ignore it (or rather: mis-use of ProGuard in the first place by try 
to obfuscate BC in the first place instead of exclude it as dependency) 
- what's wrong about that android stuff - dunno - but also still has to 
do some about Java8 and some tool access a class it should not. BC by 
itself isn't causing any error. When using 1.62 in a Java8 environment 
the stuff in META-INF/version/9 is never processed at any time - maybe 
only at very signature - so it's not the fault / an issue of BC itself. 
I don't want offense anyone personal, but when sticking to such old 
stuff upgrading a security lib, wich in fact itself doesn't do anything 
wrong, is the issue. When using J8 why not stick to 1.59/1.60 - wich 
obvious works fine without issues. Or, the correct way: consider why not 
to upgrade to newer Java version and newer versions of the used tools, 
as THIS would solve the false-positive-not-really-an-issue.

Matt

Am 06.08.2019 um 23:59 schrieb Andreas Schildbach:
> Nevertheless library users should be able to upgrade easily. A security
> fix can require quick action.
>
>
> On 06/08/2019 23.51, cryptearth wrote:
>> This issue should be marked as invalid, as all the issues caused by
>> tools try to access data they shouldn't access. The module-info.java
>> file is obvious a Java9 feature - when some tools rely on Java8 try to
>> do some with it they're not supposed to (like proguard obfuscation) - so
>> it's wrong to blame the lib but rather it should be reported to the
>> tools failing with that specific class.
>>
>> That's just my opinion ...
>>
>> Matt
>>
>> Am 06.08.2019 um 23:44 schrieb Andreas Schildbach:
>>> This issue is tracked here:
>>>
>>> https://github.com/bcgit/bc-java/issues/512
>>>
>>>
>>> On 06/08/2019 23.26, Mondain wrote:
>>>> Its a breaking change when the bytecode / class version is set at 53.0
>>>> and one is compiling with proguard enabled with JDK 8. I'd like to avoid
>>>> hacky workarounds such as modifying a dependency jar during the build
>>>> process.
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>> On Tue, Aug 6, 2019 at 12:41 PM cryptearth <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>>       Hey Paul,
>>>>
>>>>       Project Jigsaw (module system) was introduced with Java 9 to build
>>>>       smaller footprint runtimes by only provide what's needed to
>>>> execute.
>>>>       As any version below 9 just doesn't access the data you noted it
>>>>       would be no problem. You can try to just remove it - but I guess
>>>>       this might break the signature wich leads to the problem that it
>>>>       can't be used anymore (some internal java security stuff).
>>>>
>>>>       Matt
>>>>
>>>>       Am 06.08.2019 um 21:35 schrieb Mondain:
>>>>>       I got this in a build earlier today where its reporting a class in
>>>>>       the bcpkix-jdk15on jar having been built with JDK 9.
>>>>>
>>>>>        [proguard] java.io.IOException: Can't read
>>>>>      
>>>>> [/home/mondain/.m2/repo/org/bouncycastle/bcpkix-jdk15on/1.62/bcpkix-jdk15on-1.62.jar]
>>>>>
>>>>>       (Can't process class [META-INF/versions/9/module-info.class]
>>>>>       (Unsupported class version number [53.0] (maximum 52.0, Java
>>>>> 1.8)))
>>>>>
>>>>>       Is there somewhere that I should post an issue report? or could I
>>>>>       be mistaken here?
>>>>>
>>>>>       Regards,
>>>>>       Paul
>>>>>       --
>>>>>       http://gregoire.org/
>>>>>       https://github.com/Red5 <http://code.google.com/p/red5/>
>>>>
>>>> -- 
>>>> http://gregoire.org/
>>>> https://github.com/Red5 <http://code.google.com/p/red5/>
>>