Re: GlusterD 2.0 status updates

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

 



> Every day we hear about vulnerabilities and exploits. Have we not yet
> reached the point were we just start with security enabled as a matter
> of routine?
> 
> Why aren't we using TLS (the real name, FWIW) from day one?

I think making it default for 3.8+ would be a good idea.  The only
issue is who's going to sift through our ongoing stream of failed
regression tests to see which ones might be related to this, and to
fix anything they find.  There are very few eyeballs on some of
this code, and those tend to be among our busiest eyeballs.  It's
part of why we're even looking at alternative RPC infrastructures.
In fact, I sent an email in an earlier thread that I probably
should have cited here already (inline for convenience).

http://www.gluster.org/pipermail/gluster-devel/2015-August/046607.html

In short, we're not getting a lot of mileage out of using the
same XDR-based infrastructure for GlusterD as we are for the I/O
path.  We've had many networking bugs that only manifest in
GlusterD, and it doesn't need RDMA support.  IMO moving GlusterD
onto something else would actually *reduce* the maintenance
burden for our current network code, and we could get always-on
TLS almost for free as well.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux