> Is it really necessary to worry about this at this point ?
Yes and no. There's two issues:

client authentication
 - this needs to be done when the server (the FreeMED billing
   module) let's its clients access data they wouldn't otherwise
   have access to - THIS IS NOT WHAT FreeMED-BILLING DOES to my
   understanding and that's why I think it may get away
   without client authentication, the way I understood the
   original proposal was that apps submit data to the billing
   module which in turn produces electronic submissions, HFCA,
   plain bills, you-name-it
 - this is better designed in than bolted on - IMHO

secure communications
 - this is needed when client and server communicate across
   unsafe links such as LANs, WANs or the internet in general
 - this may be necessary for the proposed billing module
 - this can be achieved below (ssh, ...) or within (ssl) the
   communications protocol and is thus easier to bolt on

So, yes and no. However, Horst argues that even client
authentication CAN be bolted on. Hence, No. :-)

This is such an important project that it should not be held
up by valid but for-now-secondary matters. If it is insecure
it can always be refactored to be secure. Python makes that
easier than Perl IMHO ;-)

Let me reiterate my offer of contributing the Modem::Hayes.pl
if need be. It is based on CPAN standard Device::Serial.pm.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Reply via email to