You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Emilian Bold <em...@gmail.com> on 2017/10/11 07:47:00 UTC
Security clearance and regressions prevention for changed dependencies [WAS: Re: [MODULE REVIEW] - o.eclipse.jgit - Questions]
Hello,
It seems important to me to double-check binary dependencies where only the Maven hash changes, especially for code that's support to talk to remote servers.
So an actual diff between JAR should be reviewed and posted.
For this particular git JAR were only some META-INF signatures added or do .class files differ?
--emi
Pe 11 oct. 2017, la 08:35, Antonio <an...@vieiro.net> a scris:
>
>
> On 11/10/17 00:59, John McDonnell wrote:
>>>> 2.
>>>>
>>>> There's 1 external dependency here:
>>>> B580E446B543A8DD2F5AA368B07F9C4C9C2E7029
>>>> org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar
>>>>
>>>> I'm not sure about the nosignature part, but I can find[1] this
>>>> version which I guess is the same one, but when I change the
>>>> binaries-list file to use
>>>> B580E446B543A8DD2F5AA368B07F9C4C9C2E7029
>>>> org.eclipse.jgit:org.eclipse.jgit:3.6.2.201501210735-r
>>>>
>>>> I got an error as the hash was wrong and had to change it to be:
>>>> 47D59DFFB5F02470CCFB6C1A5A31B6040A1636E5
>>>> org.eclipse.jgit:org.eclipse.jgit:3.6.2.201501210735-r
>>>>
>>>> Should I be viewing this as a potential question mark, or is it okay?
>>>
>>>
>>> Enter the SHA-1 Checksum at the bottom of this page:
>>>
>>> http://search.maven.org/#advancedsearch
>>>
>>> And doublecheck that the version (name, etc.) is correct.
>> Nope, that hash didn't return anything from that search tool.
>
> This is confusing, I know, so please let me try to explain myself again.
>
> It's normal that the original SHA1 sum (B580E446B54... ) is NOT in maven central. This is so because ages ago the original jar binary file was uploaded to the NetBeans repository by the NSA/KGB/CIA guys :-D.
>
> The idea is to look up the jar again in maven central and fetch a proper binary hash sum. The error suggests (47D59DF...).
>
> What I meant when I said "doublecheck that the version is correct" is that we should now check this new checksum in the http://search.maven.org/#advancedsearch page. If we do so we get [1], which looks correct (same artifact name, same version) for this binary.
>
> So now we can get rid of that NSA/KGB binary that was once placed there in the NetBeans repository (with that B580E... checksum), and replace it with one from Maven central (with that 47D59DF... checksum). This is safer, because NSA/KGB have new hacking techniques and do deliver now new official binaries from maven central. :-D
>
> So, to summarize, we once had this line in the binaries-list file:
>
> B580E446B543A8DD2F5AA368B07F9C4C9C2E7029 org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar
>
> With a SHA-1 sum that is NOT in maven central, and we now have to replace it with
>
> 47D59DFFB5F02470CCFB6C1A5A31B6040A1636E5 org.eclipse.jgit:org.eclipse.jgit:3.6.2.201501210735-r
>
> With corresponds to the official maven binary, with the latest NSA/KGB patches applied.
>
>
> [1] http://search.maven.org/#search%7Cga%7C1%7C1%3A%2247D59DFFB5F02470CCFB6C1A5A31B6040A1636E5%22
>
>>> If the name of the jar file is different from the original entry you'll have
>>> to update nbproject/project.xml and nbproject/project.properties. In your
>>> case the original file had a '_nosignature' thing there, which is missing in
>>> the file downloaded from central.
>
> The original binary was named
>
> org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar
>
> And the one from maven central is named differently:
>
> org.eclipse.jgit-3.6.2.201501210735-r.jar
>
> So we'll have to modify nbproject/project.properties and nbproject/project.xml to reflect this name change.
>
> In project.properties we see
>
> release.external/org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar=modules/org-eclipse-jgit.jar
>
> That should be changed to
>
> release.external/org.eclipse.jgit-3.6.2.201501210735-r.jar=modules/org-eclipse-jgit.jar
>
> (removing the _nosignature stuff)
>
> and in project.xml
>
> <class-path-extension>
> <runtime-relative-path>org-eclipse-jgit.jar</runtime-relative-path>
> <binary-origin>external/org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar</binary-origin>
> </class-path-extension>
>
> should now look like:
>
>
> <class-path-extension>
> <runtime-relative-path>org-eclipse-jgit.jar</runtime-relative-path>
> <binary-origin>external/org.eclipse.jgit-3.6.2.201501210735-r.jar</binary-origin>
> </class-path-extension>
>
> (removing the _nosignature suffix)
>
> To verify that these changes are correct just run "ant test" in the module directory.
>
>
> [2] http://repo1.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/3.6.2.201501210735-r/
>
>
>> No worries, thanks for the advice. I might move this to one side and
>> start another module tomorrow and come back to it.
>
> Ok. Let me know if you need help (but I'll be offline for a few hours from now).
>
> Cheers,
> Antonio
>
>
Re: Security clearance and regressions prevention for changed
dependencies [WAS: Re: [MODULE REVIEW] - o.eclipse.jgit - Questions]
Posted by Emilian Bold <em...@gmail.com>.
Great! Something like this would be good to know for every JAR where
the Maven hash is different.
--emi
On Wed, Oct 11, 2017 at 12:11 PM, John McDonnell
<mc...@gmail.com> wrote:
> Hi,
>
> I took a look using a tool called DeltaWalker and the only differences
> between the 2 are:
> The new version contains 2 additional files META-INF/ECLIPSE_.SF and
> META-INF/ECLIPSE_.RSA and the file META-INF/MANIFEST.MF has SHA-1
> signatures for each class found in the JAR.
>
> The class files themselves are the same between both jars.
>
> Regards
>
> John
>
>
>
>
> On 11 October 2017 at 08:47, Emilian Bold <em...@gmail.com> wrote:
>> Hello,
>>
>> It seems important to me to double-check binary dependencies where only the Maven hash changes, especially for code that's support to talk to remote servers.
>>
>> So an actual diff between JAR should be reviewed and posted.
>>
>> For this particular git JAR were only some META-INF signatures added or do .class files differ?
>>
>> --emi
>>
>> Pe 11 oct. 2017, la 08:35, Antonio <an...@vieiro.net> a scris:
>>
>>>
>>>
>>> On 11/10/17 00:59, John McDonnell wrote:
>>>>>> 2.
>>>>>>
>>>>>> There's 1 external dependency here:
>>>>>> B580E446B543A8DD2F5AA368B07F9C4C9C2E7029
>>>>>> org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar
>>>>>>
>>>>>> I'm not sure about the nosignature part, but I can find[1] this
>>>>>> version which I guess is the same one, but when I change the
>>>>>> binaries-list file to use
>>>>>> B580E446B543A8DD2F5AA368B07F9C4C9C2E7029
>>>>>> org.eclipse.jgit:org.eclipse.jgit:3.6.2.201501210735-r
>>>>>>
>>>>>> I got an error as the hash was wrong and had to change it to be:
>>>>>> 47D59DFFB5F02470CCFB6C1A5A31B6040A1636E5
>>>>>> org.eclipse.jgit:org.eclipse.jgit:3.6.2.201501210735-r
>>>>>>
>>>>>> Should I be viewing this as a potential question mark, or is it okay?
>>>>>
>>>>>
>>>>> Enter the SHA-1 Checksum at the bottom of this page:
>>>>>
>>>>> http://search.maven.org/#advancedsearch
>>>>>
>>>>> And doublecheck that the version (name, etc.) is correct.
>>>> Nope, that hash didn't return anything from that search tool.
>>>
>>> This is confusing, I know, so please let me try to explain myself again.
>>>
>>> It's normal that the original SHA1 sum (B580E446B54... ) is NOT in maven central. This is so because ages ago the original jar binary file was uploaded to the NetBeans repository by the NSA/KGB/CIA guys :-D.
>>>
>>> The idea is to look up the jar again in maven central and fetch a proper binary hash sum. The error suggests (47D59DF...).
>>>
>>> What I meant when I said "doublecheck that the version is correct" is that we should now check this new checksum in the http://search.maven.org/#advancedsearch page. If we do so we get [1], which looks correct (same artifact name, same version) for this binary.
>>>
>>> So now we can get rid of that NSA/KGB binary that was once placed there in the NetBeans repository (with that B580E... checksum), and replace it with one from Maven central (with that 47D59DF... checksum). This is safer, because NSA/KGB have new hacking techniques and do deliver now new official binaries from maven central. :-D
>>>
>>> So, to summarize, we once had this line in the binaries-list file:
>>>
>>> B580E446B543A8DD2F5AA368B07F9C4C9C2E7029 org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar
>>>
>>> With a SHA-1 sum that is NOT in maven central, and we now have to replace it with
>>>
>>> 47D59DFFB5F02470CCFB6C1A5A31B6040A1636E5 org.eclipse.jgit:org.eclipse.jgit:3.6.2.201501210735-r
>>>
>>> With corresponds to the official maven binary, with the latest NSA/KGB patches applied.
>>>
>>>
>>> [1] http://search.maven.org/#search%7Cga%7C1%7C1%3A%2247D59DFFB5F02470CCFB6C1A5A31B6040A1636E5%22
>>>
>>>>> If the name of the jar file is different from the original entry you'll have
>>>>> to update nbproject/project.xml and nbproject/project.properties. In your
>>>>> case the original file had a '_nosignature' thing there, which is missing in
>>>>> the file downloaded from central.
>>>
>>> The original binary was named
>>>
>>> org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar
>>>
>>> And the one from maven central is named differently:
>>>
>>> org.eclipse.jgit-3.6.2.201501210735-r.jar
>>>
>>> So we'll have to modify nbproject/project.properties and nbproject/project.xml to reflect this name change.
>>>
>>> In project.properties we see
>>>
>>> release.external/org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar=modules/org-eclipse-jgit.jar
>>>
>>> That should be changed to
>>>
>>> release.external/org.eclipse.jgit-3.6.2.201501210735-r.jar=modules/org-eclipse-jgit.jar
>>>
>>> (removing the _nosignature stuff)
>>>
>>> and in project.xml
>>>
>>> <class-path-extension>
>>> <runtime-relative-path>org-eclipse-jgit.jar</runtime-relative-path>
>>> <binary-origin>external/org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar</binary-origin>
>>> </class-path-extension>
>>>
>>> should now look like:
>>>
>>>
>>> <class-path-extension>
>>> <runtime-relative-path>org-eclipse-jgit.jar</runtime-relative-path>
>>> <binary-origin>external/org.eclipse.jgit-3.6.2.201501210735-r.jar</binary-origin>
>>> </class-path-extension>
>>>
>>> (removing the _nosignature suffix)
>>>
>>> To verify that these changes are correct just run "ant test" in the module directory.
>>>
>>>
>>> [2] http://repo1.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/3.6.2.201501210735-r/
>>>
>>>
>>>> No worries, thanks for the advice. I might move this to one side and
>>>> start another module tomorrow and come back to it.
>>>
>>> Ok. Let me know if you need help (but I'll be offline for a few hours from now).
>>>
>>> Cheers,
>>> Antonio
>>>
>>>
>
>
>
> --
> John
Re: Security clearance and regressions prevention for changed
dependencies [WAS: Re: [MODULE REVIEW] - o.eclipse.jgit - Questions]
Posted by John McDonnell <mc...@gmail.com>.
Hi,
I took a look using a tool called DeltaWalker and the only differences
between the 2 are:
The new version contains 2 additional files META-INF/ECLIPSE_.SF and
META-INF/ECLIPSE_.RSA and the file META-INF/MANIFEST.MF has SHA-1
signatures for each class found in the JAR.
The class files themselves are the same between both jars.
Regards
John
On 11 October 2017 at 08:47, Emilian Bold <em...@gmail.com> wrote:
> Hello,
>
> It seems important to me to double-check binary dependencies where only the Maven hash changes, especially for code that's support to talk to remote servers.
>
> So an actual diff between JAR should be reviewed and posted.
>
> For this particular git JAR were only some META-INF signatures added or do .class files differ?
>
> --emi
>
> Pe 11 oct. 2017, la 08:35, Antonio <an...@vieiro.net> a scris:
>
>>
>>
>> On 11/10/17 00:59, John McDonnell wrote:
>>>>> 2.
>>>>>
>>>>> There's 1 external dependency here:
>>>>> B580E446B543A8DD2F5AA368B07F9C4C9C2E7029
>>>>> org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar
>>>>>
>>>>> I'm not sure about the nosignature part, but I can find[1] this
>>>>> version which I guess is the same one, but when I change the
>>>>> binaries-list file to use
>>>>> B580E446B543A8DD2F5AA368B07F9C4C9C2E7029
>>>>> org.eclipse.jgit:org.eclipse.jgit:3.6.2.201501210735-r
>>>>>
>>>>> I got an error as the hash was wrong and had to change it to be:
>>>>> 47D59DFFB5F02470CCFB6C1A5A31B6040A1636E5
>>>>> org.eclipse.jgit:org.eclipse.jgit:3.6.2.201501210735-r
>>>>>
>>>>> Should I be viewing this as a potential question mark, or is it okay?
>>>>
>>>>
>>>> Enter the SHA-1 Checksum at the bottom of this page:
>>>>
>>>> http://search.maven.org/#advancedsearch
>>>>
>>>> And doublecheck that the version (name, etc.) is correct.
>>> Nope, that hash didn't return anything from that search tool.
>>
>> This is confusing, I know, so please let me try to explain myself again.
>>
>> It's normal that the original SHA1 sum (B580E446B54... ) is NOT in maven central. This is so because ages ago the original jar binary file was uploaded to the NetBeans repository by the NSA/KGB/CIA guys :-D.
>>
>> The idea is to look up the jar again in maven central and fetch a proper binary hash sum. The error suggests (47D59DF...).
>>
>> What I meant when I said "doublecheck that the version is correct" is that we should now check this new checksum in the http://search.maven.org/#advancedsearch page. If we do so we get [1], which looks correct (same artifact name, same version) for this binary.
>>
>> So now we can get rid of that NSA/KGB binary that was once placed there in the NetBeans repository (with that B580E... checksum), and replace it with one from Maven central (with that 47D59DF... checksum). This is safer, because NSA/KGB have new hacking techniques and do deliver now new official binaries from maven central. :-D
>>
>> So, to summarize, we once had this line in the binaries-list file:
>>
>> B580E446B543A8DD2F5AA368B07F9C4C9C2E7029 org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar
>>
>> With a SHA-1 sum that is NOT in maven central, and we now have to replace it with
>>
>> 47D59DFFB5F02470CCFB6C1A5A31B6040A1636E5 org.eclipse.jgit:org.eclipse.jgit:3.6.2.201501210735-r
>>
>> With corresponds to the official maven binary, with the latest NSA/KGB patches applied.
>>
>>
>> [1] http://search.maven.org/#search%7Cga%7C1%7C1%3A%2247D59DFFB5F02470CCFB6C1A5A31B6040A1636E5%22
>>
>>>> If the name of the jar file is different from the original entry you'll have
>>>> to update nbproject/project.xml and nbproject/project.properties. In your
>>>> case the original file had a '_nosignature' thing there, which is missing in
>>>> the file downloaded from central.
>>
>> The original binary was named
>>
>> org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar
>>
>> And the one from maven central is named differently:
>>
>> org.eclipse.jgit-3.6.2.201501210735-r.jar
>>
>> So we'll have to modify nbproject/project.properties and nbproject/project.xml to reflect this name change.
>>
>> In project.properties we see
>>
>> release.external/org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar=modules/org-eclipse-jgit.jar
>>
>> That should be changed to
>>
>> release.external/org.eclipse.jgit-3.6.2.201501210735-r.jar=modules/org-eclipse-jgit.jar
>>
>> (removing the _nosignature stuff)
>>
>> and in project.xml
>>
>> <class-path-extension>
>> <runtime-relative-path>org-eclipse-jgit.jar</runtime-relative-path>
>> <binary-origin>external/org.eclipse.jgit-3.6.2.201501210735-r_nosignature.jar</binary-origin>
>> </class-path-extension>
>>
>> should now look like:
>>
>>
>> <class-path-extension>
>> <runtime-relative-path>org-eclipse-jgit.jar</runtime-relative-path>
>> <binary-origin>external/org.eclipse.jgit-3.6.2.201501210735-r.jar</binary-origin>
>> </class-path-extension>
>>
>> (removing the _nosignature suffix)
>>
>> To verify that these changes are correct just run "ant test" in the module directory.
>>
>>
>> [2] http://repo1.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/3.6.2.201501210735-r/
>>
>>
>>> No worries, thanks for the advice. I might move this to one side and
>>> start another module tomorrow and come back to it.
>>
>> Ok. Let me know if you need help (but I'll be offline for a few hours from now).
>>
>> Cheers,
>> Antonio
>>
>>
--
John