While both Gitea and Drone rely in part on js, it is still possible that some users would prefer to connect to us using tor (possibly with js whitelisted here).
I propose we make our core services available as onion services, too.
While both Gitea and Drone rely in part on `js`, it is still possible that some users would prefer to connect to us using tor (possibly with `js` whitelisted here).
I propose we make our core services available as onion services, too.
current progress
- [x] homepage
- [x] gitea
- [ ] drone - set up but not properly working (see #5)
- [x] statuspage
- [x] prometheus (dotya.ml/homepage!23)
- [x] grafana
edit:
after this is concluded, we could apply to add the services to the WeSupportTor list https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor
edit: note that ssh is also enabled for gitea via tor
as also mentioned in [39a5ba03c8](https://git.dotya.ml/dotya.ml/homepage/commit/39a5ba03c8) and thanks to @kreyren ๐ we now have both the homepage and gitea available as onion services.
homepage: http://6426tqrh4y5uobmo5y2csaip3m3avmjegd2kpa24sadekpxglbm34aqd.onion
gitea: http://2crftbzxbcoqolvzreaaeyrod5qwycayef55gxgzgfcpqlaxrnh3kkqd.onion
prometheus: http://vognfwm7c6wq2gxqcmswi2flwckuxryefd7n3axxkvlpasdjhns5buqd.onion
grafana: http://6t3ydf7sl7iso2wbymbfjtaq6qqlrms37ffik2siulsljc3ubobklnid.onion
statuspage: http://o4irro4dspyuytbw2b2g2ac4ukkh2ex53oolhzw7hrfjmq6tiklrtwqd.onion/
more on this, including what's up with *hidden* drone:
https://dotya.ml/about/#onion-services
http://6426tqrh4y5uobmo5y2csaip3m3avmjegd2kpa24sadekpxglbm34aqd.onion/about/#onion-services
edit: note that ssh is also enabled for gitea via tor
What is the status on this in terms of gitea handling? Seems that gitea needs adaptation to replace the domain with onions when accessed from onions -> Create tracking of what is needed in upstream willing to consider contribs
What is the status on this in terms of gitea handling? Seems that gitea needs adaptation to replace the domain with onions when accessed from onions -> Create tracking of what is needed in upstream willing to consider contribs
What is the status on this in terms of gitea handling? Seems that gitea needs adaptation to replace the domain with onions when accessed from onions -> Create tracking of what is needed in upstream willing to consider contribs
As you say, the only thing that prevents you from functioning easily on Gitea via tor is Gitea using absolute link paths at certain places - using relative (as in /user/whateverrepo/commits/...) links would solve this. Also, a parameter DOMAIN is set in app.ini config, which would need to either be handled differently or something..this gets used in the displayed cloning URL etc. These I can think of off the top of my head atm, there are probably more (e.g. zeripath - one of the Gitea maintainers - mentioned email links)
@kreyren
>What is the status on this in terms of gitea handling? Seems that gitea needs adaptation to replace the domain with onions when accessed from onions -> Create tracking of what is needed in upstream willing to consider contribs
As you say, the only thing that prevents you from functioning easily on Gitea via tor is Gitea using absolute link paths at certain places - using relative (as in `/user/whateverrepo/commits/...`) links would solve this. Also, a parameter DOMAIN is set in app.ini config, which would need to either be handled differently or something..this gets used in the displayed cloning URL etc. These I can think of off the top of my head atm, there are probably more (e.g. zeripath - one of the Gitea maintainers - mentioned email links)
While both Gitea and Drone rely in part on
js
, it is still possible that some users would prefer to connect to us using tor (possibly withjs
whitelisted here).I propose we make our core services available as onion services, too.
current progress
edit:
after this is concluded, we could apply to add the services to the WeSupportTor list https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor
as also mentioned in 39a5ba03c8 and thanks to @kreyren ๐ we now have both the homepage and gitea available as onion services.
homepage: http://6426tqrh4y5uobmo5y2csaip3m3avmjegd2kpa24sadekpxglbm34aqd.onion
gitea: http://2crftbzxbcoqolvzreaaeyrod5qwycayef55gxgzgfcpqlaxrnh3kkqd.onion
prometheus: http://vognfwm7c6wq2gxqcmswi2flwckuxryefd7n3axxkvlpasdjhns5buqd.onion
grafana: http://6t3ydf7sl7iso2wbymbfjtaq6qqlrms37ffik2siulsljc3ubobklnid.onion
statuspage: http://o4irro4dspyuytbw2b2g2ac4ukkh2ex53oolhzw7hrfjmq6tiklrtwqd.onion/
more on this, including what's up with hidden drone:
https://dotya.ml/about/#onion-services
http://6426tqrh4y5uobmo5y2csaip3m3avmjegd2kpa24sadekpxglbm34aqd.onion/about/#onion-services
edit: note that ssh is also enabled for gitea via tor
What is the status on this in terms of gitea handling? Seems that gitea needs adaptation to replace the domain with onions when accessed from onions -> Create tracking of what is needed in upstream willing to consider contribs
@kreyren
As you say, the only thing that prevents you from functioning easily on Gitea via tor is Gitea using absolute link paths at certain places - using relative (as in
/user/whateverrepo/commits/...
) links would solve this. Also, a parameter DOMAIN is set in app.ini config, which would need to either be handled differently or something..this gets used in the displayed cloning URL etc. These I can think of off the top of my head atm, there are probably more (e.g. zeripath - one of the Gitea maintainers - mentioned email links)@wanderer So what's preventing you from submitting upstream tracking?