Hash files contain a relative path before the file name

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Hash files contain a relative path before the file name

Marcus (OOo)
With hash files of previous versions is was easily possible to check the
integrity of the download file with "sha256sum -c <file name>.sha256".

Now with 4.1.4 a relative path was added before the file name in the
hash files. Now it's a bit more complicated to get the same working. As
we are publishing the hash files for our users, it's also more difficult
for them to verify the install files.

Was there a change in the build scripts? If so, it would be great to
improve them to get the old behavior back.

Of course, no problem for the current vote.

Thanks for your help.

Marcus

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Matthias Seidel
For the Windows files I used Jims hash-script [1], but the path there is
a bit different because I created them separately in every single
sub-directory.

[1]
http://svn.apache.org/repos/asf/openoffice/devtools/release-scripts/hash-sign.sh

Matthias


Am 14.10.2017 um 15:39 schrieb Marcus:

> With hash files of previous versions is was easily possible to check
> the integrity of the download file with "sha256sum -c <file
> name>.sha256".
>
> Now with 4.1.4 a relative path was added before the file name in the
> hash files. Now it's a bit more complicated to get the same working.
> As we are publishing the hash files for our users, it's also more
> difficult for them to verify the install files.
>
> Was there a change in the build scripts? If so, it would be great to
> improve them to get the old behavior back.
>
> Of course, no problem for the current vote.
>
> Thanks for your help.
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Matthias Seidel
In reply to this post by Marcus (OOo)
Am 14.10.2017 um 15:39 schrieb Marcus:

> With hash files of previous versions is was easily possible to check
> the integrity of the download file with "sha256sum -c <file
> name>.sha256".
>
> Now with 4.1.4 a relative path was added before the file name in the
> hash files. Now it's a bit more complicated to get the same working.
> As we are publishing the hash files for our users, it's also more
> difficult for them to verify the install files.
>
> Was there a change in the build scripts? If so, it would be great to
> improve them to get the old behavior back.
While at it, we could also add support for SHA512. ;-)

https://bz.apache.org/ooo/show_bug.cgi?id=127530

Matthias

>
> Of course, no problem for the current vote.
>
> Thanks for your help.
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Jim Jagielski

> On Oct 14, 2017, at 9:56 AM, Matthias Seidel <[hidden email]> wrote:
>
> Am 14.10.2017 um 15:39 schrieb Marcus:
>> With hash files of previous versions is was easily possible to check
>> the integrity of the download file with "sha256sum -c <file
>> name>.sha256".
>>
>> Now with 4.1.4 a relative path was added before the file name in the
>> hash files. Now it's a bit more complicated to get the same working.
>> As we are publishing the hash files for our users, it's also more
>> difficult for them to verify the install files.
>>
>> Was there a change in the build scripts? If so, it would be great to
>> improve them to get the old behavior back.
>
> While at it, we could also add support for SHA512. ;-)
>
> https://bz.apache.org/ooo/show_bug.cgi?id=127530

+1. I can adjust the script accordingly.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Marcus (OOo)
In reply to this post by Matthias Seidel
Am 14.10.2017 um 15:56 schrieb Matthias Seidel:

> Am 14.10.2017 um 15:39 schrieb Marcus:
>> With hash files of previous versions is was easily possible to check
>> the integrity of the download file with "sha256sum -c <file
>> name>.sha256".
>>
>> Now with 4.1.4 a relative path was added before the file name in the
>> hash files. Now it's a bit more complicated to get the same working.
>> As we are publishing the hash files for our users, it's also more
>> difficult for them to verify the install files.
>>
>> Was there a change in the build scripts? If so, it would be great to
>> improve them to get the old behavior back.
>
> While at it, we could also add support for SHA512. ;-)
>
> https://bz.apache.org/ooo/show_bug.cgi?id=127530

sure, adding this is necessary. But fixing the path problem should be
done, too.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Matthias Seidel
Am 14.10.2017 um 16:09 schrieb Marcus:

> Am 14.10.2017 um 15:56 schrieb Matthias Seidel:
>> Am 14.10.2017 um 15:39 schrieb Marcus:
>>> With hash files of previous versions is was easily possible to check
>>> the integrity of the download file with "sha256sum -c <file
>>> name>.sha256".
>>>
>>> Now with 4.1.4 a relative path was added before the file name in the
>>> hash files. Now it's a bit more complicated to get the same working.
>>> As we are publishing the hash files for our users, it's also more
>>> difficult for them to verify the install files.
>>>
>>> Was there a change in the build scripts? If so, it would be great to
>>> improve them to get the old behavior back.
>>
>> While at it, we could also add support for SHA512. ;-)
>>
>> https://bz.apache.org/ooo/show_bug.cgi?id=127530
>
> sure, adding this is necessary. But fixing the path problem should be
> done, too.
This was meant by "also" ;-)

