Le vendredi 06 septembre 2019 à 08:15 -0400, Paul Frields a écrit :
On Fri, Sep 6, 2019 at 7:58 AM Michael Scherer
<mscherer(a)redhat.com>
wrote:
> Le jeudi 05 septembre 2019 à 08:09 -0400, Paul Frields a écrit :
> > Off the top of my head...
> >
> > On Thu, Sep 5, 2019 at 7:43 AM Michael Scherer <
> > mscherer(a)redhat.com>
> > wrote:
> > >
> > - how up to date do we want it to be regarding posts, etc ?
> > > (I think we can't do a regular automated sync easily, so if
> > > that's
> > > needed, I will have to find some way to automate that)
> > >
> >
> > Doesn't need to be sync'd all the time. If the current content is
> > needed we
> > can always ask.
> >
> >
> > > - do we want to have it plugged to the prod instance of FAS or
> > > the
> > > staging one ?
> > > (for now, that's the staging one)
> >
> >
> > Staging seems right to me.
>
> Ok, we need to keep that in mind if we sync again, this will be
> erased/forgotten.
>
> I will take care of that next week.
>
Is there any risk to FAS if someone gains access to the staging
server? My
bet is not (only exposes an ability to federate ID) but if so, that
would
be one less thing to worry about. We could use production in that
case.
That is a good point, I would say "no" for openid, but I didn't look in
details. I can't even find the git repo for the automated login plugin
(who just insert a js script for that), so I will likely have to do
touch to the code myself.
Worst possible attack I can think of would be if a cunning attacker
simply replace the remote server in that plugin code, redirecting
people for phising credentials on a fake FAS server. I do assume that
most people wouldn't check the URL or anything.
But this is quite convoluted, nor something we can fix on wp side.
--
Michael Scherer / He/Il/Er/Él
Sysadmin, Community Infrastructure