[aur-general] Securing the AUR website

[Estêvão]

2011/8/5 Lukas Fleischer <archlinux at cryptocrack.de>

> On Sat, Aug 06, 2011 at 12:09:34AM +0200, Pierre Schmitz wrote:
> > On Fri, 5 Aug 2011 23:54:57 +0200, Lukas Fleischer wrote:
> > > We won't do that. HTTPs will be the default but we won't force users to
> > > use HTTPs. If you decide to use HTTP intentionally, we won't prevent
> you
> > > from doing so. HTTPs implies an unnecessary overhead and there's no
> > > point in forcing everybody to use HTTPs even if one doesn't even have
> an
> > > AUR account.
> >
> > Seriously the overhead is negligible, on client as on sever side. Even
> > for those who don't have an AUR account, https would prevent anybody
> > else injecting code. But those wont matter anyway because securing those
> > who have an account should be priority. At least ensure that cookies are
> > never sent unencrypted.
>
> Yeah, that is no reason for disabling plain HTTP, still. You have a
> valid point with the unencrypted cookies though. I will probably fix
> this when doing the next AUR release (which will be pretty soon).
>
> >
> > > That is kind of fixed in Git (again, check [1], [2], [3] and [4]).
> > >
> > > [1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57
> > > [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19
> > > [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85
> > > [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
> >
> > None of these patches fixes the issue that session data will still be
> > send unencrypted. This is a real world issue; even if you login using
> > https it wont be unlikely that you later will visit the site unencrypted
> > (by clicking on a link or some resource you forgot to send via https).
>
> Agreed. I'm still against completely disabling HTTP. We will use HTTPs
> for all links by default so there shouldn't be any users unintentionally
> pasting HTTP links anywhere. Malicious links might still be an issue but
> observant users should be aware of that. And using secure cookies should
> fix that, anyway.
>

IMHO, I think that some HTTPs is better than nothing and that some HTTPs is
better than HTTPsing everything. So, I think that Lukas' solution is good
for now and it can be adjusted later if needed.


-- 
Estêvão Valadão