Matthias

>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Andrea Pescetti-2
In reply to this post by Matthias Seidel
Matthias Seidel wrote:
> While at it, we could also add support for SHA512. ;-)
> https://bz.apache.org/ooo/show_bug.cgi?id=127530

Yes, but while at it we could also... just fix the SHA256 bug and be
happy with it.

Every time we add some other change "while at it", this has side effects
on the rest of the process. For example, this specific "enhancement"
will break the instructions for the tree preparation for the SF area and
will require changes to the download pages.

We can have SHA512 starting from the next version (I mean 4.2.0). There
is no reason to pollute the RC5 tree when the vote is ongoing.

Of course, improved SHA256 hash files should instead be uploaded to the
RC5 tree since they are expected and fully supported by current tools.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Matthias Seidel
Am 14.10.2017 um 16:40 schrieb Andrea Pescetti:

> Matthias Seidel wrote:
>> While at it, we could also add support for SHA512. ;-)
>> https://bz.apache.org/ooo/show_bug.cgi?id=127530
>
> Yes, but while at it we could also... just fix the SHA256 bug and be
> happy with it.
>
> Every time we add some other change "while at it", this has side
> effects on the rest of the process. For example, this specific
> "enhancement" will break the instructions for the tree preparation for
> the SF area and will require changes to the download pages.
>
> We can have SHA512 starting from the next version (I mean 4.2.0).
> There is no reason to pollute the RC5 tree when the vote is ongoing.
Don't get me wrong:
This is exacty what I meant and therefore the issue is for Target
Release 4.2.0

>
> Of course, improved SHA256 hash files should instead be uploaded to
> the RC5 tree since they are expected and fully supported by current
> tools.
>

I have absolutely no problem verifying the hashes with "gpg --verify
filemane.asc". How about others?
And why did nobody complain in RC1, RC2 and RC4?

Regards, Matthias

> Regards,
>   Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Marcus (OOo)
In reply to this post by Andrea Pescetti-2
Am 14.10.2017 um 16:40 schrieb Andrea Pescetti:

> Matthias Seidel wrote:
>> While at it, we could also add support for SHA512. ;-)
>> https://bz.apache.org/ooo/show_bug.cgi?id=127530
>
> Yes, but while at it we could also... just fix the SHA256 bug and be
> happy with it.
>
> Every time we add some other change "while at it", this has side effects
> on the rest of the process. For example, this specific "enhancement"
> will break the instructions for the tree preparation for the SF area and
> will require changes to the download pages.
>
> We can have SHA512 starting from the next version (I mean 4.2.0). There
> is no reason to pollute the RC5 tree when the vote is ongoing.

of course nobody wants anything new for 4.1.4. The first release we
integrate the improvements would be 4.2.0. ;-)

> Of course, improved SHA256 hash files should instead be uploaded to the
> RC5 tree since they are expected and fully supported by current tools.

This could be done but I don't expect updated files for 4.1.4.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Matthias Seidel
In reply to this post by Matthias Seidel
Am 14.10.2017 um 16:47 schrieb Matthias Seidel:
>
> I have absolutely no problem verifying the hashes with "gpg --verify
> filemane.asc". How about others?
> And why did nobody complain in RC1, RC2 and RC4?

Sorry, that was for verifying the signature... ;-)

Matthias

>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Matthias Seidel
In reply to this post by Marcus (OOo)
Am 14.10.2017 um 15:39 schrieb Marcus:
> With hash files of previous versions is was easily possible to check
> the integrity of the download file with "sha256sum -c <file
> name>.sha256".

For Windows files I get:

sha256sum -c Apache_OpenOffice_4.1.4_Win_x86_install_de.exe.sha256
./Apache_OpenOffice_4.1.4_Win_x86_install_de.exe: OK

But that is because I made them "by hand" for every single subdirectory.

I think Jim ran the script from a main directory recursing into all the
subdirectories...

Matthias

>
> Now with 4.1.4 a relative path was added before the file name in the
> hash files. Now it's a bit more complicated to get the same working.
> As we are publishing the hash files for our users, it's also more
> difficult for them to verify the install files.
>
> Was there a change in the build scripts? If so, it would be great to
> improve them to get the old behavior back.
>
> Of course, no problem for the current vote.
>
> Thanks for your help.
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Andrea Pescetti-2
In reply to this post by Matthias Seidel
Matthias Seidel wrote:
> Don't get me wrong:
> This is exacty what I meant and therefore the issue is for Target
> Release 4.2.0

