[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bits.d.o as an onion service

On Sun, Aug 28, 2016 at 07:13:01PM +0200, Ana Guerrero Lopez wrote:
> The absolute path hardcoding was due to a problem with the RSS feed IIRC at
> the time of creating the blog (I don't remember very well the details
> anymore).

I think that still "exists" if you are just changing to relative URIs,
which is why I modified (or actually replaced) FEED_DOMAIN, too, as that
seems to result in relative URIs to the feeds, while the URIs in the
feed are absolute as it should be… but as said, never used pelican
before, so its a bunch of very wild guesses and not something I would
feel comfortable committing on my own…

> The hardcode path was left with the idea of fixing it after launching
> the blog and got forgotten. I can imagine how bad it looks when browsing
> the onion service, I'm looking at it now.

The thing is that for a "normal" Tor user (with the default Tor browser)
it looks normal as by default content from third-party domains is loaded
just fine. It is just "pointless" to use the onion service if close to
the only thing I can hide with it compared to just using https is that
I browse bits.d.o – which is still communicated in the clear via the
load of CSS/images from that domain.

Of course "I have nothing to hide" and especially not visiting bits.d.o,
I just have a bunch of https-everywhere rules which redirect me to known
.onion services just because I know they exist and someone ought to try…
Also, I am playing with another extension (uMatrix) which can be
configured to [and I did] block all types of third-party content.
In other words: I am asking the internet to look and behave poorly by
default and many websites are very eager to comply for various more or
less legit reasons.

So, all in all I wouldn't be entirely surprised if the upper bound of
visually effected users is 1 – which was the deeper reason for me to try
to come up at least with something roughly looking like a patch…

(actually, in an "ideal world", the https-everywhere rules would apply
before uMatrix's do, but that isn't possible so far – on the upside
I can at least see and report such unneeded leaks then).

And for the record: Debian websites are among those which tend to work
even in my crazy setup, so that the occasional 'bad apple' actually
stands out… aka: thanks for trying to support me! :)

Best regards

David Kalnischkies
diff --git a/pelicanconf.py b/pelicanconf.py
index 902dc4d..82a9834 100644
--- a/pelicanconf.py
+++ b/pelicanconf.py
@@ -18,14 +18,13 @@ LOCALE='C'
 # URL settings
 # We might want this for publication
 ARTICLE_URL = '{date:%Y}/{date:%m}/{slug}.html'
 ARTICLE_SAVE_AS = '{date:%Y}/{date:%m}/{slug}.html'
 ARTICLE_LANG_URL = '{date:%Y}/{date:%m}/{slug}-{lang}.html'
 ARTICLE_LANG_SAVE_AS = '{date:%Y}/{date:%m}/{slug}-{lang}.html'
 # Feeds settings
 FEED_ATOM = 'feeds/atom.xml'
 FEED_RSS = 'feeds/feed.rss'
@@ -43,7 +42,7 @@ CATEGORIES_SAVE_AS = None
-MENUITEMS =  (('Home', 'https://bits.debian.org'),)
+MENUITEMS =  (('Home', '/'),)
 SOCIAL = (('identi.ca/debian', 'https://identi.ca/debian'),
           ('Debian Project News', 'https://www.debian.org/News/'),
diff --git a/theme-bits/templates/base.html b/theme-bits/templates/base.html
index 362a804..62369fa 100644
--- a/theme-bits/templates/base.html
+++ b/theme-bits/templates/base.html
@@ -43,9 +43,9 @@
                 {% endif %}
                 <li><a href="{{ SITEURL }}/archives.html">Archives</a>
-                <li><a href="{{ FEED_DOMAIN }}/{{ FEED_ATOM }}" rel="alternate">Atom feed</a></li>
+                <li><a href="{{ SITEURL }}/{{ FEED_ATOM }}" rel="alternate">Atom feed</a></li>
                 {% if FEED_RSS %}
-                <li><a href="{{ FEED_DOMAIN }}/{{ FEED_RSS }}" rel="alternate">RSS feed</a></li>
+                <li><a href="{{ SITEURL }}/{{ FEED_RSS }}" rel="alternate">RSS feed</a></li>
                 {% endif %}

Attachment: signature.asc
Description: PGP signature

Reply to: