port:qt5 and (proposed) port:qt5-kde cohabitation

[Clemens Lang]

On Sun, Oct 23, 2016 at 08:00:25PM +0200, René J.V. Bertin wrote:
> I meant my local copy evidently which I'll most like keep in
> sources.conf and update from the new git working copy. If the svn
> history is migrated to github I'll be able to delete the .svn
> directory.

Sorry, I was assuming the things you sent to the list were relevant for
the subscribers. What you are doing locally on your machine is, of
course, your business.

> > The Referer header is used, see
> >   https://www.edgewall.org/docs/tags-trac-1.0/epydoc/trac.web.auth-pysrc.html#LoginModule._redirect_back
> 
> I'm surely not the only one using privoxy who might want to use trac.

Possibly. In any case it's a problem in Trac that should be solved
together with Trac upstream.

> Do you know if we can add trac.macports.org to a whitelist for the
> corresponding filter rule, or some other host?

I do not know how privoxy works. If this uses some global filter rules,
please get in touch with the maintainers of these filter rules yourself.
Otherwise, adding an exception for trac.macports.org should be
sufficient.

> > What makes you think this is running on GitHub?
> 
> The Github login. Of course I noticed that the site name didn't
> change, but that doesn't mean it isn't hosted on a github server
> nowadays. 

GitHub allows 3rd party applications to use their login service, which
is what we are doing. See https://developer.github.com/v3/oauth/. Our
servers do not serve the GitHub login page, and we never see your GitHub
password.

In a nutshell, we redirect a user to a special URL at GitHub and pass an
application ID and a nonce. That user logs in to GitHub and GitHub sends
them back to our webserver with a HMAC using a previously shared key
matching the application ID so we know the login was successful. It's a
little more complicated than that, but the OAuth standard should answer
all your remaining questions.

-- 
Clemens