Re: config files proposal

[antonio_duran@hotmail.com (Antonio Duran)]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uu1o7uuw1.fsf@gsfc.nasa.gov>...
> antonio_duran@hotmail.com (Antonio Duran) writes:
> 
> > Form my point of view, in some cases it could be necessary/interesting
> > to keep configuration information confidential and to provide the
> > means to check the integrity of a configuration file.
> 
> I'm not clear what you mean by "confidential". Clearly, the
> application program that uses the config file must be able to read it.
> 
> If you mean that no other process/person should be able to read it,
> that would be up to the operating system. If the OS provides access
> controls to files, you can enforce confidentiality.
> 
> I think that issue has to be outside the scope of the Config_Files
> API, since it depends heavily on the OS, and we want the Config_Files
> API to be OS independent.
> 
> 
> As for checking the integrity of the config file, that could be done
> with an XML DTD and a validating parser. Come to think of it, that is
> an advantage of using XML that I had not considered. Although, a
> non-XML parser could also check integrity to the same degree.
> 
> Hmm. I'm not clear what you mean by "integrity". XML DTD's allow
> specifying what values must be present, and to some extent what type
> they are.
> 
> In other situations, "integrity" might mean a version control revision
> number, or a checksum, or something similar.

What I meant with confidentiality and integrity was to use
cryptographic technics to encrypt/decrypt config files for
confidentiality and hash/digest for checking integrity.

I know this is far beyond the scope since by using that the file
couldn't be modified by hand with a simple text editor. My intent was
to know if that kind of functionality could be of interest in some
circumstances.

Antonio Duran