Unless there is some use case I'm missing, unit tests would be the only place a newly written file hash would need to match a precalculated value, meaning c) should be fine by me. I don't think anyone should expect POI to read a file and have the saved result be binarily equal to the input. The only guarantee should be semantic equivalence.
On Tue, Jul 25, 2017, 03:53 <[email protected]> wrote: > https://bz.apache.org/bugzilla/show_bug.cgi?id=61182 > > --- Comment #6 from Andreas Beeker <[email protected]> --- > The windows/linux files differ in their line-endings, due to > org.apache.xmlbeans.impl.store.Saver._newLine being system dependent. > > As the xml canonicalization handles the newlines as-is, this leads to > different > hashes. > > Currently I think about 3 options: > a) change the _newLine static final via reflection > b) normalize the xmls to unix linebreaks on signing > c) add a switch in the junit test to check for windows/mac/linux hashes > > As the files signed by a linux system worked in Libre/MS Office, I probably > just go with c) > > -- > You are receiving this mail because: > You are the assignee for the bug. > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
