Thank you @cel for clarifying.
I have long been wondering: wouldn't it be possible (if a little crude) to locate all git-ssb indexes in
~/.cache/git-ssb-index? Or, if running the entire git-ssb suite, in
* with other clients
Daan, just drink your damn coffee before posting immutable messages, will ya? :D
Just to clarify: why can't we include this index into git-ssb-web by default? I'd argue this actually is a block to make git-ssb-web feature complete, not a convenience addon. Scanning a 1GB offset log for git messages takes quite some time...
So indeed the option was explicitly set by me. However, not being a security person I probably copied it from some article on "how to secure nginx".
Here's what the mozilla docs say about that header:
This header was introduced by Microsoft in IE 8 as a way for webmasters to block content sniffing that was happening and could transform non-executable MIME types into executable MIME types. [...] Site security testers usually expect this header to be set.
So a config change will do, but it might be worth thinking about this since the prospect of inadvertently hosting malicious files like that makes my tummy hurt. :|
Very likely not necessary, and totally an artifact of me not being a webadmin.
Great, then it's just a matter of config. I'll figure it out and maybe drop a line into the readme. :)
This happens for any image attachment on my viewer instance at least. Example: https://ssb.muchmuch.coffee/%25U13iMbNEjhdpAoNb2vwpD4iLBj0YiTfR2oZzq2awlKw%3D.sha256
Browser-wise this happens on any Firefox version I tried (including nightly) and also on chromium.
However, I just realized there's an easy check whether this is a config issue on my viewer, and indeed this link works fine with Firefox and chromium: https://viewer.scuttlebot.io/&5G+cePXuwiBGFgm9ufEHbH7QhS8/8h5WhyDrt89RfZ0=.sha256
However, I don't see any content-type headers being returned in either case, so I don't get why the browsers correctly interpret one set of bytes but not the other...
Built with git-ssb-web