OK! Then I simply got it wrong... we are on the same page, good.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Matthias Seidel
If we do want to correct the files, wouldn't it be the easiest way to
strip the relative paths and keep the hash?
I don't think we need completely new hash files...

The script itself can be updated for future use afterwards.

Matthias


Am 14.10.2017 um 18:09 schrieb Andrea Pescetti:

> Matthias Seidel wrote:
>> Don't get me wrong:
>> This is exacty what I meant and therefore the issue is for Target
>> Release 4.2.0
>
> OK! Then I simply got it wrong... we are on the same page, good.
>
> Regards,
>   Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Jim Jagielski
IMO, no need to redo the hash files. We can adjust the script
post-release to simply use basename, or whatever we want.

> On Oct 14, 2017, at 12:55 PM, Matthias Seidel <[hidden email]> wrote:
>
> If we do want to correct the files, wouldn't it be the easiest way to
> strip the relative paths and keep the hash?
> I don't think we need completely new hash files...
>
> The script itself can be updated for future use afterwards.
>
> Matthias
>
>
> Am 14.10.2017 um 18:09 schrieb Andrea Pescetti:
>> Matthias Seidel wrote:
>>> Don't get me wrong:
>>> This is exacty what I meant and therefore the issue is for Target
>>> Release 4.2.0
>>
>> OK! Then I simply got it wrong... we are on the same page, good.
>>
>> Regards,
>>   Andrea.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Andrea Pescetti-2
Jim Jagielski wrote:
> IMO, no need to redo the hash files. We can adjust the script
> post-release to simply use basename, or whatever we want.

It's really a cosmetic issue, without any effects on the ongoing vote,
but indeed the instructions we give to users assume that the .md5 and
.sha256 files are in the form

e0b12ff2a19c18c24db844767c56d27e
*Apache_OpenOffice_4.1.4_Linux_x86-64_install-rpm_it.tar.gz

and not (current version)

e0b12ff2a19c18c24db844767c56d27e
*./binaries/it/Apache_OpenOffice_4.1.4_Linux_x86-64_install-rpm_it.tar.gz

So no need to regenerate them at all, but a quick pass of sed over the
RC5 tree should rectify this and make it easier for users to test the
hashes.

I can take care of it if needed; but if someone else is going to do it,
even better!

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Jim Jagielski
All done.

> On Oct 14, 2017, at 1:42 PM, Andrea Pescetti <[hidden email]> wrote:
>
> Jim Jagielski wrote:
>> IMO, no need to redo the hash files. We can adjust the script
>> post-release to simply use basename, or whatever we want.
>
> It's really a cosmetic issue, without any effects on the ongoing vote, but indeed the instructions we give to users assume that the .md5 and .sha256 files are in the form
>
> e0b12ff2a19c18c24db844767c56d27e *Apache_OpenOffice_4.1.4_Linux_x86-64_install-rpm_it.tar.gz
>
> and not (current version)
>
> e0b12ff2a19c18c24db844767c56d27e *./binaries/it/Apache_OpenOffice_4.1.4_Linux_x86-64_install-rpm_it.tar.gz
>
> So no need to regenerate them at all, but a quick pass of sed over the RC5 tree should rectify this and make it easier for users to test the hashes.
>
> I can take care of it if needed; but if someone else is going to do it, even better!
>
> Regards,
>  Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hash files contain a relative path before the file name

Marcus (OOo)
Am 14.10.2017 um 22:39 schrieb Jim Jagielski:
> All done.

great, thanks for the updates.

Marcus



>> On Oct 14, 2017, at 1:42 PM, Andrea Pescetti <[hidden email]> wrote:
>>
>> Jim Jagielski wrote:
>>> IMO, no need to redo the hash files. We can adjust the script
>>> post-release to simply use basename, or whatever we want.
>>
>> It's really a cosmetic issue, without any effects on the ongoing vote, but indeed the instructions we give to users assume that the .md5 and .sha256 files are in the form
>>
>> e0b12ff2a19c18c24db844767c56d27e *Apache_OpenOffice_4.1.4_Linux_x86-64_install-rpm_it.tar.gz
>>
>> and not (current version)
>>
>> e0b12ff2a19c18c24db844767c56d27e *./binaries/it/Apache_OpenOffice_4.1.4_Linux_x86-64_install-rpm_it.tar.gz
>>
>> So no need to regenerate them at all, but a quick pass of sed over the RC5 tree should rectify this and make it easier for users to test the hashes.
>>
>> I can take care of it if needed; but if someone else is going to do it, even better!
>>
>> Regards,
>>   Andrea.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]