On Tue, Apr 15, 2014 at 11:00:45AM -0400, Simo Sorce wrote: > On Mon, 2014-04-14 at 15:07 +0200, Jaroslav Reznik wrote: > > = Proposed Self Contained Change: Remote Journal Logging = > > > The communication between the two daemons is done over standard HTTPS, > > following rather simple rules, so it is possible to create alternate > > implementations without much work. For example, curl can be easily used to > > upload journal entries from a text file containing entries in the export > > format. Basically, the data are sent in an HTTP POST to /upload with Content- > > Type: application/vnd.fdo.journal. When doing "live" forwarding, the size of > > the transfer cannot be known in advance, so Transfer-Encoding: chunked is > > used. All communication is encrypted, and the identity of both sides is > > verified by checking for appropriate signatures on the certificates. > What are the pros of using HTTP if all you are doing are POSTS to a > hardcoded URL ? Using HTTP makes it possible to use e.g. use curl to upload some logs from the commandline. It should also be fairly easy for people to write e.g. Python code to upload logs. I also expect people to want to send json formatted logs at some point, and the HTTP headers make things fairly extensible. I think that using standard HTTP is easier than designing a biderectional protocol. > HTTP seem like a bad idea in terms of security, certificates are > notoriously very hard to manage, even with the help of things like > certmonger, and hard to properly validate in most libraries today. > > Let alone dealing with setting up a CA just for enabling remote logging > (or otherwise painfully exchange fingerprints and white list > certificates for each client-server pair. > > And please do not tell me this is deferred to the admin to figure out, > because then it would mean this feature cannot seriously be used in > normal setups. I think you exaggarate a bit. Managing certificates is annoying, true, but there's lots of advice on the web and howto and various helper software. I'd imagine that in a setup with a few servers one would create the certificates on the receiver machine, copy&pasting some instructions from Fedora docs, and scp them to the other hosts. > Is there any reason why a better custom protocol that can be secured > using things like SASL or GSSAPI is not used ? It doesn't really fit well with the overall approach of using HTTP. But I'm open to suggestions how to do this better. The Change page is so obnoxiously detailed so that I can get feedback :) Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
