Just to close the loop on this, infra have updated the dist.apache.org config to have the files present as text/plain, as they do on www.apache.org, which lets them work in firefox without us needing to play with the svn mime types.
On 10 March 2017 at 17:16, Robbie Gemmell <[email protected]> wrote: > I decided to set the svn:mime-type to text/plain for the > qpid-jms-0.21.0 release files I just added. It turns out that is what > gets used on the main www.apache.org webserver once they are > eventually released, and the issue only applies on the dist.apache.org > webserver fronting the svn dist repo. > > Robbie > > On 10 March 2017 at 12:22, Robbie Gemmell <[email protected]> wrote: >> As noted in the vote thread, the webserver presenting the svn dist >> repo is seemingly mishhandling the .sha files and this leads to >> Firefox saving a gzip encoded version of the checksum. This is raised >> as https://issues.apache.org/jira/browse/INFRA-13629 >> >> Hopefully it can be fixed webserver side, but in the mean time setting >> a mime type on the file in the svn repo makes the webserver pick it up >> and act differently, and this gets things working in Firefox. I used >> the following for the proton-j 0.18.0 release checksums: >> svn propset svn:mime-type application/x-sha2 *.sha >> >> If needed, we can use some svn client config to do that automatically >> in future. If folks use a recent enough svn client it can actually be >> propset in the repo and clients will pick it up and action it. >> >> On 7 March 2017 at 23:24, Robbie Gemmell <[email protected]> wrote: >>> Thats probably where the key difference lies - I dont have the general >>> shasum, only specific sha[1|224|256|384|512]sum variants that do >>> complain when given the 'wrong' thing. I'm long overdue an update to >>> an up to date OS so that probably explains that. It makes sense they >>> should be able to look at whats there and attempt to verify as seems >>> appropriate. >>> >>> My suggestion to change wasnt really to say that there is an implied >>> particular choice for .sha, just that given we are changing things we >>> should make them consistent the distribution policy and each other >>> while doing so. >>> >>> On 7 March 2017 at 23:04, Justin Ross <[email protected]> wrote: >>>> I will change the qpid-python .sha file to SHA-512. And I wouldn't have >>>> objected to using .sha512 if Robbie had felt like going against the grain. >>>> >>>> FWIW, before I made the change to SHA-256 and .sha, I tested that Fedora's >>>> 'shasum' does not require extra options to check such files. It seems to >>>> figure it out on its own. In some cursory poking around, I haven't found >>>> anything that says .sha indicates any particular SHA hash function. >>>> >>>> On Tue, Mar 7, 2017 at 10:19 AM, Robbie Gemmell <[email protected]> >>>> wrote: >>>> >>>>> ;) >>>>> >>>>> I decided to go with the guideline and created a SHA512 file with .sha >>>>> extension. We can make it clear on the website that its SHA512. Folks >>>>> doing it blind will just have to try it, or look at the content to >>>>> figure it out. >>>>> >>>>> Given the name is 'correct', I'd probably regenerate the qpid-python >>>>> checksum using SHA512. We could also just leave it alone this time >>>>> since it only says you SHOULD use SHA512. >>>>> >>>>> On 7 March 2017 at 18:05, Rob Godfrey <[email protected]> wrote: >>>>> > To be fair that page says nothing about how to name SHA256 checksums >>>>> > :-), >>>>> > only that we SHOULD be creating SHA512 checksums named .sha. >>>>> > >>>>> > So, I'm +1 on naming the SHA256 .sha256 ... and it seems like the Python >>>>> > release really shouldn't name a SHA256 file .sha as by the above that >>>>> > extension should be reserved for SHA512. >>>>> > >>>>> > -- Rob >>>>> > >>>>> > On 7 March 2017 at 18:34, Timothy Bish <[email protected]> wrote: >>>>> > >>>>> >> On 03/07/2017 12:23 PM, Robbie Gemmell wrote: >>>>> >> >>>>> >>> According to http://www.apache.org/dev/release-distribution.html#sigs- >>>>> >>> and-sums >>>>> >>> .sha is actually required: >>>>> >>> >>>>> >>> "An SHA checksum SHOULD also be created and MUST be suffixed .sha. The >>>>> >>> checksum SHOULD be generated using SHA512." >>>>> >>> >>>>> >>> I find the extension a little unhelpful personally, but ok.. :) >>>>> >>> >>>>> >> >>>>> >> I would have voted for .sha256 for clarity >>>>> >> >>>>> >> >>>>> >>> Robbie >>>>> >>> >>>>> >>> On 7 March 2017 at 17:11, Robbie Gemmell <[email protected]> >>>>> >>> wrote: >>>>> >>> >>>>> >>>> Hi folks, >>>>> >>>> >>>>> >>>> I noted in the qpid-python-1.36.0 vote thread that the .sha file >>>>> >>>> contained a sha256 checksum, this being in place of the historic >>>>> >>>> .sha1 >>>>> >>>> checksum file. >>>>> >>>> >>>>> >>>> I'm curious what people think about the name relative to the >>>>> >>>> contents? >>>>> >>>> I think .sha256 might be friendlier so that people know how to try >>>>> >>>> and >>>>> >>>> verify it implicitly from its name? >>>>> >>>> >>>>> >>>> I mainly ask as I think I'll include one for the proton-j-0.18.0 >>>>> >>>> release im about to cut, and am trying to settle on a name for it. >>>>> >>>> >>>>> >>>> Robbie >>>>> >>>> >>>>> >>> --------------------------------------------------------------------- >>>>> >>> To unsubscribe, e-mail: [email protected] >>>>> >>> For additional commands, e-mail: [email protected] >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >> >>>>> >> -- >>>>> >> Tim Bish >>>>> >> twitter: @tabish121 >>>>> >> blog: http://timbish.blogspot.com/ >>>>> >> >>>>> >> >>>>> >> >>>>> >> --------------------------------------------------------------------- >>>>> >> To unsubscribe, e-mail: [email protected] >>>>> >> For additional commands, e-mail: [email protected] >>>>> >> >>>>> >> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
