securitygit-annexhttp://git-annex.branchable.com/security/git-annexikiwiki2020-06-17T01:18:32Zcomment 1http://git-annex.branchable.com/security/comment_1_285da453a385bd4bd225e26377a47cd5/Ilya S2018-09-07T21:08:24Z2018-09-07T21:08:24Z
<p>It would be good if annex.security.allowed-http-addresses could add an exception not just for any 'localhost' access, but only for URLs matching a given regexp, e.g. only for
http://localhost:808?/dnanexus/file-[a-f0-9]+</p>
comment 2http://git-annex.branchable.com/security/comment_2_261b1904e41f4566490b977010ce8734/joey2018-09-11T16:49:51Z2018-09-11T16:39:14Z
<p>@Ilya, it seems to me you could just configure your localhost webserver to
listen on one of the other localnet addresses (eg 127.0.0.2), and
only serve up the "safe" files on that address.
Then whitelist that address in git-annex.</p>
<p>That seems better than adding user-configured regexps to a security path.
(Worth noting that the example regexp you gave also matches port 808, probably
by accident! Regexps and security are often not the best combination.)</p>
<p>Also, I don't think it would be possible to implement anything that looks
at the whole url in the restricted Http Manager, since the http-client
library's interface does not provide the path being requested to the hook
that is built on.</p>
Another use case -- http_proxyhttp://git-annex.branchable.com/security/comment_3_0cc44e032fc94f4d374fb297ca9a8f2d/yarikoptic2020-06-17T01:18:32Z2019-11-12T17:51:25Z
<p>On some institutional servers they mandate for all http traffic to go through proxy. In our case <code>http_proxy</code> looked like <code>http://ptn07-e0:3128</code>.
<code>datalad install</code> worked out but an attempt to <code>datalad get</code> a bunch of files resulted in massive list of errors, and <code>annex-ignore</code> being set for "origin" which is otherwise available.
We managed to fish out that warning about security schemes and http_proxy being ignored for that reason in one of the subsequent attempts (after unsetting annex-ignore).
Upon attempts to set that variable we realized that we had to provide IP instead of <code>http_proxy</code> full value or just a name (<code>ptn07-e0</code>), netmasked address (e.g. 10.0.0.1/24) also didn't work. That makes it really inflexible. Actual IP could change, without http_proxy being changed. Even the value of http_proxy could change system wide. It would be painful to require our users to adjust for that every time, and it is infeasible to demand sysadmins to somehow tune up their configuration across HPC (we have no direct connection to them). If we could at least whitelist private network -- that would provide some remedy. Regular expression, though indeed not a really security-friendly solution, could have also provided remedy.
Have we missed some already existing way to make our lives easy on that system?</p>
comment 4http://git-annex.branchable.com/security/comment_4_3822244fb9becc32385d57233fa036a4/joey2020-06-17T01:18:32Z2020-02-20T20:29:20Z
<p>If you have a problem with some change that was made to fix a security
hole, about the only thing you can do is file a bug report. With some
really well thought out way to improve it ideally. I'm certianly not going
to revert security hole fixes because some comment here complains about
them.</p>
comment 5http://git-annex.branchable.com/security/comment_5_616b08553430a64beab196571c5b9cdc/yarikoptic2020-06-17T01:18:32Z2020-02-21T00:07:53Z
<a href="https://git-annex.branchable.com/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/">done</a>